id: design: provider discovery & negotiation protocols (from #5686) #5899

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-1582
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 — discovery layers in the wild (OS registries, MCP registry, wasmCloud link definitions) and the replicon interest-management analogue in §4.3. 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

   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
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-c
   • Session / ID: task 10301
   • Found via: queue claim
   • Task: Triage issue id: design: provider discovery & negotiation protocols (from #5686) #5899 (provider discovery & negotiation protocols 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, scope the design path, record blockers/ordering.
   • Expectation: s — triage complete with evidence and ordering recorded on issue id: design: provider discovery & negotiation protocols (from #5686) #5899; no implementation in this task.
   • Links: parent issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686; programme epic epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056; field survey issue id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931
6. 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-c
   • Session / ID: task 10301
   • Found via: queue claim
   • Task: Triage of issue id: design: provider discovery & negotiation protocols (from #5686) #5899 complete — findings below.
   • Expectation: done for task 10301 (triage); the design work itself remains open on issue id: design: provider discovery & negotiation protocols (from #5686) #5899, ordered after its parent.
   • Links: parent issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686; programme epic epic: ID platform expansion — apps, comms, currency, hosting, boards (2026-10-28 directive, LIST 6–15) #2056; field survey issue id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931

   Triage findings (task 10301, verified 2026-11-05)

   • State verified fresh: issue id: design: provider discovery & negotiation protocols (from #5686) #5899 is OPEN, labels at claim were task/triage, queue/queued, app/id — no hard-stop labels (held, user/owned, do-not-merge, do-not-auto-edit) and no user/review/user/escalated. No PR or branch owns this work.
   • What this is: a follow-on design ticket from issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686, filed 2026-11-04 in the WS-F gap pass. Its deliverable is a recorded decision — visibility/minimisation rules, negotiation shape, and stale-provider handling for capability providers — not code in the first instance.
   • Useful input already present: Drew's 2026-11-05 comment on issue id: design: provider discovery & negotiation protocols (from #5686) #5899 points to the field survey in issue id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931, whose §6.7 covers discovery layers in the wild (OS registries, MCP registry, wasmCloud link definitions) and §4 covers the replicon interest-management analogue. That survey is an input to this design, not a substitute for its decision record.
   • Blocker / ordering (recorded per acceptance): parent issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 (client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web) is still OPEN and undecided; it fixes the single capability-provider model — declaration, discovery, negotiation, least-privilege grants. Issue id: design: provider discovery & negotiation protocols (from #5686) #5899's own body states the parent carries the surrounding decisions this ticket must not re-decide, and that implementation timing is a separate decision, possibly months out. Discovery/negotiation protocol design presupposes the parent's provider model — designing it first would silently fork the parent's decisions, which the ticket explicitly forbids.
   • Scoped path once unblocked: (1) parent issue design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 records its provider-model decision; (2) this design, using issue id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931's survey as evidence, settles visibility/minimisation rules, negotiation shape, and stale-provider handling, recording alternatives rejected and the invariants implementation must hold, per the ticket's decision-record requirement; (3) implementation splits are filed as separate linked issues rather than growing this one, as the ticket instructs.
   • Disposition: triaged, left OPEN pending the parent decision. No code change, no PR, and no duplicate design/implementation issue filed in this pass.
7. 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 5, 2026
8. github-actions

   assigned

   dezren39

   on Nov 5, 2026