[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-83174":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":16,"starSnapshotCount":16,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},83174,"astrid","unicity-astrid\u002Fastrid","unicity-astrid","An operating system for AI agents.","",null,"Rust",8683,94,19,201,0,133,911,694,36.93,"Apache License 2.0",false,"main",true,[],"2026-06-12 02:04:32","# Astrid\n\n**An operating system for AI agents.**\n\n[![CI](https:\u002F\u002Fgithub.com\u002Funicity-astrid\u002Fastrid\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Funicity-astrid\u002Fastrid\u002Factions)\n[![License: MIT OR Apache-2.0](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-MIT%20OR%20Apache--2.0-blue.svg)](LICENSE-MIT)\n[![MSRV](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FMSRV-1.94-blue)](https:\u002F\u002Fwww.rust-lang.org)\n[![Rust 2024](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FRust-2024_edition-orange)](https:\u002F\u002Fwww.rust-lang.org)\n\n---\n\nAstrid is a user-space microkernel that treats AI agents the way Linux treats processes. It has a kernel with a boot sequence, a virtual filesystem with copy-on-write overlay, ed25519 capability tokens, an IPC event bus, WASM process isolation, and a cryptographic audit trail where each entry hashes the previous.\n\nThe kernel is fixed. Everything else is a swappable **capsule**: providers, orchestrators, tools, frontends, interceptors. You do not fork Astrid to customize it. You compose capsules into a configuration that fits your use case. Same core OS, different capsule sets, infinite configurations.\n\nCurrently v0.5.0. Runs in user space. The only frontend today is the built-in CLI (`astrid chat`). The architecture is designed for unikernel deployment.\n\n## Why capsules matter\n\nMost agent frameworks bake their assumptions into the code. The LLM provider is a library import. The orchestration loop is a hardcoded function. The tool set is a static list. Changing any of these means forking the framework, understanding its internals, and maintaining a divergent copy.\n\nAstrid inverts this. The kernel provides sandboxing, IPC, a filesystem, capability tokens, budget enforcement, and audit. Everything above that boundary is a capsule: an isolated WASM process described by a `Capsule.toml` manifest. Capsules declare what they provide and what they require via typed `[imports]`\u002F`[exports]` tables. The kernel resolves dependencies via topological sort and boots them in order.\n\nThis is not a plugin system bolted onto an application. It is the application's architecture.\n\n### What this makes possible\n\n**Run completely offline.** Swap the provider capsule for one that talks to Ollama or vLLM. Everything else works identically. The orchestrator does not know or care which model backend is running.\n\n**Build novel agent architectures.** Write a custom orchestrator capsule: a debate system, a Monte Carlo tree search planner, a chain-of-verification loop. Agent architecture is the frontier of AI research. Astrid gives researchers a production runtime where sandboxing, budget enforcement, and audit are already solved.\n\n**Cut LLM costs with transparent caching.** Install a caching capsule as middleware between orchestrator and provider. Seen this prompt before? Return the cached response. Neither orchestrator nor provider needs modification.\n\n**Autonomous agents that work overnight.** Replace the default orchestrator with an autonomous worker capsule. It generates code, runs tests, reads errors, self-corrects, and loops until green. The difference between a chatbot and an autonomous agent is the orchestration logic, and that logic is a swappable capsule.\n\n**Mix and match providers.** Run multiple provider capsules simultaneously. A routing capsule examines each request and picks the best provider by complexity, cost, or latency. Every provider speaks the same IPC event schema.\n\n**Self-modifying agents.** The agent can write a new capsule — Rust source, `Capsule.toml`, tests — build it via `astrid-build`, install it with `capsule install`, and exercise it by publishing to its IPC topics. It can extend its own OS at runtime: add new tools, new interceptors, new capabilities. It can also modify its own existing configuration, environment, and persistent state across sessions. The identity capsule already does this in miniature — the LLM rewrites its own `spark.toml` during onboarding. The full picture is an agent that writes, tests, and deploys its own capsules — evolving its own harness within the capability sandbox.\n\n**Ship custom distros.** Package a `Distro.toml` plus capsules. Enterprise A gets an approval-gated orchestrator. Startup B gets an autonomous worker with a local model. Security patches ship to everyone simultaneously.\n\n> These scenarios are architecturally possible today. The kernel, IPC bus, capsule manifest system, and dependency resolver all exist and are tested. What varies is how many capsules have been built on top of this foundation so far.\n\n## The agent has agency. The human has authority.\n\nTraditional computing puts the human at the center. AI agents invert this relationship. The agent operates, reasons, and acts. The human supervises, approves, and steers. Astrid is built for this inverted model from the ground up.\n\nThe kernel enforces boundaries so the agent can act freely within them. The approval gates keep humans in the loop at moments that matter, not at every step. The audit trail provides cryptographic accountability for every action. The capability system lets trust expand gradually as the agent proves reliable.\n\nHow much authority you keep is up to you. `mode = \"safe\"` asks before every action outside the workspace. `mode = \"guided\"` auto-allows reads, asks for writes. `mode = \"autonomous\"` takes the guardrails off. And for daring Astrinauts: `mode = \"yolo\"`.\n\n## The security model\n\nEvery sensitive action passes through five layers before it executes:\n\n```text\nAgent proposes action\n       |\n  [1. Policy]    Hard blocks. \"sudo\" is always denied. Path traversal is always denied.\n       |         Admin-controlled deny lists, allowed paths, denied hosts.\n       |         Cannot be overridden by tokens or approvals.\n       |\n  [2. Token]     Does a valid ed25519 capability token cover this action?\n       |         Scoped to resource patterns via globset matching.\n       |         Time-bounded. Linked to the audit entry that created it.\n       |\n  [3. Budget]    Is the session within its spending limit?\n       |         Per-action and per-session limits, enforced atomically.\n       |         Dual-budget: session budget AND workspace budget must both allow.\n       |         Reservation-based: cost is held during approval, refunded on denial.\n       |\n  [4. Approval]  No token? Ask the human.\n       |         Allow Once \u002F Allow Session \u002F Allow Workspace \u002F Allow Always \u002F Deny.\n       |         \"Allow Always\" mints a signed capability token for next time.\n       |         \"Allow Session\" creates a scoped allowance that auto-matches future calls.\n       |         Human unavailable? The action queues, not silently skips.\n       |\n  [5. Audit]     Every decision — allowed, denied, deferred — is logged.\n                 Each entry is signed by the runtime's ed25519 key.\n                 Each entry contains the content hash of the previous.\n                 Tamper with the history and the chain breaks.\n```\n\nThis is real code. [`SecurityInterceptor`](crates\u002Fastrid-approval\u002Fsrc\u002Finterceptor\u002Fmod.rs) implements this exact flow. The tests cover policy blocks, budget exhaustion, budget reservation refund on denial, budget refund on async cancellation, capability token authorization, the \"Allow Session\" allowance minting path, and the \"Allow Always\" token minting path.\n\n## Two sandboxes\n\n**WASM sandbox.** Capsules run in WebAssembly via Extism\u002FWasmtime. No syscalls, no file descriptors, no host memory access. Every external resource (filesystem, network, IPC, KV storage) is gated behind a capability-checked host function. The host ABI exposes 49 functions across filesystem, IPC, storage, network, identity, lifecycle, process management, approval, hooks, and clock subsystems. Hard limits: 64 MB memory ceiling, 5-minute wall-clock timeout, BLAKE3 hash verification on capsule binaries (no hash or wrong hash means no load).\n\n**VFS overlay.** The agent operates against a copy-on-write filesystem. The workspace is the read-only lower layer. Writes go into an ephemeral upper layer backed by a temp directory. Session ends: commit the diff to the workspace, or drop the temp directory to discard. Path traversal (`..\u002F..\u002Fetc\u002Fpasswd`) is rejected at the VFS layer before reaching the host filesystem. File handles use capability-based `DirHandle`\u002F`FileHandle` types.\n\n## The host ABI\n\nThe WASM-to-host boundary is a flat syscall table. WASM guests cannot import arbitrary host functions.\n\n| Subsystem | Syscalls |\n|---|---|\n| **Filesystem** | `astrid_fs_exists`, `astrid_read_file`, `astrid_write_file`, `astrid_fs_mkdir`, `astrid_fs_readdir`, `astrid_fs_stat`, `astrid_fs_unlink` |\n| **IPC** | `astrid_ipc_publish`, `astrid_ipc_subscribe`, `astrid_ipc_recv` (blocking), `astrid_ipc_poll` (non-blocking), `astrid_ipc_unsubscribe` |\n| **Uplinks** | `astrid_uplink_register`, `astrid_uplink_send` |\n| **Storage** | `astrid_kv_get`, `astrid_kv_set`, `astrid_kv_delete`, `astrid_kv_list_keys`, `astrid_kv_clear_prefix` |\n| **HTTP** | `astrid_http_request`, `astrid_http_stream_start`, `astrid_http_stream_read`, `astrid_http_stream_close` |\n| **Network** | `astrid_net_bind_unix`, `astrid_net_accept`, `astrid_net_poll_accept`, `astrid_net_read`, `astrid_net_write`, `astrid_net_close_stream` |\n| **Identity** | `astrid_identity_resolve`, `astrid_identity_link`, `astrid_identity_unlink`, `astrid_identity_create_user`, `astrid_identity_list_links` |\n| **Lifecycle** | `astrid_elicit` (user input during install), `astrid_has_secret`, `astrid_signal_ready`, `astrid_get_caller`, `astrid_get_config` |\n| **Process** | `astrid_spawn_host`, `astrid_spawn_background_host`, `astrid_read_process_logs_host`, `astrid_kill_process_host` |\n| **Approval** | `astrid_request_approval` (blocks guest until human responds or timeout) |\n| **Security** | `astrid_check_capsule_capability` |\n| **Hooks** | `astrid_trigger_hook`, `astrid_get_interceptor_handles` |\n| **Clock** | `astrid_clock_ms` |\n| **Logging** | `astrid_log` |\n\nEvery parameter crosses the boundary as raw bytes. The [SDK](https:\u002F\u002Fgithub.com\u002Funicity-astrid\u002Fsdk-rust) adds typed ergonomics on top, mirroring `std` module layout (`fs`, `net`, `process`, `env`, `time`, `log`) plus Astrid-specific modules (`ipc`, `kv`, `http`, `hooks`, `uplink`, `identity`, `approval`, `runtime`).\n\n## Capsules\n\nCapsules are processes in the OS model: isolated execution units described by a `Capsule.toml` manifest. A capsule can combine multiple engines:\n\n- **WASM** — compiled sandbox, full host ABI access via syscalls\n- **MCP** — native subprocess proxied via JSON-RPC (MCP 2025-11-25 spec, wraps `rmcp`)\n- **Static** — declarative context injection (files, prompts)\n\nA manifest declares the capsule's `[imports]` (what it needs from other capsules) and `[exports]` (what it provides to the system), using namespaced interface names with semver version requirements. Dependencies between capsules are resolved via topological sort at boot. The kernel validates that all required imports are satisfied before any capsule starts.\n\nA manifest can also declare commands, skills, interceptors, IPC topics, MCP servers, and uplinks.\n\n```rust\nuse astrid_sdk::prelude::*;\n\n#[derive(Default)]\npub struct MyTools;\n\n#[capsule]\nimpl MyTools {\n    #[astrid::tool]\n    fn search_issues(&self, args: SearchArgs) -> Result\u003CSearchResult, SysError> {\n        let token = env::var(\"GITHUB_TOKEN\")?;\n        let resp = http::get(&format!(\n            \"https:\u002F\u002Fapi.github.com\u002Fsearch\u002Fissues?q={}\", args.query\n        ))?;\n        \u002F\u002F ...\n    }\n}\n```\n\nThe `#[capsule]` proc macro generates all WASM ABI boilerplate: `extern \"C\"` exports, JSON serialization across the boundary, and dispatch routing for tools, commands, hooks, install, and upgrade entry points. Capsule authors depend on `astrid-sdk` and `serde`.\n\nTypeScript and JavaScript plugins from the OpenClaw ecosystem compile to WASM via an all-Rust pipeline (OXC transpiler, QuickJS\u002FWizer, export stitcher). No Node.js required for Tier 1 plugins.\n\n## Interceptors\n\nCapsules can register interceptors on IPC topics — eBPF-style middleware that fires before (or instead of) the core handler. Interceptors return `Continue`, `Final`, or `Deny` to control the chain. A guard at priority 10 can veto an event before the core handler at priority 100 ever sees it. Tools are an IPC convention: tool capsules intercept `tool.v1.execute.\u003Cname>` and `tool.v1.request.describe` topics. The router capsule handles discovery and dispatch. The kernel has no knowledge of tool schemas.\n\n## Quick start\n\n**Prerequisites:** Rust 1.94+. An LLM provider (e.g. Anthropic API key) is needed for the default distro but not for the kernel itself.\n\n```bash\n# Install from crates.io (installs both astrid and astrid-daemon binaries)\ncargo install astrid\n\n# Initialize — fetches the default distro, installs capsules, sets up PATH\nastrid init\n\n# Start a session (daemon boots automatically on first use)\nANTHROPIC_API_KEY=sk-... astrid chat\n\n# Or build from source\ngit clone https:\u002F\u002Fgithub.com\u002Funicity-astrid\u002Fastrid.git\ncd astrid\ncargo build --release\n.\u002Ftarget\u002Frelease\u002Fastrid init\n```\n\nThree binaries work together: `astrid` (CLI frontend), `astrid-daemon` (kernel process), and `astrid-build` (capsule compiler). When you run `astrid chat`, the CLI auto-starts the daemon as a background process, connects over a Unix domain socket, and renders streaming events. The daemon manages the VFS, capsules, IPC, audit, and security. The CLI manages input and display.\n\n### Headless \u002F scripting mode\n\n```bash\n# Single-prompt, non-interactive — prints response and exits\nastrid -p \"summarize the git log\"\n\n# Pipe stdin\ngit diff HEAD~1 | astrid -p \"write a commit message for this diff\"\n\n# Multi-turn scripted conversation\nSESSION=$(astrid -p \"start a task\" --print-session 2>&1 | tail -1)\nastrid -p \"continue the task\" --session \"$SESSION\"\n\n# Autonomous mode (auto-approve all tool requests)\nastrid -p \"fix all failing tests\" --yes\n```\n\n### Daemon lifecycle\n\n```bash\nastrid start     # Start a persistent daemon (survives terminal close)\nastrid status    # Show PID, uptime, connected clients, loaded capsules\nastrid stop      # Graceful shutdown\nastrid self-update  # Download the latest release binary to ~\u002F.astrid\u002Fbin\u002F\n```\n\n## The distro system\n\nA **distro** is a `Distro.toml` manifest that describes a curated set of capsules for a particular use case. `astrid init` fetches the manifest, presents a multi-select provider group picker, resolves `{{ var }}` template variables via interactive prompts, and installs all selected capsules with progress bars. A `Distro.lock` is written atomically with BLAKE3 hashes of every installed capsule for reproducible deployments.\n\n```bash\n# Install the default distro (astralis)\nastrid init\n\n# Install a custom distro\nastrid init --distro @myorg\u002Fmy-distro\n\n# Install from a local Distro.toml\nastrid init --distro .\u002Fpath\u002Fto\u002FDistro.toml\n```\n\n## Capsule management\n\n```bash\n# Install from GitHub (downloads pre-built .wasm release asset, falls back to build from source)\nastrid capsule install @org\u002Fcapsule-name\n\n# Install from a local path\nastrid capsule install .\u002Fpath\u002Fto\u002Fcapsule\n\n# List installed capsules with capability metadata\nastrid capsule list\nastrid capsule list --verbose\n\n# Show the imports\u002Fexports dependency graph\nastrid capsule tree\n\n# Update a specific capsule (or all capsules)\nastrid capsule update my-capsule\nastrid capsule update\n\n# Remove a capsule (checks dependents before removing)\nastrid capsule remove my-capsule\nastrid capsule remove my-capsule --force  # bypass dependency check\n```\n\nContent-addressed WASM binaries are stored in `~\u002F.astrid\u002Fbin\u002F` using BLAKE3 hashes. Capsule removal cleans up the binary from `bin\u002F` when no other capsule references the same hash. The binary store itself (`bin\u002F` and `wit\u002F`) is append-only; `astrid gc` for explicit cleanup is planned.\n\n## Directory layout\n\nAstrid uses a Linux FHS-aligned layout under `~\u002F.astrid\u002F` (overridable via `$ASTRID_HOME`):\n\n```text\n~\u002F.astrid\u002F\n├── etc\u002F\n│   ├── config.toml          deployment config\n│   ├── servers.toml         MCP server config\n│   ├── gateway.toml         daemon config\n│   └── hooks\u002F               system hooks\n├── var\u002F\n│   └── state.db\u002F            system KV (SurrealKV, persistent)\n├── run\u002F                     ephemeral runtime state\n│   ├── system.sock          Unix domain socket\n│   ├── system.token         session authentication token\n│   └── system.ready         daemon readiness sentinel\n├── log\u002F                     system logs\n├── keys\u002F\n│   └── runtime.key          ed25519 signing key\n├── bin\u002F                     content-addressed WASM binaries (BLAKE3-named)\n├── wit\u002F                     content-addressed WIT interface definitions\n└── home\u002F\n    └── {principal}\u002F         per-principal isolation\n        ├── .local\u002F\n        │   ├── capsules\u002F    user-installed capsules\n        │   ├── kv\u002F          capsule KV data\n        │   ├── log\u002F         capsule logs (daily rotation, 7-day retention)\n        │   ├── audit\u002F       per-principal audit chain\n        │   ├── tokens\u002F      capability tokens\n        │   └── tmp\u002F         VFS \u002Ftmp mount\n        └── .config\u002F\n            └── env\u002F         capsule env config overrides\n\n\u003Cproject>\u002F.astrid\u002F           workspace-level config (committable)\n├── workspace-id             UUID linking project to global state\n└── ASTRID.md                project-level agent instructions\n```\n\nConfiguration follows a precedence chain: workspace > user > system > env vars > compiled defaults. Workspace configs can only **tighten** security settings, never loosen them.\n\n## Multi-principal support\n\nEach principal (user identity) gets fully isolated capsules, KV data, audit chain, capability tokens, and logs under `home\u002F{principal}\u002F`. The acting principal is carried transparently through every IPC message chain — capsules never see or touch principal routing. KV namespace format: `{principal}:capsule:{name}`. Per-invocation principal resolution means cross-user invocations write to the correct principal's audit log and KV.\n\n## Architecture\n\nAstrid follows a strict kernel\u002Fuser-space divide. The kernel (native Rust daemon) owns all privileged resources. Capsules (WASM guests) have zero ambient authority and must request everything through the host ABI.\n\n### Kernel crates\n\n| Crate | Role |\n|---|---|\n| `astrid-kernel` | Boots the runtime. Owns VFS, IPC bus, capsule registry, MCP client, audit log, KV store. Listens on Unix socket for CLI connections. |\n| `astrid-approval` | `SecurityInterceptor`: the five-layer gate. Policy engine, budget tracker, allowance store, approval manager. |\n| `astrid-capabilities` | Ed25519-signed capability tokens with glob resource patterns and time bounds. |\n| `astrid-audit` | Chain-linked cryptographic audit log. Each entry is signed and hashes the previous. SurrealKV-backed with chain verification. Per-principal chain splitting. |\n| `astrid-vfs` | Copy-on-write overlay filesystem. `Vfs` trait with `HostVfs` and `OverlayVfs` implementations. Capability-based `DirHandle`\u002F`FileHandle`. |\n| `astrid-events` | IPC event bus. Broadcast-based with async receivers and synchronous subscriber callbacks. Types re-exported from `astrid-types`. |\n| `astrid-types` | Shared data types: IPC payloads, LLM schemas, kernel API. Minimal deps, WASM-compatible. Used by both kernel and SDK. |\n| `astrid-capsule` | Capsule runtime: manifest parsing, WASM\u002FMCP\u002Fstatic engines, dependency resolution via toposort, capsule registry, hot-reload watcher. |\n| `astrid-mcp` | MCP client\u002Fserver lifecycle. Wraps `rmcp` with binary hash verification, capability gating, and elicitation support. |\n| `astrid-crypto` | Ed25519 key pairs (via `ed25519-dalek`), BLAKE3 content hashing, signatures. Keys are zeroized on drop. |\n| `astrid-storage` | Two-tier persistence. Tier 1: raw KV via embedded SurrealKV. Tier 2: full SurrealDB query engine with SurrealQL. |\n| `astrid-config` | Layered TOML configuration: workspace > user > system > env > defaults. Workspace configs can only tighten security, never loosen it. |\n| `astrid-workspace` | Workspace boundary detection and process sandbox configuration. |\n| `astrid-hooks` | Hook system for session lifecycle, tool calls, and approval flows. Handlers: command, HTTP, WASM. |\n| `astrid-core` | Foundation types: `SessionId`, `PrincipalId`, `Permission`, identity primitives, elicitation types, session tokens. |\n\n### User-space crates\n\n| Crate | Role |\n|---|---|\n| [`astrid-sdk`](https:\u002F\u002Fgithub.com\u002Funicity-astrid\u002Fsdk-rust) | Safe Rust SDK for capsule authors. Mirrors `std` layout. Includes `astrid-sys` (syscall table) and `astrid-sdk-macros` (`#[capsule]` proc macro). Standalone repo. |\n| `astrid-openclaw` | TypeScript-to-WASM compiler for OpenClaw plugin compatibility. All-Rust pipeline: OXC + QuickJS\u002FWizer. |\n\n### Binaries\n\n| Binary | Crate | Role |\n|---|---|---|\n| `astrid` | `astrid-cli` | Terminal frontend. Connects to daemon over Unix socket. TUI rendering, headless\u002Fscripting mode, capsule management, distro init, daemon lifecycle commands. |\n| `astrid-daemon` | `astrid-daemon` | Background kernel process. Boots the kernel, loads capsules, serves IPC requests. `--ephemeral` flag for CLI-spawned instances. |\n| `astrid-build` | `astrid-build` | Capsule compiler and packager. Handles Rust, OpenClaw (JS\u002FTS), and legacy MCP projects. Invoked by CLI as a companion binary. |\n\n### Infrastructure crates\n\n| Crate | Role |\n|---|---|\n| `astrid-telemetry` | Structured logging with `tracing`. JSON and human-readable outputs. File-based output with daily rotation. |\n| `astrid-prelude` | Common re-exports for internal crates. |\n\n## Storage\n\nTwo tiers, one API surface:\n\n| Deployment | KV backend | DB backend |\n|---|---|---|\n| Dev \u002F single-agent | SurrealKV (embedded) | SurrealDB (embedded, SurrealKV) |\n| Production \u002F multi-node | SurrealKV (embedded) | SurrealDB (over TiKV, Raft) |\n\nCapsule KV stores are namespace-scoped per principal and per capsule. The kernel, audit log, capability store, and identity system use the DB tier. Scaling from embedded to distributed is a config change.\n\n## v0.5.0 highlights\n\nThe major changes in this release:\n\n- **FHS directory layout** — `~\u002F.astrid\u002F` restructured to `etc\u002F`, `var\u002F`, `run\u002F`, `log\u002F`, `keys\u002F`, `bin\u002F`, `home\u002F`. Existing `~\u002F.astrid\u002F` must be deleted before upgrading (no migration path).\n- **Multi-principal isolation** — each principal gets isolated capsules, KV, audit chain, tokens, and config under `home\u002F{principal}\u002F`.\n- **Tools are a pure IPC convention** — the kernel no longer parses or manages tool schemas. Tool capsules use IPC interceptors. The router capsule handles discovery and dispatch.\n- **LLM providers are a pure IPC convention** — `[[llm_provider]]` and `LlmProviderDef` removed from the manifest. LLM capsules self-describe via interceptors.\n- **`[imports]`\u002F`[exports]` manifest format** — replaces the old string-array `[dependencies]` with namespaced TOML tables, semver version requirements, optional imports, and namespace\u002Finterface name validation.\n- **`astrid self-update`** — downloads platform-specific binaries from GitHub releases to `~\u002F.astrid\u002Fbin\u002F`, no sudo required. Startup update banner (cached 24h).\n- **`astrid init` distro system** — fetches `Distro.toml`, multi-select provider groups, `{{ var }}` template resolution, atomic `Distro.lock` writes with BLAKE3 hashes.\n- **Export conflict detection** — `astrid capsule install` detects when a new capsule exports interfaces already provided by an installed capsule and prompts to replace.\n- **Interceptor priority** — `priority` field on `[[interceptor]]` enables layered interception chains.\n- **Short-circuit interceptors** — `Continue`, `Final`, or `Deny` wire format controls the middleware chain.\n- **Per-principal audit chains** — independently verifiable via `verify_principal_chain()`.\n- **`astrid capsule tree`** — renders the imports\u002Fexports dependency graph.\n- **OpenClaw Tier 2** — TypeScript plugins with npm dependencies install, transpile, and run as MCP capsules.\n- **`--snapshot-tui`** — renders the full TUI to stdout for automated smoke testing without an interactive terminal.\n\nSee [CHANGELOG.md](CHANGELOG.md) for the complete list of changes, fixes, and breaking changes.\n\n## Current state\n\n**v0.5.0.** The core runtime works end-to-end:\n\n- Kernel boots, discovers and loads capsules, manages VFS overlay, listens on Unix socket\n- `SecurityInterceptor` with all five layers, tested with policy blocks, budget exhaustion, token auth, session\u002Fworkspace allowances, and the \"Allow Always\" token minting path\n- WASM sandbox with 49 host functions, 64 MB memory ceiling, 5-minute tool timeout\n- Chain-linked audit log with ed25519 signatures and per-principal chain integrity verification\n- MCP client (2025-11-25 spec) via `rmcp` with capability gating and binary hash verification\n- IPC event bus with broadcast subscribers and capability-scoped publish\u002Fsubscribe ACLs\n- Capsule dependency resolution via topological sort with semver-versioned interface matching\n- Capsule manifest supporting commands, skills, interceptors, IPC topics, MCP servers, and uplinks\n- OpenClaw TypeScript-to-WASM compiler (OXC + QuickJS\u002FWizer, Tier 1 and Tier 2)\n- CLI with TUI, streaming responses, session persistence, headless mode, capsule management\n- Distro system with `Distro.toml` manifests and `Distro.lock` for reproducible installs\n- Layered configuration with workspace-level security tightening\n- `astrid self-update` downloading from GitHub releases\n\n**Not yet done:** Multi-node SurrealDB (TiKV\u002FRaft). WASM Component Model migration (Extism to WIT bindings). Additional frontends beyond CLI. Capsule registry for distribution.\n\n## Development\n\n```bash\n# Build\ncargo build --workspace\n\n# Test\ncargo test --workspace -- --quiet\n\n# Lint\ncargo clippy --workspace --all-features -- -D warnings\ncargo fmt --all -- --check\n```\n\nAll crates enforce `#![deny(unsafe_code)]` except `astrid-sys` and `astrid-sdk` (WASM FFI requires it). Clippy runs at pedantic level. Integer arithmetic overflow is a lint error (`clippy::arithmetic_side_effects = \"deny\"`).\n\nRelease binaries for macOS (x86_64, aarch64) and Linux (x86_64, aarch64) are built automatically on tag push via the [release workflow](.github\u002Fworkflows\u002Frelease.yml).\n\n## Operator documentation\n\n- [Gateway deployment runbook](docs\u002Fgateway-deployment.md) — setting up the HTTP admin gateway behind a reverse proxy or with native TLS, monitoring, key rotation, troubleshooting.\n- [Generating a gateway API client](docs\u002Fgateway-client.md) — building a browser\u002Fnative client against the HTTP admin API from the OpenAPI spec, and why it doesn't belong in the capsule SDKs.\n- [Unified config schema](docs\u002Fconfig.md) — `astrid.toml` reference.\n- [SDK ergonomics notes](docs\u002Fsdk-ergonomics.md) — capsule-author guidance.\n\n## Contributing\n\nContributions are welcome. Astrid uses a tiered contributor system to protect security-critical code while keeping the door open for new contributors. Every PR must be linked to a GitHub issue. See [CONTRIBUTING.md](CONTRIBUTING.md) for the full process, including issue-first workflow, tier descriptions, and security-critical crate restrictions.\n\n## License\n\nDual-licensed under [MIT](LICENSE-MIT) and [Apache 2.0](LICENSE-APACHE).\n\nCopyright (c) 2025-2026 Joshua J. Bouw and Unicity Labs.\n","Astrid是一个专为AI代理设计的操作系统。它采用Rust语言开发，具备用户空间微内核架构，能够像Linux操作系统对待进程一样管理AI代理，支持虚拟文件系统、基于ed25519的权限令牌、IPC事件总线、WASM进程隔离以及加密审计跟踪等核心功能。Astrid通过胶囊（capsule）机制实现高度可配置性，允许用户根据具体需求组合不同的胶囊而不需修改核心代码，非常适合需要灵活定制AI代理行为的场景，如离线运行、构建新颖的代理架构、透明缓存以降低大模型成本或创建能够在无人干预下工作的自主代理。",2,"2026-06-11 04:10:22","top_language"]