Reflect.ts "learn" step is self-invoked only — no enforcement, so the reflection corpus silently stays empty

[garthsch]

Version: Algorithm v8.17.3–v8.20.2 / LifeOS 7.28.3–7.40.4 (schema-9 Reflect.ts era, confirmed present at current upstream HEAD).

What's broken: LIFEOS/ALGORITHM/v8.20.2.md requires appending a reflection "at learn, for any run that did real work" via bun LIFEOS/TOOLS/Reflect.ts --reflection "...". Nothing calls this automatically — it depends entirely on the model remembering to self-invoke at the end of a run. No hook checks whether a real-work session produced a matching entry. hooks/WorkCompletionLearning.hook.ts looks like it might cover this (SessionEnd-triggered, writes to LEARNING/) but it only checks whether ISA claims were closed and writes an unrelated WORK→LEARNING bridge file — it never touches Reflect.ts or algorithm-reflections.jsonl. So every downstream consumer of that file (MineReflections workflow, Upgrade skill, AlgorithmUpgrade workflow) reads it expecting signal, and silently reports "0 entries" / "nothing to mine" instead of flagging that the capture step itself never ran.

Repro on a clean tree: Fresh install → run a session that edits files and/or dispatches agents (real work by any reasonable definition) → close the session without manually invoking Reflect.ts → nothing blocks close-out, no warning appears → MEMORY/LEARNING/REFLECTIONS/algorithm-reflections.jsonl gains zero entries for that session.

Negative control: Reflect.ts itself is not broken — invoked manually with a valid --reflection string, it validates and appends correctly against the schema-9 shape. The defect is purely the missing trigger/enforcement, not the writer.

Suggested fix (optional): A session-end check that detects "real work happened this session" (files touched, agents dispatched) and verifies a Reflect.ts entry exists for the session_id before treating close-out as complete — surfacing a nudge rather than silently passing. This is the same failure class #850 (closed 2026-03-02, v4.0.2) fixed via the ReflectionCapture hook and PhaseGate/ReflectionDigest (#735, #1029) — the capture mechanism changed shape since then (automatic hook → manual self-invoke), and the enforcement gap came back with it. WorkCompletionLearning.hook.ts is the natural place to extend, since it already runs on SessionEnd and already has the "did real work happen" significance test — it would just need a second check alongside the claims-closed one.

Severity (my own read, no severity label scheme exists in this repo): Medium — silent, systemic, non-crashing. No data loss, no crash, no security exposure, and the Algorithm keeps executing real work fine. But it defeats the reflection/upgrade subsystem's entire purpose by default on every install, and the failure is indistinguishable from "genuinely nothing to learn" unless someone manually interrogates the corpus.

[danielmiessler]

Accurate read of the code, and a no from me on the enforcement. The Algorithm is prompt-driven by design and loaded every turn; on this install 28 reflections landed in the last 7 days through exactly that path. A Stop-hook nudge for it is scaffolding a capable model doesn't need. If it ever stops firing that's a doctrine problem, not a hook gap. Thanks for the careful writeup.

[garthsch]

Data point for anyone else who hits this on a lower-tier-model install.

Checked self-invocation directly rather than trusting the reflections file's own metadata. Grepped every session transcript on this install for actual Reflect.ts CLI invocations (JSONL entries alone aren't proof — they can be backfilled): as of the original investigation, only 3 real calls existed in this install's ~4 weeks of Reflect.ts history, and every one followed an explicit prompt from me — none arose unprompted at learn. Of 11 entries then in the reflections corpus, 8 were retroactive manual backfills done specifically to answer this issue. (This same conversation has since added 2 more entries and 2 more real calls, both still principal-prompted — same pattern holding, corpus now 13/5.)

Model mix, measured rather than assumed: across 556 logged sessions on this install, Sonnet is primary in 436 (78%); Opus and Fable combined are primary in 9 (1.6%). So "prompt-driven by design" holds here too — the model runs the discipline fine once nudged. What's missing is unprompted initiation at learn, which is consistent with being capability-dependent, though I haven't isolated model tier from everything else that differs between our installs (n=1, no A/B).

One thing worth naming directly: "a capable model" is doing a lot of work in that close, and it's undefined — no tier, no benchmark, no floor. That's a fine design bet if LifeOS is explicitly opinionated about a minimum model tier. But the project frames itself as skills-based and model/harness-agnostic, which means an unstated capability floor on load-bearing doctrine (self-invocation at learn) is a real spec gap, not just an install-specific quirk — an operator on a lower tier loses the signal silently, with no way to know why until they go digging like this.

Not asking for hook enforcement back — that's the right call for an install where self-invocation demonstrably fires, as yours does. Asking for the assumption to be written down: even one sentence in the doctrine naming the capability floor this relies on would tell a lower-tier operator to reach for a compensating pattern (like the one below) instead of losing weeks of signal not knowing why.

Built a local compensating control: a weekly deterministic sweep (no LLM call, no live hook) that diffs closed/in-progress work against the reflections corpus and flags gaps for the next session to fill in by hand — detection only, never generates the reflection itself.