@pareto4/pp-core 1.19.0 → 1.20.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "pp-core",
   "displayName": "PP Core",
-  "version": "1.19.0",
+  "version": "1.20.0",
   "description": "PP Core is a meta-prompting, context engineering, and spec-driven development system for AI coding agents.",
   "author": {
     "name": "pareto4",

package/agents/pp-phase-researcher.md

@@ -61,6 +61,12 @@ Before researching, discover project context:
 | `## Deferred Ideas` | Out of scope — ignore completely |
 
 If CONTEXT.md exists, it constrains your research scope. Don't explore alternatives to locked decisions.
+
+**`{padded}-DISCOVERY-EXTRACT.md`** (if listed in your files to read) — the Discovery registers' rows
+that cite this phase's requirement IDs. Required reading; Read
+`pp-core/references/planner-discovery-extract.md` § Researcher and follow it. **Never open
+`.planning/discovery/session-NN.md`**: the session files are the facilitation record, not a
+source. Absent file → nothing here applies.
 </upstream_input>
 
 <downstream_consumer>
@@ -548,6 +554,10 @@ cat "$phase_dir"/*-CONTEXT.md 2>/dev/null
 - User decided "simple UI, no animations" → don't research animation libraries
 - Marked as Claude's discretion → research options and recommend
 
+Then read `$phase_dir`/*-DISCOVERY-EXTRACT.md if it exists (see `<upstream_input>`): list the
+entities, integrations and rules it names under `## User Constraints` as "Discovery facts (by row
+ID)" so the planner sees them beside the locked decisions. Do not open any `session-NN.md`.
+
 ## Step 1.3: Load Graph Context
 
 Check for knowledge graph:

package/agents/pp-planner.md

@@ -362,6 +362,11 @@ Output: [Artifacts created]
 Its exact shape comes from `pp_run vault standards block`, per `pp-core/references/planner-vault-standards.md`.]
 </vault_standards>
 
+<discovery_extract>
+[Present ONLY when a `*-DISCOVERY-EXTRACT.md` is in your files to read — omitted entirely otherwise.
+The file's content verbatim, `<!-- discovery:auto -->` markers included; see <discovery_mode>.]
+</discovery_extract>
+
 <tasks>
 
 <task type="auto">
@@ -577,6 +582,13 @@ start of execution when the injected `plan:pre -> into: planner` fragment for
 the vault capability is present in your context.
 </vault_standards_mode>
 
+<discovery_mode>
+See `pp-core/references/planner-discovery-extract.md`. Load this file at the
+start of execution when a `*-DISCOVERY-EXTRACT.md` is listed in your files to
+read: it is required reading, embedded verbatim as `<discovery_extract>`, and
+you never open a `.planning/discovery/session-NN.md`.
+</discovery_mode>
+
 <execution_flow>
 
 <step name="load_project_state" priority="first">
@@ -604,6 +616,7 @@ Check the invocation mode and load the relevant reference file:
 - If `<revision_context>` provided by orchestrator: Read `pp-core/references/planner-revision.md`
 - If `--reviews` flag present or reviews mode active: Read `pp-core/references/planner-reviews.md`
 - If the vault capability's `plan:pre` fragment is present: Read `pp-core/references/planner-vault-standards.md`
+- If a `*-DISCOVERY-EXTRACT.md` is in your files to read: Read `pp-core/references/planner-discovery-extract.md`
 - If task_breakdown identifies TDD candidates or TDD mode is active: Read `pp-core/references/planner-tdd.md`
 - Standard planning mode: no additional file to read
 
@@ -812,6 +825,8 @@ Use template structure for each PLAN.md.
 
 When the fragment IS present, follow `pp-core/references/planner-vault-standards.md` in full — select documents from the INDEX, read each in full, obtain the block from `pp_run vault standards block` once `files_modified` settles, embed it verbatim after `<context>` and before `<tasks>`, fill only the reason slots, and re-run it on revision.
 
+**Discovery extract block (only when a `*-DISCOVERY-EXTRACT.md` is in your files to read):** embed the file verbatim as `<discovery_extract>` after `<context>` (and after `<vault_standards>` when present), before `<tasks>`, per `<discovery_mode>`. Absent file → write no block.
+
 **ALWAYS use the Write tool to create files** — never use `Bash(cat << 'EOF')` or heredoc commands for file creation.
 
 **Write contract (hard rules — must follow):**

package/agents/pp-vault-reviewer.md

@@ -56,6 +56,8 @@ Forbidden, without exception, even when a finding seems to demand it:
 **Counts, never a score.** Report counts by verdict in the exact counts line the template shows. A ratio, percentage, letter grade or compliance number is prohibited anywhere in the artifact.
 
 A document the executor marked `not read: …` is still judged against the code; record the executor's reason in the row's evidence, because a standard nobody read is worth a reader's attention.
+
+**Deviations on file (`deviations[]` in the payload).** A Discovery Sprint records the client's agreed departures from the vault in `.planning/discovery/_deviations.md`; the CLI copies them into the payload (`pp-core/references/discovery-build-consumption.md` § `_deviations.md` read contract). Before writing `FAIL`, check the list: when a deviation whose `standard` names the document and whose `status` is `Approved` covers the clause the code breaks, the verdict is `N-A` with the reason `deviation on file: <id> (<decision>)` — the sponsor chose this departure and the document does not govern that clause here. A deviation in any other status (`Proposed`, `Rejected`, empty) leaves the `FAIL` standing; name the deviation and its status in the reason so the reader sees the gap between what was asked and what was approved. Never coin a verdict for it; `N-A` with that reason is the whole mechanism. An empty `deviations[]` changes nothing.
 </verdicts>
 
 <adversarial_stance>

package/agents/pp-verifier.md

@@ -188,7 +188,7 @@ For each truth, determine if codebase enables it.
 - ✗ FAILED: One or more artifacts missing, stub, or unwired
 - ? UNCERTAIN: Can't verify programmatically (needs human)
 
-**Behavior-dependent truths.** A truth is *behavior-dependent* when its correctness hinges on runtime behavior grep/presence checks cannot see — a **state transition** or a **cancellation / cleanup / ordering invariant** (e.g. "cancels the in-flight task and bumps the generation counter", "resets the busy flag on abort", "rolls back on failure"). For these, symbol presence + wiring is *necessary but not sufficient*: the code can be present and wired yet still leak state on the very path the invariant covers.
+**Behavior-dependent truths.** A truth is *behavior-dependent* when its correctness hinges on runtime behavior grep/presence checks cannot see — a **state transition** or a **cancellation / cleanup / ordering invariant** (e.g. "cancels the in-flight task and bumps the generation counter", "rolls back on failure"). For these, symbol presence + wiring is *necessary but not sufficient*: code can be present and wired yet leak state on the very path the invariant covers.
 
 For each truth:
 
@@ -424,6 +424,8 @@ grep -E "Phase $PHASE_NUM" .planning/REQUIREMENTS.md 2>/dev/null
 
 If REQUIREMENTS.md maps additional IDs to this phase that don't appear in ANY plan's `requirements` field, flag as **ORPHANED** — these requirements were expected but no plan claimed them. ORPHANED requirements MUST appear in the verification report.
 
+**6d. Discovery conformance (R3):** if `.planning/discovery/` exists, Read and follow `~/.claude/pp-core/references/verifier-discovery-conformance.md`; a `missed` row is a gap.
+
 ## Step 7: Scan for Anti-Patterns
 
 Identify files modified in this phase from SUMMARY.md key-files section, or extract commits and verify:
@@ -473,7 +475,7 @@ Anti-pattern scanning (Step 7) checks for code smells. Behavioral spot-checks go
 
 **When to run:** For phases that produce runnable code (APIs, CLI tools, build scripts, data pipelines). Skip for documentation-only or config-only phases.
 
-**Behavioral evidence for behavior-dependent truths (Step 3).** When a truth asserts a state transition or a cancellation/cleanup/ordering invariant, the single named test below is what upgrades it from ⚠️ PRESENT_BEHAVIOR_UNVERIFIED to ✓ VERIFIED. Run only the one named test that exercises the transition/invariant — never the full suite (per #25/#753). If no such test exists, leave the truth ⚠️ PRESENT_BEHAVIOR_UNVERIFIED and route it to human verification (Step 8); do not mark it VERIFIED on presence.
+**Behavioral evidence for behavior-dependent truths (Step 3).** For a state transition or a cancellation/cleanup/ordering invariant, the single named test below is what upgrades the truth from ⚠️ PRESENT_BEHAVIOR_UNVERIFIED to ✓ VERIFIED. Run only that one test — never the full suite (per #25/#753). No such test → leave it ⚠️ PRESENT_BEHAVIOR_UNVERIFIED and route it to human verification (Step 8); never VERIFIED on presence.
 
 **How:**
 
@@ -567,7 +569,7 @@ done
 
 **Needs human if uncertain:** Complex wiring grep can't trace, dynamic state behavior, edge cases.
 
-**Behavior-unverified truths (Step 3):** Every truth left ⚠️ PRESENT_BEHAVIOR_UNVERIFIED is recorded in the `behavior_unverified_items` frontmatter list (emitted whenever the count > 0, regardless of overall status, so it survives a gaps_found phase) and surfaces for human verification; when the overall status is human_needed it also appears in the human_verification section. Phrase each item around the invariant: what to trigger, what state must hold afterward, and why presence checks can't see it.
+**Behavior-unverified truths (Step 3):** every ⚠️ PRESENT_BEHAVIOR_UNVERIFIED truth is recorded in the `behavior_unverified_items` frontmatter list (emitted whenever the count > 0, regardless of overall status, so it survives a gaps_found phase) and surfaces for human verification — also in the human_verification section when the status is human_needed. Phrase each item around the invariant: what to trigger, what state must hold afterward, why presence checks can't see it.
 
 **Harvest deferred items from PLAN.md (#3309 / `workflow.human_verify_mode = end-of-phase`):** Scan every PLAN file in the phase for `<verify><human-check>` blocks on `auto` tasks. These are verification items the planner deliberately deferred from `checkpoint:human-verify` to end-of-phase to avoid the executor cold-start cost. Each block has the same shape used by the planner:
 
@@ -581,7 +583,7 @@ done
 </verify>
 ```
 
-Merge those harvested items into the same human verification list as your own analysis. Deduplicate when the planner-deferred item and your own analysis describe the same check. The downstream `human_needed` → `{phase_num}-UAT.md` path in `workflows/execute-phase.md` is the single sink — no separate file is created.
+Merge the harvested items into your own human verification list, deduplicating items that describe the same check. The downstream `human_needed` → `{phase_num}-UAT.md` path in `workflows/execute-phase.md` is the single sink — no separate file is created.
 
 **Format:**
 
@@ -597,7 +599,7 @@ Merge those harvested items into the same human verification list as your own an
 
 Classify status using this decision tree IN ORDER (most restrictive first):
 
-1. IF any truth FAILED, artifact MISSING/STUB, key link NOT_WIRED, or blocker anti-pattern found:
+1. IF any truth FAILED, artifact MISSING/STUB, key link NOT_WIRED, blocker anti-pattern found, or Discovery conformance row `missed` (Step 6d):
    → **status: gaps_found**
 
 2. IF Step 8 produced ANY human verification items (section is non-empty) — this includes every ⚠️ PRESENT_BEHAVIOR_UNVERIFIED truth from Step 3:
@@ -607,11 +609,11 @@ Classify status using this decision tree IN ORDER (most restrictive first):
 3. IF all truths VERIFIED, all artifacts pass, all links WIRED, no blockers, AND no human verification items:
    → **status: passed**
 
-**passed is ONLY valid when the human verification section is empty.** If Step 8 produced any items — including any truth left ⚠️ PRESENT_BEHAVIOR_UNVERIFIED — the status is not `passed`: it is `human_needed`, or `gaps_found` when rule 1 also fires (the ordered tree keeps gaps_found's precedence).
+**passed is ONLY valid when the human verification section is empty.** If Step 8 produced any items — including any ⚠️ PRESENT_BEHAVIOR_UNVERIFIED truth — the status is not `passed`: it is `human_needed`, or `gaps_found` when rule 1 also fires (gaps_found keeps precedence).
 
-**A ⚠️ PRESENT_BEHAVIOR_UNVERIFIED truth is never FAILED and never VERIFIED.** It does not trigger gaps_found (the code is present and wired) and is not counted as verified (behavior unexercised). On its own it routes to human_needed; when a higher-precedence gaps_found also applies, the status stays gaps_found and the item is preserved in the always-on `behavior_unverified_items` list so it is never lost. Either way it stays a *per-truth* state — the overall-status vocabulary is unchanged, with no new status value.
+**A ⚠️ PRESENT_BEHAVIOR_UNVERIFIED truth is never FAILED and never VERIFIED.** It does not trigger gaps_found (present and wired) and is not counted as verified (behavior unexercised). Alone it routes to human_needed; under a higher-precedence gaps_found the status stays gaps_found and the item is preserved in the always-on `behavior_unverified_items` list. It stays a *per-truth* state — the overall-status vocabulary is unchanged, with no new status value.
 
-> **Shared status seam**: the status vocabulary (`passed`, `gaps_found`, `human_needed`) and the per-status routing (next action and next command for each value) are owned by `src/verification.cts` via `pp-tools query verification.status`. This agent is the single emitter of the frontmatter status field; consumers (ship.md, execute-phase.md) read routing from that query instead of re-deriving it.
+> **Shared status seam**: the status vocabulary (`passed`, `gaps_found`, `human_needed`) and the per-status routing are owned by `src/verification.cts` via `pp-tools query verification.status`. This agent is the single emitter of the frontmatter status field; consumers (ship.md, execute-phase.md) read routing from that query instead of re-deriving it.
 
 **Score (presence- vs behavior-verified split):**
 
@@ -829,6 +831,8 @@ Only include this section if deferred items exist (from Step 9b).
 | Requirement | Source Plan | Description | Status | Evidence |
 | ----------- | ---------- | ----------- | ------ | -------- |
 
+{Step 6d block, when produced: `### Discovery conformance` + the filled `<!-- discovery:conformance -->` block}
+
 ### Anti-Patterns Found
 
 | File | Line | Pattern | Severity | Impact |

package/commands/pp-discovery.md

@@ -1,7 +1,7 @@
 ---
 name: pp:discovery
 description: Run the Pareto Discovery Sprint — 13 guided sessions to define your product, users, and roadmap
-argument-hint: "[session number 1-13 | prototype]"
+argument-hint: "[session number 1-13 | prototype | charter]"
 allowed-tools:
   - Read
   - Write
@@ -17,8 +17,9 @@ Facilitate the 13-session Pareto Discovery Sprint. Flows:
 - (no arg) — show progress + recommend next session
 - (N) — facilitate session N
 - prototype — build the clickable prototype from Sessions 1–4
+- charter — record signatures on, or redraft and re-export, the Project Charter
 
-Output: .planning/discovery/session-NN.md + _progress.md + _context.md
+Output: .planning/discovery/session-NN.md + _progress.md + the registers; docs/discovery/PROJECT-CHARTER.md (+ .docx/.pdf) from Session 13
 </objective>
 
 <execution_context>

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "pp-core",
-  "version": "1.19.0",
+  "version": "1.20.0",
   "description": "PP Core — a meta-prompting, context engineering, and spec-driven development system for AI coding agents. Loads pp-core's operating context into every Gemini CLI session.",
   "contextFileName": "GEMINI.md"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pareto4/pp-core",
-  "version": "1.19.0",
+  "version": "1.20.0",
   "description": "Pareto pp-core — The Pareto Project's AI-assisted engineering framework: meta-prompting, context engineering, and spec-driven development for AI coding agents.",
   "bin": {
     "pp-core": "bin/install.js",
@@ -71,10 +71,13 @@
   },
   "overrides": {
     "qs": ">=6.16.0",
-    "@hono/node-server": ">=2.0.5"
+    "@hono/node-server": ">=2.0.5",
+    "body-parser": "^2.4.0",
+    "fast-uri": "^3.1.9",
+    "zod": "^4.6.6"
   },
   "optionalDependencies": {
-    "fallow": "^2.70.0"
+    "fallow": "^3.35.0"
   },
   "scripts": {
     "sync:launcher": "node scripts/sync-runtime-launcher.cjs",

package/pareto-skills/_shared/pp-claude-md-protocol.md

@@ -17,7 +17,7 @@
 ## GitHub Board Sync
 
 Requirements are tracked as GitHub issues on a project board. The mapping
-between pp-core requirement IDs (EPIC-xxx, US-xxx, FR-xxx) and GitHub issue
+between requirement IDs (`E-nn` EPICs, `US-nn` stories, `<PREFIX>-nn` requirements) and GitHub issue
 numbers lives in `.planning/github-issues.json`.
 
 **Status flow:**