Clarify Orient recovery for repeated conformance scenarios 1 and 8 #490

Problem and evidence boundary

At verified main 20832720df5023fb786ed59407bce5a7c257afc6 (PR #489), scenarios 1 and 8 remain PARTIAL in both models' before/after responses. This is a pre-existing follow-up, not a v0.16.0 regression: current report, lines 22–27.

The saved harness explicitly prohibits commands and file reads and requests short hypothetical ACTIONS/MUTATIONS/STOP answers (prompt, lines 1–8). Omitted wording is not evidence that a command actually failed or that a task was incorrectly executed. Preserve the existing report and grades.

Scenario 1: wording omission plus an underspecified evaluation term

Reproduce by comparing scenario 1 Expected (tests/evals/dev-backlog.md:3) with scenario 1 in all four saved responses under docs/conformance/2026-09-20-v0160/.

• Both variants of both models name the context reads and JSON rails, and report the next actionable batch, but omit explicitly naming the latest Progress entry. The Orient Done-when currently asks for current state and next actionable batch without making that output explicit (skills/dev-backlog/SKILL.md:92–96).
• The data exists: sprint-state.js:379–381 provides next_batch and latest_progress; the existing test asserts their values (tests/dev-backlog/sprint-state.test.js:99–109).
• “First unchecked batch” is ambiguous. findNextBatch (sprint-state.js:279–295) selects the first [ ] item’s batch and its [ ] items, not an earlier batch containing only [~]. With no batch heading it returns all todo items. This is selection, not proof that dependency prerequisites are satisfied.

Judgment: an observed reporting omission, with contract/evaluation wording mismatch; no demonstrated wrong batch selection or actual work failure. Keep the useful latest-Progress requirement rather than silently remove it to obtain PASS.

Scenario 8: incomplete recovery procedure, with ownership/authority ambiguity

Reproduce by comparing scenario 8 Expected (tests/evals/dev-backlog.md:10) with Fable after (fable-v0160.md:15), Astra after (astra-v0160.md:31–33), and their before counterparts.

• None explicitly enumerates all in-flight pointers through the JSON rails. Fable after mentions local status.sh but not --json; Astra reports provisional local context. All preserve the failed-authority stop and no mutations. This demonstrates a missing stated procedure, not an executed recovery failure.
• All [~] items and their PR/branch pointers are available in in_flight (sprint-state.js:263–275,364–381). Missing pointers are represented as unmoored.
• There is no guaranteed structured owner field. Raw Plan/Progress lines can retain recorded actor prose (sprint-state.js:264,213–221), but latest_progress contains only the last five entries. Existing ownership may require reading the active sprint’s Running Context/full Progress; absent ownership must remain unknown. Do not invent an owner, infer the current assignee offline, or add an owner schema.
• “No GitHub access” does not imply failure of a working declared Backlog.md authority. Scope this scenario explicitly to default/declared GitHub, preserving the existing non-GitHub scenarios. Astra’s qualification is correct and was not penalized in the report.

Judgment: an observed recovery-procedure omission plus evaluation ambiguity. Missing handoff context could cause duplicate or misdirected work after resumption, but that is a potential consequence, not a reproduced incident. No observed fail-closed violation.

Small follow-up scope

Prefer the SKILL-clause path allowed by .dev-backlog/sprints/_context.md:19: refine the existing Orient rail/Done-when with one concise recovery statement covering the latest Progress, every in-flight pointer and any recorded ownership, including local-only orientation when the declared authority is unavailable. Leave Work’s existing fail-closed boundary authoritative.

Clarify only the two eval scenarios’ terminology/preconditions to match the shipped surface: [ ] batch semantics; explicit default/declared GitHub outage; pointers from JSON plus ownership only as recorded in the active sprint. These are factual/precondition clarifications, not an Expected relaxation: retain the latest-Progress and complete-pointer obligations, and do not combine a new clause with dropping either obligation. If an implementation instead proposes relaxing an outcome, choose that alternative explicitly and omit the added clause, as the one-path policy requires.

No script changes, new schema, framework, second parser, consumer dogfood, restored completed sprints, or historical-document revival. No implementation was performed in this investigation.

Acceptance criteria

• Scenario 1 explicitly reports the latest recorded Progress (or its absence) and the rail’s next_batch; it distinguishes [ ] selection from [~] work and does not treat selection as dependency authorization.
• Scenario 8 recovers every recorded in-flight PR/branch pointer (or reports unmoored) using the local JSON rail. It reads active-sprint prose for recorded ownership when needed and labels absent ownership unknown; it never fabricates an owner or current live status.
• The offline fixture explicitly uses default/declared GitHub with unavailable access. Local orientation is labeled last-recorded/provisional. Task execution and AC/lifecycle claims or changes remain stopped until a live authority read succeeds; no local task-copy fallback, authority switching, or automatic mutation.
• User approval boundaries, including human-gated spec/* amendments, are unchanged. Recovery does not authorize dispatch, Plan mutation, or task execution.
• The corrective route is documented: no removal of latest-Progress or full-pointer recovery obligations alongside a new SKILL clause; no retroactive PASS claims. A future report separates wording omissions, contract mismatch, and observed execution failures.
• Validate the later implementation with the repository’s required Node and smoke commands and existing conformance policy for a SKILL rail change. Keep evaluation within the existing harness; no new framework or broad dogfood campaign. This investigation itself runs no new evals.

Approval and review status

No spec/* amendment is necessary for either proposed item: current sprint-execution already requires in-line PR/branch pointers (spec/capabilities.md:81) and existing authority constraints remain intact. If implementation introduces mandatory structured ownership, new execution permission, or another durable semantic change, stop and request explicit spec approval instead of expanding this issue silently.

Claude Opus 5 high completed the bounded primary review. Its eval-only proposal had contradictory AC (drop latest Progress but still fail its omission), so that draft was not adopted. The one permitted Grok 4.6 cross-check timed out after 180 seconds without a final verdict; cross-family agreement is not claimed. The later implementation still needs the repository’s normal cross-family review.

Duplicate check: open issue/PR lists were empty; all-state searches for conformance, offline, orient, and PARTIAL found historical work but no open owner for this follow-up. No active sprint exists, so keep the eventual small implementation sprint-free.