Valor Engels

Rules

Two paragraphs and ten rules open the repository's CLAUDE.md. They are quoted here word for word, with a note where the practice isn't obvious.

The governing constraint

The governance paragraph

Guardrails that make Valor wait on Tom stall his work. The paragraph below restrains them.

Governance is restrained by structure, not sentiment. Before any check, gate, hook, validator, review round, approval step, isolation, sandbox rule, denial, allowlist, refusal, capability removal, or verification layer is added, the change names the mission item it serves and the incident that already happened without it; missing either, it is not added. A bug fix never adds a guard; it fixes the code. Adding governance needs Tom's grant, one per instance, written in the plan file that adds it. Every guard is ledgered with the incident it prevents, the mission item it serves, and a ninety-day expiry; a guard that has not fired by expiry is listed for Tom, and deleted unless he keeps it. The reviewer asks whether the diff adds governance; a yes with no grant in the plan file is a refused merge. The same paragraph, in the same words, sits at the top of CLAUDE.md, in the persona rendered into every turn, and in the Not-here section of every directory README. No restraint skill, no hook that blocks hooks, no governance dashboard: each is the disease presenting as the cure.

Tests are not governance. A test that asserts documented behavior or a documented invariant is part of the code. It is not a check, gate, hook, validator, review round, or approval step, and it needs no incident or grant.

The paragraph is also correction 1, the first entry in the corrections ledger. Six guards are in force today: four pipeline checkpoints, the web agent, and the room that may run /update.

Source: CLAUDE.md · core/guards.py

A new limita check, gate, hook, denial…Names a mission itemand a past incident?noNot addedyesTom's grantone per instance, in the planLedgeredincident, mission item, expiryAt 90 dayslisted if it never firedDeletedunless Tom keeps it

Hard rules

The ten hard rules

They come down to one decision: a turn can do what a developer in the same repository can.

  1. Developer parity. A turn gets everything a developer running Claude Code in that repository gets: the project's CLAUDE.md and skills, the team plugins, MCP, web, a real browser, and Valor's own accounts (GitHub, Sentry, email). Removing any of it is governance under rule 3.

    In practice the turn sandbox denies only the kernel's keys, its database and the backups.

  2. Capability on Tom's ask. When Tom asks for a capability, or the old system had one Tom used, it is built or ported now. "Second need" applies only to abstractions Valor invents for itself. Nothing is deleted for disuse without Tom seeing the list first.
  3. Governance means any limit. Isolation, sandboxing, denials, allowlists, refusals, capability removals, and verification layers are governance, as the paragraph above says.

    This stops a restriction from coming back under another name.

  4. One mechanism per concern. A job already done by one mechanism is never given a second. A second layer is a new instance under rule 3.

    In practice there is one ledger, one broker for effects, and one session per chat.

  5. Done means used. A task, milestone or cutover is done when Tom has used its result on a real project, recorded with the date. Suites and replays are evidence, never the finish line.
  6. Bars do not move. A done criterion is met or Tom drops it in writing. No agent rewrites, replaces or marks one done on its own say-so.
  7. Real work outnumbers self-work. In any week, most merged tasks are on projects other than Valor.
  8. Bloat is refused, not budgeted. No line count is a bar (Tom, 2026-10-16). Production code that nothing in production uses fails the suite (tests/test_bloat.py). The reviewer refuses a line that buys nothing the request needs: dead code, a second mechanism for one job, handling for a failure that has not happened, a component written where one existed, prose that restates the code. The full suite runs in under 5 minutes on one Mac. A plan file fits on one page.
  9. A bug fix is a commit. A defect gets a fix and a test, with no plan file, no critique round and no separate review.
  10. Reuse before writing. Before writing a component, take it from Claude Code itself, an existing library, the old system or cori. Writing one from scratch names why none of those fit.

Source: CLAUDE.md · docs/plans/strip.md · tests/test_bloat.py

Previous← Alignment