Repository navigation
id: device.info capability — device capability manifest for interface adaptation (#2027) #2338
Description
Follow-up from the capability taxonomy v0 investigation (#2027, record: doc/2026-10-29T14-05-00Z_investigation_capability_taxonomy/, PR #2337).
Goal
Add a device.info capability to pkgs/id/src/world_caps.rs returning the device's capability manifest (display kind/size/colours, input keys/encoder/pointer/text_entry, sensors with accuracy, audio in/out, transport class), so a world program can adapt one model to web, ESP32 and text/agent devices instead of rendering blind.
Why first
Every other interface capability in the taxonomy is conditional on it. It is deliberately a capability, not a surface field, so a program asks when it cares.
Scope
- New catalog name
device.info(append-only CATALOG rule; existing 17 names unchanged; noWANTS_VERSIONbump — v1 already admits new names). - Manifest value shape per taxonomy §3.1:
{manifest:{v:1}, display, input, sensors, audio, network}. - One-shot request only; the manifest is node-local, journaled, unsigned — same trust rule as other grants.
- Per-device caching by the adapter; a program must never be able to make the device re-enumerate for free.
- Refusal:
unknown_capif the node cannot describe itself.
Acceptance
device.infoin CATALOG, provider in the world actor, and a test asserting the manifest round-trips and that an unknown manifest version is refused.- Program-side helper (Roc or plain JSON) documented in the module header alongside the existing wants example.
- No change to existing capability semantics.
Out of scope
form.*, loc.*, media.* (separate follow-ups), MQTT transport (separate follow-up).
Acceptance criteria
-
device.infois in the world_caps CATALOG (append-only; existing 17 names unchanged, no WANTS_VERSION bump) with a provider in the world actor - A test asserts the manifest round-trips and that an unknown manifest version is refused (
unknown_capwhen the node cannot describe itself) - Program-side helper (Roc or plain JSON) documented in the module header alongside the existing wants example
- No change to existing capability semantics; per-device adapter caching means a program cannot force free re-enumeration
Activity
developing-today commentedon Oct 29, 2026
CODE-1183
dezren39 commentedon Oct 29, 2026
Intake review
Related: parent investigation #2027 (record: PR #2337); siblings #2338-#2345 are the other taxonomy follow-ups
Notes: Filed 2026-10-29T14:04Z as a follow-up of the #2027 capability-taxonomy investigation. Still live: no open or merged PR implements it (open-PR snapshot checked this run). The taxonomy calls this the gating capability — every other interface capability is conditional on the manifest.
Risks: Manifest shape drift across adapters would silently break adaptation logic; the version-refusal test is the guard.
Suggested approach: Implement first among the #2338-#2345 family: CATALOG entry + world-actor provider + round-trip/version tests, then the header helper doc.
🤖 Agent note · filed
meta/enrichedapplied. Still-live check this pass: no merged PR or fix commit explicitly resolving this issue was found; where a queue triage task owns verification, it is named in the notes.developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 6820 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 3, 2026
agent-note:v1\nstate: picked-up\ntask: 6820\nworker: repo-worker-code\nlane: 8ac61616-3815-4e7b-b33d-840a3829154a\nat: 2026-11-03T22:02:22Z\nnext: Verify current main and related PRs, then disposition issue #2338 and notify dependent task 5770.
dezren39 commentedon Nov 3, 2026
agent-note:v1\nstate: triaged\ntask: 6820\nworker: repo-worker-code\nlane: 8ac61616-3815-4e7b-b33d-840a3829154a\nat: 2026-11-03T22:15:06Z\n\nVerdict: still valid, explicitly deferred to v1.1; not implemented and not closed. Fresh current main is e425b6a: is absent from the world_caps CATALOG and Rust source; a fresh PR search found no implementing PR. The controlling #2028 v1 design is on main and #2028 is closed; §§1, 7 explicitly limits v1 to app packaging, #2340 Form, #2339 text/1, and web binding, while deferring #2338-#2345 wholesale.\n\nNo #2338 implementation task is enqueued by this triage: the capability remains valid future hardware/device work, not current v1 scope.\n\nDependency finding: #2340 / task 5770 remains parked. Its issue acceptance and packet still gate Form on #2338, which conflicts with the controlling #2028 v1 sequence. Reconcile #2340's acceptance/packet before task 5770 resumes; this note does not claim the device capability exists.\n\nLinks: #2028, #2340, PR #3909; source checked on main e425b6a.
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged
task: 6820
worker: repo-worker-code
lane: 8ac61616-3815-4e7b-b33d-840a3829154a
at: 2026-11-03T22:17:00Z
Correction and complete disposition (supersedes the formatting of my previous note):
Verdict: #2338 remains valid future work, explicitly deferred to v1.1; not implemented and not closed. Fresh current main is e425b6a. The Rust world_caps CATALOG and source contain no device.info implementation; a fresh GitHub PR search found no implementing PR.
The controlling #2028 v1 design is on main, and #2028 is closed. The record at doc/2026-11-01_design_id2028.md, sections 1 and 7, limits v1 to app packaging, #2340 Form, #2339 text/1, and web binding; it explicitly defers #2338-#2345 wholesale. No #2338 implementation task is enqueued by this triage; keep the issue open for later device/hardware scope.
Dependency finding: #2340 / task 5770 remains parked. Its issue acceptance and packet still gate Form on #2338, conflicting with the controlling #2028 v1 sequence. Reconcile #2340 acceptance and packet before task 5770 resumes. This does not claim the device capability exists.
Links: #2028, #2340, PR #3909. Source checked on main e425b6a.