SessionStart dynamic context is empty by construction: LoadContext reads three sources nothing ever writes

[jacobo-ortiz]

Version: v7.1.1

The defect

hooks/LoadContext.hook.ts builds its <system-reminder> from three dynamic sources. On this install all three are empty by construction, so the hook takes its empty branch and emits only:

✅ LifeOS session ready...

28 bytes. Exit code 0, no warning. Not even the ⏭️ Skipped … (disabled) line, because the features are enabled; their data sources are simply never written.

Repro

echo '{"session_id":"probe"}' | bun ~/.claude/hooks/LoadContext.hook.ts | wc -c
# 28

The three sources, and who writes them

1. LIFEOS/MEMORY/WISDOM/FRAMES/ is read by loadWisdomFrames() in hooks/lib/learning-readback.ts, which scans *.md for ### <name> [CRYSTAL: N%] headers. LIFEOS/TOOLS/WisdomFrameUpdater.ts exists and would produce these, but nothing invokes it: no hook registration, no cron entry, no other script references it outside documentation. On my install, git log --all --diff-filter=A -- 'LIFEOS/MEMORY/WISDOM/FRAMES/*.md' is empty. No frame has ever existed.

2. LIFEOS/MEMORY/RELATIONSHIP/YYYY-MM/YYYY-MM-DD.md is read for today and yesterday only. Nothing in the tree writes these files. They appear only when the assistant happens to write one by hand mid-session, which is sporadic, so the today-or-yesterday window almost never hits even when files exist. Mine has 8 files across 5 months.

3. LIFEOS/MEMORY/STATE/progress/ is written only by LIFEOS/TOOLS/SessionProgress.ts, a manual CLI whose invocation LoadContext itself prints as a hint. Where the user has never run it, the directory does not exist.

The 2026-07-10 change that made this total

The code documents it at hooks/LoadContext.hook.ts:426:

// 2026-07-10 directive: keep ONLY the Wisdom Frames — the actionable
// behavioral guidance. Dropped the self-rating wall (Performance Signals,
// Complaint Clusters, Recent Learning Signals, Recent Failure Patterns): it was
// negative session-start priming and the biggest single one-time context block.

Dropping that wall is defensible on its own terms. The side effect is that the one source left standing is the only one with no producer, so the block went to zero. Measured on my install: 45 of 45 sessions before that change emitted over 200 bytes; 60 of 60 after emitted the 28-byte stub.

Why nothing caught it

LIFEOS/TOOLS/MemoryHealthCheck.ts reported "overall":"ok" for 60 consecutive runs across the same period. Every one of its checks asserts that a file or a hook registration exists; none asserts that a hook produces output. Presence is not delivery.

Suggested direction

Two independent fixes:

1. Either schedule the wisdom-frame generator and create the directories at install time, or drop the sources that have no producer. Right now there is a reader with no writer, which is invisible precisely because the empty branch looks like success.

2. Add a health check that asserts delivery. Comparing the hook's output length against a floor would have caught this on day one.

For what it is worth, I pointed the dynamic block at LIFEOS/MEMORY/WORK/<slug>/ISA.md instead, which is the one corpus written on every substantive run, and read back decisions and open claims from the last 72 hours. That took the block from 28 bytes to about 2.4 KB of genuinely useful continuity, at roughly 690 tokens. Happy to send a PR if that shape is interesting.

[anikinsasha]

This is right, and it is worse than it looks. I re-read the tree at v7.28.3 — you
filed against v7.1.1, and the release that shipped the next day does not change your
finding. Two facts sharpen it.

1. The relationship source wasn't sporadic — its writer was deleted.

RelationshipMemory.hook.ts shipped in the payload and was registered under
SessionEnd at v6.0.0, v6.0.2 and v6.0.5. It is absent from the v7.0.0 payload
onward. The docs record that as deliberate: HookSystem.md:123 calls it "retired
2026-07-11 … relationship signal is carried by the autonomic memory reviewer
instead", and LifeosSystemArchitecture.md:589 calls it "deleted 7.0.0 — dead code".

What survived is the reader and the paperwork around it:

• the SessionStart reader itself — LoadContext.hook.ts:91, called at :414
• its knob, still defaulting on — settings.system.json:368, "relationshipContext": true
• three tables in MemorySystem.md that still name the deleted hook as a current
  writer, in the present tense: the capture-flow diagram at :42, the hook→path table
  at :636 (RelationshipMemory.hook.ts | UserPromptSubmit / Stop | RELATIONSHIP/YYYY-MM/YYYY-MM-DD.md), and the source table at :976
• CurationCoverage.md:60, which still gives MEMORY/RELATIONSHIP/** a cadence of
  "Per turn (batched)"

The same document already knows better. The memory inventory row at
MemorySystem.md:283 now marks RELATIONSHIP/ a "dormant archive", states that all
three writers "are gone from disk", and lists its writers as "(none — read-only
archive)". So MemorySystem.md contradicts itself three tables later, and the reader
is wired to the losing side.

2. The wisdom source has a graduation path — and it writes a format the reader
cannot see.

The reader loads ### Name [CRYSTAL: N%] and keeps only N ≥ 85 — regex at
hooks/lib/learning-readback.ts:154, floor at :157. Tree-wide, CRYSTAL appears in
exactly two files: that reader, and WisdomCrossFrameSynthesizer.ts:85, which only
reads those headers. Nothing writes one.

Meanwhile there is a shipped Graduate button. PULSE/modules/hypotheses.ts:240
graduateToFrame() either seeds a new frame with # Frame: <slug> / ## Meta /
## Core Claim (:246), or appends a ## Hypothesis-Sourced (<stamp>) section to an
existing one (:254). Neither form emits a CRYSTAL header. WisdomFrameUpdater.ts:220
writes the placeholder "No crystallized principles yet. Observations accumulating."
and contains no CRYSTAL string at all.

So this is not a source with no writer. It is a source whose writer and reader disagree
on the format. A person can work the review queue, click Graduate, get a real frame
file on disk, and still see nothing at session start — indefinitely, with their own
action as camouflage. That is a worse failure than an empty directory, because it looks
like it worked.

The chain as it ships, a third gap, and what I'd propose

The chain. SatisfactionCapture.hook.ts (registered, UserPromptSubmit —
hooks/hooks.json:212) → MEMORY/LEARNING/SIGNALS/ratings.jsonl → the nightly
com.lifeos.deriver launchd job running LearningPatternSynthesis.ts --hypothesize
(floors at :67-69 — confidence ≥ 0.6, sample ≥ 5, ≤ 3 per run) →
MEMORY/WISDOM/FRAMES/_hypotheses/ → human review in Pulse at /upgrades
(/hypotheses was folded in on 2026-07-23 and now redirects — UpgradesSystem.md:50)
→ graduateToFrame() → loadWisdomFrames() at SessionStart. Every piece ships, and
every piece works in isolation. The last handoff is the format mismatch above.

The third gap: the engine is unadvertised. Tools/DeployComponents.ts:56-60
carries deriver among sixteen launchd components, and LIFEOS/TOOLS/Services.ts:49
marks it optIn: false — default-on, rendered as core in the generated
BackgroundServices.md:45. But neither install menu lists it: INSTALL.md:124-132 and
Workflows/Setup.md:40-50 each advertise seven optional components, and Setup routes
launchd installs through DeployComponents --components <csv> with only what the user
picked. bun Services.ts install would install it (Services.ts:197 targets
everything not optIn), but no documented install path runs that command.

Its stated purpose is also wrong, and that text is now generated rather than
hand-written: Services.ts:50 says the deriver "Regenerates Pulse's derived Data-Plane
pages on a cadence", while PULSE/manage-deriver.sh:84 execs
LearningPatternSynthesis.ts --hypothesize. BackgroundServices.md is stamped from
that row, so the wrong description now propagates automatically.

Net: a fresh install emits nothing from this channel indefinitely unless the operator
installs a service no menu mentions, works a review queue they were never told about,
and then hits the format mismatch anyway.

Your third source, STATE/progress, is a separate dead path — SessionProgress.ts
is a manual CLI. Worth noting that the ISA-based continuity readback you suggest as the
alternative is substantially what #1714 implements. That one is mine and still a draft,
so treat it as a cross-reference rather than an answer.

What I'd propose, if useful:

1. Add deriver to both menus, and fix the Services.ts row both ways — the purpose
   text, and whether default-on is what you actually mean. That is the whole fix for
   the third gap.
2. Make graduation write what the reader reads. Either graduateToFrame() emits a
   ### <name> [CRYSTAL: N%] header, or the reader stops requiring one — but one of
   the two, because a Graduate button that produces invisible output is the worst of
   the three states. If it emits a number, make it explicit rather than defaulted:
   hypotheses are derived at 0.6 and the reader loads at 85, so a defaulted number
   would write a correctly-formatted frame that is silently ignored forever.
3. A delivery-focused health check that cannot become a nag: one line, only when a
   human action is actually waiting — hypotheses pending review, or ratings
   accumulating with no deriver installed. Probe installed state via launchctl
   rather than inferring it, since "ratings but no hypotheses" is also what a healthy
   deriver below its floors looks like. Silent on cold start and on non-macOS.
4. The relationship leg is a decision, not a fix: retire the dangling reader and its
   knob (smallest diff, and it matches what MemorySystem.md:283 already says), or
   restore the writer from v6.0.5 history if the retirement was collateral. Either way
   the four stale tables above want fixing.

One adjacent thing while you are in there: hooks/README.md:171 describes
LoadContext.hook.ts as injecting "identity, work, projects". It injects neither
identity nor projects — which is part of why this went unnoticed.

Questions only you can answer:

• Has any install ever graduated a frame that the reader then loaded? If yes, by what
  means?
• Is the intended CRYSTAL producer the Pulse review UI, a CLI, or the planned monthly
  cron (CurationCoverage.md:61)?
• Is the relationship leg retire-the-reader or restore-the-writer?
• Which components are the install menus meant to advertise? DeployComponents
  knows twenty-one; the menus name seven. deriver is the one with a shipped consumer
  chain, but pulse-menubar, conduit, conduit.insight, synthesis and the rest sit
  in the same position. Fixing deriver alone leaves the gap open for the next one.