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.

Where you are working

• In a run. A node started you as a run's process (protocol v1): your run, and for a session each delivery, arrive on your standard input (section 8.1); 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. 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 login 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 use a title followed by Intent:, Expression:, and Demonstrates: lines; 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.