docs(plan): ship kernel-kind-parity-bar — the bar is every kernel kind

[tato123]

Ships kernel-kind-parity-bar: narrows §Graphics' parity claim to every kernel kind, names the four capabilities Python cannot reach, annotates the ADR that owns the decision, and archives the change file.

Precondition — every ticket merged

Ticket	PR	Merged
#1777 graphics and ray-tracing kernels at Python parity	#1896	2026-08-18

The change's own ticketing note is explicit that /derive-tickets mints nothing for a plan-and-ADR wording change inside work already ticketed — the narrowing rides #1777. The two tickets the owner ruling created are both already discharged, checked rather than assumed:

• plan(python): spell CPU readback and write-back of texture-backed surfaces in the wheel #1758 was widened 2026-08-18 ("Widened by owner ruling, 2026-08-17 — this ticket now owns CPU write as well as read"), which is the condition the owner attached to accepting gap 3.
• feat(engine): vertex and index buffers, and indexed draws, reachable from Python #1898 is filed post-MVP on Graphics Kernel Buildout for gap 1.

Archive date is #1896's merge date, 2026-08-18.

Step 1 — the REMOVED gate

$ bash .claude/scripts/ship-change-removed-gate.sh docs/plan/changes/kernel-kind-parity-bar.md
note: docs/plan/changes/kernel-kind-parity-bar.md declares no '- REMOVED:' bullets — nothing to verify.
EXIT: 0

This matches the change's own ## REMOVED section, which reasons the point out rather than asserting it: nothing in the tree retires, because the four refusals this change records are shipped behaviour, and the plan sentence and ADR clause it amends live in trees the gate excludes from its content sweep. Re-run against the archived path is identical.

The fold was entirely outstanding

Worth stating plainly, because the change file says otherwise. It records that "the narrowed prose and the ADR annotation ride #1777 / PR #1896". Neither did. PR #1896 touched only docs/plan/changes/python-kernel-surface.md among docs; PR #1897 landed this change file plus one header line (git log docs/decisions/python-kernel-api.md shows no commit from either).

So until this PR, five days after the owner narrowed the claim:

• ARCHITECTURE.md promised Python "reaches every GPU capability Rust authoring reaches… No kernel capability is Rust-only".
• docs/decisions/python-kernel-api.md decision 1 read unannotated.

This is also the finding CodeRabbit raised on #1907, which I declined there on the grounds that writing an unshipped change's text into the decision source is the doctrine violation /ship-change exists to prevent. This is the sanctioned place for it.

Step 2 — the fold

Applied as the change wrote them, paste-ready:

• §Graphics' parity entry narrows to every kernel kind. The enumeration survives verbatim because it is what the ruling narrows to, and the two gaps a Python processor cannot reach are named inside the entry where the claim is read — vertex and index buffers with indexed draws, and storage- and uniform-buffer bindings. Both undesigned. The bracket keeps python-kernel-surface's SHIPPED clause and gains the semicolon amendment clause, the document's idiom for a partial later amendment.
• §Graphics' trailing OPEN entry expands to name gaps 2 and 4 — depth attachments and MSAA. They land in OPEN rather than in the DECIDED entry because neither is a Python-reach gap: both are unbuilt in every language, and equalising a construction surface with no pass to render against would buy nothing.
• The ADR's decision 1 is annotated, not overwritten, per .claude/rules/docs-policy.md's supersession form. The annotation names no issue or PR number, per docs/decisions/README.md:19. Its differentiator claim survives unnarrowed — being "a proxy to Rust-powered GPU work" claims a relationship, not a surface area.

§Graphics stays IN-FLIGHT, and the header now carries no arrow — a form the document has not used before, so flagging it. No live change drives the section, but it cannot flip to SHIPPED either: its last [python-kernel-api] entry, the Rust bindings-at-dispatch convergence, is unbuilt and has no change file.

Both commissioned markers are CI-runnable and were actually run, not just name-checked:

$ .venv/bin/python -m pytest tests/test_graphics_kernel.py::test_a_draw_takes_no_vertex_buffer_no_index_buffer_and_no_depth_target \
                            tests/test_graphics_kernel.py::test_a_graphics_kernel_carries_no_depth_or_vertex_input_state -q
..                                                                       [100%]
2 passed in 0.02s

Signature-only, no GPU — real CI coverage, unlike the rig-only markers on the neighbouring entries.

Step 3 — the diagram

No diagram edit is owed. Re-verified rather than inherited from the change file, whose system.mmd:31 anchor predates the last two ships: the diagram's kernel references are neither kind- nor capability-scoped, so the narrowing does not falsify any label.

Note on the archived file's anchors

The change file's ARCHITECTURE.md:NNN citations are stale again — #1908's raw-handle fold shifted everything below §Packages by ten lines. I re-anchored them one PR ago because the file was still live and its fold pending; now it archives, and an archive is a record of what was true at authoring, so they are left as written. Same posture as the existing archives.

Verification

cargo run -p xtask -- check-all-source-gates — all 10 source-walking gates pass.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@tato123, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 17 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 00ab1609-c860-427c-b09e-be82e079d1ee

📥 Commits

Reviewing files that changed from the base of the PR and between d6b12a7 and aabcbcb.

📒 Files selected for processing (3)

• docs/decisions/python-kernel-api.md
• docs/plan/ARCHITECTURE.md
• docs/plan/changes/archive/2026-08-18-kernel-kind-parity-bar.md

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}