repo-harness 0.9.2 → 0.10.0

package/AGENTS.md

@@ -17,7 +17,7 @@ This repository self-hosts the `repo-harness` contract; the former `repo-harness
 - `.ai/harness/policy.json` for the machine-readable workflow contract
 - `.ai/context/context-map.json` for progressive context loading
 - `docs/architecture/index.md` for umbrella architecture status, drift requests, snapshots, and diagram links
-- `docs/reference-configs/agentic-development-flow.md` for gstack/Waza routing rules
+- `docs/reference-configs/agentic-development-flow.md` for parent-agent/Waza routing and P1/P2/P3 rules
 
 ## Operating Rules
 
@@ -25,7 +25,7 @@ This repository self-hosts the `repo-harness` contract; the former `repo-harness
 - Use `tasks/notes/<plan-stem>.notes.md` only for non-obvious slice decisions, deviations, tradeoffs, and open questions; `<plan-stem>` is the active plan filename without `plan-` and `.md` (for example `20260531-0045-governance-workflow`). Do not use notes as durable memory or a task log, and archive/promote them deliberately when the slice closes.
 - Treat hook execution as central-first: trusted repos run `~/.repo-harness/hooks/` (bash shim) or the packaged CLI copy; this self-host repo pins `"hook_source": "repo"` in `.ai/harness/policy.json` so `.ai/hooks/` stays the live development runtime, with `assets/hooks/` as the product source mirrored on install. User-level `~/.claude/settings.json` and `~/.codex/hooks.json` are the host adapters.
 - Keep the umbrella hierarchy explicit: architecture owns stable truth, capability contracts own local agent context, `tasks/workstreams/<domain>/<capability>/` owns durable progress, and `tasks/todos.md` owns only deferred medium/long-term goals with tradeoff and revisit trigger.
-- Treat `.ai/context/capabilities.json` as the source of truth for capability prefixes; `agent-context-blocks.txt` and nested agent files are compatibility inputs only.
+- Treat `.ai/context/capabilities.json` as the source of truth for capability prefixes; `agent-context-blocks.txt` and nested agent files are initialization inputs only, never runtime resolver authority.
 - Keep architecture drift handling split: `architecture-queue.sh` writes architecture requests/events, `workstream-sync.sh` maintains durable capability workstreams, and `context-contract-sync.sh` only updates controlled local `CLAUDE.md`/`AGENTS.md` architecture blocks.
 - Keep `assets/workflow-contract.v1.json` and `.ai/harness/workflow-contract.json` in sync.
 - Keep `CLAUDE.md` and `AGENTS.md` short; put detailed guidance in `docs/reference-configs/`.
@@ -33,22 +33,29 @@ This repository self-hosts the `repo-harness` contract; the former `repo-harness
 - Treat `.ai/harness/checks/*.latest.{json,md}` and `.ai/harness/runs/` as ignored runtime evidence cache; commit durable conclusions in `tasks/reviews/`, `tasks/contracts/`, `tasks/notes/`, or `docs/researches/` instead.
 - Treat architecture/spec/research docs as the human reading entrypoint. Before closing a workflow, promote durable conclusions into `docs/architecture/`, `docs/researches/`, `docs/spec.md`, or `tasks/lessons.md`; then archive fulfilled plan/contract/review/notes/todo artifacts so root workflow surfaces represent active work only. `.rgignore` hides archived workflow artifacts and runtime evidence from default `rg` searches; use explicit paths or `rg -uu` for audits.
 - Treat `_ref/` as an occasional ignored external reference checkout cache, not a commit surface or daily workflow. Agents may read or refresh it for comparison; when it influences a decision, cite the source repo plus commit/tag and path in `tasks/notes/` or `docs/researches/`.
-- Treat `deploy/` as the trackable deployment and operations surface for runbooks, submission materials, release checklists, helper scripts, ordered SQL files under `deploy/sql/`, and env examples.
+- Treat `deploy/` as the trackable deployment and operations surface for runbooks, submission materials, release checklists, helper scripts, ordered SQL files, and env examples; follow `.ai/harness/policy.json#operations.deploy_sql` for configured SQL roots and naming modes, otherwise keep SQL directly under `deploy/sql/` with 4-digit ascending prefixes.
 - Treat `_ops/` as ignored local operations state for secrets, real env files, provider state, artifacts, logs, and scratch files; do not commit or agent-edit `_ops/*`.
 - Treat contract-level task execution as worktree-first: `repo-harness run plan-to-todo --plan <approved-plan>` starts `repo-harness run contract-worktree start --plan <approved-plan>` when policy enables it, and completed blocks finish through Waza `/check` plus `repo-harness run contract-worktree finish`.
 - Treat the EXECUTION_BOUNDARY anti-extras clause as mandatory on every delegated runner surface (contract worker prompts, the Codex delegation advisor hook, subagent start context, and MCP `codex-goal` documents): absent requirements are forbidden design space, not permission to improve, and unrequested extras fail closed.
 - After Codex Plan mode, Waza `/think`, or `repo-harness-plan` produces a decision-complete work-package plan, capture it with `repo-harness run capture-plan --artifact-level work-package --slug <slug> --title <title>` so `plans/` becomes the file-backed source of truth; if the user has already approved implementation, capture with `--status Approved --execute --promotion-reason <merge_boundary|rollback_boundary|verification_boundary|risk_boundary|human_decision_boundary|worktree_boundary>` or run `repo-harness run plan-to-todo --plan <active-plan>`.
 - Promote work into a top-level `plans/plan-*.md` only when `Artifact Level: work-package` is justified by a merge/PR unit, rollback surface, independent verification boundary, review/acceptance boundary, high-risk surface, or otherwise cannot remain a checklist item in the current active plan or sprint backlog. Inline sprint rows and checklist rows stay in the sprint backlog or active plan `## Task Breakdown`; contract rows may expand into plan -> contract -> review -> notes only through the work-package gate.
 - If current repo state conflicts with the task, open an isolated `codex/<task-slug>` worktree, finish there, run Waza `/check`-style validation, then merge back to `main` without absorbing unrelated dirty changes.
-- Route product discovery to gstack `office-hours`, complex engineering plans to gstack `plan-eng-review`, design plans to gstack `plan-design-review`, and daily small/medium planning, bug hunts, and checks to Waza `/think`, `/hunt`, and `/check`.
+- Route product discovery and complex/design planning to the parent agent: use `geju` for pre-contract framing, complete P1/P2/P3 with the parent agent's own capabilities, and freeze the accepted direction into the plan and contract. Route daily small/medium planning, bug hunts, and checks to Waza `/think`, `/hunt`, and `/check`. Route a proactive multi-direction visual/UX choice mid-task to the design-options convention (`repo-harness docs show design-options`).
 - Codex automation profile is runtime-referenced, not vendored: required skills are `health`, `check`, and `diagram-design` from `~/.codex/skills`.
-- Route knowledge sync and handoff retrieval to `gbrain`.
-- Register valuable repo-authored docs in `.ai/harness/brain-manifest.json` with `sync.direction=repo-to-brain`; `scripts/sync-brain-docs.sh` and the PostEdit hook mirror only those explicit entries into the default brain vault.
+- Keep durable repo knowledge in `docs/researches/`, `tasks/lessons.md`, and the canonical workflow artifacts.
+- 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 `scripts/migrate-project-template.sh` or `scripts/lib/project-init-lib.sh`, verify self-migration of this repo still works.
+- When changing adoption planner or transaction code, verify `repo-harness adopt --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
+
+- Reason from first principles: identify observable conditions, controllable inputs, the invariant, and the actual pressure point before changing structure.
+- Keep one source of truth for each datum; every other representation must be a deterministic projection with a drift check.
+- Do not add steady-state compatibility code, dual authority, semantic fallbacks, aliases, or shadow parsers. Explicit one-shot migrations must fail closed and remove the retired path in the same work-package.
+- Create shared components only for observed reuse or a cross-module invariant. Prefer an existing monorepo workspace only when independently meaningful consumers need the shared package; do not convert this single-package repo without that boundary.
+
 ## Required Checks
 
 ```bash
@@ -58,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
-bash scripts/migrate-project-template.sh --repo . --dry-run
+bun src/cli/index.ts adopt --repo . --dry-run
 ```
 
 <!-- BEGIN ARCHITECTURE CONTRACT -->

package/CLAUDE.md

@@ -17,7 +17,7 @@ This repository self-hosts the `repo-harness` contract; the former `repo-harness
 - `.ai/harness/policy.json` for the machine-readable workflow contract
 - `.ai/context/context-map.json` for progressive context loading
 - `docs/architecture/index.md` for umbrella architecture status, drift requests, snapshots, and diagram links
-- `docs/reference-configs/agentic-development-flow.md` for gstack/Waza routing rules
+- `docs/reference-configs/agentic-development-flow.md` for parent-agent/Waza routing and P1/P2/P3 rules
 
 ## Operating Rules
 
@@ -25,7 +25,7 @@ This repository self-hosts the `repo-harness` contract; the former `repo-harness
 - Use `tasks/notes/<plan-stem>.notes.md` only for non-obvious slice decisions, deviations, tradeoffs, and open questions; `<plan-stem>` is the active plan filename without `plan-` and `.md` (for example `20260531-0045-governance-workflow`). Do not use notes as durable memory or a task log, and archive/promote them deliberately when the slice closes.
 - Treat hook execution as central-first: trusted repos run `~/.repo-harness/hooks/` (bash shim) or the packaged CLI copy; this self-host repo pins `"hook_source": "repo"` in `.ai/harness/policy.json` so `.ai/hooks/` stays the live development runtime, with `assets/hooks/` as the product source mirrored on install. User-level `~/.claude/settings.json` and `~/.codex/hooks.json` are the host adapters.
 - Keep the umbrella hierarchy explicit: architecture owns stable truth, capability contracts own local agent context, `tasks/workstreams/<domain>/<capability>/` owns durable progress, and `tasks/todos.md` owns only deferred medium/long-term goals with tradeoff and revisit trigger.
-- Treat `.ai/context/capabilities.json` as the source of truth for capability prefixes; `agent-context-blocks.txt` and nested agent files are compatibility inputs only.
+- Treat `.ai/context/capabilities.json` as the source of truth for capability prefixes; `agent-context-blocks.txt` and nested agent files are initialization inputs only, never runtime resolver authority.
 - Keep architecture drift handling split: `architecture-queue.sh` writes architecture requests/events, `workstream-sync.sh` maintains durable capability workstreams, and `context-contract-sync.sh` only updates controlled local `CLAUDE.md`/`AGENTS.md` architecture blocks.
 - Keep `assets/workflow-contract.v1.json` and `.ai/harness/workflow-contract.json` in sync.
 - Keep `CLAUDE.md` and `AGENTS.md` short; put detailed guidance in `docs/reference-configs/`.
@@ -33,22 +33,29 @@ This repository self-hosts the `repo-harness` contract; the former `repo-harness
 - Treat `.ai/harness/checks/*.latest.{json,md}` and `.ai/harness/runs/` as ignored runtime evidence cache; commit durable conclusions in `tasks/reviews/`, `tasks/contracts/`, `tasks/notes/`, or `docs/researches/` instead.
 - Treat architecture/spec/research docs as the human reading entrypoint. Before closing a workflow, promote durable conclusions into `docs/architecture/`, `docs/researches/`, `docs/spec.md`, or `tasks/lessons.md`; then archive fulfilled plan/contract/review/notes/todo artifacts so root workflow surfaces represent active work only. `.rgignore` hides archived workflow artifacts and runtime evidence from default `rg` searches; use explicit paths or `rg -uu` for audits.
 - Treat `_ref/` as an occasional ignored external reference checkout cache, not a commit surface or daily workflow. Agents may read or refresh it for comparison; when it influences a decision, cite the source repo plus commit/tag and path in `tasks/notes/` or `docs/researches/`.
-- Treat `deploy/` as the trackable deployment and operations surface for runbooks, submission materials, release checklists, helper scripts, ordered SQL files under `deploy/sql/`, and env examples.
+- Treat `deploy/` as the trackable deployment and operations surface for runbooks, submission materials, release checklists, helper scripts, ordered SQL files, and env examples; follow `.ai/harness/policy.json#operations.deploy_sql` for configured SQL roots and naming modes, otherwise keep SQL directly under `deploy/sql/` with 4-digit ascending prefixes.
 - Treat `_ops/` as ignored local operations state for secrets, real env files, provider state, artifacts, logs, and scratch files; do not commit or agent-edit `_ops/*`.
 - Treat contract-level task execution as worktree-first: `repo-harness run plan-to-todo --plan <approved-plan>` starts `repo-harness run contract-worktree start --plan <approved-plan>` when policy enables it, and completed blocks finish through Waza `/check` plus `repo-harness run contract-worktree finish`.
 - Treat the EXECUTION_BOUNDARY anti-extras clause as mandatory on every delegated runner surface (contract worker prompts, the Codex delegation advisor hook, subagent start context, and MCP `codex-goal` documents): absent requirements are forbidden design space, not permission to improve, and unrequested extras fail closed.
 - After Codex Plan mode, Waza `/think`, or `repo-harness-plan` produces a decision-complete work-package plan, capture it with `repo-harness run capture-plan --artifact-level work-package --slug <slug> --title <title>` so `plans/` becomes the file-backed source of truth; if the user has already approved implementation, capture with `--status Approved --execute --promotion-reason <merge_boundary|rollback_boundary|verification_boundary|risk_boundary|human_decision_boundary|worktree_boundary>` or run `repo-harness run plan-to-todo --plan <active-plan>`.
 - Promote work into a top-level `plans/plan-*.md` only when `Artifact Level: work-package` is justified by a merge/PR unit, rollback surface, independent verification boundary, review/acceptance boundary, high-risk surface, or otherwise cannot remain a checklist item in the current active plan or sprint backlog. Inline sprint rows and checklist rows stay in the sprint backlog or active plan `## Task Breakdown`; contract rows may expand into plan -> contract -> review -> notes only through the work-package gate.
 - If current repo state conflicts with the task, open an isolated `codex/<task-slug>` worktree, finish there, run Waza `/check`-style validation, then merge back to `main` without absorbing unrelated dirty changes.
-- Route product discovery to gstack `office-hours`, complex engineering plans to gstack `plan-eng-review`, design plans to gstack `plan-design-review`, and daily small/medium planning, bug hunts, and checks to Waza `/think`, `/hunt`, and `/check`.
+- Route product discovery and complex/design planning to the parent agent: use `geju` for pre-contract framing, complete P1/P2/P3 with the parent agent's own capabilities, and freeze the accepted direction into the plan and contract. Route daily small/medium planning, bug hunts, and checks to Waza `/think`, `/hunt`, and `/check`. Route a proactive multi-direction visual/UX choice mid-task to the design-options convention (`repo-harness docs show design-options`).
 - Codex automation profile is runtime-referenced, not vendored: required skills are `health`, `check`, and `diagram-design` from `~/.codex/skills`.
-- Route knowledge sync and handoff retrieval to `gbrain`.
-- Register valuable repo-authored docs in `.ai/harness/brain-manifest.json` with `sync.direction=repo-to-brain`; `scripts/sync-brain-docs.sh` and the PostEdit hook mirror only those explicit entries into the default brain vault.
+- Keep durable repo knowledge in `docs/researches/`, `tasks/lessons.md`, and the canonical workflow artifacts.
+- 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 `scripts/migrate-project-template.sh` or `scripts/lib/project-init-lib.sh`, verify self-migration of this repo still works.
+- When changing adoption planner or transaction code, verify `repo-harness adopt --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
+
+- Reason from first principles: identify observable conditions, controllable inputs, the invariant, and the actual pressure point before changing structure.
+- Keep one source of truth for each datum; every other representation must be a deterministic projection with a drift check.
+- Do not add steady-state compatibility code, dual authority, semantic fallbacks, aliases, or shadow parsers. Explicit one-shot migrations must fail closed and remove the retired path in the same work-package.
+- Create shared components only for observed reuse or a cross-module invariant. Prefer an existing monorepo workspace only when independently meaningful consumers need the shared package; do not convert this single-package repo without that boundary.
+
 ## Required Checks
 
 ```bash
@@ -58,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
-bash scripts/migrate-project-template.sh --repo . --dry-run
+bun src/cli/index.ts adopt --repo . --dry-run
 ```
 
 <!-- BEGIN ARCHITECTURE CONTRACT -->

package/README.es.md

@@ -85,7 +85,7 @@ artifacts.
 ## Novedades
 
 Las notas de versión viven en [`docs/CHANGELOG.md`](docs/CHANGELOG.md). La línea
-actual es `0.9.2`.
+actual es `0.10.0`.
 
 ## Cómo funciona
 
@@ -172,20 +172,20 @@ flowchart TD
 ## Bucles largos de producto
 
 Para trabajo Greenfield y Brownfield, adelanta la discovery y el juicio de
-engineering plan en Claude-Fable antes de pedirle a Codex que haga loops de
+engineering plan en el parent agent antes de pedirle a Codex que haga loops de
 ejecución:
 
-1. En Claude-Fable, usa gstack `office-hours` para product discovery o
-   `plan-eng-review` para review del plan de ingeniería. La salida debe ser los
-   development documents que fijan la intención de producto, la arquitectura, los
-   riesgos y el evidence contract.
+1. Antes de crear un contract, el parent agent invoca `geju` para abrir el marco y
+   después completa P1/P2/P3 con sus propias capacidades repo/runtime. Fija la
+   intención de producto, la arquitectura, los riesgos, el falsifier y el evidence
+   contract aceptados en los development documents.
 2. Convierte esos documentos en un PRD Sprint bajo `plans/prds/`, con un
    backlog ordenado y sub-plans detallados para cada execution slice.
 3. Crea un Codex Goal que apunte a ese archivo de sprint. repo-harness puede
    entonces proyectar cada sprint item por el flow normal plan -> contract ->
    worktree -> verification.
 
-Ese handoff mantiene precisos los loops largos: Claude-Fable se ocupa del juicio
+Ese handoff mantiene precisos los loops largos: el parent agent se ocupa del juicio
 amplio al inicio, el PRD Sprint es la durable source of truth, y Codex Goal mode
 retoma contra un sprint concreto en vez de reinterpretar el chat original.
 
@@ -200,8 +200,9 @@ recomienda al aplicar el settings merge.
 
 ### Instalar el CLI
 
-La ruta por defecto no requiere Node.js: el instalador usa Bun como runtime. Si
-Bun no existe, instala Bun primero y después instala el CLI `repo-harness`.
+La ruta por defecto no requiere Node.js: el instalador usa Bun >= 1.1.35 como
+runtime. Si Bun no existe o es anterior, lo instala o actualiza antes de
+instalar el CLI `repo-harness`.
 
 ```bash
 # macOS / Linux
@@ -212,7 +213,7 @@ irm https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.ps1 |
 ```
 
 <details>
-<summary>¿Ya tienes Bun? Usa Bun primero, o npx como fallback</summary>
+<summary>¿Ya tienes Bun >= 1.1.35? Usa Bun primero, o npx como fallback</summary>
 
 ```bash
 # Bun (recomendado)
@@ -264,7 +265,7 @@ El comando debería terminar imprimiendo `=== Migration Report ===`, e incluir:
 - `Host hook adapters are user-level:`: recordatorio de instalar los global adapters y de confiar en `~/.codex/hooks.json`
 - `Workflow migration:`: el plan de creación o refresco de las repo-local harness surfaces
 - `Helper runtime:`: la cadena de herramientas operativa que obtendrás tras aplicar
-- `--- External Tooling ---`: el routing de gstack/Waza/gbrain más las advisory de instalación/actualización
+- `--- External Tooling ---`: la guía de planning parent/Geju, la readiness de Waza y CodeGraph y las advisory de instalación/actualización
 
 ### Los dos comandos siguientes
 
@@ -419,8 +420,8 @@ Guards habituales:
 
 ## Release actual
 
-- npm package: `repo-harness@0.9.2`
-- Generated workflow stamp: `repo-harness@0.9.2+template@0.9.2`
+- npm package: `repo-harness@0.10.0`
+- Generated workflow stamp: `repo-harness@0.10.0+template@0.10.0`
 - GitHub repository: `Ancienttwo/repo-harness`
 - Release history: [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -435,10 +436,6 @@ Gracias a [TW93](https://x.com/HiTw93), autor de Waza. Los skills centrales
 `think`, `hunt`, `check` y `health` dan forma al ritmo diario de planning, bug
 hunt y verification de `repo-harness`.
 
-Gracias a [Garry Tan](https://x.com/garrytan), autor de gstack y gbrain. Ambos
-influyeron en el workflow de product discovery, plan/design review, release
-documentation, knowledge sync y handoff retrieval.
-
 Gracias a [Peter Steinberger](https://x.com/steipete), autor de Oracle
 (`@steipete/oracle`, MIT). Es el motor de consult de navegador GPT Pro / ChatGPT
 Web por defecto de `chatgpt-browser`: el provider Oracle ejecuta el binario oracle
@@ -545,7 +542,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
-bash scripts/migrate-project-template.sh --repo . --dry-run
+bun src/cli/index.ts adopt --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```
@@ -582,7 +579,7 @@ bun run benchmark:skills --eval repair-agents-task-sync
 - Scaffolding scripts:
   - `scripts/init-project.sh`
   - `scripts/create-project-dirs.sh`
-- Legacy-doc migrator: `scripts/migrate-workflow-docs.ts`
+- Canonical adoption planner: `src/core/adoption/standard-plan.ts`
 
 ## Generated vs Self-Hosted Hook Projection
 
@@ -620,7 +617,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
-bash scripts/migrate-project-template.sh --repo . --dry-run
+bun src/cli/index.ts adopt --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

@@ -85,7 +85,7 @@ l'emportent.
 ## Nouveautés
 
 Les notes de version vivent dans [`docs/CHANGELOG.md`](docs/CHANGELOG.md). La
-ligne actuelle est `0.9.2`.
+ligne actuelle est `0.10.0`.
 
 ## Comment ça marche
 
@@ -174,20 +174,20 @@ flowchart TD
 ## Longues boucles produit
 
 Pour le travail Greenfield comme Brownfield, avancez la discovery et le jugement
-d'engineering plan dans Claude-Fable avant de demander à Codex de boucler sur
+d'engineering plan dans le parent agent avant de demander à Codex de boucler sur
 l'exécution :
 
-1. Dans Claude-Fable, utilisez gstack `office-hours` pour la product discovery ou
-   `plan-eng-review` pour la review du plan d'ingénierie. La sortie doit être les
-   development documents qui verrouillent l'intention produit, l'architecture,
-   les risques et l'evidence contract.
+1. Avant la création d'un contract, le parent agent invoque `geju` pour ouvrir le
+   cadre, puis réalise P1/P2/P3 avec ses propres capacités repo/runtime. Il fige
+   l'intention produit, l'architecture, les risques, le falsifier et l'evidence
+   contract acceptés dans les development documents.
 2. Transformez ces documents en PRD Sprint sous `plans/prds/`, avec un backlog
    ordonné et des sub-plans détaillés pour chaque execution slice.
 3. Créez un Codex Goal qui pointe vers ce fichier de sprint. repo-harness peut
    ensuite projeter chaque sprint item dans le flow normal plan -> contract ->
    worktree -> verification.
 
-Ce handoff rend les longues boucles plus précises : Claude-Fable porte le
+Ce handoff rend les longues boucles plus précises : le parent agent porte le
 jugement large en amont, le PRD Sprint devient la durable source of truth, et
 Codex Goal mode reprend sur un sprint concret au lieu de réinterpréter le chat
 initial.
@@ -203,9 +203,9 @@ lors de l'application d'un settings merge.
 
 ### 1. Installer le CLI
 
-Le chemin par défaut ne demande pas Node.js : l'installateur utilise Bun comme
-runtime. Si Bun est absent, il installe Bun d'abord, puis installe le CLI
-`repo-harness`.
+Le chemin par défaut ne demande pas Node.js : l'installateur utilise Bun >=
+1.1.35 comme runtime. Si Bun est absent ou plus ancien, il l'installe ou le met
+à niveau avant d'installer le CLI `repo-harness`.
 
 ```bash
 # macOS / Linux
@@ -216,7 +216,7 @@ irm https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.ps1 |
 ```
 
 <details>
-<summary>Vous avez déjà Bun ? Utilisez Bun en priorité, ou npx en fallback</summary>
+<summary>Vous avez déjà Bun >= 1.1.35 ? Utilisez Bun en priorité, ou npx en fallback</summary>
 
 ```bash
 # Bun (recommandé)
@@ -276,7 +276,7 @@ La commande doit se terminer par `=== Migration Report ===` et inclure :
 - `Host hook adapters are user-level:` : rappel d'installer les global adapters, et de faire confiance à `~/.codex/hooks.json`
 - `Workflow migration:` : le plan de création ou de rafraîchissement des repo-local harness surfaces
 - `Helper runtime:` : la chaîne d'outils opérationnels obtenue après application
-- `--- External Tooling ---` : le routing gstack/Waza/gbrain ainsi que les conseils d'installation/mise à jour advisory
+- `--- External Tooling ---` : le guide de planning parent/Geju, la readiness Waza et CodeGraph et les conseils d'installation/mise à jour advisory
 
 Si la sortie du dry-run est incorrecte, arrêtez-vous ici et lisez
 [`docs/reference-configs/hook-operations.md`](docs/reference-configs/hook-operations.md).
@@ -424,8 +424,8 @@ Guards courants :
 
 ## Release actuelle
 
-- npm package : `repo-harness@0.9.2`
-- Generated workflow stamp : `repo-harness@0.9.2+template@0.9.2`
+- npm package : `repo-harness@0.10.0`
+- Generated workflow stamp : `repo-harness@0.10.0+template@0.10.0`
 - GitHub repository : `Ancienttwo/repo-harness`
 - Release history : [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -440,10 +440,6 @@ Merci à [TW93](https://x.com/HiTw93), auteur de Waza. Les skills centraux
 `think`, `hunt`, `check` et `health` structurent le rythme quotidien de planning,
 bug hunt et verification de `repo-harness`.
 
-Merci à [Garry Tan](https://x.com/garrytan), auteur de gstack et gbrain. Ils ont
-influencé le workflow de product discovery, plan/design review, release
-documentation, knowledge sync et handoff retrieval.
-
 Merci à [Peter Steinberger](https://x.com/steipete), auteur d'Oracle
 (`@steipete/oracle`, MIT). C'est le moteur de consult navigateur GPT Pro /
 ChatGPT Web par défaut de `chatgpt-browser` : le provider Oracle lance le binaire
@@ -551,7 +547,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
-bash scripts/migrate-project-template.sh --repo . --dry-run
+bun src/cli/index.ts adopt --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```
@@ -588,7 +584,7 @@ bun run benchmark:skills --eval repair-agents-task-sync
 - Scaffolding scripts:
   - `scripts/init-project.sh`
   - `scripts/create-project-dirs.sh`
-- Legacy-doc migrator : `scripts/migrate-workflow-docs.ts`
+- Canonical adoption planner: `src/core/adoption/standard-plan.ts`
 
 ## Generated vs Self-Hosted Hook Projection
 
@@ -626,7 +622,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
-bash scripts/migrate-project-template.sh --repo . --dry-run
+bun src/cli/index.ts adopt --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

@@ -75,7 +75,7 @@ review、checks、handoff と食い違う場合は、source artifacts を優先
 ## What's New
 
 リリースノートは [`docs/CHANGELOG.md`](docs/CHANGELOG.md) にあります。現在の
-ラインは `0.9.2` です。
+ラインは `0.10.0` です。
 
 ## 仕組み
 
@@ -156,19 +156,19 @@ flowchart TD
 ## 長期プロダクト Loop
 
 Greenfield と Brownfield の作業では、Codex に実行 loop を任せる前に、
-discovery と engineering-plan judgment を Claude-Fable 側で前倒しします。
+discovery と engineering-plan judgment を parent agent 側で前倒しします。
 
-1. Claude-Fable で、product discovery には gstack `office-hours` を使い、
-   engineering plan review には `plan-eng-review` を使います。出力は、product
-   intent、architecture、risks、evidence contract を固定する development
-   documents にします。
+1. contract を作る前に parent agent が `geju` で視野を広げ、その後、自身の
+   repo/runtime 能力で P1/P2/P3 を完了します。合意した product intent、
+   architecture、risks、falsifier、evidence contract を development documents
+   に固定します。
 2. それらの documents を `plans/prds/` 配下の PRD Sprint に変換し、
    各 execution slice に ordered backlog と detailed sub-plans を持たせます。
 3. Codex Goal を作成し、その sprint file を指します。repo-harness はその後、
    各 sprint item を通常の plan -> contract -> worktree -> verification flow
    へ投射できます。
 
-この handoff により、長期 loop は精密になります。Claude-Fable が広い前置判断を担い、
+この handoff により、長期 loop は精密になります。parent agent が広い前置判断を担い、
 PRD Sprint が durable source of truth となり、Codex Goal mode は元の chat を再解釈する
 のではなく、具体的な sprint に対して resume します。
 
@@ -181,8 +181,8 @@ PRD Sprint が durable source of truth となり、Codex Goal mode は元の cha
 
 ### CLI をインストールする
 
-既定の経路では Node.js は不要です。installer は Bun を runtime として使います。
-Bun が見つからない場合は、先に Bun をインストールしてから `repo-harness` CLI をインストールします。
+既定の経路では Node.js は不要です。installer は Bun >= 1.1.35 を runtime として使います。
+Bun が見つからない場合や古い場合は、先に Bun をインストールまたは更新してから `repo-harness` CLI をインストールします。
 
 ```bash
 # macOS / Linux
@@ -193,7 +193,7 @@ irm https://raw.githubusercontent.com/Ancienttwo/repo-harness/main/install.ps1 |
 ```
 
 <details>
-<summary>Bun がすでにある場合は Bun を優先し、npx を fallback として使えます</summary>
+<summary>Bun >= 1.1.35 がすでにある場合は Bun を優先し、npx を fallback として使えます</summary>
 
 ```bash
 # Bun（推奨）
@@ -246,7 +246,7 @@ repo-harness adopt
 - `Host hook adapters are user-level:`：global adapters のインストールを促し、`~/.codex/hooks.json` を信頼するよう注意する
 - `Workflow migration:`：repo-local harness surfaces の作成またはリフレッシュ計画
 - `Helper runtime:`：適用後に得られる操作ツールチェーン
-- `--- External Tooling ---`：gstack/Waza/gbrain の route と advisory なインストール/更新のヒント
+- `--- External Tooling ---`：parent/Geju planning の指針、Waza と CodeGraph の readiness、advisory なインストール/更新のヒント
 
 ### 続けて実行する 2 つのコマンド
 
@@ -398,8 +398,8 @@ hook がブロックしたときは、まず terminal の構造化された出
 
 ## 現在の Release
 
-- npm package：`repo-harness@0.9.2`
-- Generated workflow stamp：`repo-harness@0.9.2+template@0.9.2`
+- npm package：`repo-harness@0.10.0`
+- Generated workflow stamp：`repo-harness@0.10.0+template@0.10.0`
 - GitHub repository：`Ancienttwo/repo-harness`
 - Release history：[`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 
@@ -413,10 +413,6 @@ decision rationale を重視する Geju の実践は、彼の貢献と示唆に
 `check`、`health` という中核 skill は、`repo-harness` の日々の planning、
 bug hunt、verification のリズムを形作っています。
 
-[Garry Tan](https://x.com/garrytan) による gstack と gbrain にも感謝します。
-これらは product discovery、plan/design review、release documentation、
-knowledge sync、handoff retrieval の workflow 設計に影響を与えています。
-
 [Peter Steinberger](https://x.com/steipete) による Oracle（`@steipete/oracle`、MIT）にも
 感謝します。これは `chatgpt-browser` の既定の GPT Pro / ChatGPT Web ブラウザ consult
 エンジンで、Oracle provider が外部の oracle バイナリを spawn して `gptpro` consult を
@@ -519,7 +515,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
-bash scripts/migrate-project-template.sh --repo . --dry-run
+bun src/cli/index.ts adopt --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```
@@ -556,7 +552,7 @@ bun run benchmark:skills --eval repair-agents-task-sync
 - Scaffolding scripts:
   - `scripts/init-project.sh`
   - `scripts/create-project-dirs.sh`
-- Legacy-doc migrator：`scripts/migrate-workflow-docs.ts`
+- Canonical adoption planner: `src/core/adoption/standard-plan.ts`
 
 ## Generated vs Self-Hosted Hook Projection
 
@@ -594,7 +590,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
-bash scripts/migrate-project-template.sh --repo . --dry-run
+bun src/cli/index.ts adopt --repo . --dry-run
 bash scripts/check-agent-tooling.sh --host both --check-updates
 bun run benchmark:skills --eval route-workflow-check
 ```