pan-wizard 3.12.3 → 3.13.1

package/pan-wizard-core/learnings/index.json

@@ -1,6 +1,6 @@
 {
   "schema_version": 1,
-  "generated_at": "2026-06-28T11:51:31.104Z",
+  "generated_at": "2026-07-09T15:40:55.203Z",
   "topics": [
     {
       "name": "experiment-runner",
@@ -34,10 +34,11 @@
         "P-RES-004",
         "P-RES-005",
         "P-RES-006",
-        "P-RES-007"
+        "P-RES-007",
+        "P-RES-008"
       ],
-      "size_bytes": 10306,
-      "size_tokens_est": 2577,
+      "size_bytes": 12400,
+      "size_tokens_est": 3100,
       "agent_relevance": {
         "planner": "medium",
         "executor": "low",
@@ -91,6 +92,24 @@
         "reviewer": "low"
       }
     },
+    {
+      "name": "adversarial-verification",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/adversarial-verification.md",
+      "patterns": [
+        "P-ADV-001",
+        "P-ADV-002",
+        "P-ADV-003"
+      ],
+      "size_bytes": 5405,
+      "size_tokens_est": 1352,
+      "agent_relevance": {
+        "planner": "medium",
+        "executor": "low",
+        "verifier": "high",
+        "reviewer": "high"
+      }
+    },
     {
       "name": "atomic-state",
       "scope": "universal",
@@ -107,6 +126,23 @@
         "reviewer": "medium"
       }
     },
+    {
+      "name": "audit-convergence",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/audit-convergence.md",
+      "patterns": [
+        "P-AUD-001",
+        "P-AUD-002"
+      ],
+      "size_bytes": 3693,
+      "size_tokens_est": 924,
+      "agent_relevance": {
+        "planner": "high",
+        "executor": "low",
+        "verifier": "high",
+        "reviewer": "high"
+      }
+    },
     {
       "name": "autonomous-loop",
       "scope": "universal",
@@ -116,8 +152,8 @@
         "P-350",
         "P-360"
       ],
-      "size_bytes": 10680,
-      "size_tokens_est": 2670,
+      "size_bytes": 10667,
+      "size_tokens_est": 2667,
       "agent_relevance": {
         "planner": "low",
         "executor": "medium",
@@ -288,6 +324,57 @@
         "reviewer": "high"
       }
     },
+    {
+      "name": "external-tool-truth",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/external-tool-truth.md",
+      "patterns": [
+        "P-XTT-001"
+      ],
+      "size_bytes": 1621,
+      "size_tokens_est": 406,
+      "agent_relevance": {
+        "planner": "low",
+        "executor": "high",
+        "verifier": "high",
+        "reviewer": "low"
+      }
+    },
+    {
+      "name": "fix-campaigns",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/fix-campaigns.md",
+      "patterns": [
+        "P-FIX-001",
+        "P-FIX-002",
+        "P-FIX-003"
+      ],
+      "size_bytes": 4897,
+      "size_tokens_est": 1225,
+      "agent_relevance": {
+        "planner": "high",
+        "executor": "medium",
+        "verifier": "high",
+        "reviewer": "high"
+      }
+    },
+    {
+      "name": "flaky-triage",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/flaky-triage.md",
+      "patterns": [
+        "P-FLK-001",
+        "P-FLK-002"
+      ],
+      "size_bytes": 3309,
+      "size_tokens_est": 828,
+      "agent_relevance": {
+        "planner": "low",
+        "executor": "medium",
+        "verifier": "high",
+        "reviewer": "medium"
+      }
+    },
     {
       "name": "glob-semantics",
       "scope": "universal",
@@ -304,6 +391,39 @@
         "reviewer": "low"
       }
     },
+    {
+      "name": "golden-sets",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/golden-sets.md",
+      "patterns": [
+        "P-GLD-001",
+        "P-GLD-002"
+      ],
+      "size_bytes": 3215,
+      "size_tokens_est": 804,
+      "agent_relevance": {
+        "planner": "high",
+        "executor": "medium",
+        "verifier": "high",
+        "reviewer": "medium"
+      }
+    },
+    {
+      "name": "harness-isolation",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/harness-isolation.md",
+      "patterns": [
+        "P-ISO-001"
+      ],
+      "size_bytes": 1736,
+      "size_tokens_est": 434,
+      "agent_relevance": {
+        "planner": "high",
+        "executor": "medium",
+        "verifier": "low",
+        "reviewer": "low"
+      }
+    },
     {
       "name": "idempotency",
       "scope": "universal",
@@ -320,6 +440,23 @@
         "reviewer": "high"
       }
     },
+    {
+      "name": "integration-verification",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/integration-verification.md",
+      "patterns": [
+        "P-INT-001",
+        "P-INT-002"
+      ],
+      "size_bytes": 3075,
+      "size_tokens_est": 769,
+      "agent_relevance": {
+        "planner": "high",
+        "executor": "low",
+        "verifier": "high",
+        "reviewer": "medium"
+      }
+    },
     {
       "name": "invariants",
       "scope": "universal",
@@ -352,6 +489,56 @@
         "reviewer": "low"
       }
     },
+    {
+      "name": "live-path-honesty",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/live-path-honesty.md",
+      "patterns": [
+        "P-HON-001",
+        "P-HON-002",
+        "P-HON-003"
+      ],
+      "size_bytes": 4975,
+      "size_tokens_est": 1244,
+      "agent_relevance": {
+        "planner": "medium",
+        "executor": "high",
+        "verifier": "high",
+        "reviewer": "high"
+      }
+    },
+    {
+      "name": "mcp-security",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/mcp-security.md",
+      "patterns": [
+        "P-MCP-001"
+      ],
+      "size_bytes": 2082,
+      "size_tokens_est": 521,
+      "agent_relevance": {
+        "planner": "medium",
+        "executor": "medium",
+        "verifier": "medium",
+        "reviewer": "high"
+      }
+    },
+    {
+      "name": "migration-safety",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/migration-safety.md",
+      "patterns": [
+        "P-MIG-001"
+      ],
+      "size_bytes": 2031,
+      "size_tokens_est": 508,
+      "agent_relevance": {
+        "planner": "high",
+        "executor": "high",
+        "verifier": "medium",
+        "reviewer": "high"
+      }
+    },
     {
       "name": "numeric-edge-cases",
       "scope": "universal",
@@ -464,6 +651,39 @@
         "reviewer": "high"
       }
     },
+    {
+      "name": "service-security",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/service-security.md",
+      "patterns": [
+        "P-SVC-001"
+      ],
+      "size_bytes": 2193,
+      "size_tokens_est": 549,
+      "agent_relevance": {
+        "planner": "medium",
+        "executor": "high",
+        "verifier": "high",
+        "reviewer": "high"
+      }
+    },
+    {
+      "name": "single-source-of-truth",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/single-source-of-truth.md",
+      "patterns": [
+        "P-SSOT-001",
+        "P-SSOT-002"
+      ],
+      "size_bytes": 3647,
+      "size_tokens_est": 912,
+      "agent_relevance": {
+        "planner": "high",
+        "executor": "high",
+        "verifier": "medium",
+        "reviewer": "high"
+      }
+    },
     {
       "name": "streaming-io",
       "scope": "universal",
@@ -480,6 +700,22 @@
         "reviewer": "low"
       }
     },
+    {
+      "name": "test-integrity",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/test-integrity.md",
+      "patterns": [
+        "P-TI-001"
+      ],
+      "size_bytes": 1915,
+      "size_tokens_est": 479,
+      "agent_relevance": {
+        "planner": "medium",
+        "executor": "high",
+        "verifier": "high",
+        "reviewer": "high"
+      }
+    },
     {
       "name": "test-patterns",
       "scope": "universal",
@@ -547,12 +783,28 @@
         "verifier": "low",
         "reviewer": "medium"
       }
+    },
+    {
+      "name": "workaround-catalog",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/workaround-catalog.md",
+      "patterns": [
+        "P-WKC-001"
+      ],
+      "size_bytes": 1741,
+      "size_tokens_est": 436,
+      "agent_relevance": {
+        "planner": "low",
+        "executor": "high",
+        "verifier": "medium",
+        "reviewer": "low"
+      }
     }
   ],
   "totals": {
-    "topics": 32,
-    "patterns": 66,
-    "size_bytes": 101338,
-    "size_tokens_est": 25344
+    "topics": 47,
+    "patterns": 93,
+    "size_bytes": 148954,
+    "size_tokens_est": 37255
   }
 }

package/pan-wizard-core/learnings/internal/external-research.md

@@ -1,6 +1,6 @@
 ---
 topic: external-research
-last_updated: 2026-05-02T18:16:19.459Z
+last_updated: 2026-07-09T14:04:40.520Z
 patterns:
   - id: P-RES-001
     summary: ACE (Zhang et al, arXiv:2510.04618, Oct 2025): summary-based context chains have brevity bias and context collapse. Treat memory as append-and-curate playbook, not paraphrase chain
@@ -30,6 +30,10 @@ patterns:
     summary: Sakana DGM (2025): in self-improvement loops, AGENT-DESIGN changes generalize across models and languages; PROMPT-FRAGMENT tweaks do not. Promote structural changes, not phrasing tweaks
     promoted_at: 2026-05-02T18:16:19.459Z
     source_experiments: [external]
+  - id: P-RES-008
+    summary: Enterprise "train on our data" asks are retrieval problems, not fine-tuning problems: schema/context LINKING is the bottleneck (BEAVER: SOTA ~10.8% on real enterprise schemas vs 80%+ on public benchmarks, ~68% of failures are schema-linking), and plain BM25 RAG beats fine-tuning alone (Tencent 160k-file study: 53.8% vs 44.2% EM; FT alone caused catastrophic forgetting; FT+RAG best at 57.4%)
+    promoted_at: 2026-07-09T14:04:40.520Z
+    source_experiments: [spec-factory]
 ---
 
 # External Research (AI-derived)
@@ -91,3 +95,11 @@ patterns:
 **Rule:** When pan-tools learn promote runs (manual gate today, possibly auto-promote in v3.8+), the promote criterion should distinguish: 1) STRUCTURAL pattern (a new agent role, a new file in .planning/, a new verification gate, a new tool-use idiom, an architectural decision) vs 2) PROMPT-FRAGMENT (specific phrasing, a worded instruction, a stylistic preference). Universal scope should be reserved for structural patterns. Prompt fragments belong in internal scope at most — they don't generalize across models or languages, so shipping them to all 5 runtimes is a bet that won't pay.
 
 **Applies in:** pan-tools learn promote --scope universal gate, optimize.cjs promotePattern criteria, future auto-promote rules
+
+## P-RES-008 — Enterprise "train on our data" asks are retrieval problems, not fine-tuning problems: schema/context LINKING is the bottleneck (BEAVER: SOTA ~10.8% on real enterprise schemas vs 80%+ on public benchmarks, ~68% of failures are schema-linking), and plain BM25 RAG beats fine-tuning alone (Tencent 160k-file study: 53.8% vs 44.2% EM; FT alone caused catastrophic forgetting; FT+RAG best at 57.4%)
+
+**Evidence:** The the tech-spec factory tech-spec factory research roadmap (adversarially verified, with citations) synthesized: on BEAVER (real enterprise schemas) SOTA agents collapse to ~10.8%; roughly 68% of failures are schema-linking, not generation. The Tencent 160k-file study showed plain BM25 retrieval beating fine-tuning alone (53.8 vs 44.2 EM) with fine-tuning alone causing catastrophic forgetting. Design consequence adopted there: never dump a full schema into context — decompose into semantic units, hybrid-retrieve a small candidate set (~50), then resolve to physical names.
+
+**Rule:** When a project asks to "train the model on our data/schema": default to retrieval-first (decompose corpus into semantic units, hybrid lexical+semantic retrieval of a small candidate set, then resolve). Treat fine-tuning as an additive step at most, never the substitute. Size context by retrieved candidates, not by dumping the schema. Expect public-benchmark performance claims to overstate enterprise reality by up to an order of magnitude.
+
+**Applies in:** Research/planning phases for RAG or fine-tune decisions, enterprise schema tooling, context-budget design.

package/pan-wizard-core/learnings/universal/adversarial-verification.md

@@ -0,0 +1,45 @@
+---
+topic: adversarial-verification
+last_updated: 2026-07-09T14:21:24.882Z
+patterns:
+  - id: P-ADV-001
+    summary: Two-stage audit: fan out cheap read-only finders, then one independent verifier per finding whose default stance is refute — expect a third to a half of raw findings to die, and action only survivors
+    promoted_at: 2026-07-09T14:04:40.513Z
+    source_experiments: [lending-fake-code-audit]
+  - id: P-ADV-002
+    summary: Anti-double-jeopardy: a verifier's first duty in a repeated audit is git-provenance against the prior findings register — refute anything byte-identical to already-adjudicated code, and confirm only with an explicit "not a re-report" clause naming the prior lines checked
+    promoted_at: 2026-07-09T14:21:24.881Z
+    source_experiments: [lending-audit-rounds-3-4]
+  - id: P-ADV-003
+    summary: Confirmation requires a REACHABLE trigger on the deployed surface, and severity is calibrated against named prior-round precedents — the recurring false-positive shapes are: unreachable fallback, value nothing consumes, happy-path-only proof, inverted causal mechanism, and code mirroring an authoritative sibling's intended semantics
+    promoted_at: 2026-07-09T14:21:24.882Z
+    source_experiments: [lending-audit-rounds-3-4]
+---
+
+# Adversarial Verification (AI-derived)
+
+> Auto-maintained by `pan-tools learn promote`. Each pattern was extracted from one or more experiment runs (see source_experiments). Patterns are **advisory** — orchestrators should weight them against current context.
+
+## P-ADV-001 — Two-stage audit: fan out cheap read-only finders, then one independent verifier per finding whose default stance is refute — expect a third to a half of raw findings to die, and action only survivors
+
+**Evidence:** A production fake-code audit ran 12 read-only slice auditors and then one adversarial verifier per finding (default stance: refute). Round 1: 80 raw findings -> 36 confirmed / 44 refuted. Round 2: 34 raw -> 23 confirmed / 11 refuted. Acting on raw finder output would have wasted roughly half the remediation effort on plausible-but-wrong findings.
+
+**Rule:** Never action raw finder output. Structure audits as: (1) parallel read-only finders raise candidate findings cheaply; (2) an independent verifier per finding, prompted to REFUTE it, with fresh context; (3) only findings that survive refutation are confirmed and actioned. Budget for a 30-55% refutation rate — if nothing is being refuted, the verifiers are rubber-stamping.
+
+**Applies in:** Code audits, security sweeps, review pipelines, multi-agent verification stages.
+
+## P-ADV-002 — Anti-double-jeopardy: a verifier's first duty in a repeated audit is git-provenance against the prior findings register — refute anything byte-identical to already-adjudicated code, and confirm only with an explicit "not a re-report" clause naming the prior lines checked
+
+**Evidence:** In a four-round production audit, every confirmed finding's verdict carried a provenance clause ("NOT a round-1 re-report — the register's only adjacent item was CONFIRMED LOW; the hunk was untouched by the remediation commits c1d1d569/acf0e03c") and refutations were proven with git ("byte-identical to the round-1 baseline; git diff shows no hunk touches these lines"). Without this, later rounds re-litigate settled findings and burn fix cycles on double-jeopardy.
+
+**Rule:** In any repeated audit, give the verifier the prior findings register and the prior audit baseline commit. Confirmation requires an explicit statement that the finding is new or on changed code (cite the register entries checked and the commits since baseline). Refute re-reports of unchanged, already-adjudicated code — including re-litigations of already-fixed findings at a lower bar.
+
+**Applies in:** Repeated audit rounds, review campaigns, any finder/verifier loop that runs more than once on the same tree.
+
+## P-ADV-003 — Confirmation requires a REACHABLE trigger on the deployed surface, and severity is calibrated against named prior-round precedents — the recurring false-positive shapes are: unreachable fallback, value nothing consumes, happy-path-only proof, inverted causal mechanism, and code mirroring an authoritative sibling's intended semantics
+
+**Evidence:** The refutation taxonomy from a 340-line verified findings register: a parser fallback that "exists exactly as cited but is unreachable on every rendered path"; a fabricated field where "no one is shown this field — the only consumer parses another key and silently drops it"; an ALWAYS_GREEN claim whose "mechanism is inverted"; and code that "byte-for-byte mirrors the owning monitor, whose designed semantics" it inherits. Confirmed findings calibrated severity to precedent: "MED matches the round-1 precedent (arrears failed-read-as-benign-data was MED)".
+
+**Rule:** A finding is confirmed only with a concrete failing input/state that is reachable on the deployed surface. Check the five false-positive shapes before confirming: (1) is the flagged code reachable? (2) does anything consume the value? (3) is the proof happy-path-only? (4) is the causal mechanism actually as described? (5) does the code intentionally mirror an authoritative sibling? Assign severity by citing a comparable prior finding, not freehand.
+
+**Applies in:** Verifier prompts, audit verdict schemas, severity rubrics for multi-round reviews.

package/pan-wizard-core/learnings/universal/audit-convergence.md

@@ -0,0 +1,33 @@
+---
+topic: audit-convergence
+last_updated: 2026-07-09T14:21:24.883Z
+patterns:
+  - id: P-AUD-001
+    summary: Stop an iterated audit on a convergence signal — top-severity count reaches zero AND confirmed findings collapse by an order of magnitude — not on "no findings at all"; escalate the model and taper the fan-out as the tree hardens
+    promoted_at: 2026-07-09T14:21:24.883Z
+    source_experiments: [lending-audit-rounds-3-4]
+  - id: P-AUD-002
+    summary: Rotate the audit LENS and its category taxonomy each round (honesty → correctness/completeness → cross-cutting depth), explicitly excluding scope already fixed in prior rounds — re-running the same lens finds the same things
+    promoted_at: 2026-07-09T14:21:24.883Z
+    source_experiments: [lending-audit-rounds-3-4]
+---
+
+# Audit Convergence (AI-derived)
+
+> Auto-maintained by `pan-tools learn promote`. Each pattern was extracted from one or more experiment runs (see source_experiments). Patterns are **advisory** — orchestrators should weight them against current context.
+
+## P-AUD-001 — Stop an iterated audit on a convergence signal — top-severity count reaches zero AND confirmed findings collapse by an order of magnitude — not on "no findings at all"; escalate the model and taper the fan-out as the tree hardens
+
+**Evidence:** A four-round production audit stopped when round 3's 108 confirmed (9 HIGH) dropped to round 4's 16 confirmed (0 HIGH — a ~7x collapse), declaring "no new HIGH-severity defect survived a 4th pass on a hardened tree; the codebase is converging; this is likely the last productive audit round." Convergence was partly forced: the model was escalated to the strongest tier and the agent count tapered from 152 to 39 as findings thinned — the convergence claim is only meaningful against the strongest reviewer.
+
+**Rule:** Define the stopping rule before the audit loop starts: stop when (a) zero findings at the top severity survive verification AND (b) the confirmed count collapses relative to the prior round (~5-10x). Never require literal zero findings — a long MED/LOW tail is normal residue. As rounds progress, escalate reviewer strength and shrink fan-out; a "converged" verdict from a weak reviewer at full fan-out proves nothing.
+
+**Applies in:** Audit campaigns, review loops, focus-loop stop conditions, quality-gate design.
+
+## P-AUD-002 — Rotate the audit LENS and its category taxonomy each round (honesty → correctness/completeness → cross-cutting depth), explicitly excluding scope already fixed in prior rounds — re-running the same lens finds the same things
+
+**Evidence:** Round 1/2 audited fabrication (LIVE_FAKE_DATA, ALWAYS_GREEN, STUB_IN_PROD); round 3 switched to "a correctness/completeness/quality lens, distinct from the rounds-1/2 mock-fake honesty audit" (INCORRECT, RACE_OR_LEAK, DUPLICATION_DRIFT, MISSING_VALIDATION); round 4 went to cross-cutting depth ("atomicity, concurrency, authz depth, regulatory-math edges") plus a dedicated fix-regression pass. Each round explicitly excluded the previous rounds' fixed findings ("the 59 already-fixed mock/fake findings were explicitly excluded"), so every pass hit a genuinely different defect class.
+
+**Rule:** Plan a repeated audit as a lens sequence, each with its own defect taxonomy: (1) honesty/fabrication, (2) correctness/completeness/error-handling, (3) cross-cutting depth (atomicity, concurrency, authorization, domain-math edges) + fix regressions. Feed each round the prior rounds' fixed-findings register as an explicit exclusion so auditors don't rediscover settled ground.
+
+**Applies in:** Multi-round audit design, review campaign planning, quality-sweep scheduling.

package/pan-wizard-core/learnings/universal/autonomous-loop.md

@@ -9,11 +9,11 @@ patterns:
   - id: P-350
     summary: In a parallel campaign, review a branch against its merge-base (three-dot / fork-sha diff), never two-dot main..HEAD, or a moved base produces phantom deletions and false blocks
     promoted_at: 2026-06-28T00:00:00.000Z
-    source_experiments: [abilitycompliance-army-v1.1]
+    source_experiments: [compliance-army-v1.1]
   - id: P-360
     summary: Campaign telemetry must be both captured (active per-step record, not just the passive hook) and trustworthy (never naive-sum a shared-session transcript — cumulative-per-turn cache-read over-counts by orders of magnitude)
     promoted_at: 2026-06-28T00:00:00.000Z
-    source_experiments: [abilitycompliance-army-v1.1, plusb-loans-focus-auto, plusbforecasting-exec]
+    source_experiments: [compliance-army-v1.1, lending-focus-auto, forecasting-exec]
 ---
 
 # Autonomous Loop (AI-derived)
@@ -65,7 +65,7 @@ patterns:
 
 ## P-350 — Review a worktree branch against its merge-base, never two-dot, when the base moves
 
-**Evidence:** In the first production army campaign (AbilityCompliance v1.1, 6 missions), a Quality squad **BLOCK was a false positive**: the reviewer diffed `main..HEAD` (two-dot) *after* an earlier parallel mission had merged and advanced `main` past the reviewed mission's fork point — so the already-merged mission's additions appeared as **phantom deletions** in the diff. The block was disproven only by re-diffing against the merge-base. A false block burns a whole cycle; the mirror case (phantom additions hiding a genuine deletion) can wave a bad change through a gate.
+**Evidence:** In the first production army campaign (the compliance project v1.1, 6 missions), a Quality squad **BLOCK was a false positive**: the reviewer diffed `main..HEAD` (two-dot) *after* an earlier parallel mission had merged and advanced `main` past the reviewed mission's fork point — so the already-merged mission's additions appeared as **phantom deletions** in the diff. The block was disproven only by re-diffing against the merge-base. A false block burns a whole cycle; the mirror case (phantom additions hiding a genuine deletion) can wave a bad change through a gate.
 
 **Rule:** Whenever you review or merge a branch whose base can advance under it (every parallel campaign):
 
@@ -77,7 +77,7 @@ patterns:
 
 ## P-360 — Campaign telemetry must be both captured and trustworthy
 
-**Evidence:** Three production projects showed campaign telemetry failing in *both* directions. (1) **Absent** — a full 5-mission army campaign (AbilityCompliance v1.1) produced **zero** cost/trace/bus records, although the hooks were installed, registered on `SubagentStop`, and verified working in isolation; a main-loop coordinator's work never fired `SubagentStop`, so nothing was captured. (2) **Corrupted** — two projects that *did* capture (a weeks-long focus-auto loop and a phase-exec project) logged physically-impossible figures: a single subagent record claiming billions of cache-read tokens, cache-hit pinned at 100%, and many byte-identical rows. Root cause: the transcript fallback summed `usage` across *every* assistant message in a transcript whose `session_id` is shared by all subagents — so each event re-summed the whole growing transcript, and `cache_read` (re-read every turn) multiplied by the turn count. Either way the HUD, `/pan:cost`, and `/pan:optimize` consumed nothing usable.
+**Evidence:** Three production projects showed campaign telemetry failing in *both* directions. (1) **Absent** — a full 5-mission army campaign (the compliance project v1.1) produced **zero** cost/trace/bus records, although the hooks were installed, registered on `SubagentStop`, and verified working in isolation; a main-loop coordinator's work never fired `SubagentStop`, so nothing was captured. (2) **Corrupted** — two projects that *did* capture (a weeks-long focus-auto loop and a phase-exec project) logged physically-impossible figures: a single subagent record claiming billions of cache-read tokens, cache-hit pinned at 100%, and many byte-identical rows. Root cause: the transcript fallback summed `usage` across *every* assistant message in a transcript whose `session_id` is shared by all subagents — so each event re-summed the whole growing transcript, and `cache_read` (re-read every turn) multiplied by the turn count. Either way the HUD, `/pan:cost`, and `/pan:optimize` consumed nothing usable.
 
 **Rule:** For any long-running, multi-step autonomous campaign, telemetry must survive the spawn pattern *and* be numerically sane:
 

package/pan-wizard-core/learnings/universal/external-tool-truth.md

@@ -0,0 +1,21 @@
+---
+topic: external-tool-truth
+last_updated: 2026-07-09T14:04:40.517Z
+patterns:
+  - id: P-XTT-001
+    summary: Judge external CLI success by the artifact it was supposed to produce, not by its exit code — tools return non-zero for cosmetic reasons while the real work succeeded
+    promoted_at: 2026-07-09T14:04:40.517Z
+    source_experiments: [compliance-army-v1.1]
+---
+
+# External Tool Truth (AI-derived)
+
+> Auto-maintained by `pan-tools learn promote`. Each pattern was extracted from one or more experiment runs (see source_experiments). Patterns are **advisory** — orchestrators should weight them against current context.
+
+## P-XTT-001 — Judge external CLI success by the artifact it was supposed to produce, not by its exit code — tools return non-zero for cosmetic reasons while the real work succeeded
+
+**Evidence:** A cloud container build (az acr build) exited non-zero because the console (cp1252 codepage) crashed printing a Unicode check-mark glyph from the build output — while the image build itself had succeeded in the cloud. Automation keyed on the exit code declared the deploy broken; the reliable signal was whether the image digest resolved in the registry.
+
+**Rule:** For external tools whose job is to produce an artifact (image, package, file, release), verify the artifact exists and resolves — digest lookup, file hash, registry query — instead of trusting the process exit code alone. Exit codes conflate the tool's own console/plumbing failures with the outcome of the work.
+
+**Applies in:** Deploy steps, build pipelines, cloud CLIs, Windows consoles with non-UTF8 codepages.

package/pan-wizard-core/learnings/universal/fix-campaigns.md

@@ -0,0 +1,45 @@
+---
+topic: fix-campaigns
+last_updated: 2026-07-09T14:21:24.885Z
+patterns:
+  - id: P-FIX-001
+    summary: Hand a large findings register to fixers as defect-CLASS clusters with an explicit fix order ranked by real risk — "fix the class once, apply everywhere" — not as N independent tickets
+    promoted_at: 2026-07-09T14:21:24.884Z
+    source_experiments: [lending-audit-rounds-3-4]
+  - id: P-FIX-002
+    summary: Treat the audit's own suggested fixes as UNTRUSTED input — the fix campaign's quality gate must adversarially review the guidance itself, reject flawed suggestions, and preserve the original text for the audit trail
+    promoted_at: 2026-07-09T14:21:24.884Z
+    source_experiments: [lending-audit-rounds-3-4]
+  - id: P-FIX-003
+    summary: After any fix campaign, run a dedicated FIX-REGRESSION lens: hunt fixes that are inert (read the wrong path), half-wired, or that broke a sibling — distinct from generic regression testing
+    promoted_at: 2026-07-09T14:21:24.885Z
+    source_experiments: [lending-audit-rounds-3-4]
+---
+
+# Fix Campaigns (AI-derived)
+
+> Auto-maintained by `pan-tools learn promote`. Each pattern was extracted from one or more experiment runs (see source_experiments). Patterns are **advisory** — orchestrators should weight them against current context.
+
+## P-FIX-001 — Hand a large findings register to fixers as defect-CLASS clusters with an explicit fix order ranked by real risk — "fix the class once, apply everywhere" — not as N independent tickets
+
+**Evidence:** A 108-finding audit register was compressed into 8 shared-defect-class clusters for the fix campaign ("Many findings are the same defect class repeated — fix the class once, apply everywhere"), ordered by consequence with idempotency/duplicate-financial-writes first ("highest real-money risk"). Fixers repaired the pattern once per class instead of patching 108 sites independently, which also made per-class regression review tractable.
+
+**Rule:** Before spawning fixers on a big findings register: cluster findings by shared defect class (same root pattern, not same file), rank clusters by real-world consequence, and hand each fixer one class with all its instances. The fix contract is "repair the class everywhere", and review happens per class — never fan out one-ticket-per-finding on a register with repeated patterns.
+
+**Applies in:** Fix campaign planning, gap-closure batching, remediation handovers after audits.
+
+## P-FIX-002 — Treat the audit's own suggested fixes as UNTRUSTED input — the fix campaign's quality gate must adversarially review the guidance itself, reject flawed suggestions, and preserve the original text for the audit trail
+
+**Evidence:** A findings register's suggestedFix for an nginx routing defect "literally recommended the broken proxy_pass form; the campaign rejected that flawed guidance in favour of the rewrite-strip. The suggestedFix text is left as-authored for the audit trail." The same round's adversarial quality reviewer also caught a fix that itself dropped a required prefix-strip (BLOCK verdict) — both the auditor's advice and the fixer's change needed independent review.
+
+**Rule:** Auditor-suggested fixes are hypotheses, not instructions: the fixer must validate the suggestion against the real system (does the API exist? does the config form parse?) and the quality gate must review the applied change independently of the suggestion. When guidance is rejected, keep the original suggestion text unmodified in the register — the divergence is part of the audit trail.
+
+**Applies in:** Fix campaigns consuming audit registers, remediation quality gates, handover contracts.
+
+## P-FIX-003 — After any fix campaign, run a dedicated FIX-REGRESSION lens: hunt fixes that are inert (read the wrong path), half-wired, or that broke a sibling — distinct from generic regression testing
+
+**Evidence:** A round-4 audit carried a dedicated fix-regression category and found three: a round-3 "resume is amount-honest" fix that "reads the resumed amount from the wrong JSON path — the fix is inert, the blind-book MED is re-opened on Live"; a checker leg reading a field the writer never sets; and a deploy-script fix that broke plan idempotency. Ordinary test suites stayed green through all three — the fixes compiled, passed, and did nothing.
+
+**Rule:** The audit round after a fix campaign must include an explicit fix-regression lens over the fixed sites: (1) INERT — does the fix actually execute on the live path, reading the real data shape? (2) HALF-WIRED — is every leg of the fix threaded through (writer AND reader)? (3) SIBLING BREAKAGE — did the fix change behavior a neighboring consumer depended on? Green tests do not clear a fix; re-verify the original finding's failing input now behaves.
+
+**Applies in:** Post-fix verification rounds, gap-closure follow-ups, re-audit scheduling.

package/pan-wizard-core/learnings/universal/flaky-triage.md

@@ -0,0 +1,33 @@
+---
+topic: flaky-triage
+last_updated: 2026-07-09T14:04:40.517Z
+patterns:
+  - id: P-FLK-001
+    summary: A failure under contended/parallel load that passes N isolated re-runs is environmental, not a regression — triage with isolated re-runs and decompose aggregate counts into disabled/timeout/genuinely-failed before reacting
+    promoted_at: 2026-07-09T14:04:40.516Z
+    source_experiments: [montyhall-cycle-close]
+  - id: P-FLK-002
+    summary: Non-deterministic verdicts (perf, endurance, memory) need windowed statistics — widen the analysis window rather than biasing the sampler, and require 2-of-3 reproduction before a finding becomes a ticket
+    promoted_at: 2026-07-09T14:04:40.517Z
+    source_experiments: [mph-factory-limits]
+---
+
+# Flaky Triage (AI-derived)
+
+> Auto-maintained by `pan-tools learn promote`. Each pattern was extracted from one or more experiment runs (see source_experiments). Patterns are **advisory** — orchestrators should weight them against current context.
+
+## P-FLK-001 — A failure under contended/parallel load that passes N isolated re-runs is environmental, not a regression — triage with isolated re-runs and decompose aggregate counts into disabled/timeout/genuinely-failed before reacting
+
+**Evidence:** A cycle-close investigation of "8 failed" concurrent GC tests ran the suspects isolated: pass/fail/pass, then 5/5 PASS — deterministically green alone, failing only under concurrent test-runner load. The aggregate count was also misleading: it mixed ~100 disabled tests and load-induced timeouts with only two genuine (and flaky) failures. Fixing "the regression" mid-sweep would have burned a cycle on an environmental artifact.
+
+**Rule:** Before treating a red test as a regression: (1) re-run it isolated 3-5 times; deterministic pass in isolation + failure only under load = environmental, log it to a known-red list instead of fixing mid-sweep; (2) decompose aggregate failure counts into disabled / timed-out / genuinely-failed — never react to the headline number; (3) record the triage so the next sweep does not re-investigate.
+
+**Applies in:** CI triage, autonomous fix loops, test-gate policies, cycle-close retrospectives.
+
+## P-FLK-002 — Non-deterministic verdicts (perf, endurance, memory) need windowed statistics — widen the analysis window rather than biasing the sampler, and require 2-of-3 reproduction before a finding becomes a ticket
+
+**Evidence:** An endurance/limits harness codified: "If you find yourself wanting to wait for the system to settle before sampling, the right answer is to widen the analysis window, not to bias the sampler." Marathon failures must reproduce in 2 of 3 independent re-runs before becoming a ticket; singletons accumulate in a watch bucket that auto-promotes only after repeated appearances.
+
+**Rule:** For perf/endurance/resource checks: never pass or fail on a single sample — use windowed signals (slopes with confidence intervals, percentiles over a window). Never bias sampling to make results stable; widen the window instead. Gate findings on independent reproduction (2-of-3); park singletons in a watch bucket that promotes on recurrence rather than discarding them.
+
+**Applies in:** Perf gates, endurance harnesses, memory-leak detection, any statistically noisy verification.

package/pan-wizard-core/learnings/universal/golden-sets.md

@@ -0,0 +1,33 @@
+---
+topic: golden-sets
+last_updated: 2026-07-09T14:04:40.518Z
+patterns:
+  - id: P-GLD-001
+    summary: "Verified" requires human-verified golden sets plus live execution checks — public benchmarks are defective at scale, and an LLM judge is only usable after calibration against human labels
+    promoted_at: 2026-07-09T14:04:40.518Z
+    source_experiments: [spec-factory]
+  - id: P-GLD-002
+    summary: Execution-gate corpus curation: admit only samples that compile AND run clean on the shipped toolchain, record every exclusion with a reason code, and regenerate by script — never hand-edit the corpus
+    promoted_at: 2026-07-09T14:04:40.518Z
+    source_experiments: [montyhall-learning-corpus]
+---
+
+# Golden Sets (AI-derived)
+
+> Auto-maintained by `pan-tools learn promote`. Each pattern was extracted from one or more experiment runs (see source_experiments). Patterns are **advisory** — orchestrators should weight them against current context.
+
+## P-GLD-001 — "Verified" requires human-verified golden sets plus live execution checks — public benchmarks are defective at scale, and an LLM judge is only usable after calibration against human labels
+
+**Evidence:** A spec-factory evaluation standard was built on the finding that naive automated eval misjudges correct work (68.3% of original SWE-bench samples were defective). Its gates: a multi-reviewer golden set anchored to facts confirmed against ground truth; read-only execution checks against the live system; LLM-as-judge admitted only after calibration against those human labels; retrieval recall@N (leave-one-out) tracked as a health metric, not a per-case blocker.
+
+**Rule:** Build eval golden sets from human-verified, ground-truth-confirmed cases — never trust public benchmark labels or a raw LLM judge. Add live execution checks where feasible (does it build, run, resolve). Calibrate any LLM judge against the human labels before it gates anything. Track statistical health metrics (recall@N) as trends, not per-case pass/fail.
+
+**Applies in:** Eval pipelines, golden-set curation, LLM-as-judge deployments, agent-quality gates.
+
+## P-GLD-002 — Execution-gate corpus curation: admit only samples that compile AND run clean on the shipped toolchain, record every exclusion with a reason code, and regenerate by script — never hand-edit the corpus
+
+**Evidence:** A 6,332-program language-training corpus was built with a hard gate (compiles + runs exit-0 on the shipped compiler) and a full audit trail: 4,204 rejected candidates recorded with reason codes (compile_fail, run_nonzero, duplicate_of, env_dependent, ffi_dependent, secret). The corpus regenerates from a script; hand-editing is banned so the manifest, dataset, and exclusion log can never diverge.
+
+**Rule:** When curating a training/eval corpus: (1) gate admission on real execution against the shipped toolchain, not on inspection; (2) log every exclusion with a machine-readable reason code — the reject histogram is itself a quality signal; (3) make regeneration scripted and idempotent; never hand-edit corpus files, so manifest and content cannot diverge.
+
+**Applies in:** Training-data curation, golden corpora, conformance suites, fixture harvesting.