@pareto4/pp-core 1.19.0 → 1.20.0

package/pareto-skills/pp-project-setup/SKILL.md

@@ -6,8 +6,7 @@ description: >
   "new project", "start a project", "create a repo", "set up a client project",
   "new engagement", or "initialise a project". This skill runs a wizard
   that collects project and client context, then automates: GitHub repo creation (via gh CLI),
-  Obsidian vault configuration, requirements templates, project definition template,
-  GitHub project board setup, and an initial commit pushed to GitHub — leaving the team
+  Obsidian vault configuration, GitHub project board setup, and an initial commit pushed to GitHub — leaving the team
   ready to start the Discovery Sprint (via `/pp-discovery 1`) immediately.
   Trigger even for vague requests like "let's start a new project" or "new client, new repo".
 ---
@@ -20,14 +19,13 @@ This skill bootstraps a new Pareto project and hands it off to `/pp-discovery` t
 **What it delivers:**
 - GitHub repository created and configured
 - Obsidian vault configured for project documentation
-- Requirements templates (functional requirements, user stories, test cases)
-- Project Definition template
 - GitHub project board with labels, milestone, and custom fields
 - Initial commit pushed to GitHub
 - Team ready to run `/pp-discovery 1` and start the Discovery Sprint immediately
 
 **What it does NOT do:**
 - Discovery Sprint facilitation — `/pp-discovery` is the sole, self-sufficient session source (it bootstraps its own `.planning/discovery/_progress.md` and `_context.md`); this skill does not scaffold a `Discovery/` tree or a Sessions Guide
+- Requirements or Project Definition templates — the sprint writes `.planning/discovery/_requirements.md` and the Project Charter (`PROJECT-CHARTER.md`) itself; a pre-scaffolded copy would be a second source of truth
 - Application scaffolding (backend/frontend code) — do this after Discovery, when the stack is confirmed
 - CI/CD pipeline setup — use `pareto-cicd-setup` after the application is scaffolded
 - Deployment setup — use `pareto-deploy-setup` when ready for staging/production
@@ -119,11 +117,10 @@ Summarise everything before running any commands:
 >
 > I'll:
 > 1. Create the GitHub repo
-> 2. Scaffold the project structure (requirements + docs)
-> 3. Set up the Project Definition and requirements templates
-> 4. Configure Obsidian vault for project documentation
-> 5. Configure GitHub project board, labels, and milestone
-> 6. Push the initial commit to GitHub
+> 2. Scaffold the project structure (docs + input documents)
+> 3. Configure Obsidian vault for project documentation
+> 4. Configure GitHub project board, labels, and milestone
+> 5. Push the initial commit to GitHub
 >
 > You'll then run `/pp-discovery 1` to start the Discovery Sprint.
 >
@@ -152,7 +149,6 @@ cd [PROJECT_NAME]
 
 ```bash
 mkdir -p \
-  requirements \
   Inputs/docs \
   docs/architecture \
   docs/decisions \
@@ -161,327 +157,9 @@ mkdir -p \
 
 Discovery Sprint artifacts are not scaffolded here — `/pp-discovery` creates `.planning/discovery/` itself on first run (session files, `_progress.md`, `_context.md`). The interactive prototype is built by `/pp-discovery prototype` into `.planning/discovery/prototype/`, on the UI kit the client vault declares.
 
-#### 4c. Scaffold Project Definition & Requirements Templates
+#### 4c. Input Documents
 
-Generate the requirements and project definition files. Discovery Sprint facilitation itself — the 13 guided sessions, the `_progress.md`/`_context.md` bootstrap files, and the Notes Template tables — is no longer scaffolded here. `/pp-discovery` is the sole, self-sufficient source for that: it bootstraps `.planning/discovery/_progress.md` and `.planning/discovery/_context.md` itself on first run (see `pp-core/workflows/discovery-sprint.md`'s Bootstrap Templates section). After STEP 4's scaffolding completes, the handoff (STEP 5) tells the team to run `/pp-discovery 1` to begin.
-
-**Generation order:** Project Definition → requirements.
-
-##### 4c.1 Project Definition Template
-
-Generate `[PROJECT_NAME]-Project-Definition.md`:
-
-```markdown
-# [PROJECT_NAME] — Project Definition
-
-> [PROJECT_DESCRIPTION]
-
-**Client:** [CLIENT_NAME]
-**Version:** 1.0
-**Date:** [today's date]
-**Status:** Draft — populated through Discovery Sprint sessions
-
----
-
-## Table of Contents
-
-1. Executive Summary
-2. Project Context
-3. Solution Architecture
-4. Functional Requirements
-5. User Roles & Access Control
-6. Integration & Interfaces
-7. Security & Compliance
-8. Team & Governance
-9. Project Roadmap
-10. Licensing & Costs
-11. Risks & Mitigations
-12. Appendices
-
----
-
-## 1. Executive Summary
-
-### Business Rationale
-<!-- Why this project? What problem does it solve? -->
-
-### Key Objectives
-
-| Objective | Description | Expected Improvement |
-|-----------|-------------|---------------------|
-|           |             |                     |
-
-### Success Criteria / KPIs
-
-| KPI | Target | Measurement |
-|-----|--------|-------------|
-|     |        |             |
-
----
-
-## 2. Project Context
-
-### Current State (As-Is)
-<!-- From Session 2 -->
-
-### Future State (To-Be)
-<!-- From Session 3 -->
-
-### Scope Definition
-
-**In Scope (MVP):**
--
-
-**Out of Scope:**
--
-
----
-
-## 3. Solution Architecture
-
-### System Overview
-<!-- From Session 5 -->
-
-### Technology Stack
-
-| Layer | Technology | Notes |
-|-------|-----------|-------|
-| Backend |         |       |
-| Frontend |        |       |
-| Database |        |       |
-| Infrastructure | |       |
-
-### Architecture Decision Records
-
-| ADR | Decision | Context | Consequences |
-|-----|----------|---------|--------------|
-|     |          |         |              |
-
----
-
-## 4. Functional Requirements
-
-See [requirements/functional-requirements.md](requirements/functional-requirements.md) for the full requirements matrix.
-
-### EPICs Overview
-
-| EPIC | Title | Phase | Priority |
-|------|-------|-------|----------|
-|      |       |       |          |
-
-### Requirements Summary
-
-| Category | Count |
-|----------|-------|
-| Functional Requirements | |
-| Non-Functional Requirements | |
-| Business Rules | |
-
----
-
-## 5. User Roles & Access Control
-
-<!-- From Sessions 3, 7 -->
-
-| Role | Description | Permissions | Device |
-|------|-------------|-------------|--------|
-|      |             |             |        |
-
----
-
-## 6. Integration & Interfaces
-
-<!-- From Sessions 5, 8 -->
-
-| Interface | System | Direction | Protocol | Phase |
-|-----------|--------|-----------|----------|-------|
-|           |        |           |          |       |
-
----
-
-## 7. Security & Compliance
-
-<!-- From Session 6 -->
-
-| Aspect | Approach | Standard |
-|--------|----------|----------|
-| Data Classification | | |
-| Compliance | | |
-| Encryption (transit) | | |
-| Encryption (at rest) | | |
-| Authentication | | |
-| Audit Logging | | |
-| Availability SLA | | |
-
----
-
-## 8. Team & Governance
-
-<!-- From Session 12 -->
-
-### Team Structure
-
-| Role | Who | Organization |
-|------|-----|--------------|
-|      |     |              |
-
-### Governance Framework
-
-| Level | Forum | Frequency | Purpose |
-|-------|-------|-----------|---------|
-|       |       |           |         |
-
----
-
-## 9. Project Roadmap
-
-<!-- From Session 11 -->
-
-### Phases
-
-| Phase | Scope | Timeline | Budget |
-|-------|-------|----------|--------|
-|       |       |          |        |
-
-### Key Milestones
-
-| Milestone | Target Date | Owner |
-|-----------|-------------|-------|
-|           |             |       |
-
----
-
-## 10. Licensing & Costs
-
-| Item | Cost | Frequency | Notes |
-|------|------|-----------|-------|
-|      |      |           |       |
-
----
-
-## 11. Risks & Mitigations
-
-| Risk | Probability | Impact | Mitigation | Owner |
-|------|-------------|--------|------------|-------|
-|      |             |        |            |       |
-
----
-
-## 12. Appendices
-
-- [Functional Requirements](requirements/functional-requirements.md)
-- [User Story Definition Guide](requirements/user-story-definition.md)
-- [Test Cases](requirements/test-cases.md)
-- Discovery Sprint sessions: `.planning/discovery/session-01.md` … `session-13.md` (run `/pp-discovery 1` to begin)
-
----
-
-**Document Status:** Draft
-**Generated by:** pareto-project-setup skill
-```
-
-##### 4c.2 Requirements Files
-
-Generate `requirements/functional-requirements.md`:
-
-```markdown
-# Functional Requirements — [PROJECT_NAME]
-
-Based on: [PROJECT_NAME] Discovery Sprint (Sessions 3, 5, 8)
-
-## How to Use This Document
-
-Requirements are captured during the Discovery Sprint, primarily in Session 3 (Business Requirements & To-Be).
-Each requirement has a unique ID, description, phase assignment, and priority.
-
----
-
-## 1. [Module Name]
-
-### 1.1 [Sub-module]
-
-| ID | Requirement | Phase | Priority | Notes |
-|----|-------------|-------|----------|-------|
-| REQ-001 | | | | |
-
----
-
-## Non-Functional Requirements
-
-| ID | Category | Requirement | Target |
-|----|----------|-------------|--------|
-| NFR-001 | Performance | | |
-| NFR-002 | Security | | |
-| NFR-003 | Usability | | |
-| NFR-004 | Availability | | |
-
----
-
-## Business Rules
-
-| ID | Rule Description | Applies To | Source |
-|----|-----------------|------------|--------|
-| BR-001 | | | |
-
----
-
-## Out of Scope
-
-The following items are explicitly out of scope:
--
-```
-
-Generate `requirements/user-story-definition.md` — this is the **full methodology guide** (reusable as-is across all projects). Include the complete User Story Definition Guide with:
-- Hierarchy: Epic → User Story → Acceptance Criteria → Test Case
-- Epic Definition (template, quality criteria, example)
-- User Story Definition (format, template, INVEST criteria, checklist, forbidden words)
-- Acceptance Criteria Definition (Given/When/Then + Concrete Condition formats)
-- Test Case Definition (template, test types, quality criteria)
-- Traceability Matrix
-- Status Definitions
-- Numbering Conventions
-- Review Checklists
-
-Generate `requirements/test-cases.md`:
-
-```markdown
-# Test Cases — [PROJECT_NAME]
-
-## Structure
-
-```
-TC-[US-ID]-[NR]: [Title]
-├── Test Type: Unit | Integration | E2E | Performance | Security
-├── User Story: US-XXX
-├── Acceptance Criterion: AC-XXX-XX
-├── Priority: Critical | High | Medium | Low
-├── Preconditions
-├── Test Steps
-├── Expected Result
-└── Test Data
-```
-
-## Test Phases
-
-| Phase | Focus | Responsibility |
-|-------|-------|----------------|
-| Unit Testing | Individual functions/components | Development team |
-| Integration Testing | Component collaboration | Development team |
-| System Testing | Complete system flows | QA team |
-| UAT | Business acceptance | Key users + PO |
-| Performance Testing | Speed and load | QA team |
-| Security Testing | Vulnerability assessment | Security team |
-
-## Test Cases
-
-_Test cases are added here as user stories are defined during the Discovery Sprint._
-
-| TC ID | User Story | AC | Type | Priority | Status |
-|-------|------------|-----|------|----------|--------|
-| | | | | | |
-```
-
-##### 4c.3 Input Documents
+No Project Definition or requirements templates are scaffolded. `/pp-discovery` creates `.planning/discovery/` on first run — `_progress.md`, `_context.md`, `_requirements.md` (the one requirement register) — and Session 13 drafts the Project Charter from the session record; a template written here would only drift from them. After STEP 4 completes, the handoff (STEP 5) tells the team to run `/pp-discovery 1`.
 
 Create `Inputs/docs/.gitkeep` (empty file — placeholder for input documents, architecture notes, and reference materials gathered during discovery).
 
@@ -665,11 +343,11 @@ Run `/pp-discovery 1` to begin. `/pp-discovery` facilitates all 13 Discovery Spr
 2. Work through all 13 sessions via guided Q&A — resume any time with `/pp-discovery <N>`, or run `/pp-discovery` with no argument to see progress
 3. Track progress at `.planning/discovery/_progress.md`
 
-**Outcome:** A validated project definition, prioritized backlog, architecture decisions, and go/no-go assessment.
+**Outcome:** A signed Project Charter, a prioritized requirement register, architecture decisions, and a go/no-go assessment.
 
 | Document | Purpose |
 |----------|---------|
-| [Project Definition]([PROJECT_NAME]-Project-Definition.md) | Consolidated output document |
+| `.planning/discovery/_requirements.md` | Requirement register (created by `/pp-discovery`) |
 | `.planning/discovery/_progress.md` | Session progress tracker (created by `/pp-discovery`) |
 | `.planning/discovery/_context.md` | Cross-session context accumulator (created by `/pp-discovery`) |
 | `.planning/discovery/prototype/` | Interactive prototype (built by `/pp-discovery prototype` after Session 4) |
@@ -679,14 +357,13 @@ Run `/pp-discovery 1` to begin. `/pp-discovery` facilitates all 13 Discovery Spr
 [PROJECT_NAME]/
   .obsidian/              Obsidian vault configuration
   .planning/discovery/    Discovery Sprint outputs and the prototype (created by /pp-discovery)
-  requirements/           Functional requirements, user stories, test cases
   Inputs/docs/            Input documents and reference materials
   docs/                   Architecture decisions and guides
 ```
 
 ## Next Steps After Discovery
 
-Once the Discovery Sprint is complete and you have a validated project definition:
+Once the Discovery Sprint is complete and the Project Charter is signed:
 1. Scaffold the application code (use `pareto-project-setup` or manually)
 2. Set up CI/CD pipeline (use `pareto-cicd-setup`)
 3. Create your first feature branch and start building
@@ -768,8 +445,8 @@ gh label create "uat"           -c "fbca04" -d "User acceptance testing"
 
 ```bash
 # Example — create after Discovery Sprint Session 3 (To-Be) when EPICs are known:
-gh label create "epic:lead-management" -c "0E8A16" -d "EPIC-001: Lead Management"  --force -R [GITHUB_ORG]/[PROJECT_NAME]
-gh label create "epic:ai-engine"       -c "B44EFF" -d "EPIC-002: AI Next-Action"   --force -R [GITHUB_ORG]/[PROJECT_NAME]
+gh label create "epic:lead-management" -c "0E8A16" -d "E-01: Lead Management"  --force -R [GITHUB_ORG]/[PROJECT_NAME]
+gh label create "epic:ai-engine"       -c "B44EFF" -d "E-02: AI Next-Action"      --force -R [GITHUB_ORG]/[PROJECT_NAME]
 # ... one per EPIC, each with a unique color for visual distinction on the board
 ```
 
@@ -781,9 +458,9 @@ gh label create "epic:ai-engine"       -c "B44EFF" -d "EPIC-002: AI Next-Action"
 
 **Rules for epic labels:**
 - Use `epic:[short-name]` format (e.g. `epic:trips`, `epic:finance`, `epic:auth`)
-- Never use generic IDs like `epic:EPIC-001` — these are unreadable on the board
+- Never use generic IDs like `epic:E-01` — these are unreadable on the board
 - Each epic gets a unique color from the palette above
-- Description includes the EPIC ID for traceability (e.g. `"EPIC-001: Trip Management"`)
+- Description includes the EPIC ID (`E-nn`, as Session 3 minted it) for traceability (e.g. `"E-01: Trip Management"`)
 - Apply `epic` label to EPIC issues, `user-story` label to story issues
 - Apply the relevant `epic:[short-name]` label to both the EPIC issue and its child stories
 
@@ -834,10 +511,8 @@ web UI (click "New view" → "Board").
 git add .
 git commit -m "chore: initial project scaffold
 
-- Prototype folder structure (populated after Discovery Session 4)
 - Obsidian vault configured
-- Requirements templates (functional requirements, user stories, test cases)
-- Project Definition template
+- Inputs/docs and docs/ folders
 - GitHub project board with Status, Priority, Sprint, Estimate fields
 - Repo labels (type, priority, phase, status, MoSCoW, issue type)
 - MVP milestone
@@ -862,7 +537,7 @@ After successful push, give the developer a clean summary:
 > 1. Run `/pp-discovery 1` to begin **Session 1 (Kick-off)**
 > 2. Work through all 13 sessions via guided Q&A — resume any time with `/pp-discovery <N>`
 > 3. Track progress at `.planning/discovery/_progress.md` (created automatically)
-> 4. Complete all 13 sessions to produce a validated project definition
+> 4. Complete all 13 sessions to produce a signed Project Charter
 >
 > **Project Board:**
 > Open at: https://github.com/users/[GITHUB_ORG]/projects/ (or https://github.com/orgs/[GITHUB_ORG]/projects/)
@@ -870,7 +545,7 @@ After successful push, give the developer a clean summary:
 > Tip: Click "New view" → "Board" in the project to create a Kanban board view
 >
 > **After Discovery:**
-> Once you have a validated project definition, scaffold the application and set up CI/CD.
+> Once the Project Charter is signed, run `/pp-discovery-to-build`, then scaffold the application and set up CI/CD.
 > Use `pareto-cicd-setup` for pipeline configuration and `pareto-deploy-setup` for deployment.
 >
 > Discover first, then build."

package/pp-core/bin/lib/capability-registry.cjs

@@ -599,7 +599,7 @@ const capabilities = {
     "id": "discovery",
     "role": "feature",
     "title": "Pareto Discovery Sprint",
-    "description": "Native 13-session Pareto Discovery Sprint facilitation; writes .planning/discovery artifacts (session-NN.md, _progress.md, _context.md).",
+    "description": "Native 13-session Pareto Discovery Sprint facilitation; writes .planning/discovery artifacts (session-NN.md, _progress.md, the registers).",
     "tier": "full",
     "requires": [],
     "runtimeCompat": {