Skip to content

Commit 21ba6c2

Browse files
codeslakeclaude
andcommitted
docs: state the narrowing limit as a design choice, not a missing capability
The paragraph said a reader "has no previous state to compare against", which reads as a limitation — and a limitation is an invitation. Someone adds the previous bundle as state, believes they have lifted it, and adds a cert-count floor. The floor would still be wrong. A shrink is legitimate whenever a root is retired or a component is uninstalled, and only the builder knows which happened, so a reader holding BOTH bundles still cannot tell a regression from a fact. Measured across two machines here: a legitimate bundle is 5 certs on one and 168 on the other, so any floor that catches narrowing on one host rejects a healthy bundle on the next. Surfaced by a peer session that had the mirror-image wording in its own comment and changed it after the same argument. Co-Authored-By: Claude <noreply@anthropic.com>
1 parent f97698f commit 21ba6c2

1 file changed

Lines changed: 12 additions & 5 deletions

File tree

README.md

Lines changed: 12 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -259,11 +259,18 @@ lets a participant publish where no builder looks, or read a file no builder
259259
writes, while still appearing to implement the contract. `CLAUDE_CONFIG_DIR`
260260
already relocates the pair, and it moves both halves together.
261261

262-
Note the limit of what a consumer can check: intact, and carries my CA. Whether
263-
the bundle is *complete* — that no corporate root went missing — is the
264-
builder's guarantee, not something a reader can verify, because a reader has no
265-
previous state to compare against and a legitimately small bundle is
266-
indistinguishable from a narrowed one.
262+
Note the limit of what a consumer checks: intact, and carries my CA. Whether the
263+
bundle is *complete* — that no corporate root went missing — is the builder's
264+
guarantee, and a consumer must not act on it even where it could.
265+
266+
That is a design choice, not a missing capability, and the distinction matters
267+
because the other reading is an invitation: someone adds the previous bundle as
268+
state, believes the limitation is lifted, and adds a floor. It would still be
269+
wrong. A shrink is *legitimate* whenever a root is retired or a component is
270+
uninstalled, and only the builder knows which happened — so a reader holding
271+
both bundles still cannot tell a regression from a fact. Measured: a legitimate
272+
bundle is 5 certs on one machine here and 168 on another, so any floor that
273+
catches narrowing on one host rejects a healthy bundle on the next.
267274

268275
**This is a cooperative convention among same-user processes, not a trust
269276
boundary.** The check proves *parses, and carries us* — never *contains only

0 commit comments

Comments
 (0)