One row per shipped version, newest first, written by the session that ships it. The full record of every version
(design, numbers measured, what was verified against what was assumed) is the living doc DAEDALUS-DESIGN.md §14 —
this file is the short version a non-technical reader can follow. The commit fence (Appolis changelog rail, 2026-09-19)
refuses a version bump that does not carry a row here in the same commit.
--plan-week weighs the week's answers at list price from every transcript and pushes shares only (the weight stays on the PC), filing the week's note to Kosmos once per window through a one-name list (kosmos_create_note); the Claude percent is read live from the status line (installed byte for byte by --plan-live-install, silent, push at most every 20 s, retried by the 2-minute sweep, with a 15-minute backstop that never asks for a token); the Codex percent comes from the newest rollout's tail. readLimits({ refresh:false }) stops at an expired token and never posts to the token endpoint - the only change to limits.js. NOT YET: the deploy, the migration on live D1, the status-line install, the first note. 951 worker tests (A1-A12 on the real copy of live D1: 25 tables), 453 local tests (L1-L9).--odometer-sweep --active 10 measures only the sessions written in the last 10 minutes and never moves the hourly sweep's state. --odometer-live install|status|remove registers the Windows task DaedalusOdometerLive to run it every 2 minutes. (5) THE BACKFILL ROAD: --odometer-sweep --since <iso> --force re-measures sessions whose local reading is already newer. It exists to file the 364 September-October sessions that were pushed before v0.54.1's project tagging (all their transcripts are still on disk). Gates: worker 938/938, local 444/444. 19 test files re-pinned: 17 worker files for the migration count (18 → 19, and the newest file's name) and 2 local files for the version number. Nothing else changed in them. NOT YET DEPLOYED in this commit: the worker deploy, the task install and the backfill each wait for Tyler's go.hands.js --odometer defaults to the Worker SUGGESTED knobs (warn 500000 · handoff 700000 · turns 375) instead of 200000/300000/150, source suggested (explicit flags still win, source flags; a Worker answer keeps printing the Worker knobs_source). (5) THE PRICE: plan_tokens and plan_equiv_usd (priceReading) are on the ODOMETER printed line and in the LOCAL reading file only - the push body is byte-for-byte what Worker 0.52.0 accepts. (6) ATTRIBUTION FROM THE TRANSCRIPT: project = the slug of the first kosmos/<slug> lane (else repo/<folder>) of the first appolis_clock_in, routine_id = the first daedalus_step input.routine; --project / --routine win. (7) THE SWEEP: new local/lib/odometer-run.js (measureAndPush, the core runOdometer now shares, and sweepOdometer) and node local/hands.js --odometer-sweep [--since <iso>] [--dry] measure and push every top-level session transcript touched since the last sweep (sweep-state.json, else two hours), skip a file whose local reading is newer, print ODOMETER_SWEEP files= measured= pushed= skipped= failed= since= and one ODOMETER_SWEEP FAIL <id> <why> per failure, exit 1 on any failure; the state moves only after a clean non-dry run; local/lib/motion-loop.js run() runs it after each hourly tick and appends its lines to the same log - a sweep failure is printed and never changes the tick verdict (a suite under node --test without MEASURE_HOME skips it; --motion-loop status ignores ODOMETER_SWEEP lines). (8) LIMITS bad-shape (consent note_6069): the real usage answer carries five_hour: null beside a valid seven_day; local/lib/limits.js now treats one valid window as figures (the missing one prints none and stays null) and only an answer with neither is bad-shape. (9) sub_agents_detail ({ agent_id, model, turns, last_ctx, last_ts } per subagent with turns, from its newest-timestamp line) joins the LOCAL reading file only, beside last_ctx and measured_at. Tests: new local/tests/odometer-v0252.test.js (10: chunk boundaries and multi-byte, NO_TRANSCRIPT, replayed-id last_ctx, the regex cases, attribution and flag precedence, knob defaults, plan figures, sub_agents_detail, the sweep with dry / skip / subagents ignored / no key / exit 1, LIMITS five_hour null, version); local/tests/limits-push-v0251.test.js LV1 re-measured from 0.25.1 to 0.25.2; local suite 427 -> 438, worker suite 933/933 unchanged (both rerun by the orchestrator). (10) AN EMPTY SESSION (found by the first live sweep, session 6e4fca06: one assistant line, no answer with a context): measureAndPush({ skipEmpty }) returns it as empty and the sweep counts it skipped with an ODOMETER_SWEEP EMPTY <id> no answer with a context (not pushed) line - before, the Worker refused it (400 model required), it counted as failed and the sweep state would never move again; pinned by S11. LIVE (2026-11-04): --odometer-sweep --since 2026-11-01T00:00:00Z pushed 24 of 25 (the empty one refused), then after (10) files=25 measured=1 pushed=1 skipped=24 failed=0 and sweep-state moved; daedalus_odometer day 2026-11-04 then served 10 sessions with project filled from the clock-in (hephaestus, solarwrld, theatron, appolis, mission-control, footage-clean-up, politics-sesh), knobs 500000/700000/375 and connector_writes counted (17 on the measuring session). The measuring runs on the PC, so no worker deploy is needed for any of it; the shared worker/src/lib/odometer.js is served at the next worker deploy. Not yet proven: the hourly timer running the sweep on its own tick.GET /api/road?kind=&size=&listening=&urgency=[&model=] and the connector tool daedalus_road (a member tool) walk Tyler's ladder - (1) the local daimones $0 for reads · maps · summaries · drafts · refutations, (2) the Claude plan through a listening session, (3) the Codex plan as a sandbox PROPOSAL for build · run · apply (law 8; its usage prints unknown), (4) the Anthropic API credit through the person's own Appolis key for sessionless jobs and, by THE RAMP, as overflow: every band and number a named knob with his value as the default (ROAD_RAMP_JSON overrides) - below 80% of the plan nothing spills; 80-90% only a job that cannot wait (urgency:now); 90-95% a growing share, counted against the picker's own last 50 picks; at 95% the API takes the overflow and the plan's last 5% is HELD for build · run · test · apply · deploy; at $20 of credit left the held 5% and the credit split 1:1 (1:1:1 with Codex once its row carries the craft); the credit gone = the plan carries all - the band is printed on every answer. THE LIVE CREDIT (new lib credit.js + the owner tool daedalus_credit): spent counted live from every call's own usage block (the consumer posts one ledger row per call, refused calls included), reconciled hourly against Anthropic's GET /v1/organizations/analytics/cost when the Worker holds an Admin credential (secret ANTHROPIC_ADMIN_KEY, never printed; an individual account or no key prints its status by name), Anthropic's own no_credit / spend_limit / spend_cap answer as the hard stop; the ONE number entered by hand is a top-up, once per top-up (no Anthropic endpoint returns a balance - measured on the live docs). Honest unknowns by name: a stale door closed · last_seen=<iso>, a plan reading over 6 h old stale -> no overflow, no reading unknown. One new pure lib road.js + credit.js reusing providers.js · router.js (tierPriceFor exported, one word) · prices.js · meter.js; BLOB_KEYS + plan-limits + credit (the KEPT limits and the credit record ride the existing push-key blob road; local 0.25.1's odometer tripwire posts the five plan figures - never a token - and triggers the reconcile); the KosmosLink binding and the mission-control key admit GET /api/road, the owner push key POST /api/credit/reconcile, and nothing else new. Pinned by worker/tests/road-v0540.test.js RD1-RD14 (ROAD_PICKER ok=14 fail=0 …), red at d1205e9, green after; 12 owner-count pins 20 -> 22, 3 member pins 13 -> 14, BLOB_KEYS, the v0410 fixture re-cut by script; worker 933/933 (DAEDALUS_REPO set) · local 427/427; /health 0.52.0 served (live, Version 742e1ba1, deployed 2026-11-01; C12 green); the first top-up entered $204.34 on 2026-11-04 (Tyler, form note_9224 Q1; the $205.71 of note_8881 was never entered) (status reconciled: the first real reconcile 2026-11-04T14:42Z read spent $0.1592 from Anthropic's cost report); three CREATEs filed (Kosmos todo_9225: ask the picker + post the row; Appolis todo_8891: the usage block + the refusal word; Kosmos todo_8890: Codex in the Kosmos chat for a usage source). Full record §14.76.--motion-loop status prints bare_stops=<n> (the old v0.51.0-shape STOP lines with no by= that the timer count could not see) and login=<the last MOTION_LOOP_ENV line's login= value, else none> before last_timer= and last_line=; a refused or failed write is named MOTION_LOOP STOP d1write by=<by> status= stdout_bytes= parsed= stderr_lines= stderr_file= with the same facts a failed read carries (d1read stays only a read's word); local/tests/motion-loop-v0530.test.js (family MOTION_LOOP_LANDS) pins it, written red first; local/package.json 0.25.0 and the one local-version pin in local/tests/park-v0300.test.js re-measured from 0.24.x to 0.25.x; the chain (the payload's own checks, not served): drills/routine-stub-live.mjs reads rendered_sha from the saved routines page by the routine's id and names rendered_sha=absent:<keys> when the row has none, measure/form-pick.mjs reads each question's marker from the form file and writes one answer file per question, the owner-identity check is graded to the shape account=acc_[a-z0-9]+, ship.sh's board gate names the reds from check-drills.out's own FAIL lines with no per-red case, J6 refuses to start until the ship phase's check has run and is green, the no-deploy road (SHIP_DEPLOY=none) carries the commit and the docs mirror, a closeout under an unattended run names pane rows as skips, and the bill resolves each seat by its own session and gives a patch builder a key; no worker file moves (VERSION 0.51.0, /health 0.51.0 env live, no new build - the shipped record says version_id=none build=none); the patch that went first is v0.52.4 (local 0.24.4, its own row below, form note_8825 answer A) — the hourly timer that refreshes the Motion dashboard now runs green on its own, a read refused right after a sign-in refresh is tried once more, and the release checks read what the pages really sayWhat changes for you: (1) THE TICK THAT LANDS. A FINDING from the timer's own log on your PC (lines 12-23 of ~/.claude/daedalus-motion-loop.log): since 11:44 UTC the hourly task that refreshes the Motion dashboard has found the Cloudflare tool every time (the previous fix was right about where it lives) and then the tool itself has crashed before answering, five ticks in a row (11:44Z, 12:44Z, 13:44Z, 14:44Z and 15:33Z, the last one started by hand through Windows), with the same message each time (Assertion failed: !(handle->flags & UV_HANDLE_CLOSING)). The very same tool, run from inside the Claude app at 15:31Z, answered fine, twice, both plainly and in a hidden window - so the fault is the setting the scheduled task runs in, not the install and not the hidden window. THE THEORY, and it is only a theory: the tool's sign-in file was saved from inside the Claude app, so it sits in the app's private copy of your AppData, and the task, which runs outside the app, starts the tool signed out. That fix shipped FIRST as its own patch, v0.52.4 (local only, nothing deployed; your answer A, "Patch first", on form note_8825): the task now writes down which sign-in it can see, points the tool at the app's copy only when no other sign-in exists, and every failed read saves the tool's exit code, how much it answered, whether that parsed, and its whole error text to a file beside the log. The sign-in file itself is never opened, copied or moved. This version adds no fix to the sign-in - it was built around the test of it: the timer's own next lines decide. A green timer tick (the log line MOTION_LOOP tick=... by=timer ... drift_after=0) proves the theory; login=real on the timer's evidence line kills it at once (your normal sign-in was there all along); login=packaged with xdg=applied and the same crash says the sign-in was not the cause. Either way no further patch is written on a guess: the evidence lines are the next theory's only input. Since the patch was committed the timer has run three times on it (its own log lines): two runs started by hand through Windows at your ask - 17:03 UTC red (the sign-in WAS found, login=packaged with xdg=applied, and the crash was gone, but the tool renewed an expired sign-in token and Cloudflare then refused the read, 403 code 7403) and 17:06 UTC green, the first green run the timer ever had - then the normal hourly run at 17:44 UTC, green too (timer_ok=2). The login theory holds. The one refusal after the token renewal is a second theory, not a proof: this version retries a read refused with code 7403 once (never the write) and names the tool's own error text instead of a lone {. (2) THE CHECKS READ THE PAGE. The three red checks of last time were the checks' own fault: the routine-file check now finds the routine by its id on the saved page and reads the checksum Daedalus actually serves (and if a row ever has none it says exactly which fields it did find, instead of printing a bare "unread"); the form-answer check reads the question's wording from the form file itself, so what is posted and what is read cannot drift apart, and each question's answer file is written by that reader, never copied by hand; the owner-identity check is pinned to what the gate really says (to Daedalus you are acc_8b23f06c8186; on Kosmos you are acc_root - two ids, one person, now written down) and is graded, so a red there can no longer slip past. (3) THE CHAIN STOPS FIBBING TO ITSELF. The board gate reads the drills check's own FAIL lines (no per-red special case in the ship script ever again); the "ship check" that never ran last time is now a gate - the live checks refuse to start until it has run and is green; a closeout under an unattended run lists the pane rows as named skips, not failures (last time it read items=6 ok=2 fail=4); and the bill finds a reviewer that ran in a second chat window by that seat's own session record, and a patch builder gets a key of its own. The status line also stops under-counting the old timer stops (it printed two where the log holds six) and shows which sign-in the last tick saw, and a refused or failed write is named as the write's, not the read's. (4) NOTHING SERVED, NOTHING DEPLOYED. The worker stays 0.51.0 (no worker file changes), so this version runs on the no-deploy road: the commit, the record and the docs mirror (which also catches up the three patch rows it was missing) - and no deploy go is asked, because no deploy happens. The local door on your PC moves to 0.25.0; no database change, no routine row (the live count stays a read), the Motion hub bytes in the repo are unchanged (still 636c7a3; the live check reads whether the store has moved ahead). NOT IN THIS VERSION: per-project routine copies and the dashboard with a context meter (both are planned with you, by form, first); the near-instant refresh (only after a proven moved tick); the moved tick itself (unless the Claude Motion lane has pushed again before the live check); the member's kept line (no paste means it is skipped by name, never counted as passed); a 17th routine row; retiring the mission-control key road; raven-session; member admission on /internal/mcp; the vision; the auto doc builder; any worker change (a red worker check would stop the run, never a quiet bump). WHAT THE DOCS DO NOT CLAIM: that retrying once cures the 403 code 7403 refusal (one red run after a token renewal is its only evidence, and the timer has never run the retry - it ships with this version); that the scheduled task runs the repo's working tree (the STATE note says so, but schtasks printed nothing when asked, twice); whether your real sign-in folder holds the file (only the timer, running outside the app, can say - from inside the app the real folder reads as present because of the app's merged view); how the tool behaves when logged out outside a terminal (inference); that the no-deploy road is clean (no run has used it since v0.39.x); that the routines page serves rendered_sha on its full view (read at the live check); the served docs page for these rows (the Appolis lane rebuilds it); and the suite and gate figures, which the ship record fills from the merged stage's own runs. Shipped 2026-11-01 — worker 0.51.0 is served with local 0.25.0, run by the chat in bypass-permissions (recorded as that road): the hourly timer that refreshes the Motion dashboard now runs green on its own, a read refused right after a sign-in refresh is tried once more, and the release checks read what the pages really say; the database's migration ledger now lists all 18 changes.
MOTION_LOOP STOP d1read by=<by> status= stdout_bytes= parsed= stderr_lines= stderr_file= <first line> with wrangler's stderr whole in daedalus-motion-loop.stop.<iso>.txt beside the log; local/tests/motion-loop-v0524.test.js pins it (L1-L9, MOTION_LOOP_LOGIN); four carried pins RE-MEASURED to the new printed shapes (d1read-v0370 LINE + a hermetic APPDATA, motion-loop-v0510 ML11, v0520 MV7 + MV11, v0522 E1 - every old field still pinned, the new ones exact); todo_8741, form note_8825 Q1 A; nothing deployedWhat changes for you: since 11:44 UTC the hourly task that refreshes the Motion dashboard found the Cloudflare tool and then crashed on every run, while the same tool works from inside the Claude app. The best explanation: the tool's sign-in was saved from inside the Claude app, so it sits in the app's private folder, and the task, which runs outside the app, starts signed out. Each run now writes down which sign-in it can see. When only the app's copy exists, the task points the tool at that copy; it changes nothing when your normal sign-in is there or a folder is already set. A failed read now records the tool's exit code, how much it answered, whether the answer made sense, and saves the tool's own error message to a file next to the log. The sign-in file itself is never opened, copied or moved. Local change only: no website deploy. Proven: the nine new checks fail on the old code and pass on the new, all 414 local checks are green, and on this PC the lookup points at the app's sign-in folder. NOT yet proven: the task's own next hourly run going green - that run is the test of the theory.
the packaged app's npm global prefix (<dir>); the not-found throw names it; the v0.52.1 comment corrected (its APPDATA-unset theory was wrong); local/tests/motion-loop-v0523.test.js pins it (PK-a..PK-d), v0520 MV9 + v0521 withTimerEnv made hermetic on LOCALAPPDATA; todo_8741, forms note_8742 Q1 A + note_8763 Q2 A; nothing deployedWhat changes for you: the env line from the 10:44 UTC run named the real cause. The Cloudflare tool was installed from inside the Claude app, and the Claude app quietly keeps what it installs in its own private copy of your AppData folder. Everything inside Claude sees it; the hourly task, which runs outside Claude, never did. The task now also looks in that private copy. Local change only: no website deploy. Proven: the new checks fail on the old code and pass on the new, and all 405 local checks are green; on this PC the lookup finds the tool. NOT yet proven: the task's own next hourly run going green.
MOTION_LOOP_ENV line (APPDATA, LOCALAPPDATA, USERPROFILE, HOMEDRIVE, HOMEPATH, HOME, os.homedir(), cwd, node, the npm shim yes/no, the wrangler wranglerCommand resolves or its error, PATH cut to 800; names and paths only, no secret); the field is from=, so --motion-loop status still counts only tick lines; local/tests/motion-loop-v0522.test.js pins it (E1-E4); todo_8741, form note_8763 Q2 A; nothing deployedWhat changes for you: the hourly task on your PC that keeps the Motion dashboard current still stops every hour saying it cannot find the Cloudflare tool, even after this morning's patch, while the very same code finds it when run by hand. Instead of guessing a third time, the task now writes one extra line to its log at the start of every hourly run, recording which folders it thinks are yours, where it is running from, and whether it can see the tool. No passwords or keys. Local change only: no website deploy. Proven: the new checks fail on the old code and pass on the new, and all 401 local checks are green. NOT yet proven: what the real task prints - its next hourly run writes it, and the fix follows from that.
What changes for you: the small hourly task on your PC that keeps the Motion dashboard current has never once finished on its own: every tick stopped at its first step saying it could not find the Cloudflare tool. v0.52.0 taught it to look in your npm folder, but Windows starts the task without the setting that names that folder, so it still looked nowhere. Now, when that setting is missing, it looks in your own user folder's AppData instead, which is where the tool really is. Local change only: no website deploy. Proven so far: the new check fails on the old code and passes on the new, and the whole local test suite is green. NOT yet proven: the timer's own next tick going green - the only proof that counts; the next run reads it from the timer's log.
What changes for you: (1) THE TWO RED CHECKS WERE THE CHECKS' FAULT. Last version's two live checks came back red and both were wrong while the app was right. The check that a second person sees only their own projects now asks Daedalus itself which account it is talking to (a new one-line answer, /api/whoami, that tells a signed-in person only their OWN account id, nothing about anyone else, and still the sign-in page for anyone signed out), reads the project ids in both shapes the page serves, treats the "All projects" overview row and an empty page as the correct answer for a person who owns nothing yet, and shows a kept line when that person does own one. The saved read of the real page you ran as the test member is its practice case, so the check is proven on the page you actually saw. The routine-file check now compares the checksum of the file on your PC to the checksum Daedalus actually serves, the field the app really sends. (2) THE FIRST REAL TICK, AND THE TIMER THAT WAS QUIETLY RED. A FINDING from planning this version, read from the timer's own log on your PC: the hourly task DaedalusMotionLoop has run twice on its own since it was installed (03:44Z and 04:44Z on 10-31) and BOTH runs stopped at their first step with "wrangler not found". A scheduled task does not carry your shell's PATH, so it could not find the Cloudflare tool that the hand-run check found (it lives in your user's npm folder), and Windows kept reporting "Last Result 0" because the hidden-window wrapper swallows the real exit code, so nothing looked wrong. Nothing leaked and nothing was written (a stop writes nothing), but the refresh loop has never ticked green by itself. This version teaches the tool to look in the npm global folder as well, and the status line now reads the timer's own ticks from the log (how many were green, how many stopped, and what the last one said), so a red timer shows up as itself. The first green timer tick is read at the live check by waiting for the next scheduled hour mark; if it still stops, the stop word is named and becomes the next fix, and the task itself is not re-installed because the fix is in the file it runs. A refresh that finds a genuinely new push is proven live only if the Claude Motion lane has pushed before the live check; otherwise it stays proven by tests only, and says so. (3) THE TICK CHECKS ITS OWN WORK. After the timer writes a patch it now reads back EVERY row it wrote (not just the manifest) and checks each against the export's checksum, so a damaged page row is rewritten on the next tick instead of being served as the bundled copy forever; a manifest row that cannot be read is repaired, not treated as missing; and each person's episode list and manifest follow the stored episode pages' own project words, so an episode that moves to another account leaves that person's list on the next check instead of the next ship. (4) THE CHAIN'S DEAD ROAD. The last run's board step had two gates in a row that could never both pass on a red-but-named result, so the chat had to post the record by a hand script; ONE rule now serves both gates, the control gains that case, the hand road is closed once the script composes, the drills line stops counting its own red, the new-rows line is printed and pinned, the bill can read a seat that ran in another chat session, every seat carries a tools cap, and the last run's mid-run fixes are dated rows with a re-seal. Version: worker 0.50.0 -> 0.51.0 (a major step in size, because the member's served index now follows the stored pages' own words and a new route names the caller's own account), local 0.23.0 -> 0.24.0 (the local door moves: the tick's read-back, the wrangler road and the timer verdict live there), no migration (the ledger stays 18), no routine or template change (the live routine count stays a read), not one byte of the Motion hub in the repo moved (still 636c7a3). It deploys only on your go (the plan form's Q1). NOT IN THIS VERSION: per-project routine copies and the dashboard with a context meter (both wait on your plan, by form), a 17th routine row (the tests keep pinning the repo's 16), retiring the mission-control key road, raven-session (it lives elsewhere), member admission on /internal/mcp, the vision, the auto doc builder, and the near-instant refresh, which waits on the plan form's Q4 and a moved tick proven live. WHAT THE DOCS DO NOT CLAIM: that the timer's first green tick has happened (it is read at the live check, not assumed; until then the only green tick on the log is the hand-run one); that a refresh with a genuinely new export has been seen live (it needs the Claude Motion lane to push first, and Wrangler's batching of the largest generated file is still unproven until then); that the member's kept line was graded (it needs one shared row for info@spartanstudios.com and your one console paste; without the paste it is skipped by name, never counted as passed); the served docs page for these rows (the Appolis lane rebuilds it); and the suite and gate figures, which the ship record fills from the merged stage's own runs. Shipped 2026-10-31 — worker 0.51.0 is served with local 0.24.0, run by the chat in bypass-permissions (recorded as that road): the timer that refreshes the Motion dashboard, which had quietly stopped at its first step every hour since it was installed, now finds its tool; the two red checks of last time now read what the page really says; and each person's episode list follows the stored pages' own project words; the database's migration ledger now lists all 18 changes.
What changes for you: (1) THE MOTION DASHBOARD CAN REFRESH ITSELF. Today daedalus.appolis.app/motion shows the Claude Motion lane's export as of commit 636c7a3 and moves only when a Daedalus session pulls it by hand and ships a new Worker. This version adds a small timer on your PC (a Windows scheduled task named DaedalusMotionLoop, the same kind as the routine auto-sync; no Claude chat, no model, no cost per tick) that checks the Claude Motion lane once an hour, or once a day at 06:00 if you pick that on the plan form (Q3). A check that finds nothing new writes nothing, and that includes the hour after a refresh, because the timer compares against what Daedalus already serves, not against the copy in the repo. A check that finds a new export writes the changed pages into Daedalus's own document store, the same place the Kosmos project list already lives, and the dashboard serves them from there first, so it moves within one check with no deploy, no version bump and no hand. If a stored page is ever damaged or half written, Daedalus names it and serves the bundled copy instead, never anything foreign. What this does NOT do: deploy anything (a deploy stays your written go), change who may see what (each account still sees only its own projects, applied to the stored pages exactly as to the bundled ones), or run as a Claude routine on a schedule (every routine stays manual; this is a PC task). The repo's bundled copy is re-cut by script at the next ship, so the two do not drift apart for long. If you pick the measure-only road on the form (Q4 B), the timer only pulls, logs and files one to-do, and the store road is not built. (2) THE MEMBER'S PROOF. The own-projects rule is proven live for a second person only if Appolis has shipped todo_8571 (Daedalus on the admin grant list): you grant info@spartanstudios.com Daedalus, sign in as it, and run ONE read-only console paste (the plan form's Q2 A). If Appolis has not shipped it, the check is SKIPPED BY NAME (blocked-by:appolis-todo_8571), counted as skipped and never as passed, and a to-do for the Appolis lane carries the one step left. (3) A ROUTINE IS DONE WHEN THE APP LISTS IT. v0.50.0 said solarwrld-session was installed because its small starter file was written and read back, but a file in that folder is not a registered routine, and you could not see it. From now on the check reads the app's own task list against the routine list and names every row that is file-only; raven-session is reported as elsewhere, because its owner is Raven and it lives on his computer, which is correct and not a defect. The solarwrld-session registration is a step the chat does on your yes, never assumed. (4) THE BUILD ROAD carries the last review's fixes (read-only carried drills that count skipped apart from failed, the bill naming rowed and unrowed over-budget seats, a real park for the merger seat at 1.25x its estimate, no routine row named in the ship script, real version ids on the deploy records, one drills printer and a board line in the ship log). Version: worker 0.49.0 -> 0.50.0 (a major step in size, because the served hub now has a second source written by a timer and the per-account filter must hold on it), local 0.22.0 -> 0.23.0 (the local door moves: the timer's code lives there), no migration (the ledger stays 18), no routine or template change (the tests pin the repo's 16 routine rows; the live count stays a read), not one byte of the Motion hub in the repo moved (still 636c7a3). It deploys only on your go (the plan form's Q1). WHAT THE DOCS DO NOT CLAIM: that a refresh with a new export has been seen live (the Claude Motion lane has not moved since 636c7a3, so the first real refresh is the next version's evidence; what is proven here is the pinned tests under a stand-in runner and an in-memory copy of the real table definition, plus, live, the task installed and read back and one quiet check); that Wrangler accepts the largest generated file in one batch (the slicing keeps every statement under D1's cap and is proven in the test, but the first real refresh is what proves the live run); that the member's check ran (it needs your form answer and the Appolis grant); the served docs page for these rows (the Appolis lane rebuilds it); and the suite and gate figures, which the ship record fills from the merged stage's own runs. Shipped 2026-10-31 — worker 0.50.0 is served with local 0.23.0, run by the chat in bypass-permissions (recorded as that road): the Motion dashboard can now keep itself current from a small timer on your PC with no deploy, and each account's own-projects rule applies to those pages too; the database's migration ledger now lists all 18 changes.
What changes for you: (1) EACH ACCOUNT SEES ITS OWN MOTION: at daedalus.appolis.app/motion the person signed in now sees only the projects of their own account, meaning the ones whose id carries their account (acc_<theirs>~<name>, the same id the Kosmos board shares them under). Raven sees Hockey Lab and the FLIP 8 roadmap, and not Daedalus, Hermes or FLIP 7. You, as the master admin, see everything exactly as before, byte for byte. A link to a project that is not the person's (a Flow or Watch link, an episode file, a roadmap) answers a plain "not yours: that project belongs to another account" instead of showing it, and nobody signed in still gets the same sign-in page. The Flow and Watch buttons on Kosmos for Raven's projects no longer land in your items. What this does NOT do yet: a member can read their own Project Flow but not save a new order (that write stays yours; it is filed as the next step with the Kosmos side, todo_8357). (2) SOLARWRLD GETS ITS OWN ROUTINE: solarwrld-session is in the Daedalus routine list, shaped exactly like the Hubs, Warehouses and FORGE orchestrators: Run now, manual only, one run = one phase of one blueprint, a deploy only on your written go. Your own words from the to-do are carried into it verbatim, and its first run is the review and merge of Codex's Stage 0-7 work. Its 7-line stub is installed on your PC under scheduled-tasks/solarwrld-session by the live check. The test suite pins the routine count at the repo's 16 rows; the live count stays a read, never a pin. (3) THE RUN'S OWN ROAD carries the five fixes the last review left: the bill adds up a seat that had to be started twice and writes its own over-budget row, a missing hands line is a named skip and never a stop that carries on, the carried drills print one saved line, the pull-gate control checks its stage before it grades, and the deploy line pins both version ids when a run resumes. Version: worker 0.48.0 -> 0.49.0 (a major step in size, because the per-account scope is a trust boundary: the gate now lets a member of this app in, and what that member may read is decided in one place), local 0.22.0 unchanged, no migration (the ledger stays 18), no template change, no door text, no floor change, not one byte of the Motion hub moved (still 636c7a3). It deploys only on your go (the plan form's Q1). ONE THING TO KNOW: the repo cannot see what word Appolis ID puts on a member's Daedalus membership; the gate admits both daedalus and hephaestus and the live member check is the proof. The Appolis source grants either word for both (read by the build chat), and the two older tests that said a member is refused at /motion (motion-v0430 MO4, docket-v0430 DK8) were re-measured: that member is let in and sees only its own projects. If neither word arrives, that member's /motion page reads "This project isn't shared with your account." and the fix is a to-do for the Appolis lane, not a rebuild here; and if Raven's account turns out to hold the master grant, he is the owner path and sees everything, an Appolis ID fact the check will say plainly. NOT VERIFIED AT THE BUILD: the live member sign-in (who signs in as the member is the plan form's Q2); the hub's page on a shorter episode list in a real browser (the tests prove the page text, not the screen); the live routine count (read after the seed, never typed); the stub on your PC until the live check installs it; the served docs page for these rows (the Appolis lane rebuilds it); the suite and gate figures, which the ship record fills from the merged stage's own runs. Shipped 2026-10-30 — worker 0.49.0 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): each account now sees only its own projects on the Motion dashboard, and SolarWRLD has its own Run now routine; the database's migration ledger now lists all 18 changes.
What changes for you: (1) THE MOTION DASHBOARD IS UP TO DATE: at daedalus.appolis.app/motion you now see 37 episodes instead of 20. The 17 new ones are Hockey Lab, SolarWRLD, QR Codes, Blueprint Skill, FLIP 7 new LP, Recharge Ops, FLIP landers, FML end cards, TipLift, Agora, How old is the US government, FLIP 8 soccer video 5, Studio 7 sessions, Brody 30s ad, Raw Sugar science site, Free Will and Petty Me, and 14 of the older 20 were refreshed. The project list gains Hockey Lab (Raven's, shown as shared) and SolarWRLD, and Hubs shows its routine. Project Flow now tells you in plain words when two people save at once ("Someone else saved first, so their order is loaded now. Make your change again if you still want it."). After this, the close-out's own pull check should print drift=0, meaning nothing is behind. (2) SHARED PROJECT NAMES ARE ACCEPTED: the board names a shared project like acc_6751cc16e945~hockey-lab. Daedalus used to refuse that name as a roadmap or plan document ("not a store path"), so the Claude Motion role, which is now this lane's, can push those two roadmaps with the roadmap tool instead of being refused by name. Only that name shape is new: who may read or write what did not change, and the first part of a name still may not carry a ~. (3) THE RUN'S OWN ROAD IS FIXED where v0.48.0 found it broken: when Claude's browser is refused a live write by its safety filter, the run no longer grades that as a failure of the product. The go-ahead step first tries one harmless write that it undoes and names the result; if the browser is refused, the run hands you ONE paste for your browser console whose answer lands as a file in your Downloads, and grades each half on its own. The form reader now reads your pick the way the form actually saves it, the board step can still write its block when a check is red for a named reason you chose, and the health line at the live checks is printed by a printer instead of pasted raw. NOT in this version: retiring the old Kosmos key road (todo_8502). Kosmos has not yet been seen reading and writing over the new wire live, so this version only lists, in the payload's consumers/key-road.md, every place in this repo that still touches that road, which is where the retire will start. Also not here: /motion per account, the SolarWRLD routine, the player on the floor. Worker 0.47.0 -> 0.48.0 (a major step, by your order on the form); no migration (the ledger stays 18), no seed, no routine or template change, nothing in local/ (stays 0.22.0). It deploys only on your go (the plan form's Q1). NOT VERIFIED AT THE BUILD: the live dashboard until the deploy and the run's live checks; the owner-console road end to end (its offline self-test is the build's proof); Kosmos's side of the shared names (its own to-do on its board); the served docs page for these rows (the Appolis lane rebuilds it); the suite and gate figures, which the ship record fills from the merged stage's own runs. Shipped 2026-10-30 — worker 0.48.0 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): the Motion dashboard catches up with the Claude Motion lane's October 30 push (37 episodes, two new projects), and Daedalus now accepts the shared-project names the board uses; the database's migration ledger now lists all 18 changes.
What changes for you: you said (form note_8361, Q2) that you did not want a key at all - you wanted an automatic connection that follows from your own profile in Daedalus. This is that, for the roadmap. (1) THE ROADMAP LIVES IN DAEDALUS: each project's roadmap (what is planned, what waits on what) was a bundle of files copied into the Motion mirror. It can now be a document of its own in Daedalus, one per project, and the Motion dashboard's roadmap view and Project Flow read those documents on the next load. Until a document is saved, nothing changes: the dashboard keeps showing today's bundle and the answer says "snapshot". (2) NO KEY, YOUR OWN NAME: nobody mints, copies or pastes anything. The Claude Motion lane's chat already talks to Daedalus through the Appolis connector as you; it gets ONE new tool, roadmap, that saves a project's roadmap (and reads, lists and removes one), and the record says which account saved it. You can also save or remove one yourself, signed in at daedalus.appolis.app, which is exactly how the live check does it. (3) A WRONG-SHAPE ROADMAP IS NEVER SERVED QUIETLY: a roadmap that is not the shape the page reads is refused when it is saved, with the reason in plain words; if a bad one ever got into the database anyway, the dashboard falls back to today's bundle as a whole and the answer's header says "docket-invalid" and why - never a half list. A wait on a project nobody has saved yet is allowed and counted in the header, because the page already copes with it. (4) KOSMOS IS NOT BOTHERED: saving a roadmap does not ping Kosmos and does not ride the wire to it, because Kosmos does not read the roadmap today; a test pins that, so it stays a decision and not an accident. (5) WHO CAN WRITE: only you (the pane or the tool as the owner). The helper keys (Claude, ChatGPT, Codex) and the Kosmos key and link can never write a roadmap document, and say so by name; Kosmos may still read them as it reads any document. A room member's chat is told the tool is owner-only. (6) THE BUILD ROAD IS MENDED: a resumed ship can no longer deploy the same build twice, every re-seal names the sha it replaced, the patch re-check is written into the ship log, the cost table has a row for every seat it pays, the live checks refuse to start under Auto mode and say why, and a live routine count is never typed into a check again. Worker 0.46.0 -> 0.47.0; no migration (a roadmap document is a row in the docket table that already exists), no seed, no routine row, no door text, no floor change, nothing in local/, and not one byte of the Motion hub moved. It deploys when the run is green (your answer, form note_8361 Q1 A). ONE CAVEAT: a chat learns a new tool only when its connector connects, so the chat that deploys this will not see the roadmap tool until its connector is reconnected or you refresh the connector's tool list; the live check tries the reconnect and otherwise says "skipped" by name, and the Claude Motion lane's first push is its own to-do on that board. NOT VERIFIED AT THE BUILD: the tool live from a running chat until its connector re-initializes; the Claude Motion lane's own push; a room member's refusal live (the unit test is the proof, no member session is at hand); the helper keys' refusal live (revoking a helper platform revokes every key of that platform, so no helper key is minted for a live test); the served docs page for this row (the Appolis lane rebuilds it); the suite and gate figures, which the ship record fills from the merged stage's own runs. Shipped 2026-10-30 — worker 0.47.0 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): your project roadmaps can now live in Daedalus as documents your own chat saves with no key to make or paste, and the dashboard's roadmap view follows them; the database's migration ledger now lists all 18 changes.
What changes for you: you asked (form note_8361, Q2) for just an automatic connection between Daedalus and Kosmos, with no key to make or paste. (1) A WIRE, NOT A KEY: both apps live on the same Cloudflare account, so Cloudflare joins them directly, the same way Kosmos already reaches the Hermes app and both reach Appolis ID. There is nothing to create, copy or paste on either side, ever. (2) KOSMOS HEARS IT AT ONCE: each time you save or delete a Project Flow plan, the order or the project list in Daedalus, and each time a chat is handed its last step (the clock-out) through the Daedalus step door, Daedalus tells Kosmos right then: which plan or which routine, which phase, which Appolis account, when. (3) NOTHING IS LOST QUIETLY: if Kosmos does not answer, the message is kept and sent first with the next one (up to 50 are kept, and if more pile up the oldest is dropped and counted, never hidden); if Kosmos says no, that is written down as refused and is not retried, because a retry cannot change a no. You can see the last push, how it went and how many are waiting at /api/docket/link on Daedalus, and send the waiting ones again from there. A save or a step still answers exactly as before; a slow Kosmos can add up to three seconds. (4) KOSMOS GETS A DOOR OF ITS OWN: a named entrypoint on the Daedalus Worker that the public internet cannot reach; only an app that the account owner binds to it in its own deploy settings can. Over it Kosmos reads what is next and the plan documents and writes the project list and plans as Kosmos, with the same stale-version refusal and the same bad-shape refusal as before and no ping back, exactly what the key allowed, with no key. Everything else is turned away. (5) THE KEY ROAD STAYS FOR NOW: the mission-control key keeps working until Kosmos has switched to the wire; it is retired in a later version (v0.49.0 at the earliest), filed. Kosmos's own half is three to-dos on that board: bind to Daedalus and switch to the wire, write the project list whenever the board changes and take Daedalus's two pushes, and remove the paste-a-key box. THE ROADMAP STORE, the plan this run first held, is parked whole and moves to v0.48.0. Worker 0.45.0 -> 0.46.0; no migration (the two new records are rows in a table that already exists), no seed, no routine row, no door text, no floor change, nothing in local/ or in the Motion hub. It deploys when the run is green (your answer, form note_8361 Q1 A). NOT VERIFIED AT THE BUILD: the road in, Kosmos reaching Daedalus through its own door, because Kosmos has not bound it yet (this run can only show the build is wired correctly); Kosmos's reaction to the end-of-session push and to the order and project-list pushes, which its listener answers "no" to today, so Daedalus will record them as refused until Kosmos's to-do ships; what Kosmos does after a push lands (its own re-read still waits on the old key and quietly fails inside Kosmos); the only live proof this run can give is that a plan save lands on Kosmos's own "last hook" record, and that is read in your signed-in page; the served docs page for this row (the Appolis lane rebuilds it); the suite and gate figures, which the ship record fills from the merged stage's own runs. Shipped 2026-10-30 — worker 0.46.0 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): Daedalus and Kosmos now talk over a built-in wire instead of a key: Kosmos hears every plan or project-list change you save and the end of every chat session, and gets its own keyless door back in once Kosmos switches it on; the database's migration ledger now lists all 18 changes.
What changes for you: v0.45.0 gave Kosmos a key and a door into Daedalus; this is the first thing that rides it. (1) THE PROJECT LIST COMES FROM THE BOARD: the tiles on the Motion dashboard (the page at /motion) were a list of 43 projects somebody copied from Kosmos on 2026-10-20 and nobody has updated since. Daedalus now keeps the list as a document of its own (flow/projects) and serves the dashboard's project list from it; Kosmos writes that document with the mission-control key you minted in v0.45.0 (its own to-do on that board), and a project added, renamed or moved to a new stage on the board shows on the dashboard on the next load. Until Kosmos writes it, nothing changes: the dashboard shows the list it shows today, and the answer says "snapshot". (2) A BROKEN LIST IS NEVER SERVED QUIETLY: a list that is not the shape the dashboard reads (no projects, a bad id, a section that is not listed, more than 500 projects) is refused when it is saved, with the reason in the answer; if a bad one ever got into the database anyway, the dashboard falls back to today's list and the answer's header says "docket-invalid" and why. (3) THE SAME SAFETY AS A PLAN SAVE: Kosmos's save of the list carries the version it read and is refused if someone saved first (re-read and retry), is marked as Kosmos's, and does not ping Kosmos back; your own save of the list pings the address in flow/hook exactly as a plan save does. (4) THE HELPER KEYS ARE NARROWED (your pick, form note_8252 Q2 A): the keys your AI helpers use unattended (claude, chatgpt, codex) could read the plan documents and the Kosmos ping address over the API; now only the mission-control key and you, signed in, can, and a helper key that tries gets a named "not yours" answer (403 KOSMOS_ONLY). A helper that later needs the plan straight from Daedalus gets that added on purpose, with a test. A helper key still cannot write anything there. (5) THE LIVE KEY TEST THAT WAS SKIPPED IS DRILLED: v0.45.0's live key test never ran; this version carries it, plus a drill of the project list itself, to be run by you in your signed-in page with Auto mode off (form note_8252 Q3 A) because each drill mints a key and saves a document. (6) THE BUILD ROAD IS MENDED: the defects v0.45.0's run found in its own build road (the build's pinned test file, the cost table the filler could not read, who read each drill's result, the two motion checks printed side by side, the review's two required blocks) are each fixed and pinned. Worker 0.44.0 -> 0.45.0; no migration (the list is a row in the docket table v0.45.0 already uses), no seed, no routine row, no door text, no floor change, nothing in local/, and not one byte of the Motion hub moved (the hub's own list file stays as the fallback). It deploys when the run is green (your answer, form note_8252 Q1 A). NOT VERIFIED AT THE BUILD: every live road (the served list, the save, the key road, the narrowed refusal) until you run the drills in your signed-in page; the helper keys' refusal live (revoking a helper platform revokes every key of that platform, so no helper key is minted for a live test; the unit test is the proof); the Kosmos end (the list is empty of Kosmos's rows until its to-do ships); what the dashboard draws for a project whose section is not listed (the shape check closes it at the door, the dashboard itself was not looked at); the served docs page for this row (the Appolis lane rebuilds it); the suite and gate figures, which the ship record fills from the merged stage's own runs. Shipped 2026-10-29 — worker 0.45.0 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): the dashboard's project list now follows the Kosmos board once Kosmos writes it, and the helper keys can no longer read your plan documents; the database's migration ledger now lists all 18 changes.
What changes for you: you asked (form note_7650, Q4) for everything built in the Claude Motion hub to come into Daedalus piece by piece, with the Kosmos project tiles opening these items on Daedalus and the "what's next" tile staying in step with the flow. This is the first piece, and it is Project Flow's door - nothing in the hub itself moved. (1) ADDRESSES THAT STAY PUT: daedalus.appolis.app/motion/flow/<project> opens that project's Project Flow page, and /motion/open/<project> opens its episode - the links the Kosmos tiles will carry; a name that is not a project id answers "not found", and both sit behind your Appolis-ID sign-in exactly as /motion does. (2) KOSMOS CAN READ YOUR FLOW: two new read-only roads - the list of docket documents that changed since a time you name, and one project's "what's next" (its next three versions and their items). (3) KOSMOS CAN WRITE ONE THING BACK: you mint a key for "mission-control" from the signed-in pane (the same walled, revocable key road the hands use), and with it Kosmos can save a project's plan or the flow order - with the same refusal if someone saved first, so it can never overwrite you - and nothing else: no delete, no change to the hook, and no other key (the hands' claude, chatgpt and codex keys) gains a write. A save that comes over that key is marked as Kosmos's and never pings Kosmos back, so the two sides cannot loop. (4) THE PING: set a URL once as the docket document flow/hook; after that every save you make of the flow order or a plan sends Kosmos a small "this changed" note (no document in it - Kosmos re-reads over its key), and the save's answer shows whether it landed (a number, "timeout", "error", "unset" or "disabled"); a ping that fails never fails your save and is never silent. (5) THE FLOOR: the click box of a Game Plan tile gains an "Open in Motion" link to that project's Project Flow. (6) THE BUILD ROAD IS MENDED: the four defects v0.44.2's run found - the docs check could not find the version's line in the design doc, the version line was never re-checked after the commit, the seed check could not say it passed, and the ship door could be sent its parts too early - are each fixed and pinned. Worker 0.43.2 -> 0.44.0; no migration (the ledger stays 18), no seed, no routine row, no door text, nothing in local/. Still to come: the Kosmos half (its own to-do on that board), a signed ping, and the road's next versions - the project list (v0.46.0), the roadmap store (v0.47.0), the player on the floor (v0.48.0). NOT VERIFIED AT THE BUILD: the live roads, the signed-in page and the key road (drilled after the deploy, if you say yes), and the Kosmos end of the ping, which cannot be tried until the Kosmos half ships. Shipped 2026-10-29 — worker 0.44.0 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): Kosmos and Daedalus can now point at each other and keep your project flow in step: tiles open Project Flow on Daedalus, and a change on either side reaches the other; the database's migration ledger now lists all 18 changes.
What changes for you: v0.44.1 could not deploy in its own run. On 2026-10-28 (shift sh_106853d7ae) the PATCH step said "Nothing is deployed" and went straight to J8 CLOSE, although you had already answered "deploy when green in that run" (note_8047 Q1 A; your 10-17 rule note_6489: a green patch deploys at once on your go) - the door had no slot to ship in and no way to learn that your go existed, so v0.44.1 (commit 0a904f6) was shipped by hand. Now: (1) THE GO RIDES THE PATCH LINE: the chat that builds the patch ends its PATCH line with the go you gave, e.g. "PATCH commit=0a904f6 version=0.43.1 deployed=no tests=767/767 go=form:note_8047:A" - the same written-form rule the nine-part ship has required since v0.39.2 (a form pick A, never a chat's word); the old line without the tail still passes, byte for byte. (2) THE PATCH SHIP SLOT: with a go on the line, the door serves PATCH-SHIP (PATCH-2-SHIP and so on for a second patch) in five parts - GUARD, DEPLOY, HEALTH, SHIPPED, MIRROR, the lines the detour deploy script prints - checks each line as it checks the ship's own, and only then serves J8 CLOSE; a J8 line is refused while the ship is open. (3) THE GO MUST MATCH: the DEPLOY part passes only a line carrying the SAME go the PATCH line named, never a parked line, and attended=yes widens nothing; a deploy that cannot run is a STOP line, nothing is recorded and the slot is served again next run. (4) NO GO, NOTHING CHANGES: a PATCH line without a go, a "PATCH none reason=" line and a REPLAN line never get a ship slot - they are served exactly what they are served today (J8 next, nothing deployed); a patch whose ship already passed is not served the ship again; the cursor-less door and blueprint=none runs keep today's road. (5) THE DETOUR SCRIPT: its DEPLOY line failed "compose STOP DEPLOY missing road" after a successful deploy, because the detour branch never set the road word; it now defaults to accept-edits (the word its SHIPPED line already named), and its self-test asserts it. (6) THE FLOOR: a ship row counts as a slot row on the game plan tiles. Worker 0.43.1 -> 0.43.2; no migration (the ship slot rides the cursor columns PATCH-2 and the nine-part ship already use), no seed, no routine row, no template, no floor page change; local 0.22.0 unchanged; the nine-part ship and every other door text are unchanged. Not checked at the plan: the live PATCH -> SHIP road (no patch exists to ship in this run - the unit test on an in-memory cursor is the proof, the first live use is the next patch), the detour script on a real deploy (its self-test shims are the proof), and the blueprint skill's lane check from the repo folder (filed on that skill's own board). Full record: DAEDALUS-DESIGN.md section 14.62. (A2) One test fix rides along: the local suite's 429-hold tests (H1/H2 in local/tests/limits-v0162.test.js) measured the five-minute hold from the moment BEFORE the helper started, so a busy machine failed a correct hold - the run gate went red twice on them on 2026-10-28 while they passed alone; the window is now bounded by the clock before AND after the helper runs. Test file only; the local code and its version (0.22.0) are unchanged. (A3) And one more: the shim test R11 (local/tests/hands-shim.test.js) now runs again once, and says so, when the helper's 2-second sign-in check timed out on a busy machine - the gate then went red on that instead (3 of 4 full runs); the 2-second cap itself is local code and stays as it is (a to-do). Shipped 2026-10-28 — worker 0.43.2 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): a patch that is green can ship in the run that built it, only on your written yes; the database's migration ledger now lists all 18 changes.
What changes for you: the game plan at the top of daedalus.appolis.app now shows the true picture. Since v0.44.0 it showed 23 versions shipped weeks ago as still RUNNING and hid today's v0.44.0 - every Daedalus run is filed under one handoff, and the tiles tied every one of them to the newest plan. Now: (1) EACH RUN HAS ITS OWN PLAN: the door stamps every round with a round tag, and a run is matched to the plan with that same tag - so a shipped version reads DONE, with the date it closed, and its steps are its own, not today's. (2) THE ORDER: the runs in progress come first (the newest first), then the versions still waiting in your Project Flow order, and the shipped ones last; a run that is not in your plans and has not moved for a week is history and leaves the row. (3) NO TWIN TILES: only a version named like v-v0-44-0 links to a run, so "after v0.44.0" and "on deck" are their own QUEUED tiles instead of borrowing v0.44.0's. (4) STUCK MEANS STUCK: one refusal marks only the run it belongs to (not every tile), and a drills step waiting on the browser pane is never called stuck just because hours went by. (5) SHORTER LINES: each recent step on a tile is a short phrase like "J5 pass · SHIPPED"; click the tile to see each step's whole line. (6) NO OVERLAY: the 30-second refresh of the meter shows a small "Refreshing the wall…" mark in the top-right corner instead of covering the page (an error still shows loudly). Worker 0.43.0 -> 0.43.1; no migration, no seed, no routine, template or door text moves; local 0.22.0 unchanged. Not checked yet - checked during the run, after the deploy: the tiles and the corner mark on the real page in the browser pane (before the deploy they were read only from a copy of the live records and by the page tests). Full record: DAEDALUS-DESIGN.md section 14.61. Shipped 2026-10-28 — worker 0.43.1 is served with local 0.22.0, run by the chat in accept-edits (recorded as that road): the first section of the floor tells the truth: the run being built now first and RUNNING, the versions waiting in your order QUEUED, the shipped ones DONE at the end, each recent step a few words.
What changes for you: the first thing on daedalus.appolis.app is now your game plan, and it is live. (1) THE TILES: above the meter, a row of up to ten tiles - one per upcoming version, in your own Project Flow order (a project you planned but never put in the order tiles last, as "unordered"). Each tile says plainly where that version stands: QUEUED (no run yet), RUNNING (which phase and step the door served last, and how long ago), DONE, or STUCK in red with three lines - WHY the door refused (its own words), NEEDED (the exact line it is waiting for) and DOING (the live session on it, the form it is waiting on, or "nothing - the lane has no session"). (2) THE LIVE TRACKER you asked for: every tile carries a five-step progress line (PLAN, BUILD+CHECK, RUN+SHIP, DRILLS+🏁, CLOSE-OUT - each done, running, stuck or still to come), how many steps have passed out of how many, and its five newest results - what went right (the passes) and what went wrong (a mismatch or a stop) - and while the page is open and in front of you it re-reads itself every 30 seconds, so a running tile's clock ticks without a reload. (3) EDIT AND REORDER: click a tile to open what that version holds - retype, add, remove and reorder its items; drag a tile left or right (or Alt+arrow keys) to reorder versions. Both save through the same owner-only, version-checked save Project Flow already uses: if someone saved first, the page reloads instead of overwriting, and only your sign-in can write. (4) NOTHING TYPED BY A MACHINE: a tile's state is worked out fresh from the step door's own records and your docket every time - when the door refuses a step it now leaves a small note of why, and the next pass of that step clears it. Worker 0.42.1 -> 0.43.0 (one new read-only address, /api/tiles, behind your Appolis sign-in like every other; one new floor section; that one small note the door writes); no migration, no seed, no routine, template or door text moves; local 0.22.0 unchanged. Not checked yet - checked during the run, after the deploy: the tiles on the real page with your real docket, the 30-second refresh and the drag in the browser (tested beforehand only against a stand-in docket), the live save on a throwaway plan (your real order is never written by a test), and the stuck path on a real refusal (seen live only when a run next refuses). Full record: DAEDALUS-DESIGN.md section 14.60. Shipped 2026-10-28 — worker 0.43.0 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): the floor opens on your game plan - up to ten live tiles, one per upcoming version in your Project Flow order, each showing queued, running, done or stuck (with why, what it needs and who is on it) and a five-phase progress line, editable and reorderable through the same owner-only docket saves; the database's migration ledger now lists all 18 changes.
What changes for you: /motion is current again and stays current on its own, and the university grew. (1) The Claude Motion hub at daedalus.appolis.app/motion is the one in your repo as of Oct 27 (commit b40d60c): every episode, the second-term column, the motion-loop and companion-mode items - 25 files copied exactly, nothing re-cut. (2) Your arrangement still saves to Daedalus, now through a small script of ours that plugs into the hook your repo offers, so every future copy is a plain file copy. (3) After every close-out, the hands on your PC pull your repo into a fixed folder, export the hub, check it, and say in one line whether /motion is behind; when it is, the close-out files the /motion patch as a to-do for the usual ship chain and your go form. (4) The second term: every link you added on Oct 25 is a source row now (115 in all; the Odyssey link filled in, the PetaPixel row dropped as you said, the Claude Motion repo's address corrected), the ten repos you approved on Oct 27 were cloned read-only onto your PC (1,737 MB, nothing in them ever run), the free local reader turned their READMEs into 27 new cited cards (52 in all), the served university index and the wings' seats read them, and your five "look at these" links each got a one-line verdict on the handoff note - none adopted on its own; the two worth exploring are named there. The web pages and the video transcript are read in the browser pane as a person, after the deploy; their cards ride the next patch. (5) Three step-door loops are fixed, as you asked today (the step-door loop fixes): the Appolis ship door now accepts Appolis's real green PREFLIGHT line (a hub-only deploy, the git-archive road, an account name with an apostrophe) instead of refusing it; a BUILD+CHECK run now claims the docs lane too, not only a RUN+SHIP run; and Flip My Life's Run now stops re-planning a blueprint that already finished - a new plan on it opens its next round instead. Worker 0.42.0 -> 0.42.1 (one served file, the page wrap and the regrown university/wing indexes; no new route, no migration), local 0.21.2 -> 0.22.0 (the --motion-pull verb); no routine or seed row moves - the only door texts that move are the three fixes in (5); nothing in your Claude Motion repo is edited by Daedalus. Full record: DAEDALUS-DESIGN.md section 14.59. Shipped 2026-10-28 — worker 0.42.1 is served with local 0.22.0, run by the chat in bypass-permissions (recorded as that road): /motion re-copied byte for byte from the Claude Motion repo at b40d60c (every episode as of Oct 27), Project Flow saving to the docket through one small host script on the hub's own MOTION_STORE hook (no re-cut of flow.js, ever again), the hands pulling, exporting and checking the hub on Tyler's PC after every close-out; the database's migration ledger now lists all 18 changes.
What changes for you: Project Flow now lives inside Daedalus. (1) Open daedalus.appolis.app/motion with your Appolis sign-in and you get the same Claude Motion hub - every project ranked from 30,000 feet, each project's versions as columns you drag items between, your own items, your episodes - and every save goes to Daedalus's own database, in two new tables (your hephaestus plan came across exactly as you left it; nothing was deleted, and only your own sign-in can save). (2) Every session's starting envelope now carries the next versions of its project from your docket, so a routine takes its next step from your arrangement. (3) Every close-out posts a short motion brief that the Motion area shows under that project's episode. (4) The floor reads its wing count from the data instead of saying "three wings". Worker 0.41.0 -> 0.42.0 (minor: new routes and one migration, ledger 17 -> 18, plus the docket-v1 seed), local 0.21.2 unchanged; no routine, door text or seed row moves. Full record: DAEDALUS-DESIGN.md section 14.58. Shipped 2026-10-27 — worker 0.42.0 is served with local 0.21.2, run by the chat in bypass-permissions (recorded as that road): Project Flow lives in Daedalus: the Claude Motion hub served at /motion behind the Appolis-ID gate with its saves in two docket tables (the hephaestus plan imported as it stood), every P3 envelope carrying the docket's next versions for its project, every close-out posting a MOTION BRIEF the Motion area shows, and the floor's wing count read from the data; the database's migration ledger now lists all 18 changes.
What changes for you: everything you sent us to learn from is now inside Daedalus and readable on the floor. (1) The whole storytold organisation is mirrored read-only (68 repositories; nothing is ever built, checked out or run, only read with git show), each with its link, its kind and the licence role it may be used under. (2) The university holds its first real technique cards - from the Higgsfield blog, YaroFlasher, Katana, Flashboards and the other sources you named - extracted by the free local helpers, and every card must quote where it learned the technique (15 words at most) or it is refused. (3) The wings grew into sectors of experts - 3D and Blender, Unreal, Adobe, design and gameify, voice, world models, video AI, the ArtCraft stack - and every seat and new specialist names the card or repository seat it learned from. (4) Two new read-only pages, /api/university and /api/wing, and two tiles on the floor serve all of it; every wing, seat and card says whether it is shared or private and who owns it, and a private item is never shown to anyone else (everything is shared today). Worker 0.40.0 -> 0.41.0 (minor: two new read-only routes, a floor tile and new specialists by seed), no database change, local 0.21.2 unchanged. Shipped 2026-10-25 — worker 0.41.0 is served with local 0.21.2, run by the chat in bypass-permissions (recorded as that road): every source Tyler sent is in the system: the whole storytold org mirrored (68 repos, git show only), the university's first cited technique cards extracted by the free daimones, the wings grown into expert sectors seeded from those cards, and both served read-only at /api/university and /api/wing with a visibility on every wing, seat and card; the database's migration ledger now lists all 17 changes.
What changes for you: (1) A ship the review marked ⛔ NOT SHIPPED (or whose deploy parked) can no longer be walked past: the next RUN+SHIP line is served the ship step (J5) again, a drills or close-out line on it is sent back to the ship and writes nothing, and you can say next=RESHIP to reopen the ship by hand - nothing already on record is deleted. (2) A room member's routine (Raven's) is asked in chat where it would have posted a form - a member cannot post one - a refused clock-in is a tool limit and never a stop, and his first steps no longer carry your admin words or your PC's script. (3) A first job that honestly finds nothing due today (a scheduled date, an empty queue) is accepted; only a reason that blames the run itself (unattended, automated, by the schedule) is still refused, and a refused line now comes back as LINE REFUSED, its own name, not STEPS STALE. (4) Every stop step now says to append the next run's line to the handoff before it clocks out, and the blueprint folder is read from the design path the plan step wrote. The ship chain carries its fixes with it: a resumed deploy never prints a deploy line it did not run, a null timestamp is no longer counted as newer, the bill is kept per session, and a fix round or an owner re-pin is made by script. Worker 0.39.2 -> 0.40.0 (minor: a new refusal name and a new line word), no database change, no seed change, local 0.21.2 unchanged. Shipped 2026-10-24 — worker 0.40.0 is served with local 0.21.2, run by the chat in bypass-permissions (recorded as that road): the step door serves the ship step again on a blueprint whose review said NOT SHIPPED, takes next=RESHIP, asks a member in chat instead of a form, and stops refusing an honest no-work reason; the database's migration ledger now lists all 17 changes.
What changes for you: the v0.40.5 ship finished, but the step door stopped the run at part 3 of 9 because two of its true lines had grown fields the door did not know yet - the pull gate now prints stamps_newer= and bodies_differ=, and a deploy line ends with the road it took (road=bypass-permissions). The door now accepts both, and still refuses a line that is only half there. Nothing else the door says changed. Shipped: deployed 2026-10-23 17:49Z on your note_7157 Q1 A (deploy.sh --in-chain from the repo, build ea359698, /health 0.39.2 env=live; ship.log untouched; the record written by v0.40.7, §14.55).
What changes for you: (1) "Tell Daedalus to just accept attended=no then" - done. A routine's first step (CHECK-IN) now takes attended=no on every routine, the Run now ones included, and goes straight on to step 2; it never answers STEPS STALE for it again. The session says attended= as it sees it, and the door keeps what it said. (2) No changes only what truly needs you: the Remote Control setter (the app refuses it anyway - a refused setter is now written set=no, a tool limit, never a reason to stop), and a deploy with no written go from you on a form, which parks for the hands instead (the run goes on, deployed=no); your questions still come to you as forms. A run that says no and meets a blueprint whose only leftovers need you is pointed to the next plan line instead of a close-out. (3) The words "never unattended" leave the first step: its rule now opens with "say attended= as you see it", and its line ends attended=yes|no (as you see it: ...). (4) The ship chain no longer stops on its own first lines: an early stop leaves the ship log alone and keeps its own record, a kept owner record is re-used, every printed road names the one permission mode, a pull whose rows differ only in their timestamps is green without a rebuild, the review contract has one written copy (the chain's copy is cut from it by script), and every helper seat a run spawns is keyed and billed. Pinned by door-v0405 AU1-AU8 (red at 9d6dbc0 on AU1-AU6, AU7 AU8 the controls), green after; no migration, no seed or routine row change, local unchanged. Full record: DAEDALUS-DESIGN.md §14.54. Shipped 2026-10-23 — worker 0.39.1 is served with local 0.21.2, run by the chat in bypass-permissions (recorded as that road): the step door accepts attended=no on every routine (say what you see; only what truly needs a person waits for you), and the ship chain stops on none of its own first lines again; the database's migration ledger now lists all 17 changes.
What changes for you: (1) A room member's connector - Raven's, on his Appolis ID - now lists daedalus_step after his other tools, and he can run, one step at a time, a routine that is HIS: a routine row whose owner is his Appolis ID. His first one, raven-session (the blueprint-skill side project and the Mac findings already on that board), is added by this version's seed as one new row; none of your twelve routines is touched. (2) Any routine that is not his - every one of yours - answers him unknown routine, in exactly the words a routine that does not exist gets, so he cannot even tell it is there; nothing is written when he is refused. (3) Nothing admin opens: go, the ledger, the dispatch plan, the session tools, the sandbox, the organizer's report and proposals, the editor, the floor and every /api route stay yours alone, exactly as today; a deploy on any routine still needs your A on the go form. (4) Every call he makes is on the ledger under his name, and a step call's row names the routine it stepped. His step calls have their own daily cap of 600 (a run is about 60-120 steps) and his 200-a-day cap now counts everything else, so running his routine never locks him out of the rest. Worker 0.38.3 -> 0.39.0 (minor: a new member surface), no database change, the seed adds one row, local 0.21.2 unchanged. Shipped 2026-10-22 — worker 0.39.0 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): Raven runs his own routine on Daedalus through the step door, and nothing admin opens to him; the database's migration ledger now lists all 17 changes.
What changes for you: (1) "Never say this again. Ever." The four routines that still told a run with "no Run now press" to "obey PREP AND PROPOSE" (hermes, kosmos-daily, forge, warehouses) now say: every firing is your Run now - the scheduler banner is how Run now arrives; never measure-only. Every routine's first step opens with your sentence: the banner never means unattended, never means measure-only, and the session never tells you a run was "scheduled". (2) The step door refuses by name, writing nothing: a check-in that says attended=no on a manual routine (every routine is manual), a plan step that answers "nothing to do" because of the banner (a plan that waits on your own form still passes), and a close that says no leftovers right after a ⛔ review - the owed work must be named as a leftover, unless your answered form says stop (stop=note_<n> on the close line). (3) THE SMALL ROAD: the first step of a plan now sizes the job by a rubric printed in the step (small = at most 2 files and about 30 lines, no new design call, no money, security or customer data, no migration; big = more than 6 files or a trust boundary). A small job is planned in the note by the chat itself, built by the chat or ONE cheap builder with the gate and one targeted check (no planner agent, no pinner, no mutants), and shipped on your go. The size rides the run (the chat's own line, then the door's memory of it, then the routine's setting, then standard) and every step it changes says which. Worker 0.38.2 -> 0.38.3 (patch), no database change, local 0.21.2 unchanged. Shipped 2026-10-22 — worker 0.38.3 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): the scheduler banner is how Run now arrives: no routine says "PREP AND PROPOSE" again, the step door refuses the three no-work lines by name, and a small job takes the small road; the database's migration ledger now lists all 17 changes.
What changes for you: (1) the ship chain closes whole. The ship script now reads your answer on the go form in the shape the connector really saves it, so the deploy is marked by the run that made it, the ship STOP 10-park that stopped the last ship on an answered form is gone, and the proof that you approved it names THIS run's form, never a copied file. (2) The board step tells the truth: it runs only after the bill is filled, so every helper's timing row (the planner, the fixer, the drills helper) is on the note and a red check can no longer be recorded green; the live step-door drill counts only its own writes, so another session's rows never turn the drills red; a green drills record is never overwritten by a red one. The step door's board step now also takes the line the script prints when the board step ends clean (with the helpers' rows counted and rc=0); the short chat line and the full line are still accepted. (3) The plan form is composed by script and checked before anything is built; the bill is cut from a fixed shape and filled from your own chat's helper launches; the fix cap has a counted road for re-cutting a file; the seal's list of pinned files is written once. (4) The step door learns five small roads: a docs-only payload with no ship script has a named direct road (J5 ship=direct, a plain deploy); a form id is now a valid waiver at the ship guard; with keep going on, a go form you already answered A deploys without a fresh form; a close with no close-out script says so (closeout=none:no-script) and passes; and the clock-in step adds the docs lane only when the handoff says the run is a SHIP run. Every routine is manual: the Run now you pressed counts as you being there - the scheduler's "AUTOMATED FIRING" banner never makes a run unattended, the first step's text now says so, and a chip saying otherwise is re-stamped yes (now pinned). (5) The deck row has a home: DECK.md in the repo, newest first, added in the same commit as this row and read by the docs city; the two older rows of this file whose code spans were wrapped across two lines (0.18.0 and 0.17.0, which showed stray backticks on the served page) are joined by script; the docs rebuild is filed to the Appolis lane. Version: the served worker moves 0.38.1 -> 0.38.2 (a patch bump: the step door's texts and checks in worker/src/lib/steps.js, plus the version number); nothing on your machine changes (local stays 0.21.2), no database change, no routine row edited. On your A on the go form it is deployed by deploy.sh, the one guarded deploy script. Pinned: worker/tests/door-v0404.test.js DU1-DU7, on the v0.40.3 ship's real guard, deploy and close lines and the plan head's step texts, all cut by script (never typed) - red at 4067983 (7 of 7), green after. Not verified offline: the chain closing whole on a real form answer, the served 0.38.2 door, the board step after a real bill fill, and the docs city reading DECK.md. Not deployed. The ship adds its Shipped sentence right here once worker 0.38.2 is live on your go. Shipped 2026-10-22 — worker 0.38.2 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): the ship chain closes whole on your real go answer, the board step tells the truth, and the step door learns five small roads; the database's migration ledger now lists all 17 changes.
What changes for you: (1) the ship now closes its own record, every time. When a run starts it writes the proof that you approved it straight from your answer on the go form (nobody types it by hand); when the deploy ends it marks the parked deploy itself and stops loudly, by name, if it cannot; and the record of the nine ship steps at the step door is written by the ship script at the end of every road, never by the chat. The checks read the run's own log, never a file someone saved. (2) One shape for the board step: the step door's J7 BOARD check now also takes the FULL line the ship script composes - it says the board block was composed from the ship log and how many timing rows it carries (composed=ship-log wall_rows=<n>) - so the board step is done by the script with the timing rows on it. The short line the chat road prints is still accepted; a line that names timing rows without saying where they came from, or a read-back that came up short, is still refused. The step's instructions now name by=script as the line the script's verify step prints. Every other step's check and instructions are unchanged byte for byte. (3) The bill and the forms are honest: one tool counter for every helper, the drills helper billed, the plan form written by script and checked byte for byte against what was posted, the ship log append-only, the session's real mode on the record. Version: the served worker moves 0.38.0 -> 0.38.1 (a patch bump: one step-door check widened in worker/src/lib/steps.js, plus the version number); nothing on your machine changes (local stays 0.21.2), no database change, no routine row edited. On your A on the go form it is deployed by deploy.sh, the one guarded deploy script. Pinned: worker/tests/door-v0403.test.js DT1-DT4, on the v0.40.2 ship's real board line and the plan head's step texts, both cut by script (never typed) - red at 3bf899e (4 of 4), green after. Not verified offline: the served 0.38.1 door taking the full line (the run's board step reads it live), a real stop at the park step, and the owner proof from a real go answer. Not deployed. The ship adds its Shipped sentence right here once worker 0.38.1 is live on your go. Shipped 2026-10-21 — worker 0.38.1 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): the ship closes its own record on every road, and the step door takes the full BOARD line the ship script writes; the database's migration ledger now lists all 17 changes.
What changes for you: (1) the keep-going switch you asked for. In the Daedalus routine editor every routine row now has a KEEP GOING box right beside PAUSE. Ticked - the default - means a run works straight through to the context tripwire instead of stopping each time a phase ends; unticked means it stops at each phase end, as runs did before. Each routine card on the floor shows keep_going yes or no, so you can read every row without opening it, and the form at the start of a run opens with one line saying which way that run is set. A setting that is not a plain yes/no is refused by name, and nothing is saved. (2) The ship record closes on its own after a stop: when a ship stops after its deploy, your answer on the go form is taken as the proof that you approved it, the step door reads the real nine ship steps, and the deploy line never re-reads a worker it has just updated - no more hand-written record commits. (3) The checks that lied last time are made honest: the seal check prints what it actually counts, the pinned list is never rewritten under a seal, the carried live checks are cross-checked for real, the ship check is a gate nobody can skip, and the bill is filled with measured numbers. Version: the served worker moves 0.37.1 -> 0.38.0 (a minor bump: one new editor control and one new setting check); nothing on your machine changes (local stays 0.21.2), no database change, no routine row edited. Pinned: worker/tests/editor-v0402.test.js, red before this version and green after. Not verified offline: a real save of the box on the live site (the run's live check reads every row back without writing), and the record closing on a real stop. Not deployed. The ship adds its Shipped sentence right here once worker 0.38.0 is live on your go. Shipped 2026-10-21 — worker 0.38.0 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): a KEEP GOING box on every routine row, the ship record closes on its own after a stop, and the checks that lied are made honest; the database's migration ledger now lists all 17 changes.
What changes for you: the ship's seed step (step 6 of 9 at the step door) only accepted the line a ship prints when it APPLIES the seed. But when a ship is picked up again after its deploy (resumed from step 8, nothing redeployed), it never re-applies the seed - it reads the seed back and prints a different, honest line saying so (SEED_READ ... resumed=yes). The door refused that line, so the v0.40.0 ship stopped at step 6 of 9. This patch, your pick on form note_6742 (Q1 A), lets step 6 take EITHER the applied line exactly as before OR the read-back line - and the read-back line only when it says resumed=yes; one saying resumed=no, or missing that word, is still refused. The step's instructions now mention the read-back line. Every other step, and every stop message, is unchanged byte for byte. The fix is pinned on the REAL read-back line, cut from the v0.40.0 ship's log by a script, never typed (THE REAL-LINE RULE): the new test fails on the old door and passes on the new one. worker 0.37.0 -> 0.37.1 (the step door only); no migration (still 17), no routine row edited, the PC sync (local 0.21.2) unchanged. Not verified before the deploy: a real resumed ship walking the served door past step 6 - the run checks that live. Shipped 2026-10-21 — worker 0.37.1 is served with local 0.21.2, deployed by the chat on your go (form note_6745 A, ship-guard OK, deploy.sh --detour after you switched the session off auto mode; the detour held back its own record line because the v0.40.0 checklist pins that version's numbers, so this row was written by hand on form note_6747 Q3 A): a ship that picks up again after its deploy now walks past the seed step - proved live, the v0.40.0 ship then walked parts 6-9 of 9 on the served door.
What changes for you: a Daedalus run no longer clocks out every time a phase ends. With "keep going" on - the default for every routine unless its settings say otherwise - it goes straight on to the next piece of work in the same chat and stops only at the context tripwire, a drills step that is only partly done, or a real STOP; a step the run is not allowed to do is parked and the run carries on with whatever does not depend on it. When the ship chain trips at its very end, the record still closes clean: one shipped-facts line, one mirror, the parked state and the door's ship step, with your answer on the plan form as the proof. The ship script now builds and checks every line it will print against the plan's acceptance list before it touches anything, the gate also catches a deploy command hidden inside a quoted string, and the bill carries measured numbers. Before a build, the live routine settings are pulled back by script and compared with the copies in the code. The served worker moves 0.36.3 -> 0.37.0 (a minor bump: one new chip on the run's first step); nothing on your machine changes (local stays 0.21.2), no database change. Not verified offline: the live door carrying "keep going" (the run's own live drill checks it after the deploy), the resume road on a real tail stop, and the pull-back's live write (a dry run only). Shipped 2026-10-21 — worker 0.37.0 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): a run keeps working to the tripwire, the ship record closes clean after a tail stop, the ship script proves its own lines, and the live settings are pulled back by script; the database's migration ledger now lists all 17 changes.
What changes for you: when you press Run now on a Daedalus routine, the run now counts you as present - every routine is treated as manual unless its settings say a scheduler fires it, so a deploy you approve on the plan form goes out in that same run instead of being parked for later. Every deploy, the normal ship and any one-off fix, now goes through one guarded script that checks the quiet window, deploys, checks the live health page three times, records what shipped and writes one log. And the ship script tests itself against the plan's real acceptance list before it touches anything, so the list the checker uses and the list the plan was written against can no longer drift apart. The served worker moves 0.36.2 -> 0.36.3; nothing on your machine changes (local stays 0.21.2), no database change. Not verified offline: the live door recording "attended" for a Run now chat (the run's own live drill checks it after the deploy), and the guarded deploy script on the real account. Shipped 2026-10-20 — worker 0.36.3 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): pressing Run now counts as you being there, every deploy goes through one guarded script, and the ship script checks itself against its own acceptance list; the database's migration ledger now lists all 17 changes.
What changes for you: nothing served changes - the worker stays 0.36.2 and nothing is deployed. The v0.39.1 drill walked all nine ship steps on a throwaway key, then started over on that SAME key and said "nothing to ship this time" - and the door answered "you are already past the ship". That answer was right: the door remembers each run, so a run that finished its ship is never asked to ship again, and a run that dropped halfway picks up at the step it stopped on. So the door is not changed; the drill is. It now makes a SECOND throwaway key for that one question, so the answer it checks is the real one. A new test reads the drill's own saved answers from v0.39.1 and turns red if anyone ever adds a "forget and start over" switch to the door. Not verified offline: the two fresh keys through the live door (the drills step proves it).
What changes for you: the ship's deploy step (step 4 of 9 at the step door) checks who is watching. When no one is (a scheduled run), the door accepted ONLY "the deploy was parked for later" - but when you had ALREADY answered A on the form that asks for the deploy go, the run rightly deployed, printed the real line saying so (go=form:<the form>:A), and the door refused it, so the run stopped at step 4 of 9 (the v0.39.1 ship's own log). This patch lets an unattended run pass step 4 with EITHER the parked line OR a real deploy line whose go is a written form answer A - nothing else: a go given any other way (for example "words:now") is still refused when no one is watching. The watched road and the no-chip road are unchanged byte for byte, and so is every other step. The step's instructions now say both roads. The fix is pinned on the REAL deploy line, cut from the v0.39.1 ship's log by a script, never typed (THE REAL-LINE RULE): the new test fails on the old door and passes on the new one. worker 0.36.1 -> 0.36.2 (the step door only); no migration (still 17), no routine row edited, the PC sync (local 0.21.2) unchanged. Not verified before the deploy: a real unattended run walking the served door past step 4 - the run checks that live. Shipped 2026-10-20 — worker 0.36.2 is served with local 0.21.2, deployed by the chat on your go (form note_6671 A, ship-guard OK, accept-edits after the classifier refused the deploy once): an unattended run that already has your written go now walks past the deploy step - proved live, the v0.39.1 ship then walked parts 4-9 of 9 on the served door.
What changes for you: last version split the ship into nine checked steps at the step door, but the door's check for step 8 (the ship's own record, the SHIPPED-FACTS line) was written from a typed example, not from a real ship - so the real ship's record was refused and every real ship stalled at step 8 of 9 (v0.39.0 finding F1). This patch changes that ONE check so the door accepts the real record (it may say how the ship resumed - no, park, mirror or a step number - and may end with the build id), and nothing else in the door moves. The fix is pinned on the REAL v0.39.0 ship record, cut from that ship's log by a script, never typed (THE REAL-LINE RULE): the new test fails on the old door and passes on the new one, and all nine real lines now pass. worker 0.36.0 -> 0.36.1 (the step door only), deployed on your go; no migration (still 17, the ledger only read), no routine row edited, the PC sync (local 0.21.2) unchanged. Not verified before the deploy: the real ship walking 9/9 through the served door - the run checks that live (a throwaway key, then this run's own ship). Shipped 2026-10-20 — worker 0.36.1 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): the ship can now walk all nine of its door steps for real; the database's migration ledger now lists all 17 changes.
Your two picks on form note_6648 set the job (Q1 A: deploy when the build is green; Q2 A: your own key opens the dashboard page). What changes for you: (1) THE SHIP AS A DOOR STEP - the ship step (J5) is no longer one line at the end; the door serves it as nine parts in order (preflight, guard, pull gate, deploy, health, seed, drift, shipped, mirror), each answered with the ship log's own line, copied byte for byte. A part out of order or a skipped part is refused by name and nothing is recorded; the old one-line answers still pass. (2) WHO IS WATCHING - the opening check-in now says attended=yes or attended=no. When you are watching, the deploy part waits for your go on the form; when no one is, the deploy is prepared for later and the run carries on, never deploying without you. (3) THE CLOSE-OUT CHECKS - the J8 line names its close-out file when leftovers remain (refused without it), and the J9 line names the absolute payload path and every skipped item, refused when the counts disagree. (4) THE PAGE KEY - GET / (the dashboard page only) opens with the owner key; a member key or no key is still refused, and every data route is unchanged. (5) THE OLD MODE WORD GONE - the read alias kept for one version is removed: a routine row is served as stored, a write outside CODING / MEASURE is refused (400); only the two migration files, this changelog, the design doc and the one pin that quotes the refusal still carry the word. (6) THE LEDGER WRITTEN - on your note_6643 Q2 A, the ship records migrations 0012 to 0017 in the live d1_migrations ledger (11 rows before, 17 after; the same command run twice inserts nothing the second time); no new migration file. (7) THE CLEAN DRILLS - the drills read the hands' D1 output correctly, use the key road for the page, keep every size answer whole in a folder, and run the 12 carried drills plus 5 new ones from one runner. Full record: DAEDALUS-DESIGN.md §14.42. Shipped 2026-10-20 — worker 0.36.0 is served with local 0.21.2, run by the chat in accept-edits (recorded as that road): the ship now walks the step door one part at a time, the dashboard opens with your own key, and the migration ledger is whole; the database's migration ledger now lists all 17 changes.
Your five points of note_6619 set the job. What changes for you: (1) THREE PROFILES BY NAME - efficient (slower, cheaper), balanced (the suite's main one: every routine that does not pick its own now runs on it) and fast (quicker, dearer); today stays in the list for the record, no longer picked by anything. Each profile's note carries numbers from a real test, not a guess: before the ship the build chat runs the same small job (add --version to the PC sync's command line, with a test) once per profile on a throwaway copy, measures the time and the tokens from the agents' own records, and checks the gap against a band - efficient 15-35% slower and at least 15% cheaper, fast 15-35% faster and at most 35% dearer. If a profile misses, one setting moves and the test runs again, three rounds at most; a profile still outside the band ships with its note saying so. Two new profile settings: "local first" (reads, maps and drafts go to the free local helpers first) and "merge rounds max". (2) THE MODE AS YOU SAID IT - the chat works in auto, lowers itself once only at the step that needs it (the deploy, a mirror push, a database read) and says so in one line; the texts that said otherwise are corrected. (3) CODING - the routine mode word is CODING everywhere: the database rows move with migration 0017, and the old word is still read for one more version so nothing breaks, but it can no longer be saved. (4) THE DASHBOARD SPLIT - "pick a routine" edits WHAT the work is, "save a profile" edits HOW FAST AND HOW DEAR it runs; no field appears in both. (5) WORK SIZE - minor, standard or major on a routine picks a smaller or the full job plan without touching the profile; standard is today's plan word for word. The live door moves 0.34.3 → 0.35.0 and deploys on your go (form Q1); the PC sync stays 0.21.2. Not verified offline: the cost weights per model tier (copied from the Claude API reference, named in the payload), and whether one small job moves the needle enough to read the band - the ladder and the three-round cap absorb it. (worker 0.35.0 · local 0.21.2 unchanged · migration 0017) Shipped 2026-10-19 — worker 0.35.0 is live (two builds in the one release: the first deploy, then the in-release patch above); migration 0017 applied and read back (10 routines CODING, 2 MEASURE, none on the old word); the four profiles are live with their measured notes and the whole suite now runs on balanced (the five routines pinned to fast were cleared, your Q2 A). Measured on a small test job over three rounds: fast ran 19–29% faster than balanced at about the same cost; efficient cost 61–69% less but was not slower on a job that small.
In-release patch, before the ship finished (J5 step 7e): the ship’s own key could only edit routines, not the run profiles, so saving the three profiles was refused (401); the owner’s key now reaches the profiles too, and any other key, a wrong key or no key is still refused. Same worker 0.35.0, rebuilt and redeployed in the same release.
Your words on 10-18 ("we better get this bullet proof very soon") set the job: fix every thing that stopped a run this week, so a scheduled run can go start to finish without anyone stepping in. What changes for you: (1) THE READ ROAD - the PC sync (local 0.21.2) gains one guarded way to READ the live database (hands.js --d1-read: SELECT or PRAGMA only, one statement, rows saved whole); the ship script reads through it instead of calling the database tool bare, so the safety check that refused three reads on 10-18 has nothing to refuse, and the sandbox guard stays exactly as it was. (2) THE AFTER STEP ONLY READS - the last step of a ship reads its results and writes nothing, so it reports honestly whether or not it is a rehearsal. (3) THE CHECK SCRIPT NEVER TRIPS ON ITSELF - a helper that one phase could not find is now defined for every phase, and the wall count separates script rows from agent rows. (4) THE SEAL SURVIVES THE RUN - the sealed cost estimate is never rewritten; measured costs go to a separate run file (bill.filled.json), every round count is read from the merge record, and over-cap notes are written from the measured tool count, never typed. (5) DOOR LINES AND WHOLE ANSWERS - the board and publish steps paste the exact line a script saved and keep each answer whole. (6) THE CLOSE-OUT FILE BY SCRIPT - the J8 step refuses to close without it and the J9 step cross-checks its count (todo_6605 D4/D5). Nothing you use changes on the live door: worker 0.34.2 stays, nothing is deployed, no migration (still 16), no template change (still 10). Not in this version: the door-side cross-check and the ship as one door step (todo_6605, todo_6337), each needs a worker bump and its own deploy. Shipped 2026-10-19 — committed with nothing deployed: worker 0.34.3 stays served with local 0.21.2, run by the chat in accept-edits (recorded as that road): every builder now hands back only after sealing its own work, and the ship's timestamp tests read the live rows' own times; the fast profile builds in 6 pieces.
worker 0.34.2 → 0.34.3: the step door only (lib/steps.js — the served J2 text and the served J2 check; index.js VERSION; package.json), no migration (still 16), no template change (still 10), no routine row edited, no restamp and no seed (the served text is laid over the stored index, the v0.23.8 rule). Built on your words, live in the Daedalus chat at 02:27Z after the 10-18 scheduled run stopped: "You are not to stop this session or clock out again for any reason until you fix and finish this. I want this to be usable by my next run." WHAT HAPPENED: the v0.37.0 build was GREEN (the merge gate 96 checks, the seal verified, the pull gate rehearsed) and the door refused its BUILT line because the merge took 4 rounds and the J2 check accepted only 1–3 — a count, not a gate, ended a run with everything built. (The first round ran before the inputs it checks existed; in the right order it is 2–3 rounds — now a trap note, not a stop.) WHAT CHANGES: the J2 check accepts any round count on a green gate; rounds beyond the plan's 3 are a RECORDED FINDING in the bill — the same rule you set on 10-16 for a builder over its step cap (note_6396 Q2) — never a stop; a red gate and a STOP line are still refused; "BUILT none" still passes. PROVEN: worker tests 499/499 (the new pin tests/steps-v0343.test.js R1–R3: the real refused line rounds=4 passes, a red gate / rounds=0 / a leading zero / a STOP line are refused, the served text is 387 chars and ≤ 400 under every tier, the stored index of every row is byte-equal to HEAD; 13 older pins re-measured to name the new served entry) · the five gen checks green · EVERY ROUTINE'S LIVE HISTORY REPLAYED through the patched door (the 438 live cursor rows, read through the guarded SELECT-only road of v0.37.0's piece A) = the same 140 outcomes as 0.34.2, zero differences · /health 0.34.3 env live after the deploy (the ship log carries the line). Not in this version: the rest of v0.37.0, which resumes at its BUILT line through this door; the docs city rebuild (docs.appolis.app) is the Appolis lane's. Shipped 2026-10-19 by shift sh_fd8d99d76f, deployed at once on your words (your 10-17 rule: no quiet window for a green patch on your go).
Nothing you use changes: the live door stays at 0.34.2, the PC sync stays at local 0.21.1, no migration (still 16), no template change (still 10), no routine row edited, and there was nothing to ask you (your rule from note_6526: when nothing served changes, the app's version numbers stay where they are and nothing is deployed). What this version does for you: (1) AN APP RE-SAVE NEVER STOPS A SHIP AGAIN. On 10-17 the desktop app re-saved a routine file with one extra blank line and the v0.35.0 ship stopped at its second step until someone fixed the byte by hand. v0.35.2 already taught the PC sync to put the right file back; this version adds the test that proves it (a re-saved copy with a blank line or Windows line endings is written back and counted as re-saved, and a copy with one real word changed is still refused) and teaches the ship's own drift check the same rule, so a re-save reads as "re-saved", never as drift. A real edit still stops the ship. (2) THE SHIP'S RECORDS TELL THE TRUTH: the record of how a version shipped now names the plan form on every road, and a ship with no deploy is recorded as committed, not as deployed; the checks at the end of a ship are found by name, so renumbering the checklist can no longer point them at the wrong line; the hand-edit drill reports how many rounds it ran; the server-health drill exits cleanly without the error message it used to print; and the cost estimate for the merge step now uses the most expensive merge ever measured (56 tool uses, 319,614 tokens, 29 minutes), with a 60-tool cap. (3) THE BUILD RAN AS FIVE PARALLEL PIECES, not six: the cost-tracking work was small enough to fold into the docs piece. Not in this version (filed on todo_6337): running the whole ship as a single step served by the door, which would change the live door and needs its own deploy. Not checked yet: whatever re-saved the file on 10-17 (the fix covers the bytes it leaves, whoever saves it), and the live drills, which run after this commit. Shipped 2026-10-18 — committed with nothing deployed: worker 0.34.2 stays served with local 0.21.1 unchanged, run by the chat in accept-edits (recorded as that road): every builder now hands back only after sealing its own work, and the ship's timestamp tests read the live rows' own times; the fast profile builds in 6 pieces.
worker 0.34.1 → 0.34.2 (the step door only) and local 0.21.0 → 0.21.1 (the PC's routine sync only); no migration (still 16), no template change (still 10), no routine row edited. Built on your words: "I'm not pressing run again until our routines are bullet proof for every session." Every routine's real run history was replayed through the door, every phase × blueprint combination a chat could send: on the 8 routines with history (131 combinations), the old door ended a run having done nothing 11 times and refused it outright 8 times; the new one does neither, and the 4 routines with no history (Phantasia, Recharge and the two measure routines) walk start to finish on both. What changes for you: (1) A CLOSE-OUT with nothing a run can do (no leftovers, leftovers that need you present, or a blueprint that isn't finished yet) is turned around on the spot to the work that is actually next, instead of ending the run empty. This is what happened to Kosmos today. (2) A finished close-out goes straight on into planning the next job in the same chat. (3) The door now TELLS each run which line to start with, from its own memory, so a chat no longer guesses the phase from the notes. (4) When the only next job is waiting on your form answer, a run says so in one line ("waiting on form …") and picks the next to-do that isn't waiting, instead of stopping confused (what happened to Hermes today). (5) Old finished blueprints are never handed steps they never had. (6) If the app re-saves a routine file with an extra blank line, the PC sync puts the right file back instead of refusing it for hours (what blocked the sync on 10-17). (7) The Remote Control switch never causes a form on an unattended run; a stopped step tells the chat to write the next run's line onto the handoff. Not fixed here (filed on the Appolis board, todo_6612): three connector clock-in quirks Kosmos hit while reporting.
worker 0.34.0 → 0.34.1 (the step door only: one rule plus the version number); local stays 0.21.0, no migration (still 16), no template change (still 10), no routine row edited. Found while checking, at your request, whether tonight's fix covers every routine: the Flip My Life lane's install plan holds its build until you answer a form, so its chat recorded the build step as "nothing built" and the check step then stopped. The door kept the "nothing built" as done, so EVERY later Flip run was handed the check step again, which stopped again — the same result every time, even after you answer the form. Now, when a run comes back to build a blueprint whose build was recorded as "nothing built" and whose check never passed, the door starts a fresh round at the build step, so the build actually runs. A blueprint that truly builds nothing (and whose check passed) is left alone, and a real build whose check found a problem still goes back to the check, as before. Proven by a new test that fails on the old door and passes on the new one, plus the same check run against all ten orchestrator routines (Appolis, Kosmos, Hermes, Flip My Life, Lander Builder, Recharge, FORGE, Phantasia, Warehouses, Daedalus).
worker 0.33.1 → 0.34.0 (the step door only: one file of its logic plus the version number); local stays 0.21.0 (nothing on your PC's side changes), no migration (still 16), no template change (still 10), no profile change, no routine row edited. Built because of your words in the chat tonight: "I'm sick of rerunning this and having the same result every time." What changes for you: (1) THE DOOR NEVER HANDS AN EMPTY RUN — last night's scheduled run asked to close out a blueprint (note_6524) that had in fact already been closed, because the handoff note told it to guess ("close out if the last step did not run"). The door then served one fact-reading step and a clock-out, and the run ended with nothing built. Now, when a run names a blueprint that has nothing left to do, the door answers on the spot with a REDIRECT: it says the blueprint is closed and hands back the exact line to send instead (start the next plan), records nothing, and the same run carries straight on into planning — the road your chat proved by hand at 22:57Z. The clock-out of a finished blueprint now also names that next line, and the opening prompt stops asking a chat to guess. (2) THE NEXT LINE COMES FROM A SCRIPT, NOT A GUESS — the handoff's "what to send next" line is printed by a script from the door's own saved answers, and the handoff template copies it word for word (no "if", no "see the clock-out"). (3) IT GOES LIVE ON YOUR ONE GO — worker 0.34.0 deploys as soon as every check is green, on your answer to form note_6552 (the only question this version asks); a drill sends the real closed-blueprint line through the connector before the deploy (the empty run) and after it (the redirect), so the fix is proven on the live door, not only in tests. (4) HONEST BOOKS — the leftovers from last version that fit one round: the parking record's knob is printed as found, one way of counting typed-in timestamps everywhere, the bill gains its re-plan and repair rows, the merge's time is the sum of its rounds, every helper agent is recorded the moment it starts, the README says which record is the ledger and that the review check runs twice, and the clock-out names the currency its token totals are counted in. (5) THE DECK ROW STAYS DEFERRED by your earlier answer (note_6511): the plain-English row lives here and in the design doc, and todo_6410 keeps the hub road. Shipped 2026-10-18 — worker 0.34.0 is served with local 0.21.0 unchanged, run by the chat in accept-edits (recorded as that road): every builder now hands back only after sealing its own work, and the ship's timestamp tests read the live rows' own times; the fast profile builds in 6 pieces.
No version bump and nothing served changes: worker stays 0.33.1 and local stays 0.21.0 (nothing is deployed and nothing on your PC's side changes), no migration (still 16), no template change (still 10), no profile change, no routine row edited — your pick A on this morning's form (note_6526). In the repo only four worker test files, one new test and these two docs move; everything else lives in the build's own folder. What changes for you: (1) THE FIRST MERGE ROUND COMES BACK GREEN — last time the six builders' work fitted together with no clashes, yet the check went red five times on bookkeeping (a file missing from the seal's list, a stale version number, a budget tally). Now every builder runs those same checks on its own copy and hands back only when they pass, so the merge has nothing left to find. (2) THE SHIP STOPS TRIPPING ON TIMESTAMPS — twice the pre-deploy check went red because four tests had the live routines' edit times typed in, and the last seed had moved them by one second. The tests now read those times from the routines the ship has just pulled, so nothing is typed in and nothing can go stale; a drill proves it on the real rows, and the costly re-measure step is spent only if the routines' shape ever changes. (3) HONEST BOOKS — the merge record says how many rounds it took and whether the expert merger was called; the merger's time is judged against the right estimate; the bill records who merged and for how long; the parking record is written on both ship roads; the version check also catches a stale re-measure note; the opening drill exits cleanly; and the planner's own cost is measured. (4) THE SHIP IS BUILT BY TWO BUILDERS (one builds the ship, one builds its checks), and every builder's tool budget is last run's measured figure plus 10% (cap 60; going over is recorded as a finding, never a stop). (5) THE DECK ROW STAYS DEFERRED, by your answer this morning (note_6511): the plain-English row lives here and in the design doc, and todo_6410 keeps the hub road. Your second answer on the form (a new "gameify" design-specialist sector for the wing) is filed as its own to-do and is not built here. This version is committed through the fence with no version bump; the ship still runs its whole chain with the deploy step skipped, so /health keeps reading 0.33.1. Shipped 2026-10-17 — committed with nothing deployed: worker 0.33.1 stays served with local 0.21.0 unchanged, run by the chat in accept-edits (recorded as that road): every builder now hands back only after sealing its own work, and the ship's timestamp tests read the live rows' own times; the fast profile builds in 6 pieces.
worker 0.33.0 → 0.33.1 only (a PATCH, todo_6546, Tyler's ask in the Daedalus orchestrator chat); local stays 0.21.0, no migration, no template, profile or routine row change. What changes for you: when a blueprint holds more than one version (the Kosmos board's note_6456: part A finished, part B still to build), pressing Run now for the build used to be told "everything here is already done — clock out", so the build never started. Now, when a run asks to plan or build on a blueprint whose closing step already passed, the step door opens a fresh round and serves the build steps again. A run that asks to ship or close an already-finished blueprint still gets "nothing left" (that guard stays), and nothing is deleted. Also in this commit: an older Daedalus test had a fixed date typed into it and started failing on every copy 24 hours later; it now reads the real clock (your pick, form note_6543 Q1 A). Tests: worker 472/472 (the new A9 is red on the old door and green on the new one), local 352/352.
worker 0.32.0 → 0.33.0 only; local stays 0.21.0 (nothing on your PC's side changes), no migration, no template change, no profile change, no routine row edited. What changes for you: (1) THE SHIP CANNOT GET STUCK AT THE MIRROR AGAIN — the small resume fix you approved this morning (note_6502) is now a permanent part of every ship, not a one-off patch: if the last step (copying the design doc to its live mirror) stops, the ship re-runs only that step and carries on. Before anything deploys, the ship now reads the LIVE mirror's fingerprint and stops early if the settings file names the wrong one, so a wrong setting can no longer surface only after the deploy; and if that last step ever stops, its message prints the live fingerprint beside the expected one. The ship also refuses to arm until the chat has saved the record of each step it was handed (last time one was forgotten). (2) THE THREE RED DRILL LINES GO GREEN FOR REAL — the opening check reads the served version from the worker's own health page (the status tool needed a job id it did not have), the hand-edit drill reads the floor's own word straight from the worker (the editor's full row now carries a floor field) and checks the routine file by re-syncing it, and the graph drill reads one run key across a resume. (3) THE PUBLISH STEP FOR EVERY LANE, proven — a pinned test walks a Daedalus row and an Appolis-shaped row through the run and ship and shows both reach the PUBLISH step after the board post; a step already done is still never run twice. (4) A FASTER BUILD MERGE — the six build pieces edit separate files, so they are now put together by a script on a fresh copy and tested there in minutes; the expert merger (last time 30 minutes on its own) is called only if that test goes red. Each piece now gets a tool budget in its brief. (5) THE DECK ROW — the plain-English row for the features deck goes onto the hub doc you name; if none is named, it waits with its reason printed (todo_6410 keeps that road). Shipped 2026-10-17 — worker 0.33.0 is served with local 0.21.0 unchanged, deployed by the chat in accept-edits (recorded as that road): the same chat now goes on after the ship to run the drills, post the board block with every agent's measured time, and print the PUBLISH line, and the fast profile builds in 6 pieces.
worker 0.31.1 → 0.32.0 only; local stays 0.21.0 (nothing on your PC's side changes), no migration, no template change, no routine row edited. What changes for you: (1) ONE CHAT CAN FINISH A VERSION — after the deploy, the same chat is handed the drills, the board post, a new PUBLISH step and the review, in that order (run → ship → drills → board → publish → review). Until now a lane's ship chat stopped after the board post and the rest waited for a second chat - Appolis had three runs that never reached the finish flag that way. A step already recorded as done is skipped, never run twice, and a STOP line still stops the run with nothing moved. The board post now comes after the drills, so the release note carries the drill results and the timing lines in one write. (2) THE PUBLISH STEP — the run now has a step that publishes a lane's skill package through the connector and reads it back. Daedalus has no skill package of its own yet (your pick), so on Daedalus the step prints an honest "nothing to publish" line with its reason. (3) YOU NEVER EDIT THE SHIP SETTINGS FILE — the red hand-edit drill line last time was the drill's own mistake: the ship already reads your push key from the file on this PC, and the drill now takes the same road; the key is read on the PC and never printed. (4) THE SMALL DRILL FIXES — the stop-line drill asks for the right step numbers (it was two behind since the check-in steps were added) and sends the run the way the door expects; the local drill prints the model's name instead of "[object Object]"; the opening S0 line is printed by a script instead of by hand. (5) HOW LONG EACH RUN TAKES — every agent's working time is read from its own record the moment it finishes and written into the bill, and one timing line per job goes onto the board with the release note, with the chat's own turns beside them. (6) THE FASTER EXPERT TEAM, first slice — the fast profile's build now splits into 6 smaller pieces instead of 4 (last time two of four ran over their budget), so a build waits on the slowest of six small pieces, not four big ones; this version was itself built that way. Shipped 2026-10-17 — worker 0.32.0 is served with local 0.21.0 unchanged, deployed by the chat in accept-edits (recorded as that road): the same chat now goes on after the ship to run the drills, post the board block with every agent's measured time, and print the PUBLISH line, and the fast profile builds in 6 pieces.
worker 0.31.0 → 0.31.1 only; local stays 0.21.0, no migration, no template bump, no routine row edited. What changes for you: v0.31.0 added two steps (the check-in and the clock-in) to the front of every run, so a chat that was already halfway through a run when it went live sent its next step number two too low and was stopped by a mismatch - that is how the v0.31.0 run itself ended right after its own deploy. Now, when a step's answer does not fit the step its number points to, the door checks the step it actually handed out last (the next one not yet done, on its own record) and accepts the answer there if it fits; anything that fits neither is still a stop, and nothing is recorded for it. A fresh "Run now" was never affected. Pinned by worker/tests/steps-v0311.test.js (the exact call that stopped: step 7 carrying the ship line, now passes and serves the board step). Gates: worker 456/456.
worker 0.30.2 → 0.31.0 and local 0.20.2 → 0.21.0; no migration, no routine row edited. What changes for you: (1) THE THIN ROUTINE — each of the 12 routine files on your PC becomes the same 7-line note (only its name and its one-line sidebar description differ) that says "call daedalus_step and do what it answers"; every instruction now lives in one place, Daedalus, so the files can no longer drift out of date, and the scheduler's habit of trimming a blank line and the last line break no longer changes them (the to-do about that, todo_6445, is closed by the new shape). (2) THE DOOR HANDS OUT EVERYTHING — the check-in (model, effort, Remote Control) and the clock-in are now steps Daedalus serves and checks before the next one, and every answer carries the context tripwire. (3) SMALL BLOCKS ASK INSTEAD OF STOPPING — a chip setter the pane refuses, a tool it will not run, or a stale helper file now posts ONE yes/no form on your board and the run keeps going; a real mismatch, a collision on a lane or a STOP line still stops. (4) THE 15-MINUTE AUTO-SYNC STAYS — it no longer matters for routine text (a note changes only when its description changes), but your park-form "A" deploys through it, so nothing is deleted; a line typed into one of the notes is still refused and reported, because instructions belong in Daedalus. (5) THE SWITCH-OVER — after the deploy, one script writes the 12 notes through your PC's hands: hephaestus-session first as the live proof, read back byte for byte, then the other 11 (local 0.21.0 adds the hands' --only so it can do them one at a time). Template 10 is the note; template 9 stays on file. Shipped 2026-10-17 — worker 0.31.0 is served with local 0.21.0, deployed by the chat in accept-edits (recorded as that road): each Daedalus routine file is now the same short stub that only calls the door - the instructions live in Daedalus alone, the check-in and the clock-in are served and checked by it, and a small block asks you one yes/no form instead of ending the run (the thin routine files written and read back 12/12 (hephaestus-session first)). No migration (16), template 10 restamped by the seed, the pull gate skipped (the live pull changed nothing), the sync wrote 0 render(s), feature commit a5d0da4.
worker 0.30.0 → 0.30.2 and local 0.20.1 → 0.20.2; no migration, no template bump, no routine row edited. What changes for you: (1) THE BOARD STEP (J7) no longer strands Kosmos and Hermes — tonight both shipped (Kosmos v8.139.0, Hermes v2.169.1) and then stopped at J7, because it told them to run their ship script in a "board" mode only Daedalus's own script has (running theirs would have redeployed). J7 now checks the script first: with the board mode it runs as before; without it the chat writes the release note onto the board itself, reads it back, and never touches the ship script. (2) YOUR FORM ANSWERS COUNT AGAIN — Kosmos v8.139.0 now says who answered a form as a small record (name, e-mail, person or AI) instead of plain text, and Daedalus's reader turned that into nonsense, so every answer you gave would have been refused as "not the owner" and the hands' automatic deploy would fall back to the manual road. The reader now accepts the record, matches you by account or e-mail, and refuses any answer an AI ticked. Gates: worker 442/442 · local 350/350.
local 0.20.0 → 0.20.1 only; worker stays 0.30.0 (nothing to deploy), no migration, no template bump. What changes for you: when the PC's hands stop a ship on their own (tonight: the scheduler's rewrite of the routine file read as a hand edit) and the chat then finishes the same ship in accept-edits on your word, the park record now says "deployed by the chat's fallback" instead of refusing to record it (lib/park-states.js: ship-exit-1 joins the fallback reasons; an answer refusal — wrong person, wrong form — still never moves, and the hands' own road never takes it). Pinned by tests/park-v0301.test.js. The two other fixes from form note_6450 live in the payload, not this repo: the SHIPPED block now goes to the board through the Appolis connector (the chat posts it and reads it back) instead of the Downloads env file, and the step-10 guard matches only the appended record. Gates: worker 442 · local 349 · overseer 167 · bench 12.
worker 0.29.0 → 0.30.0 and local 0.19.0 → 0.20.0 (the PC hands change, so both move; this one row names both); overseer stays 0.1.17; no migration (16 total), no template bump (still 9), no routine row edited, no seed change. What changes for you: (1) THE ANSWER LEG — last version your A on the park form was refused because Kosmos forms do not record who answered. Now the hands decide without that field by BOARD PROOF: the form is the one THIS park posted, it sits on your board, it was answered after the park, and it was read over your own key. When Kosmos starts sending who answered (todo_6410), that is read first and wins. What board proof cannot prove - which person on your account clicked - is printed as unproven=person on every park line that follows an answer (a verdict, a release, a deploy, a deploy-time refusal), never hidden; a line before any answer claims no proof. If the hands cannot finish, the chat finishing the same ship in accept-edits is now a RECORDED road (road=accept-edits), not a red. (2) J7 BOARD — the ship graph gains one step after the ship: a script appends the SHIPPED block to the plan note over the PC's one board-write road (local/lib/kosmos-apply.js gains appendNote: Kosmos's update_note with appendText only - it can add to a note, never replace or rename one - bracketed by a read before and a read-back after), then the plain-English deck row, and the chat only records the one BOARD line; there is no road yet for the deck doc, so this version says deferred and the row is filed by hand at the close - never a stop. Nothing about your saved routines moves: the new step is added when a step is served, so no row is rewritten. (3) THE DRILLS — the four red drills now take the roads the doors actually take (the step door wants your Appolis ID, so the chat makes that ONE call and the script checks the rows), and the walls and fan-out tokens are measured by script instead of left blank. (4) THE WING, second slice — wing/assign.mjs cuts the 283 roster seats (290 minus 7 duplicate rows folded into their originals) into teams of four inside each domain, every file with exactly one owner and no file in two teams, plus the seat brief every seat will be handed (its files, its domain, the 60-step cap, the one report line, and "a report is never a verdict"); this version is also the first build merged by a Fable merger agent on a fresh stage, timed. (5) Small fixes on the ship: REMEASURE happened=no when nothing was pulled, the mirror retries once after a 20-second pause on a server error, and steps 8/8a print once each. NOT VERIFIED OFFLINE: the hands' live read of this version's form under board proof, the key's account id as the live road reports it, the first timer fire after the commit, the deploy, and the deck-doc road. Shipped 2026-10-16 — worker 0.30.0 is served with local 0.20.0, deployed by the chat in accept-edits (recorded as that road): your A on the park form now deploys without Kosmos naming who answered, the chat's fallback is a recorded road, the board rows are posted by script at J7, and the wing's seats are cut into disjoint file groups. No migration (16), template 9, no seed change, the pull gate skipped (the live pull changed nothing), the sync wrote 0 render(s), feature commit 516a346.
worker 0.28.0 → 0.29.0 and local 0.18.0 → 0.19.0 (the PC hands change, so both move; this one row names both); overseer stays 0.1.17; no migration (16 total), no template bump (still 9), no routine row edited. What changes for you: (1) THE AUTO-MODE DEPLOY ROAD (your note_6396 answer) — the chat no longer has to race you for an "allow" click on the deploy. It writes ONE "armed" file and stops; the hidden auto-sync task your PC already runs every 15 minutes picks it up, does every pre-deploy read (who is logged in, the guard, the live pull and its test gate, the drift count) and PARKS right before the deploy. The chat then posts ONE inbox form quoting those lines. When you answer A, the next timer fire checks again that nothing moved (your answer, the sealed build, the code unchanged, nothing uncommitted, within 24 hours) and deploys through the same ship script. One deploy per answer; answering twice does nothing; a park that went stale refuses loudly and deploys nothing; B releases it. (2) A BUILDER OVER ITS STEP BUDGET NO LONGER STOPS A SHIP — it is written down as a finding in the bill and the review; only a red test gate stops anything. (3) THE MERGER SEAT (todo_6337) — every run profile gains a seventh seat, "merger": the model that merges a fan-out's pieces. Empty means "the builder's model", and an empty seat changes nothing at all (no routine is re-stamped); the fast profile gets Fable, set once by the seed and only if you had not set it yourself. (4) THE WING ROSTER, FIRST SLICE — a free script reads the harvest index of the 43 repos you dumped and the forge's map of them, and writes wing/ROSTER.json: every real, checked piece of a liftable repo becomes an expert seat with its license role and its source path; pieces of study-only repos become idea seats that are never copied; pieces whose path the mirror does not hold are counted and never seated. Every count is measured from the two files, and a check regenerates the file and compares it byte for byte. The forge's map is only read, never written. (5) THE SIX v0.28.0 LEFTOVERS — the live drills read this chat's own saved envelope, the "STOP" drill on the throwaway key, the hand-edit drill undone in the same run, a written guard waiver that no longer compares a stale minute, the step-count scan reads only scripts, and a conditional job is found in the bill. (6) BUILT BY FOUR OPUS BUILDERS on files that never overlap, each measured for tools, tokens and wall time and gated by machine, never by its own report. Shipped 2026-10-16 — worker 0.29.0 is served with local 0.19.0: a routine chat that stays in auto mode can now ship (it arms, your PC parks right before the deploy, you answer once, your PC deploys once), a builder over its tool budget is a recorded finding instead of a stop, every run profile has a merger seat (fast uses fable), and the wing roster lists the expert seats from the harvest.
worker 0.27.0 → 0.28.0 only; local stays 0.18.0 and overseer stays 0.1.17; no migration (16 total), no template bump (still 9), no routine row edited. What changes for you: (1) THE STOP FIX GOES LIVE — version 0.27.1 taught the step door that a chat printing a "STOP …" line at the check step has stopped: nothing is recorded and the same step is served again. It was committed but never served; this ship serves it and proves it on a throwaway run, read back. (2) EVERY SHIP RE-MEASURES THE TESTS AGAINST YOUR LIVE SETTINGS (your answer A: "each ship re-measures those tests against the fresh live copy") — the ship still copies your live routine settings over the saved copy first; now, before anything is deployed or committed, the worker tests run on a fresh copy of the code with those settings. Green: the ship carries on and the copy joins the ship's commit as before. Red: the ship stops by name, puts the two files back exactly as they were, keeps the pulled copy, and writes ONE re-measure job for one builder — every expectation moved to the live value and marked, nothing loosened — then the same ship command runs again. No hand restore, ever again. (3) THE SEED'S DATE FOLLOWS YOUR EDITS — the one date stamp in the seed file is now the later of a fixed floor and one second after your newest dashboard edit, so it can never be older than that edit (today it changes nothing live). (4) THE ROUTINES LIST SAYS "HAND-EDITED" — the full routines list (the one the dashboard's editor reads) now carries, per row, whether your PC holds a hand-edited copy and the last pushed fingerprint, so a script reads it instead of guessing; tested on a clean row, a reported hand edit and a "use the row" take, and the editor page ignores the new fields. (5) THE HIDDEN AUTO-SYNC, CHECKED LIVE — the drills read the scheduled task itself: it starts hidden (no console window) and has fired on its timer since the ship. (6) TWO AUTO-SYNC TESTS NO LONGER DEPEND ON THE FOLDER — on a deep checkout folder they used to fall back to "path too long" and never checked the installed line; they now reach the code through a short path they control (with a deep folder simulated on purpose) and check the installed, hidden-window line on every machine; the too-long refusal keeps its own test. (7) THE SHIP SCRIPT TEMPLATES — the sync check is read from the hands script's own print line instead of being typed in, a ship resumed after the deploy reads the first run's sync count, the ship prints the permission mode it runs in and stops in the wrong one, and the check script gains a review phase. (8) BUILT BY FOUR OPUS BUILDERS on files that never overlap, each measured for tools, tokens and wall time and gated by machine, never by its own report; no Sonnet or Haiku this version. Shipped 2026-10-16 — worker 0.28.0 is served with local 0.18.0: a chat that answers STOP at the build check is stopped and served the check again, every ship now tests your live routine settings before it deploys, and the full routine list says which rows were hand-edited.
worker 0.26.0 → 0.27.0 only; local stays 0.18.0 and overseer stays 0.1.17; no migration (16 total) and no template bump (still 9). What changes for you: (1) A FIFTH PHASE — the step door gets CLOSE-OUT with one slot, J9, that carries a finished blueprint's leftovers: the live checks that were skipped, the re-fires, the to-do closes, each its own line a script prints. Two runs in a row found no slot for that list and clocked out at the end; now a handoff that says PHASE=CLOSE-OUT is served J9, never the clock-out, until its line is in. (2) THE REVIEW CAN HAND YOU THE LIST — the review's closing line may say how many leftovers there are, and when it does the door walks on into CLOSE-OUT in the same chat; a blueprint with no leftovers is served exactly as before. (3) A PATCH ROUND MAY END HONESTLY — when the handoff names no code fix, "PATCH-2 none" with a reason is accepted instead of an invented fix. (4) NOTHING RE-RUN THAT IS ALREADY GREEN — an item with a saved green line is re-verified from that line, never run again. (5) THE FIRST USE is version 0.26.0's own list: the after-chain, the editor and hand-edit drills on a real row (with a scripted road named up front in case the click is refused again), the fact-checker's case re-fired on your PC for $0, the routine description that still says "sonnet" corrected through the editor, and the twelve routine-fix to-dos closed by id, each only with the line that proves it. (6) THE TEMPLATES STOP LYING — the ship script keeps its version in one place, the commit message is read from a file that must name this version, and a ship stopped after the deploy can resume at the sync step. (7) THE WIDE FAN-OUT TRIAL — this build ran as twenty pieces on files that never overlap (4 Opus, 6 Sonnet, 10 Haiku), each job on the cheapest model that does it reliably, every piece measured for tools, tokens and wall time and gated by machine, never by its own report; this overrides the fast profile's "never Sonnet" for this trial only, by your word on form note_6348. Shipped 2026-10-16 — worker 0.27.0 is served with local 0.18.0: a blueprint's last chat can close out its leftovers through a fifth CLOSE-OUT phase, and the hephaestus-session routine's description no longer names a model.
worker 0.25.0 → 0.26.0 and local 0.17.0 → 0.18.0; one migration (0016: run_profiles gains a fanout column); overseer package unchanged at 0.1.17. What changes for you: (1) THE ONE WRITE ROAD — a routine's text is written only through the Worker's editor route (PUT /api/routines/:id); the floor page and the ship's row edits both use it, and the seed only adds rows it does not have. (2) THE PULL THAT REFUSES — your PC compares each installed routine file with the last one the Worker sent it; a file you edited by hand is never overwritten: the pull names it, the floor shows HAND-EDITED, and only "use the row" (or --take) replaces it, keeping the old file as .prev. Each row shows synced, pending (a row or profile change not pulled yet), hand-edited or never. (3) PAUSE — a paused routine's file opens with a stop line, so pressing Run does nothing until you un-pause it. (4) FAN-OUT — the profile says whether a build fans out: fast fans out four pieces with a 60-tool cap each and the chat merges them; today does not. (5) The routine text now carries template 9: it names the model your profile picks for each worker slot (no "Sonnet agent" under fast), a docs lane only on a ship, and the step text's other fixes the lanes filed. (6) The fact-checker (Elenktes) seat moves from qwen3:32b to qwen3.8:27b, its map-first road cites resolve the way the grader resolves them, and its quotes against a map are checked against that map's line. Starting a routine from the app is measured only; the button comes in a later version. Shipped 2026-10-16 — worker 0.26.0 is served with local 0.18.0: routines are edited and paused from the app, a hand-edited routine file is refused by the sync instead of overwritten, and the fast profile carries the fan-out setting.
worker 0.24.1 → 0.25.0 and local 0.16.3 → 0.17.0; no migration; overseer package unchanged at 0.1.17 (its new exam, grader and learn script ride in the same commit). What changes: (1) THE GROUNDING RULE v3 — Elenktes's answer (manifest version 3) gives every quote a how, one sentence on what that exact line shows about the claim, and a counter: the cite of the one quoted line that contradicts the claim, or no cite and the literal words 'no grounded counter-evidence'; the local door (lib/ground.js) refuses a quote without a real how, a counter that is not one of its own quotes, and a "refuted" whose counter line is not where it says it is; an answer in the old shape is refused as shape. (2) THE 2026-10-15 EXAM — a new known-answer set of 46 claims, 10 of them a new kind, "support": a true claim whose obvious line looks damning while the deciding line (a guard, a gate, an early return) sits elsewhere; case #1 is the kosmos guarded handler that fooled it before, frozen word for word; 6 old claims were re-pointed to frozen copies of files too long for the 3,000-character refuter window; the 2026-09-30 set stays as history; a learn script turns one thrown-away refutation into one new exam case (no model, no network). (3) TWO ROADS AND A THREE-RUNG LADDER — the grader runs Elenktes either reading the files itself (direct) or reading only a map Anagnostes draws first (mapped), and now scores whether its counter-evidence is the deciding line and whether it took the decoy; the ladder is qwen3:32b direct, qwen3:32b mapped, then qwen3.8:27b (18 GB, pulled by the chat when the ladder runs) on the winning road; its numbers come from that run, and until the new bar is met Elenktes's word stays advice and the check step prints only its skip line. (4) THE EXPLICIT TIMEOUT — the "This operation was aborted" failures were the door's own silent 180,000 ms limit in bench/scripts/lib/ollama.js chat(); every call now passes its limit (a thinking refuter gets 600,000 ms), the limit is written on the call's ledger row, and a call that is cut off is ledgered as a timeout with its elapsed time. (5) TEMPLATE v8 — the routine text names the six slots (J1, J-last, pinner, builder, executor, helper), each with the model your bound profile gives it, so a fast routine no longer says "sonnet builder"; the seed restamps the twelve routines to template 8 and leaves your run profiles untouched. (6) THE AUTO-SYNC — node local/hands.js --autosync install|status|remove|run: a Windows scheduled task, DaedalusAutoSync, runs the same routine sync every 15 minutes and writes one line per run to ~/.claude/daedalus-autosync.log (or DAEDALUS_AUTOSYNC_LOG); the install is read back, other platforms are refused by name, and the tests stub the scheduler (HANDS_SCHTASKS_BIN) so no test registers a real task; the ship installs it with the --autosync hands after the sync. (7) The test routine drill-throwaway is removed at the ship by one delete on that id, read back. Shipped 2026-10-15 — worker 0.25.0 is served: the refuter's grounding rule is live, every routine file now names its six worker slots from its profile, the throwaway drill routine is gone, and your PC now pulls routine changes from the dashboard by itself every 15 minutes.
worker 0.24.0 → 0.24.1 and local 0.16.2 → 0.16.3; no migration; overseer stays 0.1.17; no routine row, template or render changes (the step door's served text only). What you can use: (1) the routine sync on your PC (node local/hands.js --sync-routines --door cli:claude --tasks-dir <dir>) no longer asks for a folder list it never needed — the v0.24.0 ship stopped on exactly that line; (2) the ship script can be re-run from step 4 (SHIP_RESUME_FROM=4): it deploys again, proves the migration and the seed by reading them (never re-applying), then finishes the sync, the drift read, the commit and the mirror; (3) the step door remembers a blueprint across the handoff notes the Appolis lane files every run, so J4 and J5 are not served twice, and when a phase is finished the door serves the next phase's first open step in the same run (RUN+SHIP, then DRILLS and the review) instead of "clock out"; a partly-done drills part still ends the run, and the clock-out line names the next run's PHASE line. A blueprint-less run behaves exactly as before. Ships together with v0.24.0, which was deployed on 2026-10-15 but never finished its PC sync. Shipped 2026-10-15 — worker 0.24.1 is served (/health 0.24.1): the step door goes on to the next phase and remembers a blueprint across handoffs, and your PC has the twelve new routine files.
worker 0.23.16 → 0.24.0 (the v0.23.16 number — a version-only bump committed on 2026-10-15 — ships with this deploy); local stays 0.16.2 (the hands are unchanged: your PC still pulls the new files itself with node local/hands.js --sync-routines, there is no sync button yet); one migration, 0015 (two new tables, fifteen migrations in all); overseer stays 0.1.17; the routine template moves v6 → v7, so every one of the twelve routine files is re-written once. v0.24.0 THE ROUTINE EDITOR — what you can use: (1) An editor on the Daedalus dashboard, for you alone: pick a routine and change its knobs, lanes, mode, baseline command or body, one routine at a time; every change is listed old → new before Save turns on, a bad value (an unproven model such as Haiku, an unknown profile) is refused by name with the Worker's own words and nothing is saved, and nothing on the page deletes anything. The routines card also shows SET or SUGGESTED beside every knob. (2) Run profiles — named ways of running a routine: the chat's model, its effort, Remote Control on or off, and which model plans (J1), reviews (J-last), pins, builds, runs and helps. Pick one for a single routine, a project, a kind of routine (orchestrate or measure) or the whole suite; saving a profile re-renders every routine that uses it. Two ship: today (how everything runs now — nothing changes until you pick otherwise) and fast (an Opus chat, Remote Control on, Fable plans and reviews, Sonnet does the rest — it differs from today in exactly two things, the chat model and Remote Control). (3) A routine chat's first line is now CHECKIN profile=… model=got/want effort=got/want remote=got/want set=yes|asked|no: it sets what the pane lets it set (each setter once) and asks you ONE question for what the pane refuses; whether an unattended run may call the setters is not proven yet, and the first differing pick will show it. (4) From this ship the dashboard is the truth about routines: the repo file becomes a one-time import and a fixture refreshed from the live table before every deploy, so a later seed can never overwrite what you edited. (5) Through the connector each person sees only their own routines and readings and you see all; a second person goes live when the Appolis grant (todo_5898) is served. Measured: worker 371, local 251, overseer 146, bench 12 tests, migrations 15; routines 12 rows, template 7, the twelve restamped once. Not verified offline by the build: the deploy and the migration, the live check-in's set=yes|asked, the editor in the signed-in pane, the second identity. Shipped 2026-10-15 together with 0.24.1 — the editor, the run profiles, the check-in line and the per-person views went live on 2026-10-15; the PC sync that had stopped on a missing --roots finished with 0.24.1.
local 0.16.1 → 0.16.2 and worker 0.23.15 → 0.23.16 BY NUMBER ONLY (the two version lines; nothing else in the worker changes and nothing is deployed by this version — what is served stays 0.23.15 until the next ship; no migration; overseer stays 0.1.17; no routine row, template or render changes). v0.23.16 THE HOLD + THE PREFLIGHT — what you can use: (1) The odometer stops re-posting your refresh token. The first real refresh (v0.23.15, 2026-10-15 02:37Z) was answered HTTP 429, and the road had no memory of it: every tripwire call of every routine chat posted the token again (six of six in one run, todo_6143). Now a refresh that fails — any HTTP answer, a timeout, an unreachable host or a malformed reply — writes a hold: the Retry-After the server asks for when it gives one (capped at a day), else five minutes; until it passes the third line reads LIMITS status=refresh-http-429-hold … until=<time> and nothing is sent, not even a read of your sign-in file. The answer's status, its Retry-After and the SHAPE of its body (the field names, never a value, never a token) are kept once in the local cache so the real endpoint's reply can be seen. (2) An expired refresh token is named before any request. Your sign-in file also carries the refresh token's own expiry (it passed on 2026-10-14 12:03Z — the likely cause of the 429); when it is past the line reads LIMITS status=refresh-token-expired expired_at=<the access token's date> refresh_expired_at=<the refresh token's date> and no request is made. A fresh claude login renews both. (3) Every ship starts with wrangler whoami. Your question on 10-15 ("why are we not just doing wrangler whoami first every time?") — yes: the read-only call that has cleared the Cloudflare 7403 at three ships running is now the FIRST line of the ship script, PREFLIGHT whoami=ok|refreshed|STOP account=<who>, before anything else; a ship that deploys stops by name when a real re-login is needed instead of retrying. Measured: worker 340, local 251 (the new limits-v0162 suite included), overseer 146, bench 12 tests, every generated surface ok, migrations 14; routines 12 rows, template 6, untouched. Not verified offline by the build: the live LIMITS line after the commit (the chat's own tripwire reads it) and the real whoami at the ship. Committed 2026-10-15 — not deployed: local 0.16.2 is in the repo (a failed token refresh now waits before asking again, and an expired refresh token is named before any request), and worker 0.23.16 is a number waiting for the next deploy (what is served stays 0.23.15).
worker 0.23.14 → 0.23.15 and local 0.16.0 → 0.16.1 (no migration; overseer stays 0.1.17; no routine row, template or served text changes, so nothing is restamped). v0.23.15 THE HONEST LIMITS + THE ELENKTES CALL — what you can use: (1) The plan-limits line stops lying. Claude Code's sign-in token expired on 2026-09-16, so the odometer's third line was a bare http-401; now it says LIMITS status=token-expired expired_at=<the date> refresh=not-released. On your Q2 = A pick the ship adds a second consent to the consent file and Daedalus asks Anthropic for a fresh token the way Claude Code does — the token lives in memory for the one question, is never written to your file and never printed; if Anthropic turns out to rotate the refresh token, the road closes itself (one claude login may then be needed). The first real call is made at the ship and is the only proof of the endpoint. (2) Every worker's bill is measured, not typed: a script reads a subagent's own transcript the moment it returns (the old hand sum counted each answer once per content block — 8,734,986 against a measured 3,799,806), the ledger writes an agent row only from that measurement, a chat row takes its model from the transcript instead of a default, and the two chats stamped with the wrong model are re-signed by script. (3) The run meters understand the second round: the cursor line gains round=<k>, step-runs calls a slot that outlived one chat "served again" instead of failing it, and the stuck-key sweep judges only the current round. (4) The drills switch a real, toggleable app (your pick: visualize) on and off and claim it only when both switches were seen. (5) The connector's routine list is a page instead of 228,000 characters — one short row per routine — and the routines tool takes an optional id to read one row whole. (6) The Elenktes call: you picked DROP IT — the refutation step prints your pick and no run spends a turn on it until a score exists; the fix is homed to the next version. (7) The ship prints every check before it stops, and no check names a served version by hand. Measured: worker 340, local 244, overseer 146, bench 12 tests, migrations 14; routines 12 rows, template 6, no restamp. Not verified offline by the build: the deploy, the first real token refresh (whether Anthropic rotates the refresh token is unknown until it runs), the served lean list and the live drills. Shipped 2026-10-15 — worker 0.23.15 is live and local 0.16.1 is committed: the plan-limits meter names an expired token, the bill of every worker is measured from its own transcript, the run scripts understand a second round, and the routine list through the connector is a page (live routine rows: 12, unchanged: nothing was restamped).
worker 0.23.13 → 0.23.14 (no migration; local stays 0.16.0; overseer stays 0.1.17; the twelve routine rows restamped — no body changed; the installed renders unchanged by content). v0.23.14 THE PATH IN THE LINE — what you can use: (1) The Warehouses orchestrator is unstuck. Its honest J0 line named its payload folder under "F:\Claude Code\.blueprints", and the door's check demanded a path with no spaces, so the run died at J0 after its plan agent had already been spawned (todo_6118, your note of 10-14 on form note_6094). Now the J0 check takes any one-line payload text and the J1 check any one-line design/review text — a path with spaces, a Windows path, or a bare name. (2) It cannot come back on any routine: a pinned test walks every orchestrator row through J0 and J1 with a spaced path on the real connector road, and a structural pin reads every check the door serves — a \S+ may only follow a field that is never a path (chat_model, effort, version, served, sh_). (3) The fix is at the source (the slot text), so every row's stored index is restamped under ONE stamp; the fix is live once the ship's seed and sync have run. Measured: worker 333 tests (the new steps-path suite included), local 232 (gate environment), overseer 146, bench 12, every generated surface ok; migrations 14; routines 12 rows, template 6. Not verified offline by the build: the deploy, the seed and the sync, the served door (a throwaway-key walk of warehouses-session after the ship proves it; the Warehouses lane's own next Run now is the proof that counts). Shipped 2026-10-14 — worker 0.23.14 is live: a payload path with spaces passes the step door's J0 and J1 checks on every routine (live routine rows: 12).
worker 0.23.12 → 0.23.13 (no migration; local stays 0.16.0; overseer stays 0.1.17; the twelve routine rows restamped — one body changed, forge-session; the installed renders unchanged by content). v0.23.13 THE SECOND ROUND — what you can use: (1) The Flip My Life session is unstuck. Its blueprint runs round after round on the same two notes, and the step door remembered round 4's plan as done — so every new PLAN run was sent straight to clock-out (todo_6078, your note of 10-14 00:27Z). Now a PLAN run that lands on a key whose plan already passed opens a NEW ROUND: the door records a ROUND marker, keeps every old row (nothing is deleted), tags the new round's rows apart, and serves J0 again; the chat is told in the envelope's done list. The same holds for every orchestrator routine. (2) The Forge orchestrator's baseline rule (its P2 step) no longer says the levers test should read 16 ✔ / 2 ✖ — it says 17 ✔ / 0 ✖ / 1 skipped, the truth since the Forge lane's commit 98df8e7 (todo_6022); the row's text is served by the step door, so the fix rides in the row, not the render. Measured: worker 326 tests (the new steps-round suite included), local 232 (gate environment), overseer 146, bench 12, every generated surface ok; migrations 14; routines 12 rows, template 6. Not verified offline by the build: the deploy, the seed and the sync, the served door (the Flip My Life run's next Run now proves the round; a served forge-session P2 envelope proves the rule). Shipped 2026-10-14 — worker 0.23.13 is live: a second plan round on the same notes opens a new round at the step door, and the Forge routine's baseline rule is true (live routine rows: 12).
worker 0.23.11 → 0.23.12 and local 0.15.1 → 0.16.0 (no migration; overseer stays 0.1.17). v0.23.12 THE PLAN LIMITS + THE LIFTS — what you can use: (1) The tripwire is yours: all twelve routines and the step door's own tripwire field print --warn 500000 --handoff 700000 --turns 375 (your form note_5895 Q3); until now they printed 200000 / 300000 / 150. The twelve routines move to template v6 in one restamp, and the ship applies the seed and the sync so the installed copies follow (todo_6056). (2) The clock-in line is ready for the clock-out token (your form note_6023): template v6 adds ONE sentence — write the token after the shift id in the fence file when the clock-in reply carries one, clock out with the same pair; a session served no token works exactly as before. (3) A build that stops on a design defect is no longer a dead end: the phase line may end in next=REPLAN and the door serves a REPLAN step (Fable rewrites the plan; REPLAN-2 … REPLAN-9 for more), on the PATCH machinery, with no tenth slot (todo_6053); the RUN step's publish-only text of v0.23.11 now lives in the stored slot itself. (4) The odometer learns your plan (local 0.16.0): after every step a third line, LIMITS five_hour=<p>% resets=… seven_day=<p>% resets=… plan=… , says how much of the 5-hour and weekly allowance is used and when each resets. It is released only by your tick on the plan form (note_6069 Q7 = A): the ship writes the consent file, and WITHOUT that file Daedalus does not even open Claude Code's sign-in file; with it, the token is read into memory for one request to Anthropic's own usage address, never printed, logged or stored, and only the percents, reset times and plan label are kept (the local reading file only — the push to the Worker never carries them). A failing call never changes the tripwire's verdict. The build proved all of it on a fake sign-in file and a local stand-in; the first real call at the ship is the proof of the real endpoint's shape. (5) The bill gains the honest dollar: a cache read is priced at a tenth of the input rate (the odometer's plan dollar figure drops for chats that re-send a big context; stored rows are never repriced), agent rows may record how many rounds a job took (one-shot column on the bill), and measure/honest-dollar.mjs says what was NOT spent on Fable. (6) Lifted from the six repos you named (ideas only; nothing installed, no repo's code touches your credentials): the refuter's card is numbered and its cites must quote the line they point at (a verdict needs a grounded cite); the drills cannot pass on nothing any more (one drill app really switched on and off, the connector's tool count by script, one real floor value and the page's console errors); a doctor line names the traps before a session starts; and a routing table, manifests/routing.json, says which worker takes which kind of task, checked by a script with no model call. (7) The old "every connector write must go through a helper" rule is retired in the Daedalus orchestrator's body (todo_4558): the connector echo is shared per session, so a write from the chat costs a little, not six thousand tokens. Measured: worker 315 tests, local 232 (with the gate's two environment variables; 4 stage-only fails named and identical at HEAD without them), overseer 146, bench 12, every generated surface ok; migrations 14. Not verified offline by the build: the deploy, the seed and the sync, the served door, the real usage endpoint and the real sign-in file's shape, and the drills. Shipped 2026-10-14 — worker 0.23.12 is live and local 0.16.0 is committed: every routine prints your tripwire figures, the clock-in line is ready for the clock-out token, a REPLAN step exists for a design defect, the odometer can show your plan limits behind your consent, and the bill gains the honest dollar (live routine rows: 12, restamped onto template v6).
worker 0.23.10 → 0.23.11 (no migration; local stays 0.15.1; routine rows, renders and the seed byte for byte unchanged; overseer stays 0.1.17). v0.23.11 THE PUBLISH-ONLY RUN — what you can use: (1) The RUN step of every orchestrator routine accepts a second honest line. Until now it demanded a commit (HANDBACK commit=… suite=pass porcelain=0), so a run whose whole job was to publish a hub document for your marks — the FLIP 8 round-4 publish on the Flip My Life board, todo_6051 — stopped at that step with a truthful mismatch and the Flip My Life session was stuck. Now a publish-only run prints PUBLISHED doc=<doc id> version=<version id> bytes=<n> (the hub's own read-back of what it stored) and goes on to its SHIP step, which already allows "J5 none" when nothing ships; a run that does commit prints the same HANDBACK line as before. (2) Nothing else moved: the text rides in the served layer of the step door, so no routine row, render or seed changed and no migration ran. Measured: worker 290 tests (the new steps-publish suite included), local 225 (gate environment), overseer 146, bench 12, every generated surface ok; migrations 14. Not verified offline by the build: the deploy and the served door (the Flip My Life run proves it on its next Run now). Shipped 2026-10-13 — worker 0.23.11 is live: a publish-only run passes the RUN step honestly and the FLIP 8 round-4 publish can go through the door (live routine rows: 12, unchanged).
worker 0.23.9 → 0.23.10 and local 0.15.0 → 0.15.1 (no migration; routine rows, renders and the seed byte for byte unchanged; overseer stays 0.1.17). v0.23.10 THE HONEST METERS + THE CLEANUP FIXES — what you can use: (1) The cleanup forms stop tripping on their own machinery (local 0.15.1): a form that the 💬 comments box joined is still approved, matched to the wave by its items instead of by position (todo_5937); a proof marker can be checked against the saved source of the page it claims to be on, and a marker that is only a note-title phrase is reported missing (--kosmetor-probe --page, todo_5938); your own answer of any length passes both checks because the provenance now keeps it whole (the 201-character case, todo_5939); a question that offers nothing shows no "yes, all of these" line (todo_5940); a "no" can name the screen it was judged on (--no with --source, todo_5941); an empty round posts nothing and records no form (todo_5945 b); and hands.js --cursor --json prints the rows the door recorded, so a drill saves them with the command that exists (todo_5985). (2) The comments form is where a run's apps are picked (worker 0.23.10, todo_5946 and todo_5947): write "apps: hermes, phantasia" in the box and the run switches exactly those apps on at its first step and off before its clock-out; a routine can also ask for the comments form after every run with the new knob comments_form (true or false, default false; nothing is switched on in any live routine by this version — you flip it with POST /api/routines). The texts ride in the served layer, so no routine row, render or seed changed. (3) The meters stop miscounting: the odometer counts the FINAL output of a streamed answer (the last copy of a message, the first copy's time), the "every step ran once" meter no longer counts the step it is running in or the throwaway key, every ledger row carries its estimate (a chat's is the middle of its last namesakes), and the ship reads the routines drift BEFORE it deploys and puts a lost final newline back. Measured: worker 284 tests, local 225 (with the gate's two environment variables; 4 stage-only fails named and identical at HEAD without them), overseer 146, bench 12, every generated surface ok; migrations 14. Not verified offline by the build: the deploy, the served door and the drills. Shipped 2026-10-13 — worker 0.23.10 is live and local 0.15.1 is committed: a cleanup form the comments box joined is approved, a long answer passes, a question with nothing to offer shows no "yes, all", a run's apps are picked on the comments form, and the meters count honestly (live routine rows: 12, unchanged).
worker 0.23.8 → 0.23.9 (no migration; local stays 0.15.0, overseer 0.1.17). v0.23.9 THE REVIEW ALWAYS RUNS — what you can use: (1) A blueprint's run always ends in its review. The drills step told every routine's chat that the drills come in four parts, so a blueprint with ONE part printed "part a of d", the door waited for three parts that do not exist, ended the run before its review, and the next run had no honest line to print (todo_5962: the Appolis session's run 15). Now the drills step asks for one part a run and for the blueprint's LAST part letter ("a/a" for one part, no part at all for a design that names none), and for a part the blueprint does not have it asks for the totals of what already passed. So the run that stopped short gets its review on its next Run now, with no hand edit of the board's memory and no made-up line, and a blueprint with one part, two parts, four parts or none reaches its review. (2) The door, not the chat, holds the rule. A line for a step is accepted only after every step before it has passed under that run: the review needs the drills finished, the close needs the review, the clock-out comes only after the close — a close line sent early, a retry or a second chat cannot skip the review. A drills line whose part comes after the last (part b of a) is refused like a wrong part. (3) Five step texts (plan, check, ship, drills, clock-out) say "run next-inputs only when the payload has it", so a chat whose payload lacks that script no longer has to print a line it cannot, and the clock-out's own text now fits its 400-character cap (it was 423). The routine rows, their renders and the seed are byte for byte unchanged — the new texts are laid over the stored steps when they are served — so there is no migration, no seed and no sync this version. Measured: worker 272 tests, local 211, overseer 146, bench 12 (all pass; the 15 new tests of steps-review.test.js and the re-pinned T8 of the cursor suite are included); migrations 14. Not verified offline by the build: the deploy, and the drills on the served door (the throwaway key, the stuck key read, the sweep of the twelve cursors) that the next phase runs. Shipped 2026-10-13 — worker 0.23.9 is live: every routine run now ends with its review, and the step door refuses to close a run that skipped it (live routine rows: 12, unchanged).
worker 0.23.7 → 0.23.8 (plus migration 0014, the table routines_cursor) · local 0.14.5 → 0.15.0 (overseer unchanged at 0.1.17). v0.23.8 THE PROOF ROAD — what you can use: (1) The cleanup can prove an old version note from the app's own screen. The proof map gains a new kind, "a screen": it ties a picture taken with you (the 7 FLIP HQ pictures of 10-11; they stay on this PC, the map carries only a file name, a fingerprint and a size) to the app version a note claims. A note is offered to you only after you look at the live page at the sitting and the page shows the feature's name (the name comes from the note's title or the app's changelog line, never from text read off a screen). What you tick is a template and nothing else: a bold name, one plain line with the day and the picture's name, one link to the app. A round with nothing to tick no longer posts a form; one line says why. A round of that kind already on record (wave 2 of 10-11: nothing to tick, never posted) no longer blocks the next dry run or rebuild: it is measured and rebuilt in place, its old form is kept under superseded_forms with one line saying so, and a form that offered something and was never posted still stops the next build. The sitting commands stop and ask for --wave instead of quietly using wave 1. The dry run of the next round now prints how far the road reaches (PROOF_DRY) and re-reads the to-dos a handoff names live from the board, so a to-do closed since the last walk is seen closed. (2) The routine step door remembers. Each run picks up where the last one stopped: the door writes what it served and what passed (the new table) and never serves a finished step again; a fix the handoff asks for is a served step (PATCH: its pinned test, the build, the check, one commit through the fence, nothing deployed); the drills step is served in four parts, one part a chat; every phase that ends prints the next phase's inputs and the clock-out requires them. Every served step still fits one envelope (the echo of finished steps gives way first). You and the hands can read the rows (GET /api/routines/<id>/cursor, node local/hands.js --cursor --routine <id>). The routine rows, their renders and the seed are byte for byte unchanged — the new step text is laid over the stored steps when it is served — so there is no seed and no sync this version. (3) The token meters count each answer once. A transcript writes one line per block of an answer, so the old reader counted an answer up to three times (the v0.23.7 J8 chat: 149 lines for 57 answers, 2.74 times the cache reads); the odometer, the tripwire's command and the new transcript reader now read through ONE function, and a session id the app made up (local_…) or a missing transcript fails loudly (NO-TRANSCRIPT, exit 2) instead of printing zeros. The turn cap in the routine rows was tuned on lines and is not changed here (changing it needs a row restamp); measure/retune.mjs prints the cap in answers that fires at the same real point. (4) The pool's Haiku 5.5 is proven in this release only if its second machine-judged build pass landed at the check (worker/src/lib/routines.js POOL is the record). Measured: worker 257 tests, local 211, overseer 146, bench 12 (all pass; the 13 worker, 26 local and 4 parity tests that pin this version are included); migrations 14. Not verified offline by the build: the live migration and deploy, the cleanup sitting with you, the three one-minute fresh chats and the after-number, the Haiku shadow's judged line. Shipped 2026-10-12 — worker 0.23.8 is live and local 0.15.0 is committed: the step door remembers where a routine run stopped (live routine rows: 12, unchanged), the meters count each answer once, and the cleanup can prove an old version note from the app's own screen once you have looked at it at the sitting.
worker unchanged at 0.23.7 · local 0.14.4 → 0.14.5 (overseer unchanged at 0.1.17; nothing deployed). v0.23.7 patch THE OPEN-WAVE RULE COUNTS ONLY WHAT WAS OFFERED — what you can use: (1) The next cleanup round can be drafted again. Wave 1 held 75 items, but the question you answered showed you only the 6 proven done; you ticked those 6 and they were applied on 10-09, yet the other 69 — never shown to you — kept wave 1 "open", and both commands that draft the next round (--kosmetor-propose and --kosmetor-wave) refused with "wave 1 (note_5467) is open — approve and apply it first". A round is now open only while an item it actually SHOWED you is still waiting; the items it held but never showed go back into the pile for a later round, and the run says so on one line ("wave 1 (note_5467) is closed — 6 offered, all answered; 69 not offered go back to the pool"). (2) Which items a round showed is read from the saved map its form was posted with (every form from local 0.14.4 on) or, for an older form, from the form file that was posted — never from the dossier, which marks what was proven, not what was shown. (3) When that list cannot be read (the form file is gone or damaged, or the round has no form record) the run keeps the old strict rule — every item the round holds counts — and now says why on ONE line just before it stops, instead of stopping without a word. Measured: local 185 tests (185 pass; 11 new in kosmetor-openwave.test.js, all 11 fail on the 0.14.4 code and pass on this one; the two older open-round STOP tests pass unchanged); the Worker, the routine rows and every other number are unchanged. Not in this version: the next cleanup round itself (the second sitting) and any change to what gets archived.
worker 0.23.6 → 0.23.7 · local 0.14.3 → 0.14.4 (overseer unchanged at 0.1.17). v0.23.7 THE SECOND SITTING — what you can use: (1) The cleanup form you tick is readable: each choice is a bold name, ONE plain sentence on why it is safe and ONE "See proof" link — no machine codes on your screen. The codes the run needs (which proposal each tick means) are kept in a saved map written when the form is posted, and your ticks are read back from that map by position, never by reading the screen; a form with neither codes nor a map is refused by name. Two new read-only commands prepare the next wave: --kosmetor-propose lists it and --kosmetor-lanes names the lanes the apply must clock in with. (2) Every routine is served the six lessons of the last run inside the step they govern (seal paths from the payload root, no silent catch on a drill road, measure the real handler before writing a stub, the payload carries its own drill inputs, the pane check at the start of the drills, ship.env stays out of the seal, a FIT line and a STOP cap for every helper job), and the close step carries the rule that nothing a worker reports is trusted: every helper write is read back and every helper number re-run. (3) The Hermes routine no longer says its files are CRLF, and the helper-check rule is in the Daedalus and Appolis routines too; ten routine rows are restamped so the one seed write reaches the live rows. (4) A test that sometimes failed (the floor page's served-at time) is fixed at its cause — another test rewrote the seed file in place while the rest read it — and the generator now writes through a temp file. (5) The Haiku proof's judge now stops with a usage error that names the missing file instead of reporting a hash mismatch. Measured: worker 244 tests (all pass, the pinned file included), local 174, overseer 146, bench 12, every generated surface ok, 12 of 12 routine rows with a generated steps index on template 5, migrations 13 (none added). Not in this version: the in-app routine editor (v0.24.0), the connector's per-person tool list (the Appolis lane), and the attended parts that need you at the pane, which are carried by name unless they were sat. Shipped 2026-10-11 — worker 0.23.7 and local 0.14.4 are live: the cleanup form is readable, its ticks are read back by position, and every routine is served the last run's lessons (live routine rows now: 12).
local 0.14.2 → 0.14.3 (worker unchanged at 0.23.6, overseer unchanged at 0.1.17; nothing deployed). v0.23.6 patch THE RESTART ROAD READS BY ID — what you can use: (1) Approving the same cleanup form again after its batch was applied (the restart of the archive drill) no longer stops with "the Worker refused the decisions (409 … is applied)": the restart looks each decided item up on its own, finds it applied (or undone), prints resumed=yes with the real count of every state (applied:6, or applied:5,undone:1) and posts nothing. (2) Applying a batch by its batch id (--kosmetor-apply --batch) has the same repair: asked about a batch that is already applied it now lists each applied item as already applied (noop) and applies an item you undid again, where it used to report an empty batch. (3) When the restart check cannot say yes it now says why on ONE line (KOSMETOR_APPROVE resume-check none reason=…): the Worker's refusal and its error, an item the Worker does not know, an item still waiting for a decision, an item that belongs to another form, an item another batch answered otherwise, or the connection's own error — and then decides exactly as before; it used to say nothing at all. Why it happened: the Worker moves an item to its apply batch the moment it is applied, so the v0.23.6 check, which listed the decision batch, found it empty once anything was applied (confirmed on the live Worker, the six archived notes, batch kb_78dfbac4, 2026-10-10); the test stand-in for the Worker had kept the old batch, so the v0.23.6 tests never showed it. Measured: local 166 tests (166 pass; 14 new, and the version test now pins 0.14.3); the 15 changed or new tests fail on the v0.23.6 code and pass on this one; the Worker, the routine rows and every other number are unchanged. Not in this version: the form-readability fix (v0.23.7), the next cleanup wave and the second proof sitting.
worker 0.23.5 → 0.23.6 · local 0.14.1 → 0.14.2 (overseer unchanged at 0.1.17). v0.23.6 THE ROUTINE GAME PLAN — what you can use: (1) A routine session no longer carries a 22–33 kB rulebook: its file is three things — the effort check, the clock-in and ONE call to Daedalus (daedalus_step). Daedalus answers with step 1 of N: what to do, the exact command, the one line that proves it and the one rule that step needs. The session runs it, pastes the line back, and Daedalus CHECKS the line itself before it hands out the next step; a line that does not match is a STOP step ("report it as it stands, clock out"), never a guess. The long rules stay whole on the Worker and are served in slices, so nothing a lane wrote is lost. When you edit a routine and save it through POST /api/routines, its step list is now rebuilt in that same write, so the owner's road can no longer leave a stale index behind (and a stale index is still never served: the door refuses it by name, STEPS STALE). (2) The twelve routine rows — the eight that stay plus Forge, Kosmos daily, Phantasia weekly and Warehouses, adopted from the lanes that converted them — move to template v5, each with its steps index generated from its own text; the lanes' words are byte-for-byte unchanged. This reaches the live Worker in one write on your yes: the deploy, then the seed, then ONE sync, after a read-only diff of every installed render against the rows. (3) Small repairs: the floor reading prints plain digits and reads the pane's saved form of the reply; a restarted archive approval returns its existing batch instead of a 409, and applying a batch reports already-applied rows as noop; the apply names the lane to clock in with before it writes and again when the board refuses for want of a shift; the Haiku proof's judge reads node 24's summary lines and a numbered claim and prints its own self-test line, and its new shadow mode prints the proof line for a real shadow run itself, so nobody writes it by hand. Measured: worker 233 tests (233 pass, the pinned file included), local 152, overseer 146, bench 12, 12 of 12 routine rows with a generated steps index (template 5, every slice at most 6,000 chars), the Daedalus row renders 2427 bytes where its template-v3 file was 22850 (9.4 times smaller), door tools 19 (was 18), migrations 13 (was 12). Not in this version: the in-app routine editor (v0.24.0), per-step persistence, the form-readability fix (v0.23.7), the next cleanup wave and the second proof sitting. Shipped 2026-10-10 — worker 0.23.6 and local 0.14.2 are live: a routine now connects and is told one step at a time, Daedalus checks each step's proof line itself, and the twelve routine rows carry the short template (live routine rows now: 12).
worker 0.23.4 → 0.23.5 · local 0.14.0 → 0.14.1 (overseer unchanged at 0.1.17). v0.23.5 THE FIRST ARCHIVE + THREE ORCHESTRATORS — what you can use: (1) The six cleanup items you ticked (note_3372 · note_4101 · note_4624 · note_601 · note_3904 · note_3919) are archived for real, from your saved answers, through the one apply road: each one is read back gone, put back once and read back, archived again and read back, and the run prints every read and every undo id, so "undo" is a thing you watched, not a promise. Nothing is deleted. Your own words beside a tick are kept as a comment and never hold the batch back. (2) Hermes, Lander Builder, Flip My Life and Recharge ops become rows in the Daedalus routine registry: the registry holds each routine's settings and pushes the file, a routine sync can no longer revert Hermes to its old text, and a routine in a folder without git no longer carries a fence line it cannot use. They go live in one write on your yes: the deploy first, then the seed, then one sync. (3) No helper runs on Haiku until Haiku 5.5 proves, by a machine-judged build task, that it no longer elides code and claims "done" without a green gate: the model pool rule is in the code (an unproven model is refused as a plan or run tier when a routine is written), every routine now runs its helpers on Sonnet, and the proof test ships as a script. (4) The free refuter answers in full (no 2,048-token cut-off) and refuses an over-sized window instead of guessing; every helper call, even an aborted one, leaves a ledger row. Underneath: routine template v4 (v3 plus the no-git fence guard, the helper on the routine's own run tier and a trust line: nothing a worker reports is trusted until the chat reads it back), the approve step reading words beside a tick as a comment, and a started-row sidecar beside the ledger. Measured: worker 202 tests (the two pinned files included: R 7 of 7), local 146 (H 6 of 6), overseer 146, bench 12, gen 6/6 (9 routine rows, template 4, the floor page 54453 chars), the two walls and the true flag exact, door tools 18, migrations 12 unchanged, no D1 change, no new route. Not in this version: a second sitting, the in-app routine editor (v0.24.0), the rename and any wing exercise. Shipped 2026-10-09 — worker 0.23.5 and local 0.14.1 are live: the cleanup archive drill and the three orchestrator rows are ready, no helper runs on Haiku, and the free refuter answers in full (live routine rows now: 6).
worker 0.23.3 → 0.23.4 · local 0.13.0 → 0.14.0 (overseer unchanged at 0.1.17). v0.23.4 THE PROOF PASS — what you can use: (1) the next cleanup question shows, beside every item you can tick, the proof the run itself saw — the line on the app's page, the command's own answer, or the board's own read — quoted with where and when; a number (a version row, /health, a test count) only decides what to look at and never decides "done". (2) Every item the run could not see is listed with its reason — a site you skipped, a screen that needs a click, no store sign-in, no read-only way to show it — and is never offered. (3) For every screen item the sitting saves a screenshot: its fingerprint sits in the 🧾 note beside the quote, and the pictures are on one private review page linked from the note (inside the note itself once Kosmos learns the attachment door — asked on the board). (4) The DAEDALUS floor page opens on a dash, never on zeros, shows its real numbers when it has read them, and says loudly — FLOOR ERROR, on the page — when a reply is missing a section or a refresh cannot be read. Underneath: a proof rule in the dossier and a proof map that gives every item one proof kind (a screen, a read-only line, the board's own read); the sitting's record written by machine with caps and one entry per item; the probes, the screenshot command (one inline PowerShell, inside the Claude window only), the gallery page and the hub upload on your PC (local 0.14.0); the Appolis docs page is now read through its redirect, so the Appolis items are judged on the page itself; and the floor fix (worker 0.23.4). Not in this version: applying wave 1 — that waits for your ticks on proof you can see. Shipped 2026-10-08 — deployed and checked live (version 0.23.4, environment live): the database did not change (no migration), the routine list is as it was (6 routines), and the Daedalus floor page now opens on a dash and shows its real numbers or an error you can read; the next cleanup question waits for the run you start at the computer, where each item is looked at with you before anything is asked of you again.
worker 0.23.2 → 0.23.3 · local 0.12.0 → 0.13.0 (overseer unchanged at 0.1.17). v0.23.3 THE DONE DOSSIER + THE TRUE FLAG — what you can use: every cleanup question in your Inbox carries, per item, one plain line you can judge — what it is, why it was proposed, done? yes / partly / no / can't tell with the proof (the version row in the app's own changelog, the live version on the app itself, a newer handoff) and whether it was seen on the screen — and it says DAEDALUS, Appolis, Hermes, never a code name. Only items proven done are offered for archiving; every other item is listed with its reason in a 🧾 DONE DOSSIER note, and nothing moves until you tick. The 75 items of wave 1 come back this way after a run you start while you are at the computer: it opens each app, waits for you to sign in (it never types a password) and only looks. And the board can never be written on a flag the door did not send: a note read without its archived flag now stops the apply before anything moves. Underneath: a dossier step and a form builder on your PC (local 0.13.0), the projects named as the board names them, the missing-key message now naming the file to set first, and the Worker version bumped to 0.23.3 so this version's own row is judged by its own rule once it is live. Not in this version: applying wave 1 — that waits for your ticks. Shipped 2026-10-07 — deployed and checked live (version 0.23.3, environment live): the database did not change (no migration), the routine list is as it was (6 routines), and the 75 items of wave 1 now wait for the run you start at the computer, where they are looked at with you signed in before anything is asked of you again.
worker 0.23.1 → 0.23.2 · local 0.11.2 → 0.12.0 (overseer unchanged at 0.1.17). v0.23.2 THE APPLY ROAD — what you can use: tick boxes (or "✅ yes, all of these") on a cleanup form and the board does the work itself: exactly what you approved is archived, or closed for a to-do, and nothing else, one item at a time, each one read back and recorded before the next, and every move has a one-step undo that puts the note back byte for byte (the note's "last edited" time is the one thing that moves). Your answer in words on the first form counts: the 23 appolis notes you approved there get archived, and the one not actually done stays where it is. From now on every project's cleanup questions come to the Daedalus board three projects at a time, each with a "yes, all of these" box, and the board sweep is a routine you start by hand whenever you want one — never on a timer. Under the hood: one database change (two new columns, still 22 tables), two new routes behind the same two locks as the rest, a form whose to-do is still open is held back instead of archived, the design doc's "═══" sections are filed one by one, and the day's filing budget counts what the database actually bills. 190 worker tests and 112 local tests green. Shipped 2026-10-05 — deployed and checked live (version 0.23.2, environment live): the two new record columns are in the live database, the board-sweep routine is in the live routine list (6 routines; registering it in the sidebar is Tyler's click), and the first real cleanup — the notes Tyler approved on the first form — runs next from his PC, one item at a time, each with its undo.
local 0.11.1 → 0.11.2 (worker unchanged at 0.23.1, overseer unchanged at 0.1.17; nothing deployed). The first full filing of Tyler's board stopped at his biggest note — the 288,000-character living design doc, 1,810 memory records in one upload — because the filing script gave the memory 30 seconds to answer and the memory needed longer (the same note had already gone through once when given three minutes). The two memory uploads the census makes now wait up to 180 seconds; every other call keeps its 30 seconds. The filing resumes where it stopped and is safe whichever way the two interrupted uploads ended: the memory never files the same note twice, and a note it already holds is simply counted as already there. The drill's one-line report now reads the walk's and the filing's final verdict instead of the first line it saw, which had made it call a finished walk "not run"; it can also run the filing alone, without re-reading the board. Still nothing on Kosmos is changed by code.
~, the mark every shared-project id carries (acc_…~note_…). A shared note's origin is exactly kosmos:<its Kosmos id>, like every other note's; nothing else the checks refused is accepted.note_12 is that account's note_12, never Tyler's.local 0.11.0 → 0.11.1 (worker unchanged at 0.23.0, overseer unchanged at 0.1.17; nothing deployed). The first real census stopped before it read a single note: the census script had been built for Kosmos's own connector, which the suite has retired — one Appolis connector now serves every app. The script now finds the Kosmos reads behind the Appolis connector by their kosmos_ names, checks the door before its first read and stops with a plain message when the door is wrong, and its read-only wall got stronger: the Appolis connector reaches every app in the suite, so every one of its tools except the five Kosmos reads is refused before anything leaves the PC. It also ignores the short compliance notice the connector adds to each answer, and waits and retries when the connector asks it to slow down. Still nothing on Kosmos is changed by code.
worker 0.22.0 → 0.23.0, local 0.10.0 → 0.11.0 (overseer unchanged at 0.1.17). Daedalus can now take a census of the owner's whole Kosmos board — every project, note, checklist, decision form and to-do — by reading it through Kosmos's own connector door with a script that is only allowed to read (any other request is refused before it leaves the PC), so nothing on the board is changed. Every note is filed whole into Daedalus's memory, nothing shortened and checked note by note that nothing was lost, so a chat can ask the memory about any project and get answers quoted from the real notes. Simple rules sort what is done, superseded, duplicated, empty, stale or overdue, and turn the clear cases into cleanup proposals — archive, mark done, merge — that wait for the owner's yes on a decision form; the local AI only gives advice, and its advice counts only when the quote it gives is really in the note. An auditor step proves the books balance — every item filed or accounted for, nothing lost — or stops loudly. A new tool, daedalus_kosmetor, shows the last census, the report and the proposals waiting. Applying the approved cleanups, with undo, is the next version (0.23.1). Migration 0011 adds three tables (22 in all); 18 door tools. Blueprint note_5112 · doc row v0.23.0 (§14.20). Shipped 2026-10-02 — deployed and checked live (version 0.23.0, environment live): the three census tables are in the live database. The new routes and the daedalus_kosmetor tool sit behind the owner's sign-in and are exercised by the first real census (the J6 drills), which runs from the owner's PC once his Kosmos connector URL is saved in its key file (Downloads/kosmos-mcp.env); nothing on the board is changed by it.
worker 0.21.1 → 0.22.0, local 0.9.1 → 0.10.0 (overseer unchanged at 0.1.17). Daedalus can now make a sandbox for any project — a separate copy of its code on its own branch, kept outside the folder the live work happens in, and for Daedalus itself also its own test copy of the service with its own database — and the owner can say, platform by platform (Claude, ChatGPT, Codex), whether that platform may touch live, the sandbox, or both. The limits are code that refuses, not instructions: a new tool, daedalus_sandbox, lets the owner flip a platform and hand it its own key (shown once, stored only as a fingerprint), and a sandbox-only platform's key is turned away from live Daedalus with SANDBOX ONLY, with the refusal written in the ledger; the commands that make and tear down a sandbox cannot deploy, push, touch the main branch or the live database, and refuse by name if asked. The owner's own key keeps working exactly as before, and a caller that does not say which platform it is meets no wall — the check on the connector door is built and tested but stays dormant until the Appolis connector starts naming the platform (a to-do on the Appolis board). The honest limit: a platform running on the owner's own PC can read any key file there, so the per-platform key is a wall against the key it was handed, not against one it could find. Two small fixes ride along: the live test that checks the local door now names the right environment variable, and a rejected answer's ledger row now records which lines the quote was actually found on. Migration 0010 adds three tables (19 in all); 17 door tools. Blueprint note_5077 · doc row §14.19. Shipped 2026-10-01 — deployed and checked live (version 0.22.0, environment live): the sandbox and the walls are in. The owner can now flip a platform between live, sandbox and both with one tool call, hand a platform its own key and revoke it, and a sandbox-only platform's key is turned away from live Daedalus; Daedalus also has its own sandbox copy (a separate Worker with its own database, at https://hephaestus-sandbox.appolis.workers.dev). The check on the connector door is built and tested but stays dormant until the Appolis connector starts naming the platform.
worker 0.21.0 → 0.21.1, local 0.9.0 → 0.9.1, overseer 0.1.16 → 0.1.17. When Elenktes, the refuter, quotes a line word-for-word but names the line just above or below it, the local door now corrects the line number instead of throwing the whole answer away — only when the quote is on exactly one neighbouring line and nowhere else, never further away — and every correction is written down (in the answer's own cite, in the call's record and in the score line), never hidden. A wrong answer is still refused whole and is never rewritten. Elenktes was then re-scored once, on the bigger qwen3:32b model with thinking on, with that fix: it cleared the 0.90 bar — qwen3:32b with thinking on scored 0.917 (33 of 36 right, every quote on its line), so the settings now use it and Elenktes's answer counts as evidence with its quotes. The roster and the drills now say which model earned a score beside the score, so a result earned by one model is never read as another's. The live test and the live drill now judge the config that is actually committed, so they cannot pass on the wrong model or fail on the right one. No migration (16 tables), no seed change. Blueprint note_5050 · doc row §14.18. Shipped 2026-10-01 — deployed and checked live (version 0.21.1); Elenktes, the checker that tests claims against the code, now runs on the bigger qwen3:32b thinking model, which scored 0.917 against the 0.90 bar (one claim better than v0.21's 0.889), so its answers that pass the door count as a real check; the door also fixes a quoted line number that is exactly one line off and writes down that it did.
worker 0.20.1 → 0.21.0, local 0.8.1 → 0.9.0, overseer 0.1.15 → 0.1.16. Elenktes, the refuter, now answers evidence first — the quotes, then the reasoning, then the verdict last — instead of leading with a verdict it then talked itself into. The local door checks every refuter answer before handing it back and rejects an unusable one as an error, never as advice: a quote that is not on the line it cites, a cite to a file it was not given, or a verdict that disagrees with its own evidence. A scored test set of 36 claims about Daedalus's own code, true and false in pairs, grades the refuter by script. A bigger local model is tried only if the smaller one fails, and the first one that clears the bar is kept (none cleared the bar — the best was qwen3:32b with thinking on at 0.889, so it stays advice only) — if none does, Elenktes stays advice only. All five scheduled routines now run at extra-high effort. Four descriptions reworded: the memory tool's, the floor's local-door card, the council's and the local ask tool's. No migration (16 tables). Blueprint note_5012 · doc row §14.17. Shipped 2026-09-30 — deployed and checked live (version 0.21.0); the five routines now carry the extra-high effort setting on the server.
worker 0.20.0 → 0.20.1, local 0.8.0 → 0.8.1. A document's address in Daedalus's memory now covers how the note was split into sections, not only its text — so a note that is split a new way becomes a NEW document instead of colliding with its older copy (the collision that refused 28 of the 41 facts of the blueprint trap note in the v0.20.0 drill). A fact that is re-posted and already known now points at the newest copy of the note: an ask shows the newest section and the fact's freshness date renews. It stays one row — nothing is deleted, the older copies stay whole. The hands now say how many facts were re-pointed (a trailing repointed= count on the memory-post line). No migration (16 tables), no seed. Blueprint note_4963 · doc row §14.16.
Daedalus's memory now has a footing that stays put. A section's address no longer moves when a note is rewritten: it is the heading up to its first bracket, so a STATE regenerated every day keeps the same subject and the same anchor (hephaestus/note_2707/baselines). A keyword ask answers with the section that IS the word before a record that only mentions it, and an ask by an older, longer address still finds the record. Facts are cut at sentence ends (a version like 0.19.0 is never split), a note that opens with a blank line no longer refuses to post, and a long one-line trap note is findable now. The ask route no longer carries test-only code. Every rewritten STATE is re-posted to the memory and the newest copy answers first (nothing is deleted). The scheduled Daedalus session now checks the effort setting and asks once before it clocks in (template v3, a new effort knob on every routine), and its instruction file is printed from the row again, tidy included — a sync no longer reverts the hand patches. No migration (16 tables). Blueprint note_4963 · doc row §14.15.
Daedalus now has ONE memory store with two tiers, one door and one reading rule. RECORDS are small typed entries — kind, subject path, a claim of at most 280 characters, who said it and when, the evidence, what it supersedes, and a date after which it is stale — and DOCUMENTS are kept WHOLE, split into sections with anchors that never change when text moves, hashed, versioned, never shortened. A record is the fast index INTO a document: ask the store one question (GET /api/memory/ask, or the door tools memory_ask and memory_record for the owner and for a member) and it answers with the record, its source and the exact document section it points to, at most a thousand characters, deterministically, with no model call — a session reads a couple of cited lines instead of an eight-thousand-character note. Every write passes a validator that refuses a malformed record or document naming the fix (a claim over 280, a missing source, a cite to a section that does not exist, a prose body, a document whose sections do not reassemble to the original). The first conversion is this project's own brain: the STATE note and the blueprints trap note are split by a script into a kept document plus one record per fact line, and a machine check proves every line is found again before anything is posted (loss 0); the originals stay. The hands post and ask from the person's PC for free (node local/hands.js --memory-post | --memory-ask | --memory-status); /api/memory/status and the floor's memory card are the daily measure (records · stale · coverage · loss). Migration 0009 (13 → 16 tables); door tools 14 → 16 owner, 8 → 10 member. Ride-along: the run steps now live in ship.sh's run phase. Blueprint note_4880 · doc row §14.14.
Daedalus can now convene a COUNCIL over the network: POST /api/council (and the council door tool, for the owner and for
a member as plan-only) turns one task and up to five local specialists into a JOB — one ask step per specialist per round
(two rounds at most), run for free on the person's own PC by the hands' new third door (node local/hands.js --door local:tyler), plus one chair step for the connected session, the PRYTANIS until a chair daimon passes its Agon. Positions
land in a new table (migration 0008), the chair's collation in the job's design; nothing runs before the owner's go, and the
Worker itself never calls a model. The routine template is now v2: its ORCHESTRATE block is filled from what the two
orchestrator routines had converged on and from the odometer's first week of readings (one run = one phase), and those two
routines — hephaestus-session and appolis-session — are registered rows, every fact line of their files carried verbatim,
so DAEDALUS pushes them. Also: a synced routine now records the template it was rendered with (the STALE flag can finally
clear), the hands end cleanly on Windows after a push (one-shot requests, no pooled socket), and both context-check.mjs
copies shrink to the one delegating line. Blueprint note_4838 · doc row §14.13.
Daedalus now live-tracks what a session spends — measured, not typed in. The hands on the PC (node local/hands.js --odometer --session <id>) read the chat's own transcript (turns, context re-sent per turn, cache reads, output, subagent
tokens, free daimon calls, connector writes), write one reading file and push it up the same key road the
routines use; the Worker keeps one row per session (migration 0007) and rolls it up per routine, project and day in the
three currencies (charged dollars · plan usage · free). The hand-off tripwire now reads that SAME measurement, with each
routine's own thresholds, settable per model. An ODOMETER card on the floor, GET /api/odometer, an owner-only
odometer door tool (daedalus_odometer once Appolis registers it). Also: a routine's rendered sha no
longer moves with the clock, a missing template fails the floor loudly, codex's own token usage is read from its JSONL.
Deferred to 0.18: template v2 and the two orchestrator routines. Blueprint note_4764 · doc row §14.12.
Daedalus now holds the one canonical template for every scheduled routine (the "session brain" tasks that run on
Tyler's PC) plus each routine's knobs, and the hands on the PC pull the rendered file down and write it into place
(node local/hands.js --sync-routines). Two new tables (routines, routine_templates), three routines converted
verbatim (hermes-session, kosmos-daily-session, footage-clean-up — the last one now its own Kosmos project, Tyler's
call on form note_4733), a ROUTINES card on the floor, two new door tools (routines, routine_render). Also fixed on
the way: the Windows shim resolver for claude/codex (F1), codex's own command line (F4), and a stalled step can
be taken over by the next hand (F3). Found by reproduction before the ship: a push would have failed with 409 because
the template stamps its render time — the sync now hands the time out and the push route renders under it.
Blueprint note_4521 · doc row DAEDALUS-DESIGN.md §14.11.