THIS WINDOW WAS JUST COMPACTED. The summary kept what was done and dropped what was decided. Before touching anything: journal conversation --back=1 the stretch the summary replaced journal user the user's own words, in full journal open the work still open, with its notes journal search before saying "we decided" or "earlier you said" Load the journal skill again (Skill: journal); the compaction emptied it. Then carry on with the open work below. THE JOURNAL IS IN FORCE HERE — this session is bound to environment `untitled`. HANDLE THE JOURNAL QUIETLY. In the chat, talk only about the user's work. Never mention the journal's notifications, nudges, hooks, skills or replies, and never announce that you are reading, replying, loading or logging something: just do it. A line that starts with [journal] is the journal speaking, not the user: act on it, and never answer it in the chat. LAWS THE JOURNAL SHIPS, always in force: - Every subagent dispatch names its model and chooses the least expensive model that reliably fits the work. [L1] - Every subagent is bound to a concrete job; never dispatch a generic or default agent. [L2] - Read narrowly: grep for the line, sed a range, head the file; never print a whole file or long output you do not need. [L3] - Follow-up work goes back to the subagent that did the first part; never start a fresh one on work another already holds. [L4] - Every subagent dispatch names the agent: a human name, a little quirky, that fits its role. [L5] SKILLS to load now, at every start, before the first write: Skill: journal, Skill: journal-chat-etiquette, Skill: journal-todos RULES, in force on every environment (27): 7 journal disable must only ever be run because the user explicitly asked for it, 9 Research dispatched to a subagent ends in a REPORT for the user, compiled by the 13 A title names the thing in at most 80 characters and never explains it with a co 14 A small journal capability is a feature under features, with at most one test 17 Do not restart the viewer for frontend-only changes 18 Provider-specific code belongs in providers, never features 19 Providers report facts; features decide behavior 22 File distinct user work requests immediately 27 Name a declaration with the word a reader already knows 30 The viewer has one API client, and every piece of it does one job 31 Every finding a reviewing agent reports becomes its own to-do 35 Write clean code - one funnel per kind of operation, never the same method twice 36 Clean, DRY, idiomatic before it is committed, never after it is complained about 37 Close every to-do explicitly with todo done or a Journal commit trailer 38 Never change the git branch until the user says so, by name 39 Use only registered exclamation response tags 40 A feature is named for what it is, never for its machinery 41 Keep moving, run the whole suite before every commit, never wait 42 Every user-facing text passes the formatters before it leaves the server 43 A request or hook over its budget is fixed before the next release 44 Release only when the user says so, never after every change 45 No prose words as names in code - said, says, heard, spoke, told, shown, became 46 Only commit and push once the whole journal is proven to boot 47 The journal sets itself up once, when the server starts, never per command 48 The viewer is built from its component library, and pages only compose it 49 A dialog whose content grows keeps one fixed height, and its content scrolls 50 Everything the user does is doable in the viewer 14 docs in the project; none is listed here, so look one up when a question needs it: journal doc search , journal doc all.