pan-wizard 3.12.2 → 3.12.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pan-wizard",
-  "version": "3.12.2",
+  "version": "3.12.3",
   "description": "Command a bot army for your codebase: an Opus Mission Control delegates whole-project goals to specialist squads and ships behind a human merge gate. Five AI CLIs, zero context rot.",
   "bin": {
     "pan-wizard": "bin/install.js"

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

@@ -1,6 +1,6 @@
 {
   "schema_version": 1,
-  "generated_at": "2026-05-03T06:35:05.956Z",
+  "generated_at": "2026-06-28T11:51:31.104Z",
   "topics": [
     {
       "name": "experiment-runner",
@@ -107,6 +107,24 @@
         "reviewer": "medium"
       }
     },
+    {
+      "name": "autonomous-loop",
+      "scope": "universal",
+      "file": "pan-wizard-core/learnings/universal/autonomous-loop.md",
+      "patterns": [
+        "P-310",
+        "P-350",
+        "P-360"
+      ],
+      "size_bytes": 10680,
+      "size_tokens_est": 2670,
+      "agent_relevance": {
+        "planner": "low",
+        "executor": "medium",
+        "verifier": "low",
+        "reviewer": "low"
+      }
+    },
     {
       "name": "binary-io",
       "scope": "universal",
@@ -532,9 +550,9 @@
     }
   ],
   "totals": {
-    "topics": 31,
-    "patterns": 63,
-    "size_bytes": 90658,
-    "size_tokens_est": 22674
+    "topics": 32,
+    "patterns": 66,
+    "size_bytes": 101338,
+    "size_tokens_est": 25344
   }
 }

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

@@ -1,11 +1,19 @@
 ---
 topic: autonomous-loop
-last_updated: 2026-06-12T00:00:00.000Z
+last_updated: 2026-06-28T00:00:00.000Z
 patterns:
   - id: P-310
     summary: Autonomous build loops should fan out research and verify in parallel but keep implement/build a single serial step, then seal with one clean build at loop end
     promoted_at: 2026-06-12T00:00:00.000Z
     source_experiments: [montyhall-focus-loop]
+  - 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]
+  - 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]
 ---
 
 # Autonomous Loop (AI-derived)
@@ -54,3 +62,29 @@ patterns:
 5. **Never let a schedule lower an irreversible-action gate** — scheduled or not, the human approves the merge. Autonomy extends up to the irreversible step, never through it.
 
 **Applies in:** `campaign.cjs` + `/pan:army --schedule` (ADR-0034), any cron/`/loop`-driven PAN automation, the self-improvement loop on a cadence.
+
+## 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.
+
+**Rule:** Whenever you review or merge a branch whose base can advance under it (every parallel campaign):
+
+1. **Diff against the merge-base, not the moved tip** — `git diff <fork-sha>..HEAD`, or three-dot `git diff main...HEAD`. Never two-dot `main..HEAD`.
+2. **Stamp the fork sha at worktree-creation time** so review and release always carry the correct base instead of recomputing it from a `main` that has since moved.
+3. **A surprising diff is a base smell first** — large phantom deletions/additions of code the mission never touched means "wrong diff base," not "bad change." Re-check the base before trusting any verdict built on it.
+
+**Applies in:** `pan-reviewer` / `pan-hardener` / `pan-integration-checker`, the `/pan:army` Quality + Release steps, `worktree.cjs` (record base sha), any parallel-branch review or merge.
+
+## 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.
+
+**Rule:** For any long-running, multi-step autonomous campaign, telemetry must survive the spawn pattern *and* be numerically sane:
+
+1. **Don't make load-bearing observability depend on a passive hook.** Subagent-stop events fire only for spawned subagents; a main-loop orchestrator's own tokens — and some headless runtimes — never trigger them.
+2. **Record per-step telemetry actively** at the Learn step — tokens (an estimate is fine), duration, role, outcome — via an explicit metrics-append, so capture survives any spawn pattern.
+3. **Never naive-sum a transcript to attribute one actor's usage.** Subagents share the parent session id, so summing all matching messages on every event counts the whole (growing) transcript repeatedly; cumulative-per-turn cache-read then explodes. Attribute per-event *deltas* (a high-water mark), prefer the event's own usage payload, and dedup identical writes.
+4. **Sanity-check before you trust the number.** A cache-hit pinned at 100%, or cache-read far exceeding input, is a miscount — not a triumph. Cap or flag implausible records instead of aggregating them.
+5. **Preflight a telemetry probe** at campaign start (write then read one record); treat empty *or* absurd telemetry as a defect, not a quiet state.
+
+**Applies in:** `/pan:army` Phase 0 + Learn step, `pan-conductor` campaign mode, `hooks/pan-cost-logger.js` + `pan-trace-logger.js`, the HUD telemetry panels, `/pan:cost`, `/pan:optimize`.