@pareto4/pp-core 1.19.0 → 1.21.0

package/pp-core/templates/project-charter.md

@@ -1,32 +1,51 @@
 # Project Charter Template
 
-Template for `.planning/discovery/PROJECT-CHARTER.md`, the document every stakeholder signs at the end
-of a Discovery Sprint.
+Template for `docs/discovery/PROJECT-CHARTER.md`, the document every stakeholder signs at the end of a
+Discovery Sprint. It lives under `docs/` because it is client-visible, like `docs/architecture/`;
+`.planning/discovery/` holds the facilitation record it condenses.
 
 **Purpose:** one short, fixed-shape document that states what will be built, why, for whom, how it will
-be delivered and on what conditions, so that sign-off is a decision on the same questions in the same
-order for every engagement. It summarises the thirteen session files; it does not replace them.
-
-**When:** after Session 13 (wrap-up and Go / No-Go), before `/pp-discovery-to-build`.
-
-**Shape is fixed.** Every charter has the same 14 numbered sections in the same order, with the same
-headings and the same table columns. A section with nothing to report stays in place and says so; it is
-never dropped, merged or renumbered. That is what lets a reader compare two charters side by side.
+be delivered, where it departs from the standards and on what conditions, so that sign-off is a decision
+on the same questions in the same order for every engagement. It summarises the thirteen session files
+and the discovery registers; it does not replace them.
+
+**When:** drafted in Session 13 Step 0.5 (after the cross-reference, before the wrap-up topics), reviewed
+in topics 2–3, set to `For sign-off` at the Closing Step, and required `Signed` or `Signed with
+conditions` by `/pp-discovery-to-build`. The drafting procedure is
+`workflows/discovery-sprint/charter.md`; the parser contract and the heading translations are in
+`references/discovery-charter.md`.
+
+**Shape is fixed.** Every charter has the same 20 numbered sections in the same order, with the same
+table columns. A section with nothing to report stays in place and says so; it is never dropped, merged
+or renumbered. That is what lets a reader compare two charters side by side, and what lets
+`pp_run query discovery.charter-check` verify one.
+
+**Language.** The charter is written in the sprint language — the `Charter language` row of Session 1's
+Sprint Logistics, else `discovery.language` in `.planning/config.json`, else the language the sprint
+was facilitated in. Headings, labels and prose are translated; the `<!-- charter:<key> -->` heading
+keys, the frontmatter fields and every enum cell (`status`, `go_no_go`, `Green / Amber / Red`,
+`Approve / Approve with conditions / Reject`, `Yes / No`) stay in English, because the check reads them.
+Column order is fixed; column headings may be translated.
 
 ---
 
 ## File Template
 
-```markdown
+Copy verbatim, then fill. Tables carry no example rows: a row is written only when a session table
+supplies it. The frontmatter placeholders `0000-00-00`, `0/13` and `und` are valid to the check and are
+replaced by the drafting step.
+
+````markdown
 ---
 document: project-charter
 project: [Project name]
 client: [Client name]
-version: [1.0]
-status: [Draft | For sign-off | Signed | Signed with conditions | Rejected]
-date: [YYYY-MM-DD]
-discovery_sessions_completed: [N]/13
-go_no_go: [Go | Go with conditions | No-Go]
+version: 1.0
+status: Draft
+date: 0000-00-00
+language: und
+discovery_sessions_completed: 0/13
+go_no_go: Pending
 ---
 
 # [Project name] — Project Charter
@@ -36,61 +55,68 @@ go_no_go: [Go | Go with conditions | No-Go]
 | Document control | |
 |---|---|
 | Client | [Client name] |
-| Version / status | [1.0] · [Draft] |
-| Date | [YYYY-MM-DD] |
+| Version / status | 1.0 · Draft |
+| Date | 0000-00-00 |
 | Prepared by | [Name, role] |
-| Based on | Discovery Sprint sessions 1–13, completed [YYYY-MM-DD] |
+| Based on | Discovery Sprint sessions 1–13, completed 0000-00-00 |
 
 ---
 
-## 1. Purpose and background
+## 1. Purpose and background <!-- charter:purpose -->
 
 [Two to four sentences: the business problem and why it matters now.]
 
 **Top pain points today**
 
-| # | Pain point | Who is affected | Impact |
-|---|---|---|---|
-| 1 | | | |
+| # | Pain point | Who is affected | Impact | Source |
+|---|---|---|---|---|
 
-## 2. Objectives and success measures
+## 2. Objectives and success measures <!-- charter:objectives -->
 
-| # | Objective | KPI | Baseline | Target | Measured by |
+| ID | Objective | KPI | Baseline | Target | Measured by |
 |---|---|---|---|---|---|
-| O-1 | | | | | |
 
-## 3. Scope
+## 3. Scope <!-- charter:scope -->
 
 **In scope (MVP)**
 
-| EPIC | Title | Priority |
-|---|---|---|
-| | | |
+| EPIC | Title | Priority | Requirements |
+|---|---|---|---|
 
 **Out of scope**
 
-- [Item] — [reason or later release]
+| Item | Reason | Decision |
+|---|---|---|
 
-**Requirements:** [N] functional, [N] non-functional, [N] business rules, as registered in
-`_requirements.md`.
+**Requirements:** [one count per registered prefix, then the dropped count — `K- 12 · N- 4 · T- 3 · Dropped 1`] <!-- charter:counts -->
 
-## 4. Stakeholders and users
+## 4. Stakeholders and users <!-- charter:stakeholders -->
 
 | Stakeholder | Role | Decision authority | Involvement |
 |---|---|---|---|
-| | | | |
 
 | Persona | Description | Main goal |
 |---|---|---|
-| | | |
 
-## 5. Solution overview
+## 5. Approvals and role holders <!-- charter:approvals -->
+
+| Approval | Approver | Consulted | Source |
+|---|---|---|---|
+
+| Role | Holder | Source |
+|---|---|---|
+| Privacy owner | | |
+| Security owner | | |
+| Incident contact | | |
+| Architect (signs deviations) | | |
+
+## 6. Solution overview <!-- charter:solution -->
 
 [Two to four sentences: the shape of the solution.]
 
 | Layer | Choice | Decision |
 |---|---|---|
-| Frontend | | [D-05-n] |
+| Frontend | | |
 | Backend | | |
 | Data | | |
 | Hosting | | |
@@ -98,129 +124,164 @@ go_no_go: [Go | Go with conditions | No-Go]
 
 **Integrations**
 
-| System | Direction | Purpose |
+| ID | System | Direction | Purpose |
+|---|---|---|---|
+
+## 7. Deviations from standards <!-- charter:deviations -->
+
+| ID | Standard | Choice | Reason | Reversible | Approver | Decision | Status |
+|---|---|---|---|---|---|---|---|
+
+## 8. Data <!-- charter:data -->
+
+| Aspect | Statement | Source |
 |---|---|---|
-| | | |
+| Highest data classification | | |
+| Personal data processed | | |
+| Controller / processor role | | |
+| Retention headline | | |
+| Availability target (RTO / RPO) | | |
 
-**Security and compliance:** [data classification, applicable regulations, availability target, in two to
-four lines.]
+## 9. Quality and acceptance <!-- charter:quality -->
 
-## 6. Quality and acceptance
+| Gate | Criterion | Approved by |
+|---|---|---|
+| UAT sign-off | | |
+| Go-live readiness | | |
 
-| Gate | Criterion |
-|---|---|
-| UAT sign-off | [criteria] — approved by [role] |
-| Go-live readiness | [criteria] |
+## 10. What was validated <!-- charter:validated -->
 
-## 7. Delivery plan
+| Round | Prototype version | Flows validated | Verdicts (change / keep / drop / question) | Closed? |
+|---|---|---|---|---|
+
+**Screens:** [n] required, [n] deferred, [n] MVP requirements in the no-screen bucket with a reason, 0 uncovered — as `_screens.md` records them.
 
-| Milestone | Target date | Included EPICs | Exit criteria |
+## 11. Delivery plan <!-- charter:delivery -->
+
+| Milestone | Target | Included EPICs | Exit criteria |
 |---|---|---|---|
-| [v1.0 — MVP] | | | |
 
 **Build order:** [EPIC order and why.]
 
-## 8. Team and governance
+## 12. Team and governance <!-- charter:team -->
 
 | Role | Name / party | Responsibility |
 |---|---|---|
-| | | |
 
 **Scope changes are approved by:** [role]. **Progress is reported:** [cadence, format].
 
-## 9. Budget, constraints and assumptions
+## 13. Budget, constraints and assumptions <!-- charter:budget -->
 
 | Type | Item | Source |
 |---|---|---|
-| Budget | [amount or "Not decided in Discovery — OI-n"] | |
-| Constraint | | |
-| Assumption | | |
 
-## 10. Risks
+## 14. Risks <!-- charter:risks -->
 
-| # | Risk | Likelihood | Impact | Mitigation | Owner |
+| ID | Risk | Likelihood | Impact | Mitigation | Owner |
 |---|---|---|---|---|---|
-| R-1 | | | | | |
 
-## 11. Open items
+## 15. Open items <!-- charter:open-items -->
 
-| ID | Item | Must resolve before build? | Owner | Target date |
-|---|---|---|---|---|
-| OI-1 | | | | |
+| ID | Item | Must resolve before build? | Owner | Target date | Status |
+|---|---|---|---|---|---|
+
+## 16. Conditions <!-- charter:conditions -->
+
+| Kind | ID | Statement | Resolution |
+|---|---|---|---|
 
-## 12. Go / No-Go recommendation
+## 17. Go / No-Go recommendation <!-- charter:go-no-go -->
 
 | Criterion | Status | Note |
 |---|---|---|
-| Business requirements clarity | [Green / Amber / Red] | |
+| Business requirements clarity | | |
 | Technical architecture feasibility | | |
 | Security and compliance readiness | | |
 | Integration dependencies resolved | | |
 | Team and budget availability | | |
 | Timeline confidence | | |
 | Stakeholder alignment | | |
-| **Overall recommendation** | **[Go / Go with conditions / No-Go]** | |
+| **Overall recommendation** | | |
 
-**Conditions:** [each condition attached to a Go, or "None".]
-
-## 13. Key decisions
+## 18. Key decisions <!-- charter:decisions -->
 
 | ID | Decision | Rationale | Owner |
 |---|---|---|---|
-| D-01-1 | | | |
 
-## 14. Sign-off
+## 19. Sign-off <!-- charter:sign-off -->
 
-By signing, each party agrees that sections 1–13 describe the project to be built, subject to the
-conditions stated.
+By signing, each party agrees that sections 1–18 describe the project to be built, subject to the
+conditions in § 16.
 
 | Role | Name | Decision | Conditions | Date | Signature |
 |---|---|---|---|---|---|
-| [Sponsor] | | [Approve / Approve with conditions / Reject] | | | |
+| [Sponsor] | | | | | |
 | [Product owner] | | | | | |
 | [Delivery lead] | | | | | |
 
+## 20. Version history <!-- charter:history -->
+
+| Version | Date | Status | Change | Decision |
+|---|---|---|---|---|
+| 1.0 | 0000-00-00 | Draft | Initial draft from Sessions 1–13 | — |
+
 ---
 
-**Source files:** `.planning/discovery/session-01.md` … `session-13.md`, `_requirements.md`.
-```
+**Source files:** `.planning/discovery/session-01.md` … `session-13.md`, `_requirements.md`, `_screens.md`,
+`_feedback.md`, `_research.md`, `_deviations.md`.
+````
 
 ---
 
 ## Where each section comes from
 
-Fill every section from the session tables below and nothing else. The session files are the source of
-truth; the charter only condenses them.
+Fill every section from the tables below and nothing else. The session files and the registers are the
+source of truth; the charter only condenses them.
 
 | § | Section | Source (file § table) |
 |---|---|---|
-| — | Front matter, document control | `_progress.md` (completion dates); Session 1 § Stakeholder Register (client) |
-| 1 | Purpose and background | Session 1 § Business Vision Summary; Session 2 § Pain Points Register (top 3–5 by impact) |
-| 2 | Objectives and success measures | Session 3 § Business Objectives |
-| 3 | Scope | Session 3 § MVP Scope Boundary and § EPIC Register; counts from the roll-up block in `_requirements.md` |
+| — | Front matter, document control | `_progress.md` (completion dates); Session 1 § Stakeholder Register (client); language per the rule above |
+| 1 | Purpose and background | Session 1 § Business Vision Summary; Session 2 § Pain Points Register (top 3–5 by impact, `PP-` IDs in Source) |
+| 2 | Objectives and success measures | Session 3 § Business Objectives (`BO-` IDs); a column the source table does not have (Baseline, say) reads `—` |
+| 3 | Scope | Session 3 § MVP Scope Boundary and § EPIC Register (`E-` IDs, each with the requirement IDs it groups — from the register's requirement column when it has one, else from the Step Matrices' Requirements cells grouped by EPIC); out-of-scope items with their `D-` decision; counts from the roll-up block of `_requirements.md` |
 | 4 | Stakeholders and users | Session 1 § Stakeholder Register; Session 4 § Refined Personas (else Session 2 § User Personas) |
-| 5 | Solution overview | Session 5 § Technology Stack Decisions and § Architecture Decision Records; Session 8 § Integration Design Register; Session 6 § Data Classification Matrix, § Compliance Requirements Register, § Availability and DR Targets; Session 7 § IdP Integration Design |
-| 6 | Quality and acceptance | Session 9 § UAT Process and § Quality Gates; Session 10 § Go-Live Readiness Checklist |
-| 7 | Delivery plan | Session 11 § Milestone Plan, § Project Timeline, § EPIC Build Order |
-| 8 | Team and governance | Session 12 § Team Structure and § Governance Structure; reporting cadence from Session 12 topic "Communication and reporting" |
-| 9 | Budget, constraints and assumptions | Session 1 § Constraints and Risks Register; any `[needs-business-input]` item still parked |
-| 10 | Risks | Session 11 § Risk Register, plus open risks from Session 1 § Constraints and Risks Register |
-| 11 | Open items | Session 13 § Open Items Register |
-| 12 | Go / No-Go recommendation | Session 13 § Go / No-Go Assessment (copied as recorded, not re-scored) |
-| 13 | Key decisions | § Key Decisions of every session — only decisions that change scope, architecture, cost or timeline |
-| 14 | Sign-off | Session 1 § Stakeholder Register — every stakeholder with approval authority gets a row |
+| 5 | Approvals and role holders | Session 1 § Approval Matrix (one row each, Source `[vault: <path>]` or `room`); a Session 1 that predates the matrix gives the Stakeholder Register's decision-authority column instead. Role holders (privacy owner, security owner, incident contact, architect) from the Key Decision of any session that names one — `Not decided in Discovery — OI-n` when none does |
+| 6 | Solution overview | Session 5 § Technology Stack Decisions (`D-05-n`) and § Architecture Decision Records; Session 8 § Integration Design Register (`IF-` IDs); Session 7 § IdP Integration Design |
+| 7 | Deviations from standards | `_deviations.md` (`DEV-` IDs, every row — `charter-check` reports a row left out) when it exists; until then every **Deviation Record** table a session carries (Sessions 5–10, `ADR-` IDs, Status as signed or superseded) plus every Sessions 4–10 **Standards Applied** row whose Deviation is not `none`, each with its `D-ss-n` |
+| 8 | Data | Session 6 § Data Classification Matrix, § Compliance Requirements Register, § Availability and DR Targets; Session 2 § Data Entity Map for personal data |
+| 9 | Quality and acceptance | Session 9 § UAT Process and § Quality Gates; Session 10 § Go-Live Readiness Checklist |
+| 10 | What was validated | `_feedback.md` (one row per round: verdict counts, whether every `Processing` cell is closed); `_screens.md` (required / deferred counts, and the number of MVP requirements in the no-screen bucket — uncovered requirements are always 0 once `screen-check` passes); `prototype/README.md` (flows, version) |
+| 11 | Delivery plan | Session 11 § Milestone Plan, § Project Timeline, § EPIC Build Order |
+| 12 | Team and governance | Session 12 § Team Structure and § Governance Structure; reporting cadence from Session 12 topic "Communication and reporting" |
+| 13 | Budget, constraints and assumptions | Session 1 § Constraints and Risks Register (`CON-` IDs); any `[needs-business-input]` item still parked. IDs are copied as minted — an engagement that minted `C1`/`R1` without a hyphen keeps them, and those rows are then outside the families `charter-check` resolves |
+| 14 | Risks | Session 11 § Risk Register plus open risks from Session 1 § Constraints and Risks Register (`R-` IDs, as minted) |
+| 15 | Open items | Session 13 § Open Items Register, row for row, in the charter's six columns — `Source Session` and `Priority` stay in the register (`OI-` IDs) |
+| 16 | Conditions | every condition attached to a `Go with conditions` (an Amber row under a plain `Go` is not a condition; it stays an open item); every section carrying `⚠️ CONDITIONAL — <RS-nn\|DG-nn>` (from the sessions' `conditional:` frontmatter); every open `Gates-MVP` row of `_research.md`; every `Dropped (D-ss-n)` row of `_requirements.md`; every Session 13 open item that must resolve before build and is still open |
+| 17 | Go / No-Go recommendation | Session 13 § Go / No-Go Assessment, copied as recorded — the eight rows in order, status cells verbatim |
+| 18 | Key decisions | § Key Decisions of every session — only decisions that change scope, architecture, cost or timeline |
+| 19 | Sign-off | Session 1 § Stakeholder Register and § Approval Matrix — every party with approval authority gets a row |
+| 20 | Version history | one row per version of this document; the last row's version equals the frontmatter `version` |
 
 ## Fill rules
 
 - **Never invent.** Every statement traces to a session table above. A value Discovery did not settle is
-  written as `Not decided in Discovery — OI-n`, and that item appears in § 11 Open items.
-- **Keep the IDs.** Requirement, EPIC, decision (`D-<ss>-<n>`), risk and open-item IDs are copied
-  exactly as the session files write them, so every line can be traced back.
+  written as `Not decided in Discovery — OI-n`, and that item appears in § 15 Open items.
+- **Keep the IDs.** Requirement, EPIC, decision (`D-<ss>-<n>`), risk, open-item, screen and deviation IDs
+  are copied exactly as the session files and registers write them. `charter-check` resolves every ID a
+  table cell cites; an ID nothing minted is a fault.
 - **Condense, don't copy.** Tables carry the headline rows; the full detail stays in the session files.
   Aim for a charter that reads in about fifteen minutes.
-- **Fixed shape.** Keep all 14 sections, their numbers, headings and table columns. An empty section
-  says `None identified in Discovery.`
-- **Go / No-Go is recorded, not re-judged.** § 12 copies Session 13's assessment and conditions verbatim.
+- **Fixed shape.** Keep all 20 sections, their keys, their order and their table columns. An empty table
+  stays in place with no rows, and the section's prose says `None identified in Discovery.` (in the
+  sprint language). The **Source files** footer names only the files that exist in this engagement.
+- **Go / No-Go is recorded, not re-judged.** § 17 copies Session 13's assessment verbatim and the
+  frontmatter `go_no_go` equals its overall recommendation; `Pending` is allowed only while `status`
+  is `Draft`.
+- **Conditions are the honest qualifiers of the sign-off.** A Session 13 open item marked
+  `Yes` under *Must resolve before build?* is either closed in Session 13 or listed in § 16.
 - **Status follows the signatures.** `Draft` while being written, `For sign-off` once circulated,
-  `Signed` when every § 14 row says Approve, `Signed with conditions` when any row approves with
-  conditions, `Rejected` when any row rejects. A new version resets the status to `Draft`.
+  `Signed` when every § 19 row says `Approve`, `Signed with conditions` when any row approves with
+  conditions, `Rejected` when any row rejects.
+- **A change is a new version.** Any edit after `For sign-off` adds a § 20 row, bumps `version`,
+  resets `status` to `Draft` and regenerates the exports (`workflows/discovery-sprint/charter.md`
+  § Redraft). The markdown is the source; `PROJECT-CHARTER.docx` and `.pdf` next to it are renderings.

package/pp-core/templates/project.md

@@ -68,9 +68,9 @@ Common types: Tech stack, Timeline, Budget, Dependencies, Compatibility, Perform
 
 <!-- Decisions that constrain future work. Add throughout project lifecycle. -->
 
-| Decision | Rationale | Outcome |
-|----------|-----------|---------|
-| [Choice] | [Why] | [✓ Good / ⚠️ Revisit / — Pending] |
+| ID | Decision | Rationale | Outcome |
+|----|----------|-----------|---------|
+| [D-<ss>-<n> from Discovery, or —] | [Choice] | [Why] | [✓ Good / ⚠️ Revisit / — Pending] |
 
 ---
 *Last updated: [date] after [trigger]*

package/pp-core/templates/requirements.md

@@ -107,6 +107,24 @@ Which phases cover which requirements. Updated during roadmap creation.
 - Complete: Requirement verified
 - Blocked: Waiting on external factor
 
+**Discovery variant (projects handed over by `/pp-discovery-to-build`):**
+- Every line is one `_requirements.md` row with its minted ID; nothing is renumbered
+- The description is followed by ` — <MoSCoW> · <Disposition> · <Provenance>` copied from the row
+  (`Must · MVP · [03 §2.1]`), and the acceptance criteria follow on an indented `- AC:` line, verbatim
+- `MVP` rows are v1, `Later` rows are v2, `Dropped (D-ss-n)` rows are Out of Scope with the decision
+  as the reason; the `**ID**` lead keeps every existing parser working
+
+```markdown
+### Order Intake (E-01)
+
+- [ ] **K-01**: User can create a task — Must · MVP · [03 §2.1]
+  - AC: A task appears in the list within one second of saving
+```
+
+The planner and verifier read the same rows through `pp_run query discovery.for-phase <N>`
+(`references/discovery-build-consumption.md`); this file is the roadmap-side mirror, not a second
+source.
+
 </guidelines>
 
 <evolution>

package/pp-core/templates/roadmap.md

@@ -107,7 +107,7 @@ Phases execute in numeric order: 2 → 2.1 → 2.2 → 3 → 3.1 → 4
 **Initial planning (v1.0):**
 - Phase count depends on granularity setting (coarse: 3-5, standard: 5-8, fine: 8-12)
 - Each phase delivers something coherent
-- Phases can have 1+ plans (split if >3 tasks or multiple subsystems)
+- Phases can have 1+ plans (split only for parallelism across independent subsystems or when the work exceeds the per-plan context budget; up to 6 tasks per plan)
 - Plans use naming: {phase}-{plan}-PLAN.md (e.g., 01-02-PLAN.md)
 - No time estimates (this isn't enterprise PM)
 - Progress table updated by execute workflow

package/pp-core/templates/verification-report.md

@@ -69,6 +69,22 @@ behavior_unverified_items: # Only if behavior_unverified > 0 — the truths abov
 
 **Coverage:** {N}/{M} requirements satisfied
 
+## Discovery conformance
+
+{Only on a project that ran the Discovery Sprint — omit the whole section otherwise. The block is
+rendered by `pp_run query discovery.for-phase {X} --conformance-template`, one row per Discovery
+register row citing this phase's requirement IDs; the verifier fills Status and Evidence and checks
+it with `--verify`. Status is exactly `honoured`, `amended (D-P<nn>-<n>)` or `missed`; a `missed`
+row is a gap. Contract: `references/discovery-build-consumption.md`.}
+
+<!-- discovery:conformance -->
+| Artifact | Row | Status | Evidence |
+|---|---|---|---|
+| `_requirements.md` | {K-01} | honoured | {file:line or test that realises the acceptance criteria} |
+| `_processes.md` | {MP-01 #3} | amended (D-P{XX}-{n}) | {the amended cell the build matches} |
+| `_rules.md` | {BR-02} | missed | {what contradicts or is absent} |
+<!-- /discovery:conformance -->
+
 ## Anti-Patterns Found
 
 | File | Line | Pattern | Severity | Impact |
@@ -193,7 +209,7 @@ None — all verifiable items checked programmatically.
 **Fix plan generation:**
 - Only generate if gaps_found
 - Group related fixes into single plans
-- Keep to 2-3 tasks per plan
+- Size each fix plan by estimated context cost (up to 6 tasks per plan)
 - Include verification task in each plan
 
 ---

package/pp-core/workflows/audit-milestone.md

@@ -163,8 +163,11 @@ Classify per phase:
 | COMPLIANT | `nyquist_compliant: true` and all tasks green |
 | PARTIAL | VALIDATION.md exists, `nyquist_compliant: false` or red/pending |
 | MISSING | No VALIDATION.md |
+| SKIPPED | No VALIDATION.md and the phase verdict skipped the Nyquist audit — report `skipped (ceremony: <reason>)`, never MISSING |
 
-Add to audit YAML: `nyquist: { compliant_phases, partial_phases, missing_phases, overall }`
+Before marking a phase MISSING, read `pp_run ceremony get "<phase number>" --pick gates.nyquist.report`; when it starts with `skipped (ceremony:` the status is SKIPPED. A failed read leaves the phase MISSING. A SKIPPED phase does not lower `overall`.
+
+Add to audit YAML: `nyquist: { compliant_phases, partial_phases, missing_phases, skipped_phases, overall }`
 
 Discovery only — never auto-calls `/pp:validate-phase`.
 

package/pp-core/workflows/autonomous.md

@@ -16,7 +16,7 @@ Read all files referenced by the invoking prompt's execution_context before star
 
 ## 1. Initialize
 
-Parse `$ARGUMENTS` for `--from N`, `--to N`, `--only N`, `--interactive`, `--supervised`, `--converge`/`--cross-ai`, reviewer selector flags, and `--max-cycles N`:
+Parse `$ARGUMENTS` for `--from N`, `--to N`, `--only N`, `--interactive`, `--supervised`, `--converge`/`--cross-ai`, `--full`, reviewer selector flags, and `--max-cycles N`:
 
 ```bash
 FROM_PHASE=""
@@ -44,6 +44,8 @@ SUPERVISED=""
 if echo "$ARGUMENTS" | grep -q '\-\-supervised'; then SUPERVISED="true"; fi
 UNATTENDED_ARG=""
 if [ -z "$SUPERVISED" ]; then UNATTENDED_ARG=" --unattended"; fi
+FULL_ARG=""
+if echo "$ARGUMENTS" | grep -qE '(^|[[:space:]])--full([[:space:]]|$)'; then FULL_ARG=" --full"; fi
 
 PLAN_STRATEGY="local"
 if echo "$ARGUMENTS" | grep -qE '(^|[[:space:]])\-\-(converge|cross-ai)([[:space:]]|$)'; then
@@ -62,11 +64,12 @@ if echo "$ARGUMENTS" | grep -qE '\-\-max-cycles\s+[0-9]+'; then
   MAX_CYCLES_ARG=$(echo "$ARGUMENTS" | grep -oE '\-\-max-cycles\s+[0-9]+' | awk '{print $2}')
   CONVERGENCE_ARGS="${CONVERGENCE_ARGS} --max-cycles ${MAX_CYCLES_ARG}"
 fi
+CONVERGENCE_ARGS="${CONVERGENCE_ARGS}${FULL_ARG}"
 ```
 
 When `--interactive` is set, discuss runs inline with questions (not auto-answered). On runtimes where a backgrounded agent can spawn subagents, plan and execute are dispatched as background agents — keeping the main context lean (only discuss conversations accumulate) and enabling overlap. On Claude Code, where a backgrounded agent cannot nest subagents, plan and execute run inline to preserve worktree isolation and independent verification, so they run sequentially and their work accumulates in the main context. Either way, user input is preserved on all design decisions.
 
-When `PLAN_STRATEGY=converge`, the planning step MUST invoke the plan-review convergence workflow instead of `pp-plan-phase`. `--cross-ai` is an alias for `--converge`. Forward `CONVERGENCE_ARGS` exactly as parsed so reviewer flags and `--max-cycles N` retain the same meaning as they have on `/pp:plan-review-convergence`.
+When `PLAN_STRATEGY=converge`, the planning step MUST invoke the plan-review convergence workflow instead of `pp-plan-phase`. `--cross-ai` is an alias for `--converge`. Forward `CONVERGENCE_ARGS` exactly as parsed so reviewer flags and `--max-cycles N` retain the same meaning as they have on `/pp:plan-review-convergence`. `--full` is forwarded the same way and reaches every plan-phase call the convergence loop makes; it is never passed to execute-phase.
 
 With `--supervised` every prompt appears as before; otherwise each decision is best-effort and recorded (reference § Rules). `--interactive` only moves discuss inline.
 
@@ -286,7 +289,7 @@ Resolve active `plan:pre` hooks:
 ```bash
 [ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 UI_SPEC_FILE=$(ls "${PHASE_DIR}"/*-UI-SPEC.md 2>/dev/null | head -1)
-HOOKS_JSON=$(pp_run loop render-hooks plan:pre --raw)
+HOOKS_JSON=$(pp_run loop render-hooks plan:pre --raw --phase "${PHASE_NUM}")
 printf '%s' "$HOOKS_JSON" | node -e "let h=[];try{h=JSON.parse(require('fs').readFileSync(0,'utf-8')).activeHooks||[]}catch{}console.log('HOOKS_JSON='+JSON.stringify({activeHooks:h}))"
 ```
 
@@ -404,7 +407,7 @@ RUNTIME=$(pp_run query config-get runtime --default claude --raw 2>/dev/null ||
   - Otherwise (local planning):
 
   ```
-  Skill(skill="pp-plan-phase", args="${PHASE_NUM}${UNATTENDED_ARG}")
+  Skill(skill="pp-plan-phase", args="${PHASE_NUM}${UNATTENDED_ARG}${FULL_ARG}")
   ```
 
 - **On other runtimes:** Dispatch plan as a background agent to keep the main context lean. While plan runs, the workflow can immediately start discussing the next phase (see step 4).
@@ -425,7 +428,7 @@ RUNTIME=$(pp_run query config-get runtime --default claude --raw 2>/dev/null ||
   Agent(
     description="Plan phase ${PHASE_NUM}: ${PHASE_NAME}",
     run_in_background=true,
-    prompt="Run plan-phase for phase ${PHASE_NUM}: Skill(skill=\"pp-plan-phase\", args=\"${PHASE_NUM}${UNATTENDED_ARG}\")"
+    prompt="Run plan-phase for phase ${PHASE_NUM}: Skill(skill=\"pp-plan-phase\", args=\"${PHASE_NUM}${UNATTENDED_ARG}${FULL_ARG}\")"
   )
   ```
 
@@ -442,7 +445,7 @@ Skill(skill="pp-plan-review-convergence", args="${PHASE_NUM} ${CONVERGENCE_ARGS}
 If `PLAN_STRATEGY=local`, run the regular planner:
 
 ```
-Skill(skill="pp-plan-phase", args="${PHASE_NUM}${UNATTENDED_ARG}")
+Skill(skill="pp-plan-phase", args="${PHASE_NUM}${UNATTENDED_ARG}${FULL_ARG}")
 ```
 
 Verify plan produced output — re-run `init phase-op` and check `has_plans`. If false → go to handle_blocker: "Plan phase ${PHASE_NUM} did not produce any plans."
@@ -535,7 +538,7 @@ Phase ${PHASE_NUM} ✅ ${PHASE_NAME} — Verification passed
 **If `gaps_found`:** rule A-3 — one closure attempt:
 
 ```
-Skill(skill="pp-plan-phase", args="${PHASE_NUM} --gaps${UNATTENDED_ARG}")
+Skill(skill="pp-plan-phase", args="${PHASE_NUM} --gaps${UNATTENDED_ARG}${FULL_ARG}")
 ```
 
 Verify gap plans were created — re-run `init phase-op ${PHASE_NUM}` and check `has_plans`. If no new gap plans → go to handle_blocker: "Gap closure planning for phase ${PHASE_NUM} did not produce plans."
@@ -561,7 +564,7 @@ Resolve the active post-verification hooks and the UI-SPEC gate:
 ```bash
 [ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 UI_SPEC_FILE=$(ls "${PHASE_DIR}"/*-UI-SPEC.md 2>/dev/null | head -1)
-HOOKS_JSON=$(pp_run loop render-hooks verify:post --raw)
+HOOKS_JSON=$(pp_run loop render-hooks verify:post --raw --phase "${PHASE_NUM}")
 ```
 
 Read the `activeHooks` array directly from the `HOOKS_JSON` value already in context (do not invoke a shell `jq` pipeline — parse as the JSON object it is). **If `activeHooks` is empty or absent:** skip silently to the iterate step.

package/pp-core/workflows/code-review.md

@@ -106,15 +106,19 @@ Default is active through the Capability Registry schema — only skip when the
 Determine review depth with priority order:
 
 1. DEPTH_OVERRIDE from --depth flag (highest priority)
-2. Config value: `pp-tools.cjs query config-get workflow.code_review_depth 2>/dev/null`
-3. Default: "standard"
+2. Phase verdict: `pp_run ceremony get "${PHASE_ARG}" --pick code_review_depth` (the configured depth when no verdict is recorded)
+3. Config value: `pp-tools.cjs query config-get workflow.code_review_depth 2>/dev/null`
+4. Default: "standard"
 
 ```bash
 if [ -n "$DEPTH_OVERRIDE" ]; then
   REVIEW_DEPTH="$DEPTH_OVERRIDE"
 else
-  CONFIG_DEPTH=$(pp_run query config-get workflow.code_review_depth --raw 2>/dev/null || echo "")
-  REVIEW_DEPTH="${CONFIG_DEPTH:-standard}"
+  REVIEW_DEPTH=$(pp_run ceremony get "${PHASE_ARG}" --pick code_review_depth 2>/dev/null || echo "")
+  if [ -z "$REVIEW_DEPTH" ]; then
+    CONFIG_DEPTH=$(pp_run query config-get workflow.code_review_depth --raw 2>/dev/null || echo "")
+    REVIEW_DEPTH="${CONFIG_DEPTH:-standard}"
+  fi
 fi
 ```
 
@@ -514,6 +518,8 @@ Spawn the pp-code-reviewer agent:
 
 Print: `◆ Spawning code reviewer... (runs in a subagent — no output until it returns, ~1–5 min; expected, not a freeze)`
 
+`pp_run timeline start code-reviewer "${PHASE_ARG}" --model inherit || true` — rules: `pp-core/references/phase-timeline.md`
+
 ```
 Agent(subagent_type="pp-code-reviewer", prompt="
 <files_to_read>
@@ -540,7 +546,7 @@ ${AGENT_SKILLS_REVIEWER}")
 
 **Agent failure handling:**
 
-If the Agent() call fails (agent error, timeout, or exception):
+If the Agent() call fails (agent error, timeout, or exception): first run `pp_run timeline end code-reviewer "${PHASE_ARG}" failed || true`, then show:
 ```
 Error: Code review agent failed: ${error_message}
 
@@ -555,6 +561,7 @@ After agent completes successfully, verify REVIEW.md was created and has valid s
 
 ```bash
 [ -z "${ZSH_VERSION:-}" ] || emulate -R sh
+TL_OUTCOME=failed
 if [ -f "${REVIEW_PATH}" ]; then
   # Validate REVIEW.md has valid YAML frontmatter with status field
   HAS_STATUS=$(REVIEW_PATH="${REVIEW_PATH}" node -e "
@@ -565,12 +572,13 @@ if [ -f "${REVIEW_PATH}" ]; then
   " 2>/dev/null)
   
   if [ "$HAS_STATUS" = "valid" ]; then
+    TL_OUTCOME=complete
     echo "REVIEW.md created at ${REVIEW_PATH}"
     
     if [ "$COMMIT_DOCS" = "true" ]; then
       pp_run query commit \
         "docs(planning): add code review report" --phase "${PADDED_PHASE}" \
-        --files "${REVIEW_PATH}"
+        --files "${REVIEW_PATH}" "${PHASE_DIR}"/*-TIMELINE.jsonl
     fi
   else
     echo "Warning: REVIEW.md exists but has invalid or missing frontmatter (no status field)."
@@ -580,6 +588,7 @@ else
   echo "Warning: Agent completed but REVIEW.md not found at ${REVIEW_PATH}. This may indicate an agent issue."
   echo "No REVIEW.md to commit. Please retry with /pp:code-review ${PHASE_ARG}"
 fi
+pp_run timeline end code-reviewer "${PHASE_ARG}" "${TL_OUTCOME}" || true
 ```
 </step>