{"content": "journal-checks, journal-messages changed since you loaded them \u2014 load one again when you next need it; only the every-start skills are held for", "meta": {"from": "journal"}}
{"content": "fact 38 \u2014 A helper reported as gone can still be reached with journal helper say \u2014 Seen repeatedly on 2026-10-11 with helper 239, Signor Bernini. The journal announced 'its agent is gone, so journal helper say cannot reach it' again and again while the helper was alive and working; journal helper say 239 answered 'sent to Signor Bernini' every time and he acted on each message. The notice tracks the agent id the journal itself dispatched, so a helper whose session was resumed by hand keeps being reported as gone. Check with pgrep and its worktree's git log before believing the notice, and never dispatch a second helper on its word alone.; fact 41 \u2014 The browser scenarios run the built viewer in src/web/dist, not the\u2026 \u2014 src/web/dist is tracked, and tests/test_the_viewer.py serves it, so a change to a .vue or .js file means nothing to a scenario until npm run build runs in src/web. Three gate runs on 2026-10-11 failed on scenarios looking for text I had already changed in the source: the dist was built at 03:26 and the edit made at 05:05. The rebuilt dist must be committed with the change.", "meta": {"from": "journal"}}
{"content": "the end tag does this in one step \u2014 [!end:N] makes the turn itself what landed; it runs only when it opens the last text of your turn", "meta": {"from": "journal"}}
{"content": "todo 75 next", "meta": {"from": "journal"}}
{"content": "fact 45 \u2014 The mascot preview is reachable from the phone at\u2026 \u2014 Opened on 2026-10-11 with 'tunler connect 8431 --domain=mascots', which answers at https://mascots.tunler.jessegall.nl/toon-preview/index.html and forwards to the preview server in Signor Bernini's worktree at 127.0.0.1:8431. The user asked for it because 127.0.0.1 means his phone when he taps it there. The tunnel runs as a background process of this session and dies with it; re-open it with the same command. To-do 4317 is the proper fix - serve the preview from the journal itself, which the phone already reaches through its pairing.", "meta": {"from": "journal"}}
{"content": "work 164 in hand \u2014 Every start checks the hooks are wired \u2014 if this is not what you are doing, end it or park it and start the work you are in", "meta": {"from": "journal"}}
{"content": "The journal is updating, so you are paused: start no new command and wait; you will be told when to continue.", "meta": {"from": "journal"}}
{"content": "The journal has updated and resumed you now: carry on with exactly what you were doing; your open work stays open and is not to be parked.", "meta": {"from": "journal"}}
{"content": "rule 76 \u2014 An environment has one live session; a second asks the user to take\u2026 \u2014 The user's ruling, 2026-10-11, refined in his own words: 'we shouldn't be able to have multiple sessions on an environment. The journal should tell the user, Hey, there's a session already here. What do you want to do? Do you want to take over? That means that the other session is unbound to that environment.' So a session starting on an environment that already has a live one does not take it silently and does not stop the other by itself: the journal asks the user what to do. On take over, the session that was there is unbound from the environment and the new one holds it; otherwise the new session does not get the environment. It came after his messages 25226, 25229 and 25230 reached a session he was not watching, while environment main held three live sessions at once.", "meta": {"from": "journal"}}
{"content": "fact 43 \u2014 A reader that copies a row it only reads is the commonest slow path\u2026 \u2014 Six instances found on 2026-10-11: the agent row the engine and seat read, the session lookup, the rows a to-do waits on, the environment summary's work rows, a subagent's task list, and a to-do's touched files. Each was load() where peek() was meant - load is peek plus a deep copy - and each was worth three to four times the speed where it was measured. Controller.peek exists for exactly this and says so in its docstring. When a read path here is slow, look for load() in a loop before looking anywhere else.", "meta": {"from": "journal"}}
{"content": "work 168 in hand \u2014 A ticket start that launches no agent says so \u2014 if this is not what you are doing, end it or park it and start the work you are in", "meta": {"from": "journal"}}
{"content": "rule 70 \u2014 Release fixes for transportklok-workspace reports at once, without\u2026 \u2014 The user, message 22416 (2026-10-09): 'All reports from the Transport Clock workspace should be handled immediately with the highest urgency and committed and pushed ASAP, without testing or running the full test suite.' A report from that project's session goes first, is fixed, committed, pushed to main and installed as soon as it works, running at most the tests beside the change.", "meta": {"from": "journal"}}
{"content": "your wait for the tickets test file run is over, because you are working again \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "meta": {"from": "journal"}}
{"content": "work 172 in hand \u2014 A secret's allowed programs are granted where the user\u2026 \u2014 if this is not what you are doing, end it or park it and start the work you are in", "meta": {"from": "journal"}}
{"content": "the await tag does this in one step \u2014 [!await] makes the rest of the turn what you wait for; [!await on=(\"<id>\", \"helper:<n>\")] waits on those; it runs only when it opens the last text of your turn", "meta": {"from": "journal"}}
{"content": "check 44 failed - a pull request is waiting - #23 by BjarneDms, Cover cold\u2026 \u2014 journal check show 44 says why; fix it, then journal check run 44", "meta": {"from": "journal"}}
{"content": "your wait for the viewer build and commit is over, because you are working again \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "the await tag does this in one step \u2014 [!await] makes the rest of the turn what you wait for; [!await on=(\"<id>\", \"helper:<n>\")] waits on those; it runs only when it opens the last text of your turn", "meta": {"from": "journal"}}
{"content": "your wait for the boot tests run is over, because you are working again \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "meta": {"from": "journal"}}
{"content": "your wait for the boot tests run is over, because you are working again \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "meta": {"from": "journal"}}
{"content": "check the boot tests run to finish, three failures showing so far now - you\u2026 \u2014 look at the thing itself: the background shell's output, the process, the run's status. If it is still going, say journal work await \"<what you wait for>\" again and wait. If it finished or failed, journal work log what came of it and take the next step. Never wait for something you can do without.", "meta": {"from": "journal"}}
{"content": "your wait for the boot tests run to finish, three failures showing so far is\u2026 \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "meta": {"from": "journal"}}
{"content": "law L3 \u2014 Read narrowly - grep for the line, sed a range, head the file; never\u2026 \u2014 Everything a tool returns stays in the context for good and is paid for on every turn after it. Search before you read, read the range you need, and cap output with grep, head or tail. Read a whole file only when you need all of it.", "meta": {"from": "journal"}}
{"content": "your wait for the two boot tests re-run is over, because you are working again \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "meta": {"from": "journal"}}
{"content": "rule 46 \u2014 Only commit and push once the whole journal is proven to boot \u2014 Messages 2178 and 2179. A release that has not been started for real can crash every project that installs it, as 2.78.3 did for Codex and 2.84.0 did to project records. Before every commit and push: the full suite passes, including tests/test_it_boots.py, which installs a packed copy into a fresh project, launches Claude and Codex from it, writes a project record, upgrades again and checks the record survives. When a change touches launching, installing or upgrading, also start a real journal in a scratch project and close it properly afterwards, leaving no process behind.", "meta": {"from": "journal"}}
{"content": "fact 39 \u2014 Measure a process's CPU by its cputime over a window, never by a\u2026 \u2014 2026-10-11: I read ps -o pcpu= four times two seconds apart on transportklok's engines, got 0.0 every time, and told the user the idle-CPU gap was closed. Ada Funnelace contradicted it with ps cputime deltas over 30 and 40 second windows: 7.7 to 8.0 percent on the same two engines. I checked her way over 14 seconds and got 8.1, 7.4 and 0.5 percent. An instant reading can land between bursts and show nothing; a CPU-time delta over a window cannot. Use ps -p <pid> -o cputime= twice, seconds apart, and divide.", "meta": {"from": "journal"}}
{"content": "rule 41 \u2014 Keep moving, run the whole suite before every commit, never wait \u2014 The full suite runs in about seven seconds: .venv/bin/python -m pytest -q --timeout=300 -n auto. Run it before every commit instead of picking tests by name. Group rows that sit in the same code into one sitting: write them all, test once, commit once. And never wait, not for a subagent, a build, or an answer you can carry on without. Dispatch it and keep working. If you truly are waiting on something, say so in the work log.", "meta": {"from": "journal"}}
{"content": "your wait for the boot tests re-run on helper-hooks-line is over, because you\u2026 \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "meta": {"from": "journal"}}
{"content": "chat etiquette - a line from the journal is an instruction, not a message\u2026 \u2014 a turn that only handles a journal line needs no words: act on it, or say once in the chat what you wait on, then carry on; what the user needs to know still goes to the chat", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "your chat talked about the journal's workings - \"Still waiting\" \u2014 the user sees replies, reactions, pills and reads themselves; say what the work is instead", "meta": {"from": "journal"}}
{"content": "fact 9 \u2014 Every public method on a controller becomes a journal command \u2014 The CLI is generated from the controllers: each public method of Controller, or of a typed controller, turns into journal <noun> <method>. A helper added to the base class therefore becomes a command on every type \u2014 which is how journal <type> handled and journal <type> refuse came to exist, from the CRUD funnel and the refusal funnel. An internal helper on a controller is named with a leading underscore, as _shaped and _status already are, or it ships as a command nobody meant.; fact 24 \u2014 An answer followed by tool calls can be missing from Claude's\u2026 \u2014 Seen 2026-09-24 for messages 9391-9404: text blocks opening with [!reply:n] that were followed by tool calls never appeared in the session's jsonl (only thinking and tool_use rows did), so the journal never saw them and the replies were lost. When a turn goes on after answering, send the answer with journal message reply <n> \"<text>\" instead of the tag.", "meta": {"from": "journal"}}
{"content": "your answer to a journal line was kept out of the chat \u2014 a journal line is an instruction, not a message: act on it and write nothing, unless the user needs to know something such as a failure, finished work or a decision that waits on them", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "auto mode is on and you stopped - the user last wrote more than 15 minutes ago \u2014 carry on with what you were doing, or take the next ready row. Only the user stopping you keeps you stopped. If you wait on the user, put it as a question on its row with journal todo ask and take the next ready row.", "meta": {"from": "journal"}}
{"content": "rule 57 \u2014 Never merge the overnight refactor into main before its pull request\u2026 \u2014 Messages 15005, 15006, 15109, 15110 (2026-10-04): all refactor work goes on branch overnight-refactor and reaches the user as one pull request, which they read in the morning; nothing of it is merged into main until they say so. Hotfixes the user explicitly asks for go to main at once and are merged into the branch.; rule 61 \u2014 Features wait as pull requests until approved; only hotfixes merge\u2026 \u2014 Message 17118 (2026-10-06), after the overnight refactor merged as 2.252.0: start new work in a new branch, do not merge, write the pull request. Every pull request or new feature is parked until the user approves it. Hotfixes can be merged into main immediately (by a dispatched agent in a worktree of main, rule 60).; rule 64 \u2014 A finished feature is merged into main without waiting for approval \u2014 The user, message 17815 (2026-10-07): 'make sure that no pull requests are lingering on the repository. You may merge them into main... You are allowed to merge everything into main once the feature is completed.' This replaces rule 61's wait for approval: a feature still goes on its own branch, and once it is complete, tested and its whole suite passes, it is merged into main and released, and no pull request is left open.", "meta": {"from": "journal"}}
{"content": "rule 35 \u2014 Write clean code - one funnel per kind of operation, never the same\u2026 \u2014 Every kind of operation has one funnel: one method that creates, one that saves, one that refuses, one that formats. A second method that does the same thing under another name splits the behaviour, and the two drift apart. Before writing a method, search for the one that already does it and extend that. scripts/checks/funnels.py finds bodies written twice.; rule 38 \u2014 Never change the git branch until the user says so, by name \u2014 The work happens on the branch the user named. That was main until message 5929 and question 80 (2026-09-23), which moved the sins work to the branch sins. Do not create, switch to or merge any other branch unless the user names it in their own words.", "meta": {"from": "journal"}}