git:20260906.3371dea to git:20260910.209b446

9 added, 18 removed. Audit A to A.

# DZ Project Continuity

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

- This is a DZ product project. Load the installed `dz` Skill before product work; if it is unavailable, say so instead of silently inventing a substitute.

- At the start of a new task, or whenever DZ is invoked again after other work continued:

- 1. Begin read-only. Read `PROJECT.md` and run the current DZ state tool's `resume-report`.

- 2. Trust neither old chat nor the saved `next_action` by itself. The report checks the full journal, the generated current view, and the saved Git checkpoint mechanically. Use its compact present summary first. Read full history or affected files only when it reports a mismatch, unexplained change, unresolved contradiction, stale view, or material uncertainty.

- 3. Reconcile that with the visible conversation and any current running or external state. In plain language, report what exists now, what changed later, what remains uncertain, and the recommended next actions with reasons and meaningful choices.

- 4. Let the user correct that account and discuss the route before new project changes. This alignment does not accept unseen product wording or authorize a new external action.

- The user's current explicit instruction takes priority over DZ workflow preferences within the allowed and authorized scope. If DZ itself forces a pause or route change, name the exact rule and concrete reason. Do safe, already-authorized, reversible preparation before asking. Do not request the same permission twice when the current message clearly specifies the action, target, and scope.

- The latest explicitly accepted product wording is current; later brainstorming is not. When an accepted decision changes, keep the old version in history but remove it from the active view, supersede only affected downstream work, and preserve compatible implementation. Record meaningful decisions, changes, checks, failures, material issues, risk decisions, pauses, cancellations, and handoffs in the ledger during the same turn.

+ DZ workflow guidance version: `2026-09-10.3`.

- Independent read-only checks or isolated work may run in parallel. Serialize changes to the same files, decision, ledger state, production target, or external action. During implementation, test affected behavior and critical shared paths; run the full required acceptance set for a release candidate, material shared-contract change, or unbounded impact.

+ Load the installed `dz` Skill before product work. The Skill owns workflow rules; this file only reconnects this project to them. If unavailable, say so and do not invent a substitute.

- Before deploying to an internal test environment or preparing a public release, run a default AI preflight: check the current Must and core user paths end to end, then review changed code and critical shared paths. Run safe in-scope local checks without asking again. Report passed, failed, and unverified items separately. This prepares internal human testing and never replaces it or independent review.

+ At a new task, mid-task DZ activation or unexplained drift:

+ 1. Begin read-only: read `PROJECT.md` and run the installed state tool's `resume-report`.

+ 2. Compare the current accepted requirements and relevant files with the report and visible conversation. The saved `next_action` is an old proposal, not a command.

+ 3. Explain what exists now, later changes, uncertainty and the recommended route. Let the user correct it and discuss the route before new project changes. A current explicit instruction that already confirms that exact position and route need not be requested again.

+ 4. After alignment, follow the Skill's correction, requirement coverage, work carry-forward, recording and authorization rules. Do not repeat takeover after an ordinary question or tool result.

- Risk severity alone is not a refusal. Explain the consequence and safer route, then let an authorized user decide. Secrets, sensitive information, payment, external writes/messages, deletion, migration, public release, and production access still require current action-specific authorization. Stopping never becomes proof: only current Passed evidence can mark required work verified, and the user may pause, cancel, or close with an honest handoff at any time.

+ Use the current report's `requirement_coverage` and `work_to_reconcile` to expose missing promises and old work still needing a keep/revise/retire decision. Read actual accepted wording; the summary is an index. Preserve later valid work. Missing coverage prevents a global verified claim, not honest stopping.

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

+ Project-local commands, architecture and stable conventions may be added outside this managed section. Current scope, decisions and evidence belong in the SDLC records. Merge this section with existing repository instructions instead of replacing them.