13# Diagnose Why Work Stopped
14
15A repeatable procedure for the recurring class of issues where the user (or a manager) points at a stalled / looping / over-recovered issue tree and asks "why did this stop / why is this looping / how do we make sure this doesn't happen again?"
16
17This skill is **diagnostic + product-design**, not engineering. The output is a written root cause and an approved plan. No code changes leave this skill.
18
19Canonical execution model: read doc/execution-semantics.md before diagnosing or proposing a new liveness/recovery rule. Use that document as the source of truth for status, action-path, post-run disposition, bounded continuation, productivity review, pause-hold, watchdog, and explicit recovery semantics. If the investigation finds a true product-rule gap, the plan should say whether doc/execution-semantics.md needs a matching update.
20
21## When to use
22
23Trigger on an assignment whose title or body matches any of:
24
25- "why did this work stop", "why did this stall", "why did this just stop"
26- "infinite loop", "looping", "spinning", "going too deep", "recovery went too deep"
27- "liveness — what happened here", "this tree stopped working", "stuck"
28- "approach it from a product perspective", "general product principle / rule"
29- An attached link to a specific stalled / looping / over-recovered issue tree
30
31Also use when the user asks for forensics, root cause, or a write-up *before* any product change.
32
33## When NOT to use
34
35- The assignment asks you to ship a code change directly. Use normal engineering flow.
36- The assignment is a normal bug report against a specific feature. Use normal investigation.
37- You are the original implementer being asked to fix your own bug. Use normal debugging.
38
39## Three invariants you must preserve
40
41Every diagnosis and every proposed rule must hold these three invariants together. The user has restated them on at least four issues; treat them as load-bearing:
42
431. **Productive work continues.** Agents that have a clear next action must keep working without needing the user to wake them. ([PAP-2674](/PAP/issues/PAP-2674), [PAP-2708](/PAP/issues/PAP-2708))
442. **Only real blockers stop work.** Stops happen when something genuinely cannot proceed (missing approval, missing dependency, human owner). Pseudo-stops (in_review with no action path, cancelled leaves, malformed metadata) must be detected and routed, not left silent. ([PAP-2335](/PAP/issues/PAP-2335), [PAP-2674](/PAP/issues/PAP-2674))
453. **No infinite loops.** Stranded-work recovery and continuation loops must be bounded and distinguishable from genuinely productive continuation. ([PAP-2602](/PAP/issues/PAP-2602), [PAP-2486](/PAP/issues/PAP-2486))
46
47If a proposed rule violates any of the three, drop it or rework it. State explicitly in the plan how each invariant is held.
48
49## Procedure
50
51### 0. Read the current execution contract
52
53Before walking the tree, read doc/execution-semantics.md and keep its terms intact:
54
55- live path / waiting path / recovery path
56- post-run disposition: terminal, explicitly live, explicitly waiting, invalid
57- bounded run_liveness_continuation
58- productivity review vs liveness recovery
59- active subtree pause holds
60- silent active-run watchdog
61
62Do not invent a new rule until you can state how it differs from the current execution semantics document.
63
64### 1. Forensics on the named tree — before anything else
65
66Do this in the same heartbeat. Do not propose a rule until you have a concrete stop point.
67
68- Open the linked issue (and its blocker chain, parents, recovery siblings, recent runs).
69- Walk the tree node-by-node and find the exact issue + state combination that stops the world. Common shapes seen in the company so far:
70 - in_review with no typed execution participant, no active run, no pending interaction, no recovery issue ([PAP-2335](/PAP/issues/PAP-2335), [PAP-2674](/PAP/issues/PAP-2674)).
71 - in_progress after a successful run with no future action path queued ([PAP-2674](/PAP/issues/PAP-2674)).
72 - Blocker chain whose leaf is cancelled / malformed / cross-company-inaccessible ([PAP-2602](/PAP/issues/PAP-2602)).
73 - issue.continuation_recovery waking the same issue >N times after successful runs ([PAP-2602](/PAP/issues/PAP-2602)).
74 - Stranded-work recovery treating its own recovery issues as more recoverable source work ([PAP-2486](/PAP/issues/PAP-2486)).
75- Quote the evidence: run ids, comment timestamps, status transitions. "Inferred" is acceptable only when an API boundary blocks direct evidence — say so explicitly and mark the claim provisional ([PAP-2631](/PAP/issues/PAP-2631)).
76
77Respect the API boundary. If the linked issue is in another company and your agent token returns 403, do not bypass scoping. Either request a board-approved diagnostic path or proceed from inferred PAP-side evidence and label it.
78
79### 2. Survey recent related work
80
81Before proposing a new product rule, read what already shipped this week in the same area. The user has explicitly called this out: ([PAP-2602](/PAP/issues/PAP-2602)) "review our recent work on liveness that we shipped in the last couple of days." A new rule that contradicts code merged 48 hours ago is rework, not improvement.
82
83Quick survey:
84- Recent merged PRs in the affected area.
85- Recent done issues whose title mentions liveness, recovery, productivity, continuation, or the affected subsystem.
86- Any active plan documents on parent issues. The fix may belong as a revision to an existing plan, not as a new top-level proposal.
87
88State in the forensics: "I reviewed X, Y, Z. The new gap is …"
89
90### 3. Classify each non-progressing issue in the tree
91
92For every issue in the affected tree that is not done / cancelled / actively running, decide:
93
94- **Truly needs human or board intervention** — name the owner and the action.
95- **Agent-actionable but not currently routed** — name the rule that would have routed it, and the agent that should have been waked.
96- **Already covered** — point at the active run, queued wake, recovery issue, or pending interaction.
97
98This is the table the user has asked for repeatedly ([PAP-2335](/PAP/issues/PAP-2335)). Without it the plan is abstract.
99
100### 4. Frame as a general product rule
101
102The user does not want a one-off patch on the named tree. They want the rule. Two checks:
103
104- The rule is **stated as a contract**, not as an if/else patch. Example contract: "every agent-owned non-terminal issue must finish each heartbeat with a terminal state, an explicit waiting path, or an explicit live path" ([PAP-2674](/PAP/issues/PAP-2674)).
105- The rule is reconciled against doc/execution-semantics.md. Prefer citing and applying the existing contract; propose a document change only when the current doc is incomplete or contradicted by accepted/implemented behavior.
106- The rule **explicitly preserves the three invariants** above. Show the work.
107
108If the rule would have blocked a recent productive run from succeeding, drop or narrow it.
109
110### 5. Plan, do not code
111
112Write the plan into the issue's plan document. Cover:
113
114- Forensics summary (root cause + evidence).
115- The general product rule, stated as a contract.
116- Whether the existing doc/execution-semantics.md contract already covers the case, or what exact documentation update is needed.
117- Phased subtasks: typically Phase 0 resolves the named live tree (carefully, not destructively), Phase 1 codifies the contract in docs, then implementation phases for detection, recovery, UI surfacing, security review, QA, and CTO review.
118- Explicit assignees per phase; favor team specialty (CodexCoder for server, ClaudeCoder for FE, UXDesigner for visible state, SecurityEngineer for ownership/permissions, QA for validation).
119- Blocking dependencies wired with blockedByIssueIds, parallel branches identified.
120
121Do not create the child issues yet. Do not push code.
122
123### 6. Request approval, then decompose
124
125- Open a request_confirmation interaction targeting the latest plan revision. Idempotency key confirmation:{issueId}:plan:{revisionId}.
126- Wait for board/CTO acceptance. If the user posts a new comment that supersedes the plan, the prior confirmation is invalidated — open a fresh confirmation tied to the new revision ([PAP-2602](/PAP/issues/PAP-2602) cycled three revisions; that is fine).
127- Only after acceptance: create the phased child issues with the right assignees and dependencies, then block this parent on the final QA / CTO review issue so the parent only wakes when the chain finishes.
128
129### 7. Phase 0 hygiene on the named tree
130
131Phase 0 cleans up the live tree without papering over evidence:
132
133- Move stalled in_review leaves with no participant to todo with a precise next action and named owner ([PAP-2335](/PAP/issues/PAP-2335)).
134- Detach cancelled/dead blockers from chains they were holding hostage; do not silently mark issues done to clear backlog.
135- Leave a comment on the original named issue summarizing what changed and why; never hide the recovery chain history.
136
137### 8. Final close-out
138
139When the phase chain is complete, post a board-level summary comment on the parent issue: what changed, what the new contract is, what the rollout step is (e.g. "restart the control-plane to pick up the new response shape"), and the live state of the originally-named tree. Then close the parent.
140
141## Pitfalls
142
143- **Coding before approval.** The user has said "make a plan first" on every recent diagnostic issue. Producing code in the forensic phase wastes the round-trip.
144- **Restating one invariant at the cost of another.** Bound continuation too tightly and productive work stalls; loosen recovery and infinite loops return. Always check all three.
145- **Skipping the recent-work survey.** Proposing a contract that contradicts what shipped 24 hours ago is the easiest way to get the plan rejected.
146- **Letting "in_review" mean done.** A leaf assigned to another agent with no participant or active run is not progress; treat it as a stop.
147- **Bypassing company scoping.** Cross-company forensics needs a board-approved diagnostic path, not a database read.
148- **Recursive recovery.** Stranded-work recovery that recovers its own recovery issues is the canonical infinite loop ([PAP-2486](/PAP/issues/PAP-2486)). Detect it and refuse to deepen.
149- **Hiding the chain.** Don't silently delete or hide the symptomatic recovery issues — the operator needs the audit trail.
150
151## Verification checklist (before posting the plan)
152
153- [ ] The exact stop point in the named tree is identified with run ids / comment ids.
154- [ ] Recent shipped work in the same area was surveyed and is referenced.
155- [ ] Every non-progressing issue is classified human-needed / agent-actionable / already-covered.
156- [ ] The proposed rule is stated as a contract, not a patch.
157- [ ] All three invariants are explicitly preserved.
158- [ ] No code change has landed in this heartbeat.
159- [ ] A request_confirmation against the latest plan revision is open.
160- [ ] Phase 0 of the plan addresses the live named tree without destroying evidence.
161- [ ] Implementation phases name specialty-appropriate assignees and blockedByIssueIds dependencies.
162