jcp: C26 — the one-writer requirement gets a conformance clause with teeth #352

Merged

dcharlot merged 1 commit from feat/c25-single-writer-conformance into main 2026-10-20 08:28:34 -04:00

Conversation 0 Commits 1 Files changed 2 +48

dcharlot commented 2026-10-20 04:04:10 -04:00

Owner

Copy link

#346 added §5's one-writer requirement and deliberately added no conformance clause, on the grounds that numbering one the pack cannot test would claim coverage that does not exist. This is that follow-up.

The clause

C26 one writer per record: a second holder is refused asserts three things on the reference FileJournal:

• a second holder of a record another endpoint holds is refused — two would each replay it, each re-establish the same remaining budget and each debit against it, spending it twice while every entry still verifies;
• the refusal is specifically a contention, not some other I/O failure a caller might paper over;
• the claim is released when the holder goes away, or a restart could never reopen the record it previously held — which would turn the requirement into a trap rather than a guarantee.

§9 gains the clause and the harness header gains its class, so the spec's list and the pack agree. This fits the pack's own stated contract — "Every check is real — it exercises the reference library and asserts a property the standard requires."

Proving it has teeth took two attempts, and the first was wrong

I first mutated the check: made it accept a second holder, made it accept any error kind. The suite stayed green, and for a moment that read as a surviving defect.

It isn't. Weakening a check makes it vacuous, and a vacuous check passes. Mutating the assertion tests nothing about whether the clause can detect a violation. The meaningful direction for a conformance clause is to break the implementation and require the clause to catch it:

implementation mutation	result
the lock does not exclude a second holder	C26 FAILED — "a second writer opened a record another endpoint holds"
no lock taken at all	C26 FAILED, same message
contention reported as a different error kind	C26 FAILED — "a contended record failed for the wrong reason"

All three caught with C26 named in the failure — which also settles the question I went in with, namely whether the clause is actually executed by all_checks_pass or merely listed. It runs.

This is the second time in two days that my first mutation set tested the wrong thing (the other being a pair of semantic no-ops). The guard is the same: a mutation must change behaviour the test is supposed to notice, and "SURVIVED" is only meaningful once the mutation is known to be real.

Verification

• cargo check --workspace --all-targets --locked (jcp-rs) — exit 0
• cargo test --workspace --locked — exit 0, 64 test binaries green, no failures
• cargo clippy -p jcp-conformance --all-targets --no-deps --locked -- -D warnings — clean
• check-spec-refs 1675 citations / 16 standards · check-tests-in-ci clean · check-lockfiles 42 current · check-comparative-prose clean

Noted, not touched

While counting clause ids I found two pre-existing asymmetries between the spec's list and the harness: §9 declares a C25 — flow the harness does not implement, and the harness has a C19 (injection resistance) that §9 does not list. Both predate this change and neither is in its path, so they are reported rather than folded in — the first is a claim of coverage, so it is the more interesting of the two.

🤖 Generated with Claude Code

#346 added §5's one-writer requirement and deliberately added **no** conformance clause, on the grounds that numbering one the pack cannot test would claim coverage that does not exist. This is that follow-up. ## The clause `C26 one writer per record: a second holder is refused` asserts three things on the reference `FileJournal`: - a second holder of a record another endpoint holds is **refused** — two would each replay it, each re-establish the same remaining budget and each debit against it, spending it twice while every entry still verifies; - the refusal is specifically a **contention**, not some other I/O failure a caller might paper over; - the claim is **released when the holder goes away**, or a restart could never reopen the record it previously held — which would turn the requirement into a trap rather than a guarantee. §9 gains the clause and the harness header gains its class, so the spec's list and the pack agree. This fits the pack's own stated contract — *"Every check is real — it exercises the reference library and asserts a property the standard requires."* ## Proving it has teeth took two attempts, and the first was wrong I first mutated **the check**: made it accept a second holder, made it accept any error kind. The suite stayed green, and for a moment that read as a surviving defect. It isn't. **Weakening a check makes it vacuous, and a vacuous check passes.** Mutating the assertion tests nothing about whether the clause can detect a violation. The meaningful direction for a conformance clause is to break the **implementation** and require the clause to catch it: | implementation mutation | result | |---|---| | the lock does not exclude a second holder | **C26 FAILED** — "a second writer opened a record another endpoint holds" | | no lock taken at all | **C26 FAILED**, same message | | contention reported as a different error kind | **C26 FAILED** — "a contended record failed for the wrong reason" | All three caught with C26 named in the failure — which also settles the question I went in with, namely whether the clause is actually executed by `all_checks_pass` or merely listed. It runs. This is the second time in two days that my first mutation set tested the wrong thing (the other being a pair of semantic no-ops). The guard is the same: a mutation must change *behaviour the test is supposed to notice*, and "SURVIVED" is only meaningful once the mutation is known to be real. ## Verification - `cargo check --workspace --all-targets --locked` (`jcp-rs`) — exit **0** - `cargo test --workspace --locked` — exit **0**, **64** test binaries green, no failures - `cargo clippy -p jcp-conformance --all-targets --no-deps --locked -- -D warnings` — clean - `check-spec-refs` 1675 citations / 16 standards · `check-tests-in-ci` clean · `check-lockfiles` 42 current · `check-comparative-prose` clean ## Noted, not touched While counting clause ids I found two pre-existing asymmetries between the spec's list and the harness: §9 declares a **`C25 — flow`** the harness does not implement, and the harness has a **`C19`** (injection resistance) that §9 does not list. Both predate this change and neither is in its path, so they are reported rather than folded in — the first is a claim of coverage, so it is the more interesting of the two. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-20 04:04:10 -04:00

jcp: C26 — the one-writer requirement gets a conformance clause with teeth ... 3a57c1f21e

#346 added §5's one-writer requirement and deliberately added no conformance
clause, on the grounds that numbering one the pack cannot test would claim
coverage that does not exist. This is that follow-up: the clause, and a check
that fails when the implementation stops providing it.

`C26 one writer per record: a second holder is refused` asserts three things on
the reference `FileJournal`:

- a second holder of a record another endpoint holds is **refused**, because two
  would each replay it, each re-establish the same remaining budget and each
  debit against it — spending it twice while every entry still verifies;
- the refusal is specifically a **contention**, not some other I/O failure a
  caller might paper over;
- the claim is **released when the holder goes away**, or a restart could never
  reopen the record it previously held, which would turn the requirement into a
  trap.

§9 gains the clause and the harness header gains its class, so the spec's list
and the pack agree.

**Proving the clause has teeth took two attempts, and the first was wrong.** I
first mutated the *check* — accepting a second holder, accepting any error kind
— and the suite stayed green. That is not a surviving defect: weakening a check
makes it vacuous, and a vacuous check passes. The meaningful direction for a
conformance clause is to break the **implementation** and require the clause to
catch it:

| implementation mutation | result |
|---|---|
| the lock does not exclude a second holder | C26 FAILED: "a second writer opened a record another endpoint holds" |
| no lock taken at all | C26 FAILED, same message |
| contention reported as a different error kind | C26 FAILED: "a contended record failed for the wrong reason" |

All three caught, with C26 named — which also settles that the clause is
actually executed by `all_checks_pass` rather than merely listed.

Noted while counting clause ids, not touched here: §9 declares a `C25 — flow`
the harness does not implement, and the harness has a `C19` (injection
resistance) §9 does not list. Both asymmetries predate this change.

Co-Authored-By: Claude Opus 5 <[email protected]>

dcharlot merged commit 55b86aaf76 into main 2026-10-20 08:28:34 -04:00

dcharlot referenced this pull request from a commit 2026-10-20 08:28:34 -04:00

Merge pull request 'jcp: C26 — the one-writer requirement gets a conformance clause with teeth' (#352) from feat/c25-single-writer-conformance into main

dcharlot referenced this pull request 2026-10-20 08:42:21 -04:00

jcp: C25 — flow was a declared clause with no check; now it has one #357

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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

Transaction-Science/open-standards!352

No description provided.