Assistant/docs/COLD_START_AND_DURABLE_CHECKPOINT.md

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.