spice-harness 0.1.0__tar.gz

spice_harness-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Infima Labs
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

spice_harness-0.1.0/PKG-INFO

@@ -0,0 +1,181 @@
+Metadata-Version: 2.4
+Name: spice-harness
+Version: 0.1.0
+Summary: Simultaneous Production, Integration, and Control Environment: an agent harness for coding repositories.
+License-Expression: MIT
+Project-URL: Homepage, https://github.com/infimalabs/spice
+Project-URL: Repository, https://github.com/infimalabs/spice
+Project-URL: Issues, https://github.com/infimalabs/spice/issues
+Requires-Python: >=3.12
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: lizard>=1.21
+Requires-Dist: ruff>=0.11
+Requires-Dist: watchfiles>=1.1
+Dynamic: license-file
+
+# spice
+
+**Simultaneous Production, Integration, and Control Environment.**
+
+spice is an installed agent harness: wrap, steer, supervise, coordinate, and
+audit coding agents across the repos they work on. Install it once, point it at
+a repository, and it provides a closed loop around the agents working there:
+
+- the agent's **transcript is the single source of truth**, and
+- the repo's **filesystem is the single channel of steering**;
+
+supervision, coordination, conscience, and hygiene are derived mechanically
+from those two surfaces.
+
+## Install
+
+```sh
+pip install spice-harness    # or: uv tool install spice-harness
+cd /path/to/your/repo
+spice init               # hooks, spice.sh shim, state scaffolding
+spice dev doctor         # verify drivers, backends, and policy
+```
+
+`spice init` writes machine-local git hook shims under `.spice/` (ignored via
+`.git/info/exclude`) and a tracked `spice.sh` shim. Repo-tracked policy lives
+in your `pyproject.toml` under `[tool.spice.*]` tables. Entrypoint resolution
+is worktree-true: when the current repo is the spice source checkout, generated
+shims and supervisor children put that checkout first on `PYTHONPATH` and run
+`python -m spice`; ordinary target repos use the installed product.
+
+A project can set its default supervised-agent launch model and thinking in
+tracked config, either by editing `pyproject.toml` or by running
+`spice config agent --scope project --model ... --thinking ...`:
+
+```toml
+[tool.spice.agent]
+model = "gpt-5.4"
+thinking = "low"
+```
+
+An operator can override those defaults for just the current worktree:
+
+```sh
+spice config agent --scope worktree --model gpt-5.4 --thinking low
+```
+
+Resolution order is explicit launch flags, then worktree config, then tracked
+project config, then the driver defaults.
+
+A repo can also mount its own tooling into the `spice` namespace:
+
+```toml
+[tool.spice.commands]
+deploy = "./scripts/deploy.sh"
+bench = ["python", "-m", "myproj.bench"]
+```
+
+`spice deploy --env staging` then runs the mounted command from the repo
+root with the remaining arguments passed through verbatim. Built-in verbs
+always win; a mount that shadows one fails loudly.
+
+Mounted names are intentionally one-level verbs (`^[a-z][a-z0-9-]*$`), not
+nested command paths. A repo with a large tool family mounts one namespace
+owner and keeps family grouping inside that repo tool's own arguments:
+
+```toml
+[tool.spice.commands]
+toolbox = ["uv", "run", "toolbox"]
+```
+
+`spice toolbox lint css --fix` then dispatches `lint css --fix` to `toolbox`.
+Do not encode families as dotted, spaced, or ad-hoc hyphenated spice mount
+names such as `lint.css`, `lint css`, or one mount per subcommand; those
+groupings belong behind the mounted repo tool's explicit contract.
+
+### Library seam for repo tools
+
+Mounted commands and tracked pre-commit extensions may import a deliberately
+narrow Python seam from `spice` instead of vendoring harness scaffolding. This
+surface is source-stable for target repos: public names in the modules listed
+below are not removed or renamed silently, and incompatible changes require an
+explicit contract update. Underscored names remain private.
+
+- `spice.errors`: `SpiceError` for user-facing command failures.
+- `spice.policy`: constitution constants and `flex_limit`.
+- `spice.flexstate`: flex-limit sticky-state persistence and rename helpers.
+- `spice.locking`: cross-platform advisory file locks.
+- `spice.paths`: repo-root, state-dir, atomic write, and tool-resolution helpers.
+- `spice.procs`: process-group spawn, liveness, and termination helpers.
+- `spice.repocfg`: tracked `[tool.spice]` table readers.
+- `spice.studies.walk`: tracked/staged path walkers, repo policy exclusions,
+  staged renames, and git blob reads.
+- `spice.studies.fileloc`, `spice.studies.complexity`,
+  `spice.studies.magicnums`, and `spice.studies.envpolicy`: finding
+  dataclasses plus `scan_*`, `detect_*`, and `render_*_board` helpers for
+  project-specific studies.
+
+Everything else is an internal implementation detail unless this section names
+it. A repo tool that needs an unlisted module should either vendor that helper
+or first add the helper to this seam with tests and a stability note.
+
+## The loop
+
+| Surface | Command | What it does |
+| --- | --- | --- |
+| Wrapper | `spice agent run -- <cmd>` (or `./spice.sh`) | Runs shell commands with proxy routing, git-shadow env, and steering injection on stderr. |
+| Lifecycle | `spice agent ensure` / `supervise` | One worktree-bound agent per worktree, started under a neutral skill prompt, watched by a durable supervisor. |
+| Steering | filesystem inbox under `.spice/inbox/` | Durable operator messages; items retire only when the agent semantically ACKs their key in its transcript. |
+| Tasks | `spice task …` | Phase-native Taskwarrior board shared by all worktrees; `task next` is allocator-owned; git sync happens at task boundaries. |
+| Sessions | `spice session` | Transcript forensics: the no-arg briefing is the primary rehydration product, with context-pressure metering. |
+| Cockpit | `spice serve` | Localhost web UI: lanes over worktrees, live transcript streams, lifetime control (Renew / Steer / Drive), task-filter routing, fused lane groups backed by server-side teams; `spice serve teams` and `spice serve browser-artifact-path <file>` expose operator diagnostics for smoke runs. |
+| Conscience | `spice maxim …` | Builtin maxims judged against assistant prose by a local model; violations come back as inbox steering. |
+| Constitution | `spice dev pre-commit` / `spice study …` | Namespace packages, path shape, LOC/byte/complexity flex+sticky gates, magic-number ratchet, env-literal inventory, commit-message policy. |
+
+Session analysis is intentionally tiered. The current tier includes
+`spice session phases` for contiguous working-phase spans and
+`spice session messages` for message-level side/phase/flavor filtering.
+Deeper report families that depend on richer topic/bucket modeling belong in
+a separate analytics tier after the basic phase/message surfaces harden.
+
+## The constitution
+
+The pre-commit gate is the executable form of the project's opinions — see
+[spice/policy.py](spice/policy.py). Highlights:
+
+- namespace packages only; no `__init__.py` under declared package roots;
+- file names match `^_*[0-9a-z]+_*$`; splitting a file requires naming the
+  seam (no `*2.py`, no generic continuation shards);
+- files flex to 1500 lines but a breach holds them to 1000 until they shrink;
+  routines flex the same way around CCN 20 / length 80;
+- magic-number regressions are a ratchet against `HEAD`, not an amnesty;
+- env-literal inventory covers `SPICE_*` and `CODEX_THREAD_ID` by default;
+  target repos can add tracked name regexes with
+  `[tool.spice.policy] env_name_patterns`;
+- commit subjects fit in 100 columns; bodies are auto-folded.
+
+The gate applies to spice itself: this repository is its own first target.
+Target repos can keep their own tracked gate lanes under the same hook by
+declaring mounted commands and pre-commit policy:
+
+```toml
+[tool.spice.commands]
+fmt-cs = ["dotnet", "format", "--verify-no-changes"]
+
+[tool.spice.policy]
+pre_commit = ["fmt-cs", { label = "assets", run = ["python3", "-m", "tools.assets"] }]
+pre_commit_success = [{ label = "clear asset sticky state", run = ["python3", "-m", "tools.assets", "--clear-sticky"] }]
+
+[tool.spice.policy.pre_commit_builtins]
+formatters = false
+"magic-numbers" = { label = "project magic", run = ["python3", "-m", "tools.magic"] }
+```
+
+Built-in pre-commit keys are `repo-shape`, `staging`, `repo-docs`,
+`formatters`, `env-policy`, `file-shape`, `complexity`, and `magic-numbers`.
+They run before extension steps unless an individual built-in is disabled or
+replaced in tracked policy. `pre_commit_success` uses the same command shape as
+`pre_commit`, but runs only after the whole gate has passed, alongside sticky
+state cleanup.
+
+## Status
+
+Work in progress: an extraction-in-progress toward a standalone, releasable
+product. Surfaces are still settling; the loop described above is real and
+exercised daily, and this repository is its own first target.

spice_harness-0.1.0/README.md

@@ -0,0 +1,165 @@
+# spice
+
+**Simultaneous Production, Integration, and Control Environment.**
+
+spice is an installed agent harness: wrap, steer, supervise, coordinate, and
+audit coding agents across the repos they work on. Install it once, point it at
+a repository, and it provides a closed loop around the agents working there:
+
+- the agent's **transcript is the single source of truth**, and
+- the repo's **filesystem is the single channel of steering**;
+
+supervision, coordination, conscience, and hygiene are derived mechanically
+from those two surfaces.
+
+## Install
+
+```sh
+pip install spice-harness    # or: uv tool install spice-harness
+cd /path/to/your/repo
+spice init               # hooks, spice.sh shim, state scaffolding
+spice dev doctor         # verify drivers, backends, and policy
+```
+
+`spice init` writes machine-local git hook shims under `.spice/` (ignored via
+`.git/info/exclude`) and a tracked `spice.sh` shim. Repo-tracked policy lives
+in your `pyproject.toml` under `[tool.spice.*]` tables. Entrypoint resolution
+is worktree-true: when the current repo is the spice source checkout, generated
+shims and supervisor children put that checkout first on `PYTHONPATH` and run
+`python -m spice`; ordinary target repos use the installed product.
+
+A project can set its default supervised-agent launch model and thinking in
+tracked config, either by editing `pyproject.toml` or by running
+`spice config agent --scope project --model ... --thinking ...`:
+
+```toml
+[tool.spice.agent]
+model = "gpt-5.4"
+thinking = "low"
+```
+
+An operator can override those defaults for just the current worktree:
+
+```sh
+spice config agent --scope worktree --model gpt-5.4 --thinking low
+```
+
+Resolution order is explicit launch flags, then worktree config, then tracked
+project config, then the driver defaults.
+
+A repo can also mount its own tooling into the `spice` namespace:
+
+```toml
+[tool.spice.commands]
+deploy = "./scripts/deploy.sh"
+bench = ["python", "-m", "myproj.bench"]
+```
+
+`spice deploy --env staging` then runs the mounted command from the repo
+root with the remaining arguments passed through verbatim. Built-in verbs
+always win; a mount that shadows one fails loudly.
+
+Mounted names are intentionally one-level verbs (`^[a-z][a-z0-9-]*$`), not
+nested command paths. A repo with a large tool family mounts one namespace
+owner and keeps family grouping inside that repo tool's own arguments:
+
+```toml
+[tool.spice.commands]
+toolbox = ["uv", "run", "toolbox"]
+```
+
+`spice toolbox lint css --fix` then dispatches `lint css --fix` to `toolbox`.
+Do not encode families as dotted, spaced, or ad-hoc hyphenated spice mount
+names such as `lint.css`, `lint css`, or one mount per subcommand; those
+groupings belong behind the mounted repo tool's explicit contract.
+
+### Library seam for repo tools
+
+Mounted commands and tracked pre-commit extensions may import a deliberately
+narrow Python seam from `spice` instead of vendoring harness scaffolding. This
+surface is source-stable for target repos: public names in the modules listed
+below are not removed or renamed silently, and incompatible changes require an
+explicit contract update. Underscored names remain private.
+
+- `spice.errors`: `SpiceError` for user-facing command failures.
+- `spice.policy`: constitution constants and `flex_limit`.
+- `spice.flexstate`: flex-limit sticky-state persistence and rename helpers.
+- `spice.locking`: cross-platform advisory file locks.
+- `spice.paths`: repo-root, state-dir, atomic write, and tool-resolution helpers.
+- `spice.procs`: process-group spawn, liveness, and termination helpers.
+- `spice.repocfg`: tracked `[tool.spice]` table readers.
+- `spice.studies.walk`: tracked/staged path walkers, repo policy exclusions,
+  staged renames, and git blob reads.
+- `spice.studies.fileloc`, `spice.studies.complexity`,
+  `spice.studies.magicnums`, and `spice.studies.envpolicy`: finding
+  dataclasses plus `scan_*`, `detect_*`, and `render_*_board` helpers for
+  project-specific studies.
+
+Everything else is an internal implementation detail unless this section names
+it. A repo tool that needs an unlisted module should either vendor that helper
+or first add the helper to this seam with tests and a stability note.
+
+## The loop
+
+| Surface | Command | What it does |
+| --- | --- | --- |
+| Wrapper | `spice agent run -- <cmd>` (or `./spice.sh`) | Runs shell commands with proxy routing, git-shadow env, and steering injection on stderr. |
+| Lifecycle | `spice agent ensure` / `supervise` | One worktree-bound agent per worktree, started under a neutral skill prompt, watched by a durable supervisor. |
+| Steering | filesystem inbox under `.spice/inbox/` | Durable operator messages; items retire only when the agent semantically ACKs their key in its transcript. |
+| Tasks | `spice task …` | Phase-native Taskwarrior board shared by all worktrees; `task next` is allocator-owned; git sync happens at task boundaries. |
+| Sessions | `spice session` | Transcript forensics: the no-arg briefing is the primary rehydration product, with context-pressure metering. |
+| Cockpit | `spice serve` | Localhost web UI: lanes over worktrees, live transcript streams, lifetime control (Renew / Steer / Drive), task-filter routing, fused lane groups backed by server-side teams; `spice serve teams` and `spice serve browser-artifact-path <file>` expose operator diagnostics for smoke runs. |
+| Conscience | `spice maxim …` | Builtin maxims judged against assistant prose by a local model; violations come back as inbox steering. |
+| Constitution | `spice dev pre-commit` / `spice study …` | Namespace packages, path shape, LOC/byte/complexity flex+sticky gates, magic-number ratchet, env-literal inventory, commit-message policy. |
+
+Session analysis is intentionally tiered. The current tier includes
+`spice session phases` for contiguous working-phase spans and
+`spice session messages` for message-level side/phase/flavor filtering.
+Deeper report families that depend on richer topic/bucket modeling belong in
+a separate analytics tier after the basic phase/message surfaces harden.
+
+## The constitution
+
+The pre-commit gate is the executable form of the project's opinions — see
+[spice/policy.py](spice/policy.py). Highlights:
+
+- namespace packages only; no `__init__.py` under declared package roots;
+- file names match `^_*[0-9a-z]+_*$`; splitting a file requires naming the
+  seam (no `*2.py`, no generic continuation shards);
+- files flex to 1500 lines but a breach holds them to 1000 until they shrink;
+  routines flex the same way around CCN 20 / length 80;
+- magic-number regressions are a ratchet against `HEAD`, not an amnesty;
+- env-literal inventory covers `SPICE_*` and `CODEX_THREAD_ID` by default;
+  target repos can add tracked name regexes with
+  `[tool.spice.policy] env_name_patterns`;
+- commit subjects fit in 100 columns; bodies are auto-folded.
+
+The gate applies to spice itself: this repository is its own first target.
+Target repos can keep their own tracked gate lanes under the same hook by
+declaring mounted commands and pre-commit policy:
+
+```toml
+[tool.spice.commands]
+fmt-cs = ["dotnet", "format", "--verify-no-changes"]
+
+[tool.spice.policy]
+pre_commit = ["fmt-cs", { label = "assets", run = ["python3", "-m", "tools.assets"] }]
+pre_commit_success = [{ label = "clear asset sticky state", run = ["python3", "-m", "tools.assets", "--clear-sticky"] }]
+
+[tool.spice.policy.pre_commit_builtins]
+formatters = false
+"magic-numbers" = { label = "project magic", run = ["python3", "-m", "tools.magic"] }
+```
+
+Built-in pre-commit keys are `repo-shape`, `staging`, `repo-docs`,
+`formatters`, `env-policy`, `file-shape`, `complexity`, and `magic-numbers`.
+They run before extension steps unless an individual built-in is disabled or
+replaced in tracked policy. `pre_commit_success` uses the same command shape as
+`pre_commit`, but runs only after the whole gate has passed, alongside sticky
+state cleanup.
+
+## Status
+
+Work in progress: an extraction-in-progress toward a standalone, releasable
+product. Surfaces are still settling; the loop described above is real and
+exercised daily, and this repository is its own first target.

spice_harness-0.1.0/pyproject.toml

@@ -0,0 +1,55 @@
+[build-system]
+requires = ["setuptools>=80", "wheel"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "spice-harness"
+version = "0.1.0"
+description = "Simultaneous Production, Integration, and Control Environment: an agent harness for coding repositories."
+readme = "README.md"
+requires-python = ">=3.12"
+license = "MIT"
+dependencies = [
+    "lizard>=1.21",
+    "ruff>=0.11",
+    "watchfiles>=1.1",
+]
+
+[project.urls]
+Homepage = "https://github.com/infimalabs/spice"
+Repository = "https://github.com/infimalabs/spice"
+Issues = "https://github.com/infimalabs/spice/issues"
+
+[project.scripts]
+spice = "spice.cli.entry:main"
+
+[tool.setuptools.packages.find]
+where = ["."]
+include = ["spice*"]
+namespaces = true
+
+[tool.setuptools.package-data]
+"spice.agent" = ["*.md"]
+"spice.serve.static" = ["*.css", "*.js", "*.ico"]
+
+[dependency-groups]
+dev = [
+    "pytest>=8.0",
+]
+
+[tool.ruff]
+target-version = "py312"
+line-length = 88
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]
+
+[tool.spice.policy]
+package_roots = ["spice"]
+
+[tool.spice.agent]
+model = "gpt-5.5"
+thinking = "xhigh"
+
+[tool.spice.tasks]
+stems = ["session", "mail", "hooks", "studies", "cli", "lifecycle", "tests"]

spice_harness-0.1.0/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+

spice_harness-0.1.0/spice/__main__.py

@@ -0,0 +1,10 @@
+"""`python -m spice` — the installation-independent entrypoint.
+
+The agent supervisor respawns through this module so a detached process finds
+the same interpreter. Worktree source checkouts are put first on PYTHONPATH;
+ordinary target repos use the installed package.
+"""
+
+from spice.cli.entry import main
+
+raise SystemExit(main())

spice_harness-0.1.0/spice/agent/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: spice
+description: Start or resume a worktree-bound spice agent from a neutral skill prompt. Use when a server or wrapper launches an agent for an existing worktree and the initial prompt must not contain operator prose.
+metadata:
+  short-description: Worktree-bound spice agent bootstrap
+---
+
+# spice
+
+You were started by spice, the Simultaneous Production, Integration, and
+Control Environment. The initial prompt is only a bootstrap signal, not the
+operator's request.
+
+Before sending any assistant prose, run these commands in this order:
+
+1. `spice agent activation`
+2. `spice session`
+3. `spice task status`
+
+If a tool call is impossible, say only what prevented it and stop. Otherwise, let the command outputs establish context first, then respond to pending steering directly. Use those outputs, side-channel steering, and the active task board as your source of truth. Do not infer a durable task from this skill invocation.
+
+If continuity is clipped, deepen with `spice session sweep --count N`, `spice session timeline --limit N`, `spice session turns --turn-id ... --view full`, `spice session compactions`, or `spice session commits`.
+
+## Working Rules
+
+- Stay in the current worktree unless live steering explicitly changes scope.
+- Recover lane identity from current repo state and `spice agent activation`; do not trust prior messages over current worktree state.
+- Run shell commands through `./spice.sh` when the repo provides it, or `spice agent run -- <command>` otherwise.
+- Use `./spice.sh proxy <command>` when a command must keep native argument and output semantics; with no proxy installed the wrapper drops `proxy` and runs the command directly, while steering injection still applies.
+- Pull work with `spice task next`, not by eyeballing a board. `task next` returns the globally-best ready task across all open boards and claims it; the selected board is derived from the claimed task, not stored as a hidden default.
+- Completing a task phase advances it: use `spice task done <handle> --validation "..."` to move a task from implementation into its review phase, then run `spice task next` for reviewer assignment. Do not manually claim your own review; if `task next` assigns it anyway, treat that as an allocator assignment and verify the task description is current before `spice task review <handle> --finding clean --note "description current; ..."`. Read the printed `advanced ... -> <phase>` / `completed ...` line, then run `task next` again; a task is not finished while later phases remain.
+- Use `spice task add` for backlog items and `spice task note` for small observations attached to a task.
+- When the tooling itself fights you (weak default, surprising output, a command that did not work as emitted), record it with `spice task oops "..." --severity ... --kind ...`. It files the friction as a task on the deferred `oops` triage board (a human works that hatch); capture the speed bump rather than silently working around it.
+- Read side-channel steering before acting and acknowledge it through the normal agent workflow.
+- Use `SAY:` in an assistant message only for genuine blockers, decisions worth operator attention, or important milestones. Do not shell out to `say` directly.
+- Treat a dirty worktree as pressure toward commit, split, or cleanup.
+- Do not spawn sub-agents.
+- Keep going while progress is real, but let the selected task, its board, and task notes shape the work instead of treating this skill as a standing user demand.
+
+## Prompt Boundary
+
+The wrapper must never pass operator prose as the initial prompt. If you need the current ask, recover it from `spice session`, `spice task status`, and side-channel messages.

spice_harness-0.1.0/spice/agent/activation.py

@@ -0,0 +1,60 @@
+"""The activation packet: the contract an agent reads before doing anything.
+
+`spice agent activation` is the first command a freshly started worktree
+agent runs (the skill mandates it). It binds the ambient thread id into the
+lane's agent state, installs the git hooks, refreshes the baseline when safe,
+and prints the working contract: git hygiene, validation expectations, and
+the command surface that is the agent's source of truth.
+"""
+
+from __future__ import annotations
+
+from pathlib import Path
+
+
+def activation_git_hygiene_lines() -> list[str]:
+    return [
+        (
+            "work_commit_contract=commit your changes into coherent, validated "
+            "local history before completing a task; amend or reshape your own "
+            "commits freely while iterating — task done captures exactly the "
+            "commits you made"
+        ),
+        (
+            "work_focus_contract=you only ever manage your own local git state; "
+            "synchronizing it with everyone else's work happens automatically at "
+            "task boundaries, so there is nothing to pull or push — just build "
+            "tasks and complete them"
+        ),
+    ]
+
+
+def activation_source_root_lines(repo_root: Path) -> list[str]:
+    return [f"project_source_root={repo_root.resolve()}"]
+
+
+def activation_browser_validation_lines() -> list[str]:
+    return [
+        (
+            "browser_validation_contract=for executable live browser checks, "
+            "start with the Playwright MCP server named playwright; if no live "
+            "browser path is available, report that browser coverage did not "
+            "run and restore Playwright MCP before continuing; do not "
+            "substitute static tests or non-browser checks for required "
+            "browser coverage"
+        )
+    ]
+
+
+def activation_command_surface_lines() -> list[str]:
+    return [
+        "session=spice session",
+        "task_status=spice task status",
+        "task_next=spice task next",
+        "task_show=spice task show <handle>",
+        "tasks=spice task list",
+        'task_done=spice task done <handle> --validation "..."',
+        "inbox_steering=automatic wrapper/side-channel injection; no public mail command",
+        "side_channel=operator steering arrives through the supervisor socket",
+        "initial_prompt_policy=skill_invocation_only",
+    ]