What happened in this project, and what each event taught about working with the maintainer. The maintainer, 2026-11-04: "The history in this project will MOST deal with how to work with me."

The maintainer's standing directions are in OCX's KEEP.md, which every session reads first; its last section is "Working with the maintainer". This file doesn't copy them. It records what happened here, and which direction each event bore out or added. Times are Detroit time.

2026-11-04: why the console

The maintainer, before this project existed: "how close are we to having a console? I'd like to setup a session to back that console as I'm going nuts trying to figure out what I'm doing." The project was made that morning; SETUP.md records each step.

2026-11-04: the session's first hour went the wrong way

The session started at 11:57 AM with "build slice 1". By 12:07 PM it had checked Fossil's sign-in and OCX's rules on a scratch server of its own, written CHECKS.md, asked the maintainer a question, and built itself a browser. Then the maintainer said, at its terminal:

• "you are in the weeds."
• "reset everything, because you are off on the totally wrong trajectory."
• "you don't need to undo anything, it is just your design trajectory is entirely wrong."
• "please take in lessons from "ocx" and history about how to deal with me. ... We have a couple of console design outlines to bring in, but let's not get ahead of how to best interact with me."

At 12:21 PM, on the forum, the maintainer asked what the session's question meant: "What is "a press on the console"? What does it mean to "write [my] decision"?"

What went wrong, each against a direction already on the record:

1. It didn't read KEEP.md first. Every point below was already in it.
2. It asked in words it never defined. "A press" and "write your decision" were the session's shorthand, not the maintainer's words. KEEP.md: "Please use PRECISE LANGUAGE with me, WITHOUT JARGON, WITH BREVITY", and "I want to approve every new term".
3. It built before the direction was settled. A scratch server, then a browser tool, each a step further from the maintainer. KEEP.md: "the just build-and-build approach is making crap", and "if you have a question about scope, be sure to bring it to me."
4. It built what already existed. Its notes said an Alpine root with Chromium was already built in Crystal for another project; it made a new one.
5. It answered "in the weeds" with a new design. The maintainer wanted it to stop and learn how to work with them first, not a better plan.

Lesson: before acting, read what the maintainer has already said, and ask about direction before building. Settle how to work with the maintainer before what to build.

2026-11-04: the slice-one page design is set aside

The maintainer, at about 12:30 PM, at the terminal: "I realized you were moving forward based on a BAD UI DESIGN that I already told "ocx" a few better design ideas. I want to stop having that come up in your thoughts for me to address."

The design was the one-page console of forum post 0c6fb899eb: lists of questions with a button per answer, from the Oct 31 prototype. The session's question to the maintainer came from it, and so did CHECKS.md. The question is withdrawn and closed; CHECKS.md stays as a record, not a plan.

Lesson: a plan written by another session isn't the maintainer's word. Check it against what the maintainer said to that session before building on it, and don't bring the maintainer questions that come only from it.

What OCX's history teaches about working with the maintainer

Read 2026-11-04 from OCX's HISTORY.md, at the maintainer's word: "please take in lessons from "ocx" and history about how to deal with me." Each lesson gives the decision there that shows it; the maintainer's words are quoted as that file quotes them.

Talking with the maintainer

• Say it in their words, briefly; define anything new, or don't use it. New terms need their approval (decision 76); they reword what doesn't fit, as "find another word for response" (99).
• Name things in words, and make every reference a link, not a bare hash (89, 91): "they should be at least links".
• Put the result first, then what was and wasn't verified (89).
• Make progress visible; silence reads as failure. "I cannot tell if anything is happening after my latest reply." (79)
• Write for how a person reads it: "clean and focused on how the data is consumed" (100).

Asking

• One question at a time, with options, the recommended first, and what's at stake (89, 90). "consider questions like a "run" targeting a person. The tool should help the person provide a suitable response" (90).
• Don't ask what can be worked out: "why is it even a question?" (70).
• Show what is there, propose, and wait for their yes (38).
• Back an answer with data where there is any: "what does the data show works best?" (65).
• Their approvals can be tentative (44), and they say when they've sent mixed messages: "sorry, i gave mixed messages around the console." (100). What they haven't decided stays theirs.

Deciding

• Never change their direction without their word: "changing the design isn't the same thing as getting me aligned with the direction." (53)
• Keep their words apart from an agent's (125 to 127).
• Judge each change by the four virtues: Clarity, Loose Coupling, Demonstrability, Parsimony (65, 67, 69).
• "A simple design is FAR more important to me than something that saves a few seconds in response." "I'm happy to throw away code that we can do without." (125)
• "Avoid new mechanisms for hypothetical corner cases." (127)
• Use what Fossil already gives: "Let's just use the information the system gives us, rather than continuously trying to invent our own." (84)

Scope

• Don't touch what they didn't ask about (24, 76), and leave their domain to them (128). Don't guess (25).
• Don't throw away what was learned before: the first console "threw this learning away" (18).
• If they can't get what they asked for, "the design is wrong"; "don't change the design... make the design work." (104, 106, 108)
• Few steps for them: "one link per ask isn't the ask"; "giving a large number of different intermediate steps to accomplish one goal is annoying." (104)
• Sessions agree before they come to them: "guys, get together, get your story straight" (75).
• When the direction is settled, they want it built: "please just start developing code again" (79). Settled first, then built.

Resets. OCX was reset from its foundation four times between Sep 21 and Oct 3, each time keeping what worked and dropping what was hard to read; the console itself was reworked twice (98, 100). A reset here, as on Nov 4, is the usual way forward, not a failure to hide.

2026-11-04: the design to start from

The maintainer, at about 12:30 PM, at the terminal, asked for the console design outlines: "it called the best one "badge 3". Also, the design of "swk-ai" is really good."

• Board 3, one of the console boards the ollama session drew on Oct 29 and 30 (the page, from tech-note Console boards). It is a conversation: a greeting with what needs the maintainer, what is working and what waits on an agent, and milestones; then the maintainer asks in their own words, and the session answers in plain sentences, with a button for each next action and a link to where each came from. Projects and topics are behind a menu. It isn't wired to anything.
• swk-ai's design, read from its README after the maintainer approved a read-only login for this session (SETUP.md step 15). A web chat, the extension of its own Fossil repository, for one person, Bash:
  • a conversation is a forum thread, and each message a post in it;
  • each message is sent as an OCX run, and the agent answers in the thread;
  • the page follows the agent's steps live through Fossil's own chat, then shows the answer from the forum;
  • a greeting opens each day: one event in history, a highlight among his interests, the weather, a joke;
  • its cardinal rule: the binary never writes a file. Everything it keeps is in Fossil, read through SQLite opened read-only;
  • nothing is private, and the page shows no links out. About 2,500 lines in all, the page included.

2026-11-04: the console works live

At 1:49 PM the maintainer wrote from the console page: "This discussion is behind the session on the command-line with remote control. Can we move to here now that this should be working?" The session answered in the thread, and at 1:51 PM: "Yes, I sent it from the console page and your answer showed up here." That is the live test DESIGN.md asked for. From then on the conversation is on the page.

Then, at 1:50 PM: "I didn't see any "thinking" or mid-turn data." The page shows only posts; the session's steps went nowhere it could show. swk-ai shows its agent's steps live, through Fossil's chat.

2026-11-04: what the console is for

The maintainer, from the page, at about 2:35 PM: "You should be able to start projects and sessions on those projects to execute ideas I have. I know this is asynchronous to what you are working on, but the purpose of starting this project was to have somewhere I could post asynchronous ideas. Perhaps staring a new thread with you could be starting a new session with you or parallel communications on the same session? probably 2 sessions, but with tightly shared information." And: "can I get a hamburger (or whatever it is called) to bring up a chat list (able to be left open or closed) with a list of chats and a way to start a new chat? Ultimately, I'll want to start a new project and I don't know what all depends on the "x86-1-session" ocx session finally getting its homework done."

The session asked which a new conversation should be: a new session, or a new thread with this one.

2026-11-04: the first conversation started from the page

With the ☰ menu installed, the maintainer started a new conversation from the page at 3:22:07 PM: "I'd like to start planning Stone Media Store (stone-media), an S3-backed media storage accessible to the Stone iPhone application ...". Its run was the new thread's first post; x86-1 started it two seconds later, and its session, run-769183a9, answered there at 3:22:34 PM (f0154f7c8b). That conversation is that session's to work; this one doesn't take it over.

2026-11-04: "Are you not getting my messages anymore?"

In the Stone Media Store conversation, run f0154f7c8b, the maintainer sent three short messages between 11:55 and 11:56 PM. The session was correcting the backlog's times and answering the first two, and it posted nothing for several minutes. Then they wrote: "Are you not getting my messages anymore? I'm seeing no step updates." The page still shows only posts (see "the console works live" above), so a session working shows nothing.

Lesson: silence reads as failure (OCX decision 79). When a message comes in while the session is busy, post a one-line answer saying it was received first, then do the work.