Track B Phase 4 (CR-9) — the Plans section (request-scoped, distinct from grants)

2026-06-21

capability-grantsliaisongovernance-dashboard

LOCKSTEP TRACEABILITY MATRIX --- api_endpoints: ["GET /auth/governance/plans"] sdk_methods_updated: ["none — dashboard JWT surface"] mcp_tools_updated: ["none"] ---

What We Built

The dashboard now has a Plans section, fed by GET /auth/governance/plans. Liaison plans are request-scoped ephemeral authority bound to an open liaison session — and the section says exactly that, in its own card, with copy that distinguishes them from durable Grants: "Plans are request-scoped ephemeral authority bound to a liaison session — not durable grants." This is the design's R11 taxonomy made literal: plans are never styled, chipped, or statused like grants.

Each liaison renders its id, status, intent summary, cost (spent / cap), and the plans it has minted (plan id + the model/tool scope each permits).

Why It Matters

The "Plans vs Grants vs Delegation" distinction is load-bearing: a plan is a single request's negotiated scope that evaporates when the liaison closes, while a grant is durable, delegable authority. Collapsing them in the UI would teach operators a wrong mental model of how authority actually flows. Phase 4 gives plans their own honest home.

How It Works

A new listByTenant(tenantId, limit) on the singleton LiaisonStore iterates its sessions (via the LruMap.values() iterator) and filters by tenant_id — the same isolation discipline the store's update() uses, since one process holds every tenant's sessions. The route projects each session + its plans read-only; the frontend renders a distinct section over authFetch.

The Numbers

  • 1 new JWT route; 1 store method + tenant-isolation test; the Plans section mounts as a distinct card. 9,031 backend + 389 dashboard tests pass; pnpm check green.

Competitive Edge

Modeling — and _showing_ — the difference between an ephemeral per-request plan and a durable cryptographic grant is something only a platform that actually has both can do. It's the authorization plane's taxonomy, surfaced honestly rather than flattened into "permissions."

Lockstep Checklist

  • [x] API Routes: GET /auth/governance/plans; LiaisonStore.listByTenant.
  • [x] TS/Python SDK / MCP: none — dashboard JWT surface.
  • [x] Generated contract: docs/openapi.yaml + static-assets regenerated.
  • [x] Tests: store tenant-isolation test; full suites green.

Track B status

With Phase 4 shipped, Track B is complete except CR-2 (per-request cohort divergence) and CR-4 (scope-check composer) — the two pieces the design flags as needing a cohort-state route and a composer refactor respectively. Phases 1, 2, 4 and the bulk of Phase 3 (CR-1 badge + ledger, CR-3 would-deny, CR-5 effective-state, CR-7 events + live feed) are live.