FutureOS

least_privilege: README and the sandbox test record show four approval tiers (off/manual/sandbox/auto), macOS Seatbelt, Linux Bubblewrap, and Windows restricted-token/ACL write protection, with per-backend boundary receipt tests; that is real evidence of privilege layering, but the desktop starts at Unrestricted (off), so the default posture is permissive — 2. user_confirmation: manual tier and rule-file approvals (fail-closed on unknown actions) are test-backed, but the auto tier hands would-be interruptions to a model reviewer, partially delegating confirmation — 2. data_flow_transparency: README asserts Noise + ChaCha20-Poly1305 end-to-end encryption and a self-hostable relay, but no protocol implementation or key-management detail is present in the reviewed files, so it is assertion rather than verifiable evidence — 1. sensitive_data_handling: API keys are written in plaintext to ~/.future/agent/auth.json with no documented encryption, permission tightening, or rotation; the sandbox doc admits snapshot/credential limitations without detail — 1. dependency_security: only lockfiles and pinned Tauri versions are visible; no audit, SBOM, or vulnerability-response process — 1. external_effects: scheduled tasks run 'at full permission', plus IM bridges and remote control, are documented as capabilities without isolation or revocation for external writes — 1. rollback: sessions are forkable and the goal plane is event-sourced, but install scripts, sandbox ACL changes, and scheduled tasks have no documented rollback path — 1. source_attribution: an MIT badge and a THIRD_PARTY_NOTICES link exist, but the publisher is unverified and installers pull binaries from dl.future-os.cn, so provenance cannot be closed inside the repository — 1.

self_consistency: README, build guide, sandbox record, and channel-runtime record agree on CLI embedding, host mode, and sandbox tiers, and the test record explicitly separates 'the test was wrong' from 'the code was wrong' — 2. dependency_availability: the build guide lists per-platform dependencies (pinned Rust 1.99.1, Node 24+, mold, WebKitGTK, Bubblewrap) and states behavior when they are missing (installer refuses without shasum/sha256sum) — 2. failure_messages: the troubleshooting table covers no-agent, gRPC, no-model, and build failures, and the test record gives concrete panic text and error-code classification — 2; end-user runtime diagnostics still lean on future doctor, so not 3.

audience_and_scenarios: clearly separates end users (one-line install), developers (source build), headless hosts, mobile, and IM scenarios — 2. capability_boundaries: the sandbox guide and test record state per-platform capability differences (Seatbelt/Bubblewrap/restricted token, pwsh versions, unmeasured platforms) honestly — 2. trigger_precision: scheduled tasks support interval/daily/weekly triggers, but deduplication, missed-run catch-up, and overlapping runs are undocumented; skill and goal triggers are described only in prose — 1. environment_fit: covers macOS/Linux/Windows/Android/iOS, static musl CLI, and older distro compatibility — 2.

information_architecture: README has nav anchors, a feature table, quick start, and troubleshooting; docs are split into guide/wiki/architecture/testing — 2. install_notes: the build-and-install guide is unusually thorough, with per-platform commands, an artifact-naming table, and explicit verification/skip-verification risk notes — 3. naming_stability: artifact filenames follow templates, but versions look like 0.0.2-<hash>, test/nightly suffix rules are complex, and CLI/GUI versions are independent — 2. examples_and_faq: configuration examples (auth.json, models.json, thinkingLevels) and a troubleshooting table exist, but there is no user-facing FAQ or end-to-end walkthrough — 2. known_limitations: the sandbox record lists unmeasured platforms, unreachable branches, CI flakiness, and pty limits — 2. license: the README badge says MIT + Apache-2.0 while the task metadata says MIT, and no LICENSE text is in the reviewed files — 1. versioning_changelog: only a version script and release-channel naming; no CHANGELOG or semver policy — 1. maintenance_responsibility: the publisher is unverified and there is no maintainer, security-response SLA, or governance statement beyond a SECURITY.md link — 1.

output_usability: the TUI folds tool calls, sessions fork, and one session spans devices — designs aimed at real output, with desktop/mobile screenshots as supporting evidence — 2. marginal_value: a unified Rust core with multi-surface access and a long-horizon goal plane is differentiated, but much of the capability depends on an external future-skills submodule and hosted services — 2. cost_benefit: installation requires piping a remote script to a shell, the desktop defaults to unrestricted permissions, and users must supply model keys or sign in; the benefit does not clearly outweigh the setup and trust cost — 1.

claim_traceability: the test records carry file:line references, commands, before/after numbers, and verbatim failure output that can be re-checked — 2. cross_source_corroboration: core README claims (encryption, sandboxing, long runs) lack a second in-repo source — no protocol code, no CI result artifacts — so they rest on documentation alone — 1. fact_inference_separation: the test record separates measured numbers, inference, and uncovered areas (e.g. 'the concurrent race itself is not covered') and flags historical data as not re-verified — 2.