[desgin-docs] v1.0.0 design set, Phase 1 implementation plan, and Stage 0 + Stage 1 of failproofaid

CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## 0.0.16-beta.0 — 2026-07-30
+
+### Docs
+- Replace the root daemon with a dedicated `_failproofai` service account as the recommended `failproofaid` enforcement boundary, and resolve the three problems that follow from it. Setup now offers `managed` (daemon runs as the service account, one sudo at install, no root at runtime), `system` (the same service as root, retained for fleet-managed `/etc` configuration and root-owned agents), and `user` (unchanged, cooperative). Three corrections come with it. Protected artifacts move out of `~/.failproofai` entirely: rename and delete permission derive from the *parent* directory, so a user who owns `~` can rename an unwritable subdirectory aside and substitute their own regardless of its mode — which also means the socket directory must be service-account-owned, closing the substitution attack where an agent unlinks the socket and binds an impostor that answers `allow`. Only *removal* is privileged, not addition: results combine `deny` over `instruct` over `allow`, so a user-added policy can only tighten enforcement and can never shadow a protected one, and convention discovery keeps working without elevation. And since a non-root daemon cannot `setuid` to an enrolled user, evaluation splits into a `sealed` tier (runs as the service account in a pinned runtime, no filesystem/subprocess/network, verdict unforgeable) and a `user-context` tier (runs as the requesting UID, verdict forgeable but additive-only, so a forged `allow` is worthless) — with the tier *derived* from declared capabilities rather than chosen, because it describes what is physically achievable. Payload-only builtins like `block-sudo` land in `sealed`. The release ships its own pinned runtime so the daemon never executes an nvm/fnm interpreter the user can rewrite, and constructs worker environments instead of inheriting `NODE_OPTIONS`/`NODE_PATH` from the agent's process. Promotion into the protected store compiles a policy and its full import graph into one content-addressed artifact, leaving authoring and dependency management unprivileged and unchanged. Enforcement performs no unbounded I/O: policies needing remote state read a cache the collection lane refreshes, rather than making GitHub's uptime a precondition for running a command. (#625)
+- Close four holes review found in the service-account boundary above, each one a case of the guarantee being narrower than the sentence claiming it. The protected surface — executables, pinned runtime, policy store, schema catalog, machine configuration — is now root-owned and **read-only to the service account the daemon runs as**, which owns only mutable runtime state; the first draft made `_failproofai` the owner of the store it evaluates, so a compromised daemon could rewrite the sealed policies it was supposed to enforce, exactly the self-rewrite argument already applied to the binaries and not to the store. Tier selection no longer trusts a policy's own capability declaration, since the author controls it and under-declaring would have been a route into `sealed`: admission derives the tier from the resolved import graph, and the `sealed` context is deny-by-default with no filesystem, process, or network bindings, so an under-declared policy fails inside the tier rather than escaping it. Native addons are refused from `sealed` outright — a pinned digest prevents substitution but constrains nothing about what native code does once loaded. And `sealed` is now stated as managed/system-only, because the protected runtime is a property of the privileged install layout, not of the shipped artifact; user scope makes no verdict-integrity claim. Also: `~/.failproofai` sources in a privileged scope are defined as additive non-authoritative inputs that only route to `user-context` and only tighten, resolving a contradiction with the out-of-home rule; "only removal is privileged" is scoped to policy administration so it stops reading as a claim about installation; uninstall unconditionally erases machine credentials rather than preserving them as configuration; catalog version detection gains a closed execution grammar (fixed executable/argument allowlists, no shell, constructed environment, output and time caps) since catalogs refresh remotely and activate automatically; catalog activation gains explicit fsync ordering, transaction metadata, and startup re-reconciliation; the release gate gains a clean-container install run; and the offline claim is qualified to operation-after-installation, since npm bootstrap is the only v1.0.0 distribution path. (#625)
+- Add a versioned home for the failproofai v1.0.0 design documents. (#625)
+- Draft the Linux/macOS Rust `failproofaid` design, preserving OSS and adding Login, Failproof Cloud, integrated collection, selectable service scopes with a recommended tamper-resistant default, and automatic version-aware hook reconciliation from a signed data-only schema catalog; keep native upgrades explicit through the single npm path, retain the branded Login/OSS setup, and defer Windows. (#625)
+
 ## 0.0.15-beta.1 — 2026-07-29
 
 ### Features

desgin-docs/v1.0.0/README.md

@@ -0,0 +1,7 @@
+# failproofai v1.0.0 design documents
+
+This directory contains checked-in design documents for the next major version of failproofai.
+
+## Documents
+
+- [`failproofaid` design](./failproofaid/) — user experience, harness integration, daemon architecture, cloud policy management, collector convergence, updates, and delivery plan.