# Cold start reconstruction and durable checkpoint guidance

## 1) Fresh session reconstruction (no chat dependency)

Any new Codex session must reconstruct active state using repository artifacts only:

1. `git status`, `git rev-parse --abbrev-ref HEAD`, `git log -1 --oneline`
2. `AGENTS.md`
3. `architecture/ARCHITECTURE_CONSTITUTION.md`
4. `architecture/CORE_SEMANTIC_MODEL_V1.md`
5. `architecture/architecture-registry.yaml`
6. `architecture/architecture-registry.json`
7. `development/CODEX_DEVELOPMENT_CONTRACT.md`
8. `dev/ACTIVE_TASK.json`
9. active task packet referenced by `dev/ACTIVE_TASK.json`
10. relevant accepted ADRs
11. `docs/PROJECT_STATUS.md`
12. relevant evidence artifacts in `docs/evidence/**` and tests configured for current task

The objective is to restore:

- what Domovoy is and current implementation state;
- active DEV/task and scope;
- architecture boundaries and governance stack;
- last verified commit and next action.

No external chat context is required.

## 2) Canonical durable checkpoint fields

Current work checkpoints are represented through:

- `docs/PROJECT_STATUS.md` checkpoint blocks per DEV-id.
- `dev/ACTIVE_TASK.json` for active packet identity.
- active task packet fields and scope.

Required conceptual fields:

- `STATUS`
- `CURRENT_PHASE`
- `COMPLETED`
- `IN_PROGRESS`
- `NOT_STARTED`
- `BLOCKERS`
- `IMPORTANT_FINDINGS`
- `EVIDENCE_OBTAINED`
- `LAST_VERIFIED_COMMIT`
- `NEXT_ACTION`

No single file must hold all facts; continuity is reconstructed from the three authoritative artifacts above plus repository evidence.

## 3) Practical continuity checks for a fresh session

The session is recoverable if it can, from the repository alone, answer:

- Which task is active and where to continue?
- What phase is current (`NOT_STARTED` / `IN_PROGRESS` / `COMPLETED`)?
- What blockers and assumptions are known?
- What evidence was last verified and where is it stored?
- What exact next action is safe to perform next?

Any ambiguous active state should be treated as blocked and converted into an explicit checkpoint update rather than implicit inference.

## 4) Deployment continuity rule

- Bootstrap config should remain minimal and task-locating.
- Live canonical configuration belongs to canonical ownership and project artifacts, not ambient shell session state.
- Missing runtime assumptions must fail early during startup checks, not defer silently to manual behavior.

## 5) Evidence expectations for this task family (DEV-000074)

- `docs/PROJECT_STATUS.md` checkpoint updated for DEV-000074.
- `AGENTS.md` contains the startup and checkpoint governance.
- `dev/ACTIVE_TASK.json` points to the active DEV-000074 packet.
- Evidence artifact file or command output captured for cold-start reconstruction validation.