Damage Control

Table of Contents

• Overview
• When To Use
• When NOT To Use
• Damage Triage
• Module Reference
• Integration Pattern
• Exit Criteria

Damage Control

Overview

Provides recovery protocols for agents that encounter broken state mid-session. Damage control covers four failure classes: agent crashes with partial work on disk, context window overflow that causes state loss, merge conflicts blocking forward progress, and general session state corruption requiring reconciliation.

The skill does not prevent failures. It defines what to do after one has already happened, so recovery is consistent, auditable, and does not silently discard work.

When To Use

• An agent process crashed and left files in an unknown state
• A session hit the context limit and cannot load prior decisions
• git merge or git rebase produced conflicts the agent cannot

resolve automatically

• Observed state (files on disk, task list, git index) disagrees

with expected state

• A downstream agent reports missing artifacts that should have

been produced upstream

When NOT to Use

• Proactive risk assessment before work starts (use

Skill(leyline:risk-classification) instead)

• Strategic architectural decisions after a failure (use

Skill(attune:war-room) instead)

• Routine error handling within a single tool call (use

Skill(leyline:error-patterns) instead)

Damage Triage

Use this decision tree to route to the correct module:

flowchart TD
    A[Failure detected] --> B{Agent process crashed\nor exited unexpectedly?}
    B -->|Yes| C[modules/crash-recovery.md]
    B -->|No| D{Context limit hit or\nprior decisions unavailable?}
    D -->|Yes| E[modules/context-overflow.md]
    D -->|No| F{git merge / rebase /\ncherry-pick conflicts?}
    F -->|Yes| G[modules/merge-conflict-resolution.md]
    F -->|No| H{State internally inconsistent?\ntask list vs disk vs git index}
    H -->|Yes| I[modules/state-reconciliation.md]
    H -->|No| J[No damage-control needed]

When multiple failure types overlap, start with state-reconciliation.md to establish a known baseline, then address the specific failure class.

Risk Assessment Checklist

Before executing Level 1+ tasks, complete the risk assessment checklist from modules/risk-assessment-checklist.md. Answer these five questions:

1. What could fail in production? List specific failure scenarios. 2. How would we detect it quickly? Monitoring, alerts, logs. 3. What is the fastest safe rollback? Step-by-step procedure. 4. What dependency could invalidate this plan? External dependencies. 5. What assumption is least certain? Weakest link in the plan.

Required for Level 1 (Watch) and above. See modules/risk-assessment-checklist.md for the full template and examples.

Module Reference

• crash-recovery.md: Triage, checkpoint inspection, and

safe resume or rollback after an agent crash.

• context-overflow.md: Procedures for reconstructing

decision context when the window is exhausted.

• merge-conflict-resolution.md: Classification and

resolution strategies for git conflicts, including escalation to human review.

• state-reconciliation.md: Protocol for reconciling

divergent state across task list, git index, and on-disk artifacts.

• risk-assessment-checklist.md: Pre-execution checklist for

Level 1+ tasks.

Integration Pattern

# In your skill's frontmatter
dependencies: [leyline:damage-control]

Invoke a specific module when a failure class is identified:

# Crash detected
Skill(leyline:damage-control) → modules/crash-recovery.md

# Context limit reached
Skill(leyline:damage-control) → modules/context-overflow.md

For orchestrators managing multiple agents, invoke state-reconciliation at session boundaries regardless of whether a failure occurred. This establishes a verified checkpoint before the next work phase begins.

Exit Criteria

• Agent state is unambiguously known (no unknown partial writes)
• Git index is clean or all conflicts are resolved
• Task list reflects actual completion status of all tasks
• All artifacts expected by downstream agents are present and

verified

• If rollback was taken, the rollback is committed and the

reverted scope is documented in the task list

• If escalation to human review was required, the escalation

record exists before the session closes

Context Overflow

When This Module Applies

Use this module when the context window is near or at its limit and the agent can no longer reliably recall earlier decisions, completed steps, or the rationale behind current state. Symptoms:

• Agent references a decision it cannot locate in the current

window

• Agent re-does work already done in the same session
• Earlier tool call results are no longer visible
• The session produces contradictory outputs (second half

disagrees with first half)

Why Context Overflow Is Dangerous

Unlike a crash, context overflow produces no error. The agent continues running but loses access to prior context. It may:

• Re-implement work already completed, creating duplicates
• Make decisions that contradict earlier reasoning
• Omit dependencies established in the now-invisible portion
• Silently discard constraints agreed on with the user

Recovery Protocol

Step 1: Stop and checkpoint

Before taking any further actions, write the current known state to a durable anchor. The task list is the primary anchor: it is outside the context window and survives session boundaries.

For each task currently in_progress:

1. Record the last completed step in the task description 2. List any decisions made that affect downstream tasks 3. List any constraints or agreed deviations from the plan

Step 2: Establish ground truth from durable sources

Context is gone. Recover state from sources that are not inside the window:

Do not trust the agent's recall of anything not confirmed by one of these sources.

Step 3: Summarize for continuation

Before ending the session or handing off to a new agent, write a handoff summary. Place it as a comment in the task description or in a temporary scratch note that the next agent can read at session start:

## Handoff Summary — [timestamp]

### Completed this session
- [task IDs and one-line description of what was done]

### Decisions made (not yet committed anywhere)
- [decision: rationale]

### In-progress state
- Task T042: completed steps 1-3; step 4 (write tests) not yet started
- Files modified but not committed: src/auth/token.py

### Constraints to carry forward
- [any deviations agreed with human, constraints on implementation]

### Recommended next action
- Resume T042 at step 4

Step 4: Hand off or end session cleanly

If handing off to a new agent:

• Commit all completed work before handoff
• Push the handoff summary to the task list
• The new agent reads the handoff summary before starting work

If ending the session:

• Stash or commit any in-progress work
• Do not leave staged changes without a note explaining them

Recovering in the same session (partial overflow)

If context is not fully exhausted but early reasoning is no longer visible:

• Run git log --oneline to anchor what was committed
• Re-read the task list to anchor task state
• Proceed only with actions the current visible context can

fully justify. Do not act on half-remembered prior context

Exit Criteria

• A handoff summary exists recording completed work,

in-progress state, and decisions made

• All completed work is committed or stashed with a descriptive

message

• The task list reflects the current completion status of every

task touched this session

• The next agent (or resumed session) can restore full working

context from the handoff summary plus git history alone, without relying on the overflowed context window

Crash Recovery

When This Module Applies

Use this module when an agent process exited unexpectedly mid-task: the shell died, a timeout fired, or an unhandled exception terminated the agent before it could report status. Signs of a crash:

• A task is marked in_progress but no agent is running
• Files on disk differ from the last known checkpoint
• The git index contains staged changes with no corresponding

commit or stash

Do not use this module for context limit exhaustion (see context-overflow.md) or for git conflicts introduced during a merge (see merge-conflict-resolution.md).

Triage Steps

Step 1: Identify the scope

git status          # staged vs unstaged changes
git diff HEAD       # total delta from last commit
git stash list      # any stashes from prior sessions

Classify what you find:

Step 2: Inspect the task list

Check the task list for the crashed task:

• If in_progress: the task was running at crash time.

Determine its last known completed step before deciding to resume or restart.

• If pending: the task had not yet started. No recovery

needed; assign normally.

• If completed: the task completed before the crash. No

action required.

Step 3: Verify artifact integrity

For each file the task was supposed to produce or modify:

git diff HEAD -- <file>        # what changed since last commit
git show HEAD:<file>           # last committed version

If the current version of the file is internally consistent (parses, tests pass for that file), the partial write is safe to keep and the task can resume from the last completed step.

If the file is corrupt or partially written, recover from git history rather than using destructive restore commands:

git show HEAD:<file> > <file>.recovered   # extract last committed version
git diff HEAD -- <file>                   # review what changed
# Compare <file> with <file>.recovered to salvage valid work
# Then replace <file> with the corrected version
rm <file>.recovered

Never use git checkout -- <file> as it discards work irreversibly. Always inspect the diff first so partial progress can be preserved.

Step 4: Decide: resume or restart

Resume when:

• The crashed task has a clear last completed step
• All files the task touched are internally consistent
• No downstream tasks have already consumed the partial output

Restart when:

• The crashed step is not deterministic (e.g., it called an

external API with side effects)

• Partial output was already read by a downstream agent
• The file integrity check failed for any touched file

Step 5: Clean up and re-enter

If resuming:

git add <files>                # re-stage work that survived
# Update task list: record last completed step in description

If restarting:

# Review what changed before reverting anything
git diff HEAD -- <files>

# Extract committed versions for comparison
for f in <files>; do
  git show HEAD:"$f" > "$f.baseline"
done

# After confirming no salvageable work, restore from history
for f in <files>; do
  git show HEAD:"$f" > "$f"
  rm -f "$f.baseline"
done
git reset HEAD <files>         # unstage
# Update task list: reset task to pending

Never use git checkout -- <files> as it discards all changes without review. Always diff first.

Mark the crashed task with a note in its description recording the crash and the recovery action taken.

Exit Criteria

• Git index is clean (nothing accidentally staged)
• All files touched by the crashed task are internally

consistent or reverted to last-committed state

• The task list accurately reflects whether the task is

pending (restart) or in-progress (resume)

• No partial artifacts remain readable by downstream agents

unless they have been verified as correct

• The recovery action (resume or restart, and why) is noted

on the task record

Merge Conflict Resolution

When This Module Applies

Use this module when a git merge, git rebase, or git cherry-pick produces conflicts (conflict markers appear in files, git status shows UU or AA entries). Also use it when an agent detects that two in-progress tasks have modified the same file and their changes cannot be trivially combined.

Conflict Classification

Before attempting resolution, classify the conflict:

Class A: Formatting or whitespace only

Both sides changed the same lines for non-semantic reasons (whitespace, import sort order, trailing comma). The conflict is safe to resolve by applying the later change.

Resolution: Take the current branch version or apply a formatter and accept all.

Class B: Independent additions to the same region

Both sides added new content to the same location (e.g., two agents added separate functions to the same file, or two migrations added separate fields). The changes do not overlap semantically.

Resolution: Manually interleave both additions, preserving both sets of content. Verify no naming collisions.

Class C: Competing modifications to the same logic

Both sides changed the same lines with different semantics. One or both changes must be partially discarded or combined by someone who understands the intent of each.

Resolution: Escalate to human review. Do not guess at intent. See the Escalation Protocol below.

Class D: Deleted vs. modified

One side deleted a file or function; the other modified it.

Resolution: Escalate to human review. The delete may be intentional (the other branch's modification is stale) or erroneous (the file should not have been deleted).

Resolution Procedure

Step 1: List all conflicted files

git status | grep -E "^(UU|AA|DD|DU|UD|AU|UA)"

Or use the short form:

git diff --name-only --diff-filter=U

Step 2: Classify each conflict

For each conflicted file, identify which class applies. Record the classification before touching the file.

Step 3: Resolve Class A and Class B conflicts

Class A:

# Accept current branch (ours)
git restore --ours <file> && git add <file>

# Or accept incoming (theirs)
git restore --theirs <file> && git add <file>

# Or run formatter and accept
<formatter> <file> && git add <file>

Use git restore instead of git checkout for file-level operations. The restore command is scoped to working tree changes and cannot accidentally switch branches.

Class B: Edit the file manually to include both additions, then:

git add <file>

After resolving, run the test suite for the affected file before marking complete.

Step 4: Escalate Class C and Class D conflicts

Do not attempt to resolve Class C or D conflicts autonomously. Instead:

1. Before aborting, verify no uncommitted work will be lost:

# Check for changes outside the conflict that should be saved
git stash list
git diff --stat

# If there are non-conflict changes worth keeping, stash them
git stash push -m "pre-abort-save: work outside conflict scope"

2. Abort the merge or rebase to restore clean state:

git merge --abort
# or
git rebase --abort

After aborting, verify the branch is in the expected state with git log --oneline -5 and git status. If a stash was created above, verify it appears in git stash list.

3. Record the conflict details in the task list:

## Conflict Escalation — [timestamp]

Files with Class C/D conflicts: [list]
Current branch intent: [what this branch was trying to do]
Incoming branch intent: [what the other branch was trying to do]
Specific conflict: [line numbers, function names, what each side did]
Recommended action: [your best read on the safest path]

4. Mark the affected task as blocked and assign to human.

Step 5: Verify after resolution

After all Class A and Class B conflicts are resolved:

git diff --check          # no leftover conflict markers
<test runner>             # affected tests pass

If tests fail after resolution, do not proceed. The resolution introduced a regression. Revert to the pre-merge state and escalate.

Parallel Agent Conflict Prevention

The best conflict resolution is avoidance. When multiple agents are running:

• Each agent should own disjoint files where possible
• Agents modifying the same module should coordinate via

task dependencies (block/unblock) rather than merging

• Lead agent monitors for file overlap and serializes

conflicting tasks rather than letting them merge

See Skill(leyline:risk-classification) verification gates for the parallel execution safety matrix.

Exit Criteria

• git status shows no files with conflict markers

(UU, AA, DD, DU, UD, AU, UA states)

• git diff --check exits clean
• Tests pass for all files that had conflicts
• Class C and Class D conflicts have escalation records

in the task list before the session closes

• The merge or rebase is either completed and committed, or

aborted cleanly with no partial state on disk

Risk Assessment Checklist

Pre-execution checklist for Level 1+ tasks.

Purpose

The risk assessment checklist forces explicit consideration of what could go wrong before execution begins. It prevents optimistic planning and ensures mitigation strategies are in place. Required for all Level 1 (Watch) and above tasks.

When to Use

Complete this checklist when:

• Task is classified as Level 1 (Watch) or higher
• You're about to modify production-affecting code
• The change touches security, data integrity, or user-facing APIs
• You feel uncertain about the scope of impact

Do NOT complete when:

• Task is Level 0 (Routine) with trivial impact
• The work is documentation-only
• You're just reading files, not modifying

Getting Started

1. Classify the task's Readiness Level first 2. If Level 1+, copy the template below 3. Answer all five questions before starting work 4. Get review if Level 2+ (peer or adversarial) 5. Keep the completed checklist with your task notes 6. Reference it if something goes wrong

Why Five Questions

The five questions cover the essential risk dimensions:

1. Failure modes - What breaks? 2. Detection - How do we know it broke? 3. Rollback - How do we fix it? 4. Dependencies - What else could break it? 5. Assumptions - What are we guessing about?

These five emerged from post-mortem analysis of production incidents. The most common root causes were: not anticipating the failure mode, not having detection, not knowing how to roll back, dependency failures, and invalid assumptions.

Each question has a mitigation purpose:

• Question 1 → Design for failure
• Question 2 → Monitoring and alerting
• Question 3 → Recovery planning
• Question 4 → Dependency awareness
• Question 5 → Humility about unknowns

The Five Questions

Before executing any Level 1+ task, answer these questions:

1. What could fail in production?

Think through specific failure scenarios:

• Data corruption: Could this change corrupt or lose data?
• Service degradation: Could this cause slowdowns or outages?
• Security breach: Could this expose sensitive information?
• Integration breakage: Could this break dependent systems?
• User impact: Could this negatively affect user experience?

Document: List 2-5 specific failure modes relevant to this task.

Example:

Failure modes for "Add rate limiting to API":
1. Rate limiter incorrectly blocks legitimate users
2. Redis unavailability causes all requests to fail
3. Rate limit state inconsistency across instances
4. Performance degradation from rate limit checks

2. How would we detect it quickly?

Define detection mechanisms:

• Monitoring: What metrics would show the problem?
• Alerting: What alerts should fire?
• Logging: What log patterns indicate failure?
• User reports: How would users report issues?
• Health checks: What health check failures would occur?

Document: List specific detection mechanisms.

Example:

Detection mechanisms:
- Alert: "Rate limit rejection rate > 5%"
- Alert: "Redis connection errors > 0"
- Metric: Request latency P99
- Log pattern: "Rate limit exceeded" for known-good users
- Health check: Redis connectivity check

3. What is the fastest safe rollback?

Define the rollback procedure:

• Code rollback: Git revert, deploy previous version
• Config rollback: Restore previous configuration
• Data rollback: Restore from backup, run migration reversal
• Feature flag: Disable the feature
• Dependency rollback: Revert to previous version

Document: Step-by-step rollback procedure with time estimate.

Example:

Rollback procedure:
1. Set feature flag RATE_LIMIT_ENABLED=false (30 seconds)
2. If Redis issues, remove rate limit middleware (2 minutes)
3. Full code rollback: git revert HEAD && deploy (5 minutes)

Fastest safe rollback: Feature flag disable (30 seconds)

4. What dependency could invalidate this plan?

Identify external dependencies and their failure impact:

• External APIs: What if they change or go down?
• Infrastructure: What if servers, databases, caches fail?
• Dependencies: What if libraries have bugs or vulnerabilities?
• Assumptions: What if our assumptions are wrong?
• Timing: What if this takes longer than expected?

Document: List dependencies and their potential issues.

Example:

Dependencies and risks:
- Redis: Single point of failure, need fallback behavior
- API documentation: If outdated, rate limit logic may be wrong
- Load testing tool: If inaccurate, may miss production patterns
- Time: If delays occur, may need to ship without full testing

5. What assumption is least certain?

Identify the weakest link in the plan:

• User behavior: Are we sure users will behave as expected?
• Performance: Are performance assumptions validated?
• Scale: Will this work at production scale?
• Compatibility: Are we sure about version compatibility?
• Documentation: Is the documentation we're relying on accurate?

Document: Identify the assumption most likely to be wrong.

Example:

Least certain assumption:
"We can accurately rate limit based on IP address"

Why uncertain:
- Users behind corporate NATs share IPs
- Mobile users have changing IPs
- Attackers can rotate IPs

Mitigation:
- Consider user-ID based limiting in addition to IP
- Plan to iterate based on production data

Checklist Template

## Risk Assessment Checklist

**Task**: [Task description]
**Readiness Level**: [0/1/2/3]
**Date**: [Date]

### 1. What could fail in production?

- [Failure mode 1]
- [Failure mode 2]
- [Failure mode 3]

### 2. How would we detect it quickly?

- [Detection mechanism 1]
- [Detection mechanism 2]
- [Detection mechanism 3]

### 3. What is the fastest safe rollback?

Steps:
1. [Step 1]
2. [Step 2]
3. [Step 3]

Estimated time: [X minutes]

### 4. What dependency could invalidate this plan?

- [Dependency 1]: [Risk]
- [Dependency 2]: [Risk]
- [Dependency 3]: [Risk]

### 5. What assumption is least certain?

Assumption: [The assumption]
Why uncertain: [Reason]
Mitigation: [Plan B]

---

Reviewed by: [Name]
Date: [Date]

Completed Example

## Risk Assessment Checklist

**Task**: Add JWT authentication to API
**Readiness Level**: 2
**Date**: 2024-03-20

### 1. What could fail in production?

- Token validation fails for valid users (blocks access)
- Private key leaked (security breach)
- Token expiration too short (user frustration)
- Clock skew causes validation failures
- Algorithm confusion attack succeeds

### 2. How would we detect it quickly?

- Alert: "Authentication failure rate > 2%"
- Alert: "Token validation latency > 100ms"
- Log pattern: "Invalid token" for known user IDs
- Metric: Active session count drops unexpectedly
- User reports: Login issues in support tickets

### 3. What is the fastest safe rollback?

Steps:
1. Set AUTH_MODE=session (feature flag, 30 seconds)
2. Remove JWT middleware from routing (1 minute)
3. Full revert: git revert HEAD~3 && deploy (5 minutes)

Estimated time: 30 seconds (feature flag)

### 4. What dependency could invalidate this plan?

- JWT library: Could have vulnerability, pin version
- Key management: If key rotation fails, old tokens invalid
- Time synchronization: NTP issues cause validation failures
- Token size: If too large, may exceed header limits

### 5. What assumption is least certain?

Assumption: "RS256 is the correct algorithm choice"

Why uncertain: We haven't validated key management
infrastructure exists or works at our scale.

Mitigation: Start with HS256 (simpler) for initial rollout,
plan RS256 migration once key management is proven.

---

Reviewed by: Security Team
Date: 2024-03-20

Integration Points

With Readiness Levels

With damage-control

When damage-control is invoked, reference the risk assessment checklist:

1. Was the failure mode anticipated? 2. Did detection mechanisms work? 3. Was rollback procedure followed? 4. Did dependencies fail as expected? 5. Was the uncertain assumption the cause?

With quality-gate

Quality gates verify checklist completion:

if readiness_level >= 1:
    require risk_assessment_checklist in task_notes
    if readiness_level >= 2:
        require checklist_peer_review

Anti-Patterns

Anti-Pattern 1: Copy-Paste Checklist

# BAD: Generic checklist that doesn't address the task
1. What could fail? "Something might break"
2. Detection? "We'll notice"
3. Rollback? "Revert"

# GOOD: Specific to the task
1. What could fail? "Redis connection timeout causes all
   requests to fail with 500"
2. Detection? "Alert on 'Redis timeout' log pattern"
3. Rollback? "Disable rate limiting via feature flag in 30s"

Anti-Pattern 2: Post-Hoc Checklist

# BAD: Writing checklist after implementation
Implement feature → Write checklist → Deploy

# GOOD: Checklist before implementation
Write checklist → Review → Implement → Verify → Deploy

Anti-Pattern 3: Ignored Checklist

# BAD: Checklist documented but not referenced during failure
- Checklist exists
- Failure occurs
- Team scrambles without using checklist

# GOOD: Checklist is the first reference
- Failure occurs
- Team pulls up checklist
- Follows documented rollback procedure

Related References

• ../../risk-classification/modules/readiness-levels.md - Level

definitions

• ../SKILL.md - Error recovery procedures
• ../../egregore/skills/quality-gate/SKILL.md - Verification requirements

State Reconciliation

When This Module Applies

Use this module when the three state sources disagree:

• Task list says task T is completed, but the expected

output file does not exist on disk

• Git index has staged changes for a file the task list

says was not yet touched

• On-disk artifacts exist that do not correspond to any

task in the task list

• An agent reports that a prerequisite artifact is missing,

but the task that should have produced it is marked done

This module is also the recommended first step when multiple failure types overlap: establish a known baseline before applying a more specific recovery protocol.

The Three State Sources

When these three agree, state is consistent. When they disagree, one or more sources is stale or incorrect.

Reconciliation Protocol

Step 1: Snapshot all three sources

Do not make any changes until the snapshot is complete.

# Task list snapshot
# (read task list: record all task IDs, statuses, owners)

# Git state snapshot
git log --oneline -20
git status
git diff HEAD

# Disk artifact check
# For each expected output, verify existence and basic integrity

Step 2: Build the disagreement map

For each task marked completed in the task list, verify that all expected outputs exist and are committed:

Any row with a "NO" is a disagreement requiring reconciliation.

Step 3: Resolve each disagreement

Task marked done, output on disk but not committed

The task completed but the commit was missed:

git add <file>
git commit -m "fix: commit output for T<id> missed in prior session"

Task marked done, output not on disk

Two possibilities:

1. The file was committed under a different name or path. Check git log --all --full-history -- <expected_path>.

2. The task did not actually complete despite the status. Reset the task to pending and note the discrepancy in the task description.

File on disk not covered by any task

Determine origin:

git log --all --follow -- <file>
git blame <file>

If the file was produced by a known task that is now missing from the task list, add a task record for it retroactively and mark it completed.

If the origin is unknown, treat the file as an orphan. Always use named stashes with descriptive messages so the work can be located later:

git stash push -m "orphan: <file> from unknown task [$(date +%F)]" -- <file>
git stash list   # verify the stash was created and note its index

Record the stash index and message in the task list so it is not lost. Then decide separately whether to adopt or discard.

Staged changes with no corresponding in-progress task

git diff --cached       # inspect what is staged
git stash push -m "unowned-staged: $(date +%F)"   # named stash
git stash list          # verify creation

Record the stash index in the task list. Then reconcile: find the task this work belongs to and reassign the stash to it, or discard only after confirming the work is superseded.

Stash safety rules:

• Always use git stash push -m "<description>" (never

bare git stash which creates unnamed entries)

• Immediately verify with git stash list after pushing
• Record the stash ref (e.g., stash@{0}) in the task

description so it can be found across sessions

• Apply with git stash pop stash@{N} using the explicit

index, not bare git stash pop which always takes the most recent entry

Step 4: Re-verify after reconciliation

After resolving all disagreements:

• Re-read the task list and rebuild the disagreement map
• The map should now show all "yes" in both columns
• Run git status (index should be clean)
• Run the test suite (all tests should pass)

If any new disagreements appear during re-verification, apply the same protocol recursively until the map is clean.

Step 5: Document the reconciliation

Add a note to each affected task describing the discrepancy found and the action taken. This creates an audit trail if the same disagreement recurs.

Exit Criteria

• Every task marked completed has all expected outputs

present on disk and committed to git

• No staged changes exist without a corresponding

in_progress task owning them

• No on-disk artifacts exist that are unaccounted for by the

task list

• git status shows a clean index (or only staged changes

belonging to a known in-progress task)

• The disagreement map from Step 2, when rebuilt, shows no

remaining "NO" entries

• Each reconciliation action is recorded in the relevant

task description