Task Continuity And Context Recovery

Long conversations are useful working memory, but poor project memory. They accumulate superseded plans, failed experiments, logs, unrelated outcomes, and tool state that a fresh agent cannot safely distinguish from current truth. STAGE therefore treats a conversation as a disposable execution surface around durable project state, not as the project archive.

This guide defines how a solo director can move among Codex tasks, recover unfinished work, and coordinate agents without losing decisions or feeding entire transcripts back into context.

Decision

Use three complementary mechanisms:

1. a Project Context Spine for durable project knowledge;
2. a Task Handoff for unfinished work crossing a task boundary; and
3. an Orientation Check to prove that a fresh task recovered the right state before it mutates anything.

The repository and its current revision remain the implementation record. A handoff is a revision-bound bridge, not a second source of truth. Conversation history and model memory may help recall, but neither is authoritative.

State Model

Layer	Owns	Expected lifetime
Working tree and Git revision	Exact implementation, assets, generated outputs, branch, and dirty state	Project lifetime
Project Context Spine	Durable operating rules, direction, vocabulary, architecture map, ownership, canonical documentation, and current work coordinates	Project lifetime, maintained in place
Active work item	One coherent outcome, protected state, accepted decisions, checks, and disposition	Until checkpointed, rejected, or deferred
Task Handoff	Minimum revision-bound state needed to resume unfinished work in another task	One task transition
Conversation and model memory	Exploration, local reasoning, transient logs, and interaction history	Disposable

The layers do not compete. They answer different questions:

• source state answers what exists now;
• the Context Spine answers how this project is governed and navigated;
• the work item answers what outcome is active;
• the handoff answers where unfinished execution stopped; and
• the conversation answers how the current task got here.

Authority When Sources Conflict

Use this order while preserving the distinction between intent and actual state:

1. the newest explicit human direction governs the intended outcome and authority boundary;
2. the live working tree and Git coordinates describe actual project state;
3. canonical project documents at that revision govern durable rules, terminology, ownership, and architecture;
4. the active work item records the bounded accepted outcome;
5. a Task Handoff provides provisional resume coordinates; and
6. older conversation text and model memory provide historical clues only.

A new human direction can require changing the repository, but does not make that change already true. A dirty working tree can contain important work even when a handoff omits it. When a handoff conflicts with source state, stop, report the mismatch, inspect the diff, and recover from the repository plus the newest human decision.

Project Context Spine

The Context Spine is a short, versioned reading path, not an encyclopedia:

1. AGENTS.md contains mandatory operating rules and links to authority.
2. STAGE.md or an equivalent project map gives concise direction, architecture, ownership, operations, verification, and known risks when the project has earned such a map.
3. A documentation index points to canonical detail instead of duplicating it.
4. Canonical documents own vocabulary, decisions, architecture, content, lifecycle, testing, and tool-specific operations.
5. The active work item records the one current coherent outcome when it needs to survive beyond conversation.

Keep AGENTS.md short because agent configuration is loaded into task context. Use it as a table of contents and safety boundary. Put explanations in versioned documents and link to them. Do not paste changelogs, architecture handbooks, or old task summaries into AGENTS.md.

An active work item is conditional state, not a mandatory project heartbeat. When the working tree is clean and the previous outcome is checkpointed, no active outcome is a correct orientation result; the next action is to wait for a new human direction. When intentional unfinished work exists in a dirty tree or active branch and must survive a task boundary, record its outcome, ownership, checks, and next action in the project's existing work-item carrier or a Task Handoff. Do not create a fictional active item after completion only to satisfy an orientation check.

The Context Spine may be small. A bounded game can use only AGENTS.md, a short architecture note, and its issue tracker. A systems-heavy game with custom tooling may justify a proportional project map. STAGE artifacts remain optional; the durable source chain is the requirement, not the filenames.

Codex Project Topology

Use one Codex local project per repository. Set its primary folder to that repository's Git root so root AGENTS.md discovery, source control, and local commands all begin in the correct project.

Examples:

The Circussy One project -> /path/to/the-circussy-one
STAGE project             -> /path/to/stage-game-engineering
Future game project       -> /path/to/that-game

Do not create one permanent mega-project containing every game, STAGE, and scratch repository. Attach a secondary repository only for a genuinely cross-repository outcome, and name which repository is primary and which may be mutated. Installed skills provide reusable method guidance without making the skill repository part of every game's working context.

Task Boundaries

Continue the same task when the outcome is still coherent:

• diagnosing and fixing the same defect;
• responding to human feedback on the current implementation;
• completing missing verification for the same change;
• tuning the same accepted hypothesis from a known checkpoint; or
• resolving one integration failure caused by that change.

Start a new task when:

• the previous outcome is checkpointed, rejected, or deliberately deferred;
• the repository or primary project changes;
• the requested outcome changes domain;
• the task has accumulated several unrelated decisions or logs;
• independent work should proceed in parallel; or
• a fresh context would be cheaper and safer than continued compaction.

“What next?” after a completed checkpoint normally begins a new task. Task titles should name the outcome, such as Fix Stage Door fallback, rather than the whole project.

There is no universal message or token threshold. Context pressure is already material when the agent repeatedly recovers stale plans, the task opens slowly, mobile clients cannot load it, unrelated history crowds out current evidence, or compaction is doing most of the continuity work.

Starting A Fresh Task

Before mutation, the fresh task should:

1. confirm the repository root, branch, revision, remotes, and dirty paths;
2. read the discovered AGENTS.md chain;
3. follow the Project Context Spine only as far as the requested outcome needs;
4. identify the current coherent outcome and protected state;
5. reconcile any Task Handoff with the live repository;
6. state the exact next action and relevant verification gates; and
7. surface unresolved authority or product decisions instead of guessing.

For a routine bounded request, these steps may be brief and implicit. Make the orientation report explicit after a long-task migration, repository switch, stale handoff, risky operation, or known dirty state.

If no active outcome exists, say so. A fresh task may safely conclude that no mutation is authorized yet. Dirty unfinished work with no durable outcome, ownership, or next action is instead a continuity gap: preserve it, report it, and return to the task or human that can checkpoint or describe it.

Task Handoffs

Create a Task Handoff only when coherent work is unfinished and another task must resume it. The /handoff skill is appropriate for this bridge because it compacts active execution state while linking back to durable sources.

A handoff should contain:

• intended outcome and explicit non-goals;
• target repository and primary folder;
• branch, base revision, current revision, and dirty paths;
• files intentionally changed and protected state;
• current work-item state and completed plan steps;
• locked human decisions;
• observations, failed routes, and unresolved hypotheses;
• exact check outcomes and remaining human or engine checks;
• exact next action;
• canonical source links; and
• a staleness rule.

Do not include:

• a transcript dump;
• raw logs already saved elsewhere;
• copied architecture or glossary prose;
• speculative adjacent work;
• hidden reasoning; or
• claims that are not supported by current source or evidence.

Prefer an operating-system temporary location for an ephemeral handoff. Keep a handoff in the repository only when a named human, audit, tracker, or regulated process needs durable retention. Delete or ignore the temporary handoff after the receiving task has reconciled it.

Every handoff is stale when its repository, branch, revision, or dirty-state description no longer matches. Staleness triggers reorientation; it does not authorize resetting the newer state.

Use templates/task-handoff.md when a manual or durable handoff is needed.

Multi-Agent Work

Do not share a giant transcript as common context. Give each agent:

• one outcome;
• the correct repository root and revision;
• the relevant Context Spine entry points;
• explicit read/write scope;
• protected and exclusive paths;
• evidence expectations; and
• the integration or reporting boundary.

Read-only agents may inspect disjoint questions in parallel. Mutating agents follow the bounded concurrency and path-ownership rules in Change, Concurrency, And Release Workflow. The lead task owns synthesis, conflict resolution, and final mutation unless a different integrator is explicit.

Agent summaries remain orientation. The receiving agent verifies them against source, diffs, engine state, and evidence.

Fresh-Task Orientation Check

Run this check before retiring a long task:

1. open a new task in the correct repository project;
2. ask it to inspect only, not mutate;
3. have it answer the questions in templates/fresh-task-orientation-check.md;
4. compare answers with the repository and the director's known decisions;
5. correct the Context Spine rather than teaching the answer only in chat; and
6. repeat once from another fresh task when a correction was material.

Classify the result:

Result	Meaning
sufficient	Critical state, authority, next action, and gates are correct; uncertainty is surfaced
needs-correction	A non-dangerous fact is missing or hard to find; update the Context Spine
unsafe	Wrong repository or branch, ignored dirty state, overridden human decision, stale handoff trusted over source, or mutation before orientation

Do not average answers into a context score. Record the exact missing or contradicted fact and repair its canonical owner.

Absence of an active work item is not itself a needs-correction result. Classify it according to source state: clean and idle can be sufficient; intentional unfinished work whose outcome cannot be recovered is needs-correction; mutation that ignores or overwrites that work is unsafe.

Test three modes:

1. No-handoff recovery: project sources alone recover durable knowledge.
2. Active-task recovery: a handoff recovers unfinished execution without duplicating project lore.
3. Stale-handoff recovery: the agent notices changed source coordinates and prefers current state plus the newest human decision.

Migrating An Oversized Task

1. Stop adding unrelated work to the old task.
2. Inspect and checkpoint coherent repository state where authorized.
3. Put durable decisions into their canonical project documents or work item.
4. Generate a Task Handoff only for the unfinished outcome.
5. Open a new Codex project or task rooted at the correct Git repository.
6. Run the Orientation Check without allowing edits.
7. Continue the unfinished outcome only after the check is sufficient.
8. Archive the old task after the new task demonstrates safe continuity.

Preserve the old task as historical evidence if useful, but do not use it as the daily operating surface or ask a new agent to reread it.

Why Not A Separate Memory Database

Repository-native Markdown, source control, project assets, and the tracker are already inspectable by humans and agents, versioned with the implementation, and reviewable through normal diffs. Add search indexes, retrieval systems, or special continuity services only when observed recurring retrieval failures remain after the Context Spine and handoff protocol are in place.

Model memory can retain preferences and recurring facts, but it is generated state with a separate lifecycle. Mandatory rules and project-specific decisions remain in checked-in sources.

Research Basis

• OpenAI's Projects and chats recommends projects for continuing work and separate chats for distinct outcomes.
• OpenAI's AGENTS.md guide describes root-to-working-directory discovery and the bounded instruction budget.
• OpenAI's Long-running work guide separates continuing one coherent outcome from parallel or independent tasks.
• OpenAI's Harness engineering describes a short agent guide as a map into a versioned repository system of record.
• OpenAI's Codex agent loop explains automatic context compaction; compaction preserves task operation but is not a replacement for canonical project state.
• Anthropic's context engineering guide describes finite attention, context degradation, structured external notes, and isolated subagent contexts.
• Lost in the Middle and Chroma's Context Rot provide evidence that more context does not guarantee reliable retrieval or use.

These sources support the risks and component practices. The complete STAGE continuity protocol is a practitioner design, not a proven universal optimum.