failproofai 1.0.0-beta.4 → 1.0.0-beta.6

package/.next/standalone/Cargo.toml

@@ -1,9 +0,0 @@
-[workspace]
-resolver = "3"
-members = ["crates/*"]
-
-[workspace.package]
-version = "1.0.0-beta.4"
-edition = "2024"
-license-file = "LICENSE"
-repository = "https://github.com/FailproofAI/failproofai"

package/.next/standalone/crates/CLOUD_POLICIES.md

@@ -1,136 +0,0 @@
-# Cloud-managed policy generations
-
-This is the contract between the Failproof Cloud HTTP transport and the
-`failproofaid` policy worker. Polling and integrity maintenance run outside the
-hook path; hooks evaluate only the last verified local generation.
-
-## Layout
-
-```text
-~/.failproofai/policies/cloud-managed/
-├── desired-state.json
-├── active.json
-├── artifacts/
-│   └── <sha256>.mjs
-└── generations/
-    └── <generation>/
-        ├── manifest.json
-        └── <policy-id>.mjs
-```
-
-- `desired-state.json` is the last complete desired-state snapshot received
-  from cloud. A later slice must authenticate it with a publisher signature;
-  SHA-256 alone proves byte identity, not publisher identity.
-- `artifacts/` is a content-addressed cache.
-- `generations/` contains complete materialized policy sets. New generations
-  are built without modifying the active one.
-- `active.json` is an atomically replaced pointer to one complete generation.
-  It is derived state and is reconstructed when it is deleted, malformed, or
-  disagrees with `desired-state.json`.
-
-## Desired-state schema
-
-```json
-{
-  "schemaVersion": 1,
-  "generation": 184,
-  "policies": [
-    {
-      "id": "block-secret-exfiltration",
-      "revision": 7,
-      "sha256": "<64 lowercase hex characters>",
-      "artifactUrl": "https://..."
-    }
-  ]
-}
-```
-
-The artifact URL is opaque to the store. A cloud client supplies downloaded
-bytes through `ArtifactFetcher`; the reconciler trusts none of those bytes
-until their SHA-256 matches the desired state.
-
-## Cloud transport
-
-Enrol with the CLI:
-
-```bash
-failproofai config --connect https://be.failproof.ai \
-  --token <org-scoped policies:pull key> \
-  --machine-id prod-runner-01     # defaults to this host's name
-```
-
-That verifies the credentials against the server before storing anything, then
-writes `~/.failproofai/cloud.json` (mode 0600). `--disconnect` removes it,
-`--status` reports the connection with the token masked.
-
-**The credential must not go in the service unit.** `daemon-service.ts` installs
-`/etc/systemd/system/failproofaid@<user>.service` at mode 0644 — root-owned and
-world-readable — and the launchd plist likewise. An
-`Environment="FAILPROOFAI_CLOUD_TOKEN=…"` line there hands an organization-scoped
-key to every local user, and `systemctl show` prints it back with no privilege
-at all. Keeping it in a file also means enrolment, rotation and disconnect need
-no root, and an already-installed daemon can be connected without reinstalling.
-
-The daemon re-resolves enrolment on **every poll**, not at startup, so all three
-take effect within one interval with nothing to restart — which matters because
-restarting a system unit needs root, the very thing this avoids.
-
-Environment variables still take precedence over the file, for CI, containers
-and tests:
-
-```text
-FAILPROOFAI_CLOUD_URL=https://be.failproof.ai
-FAILPROOFAI_CLOUD_TOKEN=<org-scoped policies:pull key>
-FAILPROOFAI_MACHINE_ID=<deployment machine id>
-FAILPROOFAI_CLOUD_CREDENTIALS=<path>   # overrides ~/.failproofai/cloud.json
-```
-
-`FAILPROOFAI_CLOUD_POLICY_POLL_MS` controls the interval (30 seconds by
-default, clamped to at least 100 ms). The client sends Bearer authentication
-to both desired-state and artifact endpoints. Relative artifact locators are
-resolved against the configured base URL; cross-origin locators are rejected
-before the token is sent.
-
-An HTTP failure, invalid desired-state response, bad digest, or incomplete
-generation leaves the previous generation active.
-
-## Activation transaction
-
-1. Validate schema, policy IDs, unique IDs, digests, and monotonic generation.
-2. Reuse a verified cache/generation copy or fetch missing bytes.
-3. Verify every artifact digest.
-4. Materialize the complete generation and `fsync` its files/directories.
-5. Persist `desired-state.json`.
-6. Atomically replace `active.json`.
-
-Any failure before step 6 leaves the previous generation active. The worker
-loads only paths named by `active.json` and independently verifies every digest
-immediately before importing JavaScript.
-
-## Integrity maintenance
-
-`failproofaid` runs a maintenance thread outside the hook path. It hashes the
-active generation periodically (30 seconds by default) and repairs either a
-modified generation copy or a modified content-addressed artifact from the
-other verified copy. If both are gone, it retains the active manifest and
-reports that a cloud re-fetch is required.
-
-`FAILPROOFAI_CLOUD_POLICY_DIR` overrides the root for tests and development.
-When cloud polling is disabled, `FAILPROOFAI_CLOUD_POLICY_RECONCILE_MS`
-overrides the standalone integrity interval, clamped to at least 100 ms. With
-cloud polling enabled, integrity repair runs on each poll.
-
-## Current security boundary
-
-PR #632 runs the daemon as the same OS user as the governed agent. This layer
-provides deterministic deployment, drift detection, and self-healing, but it
-does not make policies tamper-proof against that user. The user can stop the
-service or delete both verified copies. Publisher signatures, deployment
-acknowledgement, and a stronger service identity are separate follow-up layers.
-The current machine credential is an org-scoped Bearer key transported over
-HTTPS.
-
-Downloaded JavaScript executes in the existing TypeScript policy worker with
-the user's authority. Cloud authorization must therefore treat assigning an
-arbitrary JavaScript policy as remote code execution until a sandboxed policy
-runtime exists.

package/.next/standalone/crates/PROTOCOL.md

@@ -1,122 +0,0 @@
-# failproofaid wire protocol
-
-The contract between the `failproofai` CLI (thin client) and the `failproofaid`
-daemon over a Unix domain socket. This is the same contract every hook
-invocation already has today — see `src/hooks/handler.ts`'s
-`handleHookEvent`: `(argv --hook <Event> --cli <cli>, stdin JSON payload) ->
-(stdout, stderr, exitCode)`. The daemon adds nothing to that contract; it only
-relays it over a socket instead of a fresh process's argv/stdin/stdout.
-
-Implemented in `crates/fpai-ipc` (framing + envelope + peer verification) and
-`crates/failproofaid` (the socket server itself). As of Stage 2, the daemon
-answers `ping` and rejects `hook` with a stub "not implemented" error — Stage 3
-wires `hook` up to a real warm Node/Bun worker.
-
-## Transport
-
-One Unix domain socket, one connection per request. The daemon reads exactly
-one frame, dispatches it, writes exactly one frame back, and lets the
-connection close — there is no request-ID multiplexing because there is never
-more than one logical request in flight per connection.
-
-Default path: `~/.failproofai/run/failproofaid.sock`. Overridable via the
-`FAILPROOFAI_DAEMON_SOCKET` env var (used by local dev and tests — never point
-this at a directory failproofaid doesn't own itself; see
-`crates/failproofaid/src/paths.rs`'s `ensure_run_dir`, which refuses to modify
-permissions on a pre-existing directory it didn't create).
-
-Permissions: the run directory is `0700` and the socket file `0600` — this is
-the actual access-control boundary (user-scope only, no elevation, same OS
-user only). `crates/fpai-ipc/src/peer.rs`'s `SO_PEERCRED` (Linux) /
-`getpeereid` (macOS) check is defense-in-depth on top of that, not a stronger
-boundary — same-user access can always reach this daemon regardless.
-
-## Framing
-
-Every message, in both directions, is:
-
-```
-+----------------------------+------------------------------+
-| length (4 bytes, big-endian u32) | UTF-8 JSON body (length bytes) |
-+----------------------------+------------------------------+
-```
-
-A declared length over `MAX_FRAME_LEN` (16 MiB) is rejected without
-allocating a body buffer for it — a hook payload is at most 1 MiB (see
-`handler.ts`'s own stdin cap), so 16 MiB is headroom, not an expected size.
-
-## Envelope
-
-Tagged JSON, `"type"` as the discriminant, camelCase field names.
-
-### Client → daemon (`ClientMessage`)
-
-```jsonc
-// Liveness/handshake check.
-{ "type": "ping", "protocolVersion": 1 }
-
-// One hook evaluation request — one per `failproofai --hook <Event> --cli <cli>` invocation.
-{
-  "type": "hook",
-  "protocolVersion": 1,
-  "hookEvent": "PreToolUse",
-  "cli": "claude",
-  "stdin": "<raw stdin payload the calling agent CLI wrote to the one-shot failproofai process, forwarded verbatim>",
-  "cwd": "/path/to/session/cwd" // optional; see the note below
-}
-```
-
-`cwd` must be the *originating* CLI process's cwd, captured by the thin
-client before dispatch — never the daemon's own cwd. The daemon is a single
-long-lived process; its own `cwd` does not vary per request and must never be
-used to resolve project config or custom policies (this is the "process.cwd()
-hazard" the TS-side plan calls out explicitly).
-
-### Daemon → client (`ServerMessage`)
-
-```jsonc
-{ "type": "pong", "protocolVersion": 1 }
-
-{
-  "type": "hookResult",
-  "protocolVersion": 1,
-  "exitCode": 0,
-  "stdout": "...",
-  "stderr": "..."
-}
-
-// The daemon accepted the connection and parsed the request, but could not
-// produce a verdict (worker down/hung, or — in Stage 2 — hook evaluation
-// simply isn't wired up yet). Distinct from hookResult so the client can
-// tell "ran and decided" apart from "daemon couldn't evaluate at all" — the
-// latter is what drives the client's fail-closed path.
-{ "type": "error", "protocolVersion": 1, "message": "..." }
-```
-
-## Protocol versioning
-
-`protocolVersion` is carried on every message in both directions. A mismatch
-gets an explicit `error` response from the daemon — the client treats *any*
-failure mode (missing socket, refused connection, timeout, malformed
-response, or an explicit version mismatch) identically: fall through to
-whatever the client's fail-closed/in-process policy dictates. There is no
-negotiation, only agree-or-fall-back.
-
-## Peer verification
-
-Every connection is checked with `SO_PEERCRED`/`getpeereid` before a single
-byte of the request is read. A peer running as a different OS user gets the
-connection dropped with **no response at all** — not even an `error` frame —
-so a connection from the wrong user can't even confirm a daemon is listening
-there.
-
-## Malformed input handling
-
-- A frame whose declared length exceeds `MAX_FRAME_LEN`: connection closed,
-  no response, no allocation attempted for the declared size.
-- A syntactically invalid or truncated frame: connection closed, no response.
-- A well-formed frame with an unrecognized `"type"`: fails to deserialize,
-  same as above.
-
-None of these crash the daemon or the connection-handling thread — a bad
-frame from one connection has no effect on any other connection.

package/.next/standalone/crates/failproofaid/Cargo.toml

@@ -1,25 +0,0 @@
-[package]
-name = "failproofaid"
-version.workspace = true
-edition.workspace = true
-license-file.workspace = true
-repository.workspace = true
-description = "Thin Rust supervisor: owns the failproofai IPC socket, service lifecycle, and warm worker process supervision. Carries no policy logic."
-publish = false
-
-[[bin]]
-name = "failproofaid"
-path = "src/main.rs"
-
-[dependencies]
-fpai-ipc = { path = "../fpai-ipc" }
-fpai-collect = { path = "../fpai-collect" }
-# Without a subscriber every `tracing::` call in fpai-collect is silently
-# discarded — including the uploader's "the server stored NONE of its events".
-tracing = "0.1"
-tracing-subscriber = { version = "0.3", default-features = false, features = ["std", "fmt", "env-filter"] }
-serde = { version = "1", features = ["derive"] }
-serde_json = "1"
-libc = "0.2"
-sha2 = "0.10"
-reqwest = { version = "0.12", default-features = false, features = ["blocking", "json", "rustls-tls"] }