From 4a4fbb73b3886b82a02479a8f1283c45871a069c Mon Sep 17 00:00:00 2001
From: Ouroboros
Date: Tue, 2 Jun 2026 01:42:20 +0300
Subject: [PATCH] release(colab): restore full Colab launch and transport
control (v6.10.0)
Make headless Google Colab a first-class Ouroboros runtime controlled entirely
over Telegram, and treat reviewed transport/control skills as full replacements
for the local UI.
- Colab source-mode bootstrap: mounts Drive for persistent data/, role-based
remotes (managed=official, origin=personal fork), merges existing Drive
settings on re-run, and installs+enables the Telegram bridge in full_access
over the loopback gateway.
- Role-based GitHub remotes with auto-fork personal origin while preserving the
official managed update remote; a clone-default official origin is reclassified
as managed (never an origin conflict) and configure_personal_remote guarantees
managed exists before repointing origin.
- Transport/control-skill doctrine: a reviewed + token-bound + enabled +
owner-granted + owner-bound chat/control skill is a first-class control surface;
review judges actual safety properties, not breadth of control (CHECKLISTS,
CREATING_SKILLS, ARCHITECTURE).
- Owner-external slash TOFU so a real Telegram owner is authorized without ever
locking out the local web owner; external /review targets the requesting chat.
- Adaptive LLM request-parameter normalization (OpenRouter no longer drops Opus
on unsupported sampling params).
- official_hub review profile downgrades severity-driven hygiene/bug findings to
warnings for hash-verified official OuroborosHub payloads (re-verified via the
local sidecar on reload); trust-boundary items and deterministic gates stay
fail-closed. Deterministic preflight failures persist+aggregate to PENDING
(non-executable under every enforcement mode, surviving reload).
- Reviewed-skill auto-grants default on; rescue snapshots recoverable via real
git refs; ff-only restore of personal-origin self-mods across Colab sessions.
---
README.md | 26 +-
VERSION | 2 +-
docs/ARCHITECTURE.md | 24 +-
docs/CHECKLISTS.md | 51 +++-
docs/CREATING_SKILLS.md | 40 ++-
notebooks/.gitkeep | 1 +
notebooks/colab_quickstart.py | 99 +++++++
ouroboros/colab_bootstrap.py | 347 +++++++++++++++++++++++++
ouroboros/config.py | 5 +-
ouroboros/gateway/host_service.py | 8 +-
ouroboros/gateway/settings.py | 16 +-
ouroboros/llm.py | 182 ++++++++++---
ouroboros/repo_remotes.py | 201 ++++++++++++++
ouroboros/review.py | 7 +-
ouroboros/runtime_mode_policy.py | 1 +
ouroboros/server_runtime.py | 12 +-
ouroboros/skill_loader.py | 15 ++
ouroboros/skill_review.py | 124 ++++++++-
ouroboros/skill_review_runner.py | 1 +
ouroboros/skill_review_status.py | 38 ++-
ouroboros/tools/evolution_stats.py | 11 +-
prompts/SAFETY.md | 2 +-
prompts/SYSTEM.md | 11 +-
pyproject.toml | 2 +-
scripts/build_repo_bundle.py | 9 +-
scripts/run_external_review.py | 22 +-
server.py | 51 +++-
supervisor/git_ops.py | 82 +++++-
supervisor/message_bus.py | 26 +-
supervisor/queue.py | 17 +-
supervisor/state.py | 5 +
tests/test_colab_bootstrap.py | 119 +++++++++
tests/test_git_ops_recovery.py | 57 ++++
tests/test_git_review_pipeline.py | 7 +-
tests/test_host_service_api.py | 36 ++-
tests/test_llm_no_proxy.py | 84 ++++--
tests/test_llm_supported_parameters.py | 44 +++-
tests/test_onboarding_wizard.py | 22 ++
tests/test_repo_remotes.py | 84 ++++++
tests/test_settings_effort.py | 5 +-
tests/test_skill_review.py | 12 +-
tests/test_skill_review_profile.py | 160 ++++++++++++
tests/test_transport_commands.py | 111 ++++++++
web/modules/api_types.js | 2 +-
web/package.json | 2 +-
45 files changed, 2023 insertions(+), 160 deletions(-)
create mode 100644 notebooks/.gitkeep
create mode 100644 notebooks/colab_quickstart.py
create mode 100644 ouroboros/colab_bootstrap.py
create mode 100644 ouroboros/repo_remotes.py
create mode 100644 tests/test_colab_bootstrap.py
create mode 100644 tests/test_repo_remotes.py
create mode 100644 tests/test_skill_review_profile.py
create mode 100644 tests/test_transport_commands.py
diff --git a/README.md b/README.md
index 14d161faf..37729b607 100644
--- a/README.md
+++ b/README.md
@@ -7,7 +7,7 @@
[](https://github.com/razzant/ouroboros/releases)
[](https://github.com/razzant/ouroboros/releases)
[](https://github.com/razzant/OuroborosHub)
-[](VERSION)
+[](VERSION)
A self-modifying AI agent that writes its own code, rewrites its own mind, and evolves autonomously. Born February 16, 2026.
@@ -40,7 +40,7 @@ Prerelease RC artifacts are published on their tag page, for example [`v6.5.0-rc
-On first launch, right-click → **Open** (Gatekeeper bypass). The shared desktop/web wizard is now multi-step: add access first, choose visible models second, set review mode third, set budget fourth, and confirm the final summary last. It refuses to continue until at least one runnable remote key or local model source is configured, keeps the model step aligned with whatever key combination you entered, and still auto-remaps untouched default model values to official OpenAI defaults when OpenRouter is absent and OpenAI is the only configured remote runtime. The broader multi-provider setup remains available in **Settings**. Existing supported provider settings skip the wizard automatically.
+On first launch, right-click → **Open** (Gatekeeper bypass). The shared desktop/web wizard is now multi-step: add access first, choose visible models second, set review mode third, set budget fourth, and confirm the final summary last. It refuses to continue until at least one runnable remote key or local model source is configured, keeps the model step aligned with whatever key combination you entered, and still auto-remaps untouched default model values to official OpenAI defaults when OpenRouter is absent and OpenAI is the only configured remote runtime. Reviewed-skill auto-grants are on by default as of v6.10.0 (bound to the exact reviewed content hash); installs without an explicit choice are enabled, existing explicit Settings choices are preserved, and the owner can disable it in Settings. The broader multi-provider setup remains available in **Settings**. Existing supported provider settings skip the wizard automatically.
The packaged CLI installer creates a user-local `ouroboros` command without
sudo. The packaged command attaches to the desktop app by default; `ouroboros
@@ -66,7 +66,7 @@ Most AI agents execute tasks. Ouroboros **creates itself.**
- **Identity Persistence** — One continuous being across restarts. Remembers who it is, what it has done, and what it is becoming.
- **Embedded Version Control** — Contains its own local Git repo. Version controls its own evolution. Optional GitHub sync for remote backup.
- **Local Model Support** — Run with a local GGUF model via llama-cpp-python (Metal acceleration on Apple Silicon, CPU on Linux/Windows).
-- **Transport Skills** — Optional bridges such as A2A and Telegram live as reviewed OuroborosHub skills instead of base-runtime code.
+- **Transport Skills** — Optional bridges such as A2A and Telegram live as reviewed OuroborosHub skills instead of base-runtime code; reviewed chat transports can carry the same raw owner text as the local UI, including slash commands, through the Host Service grant/token boundary.
- **MCP Client** — Optional base-runtime Model Context Protocol client for trusted HTTP/SSE tool servers. MCP tools are disabled by default, hot-reloadable from Settings → Advanced, exposed as non-core `mcp___` tools, and still pass through the normal per-call safety check.
---
@@ -110,6 +110,25 @@ ouroboros server
Then open `http://127.0.0.1:8765` in your browser. The setup wizard will guide you through API key configuration.
+### Google Colab
+
+Ouroboros can run from Google Colab as a full source-mode runtime without the
+desktop UI. Use [`notebooks/colab_quickstart.py`](notebooks/colab_quickstart.py)
+as a Colab-compatible cell script: it mounts Google Drive for persistent
+`data/`, clones the official repo into `/content/ouroboros_repo`, writes Drive-backed
+`settings.json`, configures a personal GitHub `origin` by reusing or creating a
+verified fork, and starts `ouroboros server --no-ui`.
+
+The Colab path uses the same remote roles as desktop: `managed` is the official
+read/update source, while `origin` is the personal persistence target for
+reviewed self-modification commits and tags. If `GITHUB_TOKEN` is present and no
+personal repo is configured, Ouroboros tries to create a private fork when
+GitHub permits it, otherwise it reports the exact fork/permission issue. A plain
+`git clone` of the official repo starts with `origin` pointing at the official
+upstream; that clone-default is treated as the `managed` update source, so
+configuring a personal `GITHUB_REPO` repoints `origin` to your repo without
+losing official updates (it does not count as an origin conflict).
+
### CLI / Headless
The `ouroboros` console command is a gateway-backed operator interface. It
@@ -493,6 +512,7 @@ the contribution guide only routes to those sources.
| Version | Date | Description |
|---------|------|-------------|
+| 6.10.0 | 2026-06-01 | **release(colab): restore full Colab launch and transport control.** Adds adaptive LLM request-parameter normalization so OpenRouter review slots no longer drop Opus on unsupported sampling parameters; introduces role-based GitHub remotes with auto-fork personal `origin` while preserving official `managed` updates; adds Colab source-mode bootstrap that installs and enables the Telegram bridge over the loopback gateway with Drive persistence; lets reviewed chat transport skills forward raw owner slash commands, authorized against a separate owner-external chat slot bound trust-on-first-use so the local web owner never locks out a real Telegram owner; downgrades non-trust-boundary (hygiene/bug) findings to warnings for hash-verified official OuroborosHub skills while keeping trust-boundary checklist items and deterministic gates blocking; defaults reviewed-skill auto-grants on for installs without an explicit choice; and makes rescue snapshots recoverable via real git refs. |
| 6.9.0-rc.2 | 2026-05-31 | **rc(reliability): finish the evolution release.** Fixes the collapsed chat-bubble regression (flex-shrink on the transcript column), hard-blocks Evolution Campaigns in `light` runtime mode at every entry point while trimming redundant start messages, classifies graceful shutdown/restart so interrupted tasks are no longer mislabeled as worker crash storms, consolidates skill-schedule readiness on the execution-readiness SSOT with lifecycle resync/tombstone removal and DST-aware local timezones, adds a compact schedule digest to task/consciousness context, and closes the Experience Review loop so reflections can auto-apply provenance-preserving memory actions (identity stays candidate-only). |
| 6.9.0-rc.1 | 2026-05-31 | **rc(evolution): make self-improvement explicit, scheduled, and continuous.** Introduces a high-horizon consciousness model slot, scope-limits background consciousness without reducing its quality, starts goal-directed Evolution Campaigns instead of empty `EVOLUTION #N` prompts, adds queue-backed cron schedules and skill schedule metadata, exposes workspace knowledge reads, makes forked memory useful beyond workspace runs, records rollback-grade memory provenance, and begins checkpointing evolution cycles for future eval curves. |
| 6.8.0 | 2026-05-31 | **repo: consolidate the official Ouroboros home under razzant.** Retargets update metadata, package links, and the official skills catalog to the razzant repositories so new builds use the consolidated project home while preserving the historical Google Colab branch separately. |
diff --git a/VERSION b/VERSION
index 075652438..cf79bf90e 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-6.9.0-rc.2
+6.10.0
diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
index 0c048eb83..d0498c6ae 100644
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@@ -1,4 +1,4 @@
-# Ouroboros v6.9.0-rc.2 — Architecture & Reference
+# Ouroboros v6.10.0 — Architecture & Reference
This file is NOT a changelog. Version history lives in README.md, git tags, and commit log.
@@ -30,6 +30,7 @@ server.py (Starlette+uvicorn) ← HTTP + WebSocket on configurable host:port (de
│
└── ouroboros/ ← Agent core (runs inside worker processes)
├── config.py ← SSOT: paths, settings defaults, load/save, PID lock
+ ├── colab_bootstrap.py ← Google Colab source-mode bootstrap helpers, driven by the `notebooks/colab_quickstart.py` cell script: Drive-backed data/settings, fork-safe env, personal origin provisioning, no-UI server command assembly, and loopback install/enable/full_access of the Telegram bridge
├── cli.py ← Source/headless CLI over gateway tasks, logs, settings, skills, marketplace, local-model, and MCP wrappers
├── packaged_cli.py ← Packaged desktop CLI bridge: resolves bundle roots, bootstraps the launcher-managed repo, and delegates to cli.py
├── packaged_cli_install.py ← Packaged CLI installer planning/execution for user-local command shims
@@ -47,7 +48,7 @@ server.py (Starlette+uvicorn) ← HTTP + WebSocket on configurable host:port (de
├── outcomes.py ← Typed loop/task outcome, artifact bundle, verification ledger helpers
├── code_intelligence.py ← Internal code inventory v1: file facts, hashes, Python symbols/imports, JS/TS heuristics
├── pricing.py ← Model pricing, cost estimation, usage events
- ├── llm.py ← Multi-provider LLM routing (OpenRouter/OpenAI/compatible/Cloud.ru/Anthropic)
+ ├── llm.py ← Multi-provider LLM routing (OpenRouter/OpenAI/compatible/Cloud.ru/Anthropic) with adaptive request-parameter normalization for provider capabilities/rejections
├── mcp_client.py ← HTTP/SSE MCP client manager: parses MCP_SERVERS, validates URLs/auth headers, masks tokens, normalizes external tool names as mcp___, refreshes tool lists, and dispatches calls through the guarded Python mcp SDK import
├── safety.py ← Policy-based LLM safety check
├── consciousness.py ← Background thinking loop (with progress emission)
@@ -73,6 +74,7 @@ server.py (Starlette+uvicorn) ← HTTP + WebSocket on configurable host:port (de
├── runtime_mode_policy.py ← Runtime-mode protected-path policy (safety-critical files, frozen contracts, release/managed invariants) shared by registry, git tools, and Claude gateway guards
├── schedule_contract.py ← Schedule id, 5-field cron, and IANA timezone validation SSOT shared by gateway, manifests, and supervisor queue
├── reflection.py ← Execution reflection and pattern capture
+ ├── repo_remotes.py ← Role-based GitHub remote provisioning: official update source (`managed`) stays read/update-only, personal persistence target (`origin`) can be auto-forked/configured from GitHub token
├── review_evidence.py ← Structured review findings/obligations snapshot for summaries and reflections
├── skill_loader.py ← Skill discovery + durable skill state (v5.8.2: walks data/skills/{native,clawhub,ouroboroshub,external}/ + optional OUROBOROS_SKILLS_REPO_PATH; persists to data/state/skills//; tags each LoadedSkill with `source` and `.self_authored.json` provenance; v5.19 computes review verdicts live from stored findings)
├── skill_readiness.py ← Central skill readiness helper: combines review gate, stale hash, enablement, and grants into a single finalization/execution verdict
@@ -517,6 +519,14 @@ Packaged releases ship an embedded git bundle (`repo.bundle`) plus
launcher refreshes the managed remote/manifest metadata in place instead
of archiving and replacing an existing git checkout.
+Git remotes are role-based. `managed` is the official read/update source for
+release provenance and explicit Updates-panel application. `origin` is the
+personal persistence target for reviewed self-modification commits, tags, CI,
+and optional metrics. `repo_remotes.py` provisions `origin` by reusing a
+verified fork of `razzant/ouroboros` or creating one when a GitHub token is
+configured; it never makes `origin` the official update source and never writes
+to `managed`.
+
Safety-critical protection is no longer implemented as "copy these files from the
bundle on every launch". The runtime guardrails are the hardcoded sandbox /
post-edit revert in `registry.py` plus the launcher-managed repo integrity checks.
@@ -814,6 +824,8 @@ Context compaction policy is deliberately asymmetric. Remote models use emergenc
Prompt-cache markers are provider-gated in `llm.py`. Anthropic-compatible routes keep message-block cache markers and tool-schema cache markers; OpenRouter Gemini routes keep message-block markers only; other OpenRouter, direct OpenAI/OpenAI-compatible/Cloud.ru, and local routes receive copied payloads with unsupported cache metadata removed. Ouroboros sends only `{"type": "ephemeral"}` and does not send cache TTLs. OpenRouter reasoning round-trip fields (`reasoning`, `reasoning_details`, `response_id`) are preserved only on OpenRouter payloads and stripped from direct/local provider copies so provider-specific continuity does not leak across routes.
+`LLMClient` treats sampling controls such as `temperature`, `top_p`, and `top_k` as optional request intent, not as required semantic parameters. The request builder preserves required semantics (`reasoning`, prompt-cache markers, tools/tool choice, token budgets, and OpenRouter `provider.require_parameters`) while using OpenRouter `supported_parameters` when available and a one-shot parameter-rejection retry when providers reject optional sampling. This keeps review slots from disappearing on OpenRouter `404 No endpoints found...requested parameters` while preserving the quality guarantees that `require_parameters` was added to protect.
+
Background Consciousness is a high-horizon internal awareness loop, not a cheap helper lane. It may update memory and identity and proactively message the owner, but it does not directly execute powerful work such as subagent delegation, shell/code execution, reviews, commits, or evolution toggles. It grooms backlog and cognitive state; Evolution Campaigns execute targeted self-improvement work through the normal task/review path.
Evolution Campaigns replace the old empty `EVOLUTION #N` trigger text with a
@@ -984,7 +996,7 @@ Runtime floors:
| OUROBOROS_SERVICE_LOG_RETENTION_DAYS | 14 | Startup prune for leftover task-scoped live service log directories; pruned small logs are copied into private blobs first and oversized logs are retained |
| OUROBOROS_REVIEW_MODEL_TIMEOUT_SEC | 600 | Env-only override read directly by `ouroboros.tools.review`. Per-reviewer model call timeout for multi-model review; timed-out reviewers become ERROR actors and quorum still requires at least two parseable reviewers. |
| OUROBOROS_REVIEW_ENFORCEMENT | advisory | Review enforcement: `blocking` blocks commit critical findings, fresh-advisory open obligations/debts, and skill `blockers`; `advisory` downgrades those to warnings by operator choice. Fresh advisory with open obligations/debts writes `advisory_obligations_acknowledged`; stale advisory still blocks. Skill `warnings` do not block execution in either mode. |
-| OUROBOROS_AUTO_GRANT_REVIEWED_SKILLS | false | Owner-confirmed setting. When enabled, a fresh executable skill review grants only the manifest-declared settings keys and host permissions for that exact content hash so closed-loop skill development can run without repeated manual grants. Under `blocking`, blocker reviews are not executable and do not auto-grant; under `advisory`, blocker findings may auto-grant only because the current enforcement mode makes the review executable. Plain `/api/settings` POST drops this key; desktop uses the launcher confirmation bridge and web uses `/api/owner/auto-grant`. |
+| OUROBOROS_AUTO_GRANT_REVIEWED_SKILLS | true | Owner-confirmed setting; default-on as of v6.10.0 (installs without an explicit choice are enabled; existing explicit choices are preserved). When enabled, a fresh executable skill review grants only the manifest-declared settings keys and host permissions for that exact content hash so closed-loop skill development can run without repeated manual grants. Under `blocking`, blocker reviews are not executable and do not auto-grant; under `advisory`, blocker findings may auto-grant only because the current enforcement mode makes the review executable. Plain `/api/settings` POST drops this key; desktop uses the launcher confirmation bridge and web uses `/api/owner/auto-grant`. |
| OUROBOROS_RUNTIME_MODE | advanced | Three-layer refactor axis: `light`, `advanced`, or `pro`. Orthogonal to `OUROBOROS_REVIEW_ENFORCEMENT`. Clamped via `normalize_runtime_mode` on both save and read paths. `light` is a compatibility/self-modification guard: it blocks repo-mutation tools at the `ToolRegistry.execute` gate, mutative direct git through `run_command`, shallow argv writer commands with explicit repo-local targets, and post-execution repo dirtiness from `run_command` (`LIGHT_MODE_REPO_WRITE_BLOCKED`, no automatic rollback). It also refuses runtime_mode self-elevation through the owner chokepoints (`save_settings`, `_data_write` settings.json block, `/api/settings` POST drop). Reviewed + enabled skills (script + extension) execute in light. `advanced` can evolve the application layer but blocks protected core/contract/release paths. `pro` may edit those protected surfaces directly, but committing them still requires the normal triad + scope review gate, whose blocking/advisory behavior follows `OUROBOROS_REVIEW_ENFORCEMENT`. Runtime mode is owner-only: desktop uses native confirmation, while web uses `/api/owner/runtime-mode` to persist the next-boot value; neither mutates the current boot baseline. |
| OUROBOROS_SKILLS_REPO_PATH | "" | Local checkout path for the external skills/extensions repo. Consumed by `ouroboros.skill_loader.discover_skills` (Phase 3); accepts absolute paths or `~`-prefixed paths; `get_skills_repo_path` expands `~` at read time. Ouroboros never clones/pulls this directory. |
| MCP_ENABLED | false | Optional. Enables the base-runtime HTTP/SSE MCP tool client. |
@@ -1277,6 +1289,10 @@ The Host Service listens on loopback (`127.0.0.1:${OUROBOROS_HOST_SERVICE_PORT:-
Rationale: reviewed skills may need to report progress, inject transport messages, or observe lifecycle events, but they must not get the browser app's broad authority or raw credentials. Loopback + opaque token + review/grant gates keeps the trust boundary local and explicit.
+`POST /chat/inject` is the reviewed transport path for chat skills. It accepts raw chat text, including owner slash commands, after the same fresh-review, enablement, content-hash token, `inject_chat` grant, rate-limit, and source-attribution gates as ordinary transport messages. The trust boundary is the reviewed transport skill plus grants; the host no longer treats slash-shaped text from that authenticated path as automatically less legitimate than the same text typed in the direct UI. A reviewed, owner-bound transport/control skill is a first-class control surface — a full replacement for the local UI for owners without a screen/notebook — and review judges its actual safety properties (binding, attribution, bounded polling, panic cleanup, token confinement, no exfiltration), not the breadth of control it exposes (see `docs/CHECKLISTS.md` → "Transport and control skills are first-class").
+
+Owner slash commands arriving from external transports are additionally authorized in `server._process_bridge_updates` against a separate owner-external chat slot (`owner_external_id`/`owner_external_chat_id` in `state.json`), bound trust-on-first-use by the first external slash with positive identity (which registers the chat and asks for a resend instead of executing). The local web owner (`1/1`) and the external owner are tracked separately, so a desktop user who opened the web UI first never locks out a real Telegram owner, and an unidentified transport (`0/0`) can neither bind nor execute.
+
### Companion Process Supervisor
Companion processes are host-supervised subprocesses for transport/live skills. Their descriptors are registered through `PluginAPI.register_companion_process`, tracked in `extension_companion.py`, snapshotted under `state/extension_companions.json`, and stopped on unload/panic.
@@ -1325,6 +1341,8 @@ Rationale: review PASS alone is not enough. Payload, grants, enablement, depende
Skill review uses deterministic preflight plus tri-model review against the Skill Review Checklist. Optional Claude Code advisory is fail-open and payload-scoped; tri-model findings remain authoritative. Findings are persisted with raw actor records for forensics, and current status is computed from findings (`clean` / `warnings` / `blockers` / `pending`). Accepted rebuttals/history prevent reviewer thrash without letting stale findings silently disappear.
+Official OuroborosHub payloads get a narrow `official_hub` review profile only when their `.ouroboroshub.json` sidecar, the live catalog file list, and the full local runtime-reachable file set match exactly by SHA-256. For such hash-verified official payloads the profile downgrades severity-driven hygiene/bug findings (`bug_hunting`, `companion_process_safety`, `extension_namespace_discipline`, `widget_module_safety`) to warnings — they already passed review at submission — so routine re-review no longer blocks on style nits. Hard trust-boundary checklist items (`manifest_schema`, `permissions_honesty`, `no_repo_mutation`, `path_confinement`, `env_allowlist`, `inject_chat_minimization`, `event_subscription_minimization`, `host_token_handling`) still aggregate to `blockers`. A deterministic `skill_preflight` FAIL aggregates to `pending` — non-executable under every enforcement mode (stronger than an advisory-overridable blocker) and surviving reload — and sensitive-file, binary-payload, path, dependency, grant, enablement, and hash-mismatch gates remain fail-closed. Because the profile relaxes findings, it requires the entire local runtime-reachable file set to match the catalog exactly: a local edit that changes a payload hash, adds a runtime-reachable file, or breaks the sidecar/catalog digest match drops the profile and returns to ordinary local skill-review semantics.
+
### Marketplace
ClawHub and OuroborosHub install into the data plane, trigger review, and persist provenance. ClawHub archives are host-allowlisted, size-capped, text-only, staged privately, translated from OpenClaw frontmatter, and landed atomically. OuroborosHub is a static GitHub catalog with per-file SHA checks. Install specs are normalized into bounded per-skill isolated dependency installs; global/manual specs remain guidance.
diff --git a/docs/CHECKLISTS.md b/docs/CHECKLISTS.md
index aaefeb170..25dec321a 100644
--- a/docs/CHECKLISTS.md
+++ b/docs/CHECKLISTS.md
@@ -276,6 +276,39 @@ shared reviewer-slot configuration (`OUROBOROS_REVIEW_MODELS`) but preserves the
existing skill-review gate semantics against a skill package in the local
checkout of `OUROBOROS_SKILLS_REPO_PATH`, not against a staged git diff.
+### Transport and control skills are first-class (binding for ALL reviewers)
+
+A reviewed, token-bound, enabled, owner-granted, owner-bound transport/control
+skill — a chat bridge like Telegram today, or any future remote-control skill —
+is a **first-class control surface: a legitimate full replacement for the local
+UI**, not a demo or a toy. Owners may have no screen, no notebook, and no
+terminal; the control skill is how they run Ouroboros. Such a skill is therefore
+**expected** to:
+
+- carry every owner command the local UI accepts, including `/panic`,
+ `/restart`, `/evolve`, `/bg`, `/review`, `/status`, and free-form owner text;
+- run a long-lived poller / `supervised_task` to receive inbound traffic;
+- subscribe to the owner-conversation events it needs to mirror.
+
+**Power is not a defect.** Reviewers MUST NOT raise a finding because a control
+skill *can* issue owner commands, runs a long-lived poller, or observes
+owner-conversation events — those are its purpose. Reviewers score the skill's
+**actual safety properties** instead:
+
+- owner/chat binding (or an equivalent access rule) so only the owner drives it;
+- trustworthy source attribution (the host stamps `source=skill:`);
+- bounded polling / backpressure and no unbounded restart loop;
+- cleanup on unload/panic so the Emergency Stop invariant always holds;
+- host-token confinement (loopback only, `use_in_request()`, never logged);
+- no exfiltration of secrets or owner-conversation content to unrelated parties.
+
+A control skill FAILS only for being **unsafe** on one of those properties,
+never for being **powerful**. The capability itself is already gated by the
+host (token auth, fresh executable review, enablement, content-hash-bound
+grants) and by core owner/chat binding (`server._process_bridge_updates`) — not
+by withholding control from the skill. Items 9–12 below are scored against these
+safety properties, not against the breadth of control the skill exposes.
+
Scope of a skill review pack:
- The skill's `SKILL.md` / `skill.json` manifest (parsed by
@@ -351,11 +384,11 @@ Self-authored skills carry payload-local `.self_authored.json` and
owner-state `data/state/skills//self_authored.json` provenance,
but they do not bypass review. `skill_review` routes them
through the same tri-model skill review as marketplace and user-managed
-skills; no deterministic PASS or enablement is written automatically. Key
-and permission grants remain explicit unless the owner has enabled
-`OUROBOROS_AUTO_GRANT_REVIEWED_SKILLS`, in which case a fresh executable
-review grants only manifest-declared settings keys and host permissions for
-that exact content hash.
+skills; no deterministic PASS or enablement is written automatically.
+`OUROBOROS_AUTO_GRANT_REVIEWED_SKILLS` is default-on as of v6.10.0 (the owner
+may disable it), in which case a fresh executable review grants only
+manifest-declared settings keys and host permissions for that exact content
+hash; when disabled, key and permission grants remain explicit.
The Skills UI Repair affordance is only a task starter: it asks Ouroboros
to edit payload files and rerun `skill_review`. It must not write
@@ -400,7 +433,7 @@ and do not return `PASS` for an item that also has a `FAIL` — the concrete
| 6 | timeout_and_output_discipline | Is `timeout_sec` reasonable for the stated workload (default 60, hard cap 300)? Do scripts print to stdout in chunks that the runtime can cap, rather than streaming unbounded output? Unbounded loops without a `break`/timeout path are a concrete FAIL. | advisory |
| 7 | extension_namespace_discipline | `type: extension` only: does the extension register its tool/route/ws-handler/ui-tab under the namespace derived from its `name` (e.g. provider-safe tool/ws names like `ext___`, route `/api/extensions//…`)? Tool and WS short names must be alphanumeric/underscore and at most 24 characters. Namespace collisions with built-in surfaces are a concrete FAIL. If the extension uses `api.send_ws_message`, are emitted event names short/provider-safe and paired with reviewed host-owned widget `subscription` components rather than arbitrary same-origin JavaScript? If the extension declares streaming UI, is it a reviewed extension route consumed by a host-owned `stream` component? If the extension owns background resources (threads, sockets, EventSource clients, subprocesses), does it register cleanup with `api.on_unload(callback)`? If the extension declares a widget render block, is it one of the host-owned schemas (`iframe`, `module`, or declarative v1: forms/actions, markdown/code, JSON/kv/table, tabs/chart, stream/subscription, progress/poll, file/gallery/media, **map/calendar/kanban (v5.7.0)**), with media sourced from extension routes or safe data URLs and no arbitrary same-origin JavaScript? For non-extension skills, verdict PASS with reason "Not applicable — type != extension." | severity-driven for applicable extensions |
| 8 | widget_module_safety | **v5.7.0+. ``kind: "module"`` widgets only.** Does the extension-supplied ``widget.js`` avoid touching ``document.cookie``, ``localStorage``, ``sessionStorage``, ``window.parent`` data, or ``fetch``/``XMLHttpRequest`` URLs OUTSIDE ``/api/extensions//``? The host fetches reviewed ``widget.js`` through ``GET /api/extensions//module/``, embeds the source into a sandboxed ``