Skip to content

Task Context And Handoff Standard

  • Status: CANONICAL / BINDING
  • Scope: Task preparation, in-progress records, verification, session resumption and handoff for Task-backed New-System work. DIRECT work uses the DIRECT path in new-system/AGENTS.md.
  • 2026-09-20 revision: the Task manifest, the EXECUTION ledger, preflight packets and Context Gate are retired. The full history of the retired machinery stays in git. The rules below take their place.

1. One Task Is One Task Document Plus Atomic Git History

  • Every bounded unit of work has a Task document at docs/tasks/<ID>.md. The Task document owns direction (request, goal), exact scope (paths, effects), acceptance criteria, execution evidence and remaining unknowns.
  • Git owns the file-to-Task mapping. A Task is delivered as one atomic commit, or a short run of commits sharing the same subject prefix. The commit subject names the owning Task: <NS3-006>: ..., <TASK-xxx>: ..., or DIRECT: ... for unplanned direct work.
  • Do not mix several Tasks into one commit. "Which Task changed this file" is answered by git log -- <path> together with the subject prefix.
  • Do not build parallel intent/spec/plan/proof trees or a separate progress ledger.

2. Plan Execute Verify

  • Plan: record the request, goal and non-goals, the affected paths and effects, acceptance criteria, the relevant boundaries and failure cases, the implementation order, and how each step is verified, all inside the same Task. Separate the approval source of important scope and architecture decisions from open questions. Do not ask again for a decision that is already approved; hold back only the implementation that depends on an open question.
  • Execute: change code, tests and documents within the approved scope together. Update that plan only when an important decision changes on new evidence. Do not create a new Task or a new approval for a simple phase transition.
  • Verify: record the actual check result per acceptance criterion plus a diff review. Separate self-review from independent review, and record the UX or business acceptance that needs a human apart from automated checks. Waiting for approval is not completion.
  • Use the required items of the existing handoff template inside the Task. Do not duplicate the Task into a separate plan or completion folder. The same boundary applies without client Plan mode.

3. Verification And Handoff

  • Run the smallest check that proves the changed surface, plus the Task's acceptance checks.
  • Reuse the Plan's acceptance wording or its existing IDs verbatim in Verification, so that requirement → changed path → check result stays linked. If a criterion is reduced or replaced by a different check, record the approval basis.
  • For each result record the command, the time it actually ran, the source identifier, the environment, the location of the raw evidence and its limits. The source identifier is a commit revision; for an uncommitted check also record the base revision and either the checked diff or the file hash. Do not dress up a future commit SHA as execution evidence.
  • Classify a result as PASS / FAIL / BLOCKED / NOT_RUN / NOT_APPLICABLE. An unexecuted item keeps its reason, its next execution step and its owner, and is kept separate from completed checks.
  • Distinguish static document or configuration checks, mock runs, real MCP connections, Playwright regression runs and Ego Lite screen verification. Browser evidence records the real backend, the connection method and the target environment. Registration in configuration or a mock run alone does not pass a real tool or screen check.
  • Before handoff, confirm that the evidence file or raw output actually exists and supports the acceptance criterion, source and environment. If the relevant source, configuration or environment changes, re-verify only that evidence. Do not copy another Task's or an earlier run's result to close a criterion.
  • Completion judgement, continuing after a failure, updating the single state source, and reporting results to the user follow Agent Workflow.
  • A state update is an acceptance criterion of the handoff or review work. Update only the single source named by the Task contract and link the other documents to it (the top of the Task when unspecified). For NS1-009, T001–T106, the single upper state table is the source and status values are not copied into sub-Tasks. Re-read the source state, the detailed evidence and the remaining work before closing. Dated judgements from the past are preserved as history.
  • Task state is BACKLOG → IN_PROGRESS → TEST_READY → TESTING → REVIEW_READY → REVIEWING → DONE → COMMITED, and waiting for a fix is NEED_REPAIR. TESTING is owner testing, REVIEWING is Astra's final verification. Do not use a space in the state label; detailed transitions and exceptions follow Agent Workflow.
  • Aggregate verification (verify:foundation, verify) is used only for shared-owner integration, architecture acceptance, and release.
  • When resuming a session, restore the Task document and the git state (dirty paths, base revision) first. Do not ask the user about a recorded fact.

4. Concurrent Work

  • Coordinate through the exact file boundaries in the Task document and the dirty paths in git status. Serialise edits to the same file and to shared mutable state (DB fixtures, browsers, services).
  • Git staging, commit and push each have one integration owner. Preserve other writers' dirty paths and do not deliver them as if they were your own Task.

5. Authority

Authority and restriction decisions follow Project Operations. There is no mechanical enforcement (manifest schema, gate, ledger). Review owns authority and restriction judgement: do not invent a restriction the user did not ask for (RESTRICTION DELTA = NONE by default), and where a restriction is necessary, record its basis and approval source in the Task document.

Source: new-system/docs/knowledge/TASK_CONTEXT_AND_HANDOFF_STANDARD.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.