@pareto4/pp-core 1.11.0 → 1.12.0

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

@@ -0,0 +1,98 @@
+# Session 7 — User & Identity Management
+
+> **Lazy-loaded.** Read from `workflows/discovery-sprint.md` Flow 2 Step 1 when facilitating this session.
+> Holds the session's Goal, vault areas, topics and Notes Template.
+
+### 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.
+
+**Vault areas:** `security/iam.md` + `security/auth-flows.md` — optional: read only when the client vault is present (Flow 2 Step 1); skipped silently otherwise.
+
+**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)?
+   - 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)?
+   - What is the approach to service-to-service authentication?
+
+**Notes Template:**
+
+**RBAC Matrix**
+
+| 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 | | | | | |
+
+**IdP Integration Design**
+
+| Aspect | Decision | Notes |
+|--------|----------|-------|
+| IdP platform | | |
+| Protocol (SAML / OIDC) | | |
+| SSO required | | |
+| User store location | | |
+
+**User Lifecycle Flows**
+
+| Event | Trigger | Process Steps | Approvals Required | Systems Affected | Automated? |
+|-------|---------|--------------|-------------------|-----------------|------------|
+| Provisioning | | | | | |
+| Role change | | | | | |
+| Deprovisioning | | | | | |
+
+**Authentication Configuration**
+
+| Setting | Value | Rationale |
+|---------|-------|-----------|
+| Authentication method | | |
+| MFA required for | | |
+| Session timeout (idle) | | |
+| Token lifetime | | |
+| Password complexity | | |
+
+**Key Decisions**
+
+| # | Decision | Rationale | Owner | Date |
+|---|----------|-----------|-------|------|
+| | | | | |
+
+**Action Items**
+
+| # | Action | Owner | Due Date | Status |
+|---|--------|-------|----------|--------|
+| | | | | |

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

@@ -0,0 +1,85 @@
+# Session 8 — Integration & Interface Design
+
+> **Lazy-loaded.** Read from `workflows/discovery-sprint.md` Flow 2 Step 1 when facilitating this session.
+> Holds the session's Goal, vault areas, topics and Notes Template.
+
+### 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.
+
+**Vault areas:** `architecture/inter-service-communication.md` — optional: read only when the client vault is present (Flow 2 Step 1); skipped silently otherwise.
+
+**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?
+   - Are there batch synchronization requirements (daily feeds, nightly reconciliation)?
+
+**Notes Template:**
+
+**Integration Design Register**
+
+| ID | External System | Interface Name | Direction | Pattern | Protocol | Data Format | Frequency | SLA | Owner |
+|----|----------------|---------------|-----------|---------|----------|-------------|-----------|-----|-------|
+| IF-01 | | | | | | | | | |
+
+**Data Transformation Map**
+
+| Interface | Source Field | Target Field | Transformation Rule | Validation | Notes |
+|-----------|------------|-------------|---------------------|------------|-------|
+| IF-01 | | | | | |
+
+**Error Handling Strategy**
+
+| Interface | Failure Scenario | Handling Pattern | Retry Policy | Dead Letter | Alert | Escalation |
+|-----------|-----------------|-----------------|-------------|-------------|-------|------------|
+| IF-01 | | | | | | |
+
+**Data Synchronization Approach**
+
+| Data Entity | Source System | Target System | Sync Method | Frequency | Conflict Resolution | Idempotency Key |
+|-------------|-------------|--------------|-------------|-----------|--------------------|-----------------|
+| | | | | | | |
+
+**Key Decisions**
+
+| # | Decision | Rationale | Owner | Date |
+|---|----------|-----------|-------|------|
+| | | | | |
+
+**Action Items**
+
+| # | Action | Owner | Due Date | Status |
+|---|--------|-------|----------|--------|
+| | | | | |

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

@@ -0,0 +1,109 @@
+# Session 9 — Quality Assurance & Testing Strategy
+
+> **Lazy-loaded.** Read from `workflows/discovery-sprint.md` Flow 2 Step 1 when facilitating this session.
+> Holds the session's Goal, vault areas, topics and Notes Template.
+
+### 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.
+
+**Vault areas:** `testing/` — optional: read only when the client vault is present (Flow 2 Step 1); skipped silently otherwise.
+
+**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?
+   - 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)?
+
+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)?
+   - How will UAT defects be triaged and prioritized?
+
+**Notes Template:**
+
+**Test Strategy Matrix**
+
+| Test Level | Scope | Coverage Target | Automation Level | Tools | Responsible | When Executed |
+|-----------|-------|-----------------|-----------------|-------|-------------|---------------|
+| Unit | | | | | | |
+| Integration | | | | | | |
+| System / E2E | | | | | | |
+| Performance | | | | | | |
+| Security | | | | | | |
+| Accessibility | | | | | | |
+
+**Testing Toolchain**
+
+| Purpose | Tool | Version | License | Notes |
+|---------|------|---------|---------|-------|
+| Unit testing | | | | |
+| E2E testing | | | | |
+| Performance testing | | | | |
+| Security scanning | | | | |
+| Code quality | | | | |
+
+**Test Environment Plan**
+
+| Environment | Purpose | Data Strategy | Refresh Cadence | Access | Infrastructure | Owner |
+|-------------|---------|---------------|-----------------|--------|---------------|-------|
+| Dev | | | | | | |
+| Test | | | | | | |
+| Staging | | | | | | |
+| Pre-prod | | | | | | |
+
+**Quality Gates**
+
+| Gate | Stage | Criteria | Threshold | Blocking? | Tool |
+|------|-------|----------|-----------|-----------|------|
+| Code review | PR merge | | | Yes | |
+| Unit test pass | PR merge | | | Yes | |
+| Code coverage | PR merge | | | Yes | |
+| Integration tests | Deploy to staging | | | Yes | |
+
+**UAT Process**
+
+| Aspect | Decision | Notes |
+|--------|----------|-------|
+| UAT participants | | |
+| UAT scenario source | | |
+| Sign-off criteria | | |
+| Sign-off approver(s) | | |
+| Defect triage process | | |
+
+**Key Decisions**
+
+| # | Decision | Rationale | Owner | Date |
+|---|----------|-----------|-------|------|
+| | | | | |
+
+**Action Items**
+
+| # | Action | Owner | Due Date | Status |
+|---|--------|-------|----------|--------|
+| | | | | |

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

@@ -0,0 +1,119 @@
+# Session 10 — Infrastructure & Deployment Readiness
+
+> **Lazy-loaded.** Read from `workflows/discovery-sprint.md` Flow 2 Step 1 when facilitating this session.
+> Holds the session's Goal, vault areas, topics and Notes Template.
+
+### 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.
+
+**Vault areas:** `ops/` — optional: read only when the client vault is present (Flow 2 Step 1); skipped silently otherwise.
+
+Session 10 maps to `ops/` because its subject — hosting, deployment,
+monitoring, backup and disaster recovery — is what a client's ops documentation covers.
+
+**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? [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)?
+   - How will infrastructure be managed (IaC with Terraform, Pulumi, CloudFormation)?
+   - What is the approach to containerization (GKE or Cloud Run via pareto-platform-gcp; Docker/Kubernetes on-prem; or other cloud options)?
+
+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?
+   - What is the rollback strategy if go-live fails?
+
+**Notes Template:**
+
+> **Platform standard (D-08):** The Pareto deployment platform is GCP / `pareto-platform-gcp` with GitLab CI as the CI/CD pipeline and Google Cloud Monitoring / Cloud Logging for observability. Fill the tables below against this baseline unless the client has an overriding constraint.
+
+**Infrastructure Architecture**
+
+| Component | Service / Product | Region | Tier / SKU | Redundancy | Est. Monthly Cost | Notes |
+|-----------|------------------|--------|-----------|------------|-------------------|-------|
+| Compute | | | | | | |
+| Database | | | | | | |
+| Storage | | | | | | |
+| Networking | | | | | | |
+| CDN | | | | | | |
+
+**Deployment Pipeline Design**
+
+| Stage | Trigger | Actions | Quality Gate | Environment | Duration |
+|-------|---------|---------|-------------|-------------|----------|
+| Build | | | | | |
+| Unit test | | | | | |
+| Deploy to test | | | | | |
+| Deploy to staging | | | | | |
+| Deploy to production | | | | | |
+
+**Monitoring and Alerting**
+
+| Metric | Source | Threshold (Warning) | Threshold (Critical) | Alert Channel | Dashboard |
+|--------|--------|--------------------|--------------------|---------------|-----------|
+| Response time (P95) | | | | | |
+| Error rate | | | | | |
+| CPU utilization | | | | | |
+
+**Backup and DR Plan**
+
+| Aspect | Strategy | Details |
+|--------|----------|---------|
+| Backup frequency | | |
+| Backup retention | | |
+| DR strategy | | |
+| DR failover time (RTO) | | |
+| DR data loss tolerance (RPO) | | |
+| DR drill cadence | | |
+
+**Go-Live Readiness Checklist**
+
+| # | Criterion | Status | Owner | Notes |
+|---|-----------|--------|-------|-------|
+| 1 | All critical defects resolved | | | |
+| 2 | UAT sign-off obtained | | | |
+| 3 | Performance benchmarks met | | | |
+| 4 | Security scan passed | | | |
+| 5 | Monitoring and alerting configured | | | |
+| 6 | Runbooks documented | | | |
+| 7 | Rollback procedure tested | | | |
+
+**Key Decisions**
+
+| # | Decision | Rationale | Owner | Date |
+|---|----------|-----------|-------|------|
+| | | | | |
+
+**Action Items**
+
+| # | Action | Owner | Due Date | Status |
+|---|--------|-------|----------|--------|
+| | | | | |

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

@@ -0,0 +1,92 @@
+# Session 11 — Project Roadmap & Release Planning
+
+> **Lazy-loaded.** Read from `workflows/discovery-sprint.md` Flow 2 Step 1 when facilitating this session.
+> Holds the session's Goal, vault areas, topics and Notes Template.
+
+### Session 11: Project Roadmap & Release Planning
+
+**Goal:** Define project phases and timeline, confirm MVP scope, establish build order and milestones, and identify key risks with mitigation strategies.
+
+**Vault areas:** `ops/` — optional: read only when the client vault is present (Flow 2 Step 1); skipped silently otherwise.
+
+**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? [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?
+   - Who owns each risk?
+
+**Notes Template:**
+
+**Project Timeline**
+
+| Phase | Start Date | End Date | Duration | Key Activities | Dependencies |
+|-------|-----------|----------|----------|---------------|--------------|
+| Discovery | | | | | |
+| Sprint 0 / Setup | | | | | |
+| Build -- MVP | | | | | |
+| UAT | | | | | |
+| Go-Live | | | | | |
+| Hypercare | | | | | |
+
+**EPIC Build Order**
+
+| Order | EPIC ID | EPIC Name | Sprint(s) | Dependencies | Critical Path? | Notes |
+|-------|---------|-----------|-----------|--------------|---------------|-------|
+| 1 | | | | | | |
+
+**Milestone Plan**
+
+| Milestone | Target Date | Included EPICs / Features | Entry Criteria | Exit Criteria | Stakeholder Demo? |
+|-----------|------------|--------------------------|----------------|---------------|-------------------|
+| Alpha | | | | | |
+| Beta | | | | | |
+| Release Candidate | | | | | |
+| GA / Go-Live | | | | | |
+
+**Risk Register**
+
+| ID | Risk Description | Category | Likelihood (H/M/L) | Impact (H/M/L) | Risk Score | Mitigation | Owner | Status |
+|----|-----------------|----------|--------------------|-----------------|-----------|-----------:|-------|--------|
+| R-01 | | | | | | | | |
+
+**Key Decisions**
+
+| # | Decision | Rationale | Owner | Date |
+|---|----------|-----------|-------|------|
+| | | | | |
+
+**Action Items**
+
+| # | Action | Owner | Due Date | Status |
+|---|--------|-------|----------|--------|
+| | | | | |

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

@@ -0,0 +1,98 @@
+# Session 12 — Team & Delivery Model Definition
+
+> **Lazy-loaded.** Read from `workflows/discovery-sprint.md` Flow 2 Step 1 when facilitating this session.
+> Holds the session's Goal, vault areas, topics and Notes Template.
+
+### Session 12: Team & Delivery Model Definition
+
+**Goal:** Define the team structure and roles, establish governance and decision-making processes, agree on agile ceremonies, and plan the support model for post-go-live.
+
+**Vault areas:** `ops/` — optional: read only when the client vault is present (Flow 2 Step 1); skipped silently otherwise.
+
+**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? [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? [needs-business-input]
+
+**Notes Template:**
+
+**Team Structure**
+
+| Role | Name / TBD | Allocation (%) | Responsible Party (Client / Partner) | Start Date | Notes |
+|------|-----------|----------------|--------------------------------------|-----------|-------|
+| Product Owner | | | | | |
+| Scrum Master | | | | | |
+| Solution Architect | | | | | |
+| Frontend Developer | | | | | |
+| Backend Developer | | | | | |
+| QA Engineer | | | | | |
+| UX Designer | | | | | |
+
+**Governance Structure**
+
+| Body | Members | Meeting Cadence | Decision Authority | Escalation From |
+|------|---------|----------------|-------------------|-----------------|
+| Steering Committee | | | | |
+| Project Board | | | | |
+| Delivery Team | | | | |
+
+**Agile Ceremonies**
+
+| Ceremony | Cadence | Duration | Participants | Facilitator | Tool |
+|----------|---------|----------|--------------|-------------|------|
+| Daily standup | Daily | | | | |
+| Sprint planning | Per sprint | | | | |
+| Sprint review | Per sprint | | | | |
+| Retrospective | Per sprint | | | | |
+| Backlog refinement | Weekly | | | | |
+
+**Support Model**
+
+| Level | Scope | SLA (Response) | SLA (Resolution) | Responsible | Escalation Path |
+|-------|-------|----------------|-----------------|-------------|-----------------|
+| L1 | | | | | |
+| L2 | | | | | |
+| L3 | | | | | |
+
+**Key Decisions**
+
+| # | Decision | Rationale | Owner | Date |
+|---|----------|-----------|-------|------|
+| | | | | |
+
+**Action Items**
+
+| # | Action | Owner | Due Date | Status |
+|---|--------|-------|----------|--------|
+| | | | | |