Investigate v5 Learning Loop integration — port-side curation layer + community research

[virtualian]

Context

The v5.0.0+ port plan (Plans/v5-0-0-plus-port.md, item #10 in the MED
list) flags the Learning standalone pack (~/.pai/skills/Learning/) as
"closes the /learn loop … v5 has nothing equivalent" and parks it for
later port work. A separate read-only investigation has now produced a
detailed contrast.

Report: reports/v5-learning-loop-vs-pack.md
(generated 2026-05-10; ~310 lines, citation-heavy).

Headline findings

• v5 has a substantial automated capture pipeline (5 capture hooks, 5
  readback functions injected per session, weekly LearningPatternSynthesis
  CLI, WisdomFrames with [CRYSTAL: %] confidence) but no human
  curation loop: no /learn, no AISTEERINGRULES.md, no PENDING/
  ACCEPTED/APPLIED proposal lifecycle, no force-loaded steering file.
• v5's system prompt actively counter-recommends writing behavioural
  rules to harness auto-memory ("infrastructure is the memory"). The
  fork's /learn apply writes "DO MORE" patterns there. Doctrinal
  conflict that needs deliberate resolution at port time.
• The fork's runtime learning-readback.ts is one function behind v5
  — missing loadSynthesisPatterns(). Adopting v5's hook code wholesale
  picks this up free.
• v5 chose CLAUDE.md @imports over loadAtStartup. Fork must decide
  whether to overlay loadStartupFiles() back in or migrate
  AISTEERINGRULES to an @import.
• v5's WisdomFrames is a different primitive the fork could adopt
  instead of (or alongside) AISTEERINGRULES.
• Neither side has runtime↔release drift detection for steering files;
  the fork accepts forward drift by design.

Scope of this issue

A. Port-side integration design

Decide how (and whether) to integrate the fork's curation layer on top of
v5's automated capture, given the constraint "don't change v5 if I can
help it":

• Resolve the doctrinal conflict on harness auto-memory — adopt v5's
  stance, retain fork's stance, or carve a documented exception
• Decide load-back primitive: overlay loadStartupFiles() /
  loadAtStartup or migrate to CLAUDE.md @imports
• Decide whether to adopt v5's WisdomFrames (with confidence gating)
  as the new write target instead of AISTEERINGRULES.md
• Pull v5's loadSynthesisPatterns() readback into runtime (free win
  regardless of larger decisions)
• Map fork's RatingCapture ↔ v5's SatisfactionCapture/
  SessionAnalysis consolidation; confirm pipeline inputs survive
  the swap

B. Community / ecosystem research (NEW — added per user direction)

The Learning Loop is the most-debated PAI subsystem (see closed cluster
#50, #73, #109, #141 + open #80, #86, #97). v5 is now public; investigate
what others are doing with v5's learning subsystem:

• Survey known forks of danielmiessler/Personal_AI_Infrastructure
  for Learning Loop modifications (GitHub fork list + recent commits)
• Search GitHub issues/discussions/PRs on upstream and notable forks
  for Learning, WisdomFrames, LearningPatternSynthesis, AISTEERING
• Check Daniel Miessler's blog / videos / Twitter for v5
  Learning-subsystem commentary post-release; capture the design intent
• Identify any third-party tooling that wires
  LearningPatternSynthesis.ts to a scheduler (cron, GitHub Action,
  CI) — v5 ships it without a trigger
• Note any community resolutions of the same doctrinal conflict
  (curation layer over auto-capture)

Report findings inline on this issue or in a follow-up
reports/v5-learning-community-survey.md.

Open questions from the report (§6)

These remain unresolved with file evidence alone and should be answered as
part of A/B above:

1. Has anyone ever run LearningPatternSynthesis.ts on v5? No
   cron/hook trigger ships in the baseline.
2. What writes ~/.pai/MEMORY/STATE/learning-cache.sh? The reader exists
   in both trees; the writer is invisible in the v5 distribution.
3. What does v5's install.sh actually deploy for
   skills/PAI/AISTEERINGRULES.md? config-gen.ts:34-35 references the
   path; the baseline tree has no such file.
4. Does v5's WorkCompletion-driven MEMORY/LEARNING/{ALGORITHM,SYSTEM}/
   feed back beyond loadLearningDigest()? If not, captures accumulate
   indefinitely as dead weight.
5. Is fork's RatingCapture.hook.ts a verbatim ancestor of v5's
   SatisfactionCapture.hook.ts? Line-by-line confirmation needed.

Out of scope

• Implementing any of the decisions above. This issue is **investigation
  • design**, not implementation. Implementation gets follow-up issues
    on virtualian/pai-v5 per the port plan's branch-as-feature workflow.
• Touching the Learning pack itself. That's Resync Research and Learning pack sources into ~/.pai/skills/ runtime #145.
• /learn extending to ingest CC per-cwd auto-memory. That's Extend /learn to ingest and curate CC per-cwd auto-memories (augment-over-override) #147.

Refs

• Report: reports/v5-learning-loop-vs-pack.md
• Parent migration: Migration: marrair → marrmini, adopt v5.0.0 as baseline, freeze v4.0.3+ #166
• Related open: Resync Research and Learning pack sources into ~/.pai/skills/ runtime #145 (Learning pack resync), Extend /learn to ingest and curate CC per-cwd auto-memories (augment-over-override) #147 (/learn ingest CC
  per-cwd memory), Promote interceptor skill from repo-local to ~/.pai/skills/ with PAI-flavoured triggers #155 (interceptor skill), feat: Scheduled synthesis — automated learning pipeline runs #80 (scheduled synthesis),
  feat: HITL approve/reject back-propagation of learnings #86 (HITL approve/reject backprop), System prompt memory instructions override PAI's own memory system #97 (system prompt memory
  override), Investigate: Claude Code harness auto-memory directive still routes agent writes to per-cwd ~/.claude/projects/.../memory/, independent of Learning skill (plus runtime-drift on #109 Part 2) #140 (Claude Code auto-memory routing)
• Related closed: Close the learning loop: synthesize signals into imperative behavioral rules #50, feat: Continuous HITL learning cycle — close the feedback loop #73, Learning skill writes feedback to Claude Code auto-memory, mislabeled as "PAI memory" + reads from stale ~/.claude/PAI/ tree #109, NATIVE mode and FAST-PATH atomic paths produce no LEARN reflection signal #141
• Design doc: Plans/v5-0-0-plus-port.md (item fix: rebuild SKILL.md with Algorithm v0.2.25 #10 MED, Learning
  standalone pack)

[virtualian]

Correction: item-4 "loadSynthesisPatterns free win" rests on a comparison error

Investigating MED#10 item 4 ("Pull v5's loadSynthesisPatterns() readback into runtime — free win") on 2026-05-20 surfaced that the substrate report (reports/v5-learning-loop-vs-pack.md) compared v5 against the runtime (~/.pai/) only, and never checked the Releases source (Releases/v4.0.3+/.claude/).

Actual three-way state

File	Runtime ~/.pai/	Releases v4.0.3+	v5 baseline
learning-readback.ts	222 lines, 4 exports	428 lines, 7 exports	281 lines, 5 exports
synthesis reader	absent	loadLatestSynthesis() (line 230)	loadSynthesisPatterns()
LoadContext wiring	imports 4	imports 5 (incl loadFeedbackMemories, NOT loadLatestSynthesis)	imports 5 (incl loadSynthesisPatterns)

Implications for item 4

1. The fork is NOT missing a synthesis reader. Releases has loadLatestSynthesis() — semantically equivalent to v5's loadSynthesisPatterns() (read SYNTHESIS dir → compact summary), under a different name.
2. The real gap is a WIRING gap, not a missing-function gap: Releases' LoadContext.hook.ts exports loadLatestSynthesis and loadBehavioralTrends but imports/calls neither — dead exports in the canonical source.
3. There's also runtime↔Releases drift: runtime (4 functions, paiDir convention) is behind Releases (7 functions, codePath() convention) — architecturally diverged, not just version-skewed.

So item 4 is mischaracterized

"Pull v5's function into runtime (free win)" should be re-scoped to one of:

• (a) Wire the existing loadLatestSynthesis into Releases LoadContext, then deploy Releases→runtime (uses fork's own code, no v5 import)
• (b) Replace loadLatestSynthesis with v5's loadSynthesisPatterns for upstream-naming alignment, then wire (churn for alignment)
• (c) Address the broader runtime↔Releases architectural drift first (separate, larger)

Decision deferred. The "free win" framing is retired — this is a wiring + drift question, not a missing-function port.

Process note

A first attempt edited the live runtime (~/.pai/hooks/...) directly before this was caught and reverted (runtime confirmed back to original byte counts 8057 / 18374). Editing unversioned runtime TS directly was the wrong target — Releases is the canonical source for hook code; the "runtime is canonical" rule applies only to /learn-extended AISTEERINGRULES.md, not TS hooks.

cc design doc Plans/v5-0-0-plus-port.md item #10 MED.

[virtualian]

Re-correction: item-4 is a clean DROP — verified against marrmini's deployed overlay state (2026-05-20)

Reviewed the actual v5 adoption target (not the marrair fork). Two facts settle item-4:

1. The overlay does not touch the learning subsystem. virtualian/pai-v5:bootstrap/v5-overlay-and-tooling → Releases/v5.0.0-overlay/ is 16 files (AISTEERINGRULES.md, askuq-gate.md, repo-url.ts, WorkArchival.ts, preserve-claudemd{,.test}.ts, README.md, SecurityValidator.hook.ts, settings.json.overlay) — no learning-readback.ts, no LoadContext.hook.ts.
2. marrmini's deployed state is pure vanilla v5.0.0 for this subsystem. ~/.claude/hooks/lib/learning-readback.ts = 281 lines, 5 exports including loadSynthesisPatterns (line 198); ~/.claude/hooks/LoadContext.hook.ts imports it (line 45) and invokes it (line 459). Verified via SSH 2026-05-20.

So loadSynthesisPatterns already exists and runs on the target host. Item-4 = DROP per the migration principle's first bar ("verify v5 doesn't already do it; if it does, drop the port").

Disregard the prior comment's framing

My earlier comment in this thread analysed marrair Releases/v4.0.3+ and the ~/.pai/ runtime — the fork being decommissioned, not the v5 target. Its "wire loadLatestSynthesis into fork Releases LoadContext" framing is the wrong tree and should be disregarded for v5-adoption purposes. (The three-way divergence it documents is accurate as marrair-internal trivia, but irrelevant to what lands on Releases/v5.0.0-overlay/.)

Real MED#10 candidate

The synthesis reader was a mis-itemized sub-task. The fork's genuinely v5-absent contribution is the /learn check|review|apply curation pipeline (substrate report §5: "net-new behavioural infrastructure; no v5 piece to defer to"). That — plus the doctrinal-conflict resolution in this issue's Part A — is the actual MED#10 work, and it would land as overlay files under Releases/v5.0.0-overlay/ if pursued.