orch: work-item state is written once and never re-read — finished containers stay open, partial-scope PRs close their item

[bmethod]

Work-item lifecycle state in orch is written only by the workflow step that happens to be running, and nothing ever re-checks it. Two distinct defects fall out of that, both observed in a real repo (drovr, Linear team DRO) and both silent — the tracker looked plausible while five items were wrong.

Defect 1 — a finished container can stay open forever

issues validate-completion --container has exactly one call site in the whole skill set:

$ grep -rn -- '--container' .agents/skills/ --include=*.md | grep -v linear/SKILL.md
.agents/skills/orch/workflows/merge-pr.md:211

So a container closes only if the merge of its final child is driven through merge-pr.md § 5 step 2. Every other path leaves it open with no alarm and no later sweep: a merge done outside the workflow, a session that ended between merge and § 5, or § 5's own documented defer with a § 6 note and continue to step 3 branch when the per-parent lock is contended. DEVELOPMENT.md:69 already records that this sequence is agent-interpreted prose rather than a tested helper.

Observed:

Container	Parked state	Since	Children
DRO-107	In Review	2026-08-10 (last child merged 2026-08-16T01:00Z)	6 Done, 1 Canceled
DRO-53	Todo	children Done since 2026-08-09	2 Done

Both return all_ok: true from validate-completion --container today, so the mechanical check that would have closed them was simply never run again.

The cost is not cosmetic. On 2026-08-16 a TPM audit-issues pass cancelled a sibling container and justified it in writing with "the omitted-gates half is DRO-107's active scope (In Review)" — a planning decision taken against a container whose work had been complete for 22 hours.

Defect 2 — a partial-scope PR closes its work item, and nothing reverts it

submit-pr.md:107 writes Closes [ISSUE_REF] - [TITLE] into the PR body with no branch for a PR that ships only part of the item's acceptance criteria, and merge-pr.md:182 then proceeds on the stated assumption that "merged PRs close issues via magic words". Neither step verifies that what merged is what the item asked for.

Observed on DRO-15 (acceptance criteria 1a, 1b, 1c):

• 2026-08-09T13:28:20Z — PR fix(issue-447): make on-disk artifact the sole review-pr completion condition #462 merges, shipping criterion 1a only. Its body says so explicitly: Linear: DRO-15 (acceptance criterion **1a only** — see Scope below).
• 2026-08-09T13:28:22.900Z — issue moves In Review → Done.
• 2026-08-09T13:29:25Z — the same session posts, in bold: "This issue stays open — 1b and 1c are not done, and 1b cannot be done as written."
• Today, seven days later: still Done. Neither 1b (--ignore-scripts + lockfile in verify-pgvector.mjs) nor 1c (stage-time staging-vs-workspace pin assertion) exists in the tree; grep finds nothing for either. Its parent DRO-53 therefore also reads as ready to close while two of its five acceptance criteria were never built.

The agent knew, wrote down the truth, and the state stayed wrong — because reverting is not a workflow step. It is ad-hoc judgment: on DRO-155, whose PR #496 shipped half the item, a different session did move the item back (In Review → In Progress, 63 seconds before writing its "REMAINING SCOPE" comment). Same situation, opposite outcome, no rule.

Suggested direction

Both defects have the same shape — a write with no read-back — so one sweep addresses both. A orch reconcile pass (standalone, and folded into oversee and audit-issues § 1) that reports, without mutating:

1. containers whose validate-completion --container is all_ok but whose state is non-terminal;
2. items in a started state whose linked PR is merged or absent, older than a threshold;
3. items closed Done whose description carries unchecked acceptance criteria.

(3) is the cheapest useful check and would have caught DRO-15 the same day.

Narrower alternative if a sweep is out of scope: make submit-pr require an explicit partial-scope declaration when the PR does not satisfy every acceptance criterion, and have merge-pr § 5 read the item's state back after the merge and restore a started state when the declaration says scope remains. That fixes defect 2 only; defect 1 still needs a backstop, because its failure modes are all "the workflow did not run".

Environment

• vstack orch skill v3.0.0, linear skill v1.1.0
• Linear tracker, drovr repo, observed 2026-08-16

[linear-code]

VST-318