bazilion 0.0.0 → 0.1.0

package/docs/backlog/README.md

@@ -1,42 +0,0 @@
-# Bazilion — Product Backlog
-
-Backlog items live in this directory, one file per item, organised by state.
-
-```
-docs/backlog/
-├── draft/        ← needs more definition / open questions / explicitly deferred
-├── todo/         ← refined, ready to pull into a sprint
-├── in_progress/  ← actively being worked on right now
-└── done/         ← shipped, kept as a historical record
-```
-
-## Conventions
-
-- **Naming:** `BAZ-NNN-short-slug.md` (sequential at creation time so codes don't shift when priority changes).
-- **Frontmatter** (every file): `id`, `title`, `status`, `size`, `created`, optional `shipped` / `priority` / `deferred` / `deferred_reason` / `note`.
-- **Body shape:** User stories (As a / I want / So that) → Goal → Why → Scope → Out of scope → Tests. Open items add Open Questions; shipped items add an As-built block.
-- **Sizes** (solo-dev pace): XS ≈ afternoon, S ≈ 1–2 days, M ≈ ~1 week, L ≈ 1–2 weeks, XL > 2 weeks → split into multiple BAZs.
-- **State transitions:** to move an item, `git mv` it between dirs and update the `status:` field in frontmatter.
-
-## State definitions
-
-- **Draft** — captured but not committed-to. Has open questions, missing acceptance criteria, or no forcing function. Don't start work without resolving the open questions.
-- **Todo** — refined and ready. User stories + scope are clear; pulling it into a sprint is a yes/no decision, not a "let's first figure out what this means" decision.
-- **In Progress** — actively being worked on right now. Move here from `todo/` when implementation starts, so it's clear what's in flight. There's no enforced limit — solo-dev pace usually keeps this folder at 0–1 items, but a refactor with multiple side BAZs in parallel is fine. Move to `done/` when shipped.
-- **Done** — shipped. The file becomes part of the project's release history; the `As-built` block records what actually happened (vs. what was planned).
-
----
-
-## Draft (1)
-
-| ID | Title | Size | Notes |
-|----|-------|------|-------|
-| [BAZ-001](draft/BAZ-001-a2a-federation-spike.md) | Spike — federated multi-employee Bazilion via A2A | S | Investigation only; output is a follow-up implementation BAZ |
-
-## Todo (0)
-
-_None yet._
-
-## Done (0)
-
-_None yet._

package/docs/backlog/draft/BAZ-001-a2a-federation-spike.md

@@ -1,125 +0,0 @@
----
-id: BAZ-001
-title: Spike — federated multi-employee Bazilion via A2A
-status: draft
-size: S (timebox 1–2 days, investigation only)
-created: 2026-05-17
-note: Spike — output is a recommendation + a follow-up BAZ with the chosen approach scoped, not shipped code. Do not pull this BAZ expecting deliverable software.
----
-
-# BAZ-001 — Spike — federated multi-employee Bazilion via A2A
-
-**Status:** Backlog (draft, spike). Today Bazilion is single-tenant per install: one operator, one bootstrap token (= god mode), all state under `~/.bazilion/` on one box. Inter-agent communication (`send_message` / `read_inbox` / `wait_for_reply`) is in-process inside the daemon, with `MessagingHost` injected either as `createDbMessagingHost(db)` (compact/context routes) or `createIpcMessagingHost()` (worker subprocess, proxied over Node IPC). To make Bazilion usable inside a company without rebuilding it as multi-tenant SaaS, an alternative direction is: every employee runs their own Bazilion, installs speak to each other over A2A (Google's Agent-to-Agent protocol, or a comparable open spec) so that `alice@acme/refactor-helper` can be invoked from Bob's box. This spike resolves the open questions before an implementation BAZ is written.
-
-**Dependency:** None on code; depends on a product decision that federation is the target shape (vs. SaaS or hardened multi-user self-hosted).
-
-## User stories (spike)
-
-- **As the operator considering company adoption**, I want a documented, decided answer to "is A2A-based federation viable as Bazilion's company-deployment story, and what's the smallest end-to-end slice that proves it", so the implementation BAZ can be scoped + estimated without revisiting the protocol choice mid-flight.
-- **As a future employee installing Bazilion on my laptop**, I want the spike to define how my install discovers and trusts other employees' installs without each pair needing manual setup, so the onboarding step is "install + join company directory", not "exchange certs with every coworker".
-- **As the operator legally responsible for audit and offboarding**, I want the spike to surface what minimum centralised infrastructure is required (directory? PKI? audit sink?) even in a peer-to-peer runtime, so the "central infra footprint" decision is informed, not accidental.
-
-## Goal
-
-Produce a written recommendation that answers the questions below with enough detail that a follow-up implementation BAZ can be drafted, sized, and pulled. **Strict timebox: 1–2 days.** No code lands from this BAZ beyond a throwaway sandbox proof-of-concept if needed to validate the wire model (e.g. a minimal A2A endpoint serving one agent card and round-tripping one message between two local installs on different ports).
-
-## Why now
-
-The exploratory conversation surfaced federation as a credible alternative to SaaS that preserves Bazilion's single-tenant ethos ("bleeding-edge personal software, skip compat shims"). Before committing direction — and before any of the existing internals (the in-process `MessagingHost`, the `~/.bazilion/groups/<slug>/` filesystem-rooted group model, the bootstrap-token-equals-god-mode auth) get refactored in ways that prematurely lock in either direction — confirm whether federation actually answers the company-deployment question or whether it just punts the hard problems to a different layer.
-
-## Questions to answer
-
-1. **Protocol choice — A2A vs. alternatives.**
-   - Google A2A (agent cards, task lifecycle, SSE-based streaming responses): the obvious candidate, openly published, framework-agnostic, maps directly onto Bazilion's existing `ChatFrame` NDJSON shape.
-   - MCP (Model Context Protocol): solves agent ↔ tool, not agent ↔ agent. Probably wrong for this use case but document the rejection.
-   - Custom HTTP + WebSocket between Bazilion installs: maximum control, minimum interop. Reject unless A2A has a hard incompatibility with Bazilion's existing shapes.
-   - Matrix / NATS / similar message bus: solves the async-delivery problem (laptops sleep) but doesn't define agent semantics; could compose with A2A rather than replace it.
-   - Decision criterion: pick the option that gives the smallest delta from the existing in-process `MessagingHost` shape while interoperating with non-Bazilion agents (a third-party A2A-speaking agent should be addressable too).
-
-2. **Discovery — how does Alice's install resolve `bob@acme/code-reviewer`?**
-   - Static config (each install lists every other install): trivial, doesn't scale past a handful of employees.
-   - mDNS / Tailscale magic DNS: works on shared networks (Tailnet, office LAN), breaks across geographies and home networks.
-   - Thin company "directory" service: a small centralised HTTP service that maps `<user>@<company>` to a current endpoint URL + presence + public key fingerprint. Each install registers itself on startup and refreshes a TTL.
-   - DNS-based (SRV records under `acme.com`): elegant but requires DNS ops and doesn't carry presence.
-   - Recommendation expected: thin directory service. Confirm the smallest surface (probably 3 endpoints: register, lookup, list).
-
-3. **Identity / trust — what authenticates an A2A call from Alice's install to Bob's?**
-   - mTLS with per-install certs issued by a company CA: standard, secure, requires CA infrastructure.
-   - Signed messages (per-install Ed25519 key, signature over the request body): simpler than mTLS, no CA per se but still needs key distribution → back to directory service holding pubkeys.
-   - OIDC + JWT bearer per call (the directory service issues short-lived tokens after the operator authenticates via SSO): heavier on the directory, lighter on the install.
-   - Today's bootstrap-token-equals-god-mode is incompatible with any of the above — `isValidToken` in `apps/daemon/src/lib/auth.ts` will need to grow a "remote A2A peer" code path that does NOT grant the same powers as a loopback bearer.
-   - Decision criterion: pick the option with the smallest surface that still supports per-agent ACLs (next question).
-
-4. **Per-agent authorization — who can invoke which of my agents.**
-   - Today: token holders can do everything. A federated story needs `alice` to expose `refactor-helper` to "the whole company", `code-reviewer` to "team-platform", and `personal-todo` to nobody.
-   - Schema sketch: an `agent_exposures(agent_id, audience, capability)` table on each install. `audience` could be `*`, `@company`, `@group:platform`, `@user:bob@acme`. `capability` could be `chat`, `read_inbox`, `read_skills_list`.
-   - Default-deny: a newly spawned agent is local-only until the operator publishes it.
-   - Open question: where does the audience definition live? On the directory service (single source of truth) or on each install (federated and possibly inconsistent)?
-
-5. **Async delivery — laptops sleep.**
-   - Bazilion's existing inbox model (`send_message`, `read_inbox`, `wait_for_reply`) is already async-friendly within a single install. Extending it cross-install means: when Alice sends to `bob@acme/code-reviewer` and Bob's box is offline, the message must be durably queued somewhere.
-   - Option A: sender retries with backoff until receiver online. Simple but requires sender to stay online too.
-   - Option B: directory service has a per-user store-and-forward inbox (HTTP PUT to deposit, HTTP GET to drain when online). The directory grows from "thin registry" into "small message broker"; design implication for question 2.
-   - Option C: third-party message bus (Matrix federation, NATS JetStream). External dep, but separates concerns cleanly.
-   - Recommendation expected: option B for the first cut (operationally simpler than running a Matrix homeserver), with the door left open to swap in C later.
-
-6. **Cross-install group state — the deepest problem.**
-   - Today: a Bazilion group is `~/.bazilion/groups/<slug>/` (real dir or symlink) + the `groups.user_md` DB column + shared qmd memory at `<group.path>/memory/`. Every member of the group writes to the same store.
-   - Federated equivalent: "Alice and Bob both belong to the platform-team group" — where does the group filesystem live? Where do the shared memory writes go?
-   - Option A — **single-owner groups**: a group lives on exactly one employee's install (its "host"). Other employees join as remote guests via A2A; their `memory_*` tool calls become A2A round-trips to the host. Loses local availability for guests when the host is offline. Simple to implement, big UX limitation.
-   - Option B — **mirrored groups with sync**: each member's install has a local copy of group state; changes sync via CRDT or last-writer-wins. Genuinely hard (qmd index conflicts, USER.md merge conflicts, file content conflicts) and changes the on-disk model materially.
-   - Option C — **directory-hosted groups**: the directory service stores group memory and USER.md; every install reads/writes via the directory. Centralises the most contested piece of state.
-   - Recommendation expected: option A for the first cut (smallest delta from today's code). Explicitly document the limitation; revisit if the limitation becomes the dominant complaint.
-
-7. **Offboarding + audit — the compliance angle.**
-   - When Alice leaves Acme: who can revoke her A2A access? Who gets her agent transcripts? Who shuts down her install's group-host role for groups she was hosting (option A from question 6)?
-   - Pure peer-to-peer makes this brittle. A central component (the directory) is the natural revocation point — yanking Alice's directory entry makes her unaddressable.
-   - Centralised audit: even with a federated runtime, compliance will likely want all transcripts streamed to a central audit sink. pi's session JSONL files are local-only today; the design should at least define the streaming hook (a webhook fired per `SessionEvent`?), even if the spike doesn't implement it.
-   - Output of the spike: a one-paragraph plain-English summary of "what central infra is mandatory for a viable company deployment" so the operator can decide whether to commit to running a directory + audit sink, or whether that footprint reframes the decision toward SaaS.
-
-8. **Implementation surface — what changes in the current codebase.**
-   - `apps/daemon/src/lib/messaging-host.ts`: a third host shape (`createA2AMessagingHost(directoryUrl)`) that resolves `alice@acme/...` addresses via the directory, then makes A2A calls.
-   - `apps/daemon/src/routes/`: a new `a2a.ts` exposing this install's agents over A2A's task/streaming endpoints, gated by the per-agent authorization model (question 4).
-   - `apps/daemon/src/lib/middleware-auth.ts`: a second code path for A2A peer auth that does NOT grant bootstrap-token powers (question 3).
-   - The `MessagingHost` interface itself probably needs to grow remote addressing semantics (address parsing for `<user>@<company>/<agent>`) — confirm whether the existing signatures cover this or need a v2.
-   - Worker IPC: workers today RPC the daemon for messaging via `createIpcMessagingHost`. Cross-install calls still resolve at the daemon (workers don't speak A2A directly), so the worker side likely doesn't change.
-
-## Out of scope (for the spike)
-
-- **Picking the directory hosting model** (self-hosted by the operator vs. a hosted service). That's an ops decision the implementation BAZ inherits.
-- **Identity provider integration** (SSO via Okta / Azure AD / Google Workspace). The spike assumes the directory has *some* way to authenticate users; which IDP is plumbing for the implementation BAZ.
-- **Billing / cost attribution.** Each install uses its own provider keys today; that's the federated default and doesn't need solving at the spike stage.
-- **A2A spec compliance certification.** The spike validates that the protocol fits Bazilion's shape; full conformance testing is implementation work.
-- **Mobile client A2A.** `apps/mobile` today talks only to its paired daemon. Federated mobile is a follow-on concern, not a spike concern.
-- **Multi-tenant within a single install.** Federation deliberately avoids this — each install stays single-tenant; multi-tenant per-install is the SaaS direction and would be a different BAZ.
-
-## Deliverable
-
-A new BAZ file `docs/backlog/todo/BAZ-NNN-a2a-federation-implementation.md` (number assigned at spike-completion time) containing:
-
-1. The chosen protocol (A2A vs. alternative) + one-paragraph rationale.
-2. The directory service shape: language/runtime, hosting model, endpoint surface, auth model. (Could itself be a separate BAZ if the directory turns out to be a non-trivial service.)
-3. The per-install changes: routes added, middleware changes, `MessagingHost` shape, schema additions for `agent_exposures` + remote-peer auth.
-4. The cross-install group model decision (single-owner / mirrored / directory-hosted) + rationale + a one-paragraph description of the limitation it accepts.
-5. The async-delivery model (sender-retries / directory-inbox / external-bus) + rationale.
-6. The compliance hook (audit-streaming webhook? per-`SessionEvent` outbound?) — at minimum, a defined surface even if implementation is deferred.
-7. A size estimate (S/M/L/XL) and explicit dependencies. If the answer is XL, split into multiple BAZs at this point.
-8. The smallest end-to-end slice that proves the model works (e.g. "two local installs on ports 4321/4421, each exposes one agent over A2A, one invokes the other through the directory, audit log captures the call") — this is what the first implementation BAZ ships.
-
-The implementation BAZ (or BAZs) is what gets pulled into a sprint. **This BAZ (BAZ-001) closes when that file lands.**
-
-## Open questions to confirm with the operator before starting the spike
-
-1. **Is federation actually the chosen direction**, or is this spike comparing federation against hardened-multi-user-self-hosted and SaaS as siblings? If sibling-comparison, the spike's deliverable is a three-way recommendation, not a federation implementation plan — which roughly doubles the timebox.
-2. **Target company size for the first deployment** — 5 employees? 50? 500? The directory service shape and the group-state decision both flex significantly between those numbers.
-3. **Operator's appetite for running central infrastructure** — "I'll happily run a small directory + audit sink on Kamal / Fly / a VPS" keeps federation in play; "I want zero central infra" forces the spike to investigate fully peer-to-peer alternatives (BitTorrent-style DHT discovery, gossip-based presence) which are research-grade and probably push the size to L or XL.
-4. **Interop ambition** — does Bazilion want to be addressable from non-Bazilion A2A clients (a Google ADK agent, a LangGraph agent), or is A2A just an internal wire format between Bazilion installs? Affects strictness of spec compliance and how much of A2A's surface needs implementing.
-
-## Tests (sketch — for the eventual implementation BAZ, not the spike itself)
-
-- Two Bazilion installs on the same machine, different ports, register with a local directory; install A invokes an agent on install B via A2A; the `ChatFrame` NDJSON stream round-trips end-to-end through the new `MessagingHost`.
-- Per-agent ACL: an agent published to `@group:platform` rejects a call from a peer not in that group; the rejection is logged on both sides.
-- Offline-recipient delivery: install A sends to an agent on install B while B is down; B comes online and drains the queued message via whatever path question 5 picks.
-- Cross-install group memory: a `memory_write` from install A appears in subsequent `memory_search` results from install B (assuming the chosen group-state model supports it; if option A from question 6 wins, the test instead asserts that B's `memory_*` tool calls correctly proxy to A as host).
-- Peer-auth code path: an A2A call presenting a valid peer credential CANNOT escalate to bootstrap-token actions (e.g. cannot mint new tokens, cannot read `auth.json`, cannot list other agents not exposed to it).
-- Compliance hook (if scoped into the first implementation BAZ): an A2A-initiated turn produces an audit event with the remote caller's identity stamped on it.

package/docs/openclaw-reference.md

@@ -1,210 +0,0 @@
-# OpenClaw — reference for Bazilion contributors
-
-Bazilion's README and `CLAUDE.md` call the project "OpenClaw-inspired", and the daemon literally reads `~/.openclaw/skills/` when you run `bazilion skill import --from openclaw`. This doc captures what upstream OpenClaw actually is, so contributors know what we borrowed, what we deliberately didn't, and where the format we accept comes from.
-
-Snapshot date: 2026-05-17. Source: `docs.openclaw.ai` + `github.com/openclaw/openclaw` `main`. Re-fetch before relying on exact counts.
-
-## 1. What OpenClaw is
-
-A self-hosted personal AI-assistant gateway — *not* a Claude Code clone. Repo: `github.com/openclaw/openclaw`. Docs: `docs.openclaw.ai`. License: MIT. Runs on Node 22.12+. Install: `npm i -g openclaw && openclaw onboard` (or `curl -fsSL https://openclaw.ai/install.sh | bash`).
-
-It speaks to the user over channels they already use (WhatsApp, Telegram, iMessage, Signal, IRC, Mattermost, voice), holds persistent memory, and is LLM-agnostic (~35 model-provider plugins). The mascot is a lobster; the slogan is "the lobster way".
-
-The two extensibility surfaces are **skills** and **plugins**. They are *not* interchangeable.
-
-## 2. Skills vs plugins — the actual difference
-
-From the docs, verbatim: *"Skills tell the agent how to do things. Plugins give the agent new abilities it couldn't have otherwise."*
-
-| Axis | Skill | Plugin |
-|---|---|---|
-| What it is | A directory with a `SKILL.md` (YAML frontmatter + markdown body) | An npm-shaped TypeScript package loaded in-process by the gateway |
-| What it adds | New *knowledge* — instructions the LLM follows using already-available tools | New *capability* — new channels, model providers, tools, memory backends, lifecycle hooks |
-| Runtime cost | Zero — only text is injected into the prompt (progressive disclosure: YAML metadata loaded eagerly, body loaded on description match) | Live code running inside the gateway process |
-| Author writes | Markdown | TypeScript |
-| Manifest | YAML frontmatter inside `SKILL.md` | Separate `openclaw.plugin.json` (declarative) + the npm package's `package.json` (code + deps) |
-| Install source | ClawHub registry, local dir, bundled | `clawhub:<pkg>`, `npm:<pkg>`, `git:<repo>@<ref>`, `./local` |
-| Discovery | Directory scan (precedence-ordered, see §5) | Listed in `openclaw.json`, loaded at gateway start |
-| Hooks | None — skills are pure prompt content | 28 lifecycle hooks across model/agent/message/tool/session/sub-agent layers |
-| Failure blast radius | A bad skill produces bad answers | A bad plugin can crash the gateway, leak secrets, intercept every tool call |
-| Trust gate needed | No (text only) | Yes (arbitrary code) |
-| Can ship the other? | No — a skill cannot register code | Yes — a plugin may bundle skills via a `skills` directory referenced in its manifest |
-
-**Rule of thumb:** if the new behavior can be expressed as "tell the agent, in English, how to use existing tools to do X", it's a skill. If it needs to register a new model provider, a new transport, a custom tool, or hook into the request/tool lifecycle, it's a plugin. The split exists because most "I want my agent to know how to do X" requests are content, not code — and content is far cheaper to author, distribute, and trust.
-
-## 3. Default skills (~57 bundled in `skills/` on `main`)
-
-Grouped by purpose (slugs match `github.com/openclaw/openclaw/tree/main/skills`):
-
-| Category | Skills |
-|---|---|
-| Messaging / chat | `imsg`, `wacli` (WhatsApp), `discord`, `slack`, `voice-call`, `xurl` (X/Twitter) |
-| Productivity / tasks | `apple-notes`, `apple-reminders`, `bear-notes`, `notion`, `obsidian`, `things-mac`, `trello`, `taskflow`, `taskflow-inbox-triage`, `spike` |
-| Google / Office | `gog` (Gmail/Calendar/Drive/Docs/Sheets), `goplaces`, `gh-issues`, `github` |
-| Smart-home / hardware | `openhue` (Hue), `eightctl` (Eight Sleep), `sonoscli`, `blucli` (BluOS), `camsnap` (RTSP cams) |
-| Media / generation | `canvas`, `diagram-maker`, `meme-maker`, `gifgrep`, `nano-pdf`, `video-frames`, `songsee`, `summarize` |
-| Speech | `openai-whisper`, `openai-whisper-api`, `sherpa-onnx-tts`, `sag` (ElevenLabs TTS) |
-| Coding / dev | `coding-agent`, `gemini` (Gemini CLI), `tmux`, `node-connect`, `node-inspect-debugger`, `python-debugpy`, `oracle`, `peekaboo` (macOS UI automation) |
-| Email / RSS | `himalaya` (IMAP/SMTP), `blogwatcher` |
-| Utility / infra | `1password`, `clawhub` (registry mgmt), `healthcheck`, `mcporter` (MCP bridge), `model-usage`, `session-logs`, `skill-creator`, `weather`, `spotify-player`, `ordercli` |
-
-### Skill file layout
-
-A skill is a directory whose only required file is `SKILL.md`. Helper scripts are optional and referenced via `{baseDir}`. No separate `metadata.json` — everything lives in YAML frontmatter:
-
-```yaml
----
-name: summarize
-description: "Summarize or transcribe URLs, YouTube/videos, podcasts, articles, transcripts, PDFs, and local files."
-homepage: https://summarize.sh
-metadata:
-  {
-    "openclaw":
-      {
-        "emoji": "🧾",
-        "requires": { "bins": ["summarize"] },
-        "install":
-          [ { "id": "brew", "kind": "brew",
-              "formula": "steipete/tap/summarize",
-              "bins": ["summarize"],
-              "label": "Install summarize (brew)" } ]
-      }
-  }
----
-```
-
-Required frontmatter: `name`, `description`. Optional: `homepage`, `version`, `user-invocable` (slash command), `hidden`, `command-dispatch` / `command-dispatch-tool` (bypass model — direct tool dispatch), `command-arg-mode`, `disable-model-invocation`, and a **single-line JSON** `metadata.openclaw` object holding `emoji`, `requires.{bins,env}`, `primaryEnv`, `os`, and `install[]` recipes (brew/npm/pip/etc.). The parser only supports single-line frontmatter values.
-
-## 4. Default plugins (~120 in the inventory)
-
-From `docs.openclaw.ai/plugins/plugin-inventory`. The inventory doesn't flag which are on by default — only that model providers, speech, and the browser plugin are auto-enabled.
-
-| Category | Plugins |
-|---|---|
-| Model providers (~35) | Anthropic, OpenAI, Google, Groq, Cerebras, DeepSeek, Fireworks, GitHub Copilot, Hugging Face, LM Studio, Ollama, Mistral, Moonshot, OpenRouter, Qwen, Together, vLLM, xAI, Z.AI, Arcee, BytePlus, Chutes, DeepInfra, Kilocode, Kimi, LiteLLM, NVIDIA, OpenCode, OpenCode Go, Qianfan, StepFun, Synthetic, Venice, Vercel AI Gateway, Volcengine, Xiaomi |
-| Channels | Clickclack, iMessage, IRC, Mattermost, Signal, Telegram |
-| Speech / media | Azure Speech, Deepgram, ElevenLabs, Gradium, Inworld, Microsoft Speech, TTS Local CLI |
-| Web / search | DuckDuckGo, Exa, Firecrawl, Perplexity, SearXNG, Web Readability |
-| Image / video gen | Alibaba, ComfyUI, FAL, Minimax, OpenRouter, Runway, Together |
-| Memory | Memory Core, Memory Wiki, Voyage |
-| Infra / utilities | Admin HTTP RPC, Bonjour, Browser, Canvas, Document Extract, File Transfer, LLM Task, Migrate Claude, Migrate Hermes, OC Path, Open Prose, Skill Workshop, Tokenjuice, Webhooks |
-
-### Plugin manifest (`openclaw.plugin.json`)
-
-Declarative only — runtime code lives in the npm package itself. Minimum:
-
-```json
-{
-  "id": "plugin-name",
-  "configSchema": { "type": "object", "additionalProperties": false, "properties": {} }
-}
-```
-
-Optional fields: `name`, `description`, `version`, `providers[]`, `channels[]`, `contracts` (capability snapshot), `activation` (activation-planner metadata), `setup`, `uiHints`.
-
-### Plugin hooks (28, six categories)
-
-- **Model resolution:** `before_model_resolve`
-- **Agent lifecycle:** `agent_turn_prepare`, `before_prompt_build`, `before_agent_{start,run,reply,finalize}`, `agent_end`, `heartbeat_prompt_contribution`
-- **Message flow:** `model_call_{started,ended}`, `llm_{input,output}`, `message_{received,sending,sent}`, `before_dispatch`, `reply_dispatch`, `inbound_claim`
-- **Tools:** `before_tool_call` (rewrite params, block, or require approval), `after_tool_call`, `tool_result_persist`, `before_message_write`
-- **Sessions / compaction:** `session_{start,end}`, `before_compaction`, `after_compaction`, `before_reset`
-- **Sub-agents / gateway:** `subagent_{spawning,delivery_target,spawned,ended}`, `gateway_{start,stop}`, `cron_changed`, `before_install`
-
-Bundled hook packs: `session-memory`, `command-logger`, `bootstrap-extra-files`. Plugins may also ship hooks inline.
-
-## 5. On-disk layout, config, discovery
-
-```
-~/.openclaw/
-  openclaw.json          # JSON5 config
-  skills/                # managed/local skills
-  credentials/           # channel + provider creds
-  agents/<id>/agent/auth-profiles.json
-  workspace/             # default workspace (overridable)
-    skills/<name>/SKILL.md
-    .agents/skills/<name>/SKILL.md
-~/.agents/skills/        # personal (non-workspace) agent skills
-```
-
-**Config — `openclaw.json`** (JSON5):
-
-```json5
-{
-  skills: {
-    entries: {
-      "image-lab": { enabled: true },
-      "peekaboo":  { enabled: true },
-      "sag":       { enabled: false },
-    },
-  },
-}
-```
-
-**Skill load order (highest precedence wins):**
-
-1. `<workspace>/skills`
-2. `<workspace>/.agents/skills`
-3. `~/.agents/skills`
-4. `~/.openclaw/skills`
-5. Bundled (shipped with install)
-6. `skills.load.extraDirs`
-
-Discovery is a directory scan — no index file. On name collision, the higher source wins. Enable/disable is **config-only**: `skills.entries.<name>.enabled` in `openclaw.json` overrides even bundled skills. SKILL.md frontmatter has no `enabled` flag.
-
-### CLI surface
-
-```
-openclaw skills search "calendar" [--limit 20] [--json]
-openclaw skills install <slug> [--version <v>] [--force] [--agent <id>]
-openclaw skills update <slug> | --all [--agent <id>]
-openclaw skills list [--eligible] [--json] [--verbose] [--agent <id>]
-openclaw skills info <name> [--json] [--agent <id>]
-openclaw skills check [--agent <id>] [--json]
-
-openclaw plugins install clawhub:<pkg>
-openclaw plugins install npm:<pkg>
-openclaw plugins install git:github.com/<owner>/<repo>@<ref>
-openclaw plugins install ./local-dir [--link]
-openclaw plugins install <pkg> --marketplace <source>
-```
-
-No `remove` / `enable` / `disable` subcommands — those flow through `openclaw.json` edits and filesystem cleanup.
-
-### ClawHub
-
-Official registry: `github.com/openclaw/clawhub`. ~13,729 third-party skills as of Feb 2026. Community-curated lists include `awesome-openclaw-plugins`, `awesome-openclaw-skills`, `awesome-openclaw`.
-
-## 6. What Bazilion borrows, and what it doesn't
-
-**Borrowed:**
-
-- The **prompt-only skill model.** `apps/daemon/src/core/skills/` reads `SKILL.md` and injects the body into the system prompt of every attached agent. Helper scripts run via the agent's generic `bash` tool. See `CLAUDE.md` → "OpenClaw skill model: prompt-only".
-- The **`SKILL.md` + YAML frontmatter format.** Upstream skills "drop in unchanged" per the README — `bazilion skill import --from openclaw` resolves to `~/.openclaw/skills/` (see `apps/daemon/src/routes/skills.ts`).
-- The general idea of a per-user state root with a workspace concept. Bazilion's `~/.bazilion/groups/<slug>/` is roughly the analogue of OpenClaw's `<workspace>/`.
-
-**Bazilion-only extensions on top of the upstream format:**
-
-- `entry:` frontmatter field + the `run_skill` tool. Upstream OpenClaw skills don't have these; that's why imported skills surface as `docs-only` in Bazilion (memory: `project_skill_model.md`).
-
-**Deliberately *not* borrowed:**
-
-- The **plugin model** (28 hooks, TypeScript in-process modules, `openclaw.plugin.json`). Bazilion has no plugin SDK — all extensibility goes through skills + native daemon code.
-- **Channels.** Upstream's first-class WhatsApp/Telegram/iMessage/Signal transports have no Bazilion equivalent; we expose HTTP only.
-- **ClawHub.** No registry integration.
-- **JSON5 `openclaw.json`** config surface. Bazilion stores config in the daemon's SQLite (`config` table) + secrets in the encrypted `secrets` table (see `CLAUDE.md` → "Secrets and config").
-- The richer skill frontmatter (`user-invocable`, `command-dispatch`, `disable-model-invocation`, install recipes). Bazilion's skill loader only consumes `name` + `description` + body today.
-
-## 7. Authoritative sources
-
-- `https://github.com/openclaw/openclaw` — main repo (`AGENTS.md`, `skills/`)
-- `https://github.com/openclaw/openclaw/tree/main/skills` — bundled skills
-- `https://docs.openclaw.ai/tools/skills` — SKILL.md format + load-path precedence
-- `https://docs.openclaw.ai/tools/skills-config` — `openclaw.json` skills config
-- `https://docs.openclaw.ai/tools/plugin` — plugin overview + install CLI
-- `https://docs.openclaw.ai/plugins/manifest` — `openclaw.plugin.json` schema
-- `https://docs.openclaw.ai/plugins/plugin-inventory` — bundled plugin list
-- `https://docs.openclaw.ai/plugins/hooks` — 28-hook SDK reference
-- `https://docs.openclaw.ai/cli/skills` — `openclaw skills …` CLI surface
-- `https://docs.openclaw.ai/clawhub/skill-format` — registry skill format
-- `https://github.com/openclaw/clawhub` — registry

package/packages/api-types/package.json

@@ -1,11 +0,0 @@
-{
-  "name": "@bazilion/api-types",
-  "version": "0.0.0",
-  "private": true,
-  "type": "module",
-  "main": "./src/index.ts",
-  "exports": {
-    ".": "./src/index.ts"
-  },
-  "dependencies": {}
-}

package/packages/api-types/src/entities.ts

@@ -1,146 +0,0 @@
-// Canonical entity shapes. The daemon's DB schema (apps/daemon/src/core/db)
-// produces these, the daemon serialises them onto the wire, every client
-// (web, mobile, cli, future SDKs) consumes them. Owned here so clients never
-// have to reach into daemon source (which carries node:sqlite) just to know
-// what an Agent is.
-
-export type Timestamp = number
-
-/**
- * A group is a collaboration context: one filesystem root, one USER.md
- * (read-only to agents, edited by the human), one roster of member agents.
- * Every agent belongs to exactly one group.
- */
-export interface Group {
-  id: string
-  name: string
-  path: string
-  /** Read-only context about the human for all agents in this group.
-   * Injected into the system prompt; never exposed as a file on disk. */
-  userMd: string
-  createdAt: Timestamp
-}
-
-export type SkillsMode = 'all' | 'selected'
-
-export interface Profile {
-  id: string
-  name: string
-  dir: string
-  defaultModel: string
-  skillsMode: SkillsMode
-  createdAt: Timestamp
-  updatedAt: Timestamp
-}
-
-export type AgentStatus = 'idle' | 'running' | 'archived'
-
-export type ReasoningLevel = 'off' | 'minimal' | 'low' | 'medium' | 'high' | 'xhigh'
-
-export const REASONING_LEVELS: ReasoningLevel[] = [
-  'off',
-  'minimal',
-  'low',
-  'medium',
-  'high',
-  'xhigh',
-]
-
-export interface Agent {
-  id: string
-  profileId: string
-  name: string
-  modelOverride: string | null
-  reasoningLevel: ReasoningLevel
-  status: AgentStatus
-  dir: string
-  /** The group this agent belongs to. Every agent has exactly one. */
-  groupId: string
-  createdAt: Timestamp
-  archivedAt: Timestamp | null
-}
-
-export interface AgentSkillAttachment {
-  agentId: string
-  skillName: string
-  attachedAt: Timestamp
-}
-
-export interface SkillMeta {
-  name: string
-  source: string | null
-  importedAt: Timestamp | null
-}
-
-export interface Message {
-  id: string
-  fromAgentId: string
-  toAgentId: string
-  replyTo: string | null
-  payload: string
-  createdAt: Timestamp
-  readAt: Timestamp | null
-}
-
-export interface WebToken {
-  id: string
-  label: string
-  createdAt: Timestamp
-  lastUsedAt: Timestamp | null
-  revokedAt: Timestamp | null
-}
-
-export type TriggerKind = 'interval' | 'cron'
-
-export interface AgentTrigger {
-  id: string
-  agentId: string
-  kind: TriggerKind
-  intervalSec: number | null
-  cronExpr: string | null
-  message: string
-  enabled: boolean
-  lastFiredAt: Timestamp | null
-  createdAt: Timestamp
-}
-
-export interface OpenAICodexStatus {
-  connected: boolean
-  /** Unix ms expiry of the current access token; null if disconnected. */
-  expiresAt: number | null
-  /** chatgpt_account_id extracted from the JWT, when available. */
-  accountId: string | null
-}
-
-export interface AgentIdentityFile {
-  name?: string
-  emoji?: string
-  theme?: string
-  creature?: string
-  vibe?: string
-  avatar?: string
-}
-
-export interface ResolvedAgent {
-  agent: Agent
-  profile: Profile
-  model: string
-  reasoningLevel: ReasoningLevel
-  group: Group
-  skills: string[]
-}
-
-export interface LoadedProfile {
-  profile: Profile
-  defaultSkills: string[]
-  files: {
-    soul: string
-    identity: string
-    bootstrap: string | null
-    agents: string | null
-    tools: string | null
-    heartbeat: string | null
-  }
-  /** Structured fields parsed from IDENTITY.md — null when no values are set. */
-  identity: AgentIdentityFile | null
-}

package/packages/api-types/src/events.ts

@@ -1,55 +0,0 @@
-// Wire shapes for chat streaming and provider message exchange. The worker
-// emits `ChatFrame`s as NDJSON, the daemon forwards them verbatim, every UI
-// renders the contained `SessionEvent`s. `ProviderMessage` is the shape both
-// the worker (in `done` frames) and clients (when displaying history) speak.
-
-export type Role = 'system' | 'user' | 'assistant' | 'tool'
-
-export interface ToolCall {
-  id: string
-  name: string
-  /** JSON-serialized arguments object */
-  arguments: string
-}
-
-export interface ProviderMessage {
-  role: Role
-  content: string
-  toolCalls?: ToolCall[]
-  /** for role='tool': links the result back to the originating call */
-  toolCallId?: string
-  /** for role='tool': name of the tool that produced this result. Pi requires it on ToolResultMessage. */
-  toolName?: string
-}
-
-export interface ToolDef {
-  name: string
-  description: string
-  /** JSON Schema for the tool's arguments object */
-  parameters: object
-}
-
-export type SessionEvent =
-  | { type: 'user_message'; text: string }
-  | { type: 'assistant_delta'; delta: string }
-  | { type: 'assistant_message'; text: string }
-  | { type: 'tool_call'; id: string; name: string; arguments: string }
-  | { type: 'tool_result'; id: string; name: string; result: string }
-  | { type: 'tool_error'; id: string; name: string; error: string }
-  | { type: 'error'; error: string }
-
-/**
- * The wire envelope the worker emits on stdout (NDJSON, one per line) and
- * the chat HTTP endpoint forwards verbatim to clients.
- *
- * - `event`: one per SessionEvent emitted during the turn
- * - `done`:  sent exactly once at the end of a successful turn with the
- *            final message list
- * - `fatal`: sent at most once when the worker itself fails before/after
- *            the turn can run — distinct from an `error` SessionEvent which
- *            lives within a completed turn
- */
-export type ChatFrame =
-  | { kind: 'event'; event: SessionEvent }
-  | { kind: 'done'; messages: ProviderMessage[] }
-  | { kind: 'fatal'; error: string }