test(console): pin what the engine actually emits for every halt category

[abrichr]

The gap

A demo or sample fixture stays schema-valid and digest-consistent forever, because both properties are computed from the fixture. Nothing anywhere asserted that a fixture is still a shape this engine can emit.

That is not theoretical. The mapping tables in console/human_decisions.py and the accept-list in console/attention.py both moved this cycle. Every downstream test would have stayed green while a fixture described last month's product — which is exactly what would have happened silently between the merge of #290 and today.

What this adds

tests/golden/human_decision_tasks.json, regenerated from real engine output: one durable pause per halt category controller.classify_halt() can produce, each projected through portable_remote_decision_task() — the Cloud-bound projection, with presentation already discarded, so nothing in the artifact describes evidence the dashboard is not entitled to.

The artifact records:

field	why a consumer needs it
category_question_map	the (task_kind, question.template) a fixture may claim
delivery_uncertain_override	the kind/template an unresolved delivery substitutes for any category
action_vocabulary	the only buttons a fixture may advertise
safe_slot_fields / evidence_fields	the projected key sets
never_populated_safe_slots = ["candidate_count"]	any surface that says "found N matches" is asserting a number the engine has never sent
never_emitted_task_kinds = ["operator_review"]	no Flow path emits it
halts[]	per category: what attention._normal_category made of it, the delivery state, the resulting kind/template, non-null slots, allowed actions

Four tests: the golden comparison; the action vocabulary is exactly the portable enum; teach and escalate are offered at every pause (proven from real capabilities, not from reading _allowed_actions); and an anchor that a replayer-driven halt — Replayer(durable=True).run(...), nobody's hand-built pause — lands on the same golden row.

Proof it bites

The comparison walks both documents together, so a failure names the exact field rather than dumping two documents at each other. Two mutations, both restored afterwards:

1. _TASK_COPY["resolution"] -> ("halt", "review_halt", ...):
   golden drift at category_question_map.resolution.question_template: the engine now emits 'review_halt', the artifact still says 'resolve_ambiguity'
2. dropped "resolution" from attention._KNOWN_CATEGORIES:
   golden drift at halts.resolution.projected_category: the engine now emits 'operator_review', the artifact still says 'resolution'

Regenerate deliberately with OPENADAPT_UPDATE_GOLDEN=1 pytest tests/test_human_decision_golden.py; the run is ~0.9s and adds no CI leg.

Boundary

The artifact is closed-vocabulary metadata — enum names, key names, and counts. No values, no run content, no PHI, no tuning. Mechanism, not data, so it is on the public side of AGENTS.md 4.2.

Consumers

openadapt-cloud vendors this file and checks its /demo/attention and ?sample=eligibility fixtures against it (companion PR). Nothing in Flow's behaviour changes here — this PR is test-only.

Noted, not fixed

Two findings this work surfaced; both are in the shared attended projection another lane is editing, so neither is touched here:

• delivery_uncertain is missing from attention._KNOWN_CATEGORIES. The golden artifact records it: halts.delivery_uncertain.projected_category is operator_review, not delivery_uncertain. The task kind still recovers at the next layer, so the operator gets the right question, but the queue headline is the generic "This run needs local operator review" for the one halt where the operator must reconcile rather than retry. Fix is two edits — add the category to _KNOWN_CATEGORIES and give it a _COPY entry — and the golden file will show the change.
• tests/test_halt_detail.py::test_resolution_halt_says_what_broke_and_what_continue_will_recheck fails on origin/main in a freshly uv sync --all-extras'd tree (halt["target_label"] is None, expected "Open"), independent of this branch. Flagging for whoever owns _safe_target_label.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NyCHrzA1psrKMFfroYbzaM

[abrichr]

Note for the reject lane (flow feat/attended-reject-action, cloud feat/attended-reject-action)

This is a deliberate interaction, not a conflict. When reject lands it will touch HumanDecisionAction in openadapt-types and _ACTION_MAP in console/human_decisions.py, and two assertions here will go red:

• test_the_action_vocabulary_is_exactly_the_portable_enum — _ACTION_MAP must stay a bijection with the enum, so adding the action to only one side fails.
• the golden comparison — action_vocabulary in tests/golden/human_decision_tasks.json will no longer match.

The fix is one command plus a read of the diff:

OPENADAPT_UPDATE_GOLDEN=1 pytest tests/test_human_decision_golden.py

and, if the action becomes offerable at a pause, the per-halt allowed_actions rows change too. That is the point — a demo fixture in openadapt-cloud may advertise a reject button only after the vocabulary ships and the artifact is refreshed, which is exactly the gate the design asked for. Nothing here blocks that lane; it just makes forgetting a consumer loud.

[abrichr]

Closing this stale contract PR without deleting its branch. Current main includes PR #296, where RemoteDecisionProjection adds the outer delivery_tier and halt_context fields. This PR's generator records only projection.task while describing the artifact as the exact Cloud projection, so its current golden cannot validate the contract that Flow now emits. It also conflicts in public-artifacts.json. Preserve the branch for reference. A later focused PR can regenerate the contract from current main and either cover the complete outer projection or narrow the claim to the signed task only.