Two Feature surfaces the suite does not reach

[TBarregren]

What to build

Two things the collection now promises about a Feature are not held by anything. They are filed together because both are the same shape — a rule stated for both entry types and enforced for one — and because docs/rules/skills.md already obliges that module to say where the suite holds less than the rule, which is half of what each needs.

The Feature half of Select's unchecking gate. cmd_apply_select in skills/kntnt/scripts/kntnt.py raises two distinct refusals through require_yes: one where unchecking deletes a Skill's files, and one where unchecking a Feature takes what it wrote back out of a Harness's own configuration. docs/rules/collection.md states both halves as the rule, and every shipped page carrying the gate now states both. Only the first is exercised by a test. Add a test for the second, alongside the existing one for the Skill half so a reader meets them together.

The README's Feature sections. docs/rules/skills.md says a Feature gets a section under the README's ## Features heading on the same terms a Skill's section is written on, and the module names the suite enforcement for the Skill case. tests/test_readme.py reads only the partition holding the Skills, against the Catalog's Skills. Nothing compares the ## Features sections against the Catalog's Features.

That second one has two admissible shapes and the choice is made here so a builder does not have to make it: extend the test. Compare the README's ## Features sections against the Catalog's features the way the existing check compares the Skills, rather than adding a disclaimer saying nothing does. The disclaimer route is what docs/rules/skills.md requires when a rule genuinely outruns the suite, and it is the wrong answer where the check is this cheap to write.

Acceptance criteria

• A test exercises the refusal cmd_apply_select raises when unchecking a Feature without --yes, asserting on that refusal and not on the one raised for a Skill.
• A test compares the README's ## Features sections against the Catalog's Features, on the terms the existing Skills check uses.
• Both new tests fail against the code with the behaviour they check removed or inverted, rather than passing vacuously.
• Where docs/rules/skills.md said the suite holds less than the rule for either of these, and it no longer does, that sentence is brought up to what the suite now holds.
• The four checks CONTRIBUTING.md lists all pass.

---

Written against 6fc533f

[TBarregren]

Readiness addendum — verified against 6a39de8, 2026-09-07

Both halves still hold. The only test of the unchecking gate is test_unchecking_refuses_without_yes in tests/test_kntnt.py, which unchecks a Skill and asserts only that --yes appears in stderr. tests/test_readme.py still partitions the README at ## Usage and reads Skill sections only, while README.md carries ## Features with ### session-cleanup and ### statusline, and skills/kntnt/catalog.json carries both under features. docs/rules/skills.md still says in its Feature list that a Feature gets a README section on the same terms, and says under ## The README that the suite enforces it — for Skills.

A fixture gap the body did not know about, settled here. The _world fixture in tests/test_kntnt.py writes a Catalog with a skills key and no features key, and its fake Manager ships no features/ directory. catalog_features() reads the Manager's own catalog.json and feature_dir() reads here()/features/<name>, so no existing world can reach the Feature refusal, and validate_names would refuse the name as unknown. The refusal itself is raised before any write: feature_change computes feature_remove from feature_state, which reads the Feature script's health. So the honest test is:

1. Extend the world with one Feature: a features entry in the fixture Catalog (shape as in the shipped catalog.json: name, category, description, binaries, capabilities, harnesses, writes) and a features/<name>/FEATURE.md under the world's Manager declaring a script via kntnt.integrations in its collection block. The simplest honest script is the shipped statusline Feature: copy MANAGER_DIR / "features" / "statusline" into here and take its Catalog entry from the shipped catalog.json. tests/test_features.py already writes throwaway FEATURE.md files under a manager (the tests refusing a Feature page with no Writes section) and is the shape to copy if a bespoke one is preferred.
2. Enable it with apply select <feature> --yes; its writes land in the world's redirected home.
3. Run apply select --off=<feature> without --yes. Use the delta form so no Skill is unchecked in the same run: the Skill gate is checked first and would mask the Feature one.
4. Assert exit 2, that stderr carries the Feature sentence (takes what they wrote back out of your Harnesses' own configuration), and that it does not carry the Skill sentence (deletes their files).

Put it beside test_unchecking_refuses_without_yes, as the body asks.

The README test. Extend tests/test_readme.py with a second partition at \n## Features\n compared against catalog["features"], with the same non-empty guard the Skills check has and an assertion message of the same shape. Keep the existing Skills test as it is.

Criterion 3 is a builder's own step, not a shipped artefact. Temporarily drop the Feature require_yes call and confirm the new test fails; temporarily delete a ### statusline section and confirm the README test fails; restore both. Say in the commit message that this was done.

Rules module. Afterwards the sentence under ## The README in docs/rules/skills.md that names suite enforcement for Skills names Features too, and the Feature bullet may point at it. The gate rule in docs/rules/collection.md (--yes means no question is asked at all) states the rule without claiming suite coverage and needs no change.

No Catalog regeneration unless a shipped file under skills/ changes; tests and docs/ are not shipped.

[TBarregren]

Second addendum — corrections after an independent readiness review, 2026-09-07, against 6a39de8

This comment outranks the first addendum wherever the two differ. A reviewer built both halves in a throwaway copy following the first addendum and confirmed they work; the points below are what it had to work out on the way, settled here so the builder does not.

The Feature is opt-in on the fixture, never part of every world. Give _world in tests/test_kntnt.py a keyword parameter that defaults off (for instance feature: bool = False) and add the Feature only where it is true. Adding it to every world turns 21 existing tests red: every Update test fails with staged Manager offers the Feature 'statusline' and does not carry it, and every Uninstall test changes shape because a Global Feature is torn down first. Only the new refusal test asks for it.

Correction: the Catalog is read from the origin first. The first addendum said catalog_features() reads the Manager's own catalog.json. It reads the origin (KNTNT_SOURCE, which the fixture points at the world's source) and falls back to the snapshot beside the Manager only when that fetch fails. The fixture's _catalog() helper writes both catalogs, so put the features list into what _catalog() returns when the parameter is on, and both are covered.

Take the Feature entry and its files from what ships. Copy the statusline entry out of the shipped skills/kntnt/catalog.json whole, digest included (the first addendum's list of keys omitted it; test_every_feature_states_what_it_writes_and_which_harnesses_it_serves expects it on a shipped entry), and copy MANAGER_DIR / "features" / "statusline" into the world's Manager at here / "features" / "statusline". Its script resolves the Library at <manager>/library, which the fixture already copies, so the shipped Feature runs unchanged in the world.

The test itself, as the first addendum gave it, stands: Enable with apply select statusline --yes, then apply select --off=statusline without --yes, assert exit 2, the Feature sentence in stderr, and the Skill sentence absent. Delta form only, since the Skill gate is evaluated first.

docs/rules/skills.md, settled. Change one sentence: the last sentence under ## The README ("The suite fails when the Catalog names a Skill the README has no section for...") is widened to say the same of a Feature and its ## Features section. Leave the Feature bullet in the FEATURE.md list as it is; it says a Feature's section is written on the same terms, which stays true. Leave line 7's "the README paragraph nothing compares against anything" as it is too: that clause is about the dependencies paragraph that closes ## Usage, which this ticket does not touch. Nothing in skills.md says the suite holds less for either of this ticket's two rules, so criterion 4 reduces to that one sentence.

[TBarregren]

Third and final addendum — 2026-09-07, against 6a39de8

Three things a second independent build had to supply. With these the recipe is complete.

A Harness must be Detected first, or the test passes vacuously. The new test's first line after _world(...) is _present(world, "home", ".claude"), exactly as test_unchecking_refuses_without_yes does. statusline serves claude-code only; without a Detected Harness feature_serves is empty, feature_change computes no removal, and the run exits 0 instead of reaching the refusal.

_catalog() gains an optional features parameter defaulting to None, and omits the key when it is None. Never emit "features": [] by default: features_of reads a missing key as a collection shipping no Features, and every other world has to keep looking like that. Only the new test's world passes a list.

"On the terms the existing Skills check uses" means: a new test function in tests/test_readme.py, using the same SECTION regex over the text between \n## Features\n and the next \n## , with the same non-empty guard and an assertion message of the same shape ending See {STANDARD}. The existing Skills test is not touched.

Everything else in the two addenda above stands.

[TBarregren]

Recorded by an unattended run: built and then verified independently against this ticket's acceptance criteria.