CB-WP-0006 T07: implement K18, amend K14

Two rules, two different answers, which is the point of a task phrased
"implement, or amend and say why".

K18 is implemented. "Criterion benches driving the same scenario format at
scale" was false — the bench hardcoded its commands and never touched
ScenarioFile, while MetricsAndScenarios §3 pointed at a benchmarks/
directory containing only baselines/. benchmarks/synthetic-3p.yaml now
holds the workload and both the bench and bench_shape read it: the
workload is data, not code.

A second defect surfaced while fixing the first. After the bench switched
to the file, bench_shape still hardcoded the same sequence, so the
workload existed twice — deleting end_round from the YAML broke bench-test
while bench_shape kept passing. Duplicated-fact drift in executable form.
Both now read the same include_str! and deleting a command breaks both.

Explicitly not claimed: this does not unblock AM-3. AM-3's baseline is a
declarative game object — moves, turn order, rules. synthetic-3p.yaml is a
command list; the rules live in games/ground. Marking it as AM-3's subject
would compare a script to a game definition, which is the category error
AM-3 is blocked on. The file says so in its own header, where the next
person will be tempted.

K14 is amended. CommitWindow had zero non-test users and GROUND enforces
the same contract inline. Wiring GROUND through it was rejected: it would
change the serialized shape of `selections`, which four scenario files
assert by dot-path and every state hash depends on, for the sole benefit
of making a sentence literally true.

The deciding argument is INTENT's, not convenience: abstractions are
extracted from working games rather than invented in isolation, and no
concept becomes canonical until it survives a second concrete use.
CommitWindow was invented before any game needed it and has survived none.
Imposing it on GROUND would manufacture the first use rather than discover
it. So K14 states what is actually guaranteed, CommitWindow is marked
provisional in the source, and it carries a delete-by date of 2026-12-31.

Kernel spec->code link 16/18 -> 18/18, stated with the caveat the gate
prints every run: that is about names, not assertions.

Two self-tests broke and both broke correctly. rule-coverage's gate test
hardcoded "unlinked rules exist today" and failed when the last one was
linked; it now computes that and asserts the gate fails iff rules are
unlinked. facts' text check rejected k_unlinked once it became
legitimately empty; empty now renders as "(none)" and the check
distinguishes absent from empty.

M-D1-MUT: 8 of 14, unchanged — K14 and K18 are kernel rules, not
acceptance rows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

specs/GameKernel.md

@@ -105,13 +105,54 @@ Command (actor-tagged intent)
   PlayerView` that structurally cannot include: other players' unrevealed
   commitments, face-down problem identities, other players' hands.
   Projections are derived views — never inputs to `validate`/`fold`.
-- **K14** The GROUND round (GR-R01..R09) is expressed through runtime
-  primitives: one commit window per Select, reveal, then fixed-order
-  resolution steps with Lead-order iteration (GR-R06/R07) driven by
-  system commands.
+- **K14** *(amended 2026-08-01, CB-WP-0006 T07 — see §2.5a)* The GROUND
+  round (GR-R01..R09) **implements the commit-window contract**: one
+  window per Select, duplicate submission rejected, completeness required
+  before Reveal, then fixed-order resolution steps with Lead-order
+  iteration (GR-R06/R07) driven by system commands. It implements that
+  contract **in its own aggregate**; `CommitWindow` in `cb-game-runtime`
+  is the extracted form, and is **provisional until a second game uses
+  it**.
 
 ### 2.6 GROUND aggregate (`games/ground`)
 
+
+#### 2.5a Why K14 was amended rather than implemented
+
+The original K14 said the round *is expressed through* runtime
+primitives. It was not: `CommitWindow` had **zero non-test users** and
+`games/ground` did not import it. GROUND collects selections in its own
+`BTreeMap` and enforces the same contract inline — duplicate submission
+(`second_selection_is_a_duplicate`), completeness before Reveal
+(`GR-R04`), and ordered reveal.
+
+Two options were available and the choice is recorded because it could
+reasonably have gone the other way.
+
+**Wiring GROUND through `CommitWindow` was rejected.** It would change
+the serialized shape of `selections`, which four scenario files assert by
+dot-path (`selections.0.action`) and which every state hash depends on —
+a large, risky refactor whose only benefit is making a sentence literally
+true. More importantly it inverts INTENT: *"abstractions are extracted
+from working games... rather than invented in isolation"*, and *"No
+concept becomes canonical merely because it looks general. It becomes
+canonical after surviving a second concrete use."* `CommitWindow` was
+invented before any game needed it and has survived **zero** uses.
+Imposing it on GROUND now would manufacture the first use rather than
+discover it.
+
+**So the rule was amended to state what is actually guaranteed**, and the
+primitive is kept and marked provisional. It costs ~60 lines, it documents
+the seam stage 3 (networked sessions) and stage 4 (packaging) will need,
+and re-extracting it from GROUND when a second game exists will be
+better-informed than keeping it aligned by hand now.
+
+**Open, with a date:** if no second game uses `CommitWindow` by
+**2026-12-31**, it should be deleted rather than carried — a primitive
+with one hypothetical user and a test that exercises only itself is the
+AM-11 shape (a claim resting on a pair with no consumer), and this project
+has now paid for that shape twice.
+
 - **K15** State implements specs/GroundRules.md §1 exactly; every GR-rule
   is realized in `validate`/`fold` and cross-referenced by rule ID in doc
   comments, giving a greppable rule→code→scenario chain.