# Fleet build directives: the same block for your AGENTS.md Generated from `src/policy/client-policy.ts` (policy v9) by `scripts/policy/public-directives.ts`. The block below is byte-for-byte the block `scripts/policy/install-block.ts --file AGENTS.md` installs: the policy text is never forked between the two files, only the file that carries it differs. Paste everything inside the fence below, markers included, into your repository's `AGENTS.md` at its top level and commit it, or run `npx tsx scripts/policy/install-block.ts --repo --file AGENTS.md --apply`. Copying this file grants no permission over the Fleet and enrolls nothing. This is the text a client session is given, not a licence and not an adoption. ## The managed block (the workstation server) ``` ## Fleet policy (managed, v9) Managed by `scripts/policy/install-block.ts` in the Fleet's code directory: change the Fleet's policy, not this block. The `trueeval-fleet` MCP server runs outside models as **engineers** in isolated git worktrees (`fleet_build`, `fleet_mission`), delegates bounded text work to outside models (`fleet_delegate`, `fleet_review`, `fleet_council`, `fleet_research`), and gives free code navigation, affected-test runs, CI triage and worktree management (`nav_*`, `test_affected`, `ci_failures`, `worktree_*`). It spends the owner's money and runs model-written code. Start with `fleet_ping({ repo })` (free). Its `onboarding` names the loaded build, the policy version, this repository's adoption mode, the managed block, where reports go, and `nextActions`: do those first. ### Fleet first Default to the Fleet for: - implementation or tests you can brief in a paragraph with the files named - an independent review of a diff before it is merged - a current fact from the web - a supported browser check The coordinator (you) keeps: - decomposition into bounded tasks - domain ambiguity: what the brief should say - integration: reading the diff, running the tests, merging - a security boundary, the money path and any protected decision Work directly, without the Fleet, when: - the task is smaller than writing its brief - the capability it needs is unavailable or unsafe here (fleet_ping says which) - it needs the coordinator's judgment across many files Record a one-line reason for a meaningful exception (reply, commit or task board). Never redo finished work, or add busywork to a trivial edit, to satisfy this policy. The policy is a requirement in a repository enrolled `fleet-first` (its `.fleet/adoption.json`, and the managed block in its CLAUDE.md). Elsewhere it is advice; the mandatory controls below apply wherever the Fleet is used. ### Mandatory controls, wherever the Fleet is used - Paid calls bill the owner's OpenRouter key. You set each budget and the runtime holds it as a hard ceiling; never raise one you were given without the owner. - Always pass `repo`. Tools default it to the server's working directory, which may be another codebase. - Always pass `writeScope` to `fleet_build`, holding every file the acceptance needs, the seam that makes the program use the work included. Two jobs never share a file; the runtime refuses the second. - `accepted` is the engineer's own tests, not a review. Read `worktree_diff` (for a reviewed chain, the diff its `next` names) and run the tests yourself before `worktree_merge`. - Never run `npm install`, `npm ci` or `git stash` in a checkout with linked worktrees: their `node_modules` and stash list are shared. - Leave nothing behind: after `worktree_merge` applies, `worktree_remove` with `deleteBranch`; remove the worktree of a job you will not resume; stop any server, watcher, browser or test run you started, and check its port is free. Never remove another session's worktree. - A change that alters behaviour updates the register, task board and manuals that describe it in the same branch. Job history goes to the evidence system and defects to the register, never into CLAUDE.md. - Never put patient identifiers, credentials, tokens or source content a data class withholds into a brief, a report, a review payload or a screenshot. Every repository declares its data classes (`.fleet/data-classes.json`) before any of it reaches a model. - Free: `fleet_ping`, `fleet_status`, `fleet_stop`, `fleet_models`, `fleet_task`, `fleet_usage`, `fleet_report`, `fleet_verdict`, `fleet_intervention`, `fleet_lessons`, `fleet_scribe`, `fleet_certify`, `fleet_video_status`, `nav_*`, `test_affected`, `ci_failures`, `worktree_*`, `fleet_browse`; also free: `fleet_mission` without execute/shadow, `fleet_scrape` without extract, `fleet_look` with vision: false. Every other `fleet_*` call bills. ### Report Fleet defects at once Mandatory. Report at once, no batching: an unexpected error or refusal, a wrong-looking result or cost, a misleading warning, a tool not doing what the manual says, a stall, a misclassified scope, a false review finding, any workaround. - **Route:** `fleet_report({ repo, tool, observed, expected, impact, ... })` (free). Stored on this machine before it answers (`persisted: true`), redacted and deduplicated; unexpected tool errors are recorded automatically, so report what code cannot see. `mode: "list"` shows their state and released fixes not loaded here. - **Otherwise:** If it answers `ok: false` (not stored) or does not exist (an older build), put the report in your reply to the owner. Never claim delivery without `persisted: true`. - **Carry:** the tool; observed and expected; job, task or chain id; impact; workaround; evidence path or id, never content. `impact` is one of: wrong result, wasted spend, blocked work, unsafe instruction, data risk, annoyance. - Then carry on with the mission. Stop only if going on risks security, patient data, money, data integrity or something destructive. - At each checkpoint, list your report ids. Product bugs go in your register; a missing Fleet ability is `kind: "capability_request"`. - Whenever you check a Fleet review finding, record the verdict with `fleet_verdict` (free). - Record every hand repair of Fleet work with `fleet_intervention` (free). ### Owner approval first - raising a budget ceiling, or spending on training - uploading a corpus or any data off this machine - enabling experimental routing or changing a production environment - relaxing a data-class, sandbox, firewall or security control - enrolling a repository (`.fleet/adoption.json`) or changing its mode - editing global client configuration (the global CLAUDE.md, the MCP server configuration) ### Reconnecting Never reconnect the server (`/mcp`) while this session owns a running engineer or mission (`fleet_status`: `mine: true`; `fleet_ping`: `onboarding.reconnect.safe` false): a reconnect ends them. ```