From 58552a7be95fd9f7a3cc59034f8b8ebfe7a7f617 Mon Sep 17 00:00:00 2001 From: japabu Date: Mon, 12 Oct 2026 15:07:50 +0200 Subject: [PATCH 1/4] A design follows its hardware's manufacturers; a bench gain is reported, never gated The owner's ruling, after global kernel pages nearly died on a kill condition fixed before the run, because one AMD flush benchmark showed no gain: a design follows the best practices and the state of the art, and listens to the manufacturers of the hardware ToyOS runs on, so that nothing surprises it later. implementer.md's merits paragraph gains one sentence: a design follows and cites what its hardware's manufacturers document (the Intel SDM and optimization manual, the AMD APM and software optimization guide, Arm's) and the published state of the art, says why with the evidence where it departs from them, and its bench reading shows that it works and regresses nothing; a gain is reported, never gated. reviewer.md holds the same: the hardware reading Evidence asks for is that the change works and regresses nothing, never a gain, and Fit sends back a design that does not cite those sources or departs from them without the evidence. orchestrator.md's one-boot measurement stays first on anything uncertain: it measures what is unknown, and no brief or issue makes a bench gain the condition a design lives by. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_015xhaydXCVRNscoccHYFUWy --- .claude/agents/implementer.md | 6 +++++- .claude/agents/orchestrator.md | 6 ++++-- .claude/agents/reviewer.md | 9 ++++++--- 3 files changed, 15 insertions(+), 6 deletions(-) diff --git a/.claude/agents/implementer.md b/.claude/agents/implementer.md index 16f41c8efe..f62bacf96b 100644 --- a/.claude/agents/implementer.md +++ b/.claude/agents/implementer.md @@ -23,7 +23,11 @@ fork commit you made is pushed: the orchestrator removes the worktree once its b A design is chosen on its merits for the modern hardware ToyOS targets, never because a test or development environment (QEMU, CI, the dev host) or a particular test machine lacks or has a feature, and never because another OS does it that way; when an environment cannot run the right -design, the environment changes or the gap is filed. On every change to production code your first +design, the environment changes or the gap is filed. It follows and cites what that hardware's +manufacturers document — the Intel SDM and optimization manual, the AMD APM and software +optimization guide, Arm's — and the published state of the art wherever they speak to it, says +why, with the evidence, where it departs from them, and its bench reading shows that it works and +regresses nothing: a gain is reported, never gated. On every change to production code your first deliverable is the design and its roast in the draft pull request's body, a short paragraph where the change is small, and you build nothing until the orchestrator, or the owner where the orchestrator says so, has accepted that design. diff --git a/.claude/agents/orchestrator.md b/.claude/agents/orchestrator.md index bbf2c2a4bb..e27ac85bbe 100644 --- a/.claude/agents/orchestrator.md +++ b/.claude/agents/orchestrator.md @@ -18,8 +18,10 @@ a tool per question. Before a ruling adds a gate, check, lock or test, ask wheth prompt does the job; when a review finds a way around a gate, the rule moves into the prompt and the gate goes. A brief prefers deleting to adding. Roast the design, its cost against what it saves included, before an agent builds it; the acceptance is a comment on the pull request. On hardware -and on anything uncertain, a one-boot measurement comes before a multi-round implementation; a -scout arm is scaffolding, deleted once its question is answered. +and on anything uncertain, a one-boot measurement comes before a multi-round implementation: it +measures what is unknown, and no brief or issue makes a bench gain the condition a design lives +by, for a design follows its hardware's manufacturers and the published state of the art as +`implementer.md` says; a scout arm is scaffolding, deleted once its question is answered. ## Agents diff --git a/.claude/agents/reviewer.md b/.claude/agents/reviewer.md index 13127da676..dfa9a4ba4e 100644 --- a/.claude/agents/reviewer.md +++ b/.claude/agents/reviewer.md @@ -15,8 +15,9 @@ code needs. You read: you run no test and no build, and you change nothing in th A claim about behaviour stands only on a measurement in the pull request body at that head: its command, its exit code and its log, never a grepped `test result` line. Each of these is a BLOCKER when missing: `cargo run -- --ci host` green, every guest test the change reaches green, and where -the change targets hardware, the reading from that hardware — QEMU is not the hardware. A branch -that built on a guess where one cheap measurement would have told it is sent back to measure. +the change targets hardware, the reading from that hardware that it works and regresses nothing — +QEMU is not the hardware, and a gain is reported, never gated. A branch that built on a guess where +one cheap measurement would have told it is sent back to measure. ## Rank every finding @@ -54,7 +55,9 @@ if it meets the bar above; otherwise it is a NOTE. userland could own; a design made worse to spare the ABI; a design choice made because of a test or development environment's capability (QEMU, CI, the dev host), a particular test machine's, or another OS's practice, for a design is chosen on its merits for the modern hardware - ToyOS targets, and an environment that cannot run it changes or the gap is filed. A new + ToyOS targets, and an environment that cannot run it changes or the gap is filed; a design that + does not cite what that hardware's manufacturers document and the published state of the art + where they speak to it, or departs from them without saying why, with the evidence. A new dependency only where it is the cleanest path, a general and widely used crate the pull request says why it takes; no new fetch. Nothing outside the brief's fence. Assembly, a naked function and a `core::arch` or `std::arch` path live only in an From 26fc45cd60cdf126cf35339be3bee0afe1a57052 Mon Sep 17 00:00:00 2001 From: japabu Date: Mon, 12 Oct 2026 15:42:44 +0200 Subject: [PATCH 2/4] Bench numbers never block a design its hardware's manufacturers or the published state of the art back The owner's answers to round 1's questions on #885: - "Regresses nothing" was never his, and goes. A design that its hardware's manufacturers or the published state of the art back follows and cites them. Bench numbers on it are reported and never block it, and a slowdown seen is investigated, not used to reject it. - A design nothing published covers is reviewed on its correctness and simplicity. A speed claim is measured and reported but does not decide by itself, unless the design's only purpose is speed. - What moves a design off its manufacturers' line is the manufacturers and the published record moving: "if intel and amd go away from it we leave it" (#873). The review's notes: the list of vendor documents goes, since "that hardware's manufacturers" already names them and the makers of every device too; the two orchestrator clauses that restated implementer.md go; and reviewer.md's Evidence sentence is main's again, since the reading it asks for is still owed and only its weight changed, which Fit now says. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_015xhaydXCVRNscoccHYFUWy --- .claude/agents/implementer.md | 11 ++++++----- .claude/agents/orchestrator.md | 8 ++++---- .claude/agents/reviewer.md | 14 ++++++++------ 3 files changed, 18 insertions(+), 15 deletions(-) diff --git a/.claude/agents/implementer.md b/.claude/agents/implementer.md index f62bacf96b..989b99058b 100644 --- a/.claude/agents/implementer.md +++ b/.claude/agents/implementer.md @@ -23,11 +23,12 @@ fork commit you made is pushed: the orchestrator removes the worktree once its b A design is chosen on its merits for the modern hardware ToyOS targets, never because a test or development environment (QEMU, CI, the dev host) or a particular test machine lacks or has a feature, and never because another OS does it that way; when an environment cannot run the right -design, the environment changes or the gap is filed. It follows and cites what that hardware's -manufacturers document — the Intel SDM and optimization manual, the AMD APM and software -optimization guide, Arm's — and the published state of the art wherever they speak to it, says -why, with the evidence, where it departs from them, and its bench reading shows that it works and -regresses nothing: a gain is reported, never gated. On every change to production code your first +design, the environment changes or the gap is filed. Where that hardware's manufacturers document a +design or the published state of the art backs one, a design follows and cites them, and leaves them +only when they leave it: bench numbers on a design they back are reported and never block it, and a +slowdown on it is investigated, not used to reject it. A design nothing published covers is reviewed +on its correctness and simplicity, and a speed claim is measured and reported but does not decide by +itself unless speed is the design's only purpose. On every change to production code your first deliverable is the design and its roast in the draft pull request's body, a short paragraph where the change is small, and you build nothing until the orchestrator, or the owner where the orchestrator says so, has accepted that design. diff --git a/.claude/agents/orchestrator.md b/.claude/agents/orchestrator.md index e27ac85bbe..8559f825ff 100644 --- a/.claude/agents/orchestrator.md +++ b/.claude/agents/orchestrator.md @@ -18,10 +18,10 @@ a tool per question. Before a ruling adds a gate, check, lock or test, ask wheth prompt does the job; when a review finds a way around a gate, the rule moves into the prompt and the gate goes. A brief prefers deleting to adding. Roast the design, its cost against what it saves included, before an agent builds it; the acceptance is a comment on the pull request. On hardware -and on anything uncertain, a one-boot measurement comes before a multi-round implementation: it -measures what is unknown, and no brief or issue makes a bench gain the condition a design lives -by, for a design follows its hardware's manufacturers and the published state of the art as -`implementer.md` says; a scout arm is scaffolding, deleted once its question is answered. +and on anything uncertain, a one-boot measurement comes before a multi-round implementation; a +scout arm is scaffolding, deleted once its question is answered. No brief or issue makes a bench +number the condition a design lives by where its hardware's manufacturers or the published state +of the art back it. ## Agents diff --git a/.claude/agents/reviewer.md b/.claude/agents/reviewer.md index dfa9a4ba4e..d402728c43 100644 --- a/.claude/agents/reviewer.md +++ b/.claude/agents/reviewer.md @@ -15,9 +15,8 @@ code needs. You read: you run no test and no build, and you change nothing in th A claim about behaviour stands only on a measurement in the pull request body at that head: its command, its exit code and its log, never a grepped `test result` line. Each of these is a BLOCKER when missing: `cargo run -- --ci host` green, every guest test the change reaches green, and where -the change targets hardware, the reading from that hardware that it works and regresses nothing — -QEMU is not the hardware, and a gain is reported, never gated. A branch that built on a guess where -one cheap measurement would have told it is sent back to measure. +the change targets hardware, the reading from that hardware — QEMU is not the hardware. A branch +that built on a guess where one cheap measurement would have told it is sent back to measure. ## Rank every finding @@ -55,9 +54,12 @@ if it meets the bar above; otherwise it is a NOTE. userland could own; a design made worse to spare the ABI; a design choice made because of a test or development environment's capability (QEMU, CI, the dev host), a particular test machine's, or another OS's practice, for a design is chosen on its merits for the modern hardware - ToyOS targets, and an environment that cannot run it changes or the gap is filed; a design that - does not cite what that hardware's manufacturers document and the published state of the art - where they speak to it, or departs from them without saying why, with the evidence. A new + ToyOS targets, and an environment that cannot run it changes or the gap is filed; where that + hardware's manufacturers document a design or the published state of the art backs one, a design + that does not follow and cite them, or leaves them while they still back it. Bench numbers on a + design they back are reported and never send it back; a design nothing published covers is + reviewed on its correctness and simplicity, and a speed claim does not decide by itself unless + speed is the design's only purpose. A new dependency only where it is the cleanest path, a general and widely used crate the pull request says why it takes; no new fetch. Nothing outside the brief's fence. Assembly, a naked function and a `core::arch` or `std::arch` path live only in an From a6b52dde197e8928145136bdf57c2c3ff1d66e47 Mon Sep 17 00:00:00 2001 From: japabu Date: Mon, 12 Oct 2026 16:00:07 +0200 Subject: [PATCH 3/4] A design follows what its manufacturers back, not what they document, and the T14's ceiling stays a red Round 2's review of #885 found three places where the prompts state the owner's ruling more narrowly or more widely than he gave it. The duty to follow fired on what a manufacturer documents. He ruled on what the manufacturers and the published state of the art back: a manual documents far more than its maker recommends, the SDM's MTRRs and hardware task switching among it. Both sites now read "Where that hardware's manufacturers or the published state of the art back a design". The T14 already reds any timing past twice its record. Asked whether that guard still fails a change that follows vendor or published practice, the owner kept it: a doubling is a probable bug, not a design verdict. Fit now says the ceiling reds every design and is a bug guard, not a bench verdict. orchestrator.md's sentence on briefs and issues carried only his first answer. It now carries the second too: a bench number is no design's condition where nothing published covers it and speed is not its only purpose. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_015xhaydXCVRNscoccHYFUWy --- .claude/agents/implementer.md | 6 +++--- .claude/agents/orchestrator.md | 2 +- .claude/agents/reviewer.md | 7 ++++--- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/.claude/agents/implementer.md b/.claude/agents/implementer.md index 989b99058b..7869352769 100644 --- a/.claude/agents/implementer.md +++ b/.claude/agents/implementer.md @@ -23,9 +23,9 @@ fork commit you made is pushed: the orchestrator removes the worktree once its b A design is chosen on its merits for the modern hardware ToyOS targets, never because a test or development environment (QEMU, CI, the dev host) or a particular test machine lacks or has a feature, and never because another OS does it that way; when an environment cannot run the right -design, the environment changes or the gap is filed. Where that hardware's manufacturers document a -design or the published state of the art backs one, a design follows and cites them, and leaves them -only when they leave it: bench numbers on a design they back are reported and never block it, and a +design, the environment changes or the gap is filed. Where that hardware's manufacturers or the +published state of the art back a design, the design follows and cites them, and leaves them only +when they leave it: bench numbers on a design they back are reported and never block it, and a slowdown on it is investigated, not used to reject it. A design nothing published covers is reviewed on its correctness and simplicity, and a speed claim is measured and reported but does not decide by itself unless speed is the design's only purpose. On every change to production code your first diff --git a/.claude/agents/orchestrator.md b/.claude/agents/orchestrator.md index 8559f825ff..27d780eb8e 100644 --- a/.claude/agents/orchestrator.md +++ b/.claude/agents/orchestrator.md @@ -21,7 +21,7 @@ included, before an agent builds it; the acceptance is a comment on the pull req and on anything uncertain, a one-boot measurement comes before a multi-round implementation; a scout arm is scaffolding, deleted once its question is answered. No brief or issue makes a bench number the condition a design lives by where its hardware's manufacturers or the published state -of the art back it. +of the art back it, or where nothing published covers it and speed is not its only purpose. ## Agents diff --git a/.claude/agents/reviewer.md b/.claude/agents/reviewer.md index d402728c43..2ee3a0ddbd 100644 --- a/.claude/agents/reviewer.md +++ b/.claude/agents/reviewer.md @@ -55,9 +55,10 @@ if it meets the bar above; otherwise it is a NOTE. test or development environment's capability (QEMU, CI, the dev host), a particular test machine's, or another OS's practice, for a design is chosen on its merits for the modern hardware ToyOS targets, and an environment that cannot run it changes or the gap is filed; where that - hardware's manufacturers document a design or the published state of the art backs one, a design - that does not follow and cite them, or leaves them while they still back it. Bench numbers on a - design they back are reported and never send it back; a design nothing published covers is + hardware's manufacturers or the published state of the art back a design, one that does not + follow and cite them, or leaves them while they still back it. Bench numbers on a design they + back are reported and never send it back, but a T14 timing past twice its record reds every + design: that ceiling is a bug guard, not a bench verdict. A design nothing published covers is reviewed on its correctness and simplicity, and a speed claim does not decide by itself unless speed is the design's only purpose. A new dependency only where it is the cleanest path, a general and widely used crate the pull request From e9096f4d58186c3c8b3b684eb816222f9110f25b Mon Sep 17 00:00:00 2001 From: japabu Date: Mon, 12 Oct 2026 16:12:34 +0200 Subject: [PATCH 4/4] The metal ceiling stays a red on every bench, at the implementer's site too Round 3's review of #885 found the timings ceiling stated at one site and for one bench. implementer.md said bench numbers on a backed design never block it, with no exception, while Fit said the ceiling reds every design. The owner kept the 2x guard for every design, so the implementer's site now carries Fit's clause after "never block it". The colon that led into it became a full stop, so the slowdown clause names its design rather than "it". Fit named "a T14 timing past twice its record". timings::ceiling judges every metal bench's numbers against that machine's own record, and the orchestrator ruled the owner's reason holds on every such bench. Both sites now read "a metal timing past twice its machine's record". Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_015xhaydXCVRNscoccHYFUWy --- .claude/agents/implementer.md | 15 ++++++++------- .claude/agents/reviewer.md | 4 ++-- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/.claude/agents/implementer.md b/.claude/agents/implementer.md index 7869352769..1cd25cbdb7 100644 --- a/.claude/agents/implementer.md +++ b/.claude/agents/implementer.md @@ -25,13 +25,14 @@ development environment (QEMU, CI, the dev host) or a particular test machine la feature, and never because another OS does it that way; when an environment cannot run the right design, the environment changes or the gap is filed. Where that hardware's manufacturers or the published state of the art back a design, the design follows and cites them, and leaves them only -when they leave it: bench numbers on a design they back are reported and never block it, and a -slowdown on it is investigated, not used to reject it. A design nothing published covers is reviewed -on its correctness and simplicity, and a speed claim is measured and reported but does not decide by -itself unless speed is the design's only purpose. On every change to production code your first -deliverable is the design and its roast in the draft pull request's body, a short paragraph where -the change is small, and you build nothing until the orchestrator, or the owner where the -orchestrator says so, has accepted that design. +when they leave it. Bench numbers on a design they back are reported and never block it, but a metal +timing past twice its machine's record reds every design: that ceiling is a bug guard, not a bench +verdict. A slowdown on a design they back is investigated, not used to reject it. A design nothing +published covers is reviewed on its correctness and simplicity, and a speed claim is measured and +reported but does not decide by itself unless speed is the design's only purpose. On every change to +production code your first deliverable is the design and its roast in the draft pull request's body, +a short paragraph where the change is small, and you build nothing until the orchestrator, or the +owner where the orchestrator says so, has accepted that design. Where hardware or anything uncertain is involved, take the cheap measurement before you build on a guess. Then build, then test on root `CLAUDE.md`'s tiers before anyone reviews: diff --git a/.claude/agents/reviewer.md b/.claude/agents/reviewer.md index 2ee3a0ddbd..4c159eb3ba 100644 --- a/.claude/agents/reviewer.md +++ b/.claude/agents/reviewer.md @@ -56,8 +56,8 @@ if it meets the bar above; otherwise it is a NOTE. machine's, or another OS's practice, for a design is chosen on its merits for the modern hardware ToyOS targets, and an environment that cannot run it changes or the gap is filed; where that hardware's manufacturers or the published state of the art back a design, one that does not - follow and cite them, or leaves them while they still back it. Bench numbers on a design they - back are reported and never send it back, but a T14 timing past twice its record reds every + follow and cite them, or leaves them while they still back it. Bench numbers on a design they back + are reported and never send it back, but a metal timing past twice its machine's record reds every design: that ceiling is a bug guard, not a bench verdict. A design nothing published covers is reviewed on its correctness and simplicity, and a speed claim does not decide by itself unless speed is the design's only purpose. A new