@pareto4/pp-core 1.19.0 → 1.21.0

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

@@ -5,43 +5,42 @@
 
 ### Session 6: Security & Compliance Setup
 
-**Goal:** Define data classification, establish the compliance framework, determine encryption and network access strategies, design audit logging, and set availability SLAs.
+**Goal:** Define data classification, establish the compliance framework, determine encryption and network access strategies, design audit logging, and set availability SLAs — against the client's security and compliance standards.
+
+**Standards first.** Where a document this session's `## Vault Context` record names already fixes a classification scheme, a compliance obligation, an encryption, key-management, network, logging or availability rule, do not ask the open question: present the vault's answer — "the vault fixes X `[vault: <path>]` — does this product deviate, and why?" — and record the standard in the **Standards Applied** row for that area. A deviation is one `DEV-<nn>` row of `.planning/discovery/_deviations.md` (template and grammar: `${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-standards.md`; create the file on first need) plus a Key Decisions row `D-06-<n>`, both cited in the Standards Applied row; never recommend an alternative the standards rule out. An area no standard covers reads `not in vault` and keeps its question open. With no vault bound, every question below stays open-ended.
 
 **What We Cover:**
 
 1. **Data classification**
    *Why it matters: classification drives every encryption, retention, and access decision below. Skip when: never — even a "no sensitive data" answer is a data point worth recording.*
-   - What categories of data will the system process (public, internal, confidential, restricted)?
+   - Classification scheme: the vault's compliance standard fixes the levels when bound — the sprint uses them as they are. Otherwise: which scheme does the client follow (public, internal, confidential, restricted)?
+   - Which level does each entity of `_entities.md` get?
    - Does the system handle PII (personally identifiable information)?
    - Does the system handle financial, health, or other regulated data?
-   - What data classification scheme does the client follow?
 
 2. **Compliance framework**
    *Why it matters: named frameworks set hard requirements the architecture and audit design must satisfy. Skip when: internal tool with no external data subjects or regulatory exposure.*
-   - What regulatory frameworks apply (GDPR, SOC 2, ISO 27001, HIPAA, PCI-DSS)? [needs-business-input]
+   - Regulatory frameworks: the vault's compliance standard names the ones the client is bound to when bound — which apply to this product beyond them? Otherwise: GDPR, SOC 2, ISO 27001, HIPAA, PCI-DSS? [needs-business-input]
    - Are there industry-specific compliance requirements? [needs-business-input]
    - What is the current compliance posture and certification status?
    - 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 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)?
+   - Encryption at rest and in transit: the vault's security standard fixes both when bound — does this product deviate, and why? Otherwise: AES-256, TDE; TLS 1.2+, mTLS?
+   - Key management: the vault fixes the key service when bound — does this product deviate? Otherwise: HSM, KMS, Vault?
    - Are there requirements for field-level or application-level encryption?
 
 4. **Network and access security**
    *Why it matters: perimeter decisions shape the infrastructure architecture built in Session 10. Skip when: internal-only tool behind an existing corporate VPN with no new exposure.*
-   - What network segmentation is required (VPCs, subnets, firewalls)?
-   - What perimeter security requirements exist (WAF, DDoS protection)?
+   - Network segmentation and perimeter: the vault's governance standard fixes them when bound — does this product deviate? Otherwise: VPCs, subnets, firewalls; WAF, DDoS protection?
    - How will IP whitelisting or geo-blocking be handled?
    - What VPN or private connectivity requirements exist?
 
 5. **Audit logging and monitoring**
    *Why it matters: logging requirements feed Session 10's monitoring/alerting design. Skip when: no compliance or audit obligation drives logging beyond application defaults.*
-   - What events must be logged for audit purposes (login, data access, admin actions)?
-   - What is the log retention period?
-   - What SIEM or security monitoring tool will be used?
+   - Audit events and retention: the vault's security standard fixes the audit trail when bound — does this product deviate, and what does it add? Otherwise: which events (login, data access, admin actions) and how long?
+   - Security monitoring: the vault fixes the platform's SIEM when bound — does this product deviate? Otherwise: which tool?
    - How will security incidents be detected and escalated?
 
 6. **Availability and SLAs**
@@ -53,12 +52,28 @@
 
 **Notes Template:**
 
+**Standards Applied**
+
+| Area | Standard | Deviation | Decision |
+|------|----------|-----------|----------|
+| Data classification scheme | | | |
+| Compliance frameworks | | | |
+| Encryption at rest and in transit | | | |
+| Secrets and key management | | | |
+| Network and perimeter | | | |
+| Audit logging and retention | | | |
+| Backup, availability and DR | | | |
+
+**Standard** is the governing document's `[vault: <rel path>]` citation, or `not in vault`. **Deviation** is `none` or the `DEV-<nn>` of the `_deviations.md` row. **Decision** is `—` or the `D-06-<n>` that records the deviation or the decision taken for an uncovered area (`references/discovery-standards.md`).
+
 **Data Classification Matrix**
 
 | Data Entity | Classification | PII | Regulated | Encryption Required | Retention Period | Notes |
 |-------------|----------------|-----|-----------|--------------------|--------------------|-------|
 | | | | | | | |
 
+**Data Entity** is an entity of `.planning/discovery/_entities.md`, spelled the same; **Classification** is one of the vault's four levels — `Public`, `Internal`, `Confidential`, `Restricted` (`[vault: security/compliance.md]` when bound). Copy every row's Classification and Retention Period into that entity's `_entities.md` row (its `—` cells from Sessions 2–5), then run `pp_run query discovery.entity-check` — exit 0, or fix the rows it names. The data model is what the build and the charter § 8 read; this matrix keeps the PII, regulation and encryption facts beside it.
+
 **Compliance Requirements Register**
 
 | ID | Framework | Requirement | Applicability | Current Status | Gap | Action Required |

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

@@ -5,23 +5,27 @@
 
 ### Session 7: User & Identity Management
 
-**Goal:** Design the RBAC model, plan Identity Provider (IdP) integration, define the user lifecycle, and map authentication and authorization flows.
+**Goal:** Record the roles and what each may do in `_roles.md`, plan Identity Provider (IdP) integration, define the user lifecycle, and map authentication and authorization flows — against the client's identity and security standards.
+
+**Inputs — read before topic 1.** `session-02.md` **User Personas**; `.planning/discovery/_processes.md` § Steps (the `Actor` column — every role is an actor the process already has); `.planning/discovery/_entities.md` § Entities; `.planning/discovery/_screens.md` § Screens; `_requirements.md`.
+
+**Standards first.** Where a document this session's `## Vault Context` record names already fixes the identity provider, the authentication protocol, the authorization model, role recovery, session or token rules, do not ask the open question: present the vault's answer — "the vault fixes X `[vault: <path>]` — does this product deviate, and why?" — and record the standard in the **Standards Applied** row for that area. A deviation is one `DEV-<nn>` row of `.planning/discovery/_deviations.md` (template and grammar: `${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-standards.md`; create the file on first need) plus a Key Decisions row `D-07-<n>`, both cited in the Standards Applied row; never recommend an alternative the standards rule out. An area no standard covers reads `not in vault` and keeps its question open. With no vault bound, every question below stays open-ended.
 
 **What We Cover:**
 
-1. **RBAC model design**
-   *Why it matters: the RBAC matrix is what Session 8/9 test authorization against. Skip when: a single-role application with no differentiated access.*
-   - What roles exist in the system (admin, manager, user, viewer, external partner)?
-   - What permissions does each role require (CRUD on which entities)?
-   - Are there hierarchical roles or role inheritance?
-   - Do permissions vary by data scope (e.g., a manager sees only their department's data)?
+1. **Roles and permissions**
+   *Why it matters: `_roles.md` is what Sessions 8/9 test authorization against and what the build's auth phase and forbidden-path tests read. Skip when: a single-role application with no differentiated access — record the one role.*
+   - Propose the roles from the actors the Session 3 step matrices name and the Session 2 personas; the client confirms, merges or renames. A role is a persona, a step-matrix actor or `System`, spelled the same — `roles-check` refuses a role nobody plays.
+   - For each role and entity it touches: which operations (`create`, `read`, `update`, `delete`, `assign`, `export`, …), under which condition (own team only, assignee or lead), realising which requirements? One `## Permissions` row per role and entity.
+   - What is each role's data scope, and how is the role recovered when its last holder leaves or is locked out? The vault's security standard fixes role recovery when bound — does this product deviate?
    - How will role assignment and delegation work?
+   - Write `.planning/discovery/_roles.md` § Roles and § Permissions — create the file from the template in `${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-access.md` on first need — then run `pp_run query discovery.roles-check` — exit 0, or fix the rows it names.
 
 2. **Identity Provider (IdP) integration**
    *Why it matters: IdP choice determines auth flow complexity and Session 10 infra dependencies. Skip when: the client mandates a single existing IdP with no alternatives to weigh.*
-   - Does the client use an existing IdP (Azure AD, Okta, Auth0, Keycloak)?
+   - Identity provider: the vault's security standard fixes it when bound — does this product deviate, and why? Otherwise: Azure AD / Entra ID, Okta, Auth0, Keycloak?
    - Will the solution federate with the existing IdP or manage its own user store?
-   - Is SSO (Single Sign-On) required? Which protocol (SAML 2.0, OIDC)?
+   - SSO and protocol: the vault fixes them when bound — does this product deviate? Otherwise: SAML 2.0 or OIDC?
    - Are there multiple IdPs for different user populations (internal vs. external)?
 
 3. **User lifecycle management**
@@ -33,28 +37,42 @@
 
 4. **Authentication flows**
    *Why it matters: authentication method choice affects UX (Session 4) and compliance (Session 6). Skip when: a platform-standard SSO is mandatory with no other options.*
-   - What authentication methods are supported (password, MFA, biometric, certificate)?
-   - Is MFA mandatory for all users or specific roles?
-   - What is the session management strategy (token lifetime, refresh, idle timeout)?
-   - How is password policy enforced (complexity, rotation, history)?
+   - Authentication methods and MFA: the vault's security standard fixes them when bound — does this product deviate? Otherwise: password, MFA, biometric, certificate; MFA for whom?
+   - Session and tokens: the vault fixes lifetimes, refresh and revocation when bound — does this product deviate? Otherwise: token lifetime, refresh, idle timeout?
+   - How is password policy enforced (complexity, rotation, history) — when the IdP does not own it?
+   - Which role may open which screen? Write one `## Screens` row per role and `SCR-nn` into `_roles.md` from `_screens.md`; the forbidden-path tests are written from these rows.
 
 5. **Authorization patterns**
    *Why it matters: fine-grained authorization design directly shapes API contract work in Session 8. Skip when: RBAC alone (Topic 1) is sufficient with no attribute-based rules needed.*
-   - How are fine-grained permissions evaluated (attribute-based, policy-based)?
+   - How are fine-grained permissions evaluated (attribute-based, policy-based)? The `Condition` column of `_roles.md` § Permissions carries the answer per permission.
    - Are there data-level access controls (row-level security, field masking)?
-   - How are API endpoints protected (OAuth 2.0 scopes, API keys)?
-   - What is the approach to service-to-service authentication?
+   - API protection: the vault's API rules fix auth per operation when bound — does this product deviate? Otherwise: OAuth 2.0 scopes, API keys?
+   - Service-to-service authentication: the vault fixes it when bound — does this product deviate? Otherwise: which approach?
 
 **Notes Template:**
 
-**RBAC Matrix**
+> **Artifact this session creates (first run only):** copy the bootstrap template verbatim, replacing `[PROJECT_NAME]` — `.planning/discovery/_roles.md` from `${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-access.md`. It is the canonical access model; the table below summarises it and is never the place a fact is first written.
+
+**Standards Applied**
+
+| Area | Standard | Deviation | Decision |
+|------|----------|-----------|----------|
+| Identity provider and SSO | | | |
+| Authentication protocol and MFA | | | |
+| Authorization model | | | |
+| Role recovery | | | |
+| Session and token handling | | | |
+| Service-to-service authentication | | | |
+
+**Standard** is the governing document's `[vault: <rel path>]` citation, or `not in vault`. **Deviation** is `none` or the `DEV-<nn>` of the `_deviations.md` row. **Decision** is `—` or the `D-07-<n>` that records the deviation or the decision taken for an uncovered area (`references/discovery-standards.md`).
+
+**Roles**
+
+The canonical rows live in `.planning/discovery/_roles.md` — § Roles (`Role | Description | Scope | Recovery path | Source`), § Permissions (one row per role and entity, operations as a list, condition, requirements) and § Screens (`Role | Screen`). This table is a reading summary — one row per role, never the place a fact is first written:
 
-| Role | Entity 1 (C/R/U/D) | Entity 2 (C/R/U/D) | Entity 3 (C/R/U/D) | Data Scope | Notes |
-|------|---------------------|---------------------|---------------------|------------|-------|
-| Admin | | | | | |
-| Manager | | | | | |
-| User | | | | | |
-| Viewer | | | | | |
+| Role | Permissions in one line | Data scope |
+|------|-------------------------|------------|
+| | | |
 
 **IdP Integration Design**
 

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

@@ -5,64 +5,85 @@
 
 ### Session 8: Integration & Interface Design
 
-**Goal:** Detail external system integrations, define interface patterns, agree on data exchange formats, and establish error handling and retry strategies.
+**Goal:** Complete the interfaces Session 5 registered in `_integrations.md` — protocols, contracts, error handling, idempotency — against the client's integration standards, and design the data migration and cut-over in `_migration.md`.
+
+**Inputs — read before topic 1.** `.planning/discovery/_integrations.md` § Interfaces (the `IF-` rows Session 5 minted); `.planning/discovery/_processes.md` § Steps (the `Integration` cells); `.planning/discovery/_migration.md` when Session 2 created it; `session-05.md` **Component Inventory**; `_requirements.md`.
+
+**Standards first.** Where a document this session's `## Vault Context` record names already fixes an integration pattern, API exposure, contract and versioning rules, error handling, idempotency or monitoring, do not ask the open question: present the vault's answer — "the vault fixes X `[vault: <path>]` — does this product deviate, and why?" — and record the standard in the **Standards Applied** row for that area. A deviation is one `DEV-<nn>` row of `.planning/discovery/_deviations.md` (template and grammar: `${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-standards.md`; create the file on first need) plus a Key Decisions row `D-08-<n>`, both cited in the Standards Applied row; never recommend an alternative the standards rule out. An area no standard covers reads `not in vault` and keeps its question open. With no vault bound, every question below stays open-ended.
 
 **What We Cover:**
 
 1. **External systems inventory**
    *Why it matters: this is the master list every interface pattern, error strategy, and SLA below is defined against. Skip when: no external integrations exist for this solution.*
-   - What are all the systems the solution must integrate with?
+   - Walk the `IF-` rows of `_integrations.md` § Interfaces: is the list complete, is every step matrix `Integration` cell linked to one? Add a row for a system Session 5 missed — never a second numbering.
    - For each system, who is the technical owner and what is their availability?
    - What is the maturity of each system's API (well-documented, legacy, in development)?
    - Are there licensing or access constraints for any system?
 
 2. **Interface patterns and protocols**
    *Why it matters: protocol choices determine what the dev team must build and test. Skip when: a single well-established pattern (e.g. REST) already applies to every integration.*
-   - What integration patterns are appropriate (request/reply, publish/subscribe, file transfer, webhook)?
-   - What protocols will be used (REST, SOAP, gRPC, SFTP, AMQP)?
-   - Will an integration middleware or ESB be used?
-   - How will API versioning be handled?
+   - Pattern and protocol per interface: the vault's integration and inter-service rules fix them when bound (sync versus async, API exposure) — does this product deviate, and why? Otherwise: request/reply, publish/subscribe, file transfer, webhook; REST, SOAP, gRPC, SFTP, AMQP? Fill `Protocol` on the `IF-` row.
+   - Middleware: the vault fixes API exposure through a gateway when bound — does this product deviate? Otherwise: integration middleware or ESB?
+   - API versioning: the vault's API rules fix it when bound — does this product deviate? Otherwise: which scheme?
 
 3. **Data exchange formats and contracts**
    *Why it matters: format/contract decisions prevent breaking changes once integration work begins. Skip when: contracts already exist and are stable (e.g. a documented OpenAPI spec).*
-   - What data formats will be used (JSON, XML, CSV, Avro, Protobuf)?
-   - How will data contracts be defined and managed (OpenAPI, JSON Schema, WSDL)?
-   - What data transformation or mapping is required between systems?
+   - Format per interface: the vault's API rules fix it when bound — does this product deviate? Otherwise: JSON, XML, CSV, Avro, Protobuf? Fill `Format` on the `IF-` row.
+   - Contract definition: the vault fixes OpenAPI when bound — does this product deviate? Otherwise: OpenAPI, JSON Schema, WSDL?
+   - Which fields does each interface exchange, with which type, mapping and validation? One `## Contract` row per field in `_integrations.md`.
    - How will schema evolution and backward compatibility be handled?
 
 4. **Error handling and retry strategy**
    *Why it matters: undefined retry/failure behavior becomes a production incident during go-live. Skip when: never — always define at least a default policy.*
-   - How should integration failures be handled (retry, dead-letter queue, manual intervention)?
+   - Failure handling: the vault's integration rules fix failures and monitoring when bound — does this product deviate? Otherwise: retry, dead-letter queue, manual intervention?
    - What retry policies apply (exponential backoff, max retries, circuit breaker)?
+   - Which failures can each interface meet, and how is each handled, retried, dead-lettered and alerted? One `## Errors` row per failure in `_integrations.md`.
    - How will failed messages be monitored and reprocessed?
-   - What alerting is needed for integration failures?
 
 5. **Data synchronization and consistency**
    *Why it matters: the consistency model choice affects correctness guarantees the QA plan (Session 9) must test. Skip when: all integrations are synchronous request/reply with no async sync needed.*
    - What is the consistency model (eventual consistency, strong consistency)?
-   - How will data conflicts between systems be resolved?
-   - What is the approach to idempotency for critical operations?
+   - How will data conflicts between systems be resolved? The vault's integration rules fix the source of truth and business keys when bound — does this product deviate?
+   - Idempotency per interface: the vault's API rules fix it when bound — does this product deviate? Otherwise: which key and window? Fill `Idempotency` on the `IF-` row, then run `pp_run query discovery.integrations-check --require-cited` — exit 0, or fix the rows it names.
    - Are there batch synchronization requirements (daily feeds, nightly reconciliation)?
 
+6. **Migration and cut-over**
+   *Why it matters: Session 2 named the data that moves; without a mapping, a cut-over strategy and a reconciliation the migration phase cannot be planned or proven. Skip when: `_migration.md` does not exist — nothing moves.*
+   - For each `MG-` row of `.planning/discovery/_migration.md`: how does each source field map onto the target entity, and which values need cleaning or translation?
+   - Cut-over: big bang, parallel run or phased per entity? When does the source system go read-only, and what is the rollback?
+   - Reconciliation: which counts, totals and spot checks prove the move, and who signs it off?
+   - Which requirements does each row realise? Back-fill `Requirements`, fill `Mapping`, `Cut-over` and `Reconciliation`, then run `pp_run query discovery.migration-check --require-cited` — exit 0, or fix the rows it names.
+
 **Notes Template:**
 
+**Standards Applied**
+
+| Area | Standard | Deviation | Decision |
+|------|----------|-----------|----------|
+| Integration pattern (sync / async) | | | |
+| API exposure and gateway | | | |
+| Contracts and versioning | | | |
+| Error handling and retries | | | |
+| Idempotency | | | |
+| Integration monitoring | | | |
+
+**Standard** is the governing document's `[vault: <rel path>]` citation, or `not in vault`. **Deviation** is `none` or the `DEV-<nn>` of the `_deviations.md` row. **Decision** is `—` or the `D-08-<n>` that records the deviation or the decision taken for an uncovered area (`references/discovery-standards.md`).
+
 **Integration Design Register**
 
-| ID | External System | Interface Name | Direction | Pattern | Protocol | Data Format | Frequency | SLA | Owner |
-|----|----------------|---------------|-----------|---------|----------|-------------|-----------|-----|-------|
-| IF-01 | | | | | | | | | |
+The canonical rows live in `.planning/discovery/_integrations.md` § Interfaces (`IF-<nn>` — `references/discovery-integrations.md`), completed in this session. This table is a reading summary — one row per interface, never the place a fact is first written:
+
+| Interface ID | Interface name | What the register row does not hold (frequency, SLA, versioning) |
+|--------------|----------------|-------------------------------------------------------------------|
+| IF-01 | | |
 
 **Data Transformation Map**
 
-| Interface | Source Field | Target Field | Transformation Rule | Validation | Notes |
-|-----------|------------|-------------|---------------------|------------|-------|
-| IF-01 | | | | | |
+The field-level contract lives in `.planning/discovery/_integrations.md` § Contract (`Interface | Field | Type | Required | Mapping | Validation`). Record here only what the contract table cannot hold — schema evolution, compatibility rules, the contract artifact's location (OpenAPI file, schema registry).
 
 **Error Handling Strategy**
 
-| Interface | Failure Scenario | Handling Pattern | Retry Policy | Dead Letter | Alert | Escalation |
-|-----------|-----------------|-----------------|-------------|-------------|-------|------------|
-| IF-01 | | | | | | |
+The failures live in `.planning/discovery/_integrations.md` § Errors (`Interface | Failure | Handling | Retry | Dead letter | Alert`). Record here only the escalation path and the reprocessing procedure the table cannot hold.
 
 **Data Synchronization Approach**
 
@@ -70,6 +91,10 @@
 |-------------|-------------|--------------|-------------|-----------|--------------------|-----------------|
 | | | | | | | |
 
+**Migration and Cut-over**
+
+The canonical rows live in `.planning/discovery/_migration.md` § Migration (`MG-<nn>` — `references/discovery-integrations.md` § `_migration.md`), completed in topic 6. Record here the cut-over timeline and who signs the reconciliation; write `None identified in Discovery.` when nothing moves.
+
 **Key Decisions**
 
 | ID | Decision | Rationale | Owner | Date |
@@ -92,4 +117,6 @@ Filled by the Closing Step below: the findings count by severity, each fix appli
 
 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.
+3. Run the artifact checks: `pp_run query discovery.entity-check`, `pp_run query discovery.process-check`, `pp_run query discovery.rules-check`, `pp_run query discovery.roles-check`, `pp_run query discovery.integrations-check`, `pp_run query discovery.migration-check` and `pp_run query discovery.deviations-check`. Each exits 0 or names the rows to fix — fix them now, in the artifact, before Sessions 9–12 build on them. An artifact that does not exist exits 0 by itself; the strict flags (`--require-cited`, `--require-approved`) belong to the handoff, not here.
+4. Record the results in this session's **Mid-Sprint Cross-Reference** notes. Session 13 re-checks the findings left open here.
+5. Run `pp_run query discovery.session-check --all` over Sessions 1–8: every Notes Template section present once with a data row, prose or `None identified in Discovery.` (`references/discovery-session-output.md`). Non-zero → fill the sections it names in their session file, now, before Sessions 9–12 read them.

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

@@ -5,35 +5,35 @@
 
 ### Session 9: Quality Assurance & Testing Strategy
 
-**Goal:** Define the overall test strategy, select testing tooling, plan test environments, establish quality gates, and design the UAT approach.
+**Goal:** Define the overall test strategy, confirm the testing tooling and quality gates against the client's standards, plan test environments, and design the UAT approach.
+
+**Standards first.** Where a document this session's `## Vault Context` record names already fixes a test level, a coverage bar, a tool, the environments, a merge or release gate, do not ask the open question: present the vault's answer — "the vault fixes X `[vault: <path>]` — does this product deviate, and why?" — and record the standard in the **Standards Applied** row for that area. A deviation is one `DEV-<nn>` row of `.planning/discovery/_deviations.md` (template and grammar: `${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-standards.md`; create the file on first need) plus a Key Decisions row `D-09-<n>`, both cited in the Standards Applied row; never recommend an alternative the standards rule out. An area no standard covers reads `not in vault` and keeps its question open. With no vault bound, every question below stays open-ended.
 
 **What We Cover:**
 
 1. **Test strategy and approach**
    *Why it matters: sets the coverage bar every EPIC (Session 3) gets built and verified against. Skip when: the client has an existing enterprise test strategy this project simply inherits.*
-   - What testing levels will be applied (unit, integration, system, E2E, performance, security)?
-   - What is the expected test coverage target for each level?
+   - Test levels and coverage: the vault's coding standards and quality gates fix them when bound — does this product deviate, and why? Otherwise: unit, integration, system, E2E, performance, security, and which target per level?
    - How will TDD or BDD be applied?
    - What is the approach to regression testing?
    - How will non-functional testing be addressed (load, stress, soak, accessibility)?
 
 2. **Testing tools and frameworks**
-   *Why it matters: tooling choice affects CI/CD pipeline design in Session 10. Skip when: tooling is fixed by an existing platform standard.*
-   - What unit testing frameworks will be used (Jest, xUnit, JUnit, PyTest)?
-   - What integration and E2E testing tools are preferred (Cypress, Playwright, Selenium)?
-   - What performance testing tools will be used (k6, JMeter, Gatling)?
-   - What security testing tools will be applied (OWASP ZAP, Snyk, SonarQube)?
+   *Why it matters: tooling choice affects CI/CD pipeline design in Session 10. Skip when: the vault's stack and quality gates fix every tool and the client deviates nowhere — record the rows and move on.*
+   - Unit and E2E tooling: the vault's language standards fix the frameworks when bound — does this product deviate? Otherwise: Jest, xUnit, JUnit, PyTest; Cypress, Playwright, Selenium?
+   - Performance tooling: the vault's sizing and release rules fix the performance test when bound — does this product deviate? Otherwise: k6, JMeter, Gatling?
+   - Security scanning: the vault's quality gates fix the scanners when bound — does this product deviate, and with which substitute? Otherwise: OWASP ZAP, Snyk, SonarQube?
 
 3. **Test environments**
    *Why it matters: environment count and refresh cadence feed Session 10's infrastructure sizing. Skip when: a single shared environment is acceptable for this scale of project.*
-   - How many test environments are needed (dev, test, staging, pre-prod)?
+   - How many test environments are needed? When a vault is bound, start from the environments its naming standard defines and record only deviations; otherwise choose (dev, test, staging, pre-prod).
    - How will test data be provisioned (synthetic data, anonymized production data, seed scripts)?
    - How will environments be kept in sync with production?
 
 4. **Quality gates and CI/CD integration**
    *Why it matters: gates here become the literal pass/fail criteria in Session 10's deployment pipeline. Skip when: never — always define at least a minimal merge gate.*
-   - What quality gates must pass before code is merged (code review, linting, unit tests, coverage threshold)?
-   - What quality gates must pass before a release is promoted?
+   - Merge gates: the vault's quality gates fix them when bound — does this product deviate, and why? Otherwise: code review, linting, unit tests, coverage threshold?
+   - Release gates: the vault's release rules fix them when bound — does this product deviate? Otherwise: what must pass before a release is promoted?
    - How will automated testing be integrated into the CI/CD pipeline?
 
 5. **UAT approach**
@@ -45,6 +45,19 @@
 
 **Notes Template:**
 
+**Standards Applied**
+
+| Area | Standard | Deviation | Decision |
+|------|----------|-----------|----------|
+| Test levels and coverage | | | |
+| Test tooling | | | |
+| Environments | | | |
+| Merge gates | | | |
+| Release gates | | | |
+| UAT and sign-off | | | |
+
+**Standard** is the governing document's `[vault: <rel path>]` citation, or `not in vault`. **Deviation** is `none` or the `DEV-<nn>` of the `_deviations.md` row. **Decision** is `—` or the `D-09-<n>` that records the deviation or the decision taken for an uncovered area (`references/discovery-standards.md`).
+
 **Test Strategy Matrix**
 
 | Test Level | Scope | Coverage Target | Automation Level | Tools | Responsible | When Executed |
@@ -68,6 +81,8 @@
 
 **Test Environment Plan**
 
+> **Environments:** when the bound vault names the environments (its naming standard, cited `[vault: <path>]` in this session's record), the rows below carry those names, in the vault's promotion order, and no others — an extra or renamed environment is a Key Decisions row `D-09-<n>`. The preset rows stand only when no vault is bound.
+
 | Environment | Purpose | Data Strategy | Refresh Cadence | Access | Infrastructure | Owner |
 |-------------|---------|---------------|-----------------|--------|---------------|-------|
 | Dev | | | | | | |

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

@@ -5,7 +5,9 @@
 
 ### Session 10: Infrastructure & Deployment Readiness
 
-**Goal:** Define the cloud or hosting strategy, plan the deployment approach, establish monitoring and alerting, determine backup and disaster recovery procedures, and assess go-live readiness criteria.
+**Goal:** Confirm the hosting, deployment, monitoring and recovery approach against the client's platform standards, record the deviations, and assess go-live readiness criteria.
+
+**Standards first.** Where a document this session's `## Vault Context` record names already fixes the hosting platform, the pipeline, infrastructure as code, naming, monitoring, backup or recovery, do not ask the open question: present the vault's answer — "the vault fixes X `[vault: <path>]` — does this product deviate, and why?" — and record the standard in the **Standards Applied** row for that area. A deviation is one `DEV-<nn>` row of `.planning/discovery/_deviations.md` (template and grammar: `${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-standards.md`; create the file on first need) plus a Key Decisions row `D-10-<n>`, both cited in the Standards Applied row; never recommend an alternative the standards rule out. An area no standard covers reads `not in vault` and keeps its question open. With no vault bound, every question below stays open-ended.
 
 **What We Cover:**
 
@@ -19,24 +21,24 @@
 
 2. **Deployment strategy**
    *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 (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 (the platform's managed container or Kubernetes service, Kubernetes on-premises, or none)?
+   - Deployment model: the vault's release rules fix stages and gates when bound — does this product deviate? Otherwise: blue-green, canary, rolling, immutable?
+   - Pipeline structure and tool: the vault's pipeline standard fixes them when bound — does this product deviate? Otherwise: GitHub Actions, GitLab CI, Azure DevOps, Jenkins? Take the platform's pipeline when Session 1 recorded one.
+   - Infrastructure as code: the vault's IaC standard fixes it when bound — does this product deviate? Otherwise: Terraform, Pulumi, CloudFormation?
+   - Resource naming: the vault's naming convention fixes it when bound — record the standard; a name outside it is a deviation.
+   - What is the approach to containerization (the platform's managed container or Kubernetes service, Kubernetes on-premises, or none)? The vault's container rules apply when bound.
 
 3. **Monitoring, logging, and alerting**
    *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)?
+   - Monitoring platform: the vault's default stack fixes observability when bound — does this product deviate? Otherwise: 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?
 
 4. **Backup and disaster recovery**
    *Why it matters: DR strategy directly answers Session 6's RTO/RPO targets with a concrete implementation. Skip when: non-critical internal tool with no formal DR requirement.*
-   - What is the backup strategy (frequency, retention, storage location)?
+   - Backup strategy: the vault's governance and compliance rules fix frequency, retention and location when bound — does this product deviate? Otherwise: which?
    - How will backups be tested and validated?
-   - What is the DR strategy (active-passive, active-active, pilot light)?
+   - DR strategy: the vault fixes the tier per criticality when bound — does this product deviate? Otherwise: active-passive, active-active, pilot light?
    - How often will DR drills be conducted?
 
 5. **Go-live readiness criteria**
@@ -50,6 +52,21 @@
 
 > **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.
 
+**Standards Applied**
+
+| Area | Standard | Deviation | Decision |
+|------|----------|-----------|----------|
+| Hosting platform and landing zone | | | |
+| Environments and promotion | | | |
+| CI/CD pipeline | | | |
+| Infrastructure as code | | | |
+| Resource naming | | | |
+| Monitoring and alerting | | | |
+| Backup and disaster recovery | | | |
+| Sizing and cost | | | |
+
+**Standard** is the governing document's `[vault: <rel path>]` citation, or `not in vault`. **Deviation** is `none` or the `DEV-<nn>` of the `_deviations.md` row. **Decision** is `—` or the `D-10-<n>` that records the deviation or the decision taken for an uncovered area (`references/discovery-standards.md`).
+
 **Infrastructure Architecture**
 
 | Component | Service / Product | Region | Tier / SKU | Redundancy | Est. Monthly Cost | Notes |
@@ -62,6 +79,8 @@
 
 **Deployment Pipeline Design**
 
+> **Environments:** the deploy stages name the environments Session 9's Test Environment Plan recorded — the bound vault's names when one is bound (its naming standard, cited `[vault: <path>]`), one `Deploy to <env>` row per environment in promotion order. The preset rows stand only when no vault is bound.
+
 | Stage | Trigger | Actions | Quality Gate | Environment | Duration |
 |-------|---------|---------|-------------|-------------|----------|
 | Build | | | | | |

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

@@ -29,6 +29,7 @@
    - What are the technical dependencies between EPICs?
    - Are there infrastructure or integration prerequisites that must be ready first?
    - What is the critical path?
+   - Which requirement IDs does each phase realise, and what must be observably true when it is done? The answers are the **Phase Plan** (`.planning/discovery/_phases.md`, Closing Step) — the literal source of ROADMAP.md; every MVP requirement belongs to exactly one phase.
 
 4. **Milestones and release plan**
    *Why it matters: milestone criteria are what stakeholder demos and Session 13's transition plan are scheduled against. Skip when: a single go-live milestone applies with no phased rollout.*
@@ -65,6 +66,10 @@
 
 **Iteration(s)** names sprints (`S1–S2`) or pp-core phases (`Phase 3`), following the iteration model chosen in topic 1.
 
+**Phase Plan** (populated via the Closing Step)
+
+One row per pp-core phase in `.planning/discovery/_phases.md` § Phases — `Phase | Goal | EPICs | Requirement IDs | Success criteria | Depends on`. Record here only what the table cannot hold (why a requirement moved phase, what was debated).
+
 **Milestone Plan**
 
 | Milestone | Target Date | Included EPICs / Features | Entry Criteria | Exit Criteria | Stakeholder Demo? |
@@ -91,3 +96,19 @@
 | ID | Action | Owner | Due Date | Status |
 |---|--------|-------|----------|--------|
 | | | | | |
+
+---
+
+## Session 11: Phase Plan
+
+**Closing Step — Phase Plan.** Run it after Step 7 and before Step 8, every time Session 11 completes, including a redo. The EPIC Build Order says in what order; the Phase Plan says what each phase delivers, by requirement ID, so `/pp-discovery-to-build` copies it into ROADMAP.md verbatim and every build phase can read its discovery rows (`references/discovery-build-consumption.md`).
+
+1. Create `.planning/discovery/_phases.md` from the bootstrap template in `${PP_TOOLS%/bin/pp-tools.cjs}/references/discovery-build-consumption.md` § `_phases.md` when it does not exist.
+2. Write one row per pp-core phase, in build order, following the iteration model from topic 1 (one iteration = one phase when that was chosen; otherwise one phase per EPIC Build Order row, several sprints to a phase being fine). pp-core phases count from 1: a "Phase 0", "Sprint 0" or "Setup" row of this session becomes Phase 1 and every later row shifts by one — record the mapping (`Session 11 phase 0 → pp-core Phase 1`) under **Phase Plan** in the Notes Template so the two numberings never meet unexplained:
+   - **Goal** — one sentence, the phase's deliverable;
+   - **EPICs** — the `E-nn` rows the phase realises, or `—`;
+   - **Requirement IDs** — every `_requirements.md` ID the phase realises: each EPIC's requirements from Session 3, the `N-`/`T-` rows that belong with them; an `MVP` requirement goes in exactly one phase, a `Later` one in none unless the plan reaches it, a `Dropped` one never. A requirement the build order splits across phases ("basic list" now, "filters" later) belongs to the phase where its acceptance criteria are fully met — the earlier phase names the partial work in its Goal, not in this column. A cross-cutting process or validation requirement that every phase exercises belongs to the phase that establishes it. A setup or infrastructure phase that realises no requirement writes `—`;
+   - **Success criteria** — two to five observable statements separated by ` · `, written from the user's seat ("A clerk closes a task and it leaves the list");
+   - **Depends on** — the earlier phase numbers whose output this phase needs, or `—`.
+3. Run `pp_run query discovery.phases-check` — exit 0, or fix the rows it names: `mvp_requirement_unplanned` is an MVP requirement no phase owns, `requirement_in_multiple_phases` a requirement two phases both claim.
+4. Smoke the join: `pp_run query discovery.for-phase 1 --markdown` renders the rows Phase 1 will read. An empty section is a fact to settle now (no step cites those IDs, no screen covers them), not a rendering fault.