PromptForge and PromptOS

Language: English | 繁體中文 | 简体中文

PromptForge is an operating system generation toolkit for the AI era. It takes a configuration file on a standard Linux host and outputs a bootable PromptOS .iso image optimized for Panther Lake NPU hardware.

PromptOS boots directly into an intent-driven interface, with traditional desktop overhead removed.

Target Hardware Baseline: Panther Lake NUC

• CPU/NPU platform: Intel Panther Lake NUC with integrated NPU (supported by intel_vpu)
• Firmware: UEFI boot enabled (Secure Boot optional for PoC, can be added later)
• Memory: 32 GB RAM recommended for local LLM + STT + browser runtime concurrency
• Storage: 256 GB NVMe minimum (512 GB recommended for model cache and logs)
• Graphics: Intel integrated Xe graphics with Mesa stack
• Audio: Onboard codec compatible with PipeWire/WirePlumber
• Network: Ethernet or Wi-Fi for model updates, telemetry, and remote management

Runtime UI Base Dependencies (must-have)

• Display and kiosk: cage, wayland, epiphany-browser (WebKitGTK-based kiosk browser)
• Graphics: mesa-vulkan-drivers, mesa-utils, mesa-utils-bin, libgles2, libegl1
• Audio stack: pipewire, wireplumber, alsa-utils
• Service boot: systemd, systemd-container
• ISO/install chain: grub-efi, xorriso, squashfs-tools, partition tools
• UI bridge runtime: browser WebSocket support + packaged xterm.js assets
• NPU/AI runtime: intel-level-zero-gpu, libze1, OpenVINO 2024

Deployment assets now included in repository:

• systemd units: infra/systemd/promptos-*.service
• fixed UI assets: infra/opt/promptos/ui/
• install helpers: scripts/linux/install-systemd-units.sh, scripts/linux/install-ui-assets.sh

Repository Implementation Layout

• Authoritative Python runtime implementation currently lives under src/promptos/
• Linux deployment assets live under infra/ and scripts/linux/
• Legacy placeholder directories under top-level src/* were removed to avoid false implementation signals
• Planned component decomposition is tracked in docs/components/*.md
• The current component-to-code mapping is maintained in docs/components/COMPONENTS_INDEX*.md

Gemma 4 Integration Strategy

PromptOS targets Panther Lake + 32 GB RAM as an edge-first inference platform. After reserving memory for OS/UI/runtime services, model memory should be explicitly budgeted.

Reference memory budget for 32 GB RAM:

• OS + Wayland + Web runtime + base services: about 6-8 GB
• Model + KV cache usable headroom: about 24 GB

Recommended local/cloud triangle (primary recommendation):

• Local primary always-on: gemma4:e4b (about 9.6 GB)
  • Role: default router, logic engine, and UI-forge baseline model
  • Why: keeps enough headroom for long context and coding/tool calls
• Local heavy on-demand: gemma4:26b (about 18 GB)
  • Role: offline complex coding, deep retrieval, long-chain reasoning
  • Policy: do not keep resident; load only when routed and memory is safe
• Cloud burst fallback: gemma4:31b-cloud (about 0 GB local RAM)
  • Role: highest-cost reasoning under high local load or premium tasks
  • Policy: cloud-edge router should prefer cloud when thermal/memory pressure is high

Recommended deployment profiles:

• Profile A (speed-first): Gemma 4 tiny/medium quantized pair
  • Tiny always-on router/logic model: gemma-4-tiny-int4
  • Medium on-demand local reasoning model: gemma-4-medium-int4
  • Goal: lower latency + stable memory headroom for UI and long context windows
• Profile B (offline-heavy): larger local model as primary reasoning engine
  • Keep tiny model for routing and safety checks
  • Add larger optional model bundle for deeper offline reasoning
  • Goal: maximize offline capability with stricter thermal and memory control

Perception middleware adjustment:

• Baseline path remains audio -> STT -> intent router
• Optional experimental path: direct multimodal audio-to-intent inference when model/runtime stack confirms support
• Recommendation: gate direct-audio mode behind explicit feature flag and fallback to STT on any runtime incompatibility

Packaging and installer integration:

• Gemma bundle contract: configs/prod/gemma4-bundles.manifest.yaml
• Bundle installer helper: scripts/linux/install-gemma4-bundles.sh
• ISO payload and package baseline: docs/components/iso-installer-pipeline.md
• Persistent model store target (runtime install): /persist/models
• Recommended layout:
  • /persist/models/base/ for always-on model bundles (for example gemma4:e4b)
  • /persist/models/optional/ for on-demand large models (for example gemma4:26b)
  • /persist/models/cache/ for transient conversion/cache artifacts

Safe staging flow (recommended on developer machines):

• Do not install runtime assets directly into host /etc or /opt while developing.
• Bootstrap and stage into an output rootfs directory instead:
  • sudo ROOTFS_DIR=out/rootfs bash scripts/linux/bootstrap-rootfs-apt.sh
  • bash scripts/linux/stage-runtime-rootfs.sh out/rootfs
• This writes units/assets/models under out/rootfs/... for image assembly.

Host install mode is still available for target machines only:

• sudo bash scripts/linux/install-systemd-units.sh
• sudo bash scripts/linux/install-ui-assets.sh
• sudo bash scripts/linux/install-gemma4-bundles.sh

Routing and security guardrails:

• Keep tiny model as always-on router and degraded fallback target
• Reserve medium/large models for complex coding and UI synthesis tasks
• Add a small isolated guard model process for payload risk screening before privileged tool execution

Detailed playbook:

• docs/GEMMA4_INTEGRATION_PLAYBOOK.md

Acceptance Gate Scripts

Use these scripts to close the remaining MVP and matrix gaps:

• scripts/linux/validate-gemma-bundles.sh
  • checks Gemma manifest integrity and required bundle declaration
• scripts/linux/run-acceptance-gates.sh
  • runs env check, installer/unit tests, and QEMU/NUC benchmark compare
• scripts/linux/validate-mvp-ready.sh
  • validates 3/3 core services + UI asset readability + /healthz

ISO Build and Headless QEMU Flow

Recommended developer workflow:

1. Bootstrap rootfs base packages into an output directory (kernel/initrd installed via apt in chroot)

• sudo ROOTFS_DIR=out/rootfs bash scripts/linux/bootstrap-rootfs-apt.sh

2. Stage runtime assets into the same rootfs

• SOURCE_DIR=/path/to/model-bundles bash scripts/linux/stage-runtime-rootfs.sh out/rootfs

3. Build ISO from staged rootfs

• RELEASE_VERSION=dev ROOTFS_DIR=out/rootfs bash scripts/linux/build-iso-installer.sh

4. Boot ISO in headless QEMU

• MODE=iso ISO_PATH=artifacts/dev/PromptOS-dev.iso bash scripts/linux/run-qemu-headless.sh

5. Validate an installed guest over SSH after disk boot

• SSH_PORT=2222 bash scripts/linux/validate-qemu-guest.sh

Headless install-and-boot workflow (no GUI):

1. Bootstrap rootfs base packages (kernel/initrd)

• sudo ROOTFS_DIR=out/rootfs bash scripts/linux/bootstrap-rootfs-apt.sh

2. Stage runtime assets

• SOURCE_DIR=/path/to/model-bundles bash scripts/linux/stage-runtime-rootfs.sh out/rootfs

3. Build ISO

• RELEASE_VERSION=dev ROOTFS_DIR=out/rootfs bash scripts/linux/build-iso-installer.sh

4. Install ISO payload into qcow image (slot A/B + data)

• ISO_PATH=artifacts/dev/PromptOS-dev.iso bash scripts/linux/install-iso-to-qcow.sh

5. Boot installed disk image in QEMU headless mode

• MODE=disk DISK_PATH=out/qemu-install/promptos-installed.qcow2 bash scripts/linux/run-qemu-headless.sh

6. Validate guest readiness over SSH

• SSH_PORT=2222 VALIDATE_GUEST=1 ISO_PATH=artifacts/dev/PromptOS-dev.iso bash scripts/linux/qemu-install-and-verify.sh

Convenience wrapper:

• scripts/linux/build-and-boot-qemu-headless.sh

Current limitation:

• The repository now has ISO build + headless disk provisioning + headless boot harnesses.
• This is a host-side install harness for CI/automation and does not replace a full in-guest interactive installer UX.

Component Library Map (How many ready options)

The following counts are curated for practical PoC choices, not an exhaustive ecosystem count.

Component Area	Ready-to-Use Library Count	Candidate Libraries
Rootfs bootstrap	3	debootstrap, mmdebstrap, live-build
Containerized build/chroot	3	chroot, systemd-nspawn, bubblewrap
Kernel and module integration	3	distro kernel packages, DKMS flow, custom kernel build scripts
NPU acceleration runtime	3	OpenVINO, ONNX Runtime (OpenVINO EP), Intel Level Zero stack
LLM inference backend	4	llama.cpp, vLLM, MLC LLM, Ollama
STT / wake word	4	whisper.cpp, sherpa-onnx, faster-whisper, Vosk
TTS	3	Piper, Coqui TTS, espeak-ng
Audio server and routing	3	PipeWire, WirePlumber, ALSA
Vector memory store	4	LanceDB, Chroma, Qdrant, FAISS
Web/sandbox runtime	3	WPE WebKit, Wasmtime, WebView
Kiosk compositor/session	3	Cage, Weston kiosk shell, Sway kiosk profile
Agent API framework	4	FastAPI, Litestar, Axum, Actix Web
Web automation/scraping	4	Playwright, Selenium, BeautifulSoup4, httpx + parsers
ISO mastering and bootloader	4	mksquashfs, xorriso, grub-efi, grub-pc-bin

End-to-End TODO Plan (to bootable image)

Stage 0: Project and config contracts

• Define panther.yaml schema: kernel, drivers, models, services, UI mode
  • Schema: configs/panther.yaml.schema
  • Example: configs/panther-lake-nuc-mvp.yaml
• Freeze directory convention: workspace/rootfs, workspace/artifacts, workspace/cache
  • Defined in schema under workspace.* section
• Add manifest lock file for reproducible package and model versions
  • Schema defines lock.lock_file field for panther.lock.yaml
  • Implementation: promptforge lock command (not yet implemented)

Stage 1: Build host validation

• Verify host OS (Ubuntu 24.04 recommended) and root/sudo permissions
• Verify toolchain: clang, ld.lld, cmake, ninja, git, python3
• Install required packages: debootstrap, squashfs-tools, xorriso, grub-*, systemd-container

Stage 2: Rootfs bootstrap

• Create base rootfs via debootstrap
• Configure apt sources, locale, timezone, minimal security settings
• Create non-root runtime user: promptos

Stage 3: Panther Lake hardware enablement

• Install kernel 6.8+ and verify intel_vpu module availability
• Install Intel userspace dependencies (OpenVINO runtime, Level Zero stack)
  • Added Intel OpenVINO apt repository
  • Install Level Zero (intel-level-zero-gpu, level-zero)
  • Install OpenVINO 2024 runtime
• Install graphics/audio stack: mesa-vulkan-drivers, pipewire, wireplumber
• Add hardware probe script to validate NPU/GPU/audio at first boot

Stage 4: AI runtime provisioning

• Build llama.cpp with OpenVINO (-DGGML_OPENVINO=1)
• Build or install STT runtime (whisper.cpp or sherpa-onnx)
• Install TTS runtime (piper) and baseline voice assets
• Stage models in /opt/promptos/models/ with checksums

Stage 5: Agent and service wiring

• Inject orchestrator and worker agents into /opt/promptos/
• Generate systemd units: orchestrator, stt, tts, model server, watchdog
• Define startup order and health checks (After=, restart policies)
• Add structured logs and journal retention policy

Stage 6: Intent UI and kiosk session

• Configure Wayland kiosk (cage) as default graphical target
• Launch WPE runtime fullscreen with intent dashboard URL
• Add fallback TTY rescue mode for recovery

Stage 7: Image mastering

• Produce filesystem.squashfs
• Build ISO tree with kernel/initrd and GRUB config
• Generate UEFI bootable image with xorriso
• Output naming convention: PromptOS-PantherLake-<version>.iso

Stage 8: Validation and release gates

• Boot test on Panther Lake NUC (cold boot and reboot paths)
• Verify NPU path is active for LLM/STT workloads
• Measure first-token latency, STT RTT, and idle memory footprint
• Run persistence and rollback checks (service crash recovery)
• Publish release notes and SHA256 checksum

Runtime Resilience Additions (recommended)

Your concern is correct: operators should not manually configure networking for normal deployment. PromptOS should self-adapt and self-diagnose by default.

Self-Adaptation and Self-Diagnostics Agents

• NetAdapt Agent: auto-detect Ethernet/Wi-Fi, apply DHCP first, then fallback profiles, and verify DNS/connectivity
• HardwareProbe Agent: detect NPU/GPU/audio devices and select compatible runtime profile
• ServiceDoctor Agent: track daemon health, restart failed services, and trigger degraded-mode fallbacks
• PolicyGuard Agent: enforce cloud/offline routing policy and privacy boundaries

Suggested target behavior:

• No manual network setup for standard NUC installations
• First boot reaches ONLINE_READY or OFFLINE_READY state within a bounded timeout
• If cloud is unavailable, system continues with local model fallback automatically

Hot Reload and Persistent Overlay

To avoid remastering ISO for every prompt/agent tweak:

• Keep immutable base in SquashFS
• Add writable persistent partition, e.g. /var/promptos_data
• Mount OverlayFS for mutable layers:
  • Prompts and policies: /opt/promptos/prompts
  • Agent configs: /etc/promptos/agents
  • Vector memory and cache: /var/lib/promptos

This enables hot updates of prompt templates and agent behavior without rebuilding the image.

JIT Runtime Watchdog and Crash Recovery

Because JIT-generated UI code can fail at runtime, add aggressive recovery:

• systemd watchdog for compositor and web runtime
• Restart burst policy with backoff and safe fallback screen
• Last-known-good UI snapshot restore path
• Health heartbeat from renderer to orchestrator

Recovery objective:

• Renderer crash should recover to listening screen in under 1 second for common failures

Cloud-Edge Hybrid Model Routing

Use local NPU models as router/privacy shield and cloud models as heavy coder/reasoner.

Task Type	Local Edge Model	Cloud Model
Intent classification, routing, short dialog	Primary	Optional
Privacy-sensitive retrieval + RAG	Primary	Restricted/opt-in
Complex UI generation and long-chain coding	Assist/fallback	Primary
Offline operation	Primary	Unavailable

Routing policy rules:

• Route COMPLEX_UI_TASK to cloud by default
• Route privacy-scoped tasks to local unless user explicitly allows cloud
• Route all tasks locally when offline mode is active

Event-Driven JIT Factory (Agent Routing Pipeline)

Implement orchestrator as an event bus with typed payload contracts.

1. Router Agent: convert user text to structured route JSON
2. Forager Agent: gather web/local/vector data sources
3. Logic Agent: clean and normalize data into canonical JSON/Markdown
4. UI-Forge Agent: assemble UI from predefined component library
5. Delivery Agent: push signed payload to renderer over WebSocket

Implementation note:

• Prefer sandboxed rendering contracts over raw eval for generated code (CSP + isolated execution path).

TODO Delta for New Capabilities

Add these items to the roadmap before release:

• Add NetAdapt Agent with DHCP/fallback/autoretry logic
• Add first-boot readiness state machine (ONLINE_READY / OFFLINE_READY)
• Add OverlayFS persistent writable layer (/var/promptos_data)
• Add ServiceDoctor crash-loop recovery rules for Cage/Web runtime
• Add cloud-edge router policy and privacy gates
• Add agent event schema and versioned payload contracts
• Add renderer sandbox policy and signed payload verification

Autonomic OS Design (Diagnostic + Adaptive)

PromptOS should operate as an autonomic system, not only an intent-to-UI generator.

Why MCP/Function Registry instead of heavy agent frameworks

For OS-level reliability and low overhead, prefer:

• MCP servers for structured tool exposure
• Native function-calling registry with JSON schema contracts
• Thin wrappers around proven Linux tools

Avoid introducing heavyweight orchestration frameworks as a hard dependency in the base image.

System Skill Registry

Create a registry directory (for example under /opt/promptos/skills_registry) that maps each skill to:

• Input schema
• Allowed execution scope
• Timeout/retry policy
• Safety guardrails and audit logs

Suggested base tools to wrap:

• Hardware telemetry: lm-sensors, Intel GPU/NPU telemetry tools
• Logs and diagnostics: journalctl, dmesg, perf
• Network and routing: iproute2, resolvectl, networkctl
• Power and thermal control: cpupower, platform thermal interfaces

Claude Code-style Skill Porting Plan

PromptOS can reproduce Claude Code-like coding skills by combining strict tool schemas with MCP server integration.

Core skill modules to standardize:

• File and semantic retrieval: view, list/glob, grep/search
• Code editing: deterministic str_replace with exact-match guard
• Terminal execution: sandboxed exec with timeout and full stdout/stderr capture
• MCP bootstrap: filesystem/memory MCP servers auto-registered at orchestrator startup

Implementation constraints:

• Every skill declares JSON schema, timeout, risk tier, and audit policy
• Editing tools must fail closed when the original string does not match exactly once
• Shell execution must run as non-root sandbox user and reject injection metacharacters
• Tier 3 destructive skills stay blocked by default and require explicit user approval

Reference design and rollout checklist:

• docs/CLAUDE_CODE_SKILL_PORTING_AND_WAYLAND_JIT_PLAN.zh-TW.md

Google ADK / Antigravity-style Skills Integration

PromptOS also adopts Google-style skill packaging concepts for scalable registry growth.

Progressive Disclosure contract (SKILL.md):

• L1 Metadata (startup menu): name, description, trigger conditions
• L2 Instructions (on invoke): workflow steps, constraints, and guardrails
• L3 Resources (lazy load): docs/scripts/assets only when requested by L2

Why this matters:

• Prevents context bloat when the registry grows to thousands of skills
• Keeps resident model context lean for routing and UI tasks
• Enables mixed global skills + project-specific skill packs

PromptOS integration rules:

• Startup loads only L1 metadata from each skills_registry/**/SKILL.md
• L2 is injected only after explicit skill selection
• L3 resources are read on demand with path allowlists and sandboxed execution
• Third-party skill packs are imported under a dedicated namespace and reviewed before enablement

Skill Factory (meta-skill) policy:

• Agent-generated skills are allowed only in quarantine namespace
• Generated skills require policy scan + tests + human approval before promotion
• Promotion records must include source, license, risk tier, and audit trail

Reference design:

• docs/GOOGLE_ADK_SKILLS_INTEGRATION_PLAN.zh-TW.md

Wayland JIT UI Rendering Path

Wayland is the display protocol; HTML rendering is handled by a resident web runtime.

Recommended low-latency pipeline:

Model UI output -> FastAPI WebSocket push -> Web runtime (WPE/Chromium) -> Cage compositor -> DRM/KMS

Execution model:

• Keep Cage + web runtime alive as a persistent shell process
• Keep a stable /shell page that listens on /ws/ui
• Push html/css/js payloads incrementally; avoid restarting renderer per request
• Enforce CSP + sandbox boundaries for runtime script execution

Diagnostic Agent (System Diagnostician)

Execution mode:

• Event-driven triggers from journald/kernel alerts
• Periodic patrol (for example every 10 seconds)

Example diagnostic skills:

• read_dmesg(lines)
• get_npu_load()
• analyze_memory_map()
• check_network_reachability(targets)

Output contract:

• Structured diagnostic JSON with severity, confidence, and recommended action

Adaptive Agent (Adaptive Controller)

Consumes diagnostic JSON and performs bounded corrective actions.

Reference scenarios:

• Cloud unreachable: switch model routing to local-first degraded mode
• Renderer memory leak: terminate and relaunch sandboxed runtime
• Thermal overload: set conservative CPU governor and reduce inference profile

Autonomic Loop in Orchestrator

Use an independent loop inside orchestrator:

1. Collect metrics and system signals
2. Classify normal/anomaly with lightweight local classifier
3. If anomaly: invoke Adaptive Agent via skill registry

Skill Pack Priority (What to define first)

Recommended implementation order for Panther Lake NUC:

1. Net and Route Skills (highest priority)
2. Resource Management Skills
3. Hardware Control Skills

Reasoning:

• Without network/routing automation, user experience and cloud-edge policy fail first
• Resource recovery is second to keep system alive under JIT/runtime failures
• Hardware tuning is third because it improves efficiency after baseline stability exists

Minimum Skill Pack v0

Net and Route (start here):

• detect_network_links
• acquire_dhcp
• verify_dns
• check_cloud_reachability
• set_model_routing

Resource Management:

• list_top_memory_processes
• kill_and_relaunch_sandbox
• compact_runtime_cache
• collect_oom_report

Hardware Control:

• get_soc_temperature
• set_cpu_governor
• set_npu_profile
• set_display_brightness

Build Host Toolchain (reported)

clang --version
Ubuntu clang version 18.1.3 (1ubuntu1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

ld.lld --version
Ubuntu LLD 18.1.3 (compatible with GNU linkers)

Product Architecture: PromptOS (Target)

1) Core Base System

• Init: systemd (daemon lifecycle, restart, dependency graph)
• Userland: busybox / coreutils
• Kernel: Linux kernel 6.8+ with intel_vpu NPU driver

2) Hardware Acceleration

• AI runtime acceleration: Intel OpenVINO
• Graphics stack: Mesa 3D (Iris/Xe)

3) Perception Middleware

• Audio stack: PipeWire + WirePlumber
• Wake word & STT: Whisper.cpp / Sherpa-onnx
• TTS: Piper

4) Cognitive and Agent Layer

• Orchestrator: Python FastAPI or Rust daemon
• LLM backend: llama.cpp (OpenAI-compatible API surface)
• Memory: LanceDB (lightweight embedded vector DB)
• Scraping tools: playwright-python / beautifulsoup4

5) Ephemeral UI Layer

• Web runtime: WPE WebKit or Wasmtime
• Compositor: Cage (Wayland kiosk fullscreen lock-in)

Generator Architecture: PromptForge

PromptForge runs on your existing development machine (for example Ubuntu) and builds PromptOS from scratch.

Core Modules

• Builder Core: Bootstrap a clean Linux root filesystem (rootfs)
• AI Toolchain Provisioner: Install OpenVINO and compile tuned llama.cpp and whisper.cpp in chroot
• Agent Injector: Inject orchestrator/agent code and wire up systemd autostart services
• Mastering Engine: Configure GRUB, compress rootfs to SquashFS, and produce UEFI-compatible ISO

Toolkit Dependencies on Build Host

• debootstrap
• chroot and systemd-nspawn
• mksquashfs (squashfs-tools)
• xorriso, grub-pc-bin, grub-efi

Pipeline: promptforge build --config panther.yaml

Phase 1: Bootstrap

• Create workspace/rootfs
• Use debootstrap to fetch minimal Ubuntu 24.04 base system

Phase 2: Kernel and Drivers

Install inside rootfs:

• linux-image-generic
• intel-npu-driver
• mesa-vulkan-drivers
• pipewire
• cage

Phase 3: AI Compile and Provision

• Build llama.cpp with OpenVINO:
  • cmake -DGGML_OPENVINO=1
• Preload local models into:
  • rootfs/opt/promptos/models/
  • Example: Llama-3-8B-Instruct.Q4.gguf, whisper-base.bin

Phase 4: Agent Wiring

• Place orchestrator code (for example prompt_orchestrator.py) into the system image
• Generate and enable systemd service:

[Unit]
Description=PromptOS Intent Orchestrator
After=pipewire.service

[Service]
ExecStart=/usr/bin/python3 /opt/promptos/orchestrator.py
Restart=always
User=promptos

• Configure cage as default display service so boot goes straight to a fullscreen command-ready view

Phase 4.5: Pre-compilation and Cache Pre-warming

• Inject mandatory fallback static UIs into /opt/promptos/ui_fallbacks/
• Package Level 0 skill JSON schema registry into /opt/promptos/skills_registry/
• Pre-create JIT cache index and paths: /var/cache/promptos/jit_ui/

Phase 5: Mastering

1. Compress workspace/rootfs into filesystem.squashfs via mksquashfs
2. Build CD structure and add GRUB config (grub.cfg)
3. Use xorriso to generate PromptOS-PantherLake-v1.0.iso

Tiered Caching and Baking Strategy

Core principle: Cache the View, JIT the Data.

Level 0: Baked Layer (Rootfs / SquashFS)

Characteristics: immutable, read-only, survival-critical.

Required skills:

• sys_recovery: restart daemons, switch TTY, inspect panic logs
• net_manager: wrap baseline Wi-Fi scan/connect via nmcli
• hw_watchdog: track Panther Lake thermal and NPU load signals

Required fallback UIs:

• The Void: minimal boot standby screen
• Panic Room: rescue view for renderer/runtime crashes
• Network Setup Wizard: statically baked HTML/JS for cloud bootstrap recovery

Level 1: Persistent Cache Layer (OverlayFS / NVMe)

Characteristics: writable and durable for verified high-value artifacts.

Suggested paths:

• /var/cache/promptos/jit_ui/
• /var/lib/promptos/skills/

Mechanism: Intent Fingerprinting.

• Normalize intent payload and compute hash (for example SHA-256)
• Use hash as UI framework cache key
• On hit, load cached view and JIT only fresh data

Level 2: Runtime Hot Cache Layer (RAM)

Characteristics: ultra-low-latency interaction.

Primary contents:

• Short-term conversation vectors
• Current DOM/component state
• Pre-warmed always-resident WPE runtime

Level 3: Ephemeral True JIT Layer

Characteristics: one-off low-frequency tasks; discard after use.

Typical examples:

• One-time WebGL/3D visualizations
• Temporary exploration UIs with low reuse probability

Intent Fingerprint and Cache Policy Recommendations

Suggested hash input fields:

• intent class
• normalized prompt
• required components list
• user profile scope

Suggested write-to-cache conditions:

• task completed successfully
• stable render without watchdog alerts
• frequency above threshold (for example >= 2)

Suggested eviction policy:

• LRU + TTL hybrid policy
• hard quota for large artifact groups

Four Critical Blind Spots (must close before daily-use release)

1) Prompt-injection to RCE escalation

Risk:

• Untrusted web content can poison tool-calling prompts and attempt destructive skills.

Required controls:

• Capability-based sandboxing for skills
• Strict intent firewall: generated UI can request read-only or user-confirmed actions only
• Mandatory second-factor confirmation for high-risk actions (delete/reformat/reboot)
• Dirty-data isolation path before data reaches router logic

2) Voice identity and command authority

Risk:

• Always-on voice UI can execute commands from TV/audio spoofing or non-admin users.

Required controls:

• Continuous speaker verification in audio pipeline
• Command payload must carry speaker identity and confidence
• Role-based command policy: unknown speaker gets harmless command set only
• Step-up authentication for sensitive operations

3) Data ownership and post-desktop UX

Risk:

• Without app/folder UX, users lose track of downloaded/generated artifacts.

Required controls:

• Semantic object store on persistent layer
• Auto-embedding + metadata tagging on ingest
• Retrieval by intent query against vector index and metadata
• Object lifecycle policy (retention, pin, archive, purge)

4) OTA updates for immutable OS

Risk:

• Traditional package upgrade flow is unsafe for immutable SquashFS systems.

Required controls:

• A/B partition update strategy
• Background install to inactive slot
• Health-gated boot switch and automatic rollback
• Power-loss safe checkpointing and signed artifact verification

Implementation Order (first code path)

Recommended first coding path:

1. Orchestrator security core (intent firewall + capability policy)
2. Voice identity lock (speaker verification + RBAC command gate)
3. PromptForge A/B update pipeline and boot health rollback
4. Semantic object store and retrieval UX

Why this order:

• Security boundary must exist before expanding tool surface
• Identity gate prevents accidental or malicious real-world voice execution
• A/B protects the platform during rapid iteration and model/driver updates
• Semantic storage becomes useful once system trust and uptime are stable

TODO Delta: Security, Identity, Storage, OTA

• Add capability policy engine and skill risk tiers (read, state-change, destructive)
• Add high-risk command approval flow with confirmation token
• Add prompt-injection detector and dirty-data quarantine path
• Add speaker verification pipeline and per-speaker RBAC profiles
• Add semantic object store schema and embedding-on-ingest worker
• Add A/B slot image layout and health-based rollback logic
• Add signed update manifest verification before slot activation

Suggested Implementation Language

For a fast PoC, use Python + Shell scripts:

• Python: config parsing and pipeline orchestration
• Shell/subprocess: invoke low-level tooling (debootstrap, chroot, xorriso, etc.)