JavaScript is disabled, so the interactive overlays are unavailable. The complete catalogue is listed below.
- No Android framework layers — Shipped
- Nuxel is not an Android fork. The phone runs a Fedora 43 aarch64 userspace on Linux, with systemd, Phosh/phoc and WebKitGTK. Hardware is reached through Linux interfaces rather than an Android HAL bridge. That removes a whole class of compatibility layers from the critical path and keeps failures traceable to one stack.
- Evidence: Repository structure and release docs; documented in docs/architecture.md
- Fedora + systemd base — Shipped
- Nuxel does not hide Linux from its owner. The phone boots systemd, runs ordinary services and can be inspected with the same tools you would use on a laptop. Nuxel-specific units are layered on top of the distribution rather than replacing it, which keeps debugging and recovery conventional.
- Evidence: Boot evidence and service receipts in docs/s10plus-live-fixes-20261028.md
- Immutable updates with rollback — In progress
- The target update path writes a complete system image to the inactive slot and switches only after verification. A failed update should fall back to the slot that was already working instead of requiring a repair. RAUC bundle configuration exists for the Pixel path and OSTree tooling exists for the Fedora VM path.
- Evidence: docs/update-strategy.md, images/rauc/, images/ostree/
- One sandboxed app model — Shipped
- Mainstream apps are Progressive Web Apps rendered in WebKitGTK with per-app data and permission boundaries. Hardware-critical apps such as Phone, Messages and Contacts are native GTK4 programs. Both flavours talk to the system through nuxel-bridge and its capability model rather than direct hardware access.
- Evidence: pwa/nuxel-common/app-registry.json and per-app app.json manifests
- nuxel-bridge capability mediator — Shipped
- nuxel-bridge is the single system service apps use to reach privileged functionality. It exposes versioned JSON endpoints over a loopback HTTP bridge and a D-Bus interface, checks the caller’s capability grants, and keeps the policy in one place. That gives the system one place to audit, revoke and log access.
- Evidence: services/nuxel-bridge/src/api.py, capabilities.py and 30+ /api/v1 routes
- Capability-based permissions — Shipped
- Permissions are expressed as capabilities rather than blanket access. An app manifest lists its capabilities, the Settings app shows and edits them, and the bridge refuses calls that are not granted. Grants live outside the app sandbox so uninstalling or resetting an app does not silently preserve authority.
- Evidence: services/nuxel-bridge capability store; pwa/nuxel-apps/settings
- Defence-in-depth sandboxing — In progress
- The sandbox design does not rely on a single mechanism. A Nuxel app is meant to run inside a bubblewrap namespace with a syscall allow-list, filesystem restrictions, an AppArmor profile and per-cgroup network rules. Hardware and files are reached through portals and the bridge. The sandbox implementation and its nftables rules are in the repository and covered by tests.
- Evidence: shell/nuxel-shell/nuxel-sandbox, configs/apparmor.d, docs/security-model.md
- Everything is opt-in — Shipped
- Nuxel’s default posture is that a capability is off until the owner enables it. The Quick Settings tiles, Settings surfaces and app manifests all reflect real state rather than optimistic placeholders. Unsupported or unverified hardware reports an honest status instead of a fabricated value.
- Evidence: Settings + Quick Settings surfaces; docs/security-defaults.md
- Honest subsystem status — Shipped
- The project keeps a device capability manifest that caps every claim at the strength of its evidence record. The UI follows the same rule. A GNSS failure says BLOCKED_FIRMWARE, a missing touch device explains the charger-mode boot, and a missing USB network transport is reported as a kernel blocker — not as a connection that might work.
- Evidence: docs/beta-finalization/release/DEVICE-CAPABILITY-MANIFEST.md
- Lockscreen and preload cinema — Shipped
- The supplied startup clip plays over the real lockscreen once display, web and launcher readiness are confirmed, while normal services continue starting. Playback is bounded, one-shot and fail-open: a decode failure shows a fallback cover and a FALLBACK receipt rather than blocking the phone. The lockscreen underneath reports charging, USB, live console and file-transfer state.
- Evidence: services/nuxel-preload-cinema, pwa/nuxel-home/js/lockscreen*.js
- Global Back, Home and Recents — Shipped
- Back, Home and Recents are owned by the launcher and act on the foreground app regardless of whether that app is a PWA or a native window. Home always returns to desktop 1. Icon state is rendered deterministically so the navigation strip cannot show a stale or duplicated surface.
- Evidence: pwa/nuxel-home/js/launcher.js, app.js and bridge window endpoints
- System keyboard and haptics — Shipped
- Nuxel’s touch keyboard is part of the launcher rather than an external IME. It ships with the intended visual design and routes key feedback through the haptics daemon. Button handling covers Power, Volume and the third shortcut button, with a single writer for vibration patterns.
- Evidence: pwa/nuxel-home/js/touch-keyboard.js, services/nuxel-haptics
- Quick Settings — Shipped
- Quick Settings is not a mock. Tiles call the bridge, which calls NetworkManager, BlueZ, the radio manager or the relevant hardware provider, and the tile reflects the result. A tile that cannot act reports that honestly instead of toggling an illusion.
- Evidence: pwa/nuxel-home/index.html and bridge system endpoints
- The Nuxel app suite — Shipped
- 23 app packages live under pwa/nuxel-apps, and the canonical launcher registry that the phone UI, native shell and HTTP bridge share carries 22 of them. They span communication, productivity, media, utilities and system tools. Each app declares its capabilities, launch path and category, and the registry is checked for drift between consumers.
- Evidence: pwa/nuxel-common/app-registry.json (registry v7)
- Files explorer — Shipped
- The Files app was rebuilt as an actual file manager rather than a static list. It browses the tree the portal exposes, performs CRUD operations, copies and moves entries, creates and extracts archives, and uploads files. Access stays bounded by the portal grant.
- Evidence: pwa/nuxel-apps/files; PWNAGE-33000 release notes
- Mail — In progress
- Mail keeps messages locally and gives the owner folder navigation and compact settings. The compose and send path depends on a configured mail service; until one exists the app reports that instead of queueing a message that can never leave the device.
- Evidence: pwa/nuxel-apps/mail and services/nuxel-bridge/src/mail_client.py
- Camera — Blocked
- The app presents camera controls and honest hardware status, but it does not claim a working viewfinder or photo capture. The remaining work is the camera backend on the vendor kernel, which is not part of the current release.
- Evidence: shell/nuxel-camera-native; release blocker list
- Gallery and Recorder — In progress
- Gallery browses, renames and plays media from the shared camera-gallery store. Recorder provisions audio capture and writes a real WAV file to the user home; when no capture path is available it reports that instead of producing a silent file. Microphone acceptance is still an owner test.
- Evidence: pwa/nuxel-apps/photos and recorder
- Terminal and nuxel-zsh — Shipped
- Terminal opens a local PTY through the launcher host — no remote shell is required. The nuxel-zsh package adds four selectable prompt themes, a persistent system and per-user configuration, a nuxel-theme command, a canonical /etc/banner and safe non-interactive handling. Bash and recovery access remain available.
- Evidence: pwa/nuxel-apps/terminal, services/nuxel-zsh
- Settings control surface — Shipped
- Settings is the real control surface, not a mock. It exposes display and orientation, Wi-Fi scanning and connection, Bluetooth management, audio and haptics, button mapping, location and maps, and a developer view with boot diagnostics. Each control calls the same bridge used by the rest of the system.
- Evidence: pwa/nuxel-apps/settings (HTML, hardware-settings.js, wifi/bluetooth/location models)
- Notifications — Shipped
- org.nuxel.Notifications runs on the system bus and stores live and historical notifications in one canonical JSON file, capped and evicted oldest-first. The Phosh agent relays them to the desktop notification interface. The bridge exposes send endpoints to apps that hold the relevant capability.
- Evidence: services/nuxel-notifications, services/nuxel-portal
- Clock, Calendar and Tools — Shipped
- The utility set works offline where possible and declares the capabilities it needs where it does not. Maps uses OpenStreetMap tiles with attribution and an offline tile cache, Weather supports manual records plus an opt-in source, and SnekByte is a complete offline game. Tools such as DevMgmt, Root & Sudo, Authenticator and Safe Cleanup are included in the same registry.
- Evidence: pwa/nuxel-apps/* and app-registry.json
- Storage and file transfer — In progress
- The USB connection mode is explicit. Selecting File Transfer transitions the storage state machine and refuses unsafe raw exports; the lockscreen shows the real mode and a transfer indicator. The phone reports the genuine transport state rather than claiming that a host can already mount it.
- Evidence: services/nuxel-bridge/src/system_indicators.py, usb_mode.py
- Tri-link access — In progress
- Nuxel exposes three phone-side console panels. The Serial Live Console is a framed root recovery console over USB CDC-ACM. The Wi-Fi SSH Console uses the phone’s current address and a pinned host key. The USB SSH Console is implemented but truthfully reports a kernel blocker on the 4.14.253 NCM stack. The phone apps show state and the exact host command; the interactive session runs on the development host.
- Evidence: TRI-LINK-QUICKSTART.md, pwa/nuxel-apps/console*, bridge tri-link API
- Serial Live Console — Shipped
- The serial console starts from the initramfs, before systemd, and holds an exclusive lock on the tty. The host launcher sends framed commands with checksums and real exit status, can mirror the kernel log, pull files and run batches. It is the recovery path when Wi-Fi and SSH are unavailable.
- Evidence: TRI-LINK-QUICKSTART.md; services/nuxel-console; tools/s10plus/a33/nuxel-console.c
- Wi-Fi SSH Console — Shipped
- The Wi-Fi SSH Console discovers the current IPv4 address and reports readiness from the phone side. The host launcher verifies the pinned Ed25519 host key, authenticates with the Nuxel key and preserves remote exit codes. The app itself stores no private key.
- Evidence: TRI-LINK-QUICKSTART.md and scripts/s10plus-debug-pack/nuxel-live-ssh.sh
- USB SSH Console — Blocked
- The USB SSH path requires a working NCM/RNDIS/ECM network gadget. On the Samsung 4.14.253 kernel this transport is not usable, so the app reports UNAVAILABLE · KERNEL BLOCKER. It does not fall back silently to Wi-Fi or serial.
- Evidence: pwa/nuxel-apps/console-usb; TRI-LINK-QUICKSTART.md
- Remote GUI access — Planned
- The tri-link model has two working transports today. Remote GUI would add a visual session over XRDP or VNC so the phone can be operated from a laptop. It depends on a stable Wayland session and a remote-desktop stack that is not part of v0.7.2-beta.
- Evidence: Roadmap and feature notes only
- Galaxy S10+ bring-up — In progress
- The S10+ boots Nuxel to a real userspace and presents the launcher through a DECON framebuffer screencopy bridge. It is not native DRM/KMS acceleration. The ABOX boot panic is patched, Bluetooth registers hci0 and scans, and audio playback works through RDMA1. GNSS, HDMI/DRM and the camera backend remain open.
- Evidence: docs/s10plus-live-fixes-20261028.md, docs/releases/v0.7.2-beta.md
- Pixel 10 Pro XL target — Planned
- The Pixel is the device Nuxel ultimately wants to run as a daily driver. The repository contains the device inventory, recovery path, flash tooling and firmware verification scripts. None of the on-device steps has been executed for Nuxel yet, and the scripts refuse to flash until the documented gates are satisfied.
- Evidence: docs/pixel10proxl-device-inventory.md, docs/mustang-recovery-bringup.md
- Moto G7 Power bring-up — In progress
- The G7 Power path is a deliberate hardware bring-up target built on the postmarketOS motorola-ocean port, mainline msm8953 work and the lk2nd chainloader. dtbo is always flashed before lk2nd and protected partitions are never touched. Every checksum and firmware filename remains a placeholder until the unit is inventoried.
- Evidence: docs/g7power-bringup.md, docs/g7power-device-inventory.md
- Audio playback — In progress
- RDMA0 starts but never advances hw_ptr on this kernel, so Nuxel routes playback through RDMA1 → SIFS1 → UAIF1 with the amplifier switches enabled. ALSA defaults and a static PipeWire sink point at the working device. Bluetooth audio is being extended on top of the now-working HCI controller, and USB/HDMI outputs are part of the current work.
- Evidence: docs/s10plus-live-fixes-20261028.md, services/nuxel-s10
- Bluetooth — In progress
- The rebuilt vendor kernel initially lost HCIUART support. With CONFIG_BT_HCIUART/H4 restored, btattach binds /dev/ttySAC1, hci0 registers and a live scan discovers peers. Settings can power, scan, pair and connect. Audio profiles and sustained operation are still being validated.
- Evidence: docs/s10plus-live-fixes-20261028.md, tests/pwnage37000/
- Wi-Fi — In progress
- The BCM4375 firmware and NVRAM blobs are installed from a pinned manifest, wlan0/wlan1 are managed devices and a credential-free scan returns real access points. Wi-Fi enable/disable is verified through NetworkManager. Association and internet access require the owner to supply network credentials.
- Evidence: docs/s10plus-daily-driver-checkpoint.md, services/nuxel-s10
- Display path — In progress
- The vendor 4.14 kernel exposes no /dev/dri, so the Wayland session is presented by copying frames into the Samsung DECON framebuffer with an explicit XRGB8888 → ABGR8888 conversion. The bridge enforces single framebuffer ownership and records frame commits. This is a real display path, but not native DRM/KMS acceleration.
- Evidence: docs/beta-finalization/boot/COLOUR-CONVERSION.md, tools/s10plus/a33/nuxel-wl-fb.c
- Connection modes — Shipped
- Connection mode is a real state machine in the bridge. Selecting File Transfer transitions the USB mode without exposing personal files, and the transfer indicator follows the actual endpoint state. Serial, USB and WLAN console indicators can be live at the same time, each driven by its own transport.
- Evidence: tests/pwnage34000/test_connection_modes.py, system_indicators.py
- Haptics and feedback — In progress
- nuxel-hapticsd serialises access to the motor so two subsystems cannot fight over it. It offers named patterns, a sleep helper and per-user intensity preferences. Intensity is reported honestly; when the motor cannot do a requested amplitude the API says so.
- Evidence: services/nuxel-haptics, pwa/nuxel-apps/settings
- Orientation, power and battery — In progress
- An orientation daemon reads the available sensors and applies a policy instead of blindly rotating. Charger and low-power-mode boots are detected, and the recovery unit performs one normal reboot with a persisted cooldown because sec_ts will not bind in LPM. Battery percentage is debounced so it does not flicker between 100% and 0%.
- Evidence: services/nuxel-orientation, services/nuxel-s10
- GNSS and location — Blocked
- The GPS rail can be powered and the chip answers on SPI, but /dev/ttyBCM does not emit NMEA. The BCM4773 speaks Broadcom’s BBD/LHD RPC protocol; the vendor gpsd is an Android/bionic binary that needs the Android linker and HIDL services, none of which exist in a Linux rootfs. Geoclue is therefore configured for Wi-Fi/IP location only and never claims a GNSS fix.
- Evidence: docs/s10plus-live-fixes-20261028.md, services/nuxel-s10/bin/nuxel-gps-status
- Maps — In progress
- Maps renders OpenStreetMap tiles with attribution and caches them for offline use. It requests location through the bridge, but on the S10+ the provider cannot return a GNSS fix. The app shows the returned state instead of drawing a false position.
- Evidence: pwa/nuxel-apps/maps, tests/a72/test_maps_location_integration.py
- Six verification tiers — Shipped
- The release gate runs the offline tiers in one command and reports each suite’s result and assertion count. The higher tiers are run against the phone and by the owner, and their verdicts are recorded separately. A green offline run means the repository is internally consistent — not that the handset boots or that audio is audible.
- Evidence: tools/beta/run-all-tests.sh, docs/beta-finalization/testing/TEST-STRATEGY.md
- Reproducible release pipeline — Shipped
- The release workflow builds the S10+ image from the merge commit rather than from a developer tree, verifies source parity and publishes the result with an annotated tag. The repository keeps VERSION, app manifests, service pins and documentation on the same release string so a release cannot drift silently.
- Evidence: .github/workflows/release.yml, tools/verify-artifacts.sh, docs/releases/
- PenGuru local AI — Planned
- PenGuru is the plan for an on-device assistant that knows the OS it runs on: services, settings, diagnostics, files and resources. It would inspect available APIs, propose an automation, generate it in isolation, test it, show the owner exactly what changes and install nothing without approval. It is not part of v0.7.2-beta.
- Evidence: docs/penguru plan and roadmap only
- Local model feasibility — Planned
- The planned starting point is quantized 1–2B parameter models via llama.cpp. Weight sizes are approximate Q4 figures, not total runtime memory. The S10+ has 7.4 GiB usable RAM and no swap, so model choice and memory pressure are part of the experiment rather than a solved detail.
- Evidence: PenGuru design notes; no model runtime is shipped