git:20260915.cce0383 to git:20260916.2732180

- Use this skill to keep long tasks checkpointed, resumable, drift-aware, and evidence-gated.

-

- This is a protocol skill. It does not execute plans, dispatch subagents, run tests, or grant completion authority.

- Current owner:

-

- - Method Pack protocol discipline

-

- Not owned here:

-

- - plan execution

- - subagent dispatch

- - host daemon / watchdog / automatic retry

- - authoritative `GateDecision`

- - evidence sufficiency final judgment

- - completion authority

- Use this skill when any of these are true:

- - the task has multiple phases or more than one meaningful work slice

- - the task may be interrupted, compacted, resumed, or handed off

- - the task uses subagents

- - the user explicitly asks for long-task continuity, resume safety, or avoiding drift

- - the task changes architecture, contracts, shared workflows, or verification gates

- For short direct answers or one-command checks, do not force this protocol.

- durable records by themselves. Use `work/` for medium+ complexity or when work

- actually crosses sessions, needs handoff, or requires resumable state;

- otherwise keep an inline checkpoint.

- Maintain artifacts under `docs/aegis/work/YYYY-MM-DD-<slug>/`:

-

- | Artifact | File | When |

- |----------|------|------|

- | TaskIntentDraft | `10-intent.md` and optional `task-intent-draft.json` | Start protocol |

- | BaselineReadSetHint | `10-intent.md` (inline) | Start protocol |

- | BaselineUsageDraft | `10-intent.md` (inline) and optional `baseline-usage-draft.json` | Start protocol and when baseline usage changes |

- | ImpactStatementDraft | `10-intent.md` (inline) | Start protocol |

- | TodoCheckpointDraft | `20-checkpoint.md` and optional `todo-checkpoint-draft.json` | Each checkpoint |

- | ResumeStateHint | `20-checkpoint.md` (inline) | Each pause/handoff |

- | DriftCheckDraft | `20-checkpoint.md` (inline) and optional `drift-check-draft.json` | Per-slice protocol |

- | EvidenceBundleDraft | `90-evidence.md` and optional `evidence-bundle-draft.json` | Per-slice protocol |

- | Reflection | `99-reflection.md` | Completion candidate |

- The table applies only when the durable-record rule above selects `work/`.

- `Execution Readiness View` may be included inline in `10-intent.md` or the

- active checkpoint when the workstream is medium/high, subagent-driven,

- handoff-prone, long-running, architecture / contract sensitive, or

- compatibility / retirement sensitive. It is a human-readable rendering of

- existing drafts and any parent plan, not a new JSON artifact or completion

- authority.

- - Use this lane when an existing parent plan/spec owns the current micro-slice

- and it executes or refines one bounded parent task, or through the no-parent

- branch for a direct bounded mechanical request with no new durable or unclear

- verification boundary.

- - Record a compact Slice Card instead of creating another durable plan/spec:

-

- ```text

- Slice Card:

- - Goal:

- - Parent plan/spec: <ref> | none — direct bounded request

- - Files:

- - Boundary:

- - Verification:

- - Stop:

- ```

-

- - Slice Card `Goal` anchors slice-level completeness only, never whole-task

- completion.

- - Final completion still requires `verification-before-completion` Goal Closure

- against the parent when present or the direct bounded request otherwise, plus

- any active goal frame, through the unified Aegis impact/safety receipt unless

- audit detail is requested.

-

- - Do not create a plan/spec merely to supply a parent for an otherwise bounded

- slice.

- - Parent-owned slices reuse existing checkpoint/evidence/drift records.

- No-parent low-complexity slices use an inline checkpoint; durable records

- follow the rule above.

- - Escalate out of this lane only when a new owner, contract, schema, public API,

- architecture boundary, migration, persistence, security/permission,

- distribution/release surface, unclear verification boundary, or mismatch

- with the parent scope or acceptance appears.

- preferred ADR Auto Backfill source. Preserve ADR signals, source refs,

- alternatives, compatibility boundaries, drift checks, retirement notes, and

- baseline-sync questions in the work record instead of relying on memory at

- completion time.

-

- These are draft / hint / projection inputs. They are not authoritative runtime records.

-

- ## Workspace Helper Protocol

-

- When this rule selects `work/` and configured or installed Aegis workspace

- support is available, use it for target-project lifecycle records:

-

- 1. Initialize before writing work records:

-

- ```bash

- python <aegis-workspace-helper> init --root <target-project-root>

- ```

-

- 2. For a new durable task process trail, prefer helper-backed lifecycle

- creation over hand-created files:

-

- ```bash

- python <aegis-workspace-helper> new-work --root <target-project-root> --date YYYY-MM-DD --slug <slug> --title "<title>" --requested-outcome "<outcome>" --scope "<scope>" --change-kind <kind>

- ```

-

- 3. After each slice, update checkpoint, evidence, and drift through the helper:

-

- ```bash

- python <aegis-workspace-helper> add-checkpoint --root <target-project-root> --work YYYY-MM-DD-<slug> ...

- python <aegis-workspace-helper> add-baseline-usage --root <target-project-root> --work YYYY-MM-DD-<slug> ...

- python <aegis-workspace-helper> add-attempt --root <target-project-root> --work YYYY-MM-DD-<slug> --slice-id <slice-id> --attempt-id <attempt-id> --attempt-status failed ...

- python <aegis-workspace-helper> add-evidence --root <target-project-root> --work YYYY-MM-DD-<slug> --slice-id <slice-id> --evidence-status <terminal-status> ...

- python <aegis-workspace-helper> add-drift-check --root <target-project-root> --work YYYY-MM-DD-<slug> ...

- ```

-

- Use `add-attempt` for a failed verification retry inside the current slice.

- Use `add-evidence` only after the slice reaches `evidence-finalized`,

- `blocked`, or `abandoned`. Do not let a failed attempt create another slice

- or a formal evidence sidecar.

-

- 4. Before pause, handoff, or completion candidate, assemble a structural proof

- bundle and check the workspace:

-

- ```bash

- python <aegis-workspace-helper> bundle --root <target-project-root> --work YYYY-MM-DD-<slug>

- python <aegis-workspace-helper> check --root <target-project-root>

- ```

-

- These helper checks validate workspace structure, index coverage, and JSON

- sidecar shape only. They do not determine evidence sufficiency, do not produce

- authoritative `GateDecision`, and do not grant completion authority.

- Before long-task execution:

- 1. State the requested outcome, scope, non-goals, and risk hints.

- 2. If goal framing exists, restate goal, success evidence, stop condition, and

- non-goals. Stop condition must allow done, blocked, needs-verification, and

- scope-exceeded outcomes.

- 3. Identify baseline refs that must be read before changing files.

- 4. Record baseline usage state:

- - required baseline refs

- - optionally delivered context refs when the host can project them

- - acknowledged before plan refs

- - cited in plan refs

- - missing refs

- 5. Create or update the todo map.

- 6. If the parent plan or workstream needs an execution handoff, render or link

- an `Execution Readiness View`:

- - intent lock

- - scope fence

- - baseline lock

- - owner / contract constraints

- - compatibility boundary

- - retirement boundary

- - task batches

- - test obligations

- - review gates

- - drift / rewind rules

- - evidence required before completion

- - advisory boundary

- 7. Create the first checkpoint:

- - current todo

- - active slice

- - completed todos

- - evidence refs

- - blocked-on items

- - next step

- 8. If baseline refs are missing, pause in `needs-baseline-readback`.

- 9. If this rule selects `work/` and the helper is available, use

- `aegis-workspace.py new-work` to create/index the first `docs/aegis/work/`

- files and run `check --root <target-project-root>` before continuing.

- A failed verification is another attempt in the current slice, not a new slice.

-

- - Reuse the current `activeSlice` as the `--slice-id`.

- - Record each retry with `add-attempt`, not `add-evidence`.

- - Do not append failed attempts to `90-evidence.md`.

- - Do not create a normal commit for attempt telemetry.

- - A process-only diff under `docs/aegis/` does not restart completed business-code verification.

- - When `add-attempt` reports `process-artifact-pressure`, stop auto-retry and route to `systematic-debugging` or `verification-before-completion`.

-

- Only terminal evidence (`evidence-finalized`, `blocked`, or `abandoned`) is

- eligible for `bundle`.

- Before each work slice, restate:

-

- 1. current goal

- 2. current todo

- 3. intended edits

- 4. explicit non-edits

- 5. verification command or manual check

- 6. `Execution Readiness View` alignment when one exists

-

- For bounded parent-plan or no-parent slices inside the lane guards, state the

- Planless Slice Card instead of opening a new planning/specification artifact.

-

- After each work slice, update:

- 1. completed todos

- 2. evidence refs

- 3. baseline usage if newly required refs were acknowledged, cited, or found missing

- 4. blockers

- 5. next step

- 6. drift check

- 7. when an active helper-backed work record exists, update JSON sidecars through

- `aegis-workspace.py add-checkpoint`,

- `aegis-workspace.py add-baseline-usage`, `aegis-workspace.py add-evidence`, and `aegis-workspace.py add-drift-check`

- when available

- 8. failed verification: `add-attempt` with the current `--slice-id`; do not add

- terminal evidence or create a process-only commit

- mitigation fired, a locally green result does not clear that direction. Reuse

- checkpoint prose and evidence refs to retain `PatchShape`, `CanonicalOwner`,

- `UpwardDrillSignal`, decision, latest outcome, and one bounded evidence ref;

- do not copy raw logs or full diffs.

-

- If no fresh evidence exists, the state is `needs-verification` or `partial`.

- When resuming:

- 1. Read latest checkpoint.

- 2. Read latest resume hint if present.

- 3. Re-read original task intent.

- 4. Re-read required baseline refs.

- 5. Passively re-read relevant active `CONTEXT.md` language for non-trivial work.

- 6. Re-read the `Execution Readiness View` if present.

- 7. Compare current worktree state with checkpoint claims.

- 8. Compare the slice with the view's intent, scope, baseline, compatibility,

- retirement, test, and review locks.

- 9. If any disagreement exists among the checkpoint, baseline, context, view, and

- worktree, compose `establishing-project-context` for a semantic conflict; for

- any other disagreement, pause or return to planning.

- 10. Before an unplanned repair, read retained invariant, owner seam, patch shape,

- and causal topology and route comparison to `systematic-debugging`; a new

- carrier name alone does not prove a new direction.

- Never resume from memory alone.

- Answer these after each slice:

-

- - Does the current work still serve the original task intent?

- - Does the current work still serve the goal and stop condition?

- - Did the slice stay inside the compatibility boundary?

- - Did any new owner, fallback, adapter, or branch appear?

- - Is the retirement track still explicit?

- - Did the evidence bundle grow enough to support the next claim?

- - If an `Execution Readiness View` exists, does the active slice still match

- its intent lock, scope fence, baseline lock, compatibility boundary,

- retirement boundary, test obligations, and review gates?

-

- Allowed decisions:

-

- - `continue`

- - `pause-for-user`

- - `needs-baseline-readback`

- - `needs-verification`

- - `blocked`

-

- Forbidden decisions:

- - `gate-passed`

- - `completion-granted`

- - `authoritatively-safe`

- Before saying work is complete:

- 1. Use aegis:verification-before-completion.

- 2. Confirm every todo has a status.

- 3. Confirm blockers are resolved or externalized.

- 4. Confirm evidence refs cover the acceptance criteria.

- 5. Confirm drift check has no blocking state.

- 6. Run `python <aegis-workspace-helper> bundle --root <target-project-root>

- --work YYYY-MM-DD-<slug>` if the helper is available and a work record

- exists.

- 7. Run `python <aegis-workspace-helper> check --root <target-project-root>`

- if the helper is available and the task wrote `docs/aegis/` records.

- 8. Treat the generated `GateInputPack` as future-runtime input only.

- 9. If durable architecture decisions were in scope, pass the work record,

- proof bundle, drift checks, evidence refs, and ADR signals into

- aegis:verification-before-completion for ADR Backfill Check.

- Method Pack output is verified evidence and advisory judgment only. It is not authoritative completion.

- Use this shape for long-task updates:

-

- - `Aegis Visibility`: why checkpoint, resume, drift, handoff, or parent-plan

- discipline is shaping the next step

- - `TodoCheckpointDraft`: current todo, completed todos, active slice, next step

- - `BaselineUsageDraft`: required refs, acknowledged refs, cited refs, missing refs, decision

- - `Execution Readiness View`: present | absent | refreshed | stale, and the

- alignment signal when present

- - `Evidence`: commands, files, logs, or manual checks

- - `Process Artifact Pressure`: attempted slices, retry count, terminal state,

- and whether convergence-stop is active

- - `DriftCheckDraft`: scope, compatibility, retirement, decision

- - `Risk / Unknown`: unresolved blockers or missing evidence

- - `Next`: the next smallest safe action