0243 runs ten readings inside a checkout of another crate, and six of the paths it names resolve in this tree to something else

[iderex]

Split: none
Scope: docs/decisions

0243 measures a crate that is not this tree, and ten of its readings are commands
run inside a checkout of that crate. Six of the ten name a path this repository
also carries, so a reader standing where every other command in the record is run
gets an answer out of the wrong file. The record says where its cargo readings
were taken and says nothing about these, and the repair is neither of the two
edits a landed record is allowed.

What is wrong

Read at origin/main c6ccf5e3ece1726744043b36dc86d9d83bdef194. The ten sites:

git grep -nE "^ {4,}(grep|sed|awk|ls|comm|cat|wc|head|tail) .*(^| )(README\.md|Cargo\.toml|src/|src/lib\.rs)" origin/main -- docs/ README.md SECURITY.md NOTICE.md CONTRIBUTING.md CODE_OF_CONDUCT.md
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:35:    grep -rn 'log::' src/verification/ | grep -c '!'
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:37:    grep -n -A2 'dependencies.log' Cargo.toml
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:67:    grep -n '' src/lib.rs | sed -n '456p;1318,1327p'
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:231:    sed -n '20,27p' README.md
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:265:    grep -rn 'Only map' src/
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:271:    grep -n '=> InvalidCertificate' src/verification/windows.rs
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:277:    grep -n 'errors::errSec' src/verification/apple.rs
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:283:    grep -n 'VerifierStatus::' src/verification/android.rs | sed -n '1,5p'
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:321:    grep -n '' Cargo.toml | sed -n '70,76p;88,91p'
origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md:486:    sed -n '56,57p' README.md | awk -F'|' '{print $2 "|" $4}'

Every one of them is in 0243 and nothing else in this file set carries the
shape. The record's only statement about where a reading was taken covers a
different set of commands by its own words:

git show origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md | sed -n '130,133p'
## How the readings below were taken

Every `cargo` reading in this record was taken in a scratch crate outside this
tree, on a Windows machine, with the toolchain `rust-toolchain.toml` pins. The

None of the ten is a cargo reading.

Four of the ten fail loudly and six do not

I ran all ten in a checkout of origin/main at the sha above, one at a time in
the shell, rather than through a wrapper. Four name a path this tree does not
carry and say so on the error stream:

grep -n '=> InvalidCertificate' src/verification/windows.rs
grep: src/verification/windows.rs: No such file or directory

The remaining six name a path this tree does carry, so they answer out of this
repository's own files with no error at all. Two of them return something
plausible. 0243:321 pastes eleven lines of the verifier crate's manifest, and
in this tree the same command answers with eleven lines of this repository's own:

grep -n '' Cargo.toml | sed -n '70,76p;88,91p'
70:# outright refusals applies: nothing in the graph opens a socket or resolves a
71:# name, none touches the filesystem, the only thread in it is inside `bytes`'s own
72:# `loom` test module, the one logging facade is `log`, which 0243 already narrowed
73:# this behaviour for and which the verifier entry brings anyway, and nothing here
74:# carries a field-bearing surface of its own. The readings are in 0292.
75:#
76:# Retired by: the toolchain offering HTTP on a stable build, which 0011 already
88:#
89:# The version is pinned at the minor, so a patch release is taken and `0.7` is
90:# not. Under this ecosystem's convention a `0.x` minor is a breaking change, and
91:# 0292 records that cadence as the price of this shape rather than hiding it.

and 0243:231 pastes a seven-row table under a sentence about the crate's own
README, while this tree's README.md answers with prose:

sed -n '20,27p' README.md
[0103](docs/decisions/0103-what-admits-a-dependency-and-what-is-refused.md) is
the rule that admitted the first entry.

THE COUNT THAT REPLACED THE NONE WENT STALE ON THE NEXT ENTRY, WHICH IS WHY
THERE IS NO NUMBER HERE NOW. It said one. A second entry arrived on 2026-09-04
with [0292](docs/decisions/0292-the-means-the-core-speaks-http-with.md), which
decides the means the core speaks HTTP with and had no reason to open this
paragraph, and the sentence above went on saying one until somebody read it

The other four of the six return nothing:

grep -n -A2 'dependencies.log' Cargo.toml ; echo "exit=$?"
exit=1
grep -n '' src/lib.rs | sed -n '456p;1318,1327p' ; echo "exit=$?"
exit=0
grep -rn 'Only map' src/ ; echo "exit=$?"
exit=1
sed -n '56,57p' README.md | awk -F'|' '{print $2 "|" $4}'
|
|

The one that reads as a proven absence

0243:35 is the expensive shape and it is worth separating. The record pastes
10 under it and the pipeline's second stage swallows the missing directory, so
in this tree it prints a number rather than an error:

grep -rn 'log::' src/verification/ | grep -c '!'
grep: src/verification/: No such file or directory
0

Standing where the record's other commands are read, a reader gets 0 on the
output stream where the record says 10. The argument that paragraph makes is
that the logging facade is not optional in the verifier crate, and a 0 is the
answer that refutes it. What produced the 0 is an absent path rather than an
absent call site, and nothing on the output stream says which.

Two of the six name the same path for what the prose calls two crates

0243:231 stands under a sentence about the platform verifier's dispatch table
and 0243:486 under one about a comparison table, three hundred lines and one
intervening crate apart, and both are written README.md:

git show origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md | sed -n '227,231p'
This is the first thing #243 asks and the answer is not uniform. The crate's own
README states its dispatch per platform, and the row that matters is the second
from last:

    sed -n '20,27p' README.md

git show origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md | sed -n '483,486p'
so it costs no narrowing of any record. What it costs is the platform's
decisions, which the crate's own comparison table states in the row for it:

    sed -n '56,57p' README.md | awk -F'|' '{print $2 "|" $4}'

Which checkout each is run in is not written anywhere in the record, so a reader
who wants to reproduce either has to infer it from the paragraph above it.

Why this is a decision and not a change

Neither edit a landed record allows reaches it.

0269 deletes a pasted output that no longer reproduces and leaves the command
standing. These outputs are not stale: each is what its command returned in the
checkout it was run in, and the record's argument rests on them. Deleting ten
correct readings out of a licence decision to repair a path prefix is a larger
move than the defect, and it leaves the same commands pointing at the same wrong
files.

Naming the directory in the command is the repair that fits the defect, and it is
an edit to the prose of a landed record. 0001 withholds that:

git show origin/main:docs/decisions/0001-decision-records.md | sed -n '105,106p'
Three edits are not supersessions and are allowed. Fixing a typographical error

git grep -n '^Narrowed-by: ' origin/main -- docs/decisions/0001-decision-records.md
origin/main:docs/decisions/0001-decision-records.md:7:Narrowed-by: 0267, on the third permitted edit, the pointer to a later record, which takes a fixed form and becomes a pair of fields where the later record narrows a clause
origin/main:docs/decisions/0001-decision-records.md:9:Narrowed-by: 0269, on the rule that a record is never edited in place, which does not reach a pasted output deleted so that only the command that produced it is left

Whether a command's working directory is part of the reading or part of the prose
is the question, and answering it in a change would settle it without anybody
deciding it. It is the same shape #313, #361 and #366 are open on, one class over:
those three ask what a stale output owes, and this asks what a correct output
owes when the command above it resolves somewhere else for the reader.

What this does not decide

• Whether any of the ten readings is right in its own checkout. I did not
  fetch the crate and did not re-run one there. What is measured here is only
  what this tree answers.
• Whether 0292 has the same defect. It names paths under ureq/, hyper/,
  reqwest/, isahc/, attohttpc/, minreq/, bytes/ and */src, none of
  which this repository carries, so every one of those fails loudly. The command
  above returns no site in that record.
• Anything about 0243's anchor. The sha under git rev-parse origin/main
  at 0243:146 is Four records anchor their measurements to a sha under git rev-parse origin/main, and 0269 deletes the anchor rather than a stale reading #366's subject and is untouched here.

Done when

The ten readings in 0243 either name the checkout they are run in, or the
record says once and in one place where a command with no directory in it is
run, or the answer is recorded that a landed record owes neither and a reader is
expected to infer it. Whichever of the three is decided is recorded in
docs/decisions/ as a record going further than 0001 and 0269 rather than as an
edit to either, and it says how the shape is recognised, so the next record
measuring a foreign checkout is written against a rule instead of against this
one's example.

[iderex]

Waiting for: decision - whether a landed record's command carries the checkout it is run in, where the path it names also resolves in this tree, and which of 0001's permitted edits reaches a command that names the wrong one

What this waits on

decision - whether a landed record's command carries the checkout it is run in, where the path it names also resolves in this tree, and which of 0001's permitted edits reaches a command that names the wrong one
Options: each of the ten commands names its checkout | the record says once and in one place where a command with no directory in it is run | a reader infers it from the paragraph above and a landed record owes nothing
Assumed meanwhile: the ten readings are readings of the verifier crate's checkout, and a run of them in this tree is not evidence about 0243

[iderex]

Decided (2026-09-18): a record going further than 0269 gives 0001 a fourth permitted edit, the dated re-reading, and it settles this site with the six beside it.

The rule: under a pasted output or a paragraph that has gone false because the world moved, a landed record may gain one dated note, Read again on <date>:, stating what the command answers now or what the sentence should be read as, and nothing else in the record moves. An output that names the reference the record's other readings were taken at (git rev-parse origin/main under a sentence saying so) is a reference and not a reading, and is left standing. An output that never reproduced at any commit of the record is deleted and gets the note, because it was never evidence. A command that ran in another checkout or against a window that moved gets its directory or its pinned reference in the note. A record is superseded only where its decision itself changes, never to repair a reading. The record that carries this rule is one change; it names #313, #361, #366, #367, #380, #394 and #397 as the sites it reaches, and each of those closes with the note it prescribes.

At this site: the record says once, in one note above the ten readings, which checkout they were run in, and each of the ten stays as written.

[iderex]

Freed: One record going further than 0269 settles this site and the six beside it: a dated re-reading is the fourth permitted edit, anchors stay, a never-reproduced output goes with its note.

Removing blocked-on-decision

Answered by the decision of 2026-09-18 in #394 (comment).

One record going further than 0269 settles this site and the six beside it: a dated re-reading is the fourth permitted edit, anchors stay, a never-reproduced output goes with its note.

[iderex]

0243 says once where the readings with no directory in them were taken

Landed in #502, squashed onto main as
b78a8b01f2426157bb15ffe2cc8a127ffb8eb7ac.

The record says once and in one place where a command with no directory in it
is run, and each of the ten stays as written. Met, by the second of the three
this issue's done-condition offers. The note sits at the foot of
## How the readings below were taken, above every one of the ten:

git show origin/main:docs/decisions/0243-the-means-a-certificate-is-validated-with.md | sed -n '144,152p'
Read again on 2026-09-18: the readings below that are not `cargo` readings were
taken the same way, each inside the extracted source of the crate the paragraph
above it names, and none of them in this tree. Ten of them name their file with
no directory in front of it; six of those name a file this repository also
carries, so a reader who runs one of the six standing in a checkout of this tree
gets an answer out of this repository's own files and no error to say so. Which
of the ten is which, and what this tree answers for each, is on #394. Every one
of the ten stays as written, under
[0313](0313-a-dated-re-reading-of-a-landed-record.md).

The ten are unchanged, counted at the merge commit with this issue's own command:

git rev-parse origin/main
b78a8b01f2426157bb15ffe2cc8a127ffb8eb7ac
git grep -nE "^ {4,}(grep|sed|awk|ls|comm|cat|wc|head|tail) .*(^| )(README\.md|Cargo\.toml|src/|src/lib\.rs)" origin/main -- docs/ README.md SECURITY.md NOTICE.md CONTRIBUTING.md CODE_OF_CONDUCT.md | wc -l
10

Recorded as a record going further than 0001 and 0269 rather than as an edit to
either, saying how the shape is recognised. Met.
docs/decisions/0313-a-dated-re-reading-of-a-landed-record.md names this state as
one of four a reading can be in - the command is correct and its output is what it
returned, in another checkout or against a window at another commit, and a reader
standing where the record's other commands are read gets a different answer out of
a file of the same name - and prescribes that the reading stays as written and the
note carries the directory or the pinned reference. So the next record measuring a
foreign checkout is written against that rule rather than against this one's
example.

What is not covered

The note names the checkout as the extracted source of the crate the paragraph
above each reading names. That is read off the record's own neighbouring commands,
which carry a directory in front of the path, and off the prose above each of the
ten. I did not fetch any of those crates and did not re-run one there, so which
checkout each of the ten belongs to is not measured, and the sentence this issue
already carries about 0243:231 and 0243:486 naming one file for what the prose
calls two crates is unanswered by it.

The note gives no directory per reading. The decision of 2026-09-18 asked for one
note above the ten rather than ten edits, and the record's own rule permits one
note per reading, so a later reading that wants its own directory is not shut out
by this one.

Nobody other than me has read #502, and its body carries the evidence in place of
a second reader.