long-task-continuation

# Long Task Continuation

## Overview

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.

## Authority Boundary

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

## When To Use

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.

Multi-step, todo-driven, or subagent-using tasks do not force durable records by themselves; keep an inline checkpoint unless the task also crosses sessions, needs handoff, or requires resumable state.

## Required Artifacts

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 |

For medium+ complexity tasks only. Low-complexity tasks skip 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 the parent plan, not a new JSON artifact type and not
completion authority.

Planless Slice Lane:

- Use this lane when a parent plan or parent spec already owns the long-task
  workstream and the current micro-slice only executes or refines one bounded
  parent task.
- Record a compact Slice Card instead of creating another durable plan/spec:

  ```text
  Slice Card:
  - Goal:
  - Parent plan/spec:
  - Files:
  - Boundary:
  - Verification:
  - Stop:
  ```

- Slice Card `Goal` anchors slice-level completeness only.
- It does not by itself grant whole-task completion.
- Final completion still requires `verification-before-completion` Goal Closure
  against the parent plan/spec and any active goal frame, rendered through the
  unified Aegis impact/safety receipt unless audit detail is requested.

- Do not create new plan/spec files for micro-slices that stay inside the
  parent plan, existing compatibility boundary, and known verification path.
- Update the existing checkpoint, evidence, and drift records when persistent
  state is needed.
- Escalate out of this lane only when a new owner, contract, schema, public API,
  architecture boundary, migration, persistence, security/permission,
  distribution/release surface, or unclear verification boundary appears.

When durable architecture decisions are in scope, these work records are the
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 configured Aegis workspace support or installed Aegis workspace support is
available, use it for the target project workspace and lifecycle records:

1. Initialize before writing work records:

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

2. For a new medium+ 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-evidence --root <target-project-root> --work YYYY-MM-DD-<slug> ...
   python <aegis-workspace-helper> add-drift-check --root <target-project-root> --work YYYY-MM-DD-<slug> ...
   ```

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.

## Start Protocol

Before long-task execution:

1. State the requested outcome, scope, non-goal