[ymote]

Adds docs/ai-services.md and docs/ai-services.zh-CN.md, and a short "AI services (octos)" section in README.md and README.zh-CN.md that links to them. Docs only.

What the page covers

• Architecture (with a Mermaid diagram): one octos kernel per shell. On a desktop it runs the binary OCTOS_APP_CORE_BIN names, on Android the APK's liboctos.so, on OpenHarmony it runs in process, and iOS has none. Also covered: AI providers and the llm host service, crates/ai-host, the app-peers broker, the system agent, AppCard and the AI pane.
• Trust model: keys and secrets stay with the host, only the person approves and does it in the owning app, the system agent holds no app tools, memory is app/<app>/acct-<hash>, and grants match exact names.
• What each kind of app can use today:
  • Native modules (Rinx) get an app peer, contexts and approvals. Rinx's tools are reached through its ServiceExecutor; peer tool registration waits on octos#2567.
  • Rinx mini apps get octos.* through Rinx's host.
  • Contained script apps get nothing yet. The Card runner registers mail, llm (os.* only, provider management), news (os.* only) and glance (os.* only), but no octos service. The page lists the exact errors they see.
• ADR 0002, piece by piece, with the status of each and links. Merged: News M1: news data service (feeds, ledger, tools; no LLM) #69 and News M4: glance.publish, published L0 cards on the glance page and a desktop panel #72. In progress: glance: contained apps publish with the glance capability, not by being os.* #86, glance: resolve sys.digest sources from host-held digests (ADR 0002 M4) #87, feat(toolbox): the system toolbox's workflow template library #82 and octos#2567/#2568. Planned: issues News M2: tool manifest, AGENT.md and an app peer for a contained app #61–Tracking: ADR 0002 first slice — News (M1–M8) #68. It also notes that the shells' App Hub pin (46d67e51) predates the new agent fields and the news and glance capabilities.
• Running it locally: a throwaway kernel and profile, the hidden-window remote scripts, the tests, and the phone.

Verified

• The desktop (cargo build --release -p octosense at 405139f) ran hidden with the exact env from step 2, using octos built at a6ea8505 with the documented command. The log showed octos: kernel service ready (starts on first use), core dir …/octos-home/.octos and llm: provider profile under …. AI providers opened from the launcher (card: os.ai-providers running under 2 capability(ies)…). Nothing was written outside the temp dir.
• Every test command in the page passes: cargo test --locked -p octosense-kernel, -p octosense-app-peers --features octos-core,ws and -p octosense-ai-host --features octos-core,llm. Both real-kernel tests pass against that octos build: kernel 1/1 and app-peers 6/6.
• The contained-app errors were run in card-host (App Hub 362d832) with a probe app:
  • no service answers "octos" on this device
  • this app was not granted "octos", which "octos.session.open" needs
  • no service answers "llm" on this device
• Relative links (checklinks.py) and in-page anchors check clean.

Not verified

• Adding a provider with a real key, and a Rinx turn on the desktop (this needs a Matrix sign-in).
• The phone steps. These are taken from phone/README.md and tools/kernel-artifact.py.

Companion PRs: OctoScript-App-Design-Flow (the developer page docs/AI-SERVICES.md) and OctoSense-App-Hub (status notes in PUBLISHING).

🤖 Generated with Claude Code