repo-harness 0.21.2 → 0.22.1

package/AGENTS.md

@@ -13,6 +13,7 @@
 - `start` recovers only a real target directory registered by this clone on the expected branch, under the topology lock, with no lock or other owner. Recovery requires a current-user-owned checkout directory without group or other write access, a regular owned Git pointer, its matching admin backpointer, and the original directory identity saved by start. Git metadata can be group-writable but must not be other-writable. Start still creates a checkout when uid is unavailable; recovery then refuses. Exact removal retires the identity after Git readback. Missing identity or a replacement directory blocks recovery. Files, symlinks, unregistered paths and other branches are refused. Cleanup refuses a registered worktree whose branch is missing. MCP cleanup also refuses active markers and retained native verification evidence. Sweep reports name processed paths. Deferred entries are reported as counts. `kept` excludes deferred entries. A command timeout sends SIGTERM to the direct child only. A grandchild can briefly extend the deadline. No detached cleanup process starts. Herdr notifications accept registered default task worktrees and paths inside them. Other temporary paths and `rh-herdr-` labels stay filtered.
 - Automatically delete only merged, clean worktrees/branches; ask the user for every other deletion. Credentials/permissions (including confirmation bypass) and release/production operations require user approval.
 - Use gatekeeper/cross-model review for large changes, security/permissions, or unresolved model uncertainty; ordinary steps record diagnostics without approval loops.
+- When you delegate, investigate first, then split work by write ownership. Give each parallel writer its own worktree from a clean source. Implementation sub-agents edit only their scope. They do not run build, typecheck or tests. They commit early in their own worktree and return early. In a shared checkout they do not commit; the parent commits. Evidence roles run the named check that is their task and do not commit. The parent agent owns task management, conflict resolution, build, typecheck, tests and integration. After integration, the parent removes each sub-agent worktree and branch whose commits are in the task branch and whose checkout is clean. It also removes the intermediate build output and temporary files that the work created. Other deletion still needs the user.
 - Model division and cross-model dispatch/review follow [Herdr Dispatch](docs/reference-configs/external-tooling.md#herdr-dispatch).
 - GitHub operations (PRs, reviews, merges, labels, releases, comments) go only through the gh/git CLI or the GitHub API. Never use simulated browser clicks on github.com: the account can be banned.
 - When one PR changes both test assertions and implementation code, run one read-only review focused on tests bent to fit a bug (on-demand, not a restored gate; dispatch per the herdr guide).

package/CLAUDE.md

@@ -13,6 +13,7 @@
 - `start` recovers only a real target directory registered by this clone on the expected branch, under the topology lock, with no lock or other owner. Recovery requires a current-user-owned checkout directory without group or other write access, a regular owned Git pointer, its matching admin backpointer, and the original directory identity saved by start. Git metadata can be group-writable but must not be other-writable. Start still creates a checkout when uid is unavailable; recovery then refuses. Exact removal retires the identity after Git readback. Missing identity or a replacement directory blocks recovery. Files, symlinks, unregistered paths and other branches are refused. Cleanup refuses a registered worktree whose branch is missing. MCP cleanup also refuses active markers and retained native verification evidence. Sweep reports name processed paths. Deferred entries are reported as counts. `kept` excludes deferred entries. A command timeout sends SIGTERM to the direct child only. A grandchild can briefly extend the deadline. No detached cleanup process starts. Herdr notifications accept registered default task worktrees and paths inside them. Other temporary paths and `rh-herdr-` labels stay filtered.
 - Automatically delete only merged, clean worktrees/branches; ask the user for every other deletion. Credentials/permissions (including confirmation bypass) and release/production operations require user approval.
 - Use gatekeeper/cross-model review for large changes, security/permissions, or unresolved model uncertainty; ordinary steps record diagnostics without approval loops.
+- When you delegate, investigate first, then split work by write ownership. Give each parallel writer its own worktree from a clean source. Implementation sub-agents edit only their scope. They do not run build, typecheck or tests. They commit early in their own worktree and return early. In a shared checkout they do not commit; the parent commits. Evidence roles run the named check that is their task and do not commit. The parent agent owns task management, conflict resolution, build, typecheck, tests and integration. After integration, the parent removes each sub-agent worktree and branch whose commits are in the task branch and whose checkout is clean. It also removes the intermediate build output and temporary files that the work created. Other deletion still needs the user.
 - Model division and cross-model dispatch/review follow [Herdr Dispatch](docs/reference-configs/external-tooling.md#herdr-dispatch).
 - GitHub operations (PRs, reviews, merges, labels, releases, comments) go only through the gh/git CLI or the GitHub API. Never use simulated browser clicks on github.com: the account can be banned.
 - When one PR changes both test assertions and implementation code, run one read-only review focused on tests bent to fit a bug (on-demand, not a restored gate; dispatch per the herdr guide).

package/README.es.md

@@ -22,10 +22,10 @@ proyecto, de modo que la siguiente sesión de agente continúa desde archivos en
 lugar del historial de chat. Adopta un repositorio existente con un contract
 de agente tasks-first que mantiene alineados a Claude y Codex.
 
-Sobre ese contract ejecuta **programas autorizados**: trabajo de larga duración
-que sostiene su propia autorización, presupuesto, task offers y leases, de modo
-que un Sprint puede avanzar a través de sesiones sin que un humano conduzca
-cada paso.
+Sobre ese contract, el Bot planifica **programas de larga duración**: los task
+offers y los leases permiten que un Sprint avance a través de sesiones.
+repo-harness aporta las herramientas y la evidencia; el Bot decide qué se
+ejecuta a continuación.
 
 ## Índice
 
@@ -172,10 +172,9 @@ repo-harness mcp uninstall --services-stopped # after stopping all MCP HTTP serv
   decisión humana cabe en una sola pantalla — verdict, archivos previstos vs
   reales, comandos que pasaron, riesgo residual, rollback — en lugar de una
   reconstrucción de lo que el agente afirma haber hecho.
-- **El trabajo desatendido sigue siendo responsable.** Un programa no puede
-  arrancar sin una autorización almacenada, no puede exceder su budget ledger,
-  no puede retener una tarea más allá de su lease, y no puede reclamar
-  aceptación sin un receipt. La autonomía está acotada por artefactos, no por
+- **El trabajo planificado sigue siendo responsable.** Una tarea no puede
+  retenerse más allá de su lease. Tampoco puede reclamar aceptación sin un
+  receipt. El Bot planifica a partir de evidencia registrada, no de la
   confianza.
 
 En un repositorio adoptado, la superficie se mantiene intencionalmente
@@ -199,21 +198,20 @@ completo para un repositorio en solitario, y todo lo que está en
 [Flujo de trabajo de tareas](#flujo-de-trabajo-de-tareas) pertenece aquí. Nada
 de lo que sigue es necesario para usarlo.
 
-**Capa 2 — programas autorizados.** Trabajo de larga duración que sobrevive a
-una sesión: un controller desatendido que avanza un Sprint, un programa de refactor guiado
-por el modelo de arquitectura, un plano de colaboración donde varios Module
-Engineers intercambian señales y handoffs. Cada programa está condicionado a
-una autorización emitida por un operador, consume de un budget ledger por goal,
-y retiene el trabajo mediante leases renovables. Ver
+**Capa 2 — programas planificados por el Bot.** Trabajo de larga duración que
+sobrevive a una sesión: un plano de colaboración donde varios Module Engineers
+intercambian señales y handoffs, y task offers de engineer retenidos mediante
+leases renovables. El Bot decide qué planificar. repo-harness aporta las
+herramientas y la evidencia. Ver
 [Programas autorizados](#programas-autorizados).
 
 | | Capa 1 | Capa 2 |
 | --- | --- | --- |
-| Unidad de trabajo | Un task contract | Un programa autorizado |
-| Quién lo conduce | Un humano en una sesión | Un controller, bajo topes |
-| Autoridad | Plan, contract, review, checks | Lo anterior, más authorization, budget, lease, receipts |
-| Punto de entrada | `repo-harness init` | `repo-harness automation grant mint` |
-| Condición de parada | Closeout de la tarea | Budget agotado, lease perdido, o un receipt terminal |
+| Unidad de trabajo | Un task contract | Una engineer task planificada |
+| Quién lo conduce | Un humano en una sesión | El Bot, a través del CLI de repo-harness y Herdr |
+| Autoridad | Plan, contract, review, checks | Lo anterior, más engineer binding y lease |
+| Punto de entrada | `repo-harness init` | `repo-harness engineer acquire-next` |
+| Condición de parada | Closeout de la tarea | Closeout de la tarea o lease perdido |
 
 La capa 2 no reemplaza a la capa 1: cada paso de un programa sigue
 proyectándose en los mismos artefactos de plan, contract y review que habría
@@ -226,8 +224,7 @@ escrito un humano.
 | **Sesiones respaldadas por archivos** | Plans, contracts, checks y handoffs viven en el repositorio, de modo que una sesión nueva retoma desde artefactos en vez de un hilo de chat |
 | **Typed hook runtime** | Ocho managed routes compartidas, más tres delegation routes exclusivas de Codex, cada una atada a exactamente un typed handler in-process, con guards fail-closed en el límite de edición |
 | **Plan → Contract → Review** | Un solo ciclo de vida desde el plan aprobado hasta el contract proyectado, el worktree aislado, la evidencia estructurada y un closeout revisable |
-| **Programas autorizados** | Programas de refactor, automation y collaboration que sostienen su propia authorization, budget ledger, task offers y leases renovables |
-| **Controller desatendido acotado** | Un bucle de dispatch de Engineer bajo topes duros de pasos, duración y reintentos, que reserva budget antes de cada intento |
+| **Programas planificados por el Bot** | Programas de collaboration con task offers de engineer y leases renovables; el Bot planifica, repo-harness aporta herramientas y evidencia |
 | **Carga de contexto progresiva** | Un root context estable de ~12KB más capability contracts de ~1KB que solo se cargan para los archivos que realmente se están tocando |
 | **Integración con CodeGraph** | Consultas estructurales (callers, callees, definitions) respondidas desde un índice pre-construido en vez de pasadas repetidas de grep-and-read |
 | **MCP planner sidecar** | ChatGPT lee el estado real del repositorio y escribe artefactos de PRD/Sprint/Goal; Codex los ejecuta, sin acceso de escritura al código fuente por defecto |
@@ -306,9 +303,9 @@ flowchart TD
   PreHooks -->|blocked| ScopeFix["Fix plan, contract, worktree, or scope"]
   ScopeFix --> Implement
   PreHooks -->|allowed| Changes["Code, docs, tests, or config changes"]
-  Changes --> PostHooks["Post-edit and post-bash hooks<br/>trace, drift request, handoff, check evidence"]
-  PostHooks --> ArchQueue["Architecture queue<br/>architecture-queue.sh record/reindex<br/>check-architecture-sync.sh"]
-  ArchQueue --> Verify["Run verification<br/>tests plus repo workflow checks"]
+  Changes --> PostHooks["Post-edit and post-bash hooks<br/>trace, handoff, check evidence"]
+  PostHooks --> ArchUpdate["Explicit architecture update<br/>archctx ChangeSet when responsibilities change<br/>architecture-projection apply"]
+  ArchUpdate --> Verify["Run verification<br/>tests plus repo workflow checks"]
 
   Verify --> Checks["Structured evidence<br/>.ai/harness/evidence/events/log.jsonl<br/>.ai/harness/runs/*.json"]
   Checks --> CheckReview["Evaluator review<br/>Waza /check -> review file"]
@@ -341,40 +338,15 @@ y [`workflow-orchestration.md`](docs/reference-configs/workflow-orchestration.md
 
 ## Programas autorizados
 
-Un programa es trabajo que sobrevive a una sesión. Todos ellos parten de las
-mismas tres primitivas, y ninguno puede arrancar sin la primera.
+Un programa es trabajo que sobrevive a una sesión. El Bot lo planifica a
+través del CLI de repo-harness y Herdr. repo-harness no mantiene un scheduler,
+un budget ledger ni un controller propios.
 
-```bash
-repo-harness automation grant mint   # store one operator ProgramAuthorizationV2
-repo-harness automation grant list   # digests held for this repository
-repo-harness automation budget show          # the enforceable per-goal ledger
-repo-harness automation budget repair        # seal a stopped or expired run's exhaustion receipt
-```
-
-- **Authorization.** Un `ProgramAuthorizationV2` emitido por un operador vive
-  en el gate store del home del harness. No existe una ruta de arranque sin
-  autenticar, y un programa nunca deriva su propio actor — el autor de cada
-  registro se resuelve desde `--authorization-id`.
-- **Budget.** Los agent turns, acquisitions y runner invocations reservan el presupuesto antes del trabajo. `budget repair` conserva los límites.
 - **Lease.** El trabajo retenido lleva un lease renovable con un intervalo de
   renovación, un TTL máximo y un conjunto cerrado de fuentes de evidencia. Un
   estado de liveness no probado exige atención en lugar de reclamarse en
   silencio.
 
-### Controller desatendido
-
-```bash
-repo-harness automation controller start --maximum-steps 20 --maximum-duration-ms 300000
-repo-harness automation controller step
-repo-harness automation controller status
-repo-harness automation controller stop
-```
-
-Un bucle de dispatch de Engineer bajo topes duros, con backoff determinista y
-un ledger acotado de reintentos por intento. Cada intento reserva budget antes
-de quedar registrado, y un resultado proyectado fuera del enum cerrado no puede
-contarse como satisfecho.
-
 ### Scheduling de Engineer
 
 ```bash
@@ -393,20 +365,17 @@ sobre un backlog más antiguo.
 
 Campaign execution moved to the existing Bot skills on 2026-10-04. Use [repo-harness](SKILL.md) to dispatch and collect work through Herdr/OAR. Use [repo-harness-product](assets/skills/repo-harness-product/SKILL.md) for planning and [repo-harness-check](assets/skill-commands/repo-harness-check/SKILL.md) for scope and verification. repo-harness has no campaign runtime.
 
-### Refactor Mode
+### Refactor recommendations
 
 ```bash
-repo-harness refactor discover        # bounded shadow scan of one local proposal
-repo-harness refactor materialize     # one recommendation into N Work Packages
-repo-harness refactor verify-candidate
-repo-harness refactor board
+repo-harness refactor recommendations                       # measured suggestions with evidence
+repo-harness refactor decide <id> accept|defer|reject --reason "<text>"
 ```
 
-Un programa respaldado por ArchContext que convierte una recomendación de
-arquitectura en work packages contra una única autoridad canónica de tarea de
-Sprint. Su activación está condicionada: el canary set y la evidencia de
-rung-promotion deben refrescarse contra el provider instalado antes de que se
-active.
+ArchContext mide problemas estructurales como ciclos y violaciones de
+dirección. repo-harness muestra cada sugerencia con sus métricas y las
+estadísticas de sus módulos, y registra la decisión del usuario. Nunca ejecuta
+un refactor; una sugerencia aceptada sigue el flujo normal de plan y pull request.
 
 ### Plano de colaboración
 
@@ -446,6 +415,8 @@ repo-harness review status --contract tasks/contracts/<task>.contract.md
 repo-harness review close --contract tasks/contracts/<task>.contract.md
 ```
 
+En la app de escritorio de Claude sin Herdr, añada `--launch app-terminal` y omita `--herdr-endpoint`. La primera llamada imprime el comando fijo del host. Claude lo ejecuta una vez en una pestaña Terminal de la app y repite la misma ronda. OAR, Seatbelt y el Receipt no cambian.
+
 Un task-agent fleet `deep-reasoner` persiste en un linked checkout dedicado y la sesión Herdr indicada, durante un máximo de tres rondas. Por defecto se elige el harness opuesto al owner; `--harness` permite elegirlo explícitamente. Sólo un ejecutable ausente antes de iniciar permite fallback anunciado. El Result de archivo pasa la validación de dominio y el writer/verifier Receipt generic-review; close verifica el Receipt otra vez. History es observación. Claude usa una allowlist de archivos resultado y fingerprints; aislamiento OS de producción e ingestión completa de paquetes grandes siguen sin verificar.
 
 ## Hooks
@@ -583,11 +554,12 @@ host mientras el CLI y los hooks poseen la ejecución.
 | `repo-harness-product` | Modos PRD, Sprint y Goal para el product planning de upper-layer |
 | `repo-harness-check` | Definir el plan. Revisar el plan. Verificar los resultados registrados. |
 | `repo-harness-ship` | Valida worktrees terminados, hace push de branches y abre PRs |
-| `repo-harness-architecture` | Docs de architecture, drift requests y diagramas sin un refresh completo del harness |
+| `repo-harness-architecture` | Modelo de architecture, docs proyectados y diagramas sin un refresh completo del harness |
 | `repo-harness-cross-review` | Generic acceptance through persistent fleet deep-reasoner task-agent + Herdr review; direct advisory runtime retired |
 | `repo-harness-chatgpt` | Consultas de Oracle browser/GPT Pro, setup del MCP Connector y bridge handoff; solo setup explícito |
 | `obsidian-memory` | Bot: leer o guardar memoria por solicitud explícita. |
 | `repo-harness-test` | Worker: pruebas del código fuente y fixtures reales. |
+| `windows-python-first` | Worker: tareas de archivos, texto y shell en Windows nativo con Python. |
 | `merge-gate` (externo) | Gate final de exact-candidate; repo-harness no distribuye ningún Skill de merge-gate — ver [external tooling](docs/reference-configs/external-tooling.md) |
 
 Los Bot skills definen el alcance, la delegación y las decisiones. Los Worker skills ejecutan los pasos.
@@ -595,7 +567,8 @@ Los Bot skills definen el alcance, la delegación y las decisiones. Los Worker s
 Bot: `repo-harness`, `repo-harness-check`, `repo-harness-product`,
 `repo-harness-ship`, `obsidian-memory`, `repo-harness-cross-review`,
 `repo-harness-chatgpt`. Worker: `repo-harness-setup`,
-`repo-harness-test`, and `repo-harness-architecture`.
+`repo-harness-test`, `repo-harness-architecture`, and
+`windows-python-first`.
 `obsidian-memory`, and `repo-harness-ship` requieren una invocación explícita.
 Las tareas comunes usan un brief corto y la descripción del PR. PRD, Sprint y Goal sirven para el trabajo de producto solicitado.
 
@@ -676,8 +649,8 @@ repositorio adopte la misma política.
 
 ## Versión actual
 
-- Paquete npm: `repo-harness@0.21.2`
-- Sello de workflow generado: `repo-harness@0.21.2+template@0.21.2`
+- Paquete npm: `repo-harness@0.22.1`
+- Sello de workflow generado: `repo-harness@0.22.1+template@0.22.1`
 - Repositorio de GitHub: `Ancienttwo/repo-harness`
 - Notas de versión e historial: [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
 

package/README.fr.md

@@ -22,10 +22,10 @@ de review, afin que la session d'agent suivante reprenne à partir des fichiers
 plutôt que de la mémoire de chat. Il adopte un dépôt existant avec un contrat
 d'agent tasks-first qui maintient Claude et Codex alignés.
 
-Par-dessus ce contrat, il exécute des **programmes autorisés** : du travail de
-longue durée qui porte sa propre autorisation, son budget, ses task offers et
-ses leases, si bien qu'un Sprint peut avancer d'une session à l'autre sans
-qu'un humain pilote chaque étape.
+Par-dessus ce contrat, le Bot ordonnance des **programmes de longue durée** :
+les task offers et les leases permettent à un Sprint d'avancer d'une session à
+l'autre. repo-harness fournit les outils et les preuves ; le Bot décide de ce
+qui s'exécute ensuite.
 
 ## Sommaire
 
@@ -171,11 +171,10 @@ repo-harness mcp uninstall --services-stopped # after stopping all MCP HTTP serv
   décision humaine tient sur un seul écran — verdict, fichiers prévus vs
   réels, commandes passées, risque résiduel, rollback — plutôt qu'une
   reconstruction de ce que l'agent prétend avoir fait.
-- **Le travail non supervisé reste redevable.** Un programme ne peut pas
-  démarrer sans une autorisation stockée, ne peut pas dépasser son budget
-  ledger, ne peut pas retenir une tâche au-delà de son lease, et ne peut pas
-  revendiquer une acceptance sans receipt. L'autonomie est bornée par des
-  artifacts, pas par la confiance.
+- **Le travail ordonnancé reste redevable.** Une tâche ne peut pas être
+  retenue au-delà de son lease. Elle ne peut pas non plus revendiquer une
+  acceptance sans receipt. Le Bot ordonnance à partir des preuves enregistrées,
+  pas de la confiance.
 
 Dans un dépôt adopté, la surface à comprendre reste volontairement réduite :
 
@@ -197,21 +196,20 @@ entier pour un dépôt en solo, et tout ce qui figure dans
 [Workflow des tâches](#workflow-des-tâches) appartient à cette couche. Rien de
 ce qui suit n'est requis pour l'utiliser.
 
-**Couche 2 — les programmes autorisés.** Du travail de longue durée qui survit
-à une session : un controller non supervisé qui fait avancer un Sprint, un programme de
-refactor piloté par le modèle d'architecture, un plan de collaboration où
-plusieurs Module Engineers échangent signaux et handoffs. Chaque programme est
-conditionné à une autorisation frappée par un opérateur, puise dans un budget
-ledger par goal, et retient le travail via des leases renouvelables. Voir
+**Couche 2 — les programmes ordonnancés par le Bot.** Du travail de longue
+durée qui survit à une session : un plan de collaboration où plusieurs Module
+Engineers échangent signaux et handoffs, et des task offers d'engineer retenus
+via des leases renouvelables. Le Bot décide de ce qu'il ordonnance. repo-harness
+fournit les outils et les preuves. Voir
 [Programmes autorisés](#programmes-autorisés).
 
 | | Couche 1 | Couche 2 |
 | --- | --- | --- |
-| Unité de travail | Un task contract | Un programme autorisé |
-| Qui le pilote | Un humain dans une session | Un controller, sous caps |
-| Autorité | Plan, contract, review, checks | Ce qui précède, plus authorization, budget, lease, receipts |
-| Point d'entrée | `repo-harness init` | `repo-harness automation grant mint` |
-| Condition d'arrêt | Closeout de la tâche | Budget épuisé, lease perdu, ou un receipt terminal |
+| Unité de travail | Un task contract | Une engineer task ordonnancée |
+| Qui le pilote | Un humain dans une session | Le Bot, via le CLI repo-harness et Herdr |
+| Autorité | Plan, contract, review, checks | Ce qui précède, plus engineer binding et lease |
+| Point d'entrée | `repo-harness init` | `repo-harness engineer acquire-next` |
+| Condition d'arrêt | Closeout de la tâche | Closeout de la tâche ou lease perdu |
 
 La couche 2 ne remplace pas la couche 1 : chaque étape d'un programme se
 projette toujours dans les mêmes artifacts de plan, contract et review qu'un
@@ -224,8 +222,7 @@ humain aurait écrits.
 | **Sessions file-backed** | Les plans, contracts, checks et handoffs vivent dans le dépôt, si bien qu'une nouvelle session reprend à partir des artifacts plutôt que d'un chat thread |
 | **Runtime de hooks typés** | Huit routes managées partagées, plus trois routes de delegation réservées à Codex, chacune liée à exactement un typed handler in-process, avec des guards fail-closed à la frontière d'édition |
 | **Plan → Contract → Review** | Un seul lifecycle, du plan approuvé au contract projeté, en passant par le worktree isolé et l'evidence structurée, jusqu'à un closeout prêt pour la review |
-| **Programmes autorisés** | Programmes refactor, automation et collaboration qui portent leur propre authorization, budget ledger, task offers et leases renouvelables |
-| **Controller non supervisé borné** | Une boucle de dispatch Engineer sous des caps stricts d'étapes, de durée et de retries, qui réserve du budget avant chaque tentative |
+| **Programmes ordonnancés par le Bot** | Programmes de collaboration avec des task offers d'engineer et des leases renouvelables ; le Bot ordonnance, repo-harness fournit les outils et les preuves |
 | **Chargement de contexte progressif** | Un root context stable d'environ 12 Ko, plus des capability contracts d'environ 1 Ko chargés uniquement pour les fichiers réellement touchés |
 | **Intégration CodeGraph** | Requêtes structurelles (callers, callees, définitions) résolues depuis un index pré-construit, au lieu de passes grep-and-read répétées |
 | **MCP planner sidecar** | ChatGPT lit l'état réel du dépôt et écrit les artifacts PRD/Sprint/Goal ; Codex les exécute, sans accès en écriture par défaut au source-code |
@@ -304,9 +301,9 @@ flowchart TD
   PreHooks -->|blocked| ScopeFix["Fix plan, contract, worktree, or scope"]
   ScopeFix --> Implement
   PreHooks -->|allowed| Changes["Code, docs, tests, or config changes"]
-  Changes --> PostHooks["Post-edit and post-bash hooks<br/>trace, drift request, handoff, check evidence"]
-  PostHooks --> ArchQueue["Architecture queue<br/>architecture-queue.sh record/reindex<br/>check-architecture-sync.sh"]
-  ArchQueue --> Verify["Run verification<br/>tests plus repo workflow checks"]
+  Changes --> PostHooks["Post-edit and post-bash hooks<br/>trace, handoff, check evidence"]
+  PostHooks --> ArchUpdate["Explicit architecture update<br/>archctx ChangeSet when responsibilities change<br/>architecture-projection apply"]
+  ArchUpdate --> Verify["Run verification<br/>tests plus repo workflow checks"]
 
   Verify --> Checks["Structured evidence<br/>.ai/harness/evidence/events/log.jsonl<br/>.ai/harness/runs/*.json"]
   Checks --> CheckReview["Evaluator review<br/>Waza /check -> review file"]
@@ -339,40 +336,15 @@ et [`workflow-orchestration.md`](docs/reference-configs/workflow-orchestration.m
 
 ## Programmes autorisés
 
-Un programme est un travail qui survit à une session. Chacun d'eux part des
-trois mêmes primitives, et aucun ne peut démarrer sans la première.
+Un programme est un travail qui survit à une session. Le Bot l'ordonnance via
+le CLI repo-harness et Herdr. repo-harness ne garde ni scheduler, ni budget
+ledger, ni controller qui lui soient propres.
 
-```bash
-repo-harness automation grant mint   # store one operator ProgramAuthorizationV2
-repo-harness automation grant list   # digests held for this repository
-repo-harness automation budget show          # the enforceable per-goal ledger
-repo-harness automation budget repair        # seal a stopped or expired run's exhaustion receipt
-```
-
-- **Authorization.** Un `ProgramAuthorizationV2` frappé par un opérateur vit
-  dans le gate store du harness home. Il n'existe aucun chemin de démarrage non
-  authentifié, et un programme ne dérive jamais son propre actor — l'auteur de
-  chaque enregistrement est résolu depuis `--authorization-id`.
-- **Budget.** Les agent turns, acquisitions et runner invocations réservent le budget avant le travail. `budget repair` conserve les limites.
 - **Lease.** Le travail retenu porte un lease renouvelable avec un intervalle de
   renouvellement, un TTL maximum, et un ensemble fermé de sources d'evidence. Un
   état de liveness non prouvé demande de l'attention plutôt qu'une reprise
   silencieuse.
 
-### Controller non supervisé
-
-```bash
-repo-harness automation controller start --maximum-steps 20 --maximum-duration-ms 300000
-repo-harness automation controller step
-repo-harness automation controller status
-repo-harness automation controller stop
-```
-
-Une seule boucle de dispatch Engineer sous des caps stricts, avec un backoff
-déterministe et un ledger borné de retries de tentative. Chaque tentative
-réserve du budget avant d'être enregistrée, et un outcome projeté en dehors de
-l'enum fermée ne peut pas être compté comme satisfait.
-
 ### Ordonnancement des Engineers
 
 ```bash
@@ -391,20 +363,18 @@ immuables sous le backlog schema v2 — lancez une fois
 
 Campaign execution moved to the existing Bot skills on 2026-10-04. Use [repo-harness](SKILL.md) to dispatch and collect work through Herdr/OAR. Use [repo-harness-product](assets/skills/repo-harness-product/SKILL.md) for planning and [repo-harness-check](assets/skill-commands/repo-harness-check/SKILL.md) for scope and verification. repo-harness has no campaign runtime.
 
-### Refactor Mode
+### Refactor recommendations
 
 ```bash
-repo-harness refactor discover        # bounded shadow scan of one local proposal
-repo-harness refactor materialize     # one recommendation into N Work Packages
-repo-harness refactor verify-candidate
-repo-harness refactor board
+repo-harness refactor recommendations                       # measured suggestions with evidence
+repo-harness refactor decide <id> accept|defer|reject --reason "<text>"
 ```
 
-Un programme adossé à ArchContext qui transforme une recommandation
-d'architecture en work packages contre une autorité unique et canonique de
-Sprint task. L'activation est conditionnée : le canary set et l'evidence de
-rung-promotion doivent être rafraîchis contre le provider installé avant
-l'activation.
+ArchContext mesure des problèmes structurels comme les cycles et les
+violations de direction. repo-harness montre chaque suggestion avec ses
+métriques et les statistiques de ses modules, et enregistre la décision de
+l'utilisateur. Il n'exécute jamais de refactor ; une suggestion acceptée suit le
+flux normal de plan et de pull request.
 
 ### Plan de collaboration
 
@@ -444,6 +414,8 @@ repo-harness review status --contract tasks/contracts/<task>.contract.md
 repo-harness review close --contract tasks/contracts/<task>.contract.md
 ```
 
+Dans l'application de bureau Claude sans Herdr, ajoutez `--launch app-terminal` et omettez `--herdr-endpoint`. Le premier appel affiche la commande fixe du host. Claude l'exécute une fois dans un onglet Terminal de l'application, puis relance la même ronde. OAR, Seatbelt et le Receipt restent identiques.
+
 Un task-agent fleet `deep-reasoner` persiste dans un linked checkout dédié et la session Herdr explicitement adressée, pour trois rounds au maximum. Le harness opposé à celui du owner est choisi par défaut ; `--harness` permet un choix explicite. Seul un executable absent avant le démarrage permet un fallback annoncé. Le Result fichier passe la validation de domaine puis le writer/verifier Receipt generic-review ; close revérifie le Receipt. History reste une observation. Claude utilise une allowlist de fichiers résultat et des fingerprints ; isolation OS de production et ingestion complète des grands packets restent non vérifiées.
 
 ## Hooks
@@ -579,11 +551,12 @@ bornée pendant que le CLI et les hooks possèdent l'exécution.
 | `repo-harness-product` | Modes PRD, Sprint et Goal pour le product planning upper-layer |
 | `repo-harness-check` | Planifier le travail. Revoir le plan. Vérifier les résultats enregistrés. |
 | `repo-harness-ship` | Valide les worktrees terminés, push les branches et ouvre les PRs |
-| `repo-harness-architecture` | Docs d'architecture, drift requests et diagrammes sans rafraîchissement complet du harness |
+| `repo-harness-architecture` | Modèle d'architecture, docs projetés et diagrammes sans rafraîchissement complet du harness |
 | `repo-harness-cross-review` | Generic acceptance through persistent fleet deep-reasoner task-agent + Herdr review; direct advisory runtime retired |
 | `repo-harness-chatgpt` | Consults Oracle browser/GPT Pro, setup du Connecteur MCP et bridge handoff ; setup explicite uniquement |
 | `obsidian-memory` | Bot : lire ou écrire la mémoire sur demande explicite. |
 | `repo-harness-test` | Worker : tests du code source et fixtures réelles. |
+| `windows-python-first` | Worker : fichiers, texte et shell sous Windows natif avec Python. |
 | `merge-gate` (externe) | Gate final exact-candidate ; repo-harness ne fournit aucun Skill merge-gate — voir [external tooling](docs/reference-configs/external-tooling.md) |
 
 Les Bot skills définissent le périmètre, la délégation et les décisions. Les Worker skills exécutent les étapes.
@@ -591,7 +564,8 @@ Les Bot skills définissent le périmètre, la délégation et les décisions. L
 Bot: `repo-harness`, `repo-harness-check`, `repo-harness-product`,
 `repo-harness-ship`, `obsidian-memory`, `repo-harness-cross-review`,
 `repo-harness-chatgpt`. Worker: `repo-harness-setup`,
-`repo-harness-test`, and `repo-harness-architecture`.
+`repo-harness-test`, `repo-harness-architecture`, and
+`windows-python-first`.
 `obsidian-memory`, and `repo-harness-ship` exigent une invocation explicite.
 Les tâches courantes utilisent un brief court et la description du PR. PRD, Sprint et Goal servent aux travaux produit demandés.
 
@@ -671,8 +645,8 @@ adopte la même policy.
 
 ## Release actuelle
 
-- Package npm : `repo-harness@0.21.2`
-- Generated workflow stamp : `repo-harness@0.21.2+template@0.21.2`
+- Package npm : `repo-harness@0.22.1`
+- Generated workflow stamp : `repo-harness@0.22.1+template@0.22.1`
 - Dépôt GitHub : `Ancienttwo/repo-harness`
 - Notes et historique de release : [`docs/CHANGELOG.md`](docs/CHANGELOG.md)