@pareto4/pp-core 1.19.0 → 1.21.0

package/agents/pp-verifier.md

@@ -70,6 +70,8 @@ Then verify each level against the actual codebase.
 
 <verification_process>
 
+**Depth.** When the prompt says `Verifier depth: light`, Read `~/.claude/pp-core/references/ceremony.md` § `## Verifier depth` before Step 0 and skip only the steps it names. Any other value, or none, is full depth.
+
 At verification decision points, apply structured reasoning:
 @~/.claude/pp-core/references/thinking-models-verification.md
 
@@ -188,7 +190,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 +426,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:
@@ -461,7 +465,7 @@ grep -n -E "=\{(\[\]|\{\}|null|undefined|''|\"\")\}" "$file" 2>/dev/null
 grep -n -B 2 -A 2 "console\.log" "$file" 2>/dev/null | grep -E "^\s*(const|function|=>)"
 ```
 
-**Stub classification:** A grep match is a STUB only when the value flows to rendering or user-visible output AND no other code path populates it with real data. A test helper, type default, or initial state that gets overwritten by a fetch/store is NOT a stub. Check for data-fetching (useEffect, fetch, query, useSWR, useQuery, subscribe) that writes to the same variable before flagging.
+**Stub classification:** A grep match is a STUB only when the value flows to rendering or user-visible output AND no other code path populates it with real data. A test helper, type default, or initial state that gets overwritten by a fetch/store is NOT a stub. Check for data-fetching (useEffect, fetch, query, useSWR, useQuery, subscribe) that writes to the same variable before flagging. Red-flag examples (component, API route and wiring stubs): `~/.claude/pp-core/references/verifier-stub-patterns.md`.
 
 **Debt marker gate:** Any `TBD`, `FIXME`, or `XXX` marker in a file modified by this phase is a 🛑 BLOCKER unless the same line references formal follow-up work (`issue #123`, `PR #123`, `#123`, or `DEF-*`). Unreferenced markers mean completion is not auditable; set `status: gaps_found` and list each marker under `gaps`.
 
@@ -473,7 +477,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 +571,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 +585,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 +601,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 +611,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 +833,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 |
@@ -903,57 +909,6 @@ Automated checks passed. Awaiting human verification.
 
 </critical_rules>
 
-<stub_detection_patterns>
-
-## React Component Stubs
-
-```javascript
-// RED FLAGS:
-return <div>Component</div>
-return <div>Placeholder</div>
-return <div>{/* TODO */}</div>
-return null
-return <></>
-
-// Empty handlers:
-onClick={() => {}}
-onChange={() => console.log('clicked')}
-onSubmit={(e) => e.preventDefault()}  // Only prevents default
-```
-
-## API Route Stubs
-
-```typescript
-// RED FLAGS:
-export async function POST() {
-  return Response.json({ message: "Not implemented" });
-}
-
-export async function GET() {
-  return Response.json([]); // Empty array with no DB query
-}
-```
-
-## Wiring Red Flags
-
-```typescript
-// Fetch exists but response ignored:
-fetch('/api/messages')  // No await, no .then, no assignment
-
-// Query exists but result not returned:
-await prisma.message.findMany()
-return Response.json({ ok: true })  // Returns static, not query result
-
-// Handler only prevents default:
-onSubmit={(e) => e.preventDefault()}
-
-// State exists but not rendered:
-const [messages, setMessages] = useState([])
-return <div>No messages</div>  // Always shows "no messages"
-```
-
-</stub_detection_patterns>
-
 <success_criteria>
 
 - [ ] Previous VERIFICATION.md checked (Step 0)

package/commands/pp-autonomous.md

@@ -1,7 +1,7 @@
 ---
 name: pp:autonomous
 description: Run the next phase autonomously (best-effort) — discuss→plan→execute; --from/--to for a range
-argument-hint: "[--from N] [--to N] [--only N] [--supervised] [--interactive] [--converge]"
+argument-hint: "[--from N] [--to N] [--only N] [--supervised] [--interactive] [--converge] [--full]"
 effort: max
 allowed-tools:
   - Read
@@ -41,6 +41,7 @@ Optional flags:
 - `--interactive` — run discuss inline with questions (not auto-answered), then dispatch plan→execute as background agents. Keeps the main context lean while preserving user input on decisions.
 - `--converge` — run each phase's planning step through `pp-plan-review-convergence` instead of plain `pp-plan-phase`. Requires `workflow.plan_review_convergence=true`.
 - `--cross-ai` — compatibility alias for `--converge`.
+- `--full` — plan every phase with the full gate stack: forwarded to every /pp-plan-phase call, through /pp-plan-review-convergence under --converge; never to execute. A later plan-phase run without --full re-classifies the phase (references/ceremony.md, Lifecycle).
 
 When `--converge` or `--cross-ai` is set, reviewer selector flags supported by `pp-plan-review-convergence` may be passed through: `--codex`, `--gemini`, `--claude`, `--opencode`, `--ollama`, `--lm-studio`, `--llama-cpp`, `--all`, and `--max-cycles N`.
 

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/commands/pp-plan-phase.md

@@ -1,7 +1,7 @@
 ---
 name: pp:plan-phase
 description: Create detailed phase plan (PLAN.md) with verification loop
-argument-hint: "[phase] [--auto] [--research] [--skip-research] [--research-phase <N>] [--view] [--gaps] [--skip-verify] [--prd <file>] [--ingest <path-or-glob>] [--ingest-format <auto|nygard|madr|narrative>] [--reviews] [--text] [--tdd] [--mvp]"
+argument-hint: "[phase] [--auto] [--research] [--skip-research] [--research-phase <N>] [--view] [--gaps] [--skip-verify] [--full] [--prd <file>] [--ingest <path-or-glob>] [--ingest-format <auto|nygard|madr|narrative>] [--reviews] [--text] [--tdd] [--mvp]"
 effort: max
 allowed-tools:
   - Read
@@ -47,6 +47,7 @@ Phase number: $ARGUMENTS (optional — auto-detects next unplanned phase if omit
 - `--skip-research` — Skip research, go straight to planning
 - `--gaps` — Gap closure mode (reads VERIFICATION.md, skips research)
 - `--skip-verify` — Skip verification loop
+- `--full` — Force every gate for this phase (ceremony mode full; rewrites the recorded verdict). Until the phase's first SUMMARY, a later plan-phase run without --full re-classifies it proportionally (D-12), so repeat --full on every re-plan that should stay full
 - `--prd <file>` — Use a PRD/acceptance criteria file instead of discuss-phase. Parses requirements into CONTEXT.md automatically. Skips discuss-phase entirely.
 - `--ingest <path-or-glob>` — Use one or more ADR files instead of discuss-phase. Parses locked decisions + scope fences into CONTEXT.md automatically. Skips discuss-phase entirely.
 - `--ingest-format <auto|nygard|madr|narrative>` — Optional ADR parser format override (`auto` default).

package/commands/pp-plan-review-convergence.md

@@ -1,7 +1,7 @@
 ---
 name: pp:plan-review-convergence
 description: "Cross-AI plan convergence - replan until review concerns are resolved."
-argument-hint: "<phase> [--codex] [--gemini] [--claude] [--opencode] [--ollama] [--lm-studio] [--llama-cpp] [--text] [--ws <name>] [--all] [--max-cycles N]"
+argument-hint: "<phase> [--codex] [--gemini] [--claude] [--opencode] [--ollama] [--lm-studio] [--llama-cpp] [--text] [--ws <name>] [--all] [--max-cycles N] [--full]"
 allowed-tools:
   - Read
   - Write
@@ -49,6 +49,7 @@ Phase number: extracted from $ARGUMENTS (required)
 - `--llama-cpp` — Use local llama.cpp server as reviewer (OpenAI-compatible, default host `http://localhost:8080`; configure model via `review.models.llama_cpp`)
 - `--all` — Use all available CLIs and running local model servers
 - `--max-cycles N` — Maximum replan→review cycles (default: 3)
+- `--full` — pass --full to the initial plan-phase run and to every --reviews replan, so the phase keeps the full gate stack
 
 **Feature gate:** This command requires `workflow.plan_review_convergence=true`. Enable with:
 `pp config-set workflow.plan_review_convergence true`

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "pp-core",
-  "version": "1.19.0",
+  "version": "1.21.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.21.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:**