kit page: four capabilities still have no card (carried over from #25)

[sandstream]

What this is

#25 brought the kit section's copy up to 6.9.0 and named four things it deliberately left out rather than pad the PR with. Recording them here so they are a decision rather than a gap someone rediscovers.

The version number self-heals — the scheduled job (#24) has bumped it unattended twice, touching exactly two lines each time. The copy does not, and this is the backlog of that.

Not yet covered

capability	why a visitor would care
kit init generating only what the repo proves	The alternative is a scaffold that asserts things about your project that are not true; "only what is proven" is the whole difference and it is currently unsaid.
MCP kit_check output offloading	A full response measured larger than the entire standing tool surface, and it is paid on every call in a check → fix → check loop. The summary-plus-file design is a real cost property, not an implementation detail.
docs/RELEASING.md	The release process is one of the more credible things to point at, and nothing on the page points at it.
6.9.0's plugin-registry fix	Smallest of the four; include only if it says something a visitor can act on.

The constraint that matters more than the list

Whatever gets written must be in the page's capability-first register — "Lost coverage outranks a regression", "Your platform's env, diffed without reading values". Not changelog voice.

That is not a style preference, it is the specific mistake #25 had to correct mid-flight: five cards shipped as changelog prose and were rewritten, including one that had already merged. The failure mode is recounting kit's own defects and version history to a reader who has never used it. A card says what kit does and why it matters; the postmortem stays in the changelog.

For the kit_check row especially, the temptation is to lead with the measurement ("the response was bigger than the surface"). The reader's version is the property: an agent in a fix loop pays for the answer every time, so the answer is summarised and the full run goes to a file.

Suggested handling

Add them deliberately, in one pass or none — not appended to an unrelated PR. Each card also needs its llms.txt counterpart in the same change, since that file is what other models read to answer "what does kit do"; leaving it behind means every second-hand description of kit stops short.

Then re-run the checks #25 used before merge: HTML tag balance, and scripts/sync-kit-version.mjs --check to confirm the copy change and the automation do not fight.

What I did NOT verify

• Whether all four are worth a card. The plugin-registry fix in particular may be below the bar for a landing page; that is a judgment for whoever writes it, not settled here.
• Whether anything since 6.9.0 belongs on this list. This is the kit site: the copy catches up to 6.9.0 — as web copy, not changelog prose #25 carry-over exactly, not a fresh audit of the current release against the page.

Related

• kit site: the copy catches up to 6.9.0 — as web copy, not changelog prose #25 — merged; brought the copy to 6.9.0 and named these four as out of scope.
• kit site: sync the two version fields from npm on a schedule (and → 6.7.0) #24 — the version-sync automation that keeps the number in step but cannot write copy.

🤖 Generated with Claude Code