@pareto4/pp-core 1.8.2 → 1.9.0

package/pp-core/workflows/discovery-sprint.md

@@ -105,8 +105,8 @@ if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
 
 1. Determine the session file path: `.planning/discovery/session-NN.md` (zero-padded, e.g. `session-03.md`).
 2. If the file does not exist, create it using the session template (see Session Content sections below).
-3. Read `.planning/discovery/_progress.md` (create if absent).
-4. Read `.planning/discovery/_context.md` (create if absent).
+3. Read `.planning/discovery/_progress.md` (create if absent — use the **Bootstrap Templates** section near the end of this workflow for the literal schema).
+4. Read `.planning/discovery/_context.md` (create if absent — use the **Bootstrap Templates** section near the end of this workflow for the literal schema).
 
 ### Step 2: Check Dependencies
 
@@ -143,17 +143,22 @@ For each numbered topic in the session's "What We Cover" section:
 
 1. **Present the topic** conversationally: "Let's talk about [Topic Name]."
 2. **Ask guiding questions** using `AskUserQuestion` (or a plain-text numbered list in text mode).
-3. **Capture into Notes Template:** after discussion, populate the corresponding table or prose section using Edit tool. Save after each topic — do not wait until the end.
-4. **Confirm with user:** summarize what was captured. Ask if anything should be adjusted.
+3. **Offer parking for out-of-competence questions:** if a question is marked `[needs-business-input]`, or the user says they cannot answer a question because it requires business or senior authority (pricing, budget, compliance sign-off, org/security policy, contractual commitment), do NOT press the user to guess and do NOT invent an answer. Instead park it:
+   a. Write `PARKED — needs business/senior input` into that topic's Notes Template section, with the open question captured verbatim underneath (e.g. `> What is the target availability?`).
+   b. Add a row to `.planning/discovery/_progress.md`'s Open Action Items table: `Action` = the parked question (verbatim), `From Session` = this session number, `Owner` = `business/senior`, `Status` = `Open`.
+   c. Increment this session's `Parked` count in `_progress.md`'s Session Progress table row, and increment `Parked questions (open):` in the Summary block by the same amount.
+   d. Treat the parked topic as **not covered** for the Step 7 completeness score — never as answered. Parking never blocks marking the session `Completed`; it only keeps the score honest.
+4. **Capture into Notes Template:** after discussion (or after parking per Step 3), populate the corresponding table or prose section using Edit tool. Save after each topic — do not wait until the end.
+5. **Confirm with user:** summarize what was captured (or parked). Ask if anything should be adjusted.
 
 ### Step 6: Key Decisions and Action Items
 
 Ask: "Any key decisions made?" → populate Key Decisions table.
-Ask: "Any action items to track?" → populate Action Items table and update `_progress.md`.
+Ask: "Any action items to track?" → populate Action Items table and update `_progress.md`. (Parked-topic Action Items rows were already added in Step 5.3b — do not duplicate them here.)
 
 ### Step 7: Complete the Session
 
-1. Update `.planning/discovery/session-NN.md` frontmatter: `status: "Completed"`, `completed_date: "[YYYY-MM-DD]"`, `completeness_score: [N]`. Compute `N = round(100 × topics_covered ÷ total_topics)` for this session — only use 100 when every topic was covered. If topics were skipped (see Edge Cases), the score reflects the proportion actually completed.
+1. Update `.planning/discovery/session-NN.md` frontmatter: `status: "Completed"`, `completed_date: "[YYYY-MM-DD]"`, `completeness_score: [N]`. Compute `N = round(100 × topics_covered ÷ total_topics)` for this session — only use 100 when every topic was covered. If topics were skipped (see Edge Cases) **or parked** (Step 5.3), the score reflects the proportion actually completed — a session with parked items must read honestly below 100%.
 2. Update `.planning/discovery/_progress.md`: set row to Completed with date and score.
 3. Update `.planning/discovery/_context.md`: populate the session's output section with concise summaries.
 
@@ -343,33 +348,39 @@ Then proceed to Step 5 (Facilitate Session 13 topics).
 **What We Cover:**
 
 1. **Project context and background**
+   *Why it matters: grounds every later architecture and scope decision in the actual business problem. Skip when: the client already has a written business case / RFP to hand over verbatim.*
    - What is the business problem or opportunity that initiated this project?
    - What has been tried before? What worked, what did not?
    - Are there existing documents, RFPs, or prior assessments to reference?
 
 2. **Business vision and strategic alignment**
+   *Why it matters: sets the yardstick every later scope and priority tradeoff gets measured against. Skip when: the vision is already documented and stakeholders have signed off.*
    - What does success look like in 6 months? In 12 months?
    - How does this initiative align with the broader organizational strategy?
    - What are the key business drivers (revenue growth, cost reduction, compliance, customer experience)?
 
 3. **Stakeholder identification and roles**
+   *Why it matters: without decision authority mapped, later sessions stall on "who approves this". Skip when: a current stakeholder/RACI register already exists and is accurate.*
    - Who are the decision-makers, subject-matter experts, and end-users?
    - Who has authority to approve scope changes or budget decisions?
    - Are there external parties (vendors, regulators, partners) who need to be involved?
 
 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
    - What is the preferred meeting cadence and format (in-person, remote, hybrid)?
    - How will decisions be documented and communicated?
 
 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.*
    - How do we handle disagreements or competing priorities?
    - What is the escalation path for blockers?
    - What tools will be used for collaboration?
 
 6. **Known constraints and risks**
+   *Why it matters: surfaces hard deadlines and budget limits early so later architecture and roadmap decisions respect them. Skip when: constraints are already fully documented elsewhere and reviewed.*
    - Are there hard deadlines (regulatory, contractual, market)?
-   - What budget constraints exist?
+   - What budget constraints exist? [needs-business-input]
    - Are there technology mandates or restrictions?
 
 **Notes Template:**
@@ -418,6 +429,7 @@ Then proceed to Step 5 (Facilitate Session 13 topics).
 **What We Cover:**
 
 1. **Current business processes**
+   *Why it matters: the To-Be design in Session 3 is built by transforming these processes, not invented from scratch. Skip when: no current process exists (fully greenfield build).*
    - What are the core business processes in scope for this initiative?
    - Can you walk us through each process step-by-step, from trigger to completion?
    - Who is involved at each step and what is their role?
@@ -425,6 +437,7 @@ Then proceed to Step 5 (Facilitate Session 13 topics).
    - Are there seasonal or volume-based variations?
 
 2. **Pain points and inefficiencies**
+   *Why it matters: pain points become the EPICs and priorities validated in Session 3. Skip when: the initiative isn't process-improvement driven (e.g. a pure greenfield product).*
    - Where do processes break down or cause delays?
    - What manual workarounds exist today?
    - What are the most frequent complaints from end-users or customers?
@@ -432,23 +445,27 @@ Then proceed to Step 5 (Facilitate Session 13 topics).
    - What processes are most error-prone?
 
 3. **User personas and stakeholders**
+   *Why it matters: personas anchor every later UX and RBAC decision in real users. Skip when: personas are already documented and validated by the client.*
    - Who are the primary users of the current system(s)?
    - What are their roles, responsibilities, and technical proficiency levels?
    - What are their daily tasks and frequency of system interaction?
    - Are there external users (customers, partners, suppliers)?
 
 4. **Current systems landscape**
+   *Why it matters: identifies systems Session 5/8 must integrate with or replace. Skip when: this is a fully greenfield build with no existing systems.*
    - What applications, tools, and platforms are currently in use?
    - Which systems are the system of record for key data entities?
    - Are there systems scheduled for decommissioning or replacement?
 
 5. **Data flows and information architecture**
+   *Why it matters: existing data flows inform the target data model and Session 5's integration map. Skip when: greenfield build with no legacy data to trace.*
    - What are the key data entities (customer, order, product, invoice)?
    - How does data flow between systems today?
    - Are there batch processes, real-time integrations, or manual transfers?
    - What data quality issues exist?
 
 6. **Regulatory and compliance context**
+   *Why it matters: constraints here carry forward directly into Session 6's compliance framework. Skip when: no regulatory obligations apply to this domain.*
    - Are there regulatory requirements that constrain current processes?
    - What audit trails or reporting obligations exist?
    - Are there data residency or retention requirements?
@@ -509,33 +526,39 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **What We Cover:**
 
 1. **Business objectives and success metrics**
+   *Why it matters: gives the roadmap (Session 11) and go/no-go (Session 13) an objective yardstick. Skip when: objectives were already locked in Session 1's business vision.*
    - What are the measurable business outcomes this initiative must achieve?
    - How will we measure success? What KPIs will be tracked?
    - What is the expected ROI or business case?
    - Are there specific targets (e.g., reduce processing time by 50%)?
 
 2. **MVP scope definition**
+   *Why it matters: the MVP boundary drives Session 11's build order and the go-live target date. Skip when: scope is fixed by contract and non-negotiable.*
    - What is the minimum set of capabilities needed to deliver value?
    - What can be deferred to a later release without jeopardizing the business case?
    - How do we differentiate "must-have" from "nice-to-have"?
-   - What is the target go-live date for MVP?
+   - What is the target go-live date for MVP? [needs-business-input]
 
 3. **EPICs and high-level features** (derived from process decomposition)
+   *Why it matters: EPICs are the units Session 11 sequences into sprints. Skip when: derived directly from Session 2 pain points with no new discussion needed.*
    - What are the major feature areas (EPICs) that compose the solution?
    - How do EPICs relate to the pain points identified in Session 2?
    - What is the relative priority of each EPIC?
 
 4. **User stories and acceptance criteria** (derived from step matrices)
+   *Why it matters: acceptance criteria are what QA (Session 9) and UAT (Session 13) will test against. Skip when: only doing high-level EPIC planning this round, not story-level detail.*
    - For highest-priority EPICs, what are the key user stories?
    - What does "done" look like for each story (acceptance criteria)?
    - Are there edge cases or exception flows to account for?
 
 5. **Functional requirements** (derived from step matrices)
+   *Why it matters: functional requirements are the direct input to architecture (Session 5) and QA planning (Session 9). Skip when: requirements are already captured in a separate BRD to reference.*
    - What specific functions must the system perform?
    - What calculations, transformations, or business logic are required?
    - What reporting or analytics capabilities are needed?
 
 6. **Non-functional requirements**
+   *Why it matters: NFRs drive infrastructure sizing (Session 10) and architecture tradeoffs (Session 5). Skip when: standard defaults apply and the client has no unusual NFR targets.*
    - What are the performance expectations (response time, throughput)?
    - What availability and uptime targets apply (e.g., 99.9%)?
    - What are the scalability requirements (users, data volume, transactions)?
@@ -603,36 +626,42 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **What We Cover:**
 
 1. **Design principles and brand alignment**
+   *Why it matters: sets the aesthetic contract every screen decision below is checked against. Skip when: the client mandates an existing design system to follow verbatim.*
    - What design principles should guide the user experience (simplicity, consistency, accessibility)?
    - Does the client have an existing design system, style guide, or brand guidelines?
    - Are there reference applications or competitors whose UX to emulate or avoid?
    - What is the desired "feel" of the application (professional, playful, minimal, data-dense)?
 
 2. **UX standards and patterns**
+   *Why it matters: locks the component/interaction vocabulary developers will build against. Skip when: reusing an established component library with no new patterns needed.*
    - What UI framework or component library will be used (Material Design, Fluent, custom)?
    - What are the standards for form design, validation feedback, and error messaging?
    - How should loading states, empty states, and error states be handled?
    - What responsive design breakpoints are required (desktop, tablet, mobile)?
 
 3. **Personas refined**
+   *Why it matters: sharpens Session 2's personas with the UX lens that drives screen and navigation decisions. Skip when: Session 2 personas are already UX-complete.*
    - Review and refine personas from Session 2 with a UX lens
    - What are each persona's goals, frustrations, and motivations when using the system?
    - What is their typical device, browser, and context of use?
    - Are there accessibility needs for any personas?
 
 4. **Key screen decisions**
+   *Why it matters: the screen inventory becomes the concrete build backlog for frontend work. Skip when: this is a backend/API-only deliverable with no UI surface.*
    - What are the primary screens/views in the application?
    - What information hierarchy applies to each screen?
    - What are the most critical user tasks and how should they be surfaced?
    - Are there dashboard or analytics views required?
 
 5. **Navigation and information architecture**
+   *Why it matters: navigation depth and model directly shape frontend complexity and dev estimate. Skip when: the application has a single screen or trivial navigation.*
    - What is the primary navigation model (sidebar, top bar, tabs, breadcrumbs)?
    - How many levels of navigation depth are acceptable?
    - How do users move between major sections of the application?
    - What is the approach to contextual help or onboarding?
 
 6. **Content and communication**
+   *Why it matters: tone and messaging patterns prevent inconsistent UX copy across the build. Skip when: content strategy is owned entirely by a separate content team.*
    - What tone of voice should the application use (formal, conversational)?
    - How should notifications and alerts be presented?
    - What is the approach to tooltips, help text, and inline guidance?
@@ -699,12 +728,14 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **What We Cover:**
 
 1. **Target architecture vision**
+   *Why it matters: every downstream technical session (6-10) inherits this architecture style. Skip when: architecture is mandated by an existing platform standard with no choice.*
    - What is the high-level architecture style (monolith, microservices, serverless)?
    - What architectural principles will guide design decisions (loose coupling, event-driven)?
    - What are the key architectural drivers (scalability, maintainability, time-to-market)?
    - Are there existing architectural standards mandated by the client?
 
 2. **Technology stack selection**
+   *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)?
@@ -712,18 +743,21 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
    - What caching strategy applies (Redis, in-memory, CDN)?
 
 3. **Key architectural components**
+   *Why it matters: the component map becomes the C4 container diagram and the build-order dependencies in Session 11. Skip when: a monolith with no meaningful internal component boundaries.*
    - What are the major services or modules in the target architecture?
    - How do components interact (synchronous, asynchronous, event-driven)?
    - What is the API strategy (REST, GraphQL, gRPC)?
    - How is the domain model organized (DDD bounded contexts, service boundaries)?
 
 4. **Integration points**
+   *Why it matters: feeds directly into Session 8's detailed integration design. Skip when: standalone system with zero external integrations.*
    - What external systems must the solution integrate with?
    - What are the integration patterns (API, file transfer, event, database-to-database)?
    - Who owns each integration endpoint?
    - What SLAs exist for external system availability?
 
 5. **Architecture Decision Records (ADRs)**
+   *Why it matters: ADRs are the client-facing artifact a Finaps-style reviewer checks for rationale traceability. Skip when: never — always capture at least the decisions already made.*
    - Document key decisions with context, decision, and consequences
    - What alternatives were considered and why were they rejected?
    - What are the trade-offs of the chosen approach?
@@ -761,6 +795,12 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 |--------|-------|---------|----------|--------------|--------|
 | ADR-01 | | | | | Accepted |
 
+**Domain Model / Entity Register**
+
+| Entity | Key Attributes | Relationships | Owner Module |
+|--------|-----------------|----------------|---------------|
+| | | | |
+
 **Key Decisions**
 
 | # | Decision | Rationale | Owner | Date |
@@ -782,37 +822,43 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **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)?
    - 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**
-   - What regulatory frameworks apply (GDPR, SOC 2, ISO 27001, HIPAA, PCI-DSS)?
-   - Are there industry-specific compliance requirements?
+   *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]
+   - 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 platform standard (GCP KMS) 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)?
    - 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)?
    - 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?
    - How will security incidents be detected and escalated?
 
 6. **Availability and SLAs**
-   - What is the target availability (e.g., 99.9%, 99.95%, 99.99%)?
+   *Why it matters: SLA targets size the infrastructure redundancy built in Session 10. Skip when: internal low-criticality tool with no formal SLA commitment.*
+   - What is the target availability (e.g., 99.9%, 99.95%, 99.99%)? [needs-business-input]
    - What is the RTO (Recovery Time Objective) and RPO (Recovery Point Objective)?
    - What are the defined maintenance windows?
    - What failover and disaster recovery requirements exist?
@@ -879,6 +925,7 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **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?
@@ -886,24 +933,28 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
    - How will role assignment and delegation work?
 
 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)?
    - 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)?
    - Are there multiple IdPs for different user populations (internal vs. external)?
 
 3. **User lifecycle management**
+   *Why it matters: lifecycle gaps here become production security incidents (orphaned accounts). Skip when: the user base is fixed/static with no onboarding or offboarding flow.*
    - How are users provisioned (self-registration, admin-created, directory sync, SCIM)?
    - What is the approval workflow for new user accounts?
    - How are users deprovisioned when they leave or change roles?
    - What happens to data owned by deprovisioned users?
 
 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)?
 
 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)?
    - Are there data-level access controls (row-level security, field masking)?
    - How are API endpoints protected (OAuth 2.0 scopes, API keys)?
@@ -968,30 +1019,35 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **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?
    - 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?
 
 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?
    - 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)?
    - What retry policies apply (exponential backoff, max retries, circuit breaker)?
    - 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?
@@ -1044,6 +1100,7 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **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?
    - How will TDD or BDD be applied?
@@ -1051,22 +1108,26 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
    - 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)?
 
 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 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?
    - How will automated testing be integrated into the CI/CD pipeline?
 
 5. **UAT approach**
+   *Why it matters: UAT sign-off criteria are what Session 13's go/no-go assessment checks against. Skip when: internal tool with no formal business acceptance step.*
    - Who will perform UAT (business users, product owner, dedicated UAT team)?
    - How will UAT scenarios be defined and managed?
    - What constitutes UAT sign-off (criteria, approvers)?
@@ -1144,13 +1205,15 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **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)?
    - 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?
+   - 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.*
    - 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)?
@@ -1158,18 +1221,21 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
    - What is the approach to containerization (GKE or Cloud Run via pareto-platform-gcp; Docker/Kubernetes on-prem; or other cloud options)?
 
 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)?
    - 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)?
    - How will backups be tested and validated?
    - What is the DR strategy (active-passive, active-active, pilot light)?
    - How often will DR drills be conducted?
 
 5. **Go-live readiness criteria**
+   *Why it matters: this checklist is what Session 13's go/no-go assessment is literally scored against. Skip when: never — always define at least a minimal readiness bar.*
    - What must be true before the solution goes to production?
    - What operational runbooks are needed?
    - What is the support handover process?
@@ -1251,29 +1317,34 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **What We Cover:**
 
 1. **Project phases and timeline**
+   *Why it matters: sets the calendar every later delivery-model and support-model decision (Session 12) must fit inside. Skip when: the timeline is fixed by contract with no flexibility to discuss.*
    - 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?
+   - 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)?
 
 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.*
    - Review the MVP scope boundary from Session 3
    - Has anything changed since the business requirements session?
    - Are all stakeholders aligned on what is in MVP vs. deferred?
    - 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.*
    - 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?
    - What is the critical path?
 
 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.*
    - What are the key milestones (alpha, beta, RC, GA)?
    - What functionality is included in each milestone?
    - What is the criteria for progressing from one milestone to the next?
 
 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.*
    - 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?
@@ -1334,33 +1405,38 @@ This session uses the **Session 3: Process-First Protocol** (Steps 5A–5G descr
 **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?
-   - Which roles are filled by the client and which by the delivery partner?
+   - 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)?
    - 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)?
    - 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)?
    - What is the reporting cadence (weekly, bi-weekly)?
    - What metrics will be tracked (velocity, burndown, defect rate, cycle time)?
 
 5. **Support model and transition**
+   *Why it matters: support model design is what Session 13's transition plan hands over to operations. Skip when: no post-go-live support obligation exists (e.g. a one-time internal tool).*
    - What support model will be in place post-go-live (L1, L2, L3)?
    - What is the SLA for incident response and resolution?
    - How will knowledge transfer to the support team be handled?
-   - What is the warranty or hypercare period?
+   - What is the warranty or hypercare period? [needs-business-input]
 
 **Notes Template:**
 
@@ -1426,33 +1502,39 @@ Before facilitating any topics, execute the **Session 13: Cross-Reference Protoc
 **What We Cover:**
 
 1. **Discovery Sprint summary**
+   *Why it matters: this synthesis is what gets handed to the build team as the single source of truth. Skip when: never — always required to close the sprint.*
    - What are the key findings across business, technical, and governance dimensions?
    - Were there any significant surprises or pivots during discovery?
    - Which assumptions were validated and which were invalidated?
    - What issues were identified and resolved by the cross-reference analysis?
 
 2. **Project Definition Document (PDD) review**
+   *Why it matters: this is the client's last chance to catch a scoping or architecture error before build starts. Skip when: never — always required before go/no-go.*
    - Walk through the PDD structure and key sections
    - Are there sections requiring further refinement?
    - Does the client agree with documented scope, architecture, and approach?
 
 3. **Go / No-Go assessment**
+   *Why it matters: this is the literal decision gate that authorizes spend on the build phase. Skip when: never — always required.*
    - Are the business requirements sufficiently clear to begin building?
    - Is the technical architecture validated and feasible?
    - Are there blocking risks or unresolved dependencies?
-   - What is the confidence level for the proposed timeline and budget?
+   - What is the confidence level for the proposed timeline and budget? [needs-business-input]
 
 4. **Open items and parking lot**
+   *Why it matters: unresolved items surfaced here become explicit known-gaps in the handoff, not silent omissions. Skip when: never — always required, even an empty parking lot is worth stating explicitly.*
    - What items remain unresolved from discovery sessions?
    - Which items can be deferred to the build phase without risk?
    - Which items must be resolved before the build phase begins?
 
 5. **Transition plan and next steps**
+   *Why it matters: this is the literal onboarding checklist the build team executes on day one. Skip when: no build phase follows immediately (e.g. discovery was standalone).*
    - What is the proposed start date for the build phase?
    - What team onboarding or environment setup is needed?
    - How will the product backlog be handed over to the development team?
 
 6. **Feedback and lessons learned**
+   *Why it matters: captured lessons improve the next engagement's Discovery Sprint facilitation. Skip when: this was the client's first and only Pareto engagement with no future comparison point.*
    - What worked well during the Discovery Sprint?
    - What could be improved for future engagements?
 
@@ -1552,6 +1634,317 @@ When facilitating sessions, reference prior session outputs from `.planning/disc
 - **Session 3:** ALWAYS use the Process-First Protocol (Steps 5A–5G) — never use the generic topic loop.
 - **Session 13:** ALWAYS run the Cross-Reference Protocol (Step 0) before topic facilitation.
 
+---
+
+## Bootstrap Templates
+
+`/pp-discovery` is self-sufficient — it does not depend on any other skill or command having run first. When `.planning/discovery/_progress.md` or `.planning/discovery/_context.md` is absent (first-ever session on this project — see Flow 2 Step 1), create it verbatim from the schema below. Both paths are fixed under `.planning/discovery/` (T-04-03) — never write to a root-level directory, an absolute path, or a path containing `..`.
+
+**`.planning/discovery/_progress.md`** (Parked-aware schema — D-11):
+
+```markdown
+# Discovery Sprint Progress — [PROJECT_NAME]
+
+**Project:** [PROJECT_NAME]
+**Client:** [CLIENT_NAME]
+**Created:** [today's date]
+**Last Updated:** [today's date]
+**Overall Status:** Not Started
+
+---
+
+## Session Progress
+
+| # | Session | Category | Status | Started | Completed | Score | Parked | Notes |
+|---|---------|----------|--------|---------|-----------|-------|--------|-------|
+| 1 | Discovery Sprint Kick-off | Introduction & Closure | Not Started | | | | 0 | |
+| 2 | Business Process Mapping (As-Is) | Business Functional | Not Started | | | | 0 | |
+| 3 | Business Requirements & Future State (To-Be) | Business Functional | Not Started | | | | 0 | |
+| 4 | UX Design & User Experience Principles | Business Functional | Not Started | | | | 0 | |
+| 5 | Application & Integration Architecture | Technical | Not Started | | | | 0 | |
+| 6 | Security & Compliance Setup | Technical | Not Started | | | | 0 | |
+| 7 | User & Identity Management | Technical | Not Started | | | | 0 | |
+| 8 | Integration & Interface Design | Technical | Not Started | | | | 0 | |
+| 9 | Quality Assurance & Testing Strategy | Technical | Not Started | | | | 0 | |
+| 10 | Infrastructure & Deployment Readiness | Technical | Not Started | | | | 0 | |
+| 11 | Project Roadmap & Release Planning | Governance & Costs | Not Started | | | | 0 | |
+| 12 | Team & Delivery Model Definition | Governance & Costs | Not Started | | | | 0 | |
+| 13 | Discovery Sprint Wrap-up & Next Steps | Introduction & Closure | Not Started | | | | 0 | |
+
+---
+
+## Summary
+
+- **Completed:** 0/13
+- **In Progress:** 0/13
+- **Not Started:** 13/13
+- **Parked questions (open):** 0
+
+---
+
+## Open Action Items
+
+| Action | From Session | Owner | Due Date | Status |
+|--------|-------------|-------|----------|--------|
+| | | | | |
+```
+
+The `Parked` column tracks how many topics in that session were marked `PARKED — needs business/senior input` instead of being answered — increment it whenever a topic is parked, and add a matching row to the `Open Action Items` table (owner: `business/senior`). Decrement that session's `completeness_score` in Step 7 to reflect the parked topic as not-covered. Keep `Parked questions (open):` in the Summary block equal to the sum of the `Parked` column across all sessions, minus any parked items subsequently resolved.
+
+**`.planning/discovery/_context.md`:**
+
+```markdown
+# Cross-Session Context — [PROJECT_NAME]
+
+This file accumulates key outputs from each completed session to provide context for subsequent sessions. It is automatically maintained as sessions are completed.
+
+---
+
+## Session 1: Kick-off Outputs
+_Populated after Session 1 completion_
+
+### Project Context
+<!-- Notes about the rationale and context -->
+
+### Business Vision
+<!-- Business vision summary, KPIs -->
+
+### Stakeholders
+<!-- Key stakeholder list with roles -->
+
+### Discovery Sprint Scope
+**In Scope:**
+-
+
+**Out of Scope:**
+-
+
+---
+
+## Session 2: As-Is Outputs
+_Populated after Session 2 completion_
+
+### Core Processes
+<!-- Current business processes -->
+
+### Pain Points
+<!-- Prioritized pain points -->
+
+### User Personas
+<!-- Key personas and their journeys -->
+
+### Current Systems
+<!-- Systems landscape -->
+
+### Data Flows
+<!-- How information moves today -->
+
+---
+
+## Session 3: To-Be Outputs
+_Populated after Session 3 completion_
+
+### Business Objectives
+<!-- Measurable outcomes and KPIs -->
+
+### MVP Scope
+<!-- What's in/out for MVP -->
+
+### EPICs Summary
+<!-- EPIC registry table -->
+
+### User Stories Summary
+<!-- Story count and distribution -->
+
+### Requirements Summary
+<!-- FR, NFR, BR counts -->
+
+---
+
+## Session 4: UX Design Outputs
+_Populated after Session 4 completion_
+
+### Design Principles
+<!-- Numbered design principles -->
+
+### UX Standards
+<!-- Platform, navigation, language, accessibility -->
+
+### Key Personas (Refined)
+<!-- Persona categories and interaction patterns -->
+
+### Key Screen Decisions
+<!-- Screen layout decisions -->
+
+---
+
+## Session 5: Architecture Outputs
+_Populated after Session 5 completion_
+
+### Target Architecture
+<!-- Platform, architecture style, ownership -->
+
+### Technology Stack
+<!-- Full stack listing -->
+
+### Key Components
+<!-- Module/component list -->
+
+### Integration Points
+<!-- External system integrations -->
+
+### ADRs
+<!-- Architecture Decision Records -->
+
+### Domain Model / Entity Register
+<!-- Entity, key attributes, relationships, owner module -->
+
+---
+
+## Session 6: Security Outputs
+_Populated after Session 6 completion_
+
+### Data Classification
+<!-- Data sensitivity levels -->
+
+### Compliance Framework
+<!-- Standards and regulations -->
+
+### Encryption
+<!-- In-transit, at-rest, key management -->
+
+### Network & Access
+<!-- Network security approach -->
+
+### Audit Logging
+<!-- Logging strategy and retention -->
+
+### Availability
+<!-- SLA targets -->
+
+---
+
+## Session 7: Identity Management Outputs
+_Populated after Session 7 completion_
+
+### RBAC Model
+<!-- Roles and permissions summary -->
+
+### IdP Integration
+<!-- Identity provider details -->
+
+### User Lifecycle
+<!-- Provisioning approach -->
+
+---
+
+## Session 8: Integration Outputs
+_Populated after Session 8 completion_
+
+### External Systems
+<!-- Systems and their interfaces -->
+
+### Interface Patterns
+<!-- Chosen patterns and protocols -->
+
+### Data Exchange
+<!-- Key data flows and formats -->
+
+---
+
+## Session 9: QA Outputs
+_Populated after Session 9 completion_
+
+### Test Strategy
+<!-- Testing approach -->
+
+### Tooling
+<!-- Test management and automation tools -->
+
+### Test Environments
+<!-- Environment list and purposes -->
+
+### Quality Gates
+<!-- Gate definitions -->
+
+### UAT
+<!-- UAT participants, period, criteria -->
+
+---
+
+## Session 10: Infrastructure Outputs
+_Populated after Session 10 completion_
+
+### Infrastructure
+<!-- Cloud/hosting setup -->
+
+### Deployment
+<!-- Deployment strategy -->
+
+### Monitoring
+<!-- Monitoring and alerting approach -->
+
+### Backup & DR
+<!-- Backup and disaster recovery -->
+
+### Go-Live Readiness
+<!-- Readiness checklist status -->
+
+---
+
+## Session 11: Roadmap Outputs
+_Populated after Session 11 completion_
+
+### Project Phases
+<!-- Phase breakdown -->
+
+### Timeline
+<!-- Sprint cadence and key dates -->
+
+### MVP Scope (Confirmed)
+<!-- Must-have vs nice-to-have -->
+
+### Build Order
+<!-- Sprint-by-sprint plan -->
+
+### Key Milestones
+<!-- Milestone dates -->
+
+### Risks
+<!-- Top risks and mitigations -->
+
+---
+
+## Session 12: Delivery Model Outputs
+_Populated after Session 12 completion_
+
+### Team Structure
+<!-- Key roles and people -->
+
+### Governance
+<!-- Governance framework summary -->
+
+### Ceremonies
+<!-- Sprint cadence and meetings -->
+
+### Support Model
+<!-- Post-go-live support approach -->
+
+---
+
+## Session 13: Wrap-up Outputs
+_Populated after Session 13 completion_
+
+### Decision Readiness
+<!-- Go / Conditional Go / No-Go assessment -->
+
+### Open Items
+<!-- Items carried forward -->
+
+### Next Steps
+<!-- Transition plan to execution -->
+```
+
 </process>
 
 <success_criteria>