Commit graph Crafter.Review/AGENTS.md
Author SHA1 Message Date
339f4b9b40
feat(modes): the kernel modes - a patch series and a mailing-list reply
Beside the push gates, crafter-review runs the pre-send review of a kernel
contributor's workbench: --mode series over a format-patch export with its
cover letter, --mode reply over a mail draft. The inventory partitions a
cover letter, a plain mail and the camera review's shape; ten kernel lenses
join the table with their gates (structure, code, artifact truth) and the
persona gate - one maintainer-persona instance per --reviewers entry, its
whole pass gating its blocks and pruning the units that are not theirs. A
series' code units are keyed on the code like the push gates'; every text
unit on its text, the references it cites and the anchor when it is dated.
The references an artifact cites are prefetched through utilities/lore.py
into the gate-state, with a digest in the run layer, and a persona's
calibration map is its lore listing. The kernel schema carries the persona
vocabulary, the kernel note kinds, the predicted review and the not-mine
list; the matrix the persona holes, the thin and the modelled units; gates
clean without a persona pass is GATES CLEAN. A reply's gate-state sits
beside the draft and is read once; a kernel mode needs --subsystem,
defaults the effort to max and the trees to work/linux,work/milos-linux,
and excuses no unit from the holes.

The kernel lenses and the common text ship verbatim; the table lists them
after the push gates' lenses and the config template holds them off, so a
repository that never turns them on changes nothing. Prompts, keys and plans
were checked byte for byte against the pipeline these modes replace, on its
own artifacts: two replies and a series, every system prompt, user prompt,
job and reuse key identical.
2026-10-31 22:56:12 +01:00
4fc15fe1c2
feat(run): the repository under review is the freeze record's, not the working directory's
A directory can review repositories other than itself: a workbench whose
config, env file and records serve several, freezing each with --repo and
--out. The run took the working directory for the repository under review:
the prompt named it, the calibration was kept under it, and --trees fell
back to it. The run now reads the repository from the artifact's
freeze.json - the prompt names it and the calibration is kept under it -
and --trees defaults to what the record says: the worktree, else the
repository when it is not the working directory, else `.`, the same rule
that builds the printed run line. The working directory keeps its roles:
the config, the env file, the slots, the lens processes' cwd and every
logged path. A damaged record stops the run at preflight.
2026-10-31 21:31:48 +01:00
ea4d362a10
feat(seats): a pass's share of the windows by the run's effort, the weekly cutoff at 99 %
The 5-hour share of a running pass was a flat 0.25 points; it follows the
run's effort now, as the weekly share already did: 0.5 at max and any other
effort, 0.125 at xhigh - the pooled means of 5438 Opus 5.5 passes on 141
seat-runs (2026-10-12..15), rounded up. The weekly cutoff moves from 95 %
to 99 %: the weekly window is the budget the lenses run out of, and with
the running passes projected against the cutoff the last percent is spent
a pass at a time, not in a burst. REVIEW_GATES_LENS_COST_PCT and
REVIEW_GATES_LENS_COST_7D_PCT still override every effort.
2026-10-31 21:13:55 +01:00
51bdd6298a
feat(http): the HTTP layer on ClientHTTP1::Fetch and the typed socket error
Crafter.Network master now carries, in their final shape, the pieces the
HTTP layer and the SQL broker were written against on a side branch:
ClientHTTP1::Fetch follows redirects by RFC 9110 §15.4 on a URL type of
its own, and SocketErrorException is a std::system_error with the phase
that failed. The broker and the HTTP layer read the errno or the resolver
code from code() and the phase from the field, instead of matching
message prefixes, and the pin moves to that commit, so the build no
longer needs --local against a checkout of the side branch.

The messages the run log, the preflight detail and the SQL helper show
are unchanged, but for the wording of a refused URL.
2026-10-31 20:46:13 +01:00
febbfc3fcc
feat(lenses): the commit-truth lens, repo-facts, as Gate 4
Every claim in every commit message, and in the documentation the range
adds or changes, proven or gone. The lens's block kinds are text, doc and
slot: a message unit is keyed on its text, the base and the code up to its
commit (MessageDeps); a documentation unit on its file, its normalised
text, the base and the code of the whole range (DocKeyParts); a diffstat on
its text alone; whole:order and whole:absent are asked in slot passes of
its own, never stored. A documentation file's diff header and a part the
commit writes nothing in are a mechanical n/a. Budgets 60/40 for a text or
doc block, 50/35 for a slot; one read. Gate 4, after the proofs, so the
messages and documents are read once the code they describe has settled;
the owner's gate is 5.

The goldens that follow from the lens table are derived by
tests/Goldens/derive.py, which asserts that the recorded table still
reproduces the recorded entries before it writes.

Proven, with the opt-in commit after this one: the suite (26 passed); a dry
run of a scratch range (2 commits, a README with sections) by the previous
binary and this one with the three static lenses on and the rest off, 25
prompts and 4 system files byte for byte; with repo-facts on as well,
those files unchanged and 10 passes and 1 system file added.
The lens's firing proof in this pipeline is owed (the owner's go).
2026-10-31 20:08:26 +01:00
61ee4602f4
feat(pool): no machine-wide width - 128 passes per available account
Jorijn: "there is no need to do a global cap anymore, the cap should be
128 per available account". `--concurrency` no longer defaults to 128:
the limits are each OAuth account's 128 (and the local login's), every
driver's counted, an API seat's own REVIEW_GATES_API_CONCURRENCY, and
free memory. `--concurrency N` still caps the machine when given; a value
below 1 is a usage error.

The dump's args.concurrency is null then. The board's driver settings
read `128 per account`, which every driver's `seats` shows as that
driver's width, and the `seats` header says a width is that driver's cap.
The Scheduler test runs 300 passes on two accounts: 256 at once, 128 each.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-31 17:33:11 +01:00
c28307601b
feat(seats): accounts without a 5-hour limit
Anthropic is removing the 5-hour limit in stages (from 2026-10-31), and
an account without it reports the weekly window alone. Until now the pool
took such an account for an unprobed seat: always eligible, ranked after
every other, never held to the weekly cutoff, with no cap on its passes.

- The burst window is the 5-hour one, else the weekly one
  (Seats::BurstWindow). An account whose burst window is the weekly one is
  ranked by it and admitted under the 95 % cutoff with the passes in
  flight projected on it, at the measured share per pass (0.04 at xhigh,
  0.125 otherwise; REVIEW_GATES_LENS_COST_7D_PCT), and waits for the weekly
  reset when over it.
- Every OAuth account and the local login takes at most 128 passes at once,
  every driver's counted (REVIEW_GATES_OAUTH_CONCURRENCY): every run
  measured with 149 or more in flight on one account drew usage-limit
  rejections, none of the 119 with 139 or fewer.
- A 'concurrents' rejection pauses the seat for 20 s or its retry-after,
  not until a window's reset (a seat sat two hours at 10 % on one).
- Board entries, the folded foreign record and the board's view carry
  cost7d, so the drivers see each other's weekly load.
- `seats` and the log table say `no limit` in such an account's 5-hour
  column; the board's others-line names its weekly projection.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-31 17:07:17 +01:00
a2974a8139
docs: AGENTS.md, the developer guide
The rule it lives by (prompts, reuse keys, shared files and exit codes
pinned byte for byte by the goldens), the layout and the partitions, the
rules for a change, the tests and their conventions, the behaviour the
checks hold and the quirks kept, the sandbox and process lifetime, every
environment variable the binary reads and how it is parsed, CI, the pins
and the publish lock, and the licence.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-31 16:46:57 +01:00