Capabilities¶

Lookup reference for the capability ACL: the capability id grammar, the closed capability list, full/own/none grading, the seeded role bundles, and a summary of which routes demand which capability. The identity model behind it — tokens, Margonem-ID binding, identity linking, governance data — is owned by Roles & permissions; the authoritative per-route table is API reference §7.

Id grammar¶

A capability is <resource>.<action> with an optional .own ownership suffix:

<resource>.<action>[.own]     e.g. entity.read, pu.award, player.write.own

• <resource>.all grants every action on the resource.
• admin.all grants everything — it is the machine token's implicit set and the Namiestnik/Koordynator bundle.
• X.own never silently satisfies X (see Grading).

Capability list¶

No seeded role bundle carries workflow.settle, workflow.map_checkup, sync.read, or sync.run — settlement spans distribution, currency, and PU at once, and sync is repo-level, so these resolve only through admin.all or a per-Person grant. .own grading is meaningless for repo-level sync — the handlers treat an own-only sync grant as no grant and refuse with 403. The daemon's own scheduled sync tick runs in-process and needs no token — design in Sync.

The machine token implicitly satisfies every capability (admin.all); it exists to authenticate local processes, never to sandbox the operator's shell. Capabilities scope end users reaching the daemon through the Discord/Margonem bot — token mechanics in Roles & permissions.

Grading (full / own / none)¶

When the dispatcher checks a route's required capability, the caller's grant is graded:

X.own never silently satisfies X. The caller's own subjects are their Gracz entity (by name or Margonem ID) and every Postać whose @należy_do is that Gracz.

Handler scoping for an OwnOnly caller, route by route:

So a Gracz holding pu.read.own reads their PU timeline but not another player's, and player.write.own lets them edit their own Postać but not create a second Gracz.

Role bundles¶

Roles are named bundles of capabilities — data, not hardcoded tiers. They load from committed .nerthus/data-tables/roles.json; the daemon seeds that file only when it is absent, so a Council edit survives every boot and re-init (file location and seed rule: Data tables, Configuration). The seeded defaults are also the fallback when the file is missing:

Namiestnik and Koordynator are two distinct roles with identical seeded bundles — roles.json keys them separately, so the Council can diverge them later. The bundles are independent lists, not strict supersets: the narrator bundle carries full pu.read/currency.read instead of the .own variants and omits identity.read; the radny bundle omits log.fetch.

A Person's effective set = union of their role bundles, plus per-Person grants, minus per-Person revokes (Grant-NerthusCapability / Revoke-NerthusCapability). Session tokens store only the role; capabilities are recomputed on every request, so a grant or revoke takes effect on live tokens immediately. Every externally-minted session token carries the gracz role — a Narrator's or Radny's extra powers attach to their Margonem ID as per-Person grants, or ride a named token minted with -Roles narrator.

Routes → capabilities (summary)¶

The full closed table — every route with its exact capability and Write flag — is API reference §7. The shape of the mapping:

Six routes are public (no bearer, no capability): GET /health, GET /schema, GET /routes, GET /schema/version, POST /auth/margonem, POST /auth/discord.

Election eligibility (GET /elections/eligibility) requires pu.read because eligibility is PU-derived data; a Gracz self-checks via pu.read.own. The formula and window live in PU model.