Function completion_column 

pub fn completion_column(
    board: &BoardConfiguration,
    config: &Config,
) -> Option<String>

The board’s completion column, chosen by category rather than by done_column (WP09).

Why this exists

BoardConfiguration::effective_done_column() answers a config question — “what did the author name?” — and on a board with a category_map it is not the same question as “which column is complete?”. A board whose map puts completed on shipped while done_column is done has two different answers, and every consumer that asked the config question got the wrong one.

That is not hypothetical. The blocked-move guard — the previous mission’s central feature — read done_column and early-returned for any other column, so on such a board:

• a blocked issue moved into shipped (genuinely complete) got no warning, no --yes requirement, and no blocked_move_acknowledged History entry; and
• moving it to done (not complete at all) did demand confirmation, because that is the column the config named.

The guard was silently disabled on exactly the boards this mission exists to support. Found by the call-site audit T038 step 4 asks for, which is the argument for having one: the pattern is five lines long and the consequence is a safety check that does not run.

Which column, when several are complete

The first configured column whose category is complete, in board order. A board with two completed columns has no single completion column, and the first is the only choice that does not depend on iteration order. None only for a board that failed validation — nothing resolves to completed — which the callers handle rather than this function panicking on a config the caller could not have built.