# DZ Project Continuity

DZ workflow guidance version: `2026-09-03.1`.

This repository is a DZ project. Before product, application, or agent work, load the installed `dz` Skill. In Codex, if the selector did not attach it, read `$HOME/.agents/skills/dz/SKILL.md` directly. On another host, use its installed DZ entry or persistent project instruction. If DZ cannot be loaded, say so instead of silently using an ordinary workflow.

At the start of every new task or session, and whenever DZ is invoked again after work continued without it, run the current DZ state tool's read-only `resume-report`. It validates the snapshot, reads every valid `.dz/journal.jsonl` record, compares the saved workspace checkpoint with the current Git worktree when available, and reports stale guidance. Also inspect the full visible conversation, `PROJECT.md`, accepted files, current files, checks, unresolved issues and later issue changes, and relevant running or external state before changing anything. The saved `next_action` is an old proposal until this comparison shows it is still current; never jump back to it and erase or bypass later work. If no saved workspace comparison exists, say which later changes cannot be dated instead of guessing. Begin with a short plain-language summary of what was already done, what changed after the latest saved record, what can stay, conflicts or unknowns, important problems found, and what actions you recommend next with reasons and meaningful options. Ask the user to correct or confirm that account and discuss how to proceed. Do not make new project changes until the user confirms the current position and execution approach. If the report says the managed guidance is stale, include `install-guidance` in the proposed actions and run it only after that confirmation. This resume confirmation does not accept an unseen product decision or authorize an external action. Do not restart discovery or rely only on chat memory when current project evidence is available.

Treat accepted files under `docs/sdlc/` as the product decisions and `.dz/state.json` as the current execution snapshot.

- Run the DZ state check before acting and recover from `.dz/journal.jsonl` if the snapshot is damaged.
- Keep one work item in progress at a time. Record meaningful changes, checks, user decisions, failures, risks, pauses, and cancellations in the same turn.
- Record each material problem in the issue ledger and let DZ route it. Ordinary defects may be repaired inside already accepted behavior without repeatedly interrupting the user. If the repair changes what users do, what is stored or sent, who can access it, material cost, current scope, or another accepted promise, show the old wording, complete proposed wording, and concrete impact; wait for the user's acceptance before implementation. Only current passed evidence plus regression protection may mark the issue verified. Keep trivial noise out unless it recurs or becomes material.
- Bind work to the combined digest of the exact accepted Intent, Specification, and Plan. Bind evidence to that contract plus an explicit observed target epoch, exact acceptance statement, tested revision, environment, method, and hashed non-empty evidence file. Changing a decision or entering implementation clears the old target and downgrades old verified work. Every target reset requires fresh checks even when its revision text is unchanged. A rerun may resolve only a Failed or Unverified gap for that same statement and target. Never remove, change, or reorder history to obtain a pass, and recover when the snapshot differs from the journal.
- Keep decision order intact. A changed Intent supersedes Specification and Plan; a changed Specification supersedes Plan. Re-accepting an upstream decision does not revive downstream approval.
- Material actions wait for an informed, scope-specific user decision regardless of severity. If the authorized user accepts, bind one action lease to the accepted decisions, exact target/revision/environment, spending ceiling when applicable, and explicit expiry. Completion, failure, cancellation, expiry, or any bound fact change prevents further use; the host must enforce those limits outside the model.
- Once risk authorization is requested, pause or closure must not erase the pending decision or unconsumed lease.
- Use blocked only for a missing capability, authority, external condition, host permission, or third-party right. Risk severity is not a blocker type.
- The user may pause, cancel, or close at any time. Never translate that choice into verified completion or claim that an outside job stopped without a real status result. After cancellation, allow only a bounded signal and one status confirmation for work already running, plus the minimum ledger and handoff updates.
- Only passed evidence can move required work to verified.
- Before stopping, ensure the run is waiting for the user or authorization, blocked with a recovery condition, paused, or truthfully finished.
- A finished run accepts no ordinary project mutation until it is explicitly resumed; recording an outstanding outside-action outcome must not reopen or upgrade its verdict.

Merge this section with existing repository instructions instead of replacing them.