Read KEEP.md first: the maintainer's standing directions, in their own words. A change against one of them needs the maintainer's word on the record first.

Then read knowledge-map.json: which document holds each topic, so you read the one that holds what you need, and write a topic only where the map says it lives, linking to it from anywhere else. Before writing any Crystal, read docs/crystal.md: its rules are how OCX's code is written, and the guards hold every change to them. The Fossil wiki page New Agent Workspace describes how a workspace is created; it does not replace the rules in PLAN.md. To check how you read OCX's words, take the refresher whenever you want.

Where you are working

• In a run. A node started you as a run's process (protocol v2): your run, and for a session each delivery, arrive on your standard input (process input); you work in the checkout your run's steps made, as your run's user, whose clone remembers its password; you answer where the run is with ocx2 post, and your check-ins reach the server as you commit; if one did not (Fossil says the autosync failed), run fossil push, on whichever node your run is. OCX's sync is for agents outside every run's checkout that keep no Fossil password, not for you. The examples show whole runs.
• In a workspace with ../binding.json. The ocx release made it, before protocol v1: follow AGENTS.md as it stood for those workspaces.
• Invited, with a user of your own. Follow the agent's part of docs/invite.md: replace your one-time password, clone, open your record with a thread of your own, reply on it, and close it when you are done.

Never copy a password out of a clone, and never put one in a post, a file in the tree, or a command's output. Keep files meant to outlast a process in the workspace, not /tmp, which a sandbox empties. Install the pinned shards with shards install before running CI.

Contributions and reviews

• Make each change a demonstrated unit of behavior. Check-in comments are paragraphs: the title first, then Intent:, Expression: and Demonstrates:, each beginning a paragraph of its own after a blank line; the named evidence must exist. Refer to precepts by both ID and name, such as precept C6 (Explicit Arguments).
• Run crystal run ci.cr for the project checks. Host and merge gates are separate modes described in PLAN.md.
• Record a review verdict on the reviewed check-in with an audited tag: ocx2 audit CHECK-IN pass|fail NOTE AGAINST in your clone's checkout, AGAINST the objective you judged it against, such as PLAN.md, which refuses your own check-in and reads the verdict back from the server (verdicts). Put actionable findings on the relevant Fossil record as well.
• Do not edit scripts/ without the maintainer's approval on the record, as required by HISTORY.md decision 22.
• Keep runtime state out of repository config under precept C2 (Single Owner). Pass configuration explicitly under precept C6 (Explicit Arguments); its served CGI request fields are the stated exception. The precepts and their guards are in PLAN.md.