docs(agents): an extraction fault is symmetric, its two outcomes are not #19

Merged
jlxq0 merged 1 commit from docs/extraction-fault-asymmetry into main 2026-08-27 04:43:25 +00:00
Owner

Comparing the allowlist literal against the deployed value printed DIFFER
against a value that was byte-identical. The comparison was correct; the
extraction was not — sed -n 'start,+9p' read one line past the string and
swallowed let allowed = parse_allowlist(...). It happened in PR #18, whose
subject was a check reporting agreement it cannot see, on the same value,
within a minute.

The mechanism is symmetric and the consequence is not. DIFFER sends
someone to look and the fault surfaces in a minute. The same extraction bug
printing IDENTICAL is never questioned by anybody, and it is the answer a
comparison like this is usually run to hear.

So the entry says two things: bind the extraction to the literal (match
let raw = "(.*?)"; and unescape the continuations) rather than to a line
count the next edit invalidates, and show the check both answers before
believing either.

Applied to the corrected version before writing it down, rather than
shipping a rule unrun:

input counts verdict
the real file 9 vs 9 IDENTICAL
a copy with claude://oauth/callback removed 9 vs 8 DIFFER, naming the entry

Gates green at the head: fmt, clippy -D warnings, 95 tests. AGENTS.md only.
v0.1.4 stays the release, pod untouched on sha256:dd915b10….

Comparing the allowlist literal against the deployed value printed `DIFFER` against a value that was byte-identical. The comparison was correct; the extraction was not — `sed -n 'start,+9p'` read one line past the string and swallowed `let allowed = parse_allowlist(...)`. It happened in PR #18, whose subject was a check reporting agreement it cannot see, on the same value, within a minute. **The mechanism is symmetric and the consequence is not.** `DIFFER` sends someone to look and the fault surfaces in a minute. The same extraction bug printing `IDENTICAL` is never questioned by anybody, and it is the answer a comparison like this is usually run to hear. So the entry says two things: bind the extraction to the literal (match `let raw = "(.*?)";` and unescape the continuations) rather than to a line count the next edit invalidates, and show the check both answers before believing either. **Applied to the corrected version before writing it down**, rather than shipping a rule unrun: | input | counts | verdict | |---|---|---| | the real file | 9 vs 9 | `IDENTICAL` | | a copy with `claude://oauth/callback` removed | 9 vs 8 | `DIFFER`, naming the entry | Gates green at the head: fmt, clippy `-D warnings`, 95 tests. `AGENTS.md` only. `v0.1.4` stays the release, pod untouched on `sha256:dd915b10…`.
docs(agents): an extraction fault is symmetric, its two outcomes are not
All checks were successful
CI / cargo (pull_request) Successful in 54s
CI / docker (pull_request) Successful in 19s
c21229b1b7
Comparing the allowlist literal against the deployed value printed DIFFER
against a value that was byte-identical. The comparison was fine; the
extraction was not -- sed -n 'start,+9p' read one line past the string and
swallowed let allowed = parse_allowlist(...). It happened in the PR whose
subject was a check reporting agreement it cannot see, on the same value,
within a minute.

The half worth recording is the asymmetry. The same fault printing IDENTICAL is
never questioned; DIFFER sends someone to look and surfaces it in a minute. So
a comparison of source against deployment has to be shown both answers before
it is believed, and the extraction has to be bound to the literal rather than
to a line count the next edit invalidates.

Applied to the corrected version before writing this: 9 vs 9 IDENTICAL on the
real file, 9 vs 8 DIFFER on a copy with one entry removed, naming the entry.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jlxq0 merged commit 51b1de12b3 into main 2026-08-27 04:43:25 +00:00
jlxq0 deleted branch docs/extraction-fault-asymmetry 2026-08-27 04:43:26 +00:00
Sign in to join this conversation.
No reviewers
No labels
waiting-on-julian
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jlxq0/carddav-mcp!19
No description provided.