id: design: capability observability surface — granted sets, used sets, diffs over time, per audience #6017

Activity

1. dezren39

   added

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   priority/normalOrdinary priority (the default)Ordinary priority (the default)

   app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)

   on Nov 5, 2026
2. developing-today commented on Nov 5, 2026

   

   developing-todayBot

   on Nov 5, 2026 – with developing.today

   Contributor

   More actions

   CODE-1683
3. dezren39

   added

   kind/designA design proposal (design-architect): multi-step, phased, decision-bearingA design proposal (design-architect): multi-step, phased, decision-bearing

   queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

   task/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   and removed

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   on Nov 5, 2026
4. 116 remaining items

   Load more

5. dezren39 commented on Nov 6, 2026

   

   dezren39

   on Nov 6, 2026

   MemberAuthor

   More actions

   🤖 Agent note · handed off

   • Agent: repo queue worker, lane code-d (repo-worker-code)
   • Session / ID: cron repo-queue-worker-shift-d run 2026-11-05 22:08 CST; task 10547
   • Found via: claimed task 10547 this shift; execution-lane assignment returned opencode
   • Task: task 10547 for issue id: design: capability observability surface — granted sets, used sets, diffs over time, per audience #6017 (triage, attempt 6/6). Fresh check via gh: issue id: design: capability observability surface — granted sets, used sets, diffs over time, per audience #6017 is OPEN, no hard-stop labels (held / user/owned / do-not-merge / do-not-auto-edit). Handed off to the opencode claimant — the claimant launches the bound opencode session; this lane does not work it directly.
   • Expectation: claimant session drives task 10547 to a terminal state.
   • Links: task 10547 · issue id: design: capability observability surface — granted sets, used sets, diffs over time, per audience #6017
6. dezren39

   added

   queue/parkedQueue task is parked (waiting on CI, time, or an event)Queue task is parked (waiting on CI, time, or an event)

   status/parkedDeliberately paused with a recorded resume conditionDeliberately paused with a recorded resume condition

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   and removed

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/parkedDeliberately paused with a recorded resume conditionDeliberately paused with a recorded resume condition

   queue/parkedQueue task is parked (waiting on CI, time, or an event)Queue task is parked (waiting on CI, time, or an event)

   on Nov 6, 2026
7. dezren39 commented on Nov 6, 2026

   

   dezren39

   on Nov 6, 2026

   MemberAuthor

   More actions

   🤖 Agent note · picked up

   • Agent: queue worker (repo-worker-code), lane c8b9355e-319a-4640-8096-7ad19480d151 (OpenChamber scheduled lane; OpenCode execution)
   • Session / ID: task 10547
   • Found via: atomic queue claim; fresh REST checks
   • Task: task 10547 (triage/design) for issue id: design: capability observability surface — granted sets, used sets, diffs over time, per audience #6017. Issue id: design: capability observability surface — granted sets, used sets, diffs over time, per audience #6017, parent id: design: capability model — requested vs discovered-used sets, registry listing, custom-compiled platforms #5958, and programme id: design program: worlds — advanced Roc libraries, capabilities, permissions, dynamic user functions, licensing (2026-11-04 brief) #5955 are open; no hard-stop labels or competing active PR found. Current id: design: capability model — requested vs discovered-used sets, registry listing, custom-compiled platforms #5958 registry decisions will be treated as authoritative; if its schema is unsettled, the matrix will name its assumptions rather than silently extend it.
   • Expectation: cross-check sibling inputs and post the audience×surface matrix plus queryable capability-diff history on this issue; then complete task 10547.
   • Links: task 10547 · issue id: design: capability observability surface — granted sets, used sets, diffs over time, per audience #6017 · registry issue id: design: capability model — requested vs discovered-used sets, registry listing, custom-compiled platforms #5958
8. dezren39 commented on Nov 6, 2026

   

   dezren39

   on Nov 6, 2026

   MemberAuthor

   More actions

   Proposed audience × surface matrix

   This is a read/query view contract, not a replacement capability model. The live #5958 issue settles the key distinction as requested versus discovered-used, but does not yet publish canonical field names or a complete registry schema. Keep those names provisional until #5958 settles them. Also preserve its C2 ruling: isolated/no-filesystem/no-network remains the default; additional file/network capability is opt-in, off by default on servers, first-party-published for now, and designed so a future general-enablement decision remains possible.

   One distinction the views must make explicit: requested is not granted. Show the world-requested set, the analyzer-derived used set, and the effective server/admin grant as separate facts. A requested capability may be denied; a derived-used capability does not itself authorize use.

   Surface	Users (before/during connection)	World authors (their own worlds)	Server admins
   Requested capabilities and effective grant	Requested set for the exact release; separately show granted/denied/conditional effective state, scope, and the policy reason. Do not label the request itself as a grant.	Requested set by release, with the effective policy outcome where known; highlight declarations that appear broader than the derived-used set.	Requested set and effective grant side by side, including grant scope and the policy/default that produced it.
   Derived-used set and certification	Show the derived-used set for the connected release, attributed to the world or dependency where useful. If derivation is absent or invalidated, show unknown / not certified and why, never an empty set that looks like “uses nothing.”	Show transitive library footprint and capability origins, plus certification status, analyzer/input version, and the reason for any uncertified result. Consume #5998/#6000 policy; do not redefine which language features invalidate certification.	Per-world derived-used set and certification status; make uncertified worlds filterable and visibly distinct from certified worlds. Do not treat an uncertified result as safe.
   Changes over time	Since the user’s last-seen registry revision: requested, effective-grant, and derived-used changes separately. Use #5999’s user-meaningful capability classes for re-approval; a used-set change under an unchanged request is visible but is not silently turned into a new grant.	Compare releases/revisions; show added/removed requested and used capabilities, dependency-origin changes, and certification transitions.	Audit changes to requests, effective grants, derivation/certification, and policy for a world or across the server; filter by time, world, and change kind.
   Inherited library footprint	Concise summary of capability contribution from included libraries, sufficient to explain why the world’s footprint differs from its own direct declarations.	Expand each transitive library and its contribution/origin; retain the aggregate world set while allowing drill-down.	Aggregate and drill down by world and dependency origin; use the same derived set and provenance as the author view.
   Grants in force and inventory	For the selected world, show what the server currently permits and the scope of that decision before the user connects.	For each owned world, show the request and known deployment grant outcome; do not imply authors can grant server authority.	Fleet inventory by world, requested/used capabilities, certification, and effective grant; show who/what policy supplied each in-force grant and its scope.
   Moderation-pack provenance	Show the active pack/version and user-visible policy effect when relevant, separate from capability grants.	Show the pack/version attached to each authored world and its configured local parameters/overrides.	Show pack id/version, publisher/signature status, preset, subscribed feed ids/versions and freshness, plus local overrides/exemptions. Consume the data-only pack and signed/versioned-feed inputs in #6005/#6006; moderation provenance is not itself a capability.

   History as queryable registry facts

   The current view should be the latest projection of revisioned facts, not the only retained state. At minimum, a history query needs a world id, monotonically ordered registry/release revision, event time, event kind, and references to the prior/current values (or normalized deltas) for requested, derived-used, certification, and effective grants. Record the catalog/schema and analyzer versions needed to interpret those facts; include actor/policy provenance for grant changes. Moderation-pack/feed version changes can be recorded as a separate provenance event. Sets should use stable capability ids, with display labels resolved for the requested catalog version.

   Queries should support current state, a revision/time range, and “since revision X,” so #5959’s reconnect notice can ask for exactly the changes since a client last saw the world. The user’s last-seen cursor belongs to the notice/connection state, not in the world’s capability facts. Access must follow the audience scopes above: users only for worlds they may inspect/connect to, authors only their own worlds, and admins within their server authority. Retention policy is not specified here.

   Boundary with #5958

   This proposal does not change the requested-vs-discovered-used model, capability vocabulary, compilation ceiling, or default/opt-in posture. The one explicit extension point is history: if #5958 settles a current-entry-only schema, observability needs an append-only revision/event history (or equivalent queryable snapshots) keyed to that schema. That is a schema decision for #5958 to accept or reject; this issue must not silently fork its registry. Exact field names and diff classifications remain owned by #5958 and #5999 respectively.
9. dezren39

   removed

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   on Nov 6, 2026
10. dezren39 commented on Nov 6, 2026

    

    dezren39

    on Nov 6, 2026

    MemberAuthor

    More actions

    🤖 Agent note · done

    • Agent: queue worker (repo-worker-code), lane c8b9355e-319a-4640-8096-7ad19480d151 (OpenChamber scheduled lane; OpenCode execution)
    • Session / ID: task 10547
    • Found via: queue claim; fresh REST verification
    • Task: task 10547 completed as triaged. Posted the audience×surface matrix and queryable revision-history proposal in comment #6677119951. It preserves id: design: capability model — requested vs discovered-used sets, registry listing, custom-compiled platforms #5958’s model and C2 posture, distinguishes requested/derived-used/effective-grant facts, and explicitly leaves any history-schema extension for id: design: capability model — requested vs discovered-used sets, registry listing, custom-compiled platforms #5958 to accept or reject.
    • Expectation: no implementation or PR; the design artifact is on this issue for the parent capability-model design to reconcile.
    • Links: task 10547 · issue id: design: capability observability surface — granted sets, used sets, diffs over time, per audience #6017 · matrix comment #6677119951