{"content": "rule 48 \u2014 The viewer is built from its component library, and pages only\u2026 \u2014 Message 4258. Every visual piece the viewer shows more than once, or that a user would recognise as the same kind of thing (a dialog, a side panel or inspector, a dropdown, a list row, a switch, a button), is one component in web/src/kit, extracted aggressively, and every page composes those components instead of building its own copy. Before writing markup or styles in a page, look for the kit component that already does it and extend it with a prop; a second hand-built version is a bug. The side panel that animated in but not out, while a separate skill panel did both, is the example.", "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": "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": "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": "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.; law L7 \u2014 Write the least code that solves the whole problem - find what\u2026 \u2014 Before writing, search the code for what already does the job or most of it, and extend that instead of adding a second way. Every read or write of one kind of thing (a file, a record, a setting, a provider) goes through the one funnel that owns it, which is where caching and checks live. A fix lands where the fault is born, not where it shows. When you finish, say in a line what you skipped or did not check.; rule 54 \u2014 Settings and feature switches are read at boot and on change, never\u2026 \u2014 The user, message 13349: the application boots, determines every feature and setting once, and re-evaluates only when something changes, such as a setting or a plugin. Never lazy-load settings.", "meta": {"from": "journal"}}
{"content": "the log tag does this in one step \u2014 [!log:N] makes the turn itself the log entry; it runs only when it opens the last text of your turn", "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": "fact 25 \u2014 A designer's install packs the whole tree, half-done server edits\u2026 \u2014 2026-09-25: Eames and Saul run python3 src/journal.py --root .journal upgrade after their viewer builds; it packs every file in src, so a server handler I was halfway through writing went live and raised on every PostToolUse hook. While designers work in parallel, keep server edits whole between tool calls (write and test in the scratchpad first), and reinstall after reverting anything.; rule 40 \u2014 A feature is named for what it is, never for its machinery \u2014 Messages 599, 600 and 703. A feature is a capability the user would name and would think of switching off. File tracking, a write gate, a phrase bank, a tree diff are services used inside a feature, not features of their own: they live in the feature they serve. Before adding a directory under features/, say what the user would call it; if the answer names a mechanism, it belongs inside something else. Report 16 holds the grouping this implies.", "meta": {"from": "journal"}}
{"content": "rule 47 \u2014 The journal sets itself up once, when the server starts, never per\u2026 \u2014 Messages 2220 and 2224. Discovering features and their handlers, seating the feature rows and the rename sweep happen once, at server boot, and again only when a feature is switched on or off, a plugin changes or an environment is added: features.load keeps a set-up generation per journal (SEATED) and redoes the work only when that generation moves. A command, a request or a hook uses what is already there; nothing in their path may rediscover handlers or rescan folders. A cost that repeats per call is a bug to fix, not a budget to raise.", "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 34 \u2014 A hooks list in a checkout's .claude/settings.json stops every\u2026 \u2014 Seen 2026-10-08: since commit 707a82915 the committed .claude/settings.json held {\"hooks\": []}; current Claude Code answers a hooks value that is not an object with a SettingsWarning dialog, which a headless helper cannot answer, so helpers 183 and 184 exited before doing anything (their launch logs in .journal/runtime/launches/ show it). This repository's journal hooks live in settings.local.json; the committed settings.json stays {}.; 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.; 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 55 \u2014 Always dispatch Codex helpers on gpt-6-sol \u2014 The user's word, message 13431: switch the codex agents to GPT-6-Sol and make it their default. ~/.codex/config.toml names it as the default model too.; rule 56 \u2014 Helpers are for work that writes; subagents read, research and design \u2014 The user, message 13464: there must be a clear distinction. A subagent can be dispatched for anything read-only: research, review, design. A helper is for actual work that writes, best in its own worktree when the work is separate. Dieter designing in Claude Design should have been a subagent, not a helper.; rule 71 \u2014 Always reuse a helper's or subagent's whole session, never only its\u2026 \u2014 The user, messages 23609 and 23614 (2026-10-10): workers are reused by their whole session, so they keep their context. A helper whose agent ended resumes its own session (to-do 3872); a fresh start under the same name wastes the user's tokens. It belongs in the journal application itself, not only this project.", "meta": {"from": "journal"}}
{"content": "rule 60 \u2014 A hotfix is done by a dispatched agent in a worktree of main \u2014 Message 16836 (2026-10-06): the orchestrator cut a worktree under .claude/worktrees for a Codex hotfix, its session moved to a new environment and the user's messages stopped reaching it. The user: when working on a branch and a hotfix comes in, create a worktree of main and dispatch an agent to do that work. The orchestrator stays on its branch and in its environment, and never cds into another checkout.", "meta": {"from": "journal"}}
{"content": "rule 66 \u2014 The journal never slows the agent down \u2014 The user, message 18990, after hooks timed out and waited on locks under load: the journal must never, ever decrease the performance of an agent. A hook answers at once with what decides the tool call; everything else runs after, in the background, and reaches the agent as a message. No hook waits on a lock it does not need.", "meta": {"from": "journal"}}
{"content": "fact 13 \u2014 This live session runs the installed copy in .journal/journal.pyz \u2014 The running journal (server, hooks, CLI) runs from .journal/journal.pyz with its viewer and skills in .journal/src, never from the repo. A change in the repo reaches it only through python3 src/journal.py --root .journal upgrade, which packs the zip again. A commit alone changes nothing that is running.; 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"}}
{"content": "main moved since your worktree was cut \u2014 It gained 1 commit (996156ef0 A write enters the funnel before it takes a lock of its own). Rebase onto main in /Users/jessegall/projects/agent-journal/.claude/worktrees/main-miss-lovelace before you report.", "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.; rule 51 \u2014 Every finished feature is committed, pushed and released with a new\u2026 \u2014 Message 9207 (2026-09-24): when a new feature is ready, commit, push and publish a new tag. This is the user's standing word for releasing, so rule 44's only-when-the-user-says is met by it for finished features; fixes in between wait for the next feature or a patch the user asks for.; rule 72 \u2014 Ship fixes as patches at once; batch features into a minor version \u2014 The user, messages 23885 and 23886 (2026-10-10): a bug fix, and any hotfix for an agent's bug, is released at once as a patch version. A new feature waits on its branch and goes out together with others in the next minor version, when enough has gathered to make one; installing every feature right away costs too much time. The orchestrator decides what is a patch and what is a minor.", "meta": {"from": "journal"}}
{"content": "main moved since your worktree was cut \u2014 It gained 5 commits (4f4e7eac4 An archive asked for while its environment waits to be packed is packed first, so unarchive never answers that there is none; 632afcd6e Removing an environment moves its record into the attic at once and packs it after the answer, so a ticket's merge no longer waits on the archive; cacaed4c5 Seating a new environment waits for its answer and boots the switches once, and its dashboard is built where it is seated; 91c9c6028 The warm-up at a start reads the text of every type a search covers, so the first search no longer reads work, comments, reports and the rest; 996156ef0 A write enters the funnel before it takes a lock of its own). Rebase onto main in /Users/jessegall/projects/agent-journal/.claude/worktrees/main-miss-lovelace before you report.", "meta": {"from": "journal"}}
{"content": "rule 49 \u2014 A dialog whose content grows keeps one fixed height, and its content\u2026 \u2014 Message 5361, after asking more than once: a dialog that shows output as it arrives (install, update, logs) opens at its final height and never jumps; only its content scrolls.", "meta": {"from": "journal"}}
{"content": "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.; rule 62 \u2014 The voice profile shapes only the agent's chat speech, never code or\u2026 \u2014 The user, message 17620 (2026-10-07): the profile (butler, homie, coach, colleague) must not leak into the code the agent writes or into user-facing text of any application it works on: names, labels, comments, commit messages, docs and briefs written into a project use plain words (helper, subagent). Speaking in the chat in the profile's voice is fine.", "meta": {"from": "journal"}}
{"content": "rule 36 \u2014 Clean, DRY, idiomatic before it is committed, never after it is\u2026 \u2014 The user should never be the one who finds duplication, dead code, a clumsy name or a pattern the codebase does not use. Read the diff before every commit as a reviewer would, and fix what is not clean then, not in a follow-up after a complaint.; rule 37 \u2014 Close every to-do explicitly with todo done or a Journal commit\u2026 \u2014 Ending work does not close its row. A to-do is closed by journal todo done <n> --how, or by a commit whose message carries Journal: todos done <n> at column 0, several numbers separated by commas. A row left open after its work landed misleads the next session and auto mode.; 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": "commit 79ee866bf closed to-do 1 and ended work 1 \u2014 The rows and the work are done; take the next one.", "meta": {"from": "journal"}}
{"content": "Code Commandments \u2014 before you commit \u2014 you've changed 10 judged files since th\u2026 \u2014 Code Commandments \u2014 before you commit: you've changed 10 judged files since the last commit. Consider running `commandments judge --changes` to confirm they conform, and fix any sin at its SOURCE (don't launder a finding with a default/cast/null-check). This is a one-time nudge for this batch \u2014 if you've already judged, or these changes aren't worth a scan, just say so and carry on.; Code Commandments \u2014 the files changed since the last check (`allow_list.py`, `r\u2026 \u2014 Code Commandments \u2014 the files changed since the last check (`allow_list.py`, `routes.py`, `countdown.py`, `http.py`) breaks a rule. Fix it now, at its SOURCE, while the code is still in front of you: \u00b7 \u2022 python-dict-return-bag at /Users/jessegall/projects/agent-journal/.claude/worktrees/main-miss-lovelace/src/features/auto_update/countdown.py:34 \u00b7 LOAD the skill `commandments-python-value-objects` before fixing \u2014 load it even if you believe you already have. \u00b7 Run `commandments info <sin>` if a rule is not one you recognise. This check reads a file at a time, so it is not the whole picture \u2014 `judge` still is.", "meta": {"from": "journal"}}
{"content": "fact 20 \u2014 A slim supervisor holds the agent and a worker reloads on every build \u2014 Since 2.118.0 (2026-09-23). src/supervisor.py is standard library only and never reloads: journal claude hands its process over to it (os.execv), and it owns the pty and the agent process, relays the terminal, writes the printed and screen captures, listens on the typist socket, restarts the agent in the same session from a relaunch command written to its runtime folder while a restart is pending, and stops it with escalation while draining the pty (an agent cannot finish exiting on macOS while its output is unread). It starts the worker (src/worker.py, which runs runner/worker.py; engine/worker.py stays as an alias for supervisors started before 2.201) and starts it again whenever it exits: RELOAD on a new build, RELAUNCH to restart the agent, STOP to end, HEAL or a quick crash to roll back a build through journal heal. The worker holds everything else: seating the session, the start-up confirm typed through the typist, services, viewer, update check, check-in, and the one-time relaunch of sessions launched before agents/terminal.py LAUNCH. agents/terminal.py holds only journal-side helpers. The server (serve.py) still runs the engines and re-execs itself on a .py change. When the agent exits, the supervisor runs journal ended, which puts set-aside hooks back and stops the server when no session is left.; 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": "main moved since your worktree was cut \u2014 It gained 7 commits (9d852bf40 The update status a screen asks for is a typed value; f44b7f855 The phone covers its screen while the journal updates, asking the same update status the viewer does; 4f4e7eac4 An archive asked for while its environment waits to be packed is packed first, so unarchive never answers that there is none; 632afcd6e Removing an environment moves its record into the attic at once and packs it after the answer, so a ticket's merge no longer waits on the archive; cacaed4c5 Seating a new environment waits for its answer and boots the switches once, and its dashboard is built where it is seated; and 2 more). Rebase onto main in /Users/jessegall/projects/agent-journal/.claude/worktrees/main-miss-lovelace before you report.", "meta": {"from": "journal"}}
{"content": "rule 43 \u2014 A request or hook over its budget is fixed before the next release \u2014 Comment 1151 on this rule. When the faults feature reports a request, a hook or a command slower than its budget, file it as a to-do at once. It does not jump ahead of the work in hand, but no version is published while one is still open: profile it, fix it, and verify the new time before the release goes out. The budget is 50ms, because everything runs locally against files.", "meta": {"from": "journal"}}
{"content": "Code Commandments \u2014 before you commit \u2014 you've changed 3 judged files since the\u2026 \u2014 Code Commandments \u2014 before you commit: you've changed 3 judged files since the last commit. Consider running `commandments judge --changes` to confirm they conform, and fix any sin at its SOURCE (don't launder a finding with a default/cast/null-check). This is a one-time nudge for this batch \u2014 if you've already judged, or these changes aren't worth a scan, just say so and carry on.", "meta": {"from": "journal"}}
{"content": "rule 42 \u2014 Every user-facing text passes the formatters before it leaves the\u2026 \u2014 Not only a brief. A title, an abstract, an outcome and every section body are read by a person, so each goes through the same formatters on its way to the viewer \u2014 chat turns, activity items, to-do rows, inspector pages, docs alike. One field formatted out of five is not a rule, it is an accident, and it is how a raw tag ended up in the activity list after the tags feature had been stripping them for weeks. When a new field carries words a person reads, it joins the list in the same place.", "meta": {"from": "journal"}}
{"content": "main moved since your worktree was cut \u2014 It gained 11 commits (7f47e916b The viewer build matches the source after the rebase; 71a694156 One rule files a chat mark under its kind: the server stamps it and the phone and the desktop both read it; 8e6fcb06c The two fast polls say in their allow-list entries that they are deliberate; 1f407ca91 A check whose script is missing says it cannot run; seven check scripts are wired; eleven readers peek instead of copying; 9d852bf40 The update status a screen asks for is a typed value; and 6 more). Rebase onto main in /Users/jessegall/projects/agent-journal/.claude/worktrees/main-miss-lovelace before you report.", "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 4 in hand \u2014 Rebase the phone update overlay onto main \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 65 \u2014 Run only new and affected tests while working; the whole suite only\u2026 \u2014 The user, messages 17914 to 17917 (2026-10-07): 'stop running the whole test suite and wasting my time... please only run the new or affected tests, and then, whenever you are merging to main or publishing to main, you can run the full test suite.' Replaces rule 41's whole suite before every commit: on a feature branch, run the tests beside what changed (journal check touched, or the feature's test.py and the browser scenarios it touches); the whole suite runs once, before a merge into main and its release.; rule 74 \u2014 Run the whole suite only for a minor; a patch runs its affected tests \u2014 Message 24581 (2026-10-10): the user forbade running the full suite except for a minor version; a patch release runs only the tests beside what changed. Replaces rule 65's whole suite before every merge to main for patches.", "meta": {"from": "journal"}}
{"content": "main moved since your worktree was cut \u2014 It gained 13 commits (d73993470 Version 2.270.2; 566206393 The phone notices an update within a second, and its scenario stages a real update through the server's own upgrade mark; 7f47e916b The viewer build matches the source after the rebase; 71a694156 One rule files a chat mark under its kind: the server stamps it and the phone and the desktop both read it; 8e6fcb06c The two fast polls say in their allow-list entries that they are deliberate; and 8 more). Rebase onto main in /Users/jessegall/projects/agent-journal/.claude/worktrees/main-miss-lovelace before you report.", "meta": {"from": "journal"}}
{"content": "rule 77 \u2014 A 3D modelling agent is dispatched on the strongest model, never a\u2026 \u2014 The user, message 25841 (2026-10-11), on seeing the mascots regress: 'What kind of agents are you sending, Opus or Sonnet? I think creating 3D models requires a bit more insight, so I'd say that's Opus, not Sonnet.' Modelling a figure to match drawn art turns on judgement of shape and proportion, which is what law L1 reserves the strongest model for. Agents that only look and list - critics, catalogues, sweeps - stay on the general model.", "meta": {"from": "journal"}}
{"content": "main moved since your worktree was cut \u2014 It gained 14 commits (2a1cc8e4b Every server start and every agent launch checks the hooks of each agent present against what this version writes, and writes again those that are missing, stale or run a path that is gone, saying so in one line; d73993470 Version 2.270.2; 566206393 The phone notices an update within a second, and its scenario stages a real update through the server's own upgrade mark; 7f47e916b The viewer build matches the source after the rebase; 71a694156 One rule files a chat mark under its kind: the server stamps it and the phone and the desktop both read it; and 9 more). Rebase onto main in /Users/jessegall/projects/agent-journal/.claude/worktrees/main-miss-lovelace before you report.", "meta": {"from": "journal"}}
{"content": "rule 45 \u2014 No prose words as names in code - said, says, heard, spoke, told\u2026 \u2014 Messages 1360 and 1698. The user has said more than once that code must not read like prose: a variable, attribute, property or function is named for what it holds or does (text, command, labels, lines), never with a verb from a story. 'says' on the Design type (1360) and 'said = call.said.lower()' in features/recital.py (1698) are the examples. Rule 27 states the naming rule; this one carries the words, so writing one of them whispers it. Before writing a name, ask whether a reader who has never seen the code would know what it holds.", "meta": {"from": "journal"}}
{"content": "work 6 is still open, with nothing logged \u2014 journal work log 6 \"<what was decided or done, and why>\" \u2014 then journal work end 6 --how \"<what landed>\", or journal work park 6 \"<why it waits>\"", "meta": {"from": "journal"}}
{"content": "Code Commandments \u2014 before you wrap up \u2014 you've changed 1 judged file since the\u2026 \u2014 Code Commandments \u2014 before you wrap up: you've changed 1 judged file since the last commit. Consider running `commandments judge --changes` to confirm they conform, and fix any sin at its SOURCE (don't launder a finding with a default/cast/null-check). This is a one-time nudge for this batch \u2014 if you've already judged, or these changes aren't worth a scan, just say so and carry on.", "meta": {"from": "journal"}}
{"content": "work 6 is still open \u2014 end it or park it before you stop: journal work end 6 --how \"<what landed>\", or journal work park 6 \"<why it waits>\"", "meta": {"from": "journal"}}
{"content": "your wait for the repeated runs of the 19 listed tests; a monitor reports\u2026 \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "meta": {"from": "journal"}}
{"content": "fact 28 \u2014 The designer agent type exists, so design work goes to a subagent \u2014 Since 2026-10-01 .claude/agents/designer.md (Dieter, Opus, Claude Design tools, read-only on the repository) is an agent type; rule 56 says design is a subagent's job, never a helper's.; rule 58 \u2014 A design runs three critique rounds, then is built on a branch \u2014 Messages 17276 and 17281 (2026-10-06): the norm is a three-round cycle. Round by round, the designer designs (or revises), separate critic agents review the design through their lenses (the critic agent type, .claude/agents/critic.md: read-only, with a browser; one per lens, such as first-time, native, words and parity), and the designer adjusts it to their findings; three rounds in all. The three rounds stand in for the user's approval of the design: the user does not approve it. After the third round the design is built on a branch of its own, which ends in a pull request that waits for the user's approval (rule 61). Replaces message 15725's prototype approval.; rule 63 \u2014 A small design is drawn once and the user approves it, with no\u2026 \u2014 The user, messages 17628 and 17629 (2026-10-07), about the tooltip and waiting-status designs: 'This design round doesn't really need multiple rounds... I just want the designer agent to design it, and I will approve it.' Rule 58's three critique rounds are for large designs such as the phone app; a small one (a tooltip, a status word, one control) is drawn once by the designer, the link goes to the user, and it is built once the user approves it.; rule 68 \u2014 The orchestrator approves the designer's designs itself \u2014 Message 19718 (and 18972): whenever a designer subagent is sent out, here or on a remote, the orchestrator makes the final call on whether the design is right and approves it; it never waits for the user to. This replaces the user-approval step in rule 63, which only the user can strike.", "meta": {"from": "journal"}}
{"content": "work 6 is still open \u2014 end it or park it before you stop: journal work end 6 --how \"<what landed>\", or journal work park 6 \"<why it waits>\"", "meta": {"from": "journal"}}
{"content": "your wait for the repeated runs of the 19 listed tests; a monitor reports\u2026 \u2014 say journal work await \"<what you wait for>\" again if you are still only waiting", "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 chat talked about the journal's workings - \"I'm still waiting\" \u2014 the user sees replies, reactions, pills and reads themselves; say what the work is instead", "meta": {"from": "journal"}}