What each number counts
The repository is private, because it holds my calendar, my grades and my notes. That is a real limit on what you can verify here and I am not going to pretend otherwise. What follows is the method behind each figure and the artifacts behind the claims, which is the strongest thing I can publish without publishing my own life.
Collected by pytest --collect-only -q across the engine, the control panel and the build tooling. The run below is the same suite executing.
Rows marked done in the phase table. Each closed against an acceptance sentence written before its code existed. 1 is marked superseded and is shown in full further down.
git rev-list --count HEAD on the single repository holding the engine, the wiki, the courses and both websites.
Entries in DECISIONS.md, each carrying its reasoning and the alternatives that were rejected. One is reproduced in full below.
Directories under simulations/. Every one is a batch of scenarios whose expected outcomes were written before the run, kept afterwards as regression tests.
Markdown pages under vault/wiki/, where every claim carries the source it came from. The pages themselves stay private; they hold my own notes.
One figure is not counted from the repository, so its method belongs here. A single working session, metered through the tool's own usage report, cost $138.40. At about twenty sessions a month that is $2,768. Measured the other way, the same session used about 24 percent of a weekly limit, which puts the month near $2,508. The two agree within ten percent, so the range is $2,500 to $2,800 a month of metered usage against a $20 subscription. The second figure assumes a usage limit tracks dollar cost proportionally, which is an assumption and not a measurement. None of it is a claim about what the work is worth. It is what the same work costs at list price.
The test suite, actually running
Not a screenshot of a number. This is the tail of pytest -q on the repository as of
05 August 2026, every test passing.
============================== warnings summary ===============================
.venv\Lib\site-packages\fastapi\testclient.py:1
C:\Users\ryan0\OneDriveNew\OneDrive\My Second Brain\.venv\Lib\site-packages\fastapi\testclient.py:1: StarletteDeprecationWarning: Using `httpx` with `starlette.testclient` is deprecated; install `httpx2` instead.
from starlette.testclient import TestClient as TestClient # noqa
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
1408 passed, 1 warning in 119.09s (0:01:59)
The suite covers the scheduling engine, the calendar gateway, the study reflow, the capture listener and the build tooling. Tests are written against behavior rather than internals, so a module can be rewritten without rewriting its tests.
How a phase closes
Every phase states, in one sentence, what has to be true before it can be called done. The sentence is written before any code exists, and it does not get edited afterwards. That last part is the whole point: an acceptance test you are allowed to rewrite once you have seen the result is not a test, it is a description of whatever you happened to build.
The clearest evidence that the rule is real is the phase that failed it. Phase 35's acceptance depended on a hook that a later architectural decision removed, so its sentence could never be true again. The tempting move was to reword the criterion so it passed. It is marked superseded instead, with a note naming the phase that absorbed the remaining work, and it stays visible in the table.
67 rows in total, 61 done, 1 superseded. Eight shown.
Proving it against scenarios, not vibes
Before a component takes over anything live, it runs against a batch of written scenarios whose expected outcomes were recorded first. If a run disagrees with an expectation, the assumption is that the code is wrong, not the expectation. The batches are never deleted afterwards; they are the regression suite. There are 15 of them.
behaviorcapturecharacterdigestenergyevening_tickfeasibilityfocusmistakesmulti_courseschedulesleep_pullstudytaweekly_review
One decision, in full
Hard-to-reverse decisions get written down with their reasoning and the alternatives that were rejected, so that a choice made for a specific reason is not quietly undone six months later by someone who cannot see the reason. There are 129. This is the one that shaped everything else, reproduced exactly as it appears in the repository.
Decision 103 — Daily systems migrate off Claude onto a local engine: code-first, local LLM at the edges (grilled 2026-07-04)
Decision. The daily systems (Morning run, schedule, study reflow, Energy capture, Weekly Review) migrate off Claude Code onto a Daily engine running locally: deterministic Python computes everything mechanical, and a free open-source model handles only the language-shaped edges. Claude is retained for ingest, wiki/curation, audits, and design sessions. Six locks from the grilling:
- Driver = budget first, always-on second. The 5-hour Claude usage cap is the binding constraint, and the daily loop burns it on mostly-mechanical work every day. Secondary: the morning run should fire on a timer with no session open.
- Code-first, LLM at the edges. Date math, the reflow cascade, retention-interval scheduling, canvas construction, and ledger writes are deterministic rules — Python owns them outright, no LLM involved. The local model is called only for genuinely judgment-shaped work: wording the morning digest, weighing tradeoffs when misses pile up. Rejected: local model executes the prompt procedures wholesale (a 14B model following a 679-line procedure makes arithmetic and rule-following errors Claude doesn't; the calendar would be maintained by the least reliable option available).
- Runtime = Ollama as a Windows background service; starting model in the Qwen3-14B class (hardware verified 2026-07-04: RTX 4080 Laptop 12 GB VRAM, i9-14900HX, 32 GB RAM — runs 8–14B fast, 30B-class MoE at usable speed). The model is swappable without touching the engine.
- The prompt procedures remain the behavioral spec.
prompts/schedule.md,study.md,energy.md,weekly_review.mdstay the source of truth for behavior; the Python must provably match them, with the Simulation harness (Decision 86) as the parity gate — scenario batches must pass before any system cuts over. - Always-on delivery = app + Telegram. Windows Task Scheduler fires the engine (~7 AM); the digest (today's plan, missed-day flag, energy reminder) lands as a Telegram message per Decision 79's digest channel, with full detail in the Cockpit (Decision 104). The
pushgate survives migration — no calendar write without explicit approval, now given in the Cockpit instead of a Claude session. - Interim state. All three daily-system hooks were halted 2026-07-04 (commit
7c3f422) and stay off; the current prompt procedures are the fallback (run manually in a Claude session) until each system's engine passes its parity gate and cuts over, one system at a time.
Reasoning. The daily loop is ~1,700 lines of procedure that is mostly date arithmetic wearing an LLM costume; paying Opus-class tokens daily for it is the single largest recurring spend in the system. Local models are weakest exactly at long multi-step procedural reasoning and strongest at short prose generation — the code-first split assigns each part to what's reliable at it. This also finally ships the Autonomous morning run rung that Phase 24 blocked on (Claude Code's phone push can't fire headless; a local engine posting to Telegram has no such limit). Decision 3's posture is not violated: its code trigger fired at Phase 04 and ~30 helpers already exist — this is the earned continuation, not a premature pivot. Hard to reverse (a second execution substrate for the daily loop), surprising without context (the system's daily heartbeat stops being Claude), and a real trade-off (Claude-quality judgment daily vs. budget + autonomy) — earns an entry.
Future notes. Migration order and per-system parity gates get their own phase docs. If the local model's judgment edges prove weak in lived use, the escape hatch is narrowing its role further (more code, less prose), not returning the loop to Claude.
One module, and its test
Everything above is about process, and process is easy to claim. This is a real module from the engine. It decides how a long-polling listener should respond to a failure: wait it out, or stop. It is pure, with no file access, no network and no clock of its own, which is what makes it testable at all.
"""Poll failure policy for long-poll daemons (Phase 45.5, Decision 123). Behavioral spec: prompts/capture.md v1.4 §7.1. A long-poll listener fails two ways that demand opposite responses, and conflating them is how a daemon dies silently while still running: a *recoverable* failure (unreachable, timed out, temporary server error) is worth waiting out, while a *permanent* one (credentials rejected) never heals. This module owns that judgment and everything downstream of it — the back-off arithmetic, the Poll-incident bookkeeping, the sustained-outage threshold, and the halt decision — behind two methods. Deliberately pure: no file access, no network, no clock of its own. The caller supplies the time and carries out the returned PollAction. Named for the general concept rather than the Capture inbox because Run record and Poll incident are daemon-wide terms (UBIQUITOUS_LANGUAGE.md). The *logic* is general; the two user-facing strings in `_halt_action` are Capture-shaped, and should be parameterised the day a second poller adopts this — not before. """
The judgment that matters is in the middle. Elapsed time is measured on a monotonic counter rather than the wall clock, because this machine resyncs its clock by hours around sleep, and a three-hour jump must not be recorded as a three-hour outage.
class PollPolicy:
"""Tracks one Poll incident at a time and decides the response to each poll."""
def __init__(self, *, monotonic_fn=time.monotonic) -> None:
# Elapsed time is measured on a monotonic counter, never on the wall
# clock: this machine resyncs its clock by hours around sleep (System
# log 2026-07-17/18), and a three-hour jump must not read as a
# three-hour outage. Wall-clock `now` survives only for stamping.
self._monotonic = monotonic_fn
self._clear()
def _clear(self) -> None:
"""Back to no-incident-in-flight: the state a healthy listener sits in."""
self._wait = _BASE_WAIT
self._opened_at: datetime | None = None
self._attempts = 0
self._kinds: tuple[str, ...] = ()
self._notified = False
self._down_for = 0.0
self._last_tick: float | None = None
self._last_wait = 0.0
def _accrue(self) -> float:
"""Add the gap since the previous poll, capped at what we actually asked
for plus one poll's worth of slack.
A larger gap means the listener was not polling and failing through it —
the machine was suspended, or the clock moved underneath us. Counting it
would surface a night of sleep as a nine-hour outage and buzz the phone
the moment the lid opens.
"""
tick = self._monotonic()
if self._last_tick is not None:
gap = tick - self._last_tick
self._down_for += max(0.0, min(gap, self._last_wait + _POLL_ALLOWANCE))
self._last_tick = tick
return self._down_for
And the test that holds it in place:
def test_first_recoverable_failure_opens_an_incident_and_waits_five_seconds():
line = _Timeline()
action = _policy(line).on_failure(
TimeoutError("The read operation timed out"), line.now
)
assert action.wait_seconds == 5
assert action.halt is None
assert action.notify is None
assert len(action.events) == 1
assert "timed out" in action.events[0]
# --- backing off ------------------------------------------------------------
def test_consecutive_failures_double_the_wait_up_to_a_five_minute_ceiling():
line = _Timeline()
policy = _policy(line)
waits = [_fail(policy, line).wait_seconds for _ in range(9)]
assert waits == [5, 10, 20, 40, 80, 160, 300, 300, 300]
The repository stays private while it holds my own life in it, so the public piece is the machinery with none of my data in it: bindery is the build that turns the calculus workbook into something sellable, extracted, ported to Python and MIT licensed. It refuses to produce a file when the author's own notes survive into it, which is the only part of it worth copying. If you want to see anything else here in more depth, email me and I will walk you through it.