goal-ledger-resume

Goal Ledger — resume and recover

Treat the ledger and Git as evidence left by another agent — possibly a weaker one, possibly mid-sentence. Establish what is verified, repair bookkeeping without discarding work, and continue from the first safe action.

1. Establish your role

• If you were handed a specific phase to run, use the goal-ledger-execute skill instead.
• If you are an ordinary helper subagent working from a delegated prompt, ignore the ledger and this skill and continue only the task you were given. An unfinished ledger is not a blocker for that task and is not worth reporting unless the prompt asks for ledger work.
• Otherwise you are resuming as the planner: you own the goal, the plan, Goal status, Git, and Gate D.

Read sections 1–4 of the sibling goal-ledger skill. If .goal-ledger/GOAL.md is missing, say there is no ledger to resume. If status is completed or abandoned, report that and stop.

2. Decide whether this request resumes the goal

• The user asks to resume, or the request matches the recorded Outcome: resume without another intent question.
• The ledger is blocked-on-human and the user answers its blockers: record the answers into the affected phase's ## Context so a re-delegated executor can see them, return affected items to [todo], and continue.
• Status drafting: return to Gate A. Status approved: if strategy, branch, baseline, or approval commit is missing or inconsistent, return to Gate B; otherwise return to Gate C.
• Status in-review: Gate D was started and not finished. Re-run it from the top rather than trusting a partial ## Review.
• Status awaiting-acceptance: report the result and ask for acceptance; do not resume execution.
• An unrelated request: report the unfinished goal and ask whether to resume it or use the goal-ledger-abandon skill. Never overwrite it silently.

3. Reconcile Git

Skip Git steps when Repository: no.

1. Verify the current branch equals Work branch. If not, do not switch with a dirty tree. Report both branches and ask before switching.
2. Verify the immutable baseline exists and is an ancestor of HEAD. If not, stop with the exact inconsistency.
3. Inspect git log <baseline>..HEAD, including commit trailers. Classify matching Goal-ID commits, foreign commits, merge commits, and phase begin/close pairs. Record foreign history in Handoff; it may prohibit squashing but does not justify deleting work.
4. Compare locally known starting/work upstream refs with their recorded Gate B SHAs. Record advances, rewinds, divergence, or goal-commit publication in Handoff. On current-branch, any upstream movement prohibits automated squash.
5. Inspect the worktree. A phase-begin commit followed by a clean tree means phase work did not start. A dirty tree means work may have stopped mid-phase; inspect the diff and do not discard it.
6. A completed phase without a matching close commit is unverified until its ## Verify passes. A close commit with stale ledger status may be reconciled after its check passes.