Repository navigation
id: native client shells and client capabilities #538
Description
What and why
Long-term client-side work from the platform report's section 15: native shells on the same screen/input contract, and capability providers that run on the client under the ceiling model. Both are expected to land in the Phase 13 plan. Ticked when the design or research package is committed and an implementation issue exists.
Items
Each box is done when the design (or research package) is committed and an implementation issue is linked here.
- D1-054 — Native client shells (Bevy, Qt, .NET, Unity, Electron, Windows) on the screen/input contract (XL, research package)
Long-term, native shells implement the same screen and input contract for what a terminal cannot do (3D, audio, native widgets). The portable surface contract and the F12.7 conformance suite make a shell swappable.- Status: design committed and implementation issue linked (2026-11-03) — design
doc/2026-11-01_design_id788.md, implementation id: Phase 13 F13.6 native client shells on the shell contract #788 (F13.6). Native shell code itself has not landed; id: Phase 13 F13.6 native client shells on the shell contract #788 remains gated on F12.7 (id: F12.7 ABI specification and conformance suite #1064). - Source: RPT §15 'Native client shells'
- Prerequisites: id: Phase 12 designs to run through the research workflow #534 (tracking issue) — D1-025 F12.7 Versioned guest ABI spec, plaza_abi_version export, conformance suite
- Status: design committed and implementation issue linked (2026-11-03) — design
- D1-055 — Client-side capability providers (local files, GPU, network) under the ceiling model (XL, design)
Extend scopes, roles and ceilings to named, granted, ceilinged providers that run on the client, keeping the Phase 12 rule that no authority path exists outside named ceilinged providers.- Status: design committed and implementation issue linked (2026-11-03) — design
doc/2026-11-01_design_id789.md(adopted from PR design(id): #789 client-side capability providers #3828), implementation id: Phase 13 F13.7 client-side capability providers under the ceiling model #789 (F13.7, design adopted, build gated). Capability execution itself is still host-side; the catalog is hard-coded inpkgs/id/crates/id-core/src/world_caps.rs(path moved since this body was written). - Source: RPT §15 'Client-side capabilities'
- Prerequisites: id: Phase 12 designs to run through the research workflow #534 (tracking issue) — D1-022 F12.4 Capability provider registry (manifested components)
- Status: design committed and implementation issue linked (2026-11-03) — design
Source
- RPT §15 'Client-side capabilities'
- RPT §15 'Native client shells'
RPT = doc/2026-10-18T18-40-00Z_report_platform_world_state/2026-10-18T18-40-00Z_report_platform_world_state.md, REF = doc/2026-10-18T00-00-00Z_reference_platform_state/2026-10-18T00-00-00Z_reference_platform_state.md. Both are uncommitted reports in the platform-world-apps-migration worktree.
Size
XL overall
Prerequisites
Listed per item above.
Acceptance criteria
- Every item listed above has its design (or research package, where marked) committed to the repo
- Every item has a linked implementation issue, and its checkbox above is ticked only once both are true
- No item is closed out on the basis of a plan or report reference alone — the committed artifact is the evidence
Activity
dezren39 commentedon Oct 24, 2026
id train triage (2026-10-24): obsolete — superseded by #791 (Phase 13 plan): D1-054 -> F13.6 #788 and D1-055 -> F13.7 #789 now have designs and implementation issues.
dezren39 commentedon Oct 26, 2026
Intake review
Verified still live on main
14dd66b6(2026-10-26, fleet monitor). This is a Phase 13 design tracker (items D1-054 native client shells, D1-055 client-side capability providers). Nothing has been committed for either item: the only "native client shell" material in the tree is the source platform report itself (doc/2026-10-18T18-40-00Z_report_platform_world_state/), and capability execution remains host-side as the body describes. No acceptance-criteria section existed, so one has been appended to the body (original text preserved verbatim above it), following the per-item rule the body itself states.Related: both items depend on designs tracked in #534 (D1-025 F12.7 ABI/conformance, D1-022 F12.4 provider registry) — this tracker cannot move before those do.
Risks / suggested approach: priority/low and effort/l are deliberate: this is long-term work gated on #534. The failure mode to avoid is the tracker silently ageing — when a #534 design lands, the matching implementation issue should be filed and linked here in the same pass.
7 remaining items
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/low). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
Triage verdict — tracker complete, closing with evidence (queue task 7578, 2026-11-03)
This is the third triage pass on #538 (2026-10-24 superseded-by-#791 verdict, 2026-10-26 intake review, 2026-10-28 "long-term tracker, gated"), so this pass answered the question the issue itself poses rather than re-describing the gate: have both items reached "design committed + implementation issue linked"? They have.
Fresh evidence (origin/main, 2026-11-03)
doc/2026-11-01_design_id788.md✅ on maindoc/2026-11-01_design_id789.md✅ on main (adopted from PR #3828)world_caps.rs:55now lives atpkgs/id/crates/id-core/src/world_caps.rs; the oldpkgs/id/src/world.rs:2526-2547path reference is likewise stale after the crates split.Why close rather than keep open
Keeping it open has no remaining action: every item has its design committed and its own implementation issue with its own gate, and the remaining blockers are tracked on those issues. Leaving the tracker open only re-queues it for the coverage pass each sweep — this is the third triage task spent on it (#2134, #5763's sibling pass, #7578) and none could add anything new. Closing records the completion; #788 and #789 remain the live surface for the work.
No follow-up packet: nothing here is actionable beyond #788's F12.7 gate.
dezren39 commentedon Nov 3, 2026
agent-note:v1
{"kind":"done","task_id":7578,"worker":"repo-worker-code","lane":"262eb403-3347-4a7c-ba6b-e7bc263ca853","stage":"complete","outcome":"already_done","note":"Third triage pass on #538. Both items now meet the tracker's own acceptance: D1-054 design doc/2026-11-01_design_id788.md + implementation #788; D1-055 design doc/2026-11-01_design_id789.md + implementation #789. Body checkboxes ticked and stale code paths corrected, then closed as completed. No follow-up packet: remaining gates live on #788 (F12.7 #1064) and #789."}
🤖 Agent note · done
repo-worker-code), OpenChamber scheduled lane262eb403world_caps.rsmoved topkgs/id/crates/id-core/src/), and closed the tracker as completed with the evidence table above.