id: design: provider declaration model (from #5686) #5898

Activity

1. dezren39

   added

   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-1581
3. dezren39 commented on Nov 5, 2026

   

   dezren39

   on Nov 5, 2026

   MemberAuthor

   More actions

   Field survey filed: #5931 (capability-provider research widening, per Drew's 2026-11-04 ruling) covers the current option space relevant to this issue in §6.7 + §6.2 — declaration surfaces in the wild: MCP tools/list, AppFunctions' OS registry, WebMCP registration, WIT interfaces, Matter clusters, set against the manifest model. It is an inventory, not a decision — the section ends with the open questions this design needs to answer.
4. dezren39

   added

   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

   on Nov 5, 2026
5. dezren39 commented on Nov 5, 2026

   

   dezren39

   on Nov 5, 2026

   MemberAuthor

   More actions

   🤖 Agent note · picked up

   • Agent: queue worker (repo-worker-code), lane code-v
   • Session / ID: task 10300
   • Found via: queue claim
   • Task: Triage issue id: design: provider declaration model (from #5686) #5898 (provider declaration model design, from issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686) at current main — verify state, dependencies, and route.
   • Expectation: effort s; done = findings posted with ordering/blockers, task 10300 completed as triaged.
   • Links: n/a
6. dezren39

   added

   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

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

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

   

   dezren39

   on Nov 5, 2026

   MemberAuthor

   More actions

   🤖 Agent note · done

   • Agent: queue worker (repo-worker-code), lane code-v
   • Session / ID: task 10300
   • Found via: queue claim
   • Task: Triage complete for issue id: design: provider declaration model (from #5686) #5898.
   • Expectation: done as below.
   • Links: parent issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686, survey issue id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931, epic issue epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056

   Triage — task 10300, issue #5898 at 2026-11-05

   Verified live (fresh gh reads this shift):

   • Issue id: design: provider declaration model (from #5686) #5898 is OPEN, labels task/triage, app/id only — no hard-stop labels (held, user/owned, do-not-merge, do-not-auto-edit), no competing PR/branch named.
   • Parent issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 ("design(id): client-side capability providers") is OPEN, kind/design, effort/l — its core provider-model decision is not yet recorded, so issue id: design: provider declaration model (from #5686) #5898 must not silently fork it (per its own body).
   • Field survey issue id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931 is OPEN (kind/design); Drew's comment on issue id: design: provider declaration model (from #5686) #5898 (2026-11-05T03:03Z) already linked it: §6.7 + §6.2 inventory declaration surfaces (MCP tools/list, AppFunctions registry, WebMCP, WIT, Matter clusters) against the manifest model, ending in the open questions this design must answer. It is inventory, not a decision.
   • Epic issue epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056 is OPEN.

   Routing / ordering:

   1. Issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 parent decision first (single capability-provider model: declaration / discovery / negotiation / least-privilege grants).
   2. Then synthesise issue id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931's survey into this ticket's options.
   3. Then this design settles: manifest contents, signing, versioning, and dynamic vs static capabilities — closing with a recorded decision (chosen shape, rejected alternatives + why, invariants for implementation), per its "Decision record expected" section. If it splits further, file/link splits rather than growing this issue.

   Not a code fix: no implementation is scoped or safe before that decision record; the issue body itself says implementation timing is a separate decision, possibly months out. No small_fix is enqueued — enqueuing implementation now would be premature. Issue #5898 stays OPEN as a design ticket under epic issue #2056.

   Outcome for task 10300: triaged.
8. dezren39

   removed

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

   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
9. github-actions

   assigned

   dezren39

   on Nov 5, 2026