repo-harness 0.11.2 → 0.12.0

package/AGENTS.md

@@ -46,7 +46,7 @@ This repository self-hosts the `repo-harness` contract; the former `repo-harness
 - Treat `.ai/harness/brain-manifest.json` and `repo-harness run sync-brain-docs` as explicit operator-invoked export surfaces only; hooks and workflow checks must not read, write, or gate on external brain-vault state.
 - Treat Waza as Codex-first: `~/.codex/skills` is the Codex runtime source; `~/.agents/skills` is skills CLI staging/cache only. Update by staging upstream Waza, copying the eight managed `SKILL.md` files into Codex, and verifying with `cmp`.
 - Use `docs/reference-configs/external-tooling.md` and `bash scripts/check-agent-tooling.sh --host both --check-updates` for environment checks; this self-host repo vendors CodeGraph as a dev dependency while generated downstream repos keep the global MCP default unless local policy opts in.
-- When changing adoption planner or transaction code, verify `repo-harness adopt --repo . --dry-run` and a fixture apply use the same TS operation model.
+- When changing adoption planner or transaction code, verify `repo-harness init --repo . --dry-run` and a fixture apply use the same TS operation model.
 - Treat repo-local `.claude/settings.json` and `.codex/hooks.json` hook adapters as retired legacy config; migration may back them up locally, but they are not product deliverables.
 
 ## Code Optimization Principles
@@ -65,7 +65,7 @@ bash scripts/check-architecture-sync.sh
 bash scripts/check-task-sync.sh
 repo-harness run check-task-workflow --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 ```
 
 <!-- BEGIN ARCHITECTURE CONTRACT -->

package/CLAUDE.md

@@ -46,7 +46,7 @@ This repository self-hosts the `repo-harness` contract; the former `repo-harness
 - Treat `.ai/harness/brain-manifest.json` and `repo-harness run sync-brain-docs` as explicit operator-invoked export surfaces only; hooks and workflow checks must not read, write, or gate on external brain-vault state.
 - Treat Waza as Codex-first: `~/.codex/skills` is the Codex runtime source; `~/.agents/skills` is skills CLI staging/cache only. Update by staging upstream Waza, copying the eight managed `SKILL.md` files into Codex, and verifying with `cmp`.
 - Use `docs/reference-configs/external-tooling.md` and `bash scripts/check-agent-tooling.sh --host both --check-updates` for environment checks; this self-host repo vendors CodeGraph as a dev dependency while generated downstream repos keep the global MCP default unless local policy opts in.
-- When changing adoption planner or transaction code, verify `repo-harness adopt --repo . --dry-run` and a fixture apply use the same TS operation model.
+- When changing adoption planner or transaction code, verify `repo-harness init --repo . --dry-run` and a fixture apply use the same TS operation model.
 - Treat repo-local `.claude/settings.json` and `.codex/hooks.json` hook adapters as retired legacy config; migration may back them up locally, but they are not product deliverables.
 
 ## Code Optimization Principles
@@ -65,7 +65,7 @@ bash scripts/check-architecture-sync.sh
 bash scripts/check-task-sync.sh
 repo-harness run check-task-workflow --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 ```
 
 <!-- BEGIN ARCHITECTURE CONTRACT -->

package/README.es.md

@@ -82,7 +82,7 @@ artifacts.
 ## Novedades
 
 Las notas de versión viven en [`docs/CHANGELOG.md`](docs/CHANGELOG.md). La línea
-actual es `0.11.2`.
+actual es `0.12.0`.
 
 ## Cómo funciona
 
@@ -91,7 +91,7 @@ En conjunto hay tres capas y un único runtime typed para host events:
 1. **Capa del paquete fuente**: este repositorio mantiene la CLI, los command
    skill facades, los templates, los hook assets, el workflow contract, los tests
    y el release gate.
-2. **Capa del contract del repositorio objetivo**: `repo-harness adopt` o la
+2. **Capa del contract del repositorio objetivo**: `repo-harness init` o la
    migración escribe `docs/spec.md`, `plans/`, `tasks/`, `.ai/context/`,
    `.ai/harness/` y helper scripts. `.ai/hooks/lib/workflow-state.sh` es solo
    una proyección de operator helper.
@@ -225,7 +225,7 @@ repo-harness install
 ```
 
 `repo-harness install` es el bootstrap global, `repo-harness update` es el refresco
-user-level y `repo-harness adopt` es el refresco repo-local. `repo-harness install`
+user-level y `repo-harness init` es el refresco repo-local. `repo-harness install`
 configura el CLI, los hook adapters de nivel usuario, Waza, Mermaid, el brain
 root y CodeGraph MCP; el viejo camino Claude plugin `scripts/setup-plugins.sh`
 queda retirado.
@@ -235,17 +235,17 @@ queda retirado.
 En un repositorio existente, ejecuta desde el repo root:
 
 ```bash
-repo-harness adopt --dry-run
+repo-harness init --dry-run
 ```
 
 Aplica solo después de que el reporte del dry-run sea correcto:
 
 ```bash
-repo-harness adopt
+repo-harness init
 ```
 
 Para un proyecto o módulo nuevo, usa el modo scaffold de `repo-harness-setup`.
-Para un repositorio existente, usa `repo-harness adopt`; este instala o refresca
+Para un repositorio existente, usa `repo-harness init`; este instala o refresca
 el harness y no crea el stack tecnológico de la aplicación.
 
 ### Cómo se ve el éxito
@@ -413,8 +413,8 @@ Guards habituales:
 
 ## Release actual
 
-- npm package: `repo-harness@0.11.2`
-- Generated workflow stamp: `repo-harness@0.11.2+template@0.11.2`
+- npm package: `repo-harness@0.12.0`
+- Generated workflow stamp: `repo-harness@0.12.0+template@0.12.0`
 - GitHub repository: `Ancienttwo/repo-harness`
 - Release history: [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -455,7 +455,7 @@ hooks ejecutan:
 
 - Router: `repo-harness` (Skill raíz, sincronizado sin condición en cada
   profile)
-- Capa setup: `repo-harness-setup` (modos adopt/init, migrate, upgrade,
+- Capa setup: `repo-harness-setup` (modos init, migrate, upgrade,
   repair, scaffold, y capability-configuration; router-only, nunca
   descubierto automáticamente por un profile)
 - Planning: `repo-harness-plan` (crea un plan decision-complete, o revisa uno
@@ -492,7 +492,7 @@ Sprint detallado; prepara un prompt `/goal` acotado para Codex/Claude y
 mantiene el PRD/Sprint como source of truth. Si falta ese documento, el modo
 Goal debe pedirlo antes de empezar implementación desde el chat.
 
-`repo-harness adopt` se usa para repositorios existentes; el modo scaffold de
+`repo-harness init` se usa para repositorios existentes; el modo scaffold de
 `repo-harness-setup` queda para crear proyectos o módulos nuevos. `hooks-init`,
 `docs-init` y `create-project-dirs` son pasos internos, no commands públicos.
 
@@ -553,7 +553,7 @@ bun test
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```
@@ -628,7 +628,7 @@ bash scripts/check-architecture-sync.sh
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```

package/README.fr.md

@@ -82,7 +82,7 @@ l'emportent.
 ## Nouveautés
 
 Les notes de version vivent dans [`docs/CHANGELOG.md`](docs/CHANGELOG.md). La
-ligne actuelle est `0.11.2`.
+ligne actuelle est `0.12.0`.
 
 ## Comment ça marche
 
@@ -91,7 +91,7 @@ L'ensemble se découpe en trois couches, avec un seul runtime typed pour les hos
 1. **Couche package source** : ce dépôt maintient le CLI, les command skill
    facades, les templates, les hook assets, le workflow contract, les tests et le
    release gate.
-2. **Couche contrat du dépôt cible** : `repo-harness adopt` ou une migration écrit
+2. **Couche contrat du dépôt cible** : `repo-harness init` ou une migration écrit
    `docs/spec.md`, `plans/`, `tasks/`, `.ai/context/`, `.ai/harness/` et les helper
    scripts. `.ai/hooks/lib/workflow-state.sh` n'est qu'une projection d'operator helper.
 3. **Couche host adapter** : les `~/.claude/settings.json` et `~/.codex/hooks.json`
@@ -225,7 +225,7 @@ repo-harness install
 ```
 
 `repo-harness install` sert au bootstrap global, `repo-harness update` au
-rafraîchissement user-level, et `repo-harness adopt` au rafraîchissement
+rafraîchissement user-level, et `repo-harness init` au rafraîchissement
 repo-local. `repo-harness install` configure le CLI, les hook adapters de niveau
 utilisateur, Waza, Mermaid, le brain root et CodeGraph MCP ; l'ancien chemin
 Claude plugin `scripts/setup-plugins.sh` est retiré.
@@ -233,26 +233,26 @@ Claude plugin `scripts/setup-plugins.sh` est retiré.
 ### 3. Prévisualiser le contrat repo-local
 
 ```bash
-repo-harness adopt --dry-run
+repo-harness init --dry-run
 ```
 
 Lancez le dry-run depuis le repo root. Il rapporte les specs, l'état des tasks,
 le helper runtime, la cible des hook adapters et les fichiers de vérification qui
 seraient créés ou rafraîchis. Il ne doit pas créer de stack applicatif : un dépôt
-existant utilise `repo-harness adopt`, un nouveau projet ou module utilise le
+existant utilise `repo-harness init`, un nouveau projet ou module utilise le
 mode scaffold de `repo-harness-setup`.
 
 ### 4. Appliquer, puis prouver le workflow
 
 ```bash
-repo-harness adopt
+repo-harness init
 bash scripts/check-task-workflow.sh --strict
 bun test
 ```
 
 Après application, le dépôt doit avoir un contract file-backed auditable plutôt
 qu'une configuration de chat propre à un outil. Pour un nouveau projet ou module,
-utilisez le mode scaffold de `repo-harness-setup` au lieu de `adopt`. Les maintainers éditant le
+utilisez le mode scaffold de `repo-harness-setup` au lieu de `init`. Les maintainers éditant le
 package lui-même ont besoin d'un source checkout — voir
 [Maintainer Reference](#maintainer-reference).
 
@@ -414,8 +414,8 @@ Guards courants :
 
 ## Release actuelle
 
-- npm package : `repo-harness@0.11.2`
-- Generated workflow stamp : `repo-harness@0.11.2+template@0.11.2`
+- npm package : `repo-harness@0.12.0`
+- Generated workflow stamp : `repo-harness@0.12.0+template@0.12.0`
 - GitHub repository : `Ancienttwo/repo-harness`
 - Release history : [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -456,7 +456,7 @@ appartient au CLI et aux hooks :
 
 - Router : `repo-harness` (Skill racine, synchronisé sans condition sur chaque
   profile)
-- Couche setup : `repo-harness-setup` (modes adopt/init, migrate, upgrade,
+- Couche setup : `repo-harness-setup` (modes init, migrate, upgrade,
   repair, scaffold, et capability-configuration ; router-only, jamais
   découvert automatiquement par un profile)
 - Planning : `repo-harness-plan` (crée un plan decision-complete, ou revoit un
@@ -496,7 +496,7 @@ Codex/Claude et garde le PRD/Sprint comme source of truth. Si ce document
 manque, le mode Goal doit le demander avant de lancer une implémentation depuis
 le chat.
 
-`repo-harness adopt` sert aux dépôts existants ; le mode scaffold de
+`repo-harness init` sert aux dépôts existants ; le mode scaffold de
 `repo-harness-setup` sert à créer un nouveau projet ou module. `hooks-init`,
 `docs-init` et `create-project-dirs` sont des étapes internes, pas des
 commands publiques.
@@ -558,7 +558,7 @@ bun test
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```
@@ -633,7 +633,7 @@ bash scripts/check-architecture-sync.sh
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```

package/README.ja.md

@@ -71,7 +71,7 @@ review、checks、handoff と食い違う場合は、source artifacts を優先
 ## What's New
 
 リリースノートは [`docs/CHANGELOG.md`](docs/CHANGELOG.md) にあります。現在の
-ラインは `0.11.2` です。
+ラインは `0.12.0` です。
 
 ## 仕組み
 
@@ -79,7 +79,7 @@ review、checks、handoff と食い違う場合は、source artifacts を優先
 
 1. **ソースパッケージ層**：本リポジトリが CLI、CLI-backed command facades、templates、hook assets、
    workflow contract、tests、release gate を所有します。
-2. **対象リポジトリ contract 層**：`repo-harness adopt` または migration が、`docs/spec.md`、
+2. **対象リポジトリ contract 層**：`repo-harness init` または migration が、`docs/spec.md`、
    `plans/`、`tasks/`、`.ai/context/`、`.ai/harness/`、helper scripts を書き込みます。
    `.ai/hooks/lib/workflow-state.sh` は operator helper projection だけです。
 3. **Host adapter 層**：user-level の `~/.claude/settings.json` と `~/.codex/hooks.json` が
@@ -203,7 +203,7 @@ repo-harness install
 ```
 
 `repo-harness install` は global bootstrap、`repo-harness update` は
-user-level refresh、`repo-harness adopt` は repo-local refresh です。`repo-harness install` は CLI、user-level hook adapters、Waza、Mermaid、
+user-level refresh、`repo-harness init` は repo-local refresh です。`repo-harness install` は CLI、user-level hook adapters、Waza、Mermaid、
 brain root、CodeGraph MCP を設定し、退役した `scripts/setup-plugins.sh` の Claude plugin path は使いません。
 
 package 本体を編集する maintainer はソースの checkout が必要です
@@ -214,17 +214,17 @@ package 本体を編集する maintainer はソースの checkout が必要で
 既存リポジトリでは repo root から実行します。
 
 ```bash
-repo-harness adopt --dry-run
+repo-harness init --dry-run
 ```
 
 dry-run のレポートが正しいことを確認してから適用します。
 
 ```bash
-repo-harness adopt
+repo-harness init
 ```
 
 新しいプロジェクトやモジュールには `repo-harness-setup` の scaffold mode を使います。既存リポジトリには
-`repo-harness adopt` を使います。これは harness をインストールまたはリフレッシュするもので、アプリケーション
+`repo-harness init` を使います。これは harness をインストールまたはリフレッシュするもので、アプリケーション
 スタックは作成しません。
 
 ### 成功した状態
@@ -389,8 +389,8 @@ hook がブロックしたときは、まず terminal の構造化された出
 
 ## 現在の Release
 
-- npm package：`repo-harness@0.11.2`
-- Generated workflow stamp：`repo-harness@0.11.2+template@0.11.2`
+- npm package：`repo-harness@0.12.0`
+- Generated workflow stamp：`repo-harness@0.12.0+template@0.12.0`
 - GitHub repository：`Ancienttwo/repo-harness`
 - Release history：[`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -427,7 +427,7 @@ package）と `assets/skill-commands/`（その場で進化する survivor）に
 host skill discovery の範囲を保ちつつ、実行は CLI と hooks が担います。
 
 - Router：`repo-harness`（root Skill。すべての profile に無条件で同期される）
-- Setup layer：`repo-harness-setup`（adopt/init、migrate、upgrade、repair、
+- Setup layer：`repo-harness-setup`（init、migrate、upgrade、repair、
   scaffold、capability-configuration の各 mode。router-only で、どの profile
   からも自動発見されない）
 - Planning：`repo-harness-plan`（decision-complete plan を作成、または既存
@@ -465,7 +465,7 @@ artifact がある場合だけ使い、Codex/Claude 向けの bounded `/goal` pr
 備し、PRD/Sprint を source of truth として維持します。その文書がない場合、
 Goal mode はチャット文脈から実装を始めず、先に文書を要求しなければなりません。
 
-`repo-harness adopt` は既存リポジトリ向け、`repo-harness-setup` の scaffold
+`repo-harness init` は既存リポジトリ向け、`repo-harness-setup` の scaffold
 mode は新しいプロジェクトやモジュールを作成します。
 `hooks-init`、`docs-init`、`create-project-dirs` は内部ステップであり、公開 commands ではありません。
 
@@ -525,7 +525,7 @@ bun test
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```
@@ -600,7 +600,7 @@ bash scripts/check-architecture-sync.sh
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```

package/README.md

@@ -88,7 +88,7 @@ active plan, contract, review, checks, or handoff, the source artifacts win.
 ## What's New
 
 Release notes live in [`docs/CHANGELOG.md`](docs/CHANGELOG.md). The current line
-is `0.11.2`.
+is `0.12.0`.
 
 ## How It Works
 
@@ -97,7 +97,7 @@ The design has three layers:
 1. **Source package**: this repository owns the CLI, CLI-backed command facades,
    templates, typed hook handlers, the operator-helper asset, workflow contract,
    tests, and release gate.
-2. **Target repo contract**: `repo-harness adopt` or migration writes repo-local
+2. **Target repo contract**: `repo-harness init` or migration writes repo-local
    files such as `docs/spec.md`, `plans/`, `tasks/`, `.ai/context/`,
    `.ai/harness/`, helper scripts, and `.ai/hooks/`.
 3. **Host adapters**: user-level `~/.claude/settings.json` and
@@ -301,7 +301,7 @@ It does not apply repo-local workflow files to the current directory.
 For an Agent-owned, read-only bootstrap audit, run `repo-harness setup check
 --json` or add `--check-updates` for version and adopted-repo refresh
 advisories. `setup check` is not a runtime hook: it does not write user-level
-files, install updates, run `adopt`, or register adapters. It emits
+files, install updates, run `init`, or register adapters. It emits
 `agent_actions` with the reason, risk, target files, optional command, and
 verification surface for the Agent to execute deliberately.
 `repo-harness init-hook` remains a compatibility alias.
@@ -322,7 +322,7 @@ repo-harness install --target both --location global
 repo-harness update --check
 
 # Refresh repo-local workflow files in an adopted repository.
-repo-harness adopt --repo /path/to/repo
+repo-harness init --repo /path/to/repo
 ```
 
 `repo-harness install --target codex|both --location global` also resolves and
@@ -343,19 +343,19 @@ it never writes a silent default.
 ### 3. Preview the repo-local contract
 
 ```bash
-repo-harness adopt --dry-run
+repo-harness init --dry-run
 ```
 
 Run the dry run from the target repository root. It reports the specs, task
 state, helper runtime, hook adapter target, and verification files that would be
 created or refreshed. It should not create an application stack; existing repos
-use `repo-harness adopt`, while new projects or modules use
+use `repo-harness init`, while new projects or modules use
 `repo-harness-setup`'s scaffold mode.
 
 ### 4. Apply, then prove the workflow
 
 ```bash
-repo-harness adopt
+repo-harness init
 bash scripts/check-task-workflow.sh --strict
 bun test
 ```
@@ -366,7 +366,7 @@ tool-specific chat setup. Agents should be able to find the stable intent in
 `.ai/harness/handoff/`.
 
 For a new project or module, use `repo-harness-setup`'s scaffold mode instead
-of `adopt`; it installs or refreshes the harness without creating an
+of `init`; it installs or refreshes the harness without creating an
 application stack. Maintainers editing the package itself need a source checkout
 — see [Maintainer Reference](#maintainer-reference).
 
@@ -470,7 +470,7 @@ Sprint.
 
 The ChatGPT Connector registers one endpoint URL, not one repository per URL.
 Adopted repos are discovered from `~/.repo-harness/registered-repos.json`, which
-is updated by `repo-harness adopt`, `repo-harness init`, and user-scope ChatGPT
+is updated by `repo-harness init` and user-scope ChatGPT
 setup. Stale registry entries are ignored unless the live repo still has
 repo-harness adoption markers.
 
@@ -638,8 +638,8 @@ Most common guards:
 
 ## Current Release
 
-- npm package: `repo-harness@0.11.2`
-- Generated workflow stamp: `repo-harness@0.11.2+template@0.11.2`
+- npm package: `repo-harness@0.12.0`
+- Generated workflow stamp: `repo-harness@0.12.0+template@0.12.0`
 - GitHub repository: `Ancienttwo/repo-harness`
 - Release history: [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -681,7 +681,7 @@ place). They keep host skill discovery bounded while the CLI and hooks own
 execution:
 
 - Router: `repo-harness` (root Skill, synced unconditionally to every profile)
-- Setup layer: `repo-harness-setup` (adopt/init, migrate, upgrade, repair,
+- Setup layer: `repo-harness-setup` (init, migrate, upgrade, repair,
   scaffold, and capability-configuration modes; router-only, never
   auto-discovered by a profile)
 - Planning: `repo-harness-plan` (create a decision-complete plan, or review an
@@ -722,7 +722,7 @@ bounded Codex/Claude `/goal` prompt and keeps the PRD/Sprint as the source of
 truth. If that document is missing, Goal mode must ask for it instead of
 starting implementation from chat context.
 
-`repo-harness adopt` is for an existing repo; `repo-harness-setup`'s scaffold
+`repo-harness init` is for an existing repo; `repo-harness-setup`'s scaffold
 mode creates a new project or module scaffold as a side mode. `hooks-init`,
 `docs-init`, and `create-project-dirs` are internal steps, not public
 commands.
@@ -866,7 +866,7 @@ bash scripts/check-architecture-sync.sh
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```

package/README.zh-CN.md

@@ -71,7 +71,7 @@ review、checks 或 handoff 冲突，以 source artifacts 为准。
 
 ## What's New
 
-Release notes 见 [`docs/CHANGELOG.md`](docs/CHANGELOG.md)，当前版本线是 `0.11.2`。
+Release notes 见 [`docs/CHANGELOG.md`](docs/CHANGELOG.md)，当前版本线是 `0.12.0`。
 
 ## 工作原理
 
@@ -79,7 +79,7 @@ Release notes 见 [`docs/CHANGELOG.md`](docs/CHANGELOG.md)，当前版本线是
 
 1. **源码包层**：本仓库维护 CLI、CLI-backed command facades、templates、hook assets、
    workflow contract、tests 和 release gate。
-2. **目标仓库合约层**：`repo-harness adopt` 或 migration 会写入 `docs/spec.md`、
+2. **目标仓库合约层**：`repo-harness init` 或 migration 会写入 `docs/spec.md`、
    `plans/`、`tasks/`、`.ai/context/`、`.ai/harness/` 和 helper scripts；
    `.ai/hooks/lib/workflow-state.sh` 只作为 operator helper projection。
 3. **Host adapter 层**：user-level `~/.claude/settings.json` 和 `~/.codex/hooks.json`
@@ -242,11 +242,10 @@ skill aliases，安装 user-level hook adapters，配置 Waza runtime skills，
 root 持久化到 `~/.repo-harness/config.json`，并配置 CodeGraph MCP。这个命令是
 幂等的：如果 CLI 已经来自 Bun global package source，它会跳过 CLI 重装，但仍继续
 刷新 host runtime pieces。它不会把当前目录默认迁移成 repo-local workflow。
-`repo-harness init` 保留为兼容 alias，给已有脚本用。
 
 如果要让 Agent 做只读 bootstrap audit，运行 `repo-harness setup check
 --json`；需要版本和已接入仓库刷新提示时加 `--check-updates`。`setup check`
-不是 runtime hook：它不会写 user-level files、安装更新、执行 `adopt` 或注册
+不是 runtime hook：它不会写 user-level files、安装更新、执行 `init` 或注册
 adapters，只输出带 reason、risk、targets、可选 command 和 verification 的
 `agent_actions`，由 Agent 再显式执行。
 `repo-harness init-hook` 保留为兼容 alias。
@@ -267,23 +266,23 @@ repo-harness install --target both --location global
 repo-harness update --check
 
 # 刷新已接入仓库里的 repo-local workflow 文件。
-repo-harness adopt --repo /path/to/repo
+repo-harness init --repo /path/to/repo
 ```
 
 ### 3. 预览 repo-local contract
 
 ```bash
-repo-harness adopt --dry-run
+repo-harness init --dry-run
 ```
 
 在目标仓库根目录运行 dry-run。它会报告将要创建或刷新的 spec、task state、
 helper runtime、hook adapter target 和 verification files。它不会创建应用技术栈；
-已有仓库走 `repo-harness adopt`，新项目或新模块走 `repo-harness-setup` 的 scaffold mode。
+已有仓库走 `repo-harness init`，新项目或新模块走 `repo-harness-setup` 的 scaffold mode。
 
 ### 4. 应用后验证 workflow
 
 ```bash
-repo-harness adopt
+repo-harness init
 bash scripts/check-task-workflow.sh --strict
 bun test
 ```
@@ -292,7 +291,7 @@ bun test
 聊天配置。agent 应该能在 `docs/spec.md` 找到稳定意图，在 `plans/` 和 `tasks/`
 找到执行状态，在 `.ai/harness/handoff/` 找到可恢复状态。
 
-新项目或新模块用 `repo-harness-setup` 的 scaffold mode 代替 `adopt`；它会安装或
+新项目或新模块用 `repo-harness-setup` 的 scaffold mode 代替 `init`；它会安装或
 刷新 harness，不会创建应用技术栈。维护者编辑 package 源码需要 source checkout
 —— 见 [Maintainer Reference](#maintainer-reference)。
 
@@ -449,8 +448,8 @@ hook block 工作时，先看 terminal 里的结构化输出。核心字段是
 
 ## 当前 Release
 
-- npm package：`repo-harness@0.11.2`
-- Generated workflow stamp：`repo-harness@0.11.2+template@0.11.2`
+- npm package：`repo-harness@0.12.0`
+- Generated workflow stamp：`repo-harness@0.12.0+template@0.12.0`
 - GitHub repository：`Ancienttwo/repo-harness`
 - Release history：[`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -488,7 +487,7 @@ canonical rule-owner package 分布在 `assets/skills/`（已激活的 canonical
 的边界，真正执行由 CLI 和 hooks 负责：
 
 - Router：`repo-harness`（root Skill，无条件同步到每个 profile）
-- Setup layer：`repo-harness-setup`（adopt/init、migrate、upgrade、repair、
+- Setup layer：`repo-harness-setup`（init、migrate、upgrade、repair、
   scaffold、capability-configuration 各 mode；仅 router-only，不被任何 profile
   自动发现）
 - Planning：`repo-harness-plan`（创建 decision-complete plan，或 review 已有 plan）
@@ -521,7 +520,7 @@ Sprint artifact 后使用，用它生成有边界的 Codex/Claude `/goal` prompt
 PRD/Sprint 保持为 source of truth。缺少这份文档时，Goal mode 必须先要求补文档，
 而不是从聊天上下文直接开工。
 
-`repo-harness adopt` 用于已有仓库；`repo-harness-setup` 的 scaffold mode 创建新
+`repo-harness init` 用于已有仓库；`repo-harness-setup` 的 scaffold mode 创建新
 项目或模块。`hooks-init`、`docs-init` 和 `create-project-dirs` 是内部步骤，不是
 公共 commands。
 
@@ -590,7 +589,7 @@ bash scripts/check-architecture-sync.sh
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```
@@ -665,7 +664,7 @@ bash scripts/check-architecture-sync.sh
 bash scripts/check-task-sync.sh
 bash scripts/check-task-workflow.sh --strict
 bun scripts/inspect-project-state.ts --repo . --format text
-bun src/cli/index.ts adopt --repo . --dry-run
+bun src/cli/index.ts init --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```

package/SKILL.md

@@ -18,7 +18,7 @@ Treat that JSON as the state authority; read Plan, Contract, checks, handoff, or
 
 ## Actions
 
-1. **setup** — install, adopt, migrate, repair, or scaffold the harness. Use `repo-harness-setup`; inspect first with `repo-harness adopt --repo . --dry-run`, or run `repo-harness docs show harness-overview` when detail is needed.
+1. **setup** — install, init, migrate, repair, or scaffold the harness. Use `repo-harness-setup`; inspect first with `repo-harness init --repo . --dry-run`, or run `repo-harness docs show harness-overview` when detail is needed.
 2. **plan** — create or capture a decision-complete plan. Use `repo-harness-plan`; run `repo-harness docs show agentic-development-flow` for promotion boundaries.
 3. **execute** — continue the active task via its resolved profile and allowed paths: Lite (brief → edit → test), Standard (plan → edit → verify → one review), Strict (Contract/worktree/checks/external-acceptance).
 4. **verify** — run targeted tests and the profile-required gates. Use `repo-harness-check`; never infer provider-owned evidence.

package/agents/fleet/deep-worker.md

@@ -0,0 +1,14 @@
+---
+name: deep-worker
+description: Heavy execution worker on Opus at high effort. Use for hard, well-scoped execution — cross-module refactors, tricky concurrency or state fixes, changes that must land right in one pass; verifies with the project's real commands and returns `RESULT: DONE/PARTIAL/BLOCKED` with the evidence. Not for planning, architecture, or acceptance judgment — those go to deep-reasoner or gatekeeper; routine execution goes to fast-worker.
+model: opus
+effort: high
+---
+
+You are a heavy execution worker. An orchestrator hands you the harder well-scoped tasks — cross-module refactors, tricky concurrency or state fixes, changes that must land right in one pass — and you execute them directly and return. You do not plan, decide architecture, or ship.
+
+- **Result first.** When you finish a dispatched task, your final message opens with exactly one of `RESULT: DONE`, `RESULT: PARTIAL`, `RESULT: BLOCKED` — the orchestrator machine-reads this line. DONE = the task is complete and its verification ran clean this turn; PARTIAL = you delivered part but a gate failed or scope remained; BLOCKED = a precondition stopped you (ambiguity, a missing dependency, or a call above your role).
+- **Stay in scope; hand back judgment.** Execute immediately — do not re-plan, widen scope, or spawn subagents, and edit only the files the task names or clearly implies. If it turns out ambiguous, architectural, or higher-risk than stated, stop and return `RESULT: BLOCKED` with what you found instead of deciding yourself.
+- **Prove it ran.** Verify changes with the project's real commands (typecheck, tests, build) and paste the actual output. A success claim counts only if its command ran this turn with output in the transcript; otherwise label it `[inferred]` or `[unverified]`. Never report `RESULT: DONE` without verification output.
+- **Boundaries.** By default you do not commit, push, open or merge PRs, install global dependencies, or touch code outside the task's surface — those are the orchestrator's or the gate's calls unless a dispatch explicitly orders one.
+- **Sign-off.** Lead with the `RESULT:` line, then list files changed with `file:line` references, the verification command → its outcome, and anything you deliberately left out of scope. Keep it compact — no process narration.

package/agents/fleet/fast-worker.md

@@ -1,8 +1,8 @@
 ---
 name: fast-worker
-description: Fast execution worker on Sonnet at max effort. Use for well-scoped implementation, tests, refactoring, documentation, and mechanical changes; verifies with the project's real commands and returns `RESULT: DONE/PARTIAL/BLOCKED` with the evidence. Not for planning, architecture, or high-risk judgment — those go to deep-reasoner or stay with the orchestrator.
-model: sonnet
-effort: max
+description: Fast execution worker on Opus at medium effort. Use for well-scoped implementation, tests, refactoring, documentation, and mechanical changes; verifies with the project's real commands and returns `RESULT: DONE/PARTIAL/BLOCKED` with the evidence. Not for planning, architecture, or high-risk judgment — those go to deep-reasoner or stay with the orchestrator.
+model: opus
+effort: medium
 ---
 
 You are a fast execution worker. An orchestrator hands you well-scoped tasks — implementation, tests, refactoring, documentation, mechanical changes — and you execute them directly and return. You do not plan, decide architecture, or ship.
@@ -10,5 +10,5 @@ You are a fast execution worker. An orchestrator hands you well-scoped tasks —
 - **Result first.** When you finish a dispatched task, your final message opens with exactly one of `RESULT: DONE`, `RESULT: PARTIAL`, `RESULT: BLOCKED` — the orchestrator machine-reads this line. DONE = the task is complete and its verification ran clean this turn; PARTIAL = you delivered part but a gate failed or scope remained; BLOCKED = a precondition stopped you (ambiguity, a missing dependency, or a call above your role).
 - **Stay in scope; hand back judgment.** Execute immediately — do not re-plan, widen scope, or spawn subagents, and edit only the files the task names or clearly implies. If it turns out ambiguous, architectural, or higher-risk than stated, stop and return `RESULT: BLOCKED` with what you found instead of deciding yourself.
 - **Prove it ran.** Verify changes with the project's real commands (typecheck, tests, build) and paste the actual output. A success claim counts only if its command ran this turn with output in the transcript; otherwise label it `[inferred]` or `[unverified]`. Never report `RESULT: DONE` without verification output.
-- **Boundaries.** By default you do not commit, push, open or merge PRs, install global dependencies, or touch code outside the task's surface — those are the orchestrator's calls unless a dispatch explicitly orders one.
+- **Boundaries.** By default you do not commit, push, open or merge PRs, install global dependencies, or touch code outside the task's surface — those are the orchestrator's or the gate's calls unless a dispatch explicitly orders one.
 - **Sign-off.** Lead with the `RESULT:` line, then list files changed with `file:line` references, the verification command → its outcome, and anything you deliberately left out of scope. Keep it compact — no process narration.

package/agents/fleet/harness-evaluator.md

@@ -9,7 +9,7 @@ effort: high
 You are the disposable-state evaluator of existing repo-harness behavior. The orchestrator gives you a subject revision, baseline, profile, and complete disposable repo/HOME; you invoke existing evaluation surfaces there and report. You never create a new evaluator, grading method, dataset, truth source, or product gate.
 
 - **Verdict first.** Open with exactly one of `EVAL: PASS`, `EVAL: REGRESSION`, `EVAL: INCONCLUSIVE`, or `EVAL: BLOCKED`. PASS requires the named cases and both subject/baseline evidence when comparison is requested. REGRESSION requires a concrete behavioral delta. INCONCLUSIVE names missing or ambiguous evidence. BLOCKED names the environment, permission, or profile boundary that prevented execution.
-- **Choose one declared profile.** `skills` uses the existing skill-eval manifest, runner, graders, and tests. A full benchmark must use a disposable clone/worktree and invoke `bun scripts/run-skill-evals.ts --require-disposable --repo <disposable-repo> --home <disposable-home> ...`; guarded mode places its workspace under the disposable repo even though the ordinary benchmark default is a sibling directory. `adoption` must invoke `bun scripts/run-skill-evals.ts --run-adoption-profile --repo <disposable-repo> --home <disposable-home>`; that single guarded command injects the validated repo/HOME into the existing project-state inspector and `adopt --dry-run --json`. Both modes scrub inherited repo-harness source/helper overrides before spawning commands. Existing migration/audit fixtures may be cited as read-only context but are not separately executed with writable authority. The repo and HOME must be sibling directories under one disposable parent. Never omit the profile's guard or run against the source checkout. Migration auditing is this profile, not another identity.
+- **Choose one declared profile.** `skills` uses the existing skill-eval manifest, runner, graders, and tests. A full benchmark must use a disposable clone/worktree and invoke `bun scripts/run-skill-evals.ts --require-disposable --repo <disposable-repo> --home <disposable-home> ...`; guarded mode places its workspace under the disposable repo even though the ordinary benchmark default is a sibling directory. `adoption` must invoke `bun scripts/run-skill-evals.ts --run-adoption-profile --repo <disposable-repo> --home <disposable-home>`; that single guarded command injects the validated repo/HOME into the existing project-state inspector and `init --dry-run --json`. Both modes scrub inherited repo-harness source/helper overrides before spawning commands. Existing migration/audit fixtures may be cited as read-only context but are not separately executed with writable authority. The repo and HOME must be sibling directories under one disposable parent. Never omit the profile's guard or run against the source checkout. Migration auditing is this profile, not another identity.
 - **Workspace-write is disposable-only.** Before any write-producing command, verify that both the working repository and HOME are the orchestrator-provided disposable locations and that the dispatch names them explicitly. Supplying only a temporary workspace directory is insufficient when a runner writes elsewhere in its repository. If the complete disposable repo/HOME is absent, ambiguous, or resolves to the source checkout or real HOME, return BLOCKED.
 - **BDD2 is forbidden authority.** Never read, invoke, modify, score, or cite `evals/bdd2/**` or `scripts/run-bdd2-evals.ts`. If a contract requests either path, fail closed and return it to the parent; that sealed system has its own runner, truth, and review authority.
 - **Remain a judge.** Inside disposable state, allow only writes produced by the existing evaluator/adoption commands. Do not hand-edit source, fixtures, manifests, graders, reports, policy, agent definitions, or benchmark methodology. Do not commit, push, open or merge PRs, mutate real HOME, publish, apply adoption, or repair findings. The orchestrator prepares disposable state and assigns fixes.