Capability doors¶

Every capability this plugin has, and how a person reaches it.

The reposition map answers the other question — what the product can do, and which layer owns each piece. This page answers the one that decides whether a feature gets used at all.

Reader-facing sibling: this page is for maintainers — every door of every capability. The reader-facing rendering, one line each and grouped by how you reach it, is Everything it does, generated from the same CAPABILITIES registry (#588).

It exists because of a small, embarrassing measurement. Think before you look — the Thought Lab's mechanic that asks what you expect before it shows you anything — was specified, built, documented and shipped, and the person who asked for it could not find it in their own vault. It was not buried. It was one eye-off button among ten identically weighted controls in one surface, and that was enough.

The five ranks¶

A door is how you arrive at a capability. They are not equivalent:

Ranks 1–3 are discovery: you arrive without having been told the thing exists. Ranks 4 and 5 are re-entry: useful to someone who already knows, useless to everyone else.

The rule¶

Every capability has at least one door of rank 1–3.

A capability whose only door is a command is a capability nobody discovers. The palette is where you go looking for something you already know is there — which is exactly the population that does not need help finding it.

And the line that keeps the rule from being argued away:

A capability is something you do to something. If there is no object — no note, no selection, no question — and the thing is a standing rule the plugin follows while you are elsewhere, it is configuration, and settings is its home by design rather than by neglect.

Knowledge patterns and the vault hooks are configuration. Both have a name, a settings group and a docs page; neither is something you open. Quick capture, deriving a project and the weekly review all have an object, and all three got a real door instead of an exemption.

This is enforced, not encouraged. Two guardrails, in test/config/capabilityDoors.test.ts:

• Guardrail A — the rule above. Rows that fail today are carried in the DOORLESS register with the issue that fixes each, so the guardrail ships green; a row that stops failing and keeps its excuse also fails the build, so the register can only shrink.
• Guardrail B — every door resolves. A command against the registrations, a surface against SURFACES, a ribbon entry against the ribbon's own table, a settings row against the locale, a control against the filesystem. A registry claiming the collision is a control in the Lab is worth nothing once the Lab renderer moves.

Adding a capability¶

src/architecture/components/core/surface/capabilities.ts is a closed vocabulary. Add the id to CAPABILITIES and TypeScript refuses to compile until it has an entry in CAPABILITY_DOORS — a name key, an owner, and at least one door. Then:

1. Give it a name in both locales. A capability with no name a person could read is not one, and that definition is what stops this list becoming a second copy of the module list.
2. Give it a rank 1–3 door in the same change. Not "later" — later is what produced this page. If the door genuinely cannot ship yet, DOORLESS takes the row with an issue number, and that issue is the commitment.
3. Regenerate the table below (capabilityAuditTable()), which capabilityAudit.test.ts compares against this page.

A command is still worth registering — a hotkey is a real convenience, and the retired views' ids are kept on purpose so a binding never breaks (§XI). It just is not a door.

The audit¶

Generated from the registry. Do not edit by hand — capabilityAudit.test.ts will tell you. A ⚠️ marks a row failing guardrail A, carried by the register.

What the first measurement said, and what happened to it¶

#575 measured forty-one capabilities and found eleven — better than one in four — with no door above a settings row. Eight of the eleven sat at rank 5: the command palette and nowhere else.

They were not the ten the plan predicted, and the difference is the interesting part. The plan counted command-only ids; the registry counts capabilities. Opening the canvas turned out to have a settings row and the 3D graph a lens control, so both dropped off — while knowledge patterns and the vault hooks, which have no command at all and so were never scanned for, took their places. A capability with no command was invisible even to the audit looking for invisible capabilities.

#578 emptied the register:

Nothing was deleted. Every one of the nine was a thing a person would want; what they lacked was a way in. What the epic actually removed is duplication and litter: a second query engine (the blind panel's hand-rolled matcher, #576), one dead stylesheet, and seventeen off-grid pixels that went on the grid while their block moved house.

What a table cannot see¶

Think before you look — the mechanic that started the epic, the one its author could not find in their own vault — passed guardrail A from the first measurement. Its eye-off button really was "a control in the view showing it": rank 1, by the letter of the rule.

That is not a hole in the guardrail. It is the guardrail being honest about what a static registry can know. A door existed; it was not visible, because it was one of ten identically weighted controls in one header. No table will ever measure that, which is why #576 (move it where you ask) and #577 (one primary action per header) had to be argued rather than asserted — and why the surfaces page carries the header rule beside this one.