[Piggidragon]

Step B8 of #152, stacked on #181 (B7). Part of #152.

A center with the settings grant can now add, change and remove capabilities of its own on a node, and the center's web UI gets a Capabilities tab to see and manage them (owner decisions Q22, Q24).

The node

• New settings actions: settings.cap-add, settings.cap-edit and settings.cap-rm.
  • They are stored in that center's own entry of the pairing ([[center.capability]]). No other center ever sees them, in list, in cap ls rows or in the settings.
  • They need the settings grant (write) and are audited through commit as center <name>.
  • settings stays unreachable through execute.
• The limits:
  • They always run as nerve-run; there is no account field (B5).
  • For the defaults they count as execute, whatever effect is declared.
  • Sense and actuate stay off until the owner's cap set … on --center. A center's own on is refused.
  • An off or hidden of a center's capability stays until the owner changes it.
  • A center can never add under the name of the owner's capability or a program's, and can never change or remove one of them.
• Where they are refused: a Windows node (Windows: the desktop app is the only way to the node #176) and a node run by hand refuse with their reason, since only the installed node has nerve-run.
• What the owner sees: cap ls shows who added each capability ("added by center X, counted as execute", or "waits for your cap set on" for sensing). cap rm NAME --center C removes one; settings.get capabilities lists a center's own.
• Shared form check: the form check moved from the desktop app into nerve-policy (config::form), so the app, the center and the node check a capability with the same code.

The center's web UI

• A top-level Capabilities tab (after Action checker) with a node picker.
• It shows the node's offered units with their effect and source (built-in, the owner's node.toml, this center, program X), and the ones left out with their reason.
• Your capabilities:
  • Add, edit and remove the center's own, removal with a confirmation.
  • The form is checked server-side as you type, by the same validator. Schemas outside the subset show where and why.
  • The node's own refusal shows in the form.
• A node without the settings grant is shown read only (the Q24 choice): its units and sources, and a note that the center may change nothing there and how the owner gives the grant. There is no form.
• API: GET /api/caps, POST /api/caps/check, POST /api/caps/save and POST /api/caps/remove. Each change is in the center's log.

Docs

• User: web-ui.md, settings-grant.md, config-capabilities.md, commands.md.
• Developer: settings-and-config.md.
• Spec: node-local.md §2 and §5, protocol.md §7.4 and the new §7.4.2, conformance.md.
• CHANGELOG: two bullets in the Architecture: two MCP tools (list, execute) and capabilities of your own (providers on the installed node, config capabilities, state and streams) #152 section.

Tests

• Node (tests/center_caps.rs):
  • a center adds, runs and edits its own capability, and the owner removes it;
  • no account field, and the owner's capabilities are left alone;
  • execute is counted, and sensing waits for the owner;
  • another center never sees it;
  • a node run by hand takes none.
• Conformance: two §7.4.2 checks in the node part; the e2e now runs 22 profile checks.
• Center (tests/caps.rs), an in-process center and node:
  • the tab lists the sources;
  • broken forms are checked and refused;
  • an add through the API, then list and execute through MCP, with settings.cap-add unreachable through execute;
  • edit, the node's refusal as a 409, the log, and remove;
  • without the grant the tab is read only and a save is refused.
• ui.rs covers the API and app.js sources.
• Shots, light and dark at 1280×800 and 390×844: the page, the form, the picker, the add steps, read only.

Real machines

• LXC, installed node (musl release build), paired with a local center that has the settings grant. Playwright drove the real page:
  • From the web UI, the center added who.am (id, read) and cam.look (sense).
  • The form flagged an argument placeholder the schema does not have.
  • A name the owner's node.toml already has was refused by the node, shown in the form.
  • execute who.am ran as uid=…(nerve-run).
  • cam.look was not offered. The center's on was refused ("only the owner can turn on what senses or actuates"). After the owner's cap set cam.look on --center lxc it ran.
  • The owner turned who.am off (the center's on was then refused) and removed it with cap rm --center.
  • The audit log has every step: the center's two adds, the calls, and the owner's on, off and rm.
  • With the grant taken away, the page was read only.
  • Found there and fixed: cap ls called a center's sensing capability "counted as execute".
  • uninstall --purge left nothing.
• Windows VM, the CI windows recipe: 1372 passed, 0 failed.

Review and checks

• Review rounds with the correctness, spec and security lenses. The usage limit stopped the first run after 5 rounds; the restarted run did 7 more. The last round had one low, which is fixed.
• cargo fmt --check, clippy and cargo xwin clippy: clean.
• cargo test --workspace: 1740 passed, 0 failed.
• Mutation sets: 145 runs, all fail their tests as expected. Mutations made stale by later rounds were refitted to the current code.

Known limits

• The desktop app has no remove button for a center's capability; the owner uses cap rm --center. Its switches work there.
• Refused settings writes are not audited, as before for every refused settings write.

🤖 Generated with Claude Code