@pareto4/pp-core 1.17.1 → 1.19.0

package/pp-core/workflows/discovery-sprint/sessions/01-kick-off.md

@@ -5,7 +5,7 @@
 
 ### Session 1: Discovery Sprint Kick-off
 
-**Goal:** Align all participants on the Discovery Sprint purpose, establish project context, confirm business vision, identify stakeholders, and agree on the discovery approach, ground rules, and logistics.
+**Goal:** Align all participants on the Discovery Sprint purpose, establish project context, confirm business vision, identify stakeholders and who approves what, and agree on the discovery approach, ground rules, and logistics.
 
 **What We Cover:**
 
@@ -29,9 +29,10 @@
 
 4. **Discovery Sprint approach and logistics**
    *Why it matters: sets expectations so the remaining 12 sessions run smoothly without renegotiating format each time. Skip when: the team has already run a Discovery Sprint together before and knows the cadence.*
-   - Walk through the 13-session agenda and expected outputs
+   - Walk through the 13-session agenda and expected outputs, including the cross-reference that closes Session 8 and the one that opens Session 13
    - What is the preferred meeting cadence and format (in-person, remote, hybrid)?
    - How will decisions be documented and communicated?
+   - What is the team shape for the sprint and the build: a full delivery team, a small team, or one person working with an AI assistant? Session 12 builds the delivery model on this answer.
 
 5. **Ground rules and ways of working**
    *Why it matters: prevents disagreements from derailing later sessions once real tradeoffs surface. Skip when: the team already has an established working agreement from a prior engagement.*
@@ -44,16 +45,28 @@
    - Are there hard deadlines (regulatory, contractual, market)?
    - What budget constraints exist? [needs-business-input]
    - Are there technology mandates or restrictions?
+   - Does the client vault or the client mandate a platform: cloud provider, CI/CD, observability? Record the mandate as a Key Decisions row `D-01-<n>`, citing `[vault: <path>]` when the vault states it. Sessions 5, 6 and 10 fill their tables against this decision; with no mandate, record that the platform is open.
 
 7. **Requirement ID prefixes and decision-ID conventions**
    *Why it matters: every requirement, decision, and action across all 13 sessions cites these IDs — chosen once here, never renumbered. Skip when: never — mandatory.*
    - Propose a prefix set derived from the stakeholder domains just mapped in topic 3: one prefix per stakeholder domain, plus `N-` (non-functional) and `T-` (technical) defaults; the user confirms or adjusts (D-09)
    - Create `.planning/discovery/_requirements.md` from the bootstrap template in the pp-core reference `references/discovery-id-conventions.md` — locate it under the installed pp-core root (`${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-id-conventions.md`) and Read it lazily; never `@`-import it. Fill the Prefix Registry header table with the confirmed set (the registry and the requirements table travel in one file — D-10)
-   - Never register a reserved prefix: the proposed set must not include `D-`, `A-`, `SP-`, `DG-`, `RS-` or `SCR-` — they are owned by other ID families, and a row claiming one makes `discovery rollup --check` report `reserved_prefix` (D-44)
+   - Never register a reserved prefix: the proposed set must not include `D-`, `A-`, `SP-`, `DG-`, `RS-`, `SCR-` or `PRC-` — they are owned by other ID families, and a row claiming one makes `discovery rollup --check` report `reserved_prefix` (D-44). Avoid the session-table row prefixes that reference lists too (`C-`, `R-`, `E-`, …), so a citation never reads two ways
    - Decisions are cited inline as `D-<ss>-<n>` per that same reference; record the chosen prefix set as a Key Decisions row in the Session 1 notes
 
+8. **Approval routes**
+   *Why it matters: Sessions 5–7 sign architecture and security deviations; an approval route found only later means those signatures were given by people who could not give them. Skip when: never — "no formal route" is itself an answer to record.*
+   - Which approvals will this project need: scope, budget, architecture, security deviations, data protection, go-live?
+   - Who gives each approval, and who is consulted or informed?
+   - When the client vault is bound, sweep it for approval rules: every document that says who must approve what. Record each route in the **Approval Matrix** with its `[vault: <path>]` citation.
+   - Where no route exists for an approval the sprint will need, who approves it? Record the answer as `D-01-<n>`.
+
 **Notes Template:**
 
+**Background**
+
+The business problem or opportunity, what was tried before and with what result, and the documents handed over, cited by accession number (`[NN]`).
+
 **Stakeholder Register**
 
 | Name | Role | Organization | Interest Area | Decision Authority | Availability |
@@ -70,21 +83,52 @@
 | Success criteria (12-month) | |
 | Key business drivers | |
 
+**Sprint Logistics**
+
+| Aspect | Agreement |
+|--------|-----------|
+| Session cadence and format | |
+| Team shape | |
+| Decision recording and communication | |
+
+**Working Agreement**
+
+| Aspect | Agreement |
+|--------|-----------|
+| Disagreements and competing priorities | |
+| Escalation path for blockers | |
+| Collaboration tools | |
+
 **Constraints and Risks Register**
 
 | ID | Type | Description | Impact (H/M/L) | Mitigation | Owner |
 |----|------|-------------|-----------------|------------|-------|
-| C1 | Constraint | | | | |
-| R1 | Risk | | | | |
+| CON-01 | Constraint | | | | |
+| R-01 | Risk | | | | |
+
+Session 11's **Risk Register** continues the `R-` sequence; a risk raised here keeps its ID there.
+
+**Approval Matrix**
+
+| Approval | Approver | Consulted | Source | Decision |
+|----------|----------|-----------|--------|----------|
+| Scope change | | | | |
+| Budget | | | | |
+| Architecture deviation | | | | |
+| Security deviation | | | | |
+| Data protection | | | | |
+| Go-live | | | | |
+
+**Source** is a `[vault: <path>]` citation or `room`. **Decision** is `—` or the `D-01-<n>` that set a route the vault does not give.
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/02-as-is.md

@@ -57,7 +57,9 @@
 
 | Process ID | Process Name | Owner | Trigger | End State | Frequency | Avg Duration | Criticality |
 |------------|-------------|-------|---------|-----------|-----------|--------------|-------------|
-| P-01 | | | | | | | |
+| PRC-01 | | | | | | | |
+
+**Process ID** is `PRC-<nn>`, a reserved prefix, so a process never shares an ID with a requirement.
 
 **Pain Points Register**
 
@@ -85,12 +87,12 @@
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/03-to-be.md

@@ -65,7 +65,7 @@ One Mermaid flowchart block per accepted sub-process decomposition.
 
 **Step Matrices** (populated via Step 5C)
 
-One step matrix per sub-process; Requirements column back-filled at Step 5D.
+One step matrix per sub-process, or one combined matrix per main process when its sub-processes are step-sized (Step 5C); Requirements column back-filled at Step 5D.
 
 **Business Objectives**
 
@@ -99,10 +99,12 @@ Orphan-requirement and uncovered-step flags only — the canonical requirements
 
 | ID | Category | Requirement | Target / Threshold | MoSCoW |
 |----|----------|-------------|-------------------|--------|
-| NFR-01 | Performance | | | |
-| NFR-02 | Availability | | | |
-| NFR-03 | Scalability | | | |
-| NFR-04 | Accessibility | | | |
+| | Performance | | | |
+| | Availability | | | |
+| | Scalability | | | |
+| | Accessibility | | | |
+
+**ID** is the requirement's `N-<nn>` row in `_requirements.md`, minted at Step 5D like every other requirement — never a separate `NFR-` sequence.
 
 **Prototype Validation Plan** (populated via Step 5G)
 
@@ -110,13 +112,13 @@ Flows to be clickable, personas covered, and per-flow definition of "validated".
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |
 
@@ -173,7 +175,7 @@ For each accepted sub-process, propose a step-level matrix:
 - **Integration:** external systems with direction
 - **Requirements:** leave blank during 5C — back-filled with minted `_requirements.md` IDs during Step 5D consolidation
 
-Present one sub-process matrix at a time. After validation, fill the section titled exactly **Step Matrices** in `.planning/discovery/session-03.md` — edit in place; never append a new heading.
+Present one sub-process matrix at a time. When a main process's sub-processes are step-sized — each one or two steps — propose one combined matrix for the main process instead, with a **Sub-process** column after `#`; the user may still ask for one matrix per sub-process. After validation, fill the section titled exactly **Step Matrices** in `.planning/discovery/session-03.md` — edit in place; never append a new heading.
 
 ### Step 5D: Consolidate Requirements
 

package/pp-core/workflows/discovery-sprint/sessions/04-ux-design.md

@@ -120,15 +120,24 @@ Read every frontend standard that passes these checks, also one the session's ow
 | Primary | | | | |
 | Secondary | | | | |
 
+**Content and Communication**
+
+| Aspect | Decision | Notes |
+|--------|----------|-------|
+| Tone of voice | | |
+| Notifications and alerts | | |
+| Tooltips, help text and inline guidance | | |
+| Languages | | |
+
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |
 

package/pp-core/workflows/discovery-sprint/sessions/05-architecture.md

@@ -20,8 +20,8 @@
    *Why it matters: the stack choice determines team skills, hosting (Session 10), and integration patterns (Session 8). Skip when: the stack is fixed by client mandate.*
    - What is the preferred frontend technology (React, Angular, Vue, Mendix, etc.)?
    - What is the preferred backend technology (Node.js, .NET, Java, Python)?
-   - What database technology is appropriate (relational e.g. Cloud SQL via pareto-platform-gcp, document, graph, time-series)?
-   - What messaging or eventing technology will be used (Google Cloud Pub/Sub via pareto-platform-gcp, Kafka, RabbitMQ)?
+   - What database technology is appropriate (relational, document, graph, time-series), preferring the managed services of the platform Session 1 recorded?
+   - What messaging or eventing technology will be used (the platform's managed broker, Kafka, RabbitMQ)?
    - What caching strategy applies (Redis, in-memory, CDN)?
 
 3. **Key architectural components**
@@ -46,7 +46,7 @@
 
 **Notes Template:**
 
-> **Platform standard (D-08):** The Pareto platform standard is GCP / `pareto-platform-gcp`. Fill this table against that baseline unless the client has an overriding constraint.
+> **Platform:** fill this table against the platform Session 1 recorded (its `D-01-<n>` platform decision, citing the vault's platform standard when there is one). A row that departs from that platform is a Key Decisions row `D-05-<n>`. When Session 1 recorded the platform as open, each row's Rationale says why the technology was chosen.
 
 **Technology Stack Decisions**
 
@@ -85,12 +85,12 @@
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/06-security.md

@@ -24,7 +24,7 @@
    - What are the audit requirements and cadence?
 
 3. **Encryption strategy**
-   *Why it matters: key management choices here constrain infrastructure options in Session 10. Skip when: the platform standard (GCP KMS) already covers requirements with no exceptions.*
+   *Why it matters: key management choices here constrain infrastructure options in Session 10. Skip when: the key management service of the platform Session 1 recorded already covers requirements with no exceptions.*
    - What encryption is required at rest (AES-256, TDE)?
    - What encryption is required in transit (TLS 1.2+, mTLS)?
    - How will encryption keys be managed (HSM, KMS, Vault)?
@@ -94,12 +94,12 @@
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/07-identity.md

@@ -85,12 +85,12 @@
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/08-integration.md

@@ -72,12 +72,24 @@
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |
+
+**Mid-Sprint Cross-Reference**
+
+Filled by the Closing Step below: the findings count by severity, each fix applied (file, what changed, why), and each finding left for Session 13.
+
+---
+
+**Closing Step — mid-sprint cross-reference.** Run it after Step 7 and before Step 8, every time Session 8 completes, including a redo. Sessions 9–12 build on Sessions 1–8; an inconsistency found now costs one edit, while Session 13 finds it repeated in every later session.
+
+1. Read `${PP_TOOLS%/bin/pp-tools.cjs}/workflows/discovery-sprint/sessions/13-wrap-up.md` § **Step 0** and run 0a to 0e over Sessions 1–8 only: the **Business Functional** and **Technical** groups. Skip the engine gates and the checklist rows that need Sessions 9–12.
+2. Check every amended decision against the back-amend rule (Flow 2 Step 6): the original line carries `→ amended by D-<ss>-<n>`. Fix any line that does not.
+3. Record the results in this session's **Mid-Sprint Cross-Reference** notes. Session 13 re-checks the findings left open here.

package/pp-core/workflows/discovery-sprint/sessions/09-qa.md

@@ -96,12 +96,12 @@
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/10-infrastructure.md

@@ -10,24 +10,24 @@
 **What We Cover:**
 
 1. **Cloud / hosting strategy**
-   *Why it matters: hosting choice constrains every deployment, monitoring, and DR decision below. Skip when: the platform standard (GCP/pareto-platform-gcp) applies with no client override.*
-   - What cloud provider will be used (GCP / `pareto-platform-gcp` is the Pareto platform standard; or AWS, Azure, on-premises, hybrid)?
+   *Why it matters: hosting choice constrains every deployment, monitoring, and DR decision below. Skip when: Session 1 recorded a mandated platform and the client has no override.*
+   - What cloud provider will be used? Start from the platform Session 1 recorded; when it is open, choose between cloud providers, on-premises and hybrid.
    - What is the account and subscription structure?
    - What regions and availability zones are required?
    - Are there data sovereignty or residency requirements that constrain hosting?
    - What is the cost model and budget for infrastructure? [needs-business-input]
 
 2. **Deployment strategy**
-   *Why it matters: deployment model determines rollback risk and go-live readiness criteria (Session 13). Skip when: the platform CI/CD pipeline already fixes this by default.*
+   *Why it matters: deployment model determines rollback risk and go-live readiness criteria (Session 13). Skip when: the mandated platform's CI/CD pipeline already fixes this by default.*
    - What deployment model will be used (blue-green, canary, rolling, immutable)?
    - How will the CI/CD pipeline be structured?
-   - What tools will be used for CI/CD (GitLab CI is the Pareto platform pipeline; or GitHub Actions, Azure DevOps, Jenkins)?
+   - What tools will be used for CI/CD (GitHub Actions, GitLab CI, Azure DevOps, Jenkins)? Take the platform's pipeline when Session 1 recorded one.
    - How will infrastructure be managed (IaC with Terraform, Pulumi, CloudFormation)?
-   - What is the approach to containerization (GKE or Cloud Run via pareto-platform-gcp; Docker/Kubernetes on-prem; or other cloud options)?
+   - What is the approach to containerization (the platform's managed container or Kubernetes service, Kubernetes on-premises, or none)?
 
 3. **Monitoring, logging, and alerting**
-   *Why it matters: alerting design determines who gets paged and how incidents are caught pre-go-live. Skip when: a platform-standard observability stack already covers requirements.*
-   - What monitoring platform will be used (Google Cloud Monitoring / Cloud Logging via pareto-platform-gcp; or Datadog, New Relic, CloudWatch)?
+   *Why it matters: alerting design determines who gets paged and how incidents are caught pre-go-live. Skip when: the mandated platform's observability stack already covers requirements.*
+   - What monitoring platform will be used (the platform's native monitoring and logging, or Datadog, New Relic, Grafana)?
    - What metrics will be tracked (latency, error rate, throughput, saturation)?
    - What is the alerting strategy (thresholds, escalation chains, on-call rotation)?
    - How will application logs be aggregated and queried?
@@ -48,7 +48,7 @@
 
 **Notes Template:**
 
-> **Platform standard (D-08):** The Pareto deployment platform is GCP / `pareto-platform-gcp` with GitLab CI as the CI/CD pipeline and Google Cloud Monitoring / Cloud Logging for observability. Fill the tables below against this baseline unless the client has an overriding constraint.
+> **Platform:** fill the tables below against the platform Session 1 recorded (its `D-01-<n>` platform decision, citing the vault's platform standard when there is one): its cloud provider, CI/CD pipeline and observability stack. A choice that departs from it is a Key Decisions row `D-10-<n>`. When Session 1 recorded the platform as open, the choices are made here.
 
 **Infrastructure Architecture**
 
@@ -103,12 +103,12 @@
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/11-roadmap.md

@@ -14,7 +14,7 @@
    - What are the major phases of the project (Discovery, Build, UAT, Go-Live, Hypercare)?
    - What is the overall timeline from build start to production go-live?
    - Are there hard deadlines driven by business events, regulatory dates, or contracts? [needs-business-input]
-   - What is the sprint cadence (1-week, 2-week, 3-week)?
+   - What is the iteration model: calendar sprints (1, 2 or 3 weeks), or one iteration = one pp-core phase (discuss, plan, execute, verify), sized by scope rather than by the calendar? Record the choice as `D-11-<n>`; Session 12's cadence follows it.
 
 2. **MVP scope confirmation**
    *Why it matters: re-validates Session 3's MVP boundary before locking the build order below. Skip when: no time has passed since Session 3 and nothing has changed.*
@@ -24,7 +24,7 @@
    - What is the minimum viable product that demonstrates value to end-users?
 
 3. **Build order and dependencies**
-   *Why it matters: this ordering becomes the literal sprint-by-sprint plan the delivery team executes. Skip when: only a single EPIC exists with no sequencing decision to make.*
+   *Why it matters: this ordering becomes the literal iteration-by-iteration plan the delivery team executes. Skip when: only a single EPIC exists with no sequencing decision to make.*
    - In what order should EPICs be built?
    - What are the technical dependencies between EPICs?
    - Are there infrastructure or integration prerequisites that must be ready first?
@@ -38,6 +38,7 @@
 
 5. **Risk register and mitigation**
    *Why it matters: risks captured here are what Session 13's go/no-go recommendation weighs most heavily. Skip when: never — always capture at least the top known risks.*
+   - Which risks from Session 1's **Constraints and Risks Register** are still open? They keep their `R-` IDs here.
    - What are the top project risks (technical, resourcing, scope, external)?
    - What is the likelihood and impact of each risk?
    - What mitigation strategies will be applied?
@@ -50,7 +51,7 @@
 | Phase | Start Date | End Date | Duration | Key Activities | Dependencies |
 |-------|-----------|----------|----------|---------------|--------------|
 | Discovery | | | | | |
-| Sprint 0 / Setup | | | | | |
+| Setup (Sprint 0 or first phase) | | | | | |
 | Build -- MVP | | | | | |
 | UAT | | | | | |
 | Go-Live | | | | | |
@@ -58,10 +59,12 @@
 
 **EPIC Build Order**
 
-| Order | EPIC ID | EPIC Name | Sprint(s) | Dependencies | Critical Path? | Notes |
-|-------|---------|-----------|-----------|--------------|---------------|-------|
+| Order | EPIC ID | EPIC Name | Iteration(s) | Dependencies | Critical Path? | Notes |
+|-------|---------|-----------|--------------|--------------|---------------|-------|
 | 1 | | | | | | |
 
+**Iteration(s)** names sprints (`S1–S2`) or pp-core phases (`Phase 3`), following the iteration model chosen in topic 1.
+
 **Milestone Plan**
 
 | Milestone | Target Date | Included EPICs / Features | Entry Criteria | Exit Criteria | Stakeholder Demo? |
@@ -74,17 +77,17 @@
 **Risk Register**
 
 | ID | Risk Description | Category | Likelihood (H/M/L) | Impact (H/M/L) | Risk Score | Mitigation | Owner | Status |
-|----|-----------------|----------|--------------------|-----------------|-----------|-----------:|-------|--------|
+|----|-----------------|----------|--------------------|-----------------|-----------|------------|-------|--------|
 | R-01 | | | | | | | | |
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/12-delivery-model.md

@@ -5,34 +5,34 @@
 
 ### Session 12: Team & Delivery Model Definition
 
-**Goal:** Define the team structure and roles, establish governance and decision-making processes, agree on agile ceremonies, and plan the support model for post-go-live.
+**Goal:** Define the team structure and roles, establish governance and decision-making processes, agree on the working rhythm, and plan the support model for post-go-live. The model fits the team shape Session 1 recorded, from a full delivery team to one person working with an AI assistant.
 
 **What We Cover:**
 
 1. **Team structure and roles**
    *Why it matters: role allocation is what the Session 11 build-order plan assumes has capacity to execute. Skip when: the team is already fully staffed and roles are fixed by contract.*
-   - What roles are needed for the build phase (PO, Scrum Master, developers, QA, UX, architect)?
-   - How many people are needed for each role?
+   - What roles are needed for the build phase (product owner, delivery lead, architect, developers, QA, UX)?
+   - How many people are needed for each role? In a small team one person holds several roles: list each role, with the same name against it. When an AI assistant does part of the work, give it its own row, with the person who reviews its output.
    - Which roles are filled by the client and which by the delivery partner? [needs-business-input]
    - Are there part-time or shared resources? What is their allocation?
 
 2. **Governance and decision-making**
    *Why it matters: governance structure determines how scope changes get approved mid-build, preventing later rework. Skip when: an existing PMO governance model already applies unchanged.*
-   - What is the governance structure (steering committee, project board)?
+   - What is the governance structure (steering committee, project board, or a single sponsor)? Start from Session 1's **Approval Matrix**.
    - How often does the governance body meet?
    - What decisions require steering committee approval vs. team-level authority?
    - What is the escalation path for blockers or scope changes?
 
-3. **Agile ceremonies and cadence**
-   *Why it matters: cadence must match the sprint length assumed in Session 11's timeline. Skip when: the team already has an established ceremony rhythm from prior engagements.*
-   - What agile framework will be followed (Scrum, Kanban, SAFe, hybrid)?
-   - What is the sprint cadence and duration?
-   - What ceremonies are planned (standup, sprint planning, review, retrospective, backlog refinement)?
+3. **Working rhythm and cadence**
+   *Why it matters: the rhythm must match the iteration model Session 11 chose. Skip when: the team already has an established rhythm from prior engagements.*
+   - What way of working will be followed (Scrum, Kanban, pp-core phases, hybrid)?
+   - What is the iteration cadence: the sprint length, or the pp-core phase rhythm Session 11 chose?
+   - Which meetings are held? For a pp-core phase rhythm, planning is `/pp-discuss-phase` plus `/pp-plan-phase` and review is `/pp-verify-work` with the client. A one-person team drops the meetings it has no one to hold; record each one dropped as `D-12-<n>`.
    - What tools will be used for backlog management (Jira, Azure DevOps, Linear)?
 
 4. **Communication and reporting**
    *Why it matters: reporting cadence sets stakeholder expectations for visibility into progress. Skip when: an existing status-reporting process already covers this project.*
-   - How will progress be communicated to stakeholders (sprint review, status report, dashboard)?
+   - How will progress be communicated to stakeholders (iteration review, status report, dashboard)?
    - What is the reporting cadence (weekly, bi-weekly)?
    - What metrics will be tracked (velocity, burndown, defect rate, cycle time)?
 
@@ -50,12 +50,13 @@
 | Role | Name / TBD | Allocation (%) | Responsible Party (Client / Partner) | Start Date | Notes |
 |------|-----------|----------------|--------------------------------------|-----------|-------|
 | Product Owner | | | | | |
-| Scrum Master | | | | | |
+| Delivery Lead (Scrum Master, or none) | | | | | |
 | Solution Architect | | | | | |
 | Frontend Developer | | | | | |
 | Backend Developer | | | | | |
 | QA Engineer | | | | | |
 | UX Designer | | | | | |
+| AI assistant (reviewed by) | | | | | |
 
 **Governance Structure**
 
@@ -69,11 +70,13 @@
 
 | Ceremony | Cadence | Duration | Participants | Facilitator | Tool |
 |----------|---------|----------|--------------|-------------|------|
-| Daily standup | Daily | | | | |
-| Sprint planning | Per sprint | | | | |
-| Sprint review | Per sprint | | | | |
-| Retrospective | Per sprint | | | | |
-| Backlog refinement | Weekly | | | | |
+| Daily sync | | | | | |
+| Iteration planning | Per iteration | | | | |
+| Iteration review / demo | Per iteration | | | | |
+| Retrospective | Per iteration | | | | |
+| Backlog refinement | | | | | |
+
+An iteration is a sprint or a pp-core phase, as Session 11 chose. Write `—` in **Cadence** for a meeting the team does not hold.
 
 **Support Model**
 
@@ -85,12 +88,12 @@
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |

package/pp-core/workflows/discovery-sprint/sessions/13-wrap-up.md

@@ -68,7 +68,7 @@ Before facilitating any topics, execute the **Session 13: Cross-Reference Protoc
 
 | ID | Item | Source Session | Priority (H/M/L) | Must Resolve Before Build? | Owner | Target Date | Status |
 |----|------|---------------|-------------------|---------------------------|-------|-------------|--------|
-| OI-1 | | | | | | | |
+| OI-01 | | | | | | | |
 
 **Cross-Reference Analysis Results**
 
@@ -103,13 +103,13 @@ Before facilitating any topics, execute the **Session 13: Cross-Reference Protoc
 
 **Key Decisions**
 
-| # | Decision | Rationale | Owner | Date |
+| ID | Decision | Rationale | Owner | Date |
 |---|----------|-----------|-------|------|
 | | | | | |
 
 **Action Items**
 
-| # | Action | Owner | Due Date | Status |
+| ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |
 
@@ -162,6 +162,8 @@ For each group: read all session files AND `.planning/discovery/_context.md`. Cr
 - [ ] **Test strategy:** S9 covers all S3 requirements and S5 components
 - [ ] **Timeline and capacity:** S11 roadmap feasible given S12 team and S9 test needs
 - [ ] **Action items:** No duplicates or contradictions in `_progress.md`
+- [ ] **Back-amends:** every decision that changes an earlier record has `→ amended by D-<ss>-<n>` at the original line (Flow 2 Step 6)
+- [ ] **Mid-sprint findings:** every finding `session-08.md` **Mid-Sprint Cross-Reference** left open is fixed or deferred again here
 
 #### 0d. Present Findings
 

package/pp-core/workflows/discovery-sprint/templates/context-template.md

@@ -28,6 +28,12 @@ _Populated after Session 1 completion_
 ### Stakeholders
 <!-- Key stakeholder list with roles -->
 
+### Approval Routes
+<!-- Who approves scope, budget, architecture and security deviations, go-live -->
+
+### Platform and Team Shape
+<!-- Mandated platform (D-01-n) or "open"; team shape for the build -->
+
 ### Discovery Sprint Scope
 **In Scope:**
 -
@@ -218,13 +224,13 @@ _Populated after Session 11 completion_
 <!-- Phase breakdown -->
 
 ### Timeline
-<!-- Sprint cadence and key dates -->
+<!-- Iteration model (sprints or pp-core phases) and key dates -->
 
 ### MVP Scope (Confirmed)
 <!-- Must-have vs nice-to-have -->
 
 ### Build Order
-<!-- Sprint-by-sprint plan -->
+<!-- Iteration-by-iteration plan -->
 
 ### Key Milestones
 <!-- Milestone dates -->
@@ -244,7 +250,7 @@ _Populated after Session 12 completion_
 <!-- Governance framework summary -->
 
 ### Ceremonies
-<!-- Sprint cadence and meetings -->
+<!-- Iteration cadence and the meetings held -->
 
 ### Support Model
 <!-- Post-go-live support approach -->