FO can advance past confirm-mapping without writing the stage-report section to index.md

[gcko]

Problem

In the spacedock-answer-questions workflow, the First Officer can mark semantic-mapping.yml as review.status: approved and advance the entity past the confirm-mapping stage without writing the corresponding ## Stage Report: confirm-mapping section into index.md.

This produces an entity where the YAML mapping records "approved" but the prose audit log of that approval is missing. Subsequent stages (propose-approach, answer, validate, format, review-format) write their reports as expected; the gap is specifically at the confirm-mapping transition. The entity still reaches terminal status=answered with a valid verdict.

Observed on plugin version 0.12.1, headless CI mode.

Evidence

Two confirmed instances in a downstream consumer's runs:

1. Prior archived entity — required a manually backfilled ## Stage Report: confirm-mapping section after the fact. The backfill note recorded: "Restored the missing confirm-mapping audit trail. The restored report reconciles the entity body with the existing approved semantic mapping."
2. Recent automated CI run (plugin 0.12.1) — same shape: approved mapping in YAML, missing stage-report section in index.md, entity nonetheless advanced through answer, validate, format, review-format, and reached terminal answered/PASSED.

In both cases the downstream consumer (a wrapper that gates artifact publishing on the presence of both pieces of evidence — review.status: approved AND the prose stage report) had to either backfill the section manually or relax its gate.

Impact

Any downstream consumer that uses the ## Stage Report: confirm-mapping section as part of an approval-evidence pair will either:

• Reject otherwise-valid entities, or
• Backfill the section manually after the fact, or
• Relax the gate (which weakens audit guarantees)

The stage report is a load-bearing audit artifact — its absence creates a documentation gap even when the underlying approval was real. For a consumer that throws on the missing-section case, the symptom is a fully successful agent run whose result is discarded by the post-flight validator.

Reproduction notes

No deterministic repro yet. Observations suggest the bug is intermittent — most runs do write the section. Hypotheses:

• The FO emits the YAML approval and the body section in two separate writes; a partial write or race could leave the body un-updated.
• A prompt-length or token-budget condition causes the FO to skip the prose summary while still advancing stage status.
• The FO has an implicit "skip stage report" code path for fast-resolve gate cases that incorrectly fires for confirm-mapping.

Proposal

Make ## Stage Report: confirm-mapping section presence a hard precondition for advancing entity status past confirm-mapping. Either:

1. Preventive: The FO refuses to advance status if the section is missing from index.md. Preserves the invariant in real time.
2. Corrective: The status binary asserts section presence as part of post-stage validation, producing a clear error before the entity reaches terminal state.
3. Both — First-officer must use unique ensign names per dispatch #1 as the primary guarantee, feat: GitHub issue/PR workflow integration with PR lieutenant #2 as defense-in-depth for the case where the FO is bypassed (e.g., manual status --set edits).

Option 1 is preferable: option 2 alone leaves the entity in a "ghost-approved" state between the FO write and the next status read.

Scale context

• Plugin version: 0.12.1
• Workflow: spacedock-answer-questions (chain includes map-semantics → confirm-mapping → propose-approach)
• Mode: headless, claude --bare, single-entity non-interactive
• Frequency: at least 2 confirmed occurrences in a downstream consumer's logs over ~2 weeks