bug(unic-archon-dlc): /build marks a slice green when its RED test pins only part of the slice's acceptance criteria #655

Observed

Build run 9ff2d6da (unic-archon-dlc 0.29.0, Archon 0.11.1, Windows 11), Consumer Becklyn-Studios/pr-review-agent, 18 slices in issues.json.

• The run-build loop marked 17 slices green-done in build-state.json.
• The same run's goals-check then reported 26 of 65 acceptance criteria MISSING (39 covered, 2 of them weak).
• Example: slice findings-review is green-done, yet its criterion "A finding without a consequence or without evidence is returned to the model and not posted" has neither a test nor code. The report.md matrix row reads: No test. submit-review.ts:119-121 renders without validating.

The pattern across slices:

1. RED writes a test that covers a subset of the slice's acceptance_criteria.
2. GREEN satisfies that subset.
3. The loop records green-done and moves on.

Nothing compares the RED test against the slice's criteria before GREEN, and no later step reopens a slice.

Why it matters

green-done reads as "this slice is done", but it only means "the test this slice's RED happened to write passes". The gap surfaces once, at goals-check, after every slice is marked done and the loop has ended. By then open-pr opens the pull request with the gap in it (see #439).

In this run goals-check was right. The problem is upstream of it: the loop's definition of done is looser than the slice's own criteria.

Evidence

• specs/0001-first-review/report.md § Goals-Check Coverage Matrix in the Consumer's build branch: 26 rows marked ✗ MISSING, each of them in a slice that build-state.json records as green-done.
• PR opened by the run: 26 MISSING criteria stated in its own body.

Related

• bug(unic-archon-dlc): goals-check counts, the precheck reads, and only the counter reaches evidence.json #483: goals-check over-counts COVERED. Here it did not; the gap is in the loop.
• bug(unic-archon-dlc): open-pr precedes its gate, and a config-value gate has no safe middle #439: a build that fails its own acceptance criteria opens a pull request.

Not decided

• Whether RED must map each failing assertion to a named acceptance criterion, and is not red-done until every criterion of the slice has one.
• Or whether the loop reopens a slice when goals-check reports one of its criteria MISSING, instead of proceeding to open-pr.
• Or whether /tickets should cap a slice at one acceptance criterion, so slice green and criterion covered coincide.