# Research And Design Gaps Backlog This file tracks important OS design, development, and user-story areas that are absent, thinly covered, or only indirectly owned by existing capOS proposals. It is a triage register, not an execution queue. Listing a gap here does not change the selected milestone in `WORKPLAN.md` and does not mean the project should immediately create a full proposal. Promote an entry out of this file only when a visible milestone, paper evidence gap, review finding, or explicit user direction makes the area actionable. Promotion targets: - `docs/research/` for prior-art survey or external precedent. - `docs/proposals/` for a concrete reviewed design direction. - A focused `docs/backlog/` file when the design is accepted enough to decompose implementation. - `docs/design-risks-register.md` when the gap is an active architectural risk with an owner. ## Status Vocabulary - **Uncovered**: no owned design exists yet. - **Thin**: mentioned indirectly, but no coherent owner or decision record. - **Backlog-only**: task decomposition exists without a full proposal. - **Research-needed**: design should not start before prior-art review. - **Ready-for-proposal**: enough constraints exist to draft a proposal. - **Deferred**: intentionally future work, not a near-term blocker. - **Rejected**: considered and explicitly not pursued. ## Promotion Checklist Before creating a proposal from an entry here: - Identify the visible user or operator outcome the work would enable. - List existing capOS docs that already partially cover the area. - List the `docs/research/` files actually read, or explain why no research file applies. - Decide the first capability boundary or trust boundary that must be designed. - Define one QEMU, host-test, documentation, or review gate that would prove the proposal made progress. ## Display, GUI, And Input Status: Uncovered. User story: a user boots capOS on a desktop, laptop, or remote graphical session and uses multiple graphical apps with keyboard, pointer, clipboard, accessibility, and app isolation. Current coverage: browser, browser/WASM, agent, GPU, and shell proposals point toward future visual sessions, but there is no native display server, compositor, input routing, window authority, clipboard, screenshot, or accessibility model. Missing decisions: - Display ownership and framebuffer/GPU authority. - Compositor trust boundary and per-window capability model. - Keyboard, pointer, touch, IME, and focus authority. - Clipboard and drag/drop data-transfer policy. - Screen capture and remote desktop authority. - Accessibility-service authority and privacy boundaries. Research needed: - Genode GUI/session routing and report-ROM style composition. - Wayland compositor security model and clipboard limitations. - Fuchsia Scenic/input pipeline if the native GUI track becomes near-term. - seL4/CapROS precedents for trusted path or secure attention, if applicable. Promote when: native graphical sessions, browser UI, desktop app isolation, or rich web/agent interaction becomes a selected milestone. ## Driver Framework And Hotplug Status: Thin. User story: an operator plugs in a device, capOS identifies it, starts or restarts the correct isolated driver, and exposes only the intended typed capabilities. Current coverage: `docs/dma-isolation-design.md`, `docs/backlog/hardware-boot-storage.md`, networking, storage, cloud, and GPU proposals cover pieces of device work. There is no general driver framework for discovery, binding, isolation, recovery, firmware, or hotplug. Missing decisions: - Device discovery authority and driver matching policy. - Driver process lifecycle, crash restart, and stale handle behavior. - Firmware loading and firmware provenance. - Hotplug attach/detach semantics. - Interrupt, MMIO, DMA, and power authority handoff. - User-space driver SDK boundaries and test harnesses. Research needed: - Genode driver components and session routing. - Zircon/Fuchsia driver framework concepts. - Linux VFIO/uio and userspace-driver isolation tradeoffs. - seL4 device-driver partitioning examples. Promote when: userspace NIC, block-device, USB, GPU, or real hardware bring-up requires reusable driver lifecycle rules. ## Power, Suspend, Resume, And Thermal Policy Status: Uncovered. User story: a laptop or VM can sleep, wake, preserve sessions, and report power or thermal limits without leaking stale authority or corrupting timers. Current coverage: tickless scheduling covers timer cleanup and idle mechanics, but not power management as an OS product area. Missing decisions: - Suspend/resume authority and system-wide quiesce protocol. - Wake-source capabilities and audit. - Battery, charger, lid, and thermal sensor surfaces. - CPU frequency, C-state, and thermal-throttling policy. - Timer and network behavior across sleep. - Session and service liveness after resume. Research needed: - ACPI power-state model and Linux suspend blockers/wakeup sources. - Fuchsia power framework if relevant. - Genode power-management patterns for component systems. Promote when: laptop hardware, cloud hibernation, low-power idle, or interactive remote-shell reliability needs sleep/resume semantics. ## Time, Clock, And Trusted Timestamp Services Status: Thin. User story: services can distinguish monotonic time, wall-clock time, and trusted audit time, and cannot silently forge system time. Current coverage: scheduler and tickless proposals mention clocks, timers, deadlines, and clocksource/clockevent split. There is no user-facing time authority model. Missing decisions: - Monotonic, boot, realtime, and coarse clock capability surfaces. - Who can set wall-clock time and how changes are audited. - NTP/PTP/cloud-metadata time synchronization authority. - Timezone and locale data ownership. - Leap-second and clock-step behavior. - Timestamp trust level carried into audit records. Research needed: - Linux clock ids, adjtimex/NTP discipline, and time namespaces. - Fuchsia clock objects and UTC maintenance. - Cloud metadata time and attestation interactions. Promote when: audit log completion, TLS certificate validation, distributed services, or durable storage needs trusted timestamp semantics. ## Software Installation, Packages, And Rollback Status: Thin. User story: a user or operator installs an app, inspects requested authority, updates it, rolls it back, and removes its state without ambient filesystem assumptions. Current coverage: repository composition, storage/naming, userspace binaries, live upgrade, cloud deployment, and public-release proposals cover adjacent pieces. There is no package/app distribution model. Missing decisions: - Package manifest schema and authority-request review. - Signed repositories, update channels, and revocation. - Dependency resolution and build provenance. - App install/remove lifecycle and state ownership. - Rollback, staged rollout, and compatibility policy. - Vulnerability advisory and emergency update workflow. Research needed: - Nix/Guix, OSTree, Flatpak portals, Android package permissions, and Fuchsia package/update system. - Supply-chain signing systems such as TUF/in-toto/Sigstore if this becomes release-critical. Promote when: capOS needs installable demos, sibling repositories, public release, or cloud image update flow. ## Crash Recovery, Supervision, And Diagnostics Status: Thin. User story: a service crashes; init or an authorized supervisor restarts it or enters a known degraded mode without leaking authority, hiding the cause, or looping forever. Current coverage: service architecture already sketches `SpawnRequest` restart policy, supervisor-owned respawn, and always/on-failure restart modes; `libcapos-service` covers service lifecycle pieces; live-upgrade planning ties fault containment to supervisor respawn; and system monitoring covers logs/metrics/crash records at a high level. Crash-loop budgets, core/minidump capture, degraded-mode semantics, watchdog policy, and stale/in-flight cleanup are still not owned as one recovery design. Missing decisions: - Restart policy authority and failure budget. - Crash-loop backoff and operator override. - Core dump or minidump capture with capability redaction. - Watchdog and health-check capabilities. - Degraded boot and emergency shell semantics. - Stale capabilities and in-flight calls after service death. Research needed: - Erlang/OTP supervision trees, systemd restart policy, Kubernetes probes, and Fuchsia component lifecycle. - Capability-system precedent for crash propagation and service replacement. Promote when: shared services, remote shell, storage, or agent workloads need production-grade recovery behavior. ## Backup, Restore, Snapshots, And Migration Status: Thin. User story: an operator loses a disk or VM and restores users, services, keys, and app state while avoiding stale authority and accidental data disclosure. Current coverage: storage/naming, cloud deployment, and the hardware/boot/ storage backlog already cover narrower pieces: user-owned encrypted save transport, fake Drive/Firebase restore rejection tests, rollback/stale handling, and cloud-backed snapshot material. System-wide disaster recovery for users, services, keys, machine identity, and authority state is still not owned as one design. Missing decisions: - Snapshot capability boundary and consistency protocol. - Encrypted export/import and restore identity. - Key recovery and disaster recovery drills. - Partial restore and per-service state ownership. - Backup retention, deletion, and privacy policy. - Migration between machines or cloud instances. Research needed: - ZFS/Btrfs snapshot semantics, Borg/Restic encrypted backup models, and cloud snapshot/key-management practices. - Capability-specific concerns from EROS/CapROS persistence if applicable. Promote when: writable storage, durable local accounts, volume encryption, or cloud deployment becomes near-term. ## Human-Facing Administration And Explainability Status: Thin. User story: an operator can answer who has access to a service, why, since when, what will happen if access is revoked, and why a request was denied. Current coverage: shell, system info, local users, system monitoring, configuration, and security proposals cover pieces. There is no unified administrator UX or policy explainability track. Missing decisions: - Account and role management commands or UI. - Grant inspection, diff, revoke, and dry-run behavior. - Denial explanation format across kernel, broker, and services. - Audit search and incident timeline views. - Diagnostics bundle generation and redaction. - Safe repair workflow for broken configuration or policy. Research needed: - Kubernetes RBAC `can-i`/audit practices. - Cloud IAM policy simulators and access-analyzer tools. - Genode configuration/reporting UX for component graphs. Promote when: local users, ABAC/MAC, remote shell, or operator configuration needs day-2 administration rather than proof-only commands. ## Developer Debugging, Profiling, And Tooling Status: Thin. User story: a developer writes a capOS service, runs it locally, debugs a failed capability call, profiles it, and ships it with reproducible evidence. Current coverage: harness engineering, benchmarks, generated-code checks, run-targets, and the paper evidence track cover pieces. There is no full debugger/profiler/developer-tooling proposal. Missing decisions: - Debug authority and process attach policy. - Symbols, stack traces, crash dumps, and source maps. - Ring/syscall/capability-call tracing. - Service schema explorer and request replay tooling. - Guest profiling, flamegraph, and benchmark attribution workflow. - App/service templates and local developer SDK. Research needed: - GDB remote protocol, Linux `perf`/eBPF-style tracing boundaries, Fuchsia diagnostics, and seL4 debug authority practices. Promote when: non-trivial third-party services, public release, or performance claims need repeatable developer workflows. ## Compatibility And App Porting Strategy Status: Thin. User story: a developer ports a small existing CLI or server to capOS and knows which Unix assumptions work, fail, or require explicit capability adapters. Current coverage: userspace binaries, Go, Lua, POSIX adapters, WASI, C/C++, and language-runtime proposals mention porting targets. There is no concrete compatibility profile matrix. Missing decisions: - Minimal libc/POSIX surface and unsupported-call policy. - Filesystem, environment, argv, signal, pipe, socket, and process semantics. - Dynamic linking and shared-library policy. - WASI adapter authority model. - Build recipes and package corpus selection. - Porting report template and acceptance tests. Research needed: - WASI preview models, CloudABI history, Redox, Hermit, Fuchsia POSIX layer, and Genode libc/VFS integration. Promote when: a language runtime, POSIX adapter, or real application corpus becomes a selected milestone. ## Accessibility And Internationalization Status: Uncovered. User story: non-English users and assistive-technology users can operate capOS shells, graphical sessions, and web/agent surfaces without privileged workarounds. Current coverage: none beyond general shell/browser surface discussions. Missing decisions: - Unicode, locale, collation, and timezone data ownership. - Input methods and keyboard layout authority. - Screen reader or accessibility tree service boundary. - High-contrast, font scaling, and reduced-motion policy. - Translation and message-catalog strategy. - Accessible denial/audit messages and setup flow. Research needed: - Web accessibility platform architecture, Wayland accessibility status, Fuchsia accessibility manager, and terminal accessibility conventions. Promote when: graphical sessions, public demos, web shell, or production interactive setup becomes user-facing beyond developer/operator proof flows. ## Fleet Operations And Remote Management Status: Thin. User story: an operator manages many capOS nodes and can prove which version, policy, keys, services, and update state each node is running. Current coverage: cloud deployment, cloud metadata, system monitoring, configuration, hosted agents, and public release cover adjacent concerns. There is no fleet-management design. Missing decisions: - Node enrollment and identity bootstrap. - Remote attestation and inventory reporting. - Configuration rollout and drift detection. - Remote logs, metrics, and audit aggregation. - Staged update and rollback policy. - Break-glass access and emergency revocation. Research needed: - Kubernetes node/bootstrap models, cloud instance identity, SPIFFE/SPIRE, TPM/measured boot attestation, and OSQuery-style inventory. Promote when: cloud deployment, hosted agent swarms, public release, or remote administration becomes more than a single-node proof. ## Privacy And Data Governance Status: Thin. User story: a user can see and revoke what data a service can access, and deleted data does not unintentionally persist in logs, backups, or derived indexes. Current coverage: capability authority, session privacy, audit redaction, identity policy, storage, monitoring, and browser/agent proposals cover parts of the problem. There is no explicit data-governance design. Missing decisions: - Data classification and purpose-bound access metadata. - Retention, deletion, and legal-hold semantics. - Derived data, indexes, caches, and backup deletion behavior. - User consent and service data export. - Audit redaction versus forensic retention. - Cross-service data-sharing policy and review UX. Research needed: - Object-capability privacy patterns, GDPR-style data lifecycle controls, browser permission UX, and cloud DLP/data catalog practices. Promote when: persistent user data, browser/agent activity, hosted services, or public release introduces real privacy expectations.