repo-harness 0.5.1 → 0.5.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.es.md CHANGED
@@ -1,5 +1,9 @@
1
1
  # repo-harness
2
2
 
3
+ <p align="center">
4
+ <img src="docs/images/image.png" alt="One next button joining Claude and Codex under repo-harness workflow rules" width="760">
5
+ </p>
6
+
3
7
  `repo-harness` convierte las sesiones de programación con Claude/Codex en un
4
8
  workflow repo-local repetible. Incluye un CLI y hooks de skill/runtime que
5
9
  escriben contexto, planes, handoffs, checks y evidencias de review dentro del
@@ -43,43 +47,20 @@ Dirección del repositorio: `https://github.com/Ancienttwo/repo-harness`
43
47
  1KB o consulta el índice, en vez de gastar miles de tokens redescubriendo la
44
48
  estructura.
45
49
 
46
- ## Novedades en 0.2.1
47
-
48
- - **Comando de inicialización global (`repo-harness init`).** Un solo comando
49
- inicializa el entorno global de Claude: essential plugins, policy
50
- hooks configurables (worktree guard, atomic commit/pending), LSP plugins
51
- opcionales según el tipo de proyecto y cuatro hook profiles (`standard`,
52
- `minimal`, `biome`, `biome-strict`). Ejecuta
53
- `npx -y repo-harness init`; no necesitas clonar el repositorio fuente.
54
- - **Comando de adopción del repo (`repo-harness adopt`).** La instalación y el
55
- refresco de repos existentes tienen su propia superficie de comando, manteniendo
56
- la ruta de migración repo-local anterior mientras `init` queda dedicado al
57
- runtime global.
58
- - **Auto-recuperación del índice CodeGraph.** Si el prompt hook detecta intención
59
- de navegación estructural y el repo no tiene índice `.codegraph`, inicializa el
60
- índice con el binario CodeGraph local o visible en PATH antes de emitir la pista.
61
- Sigue siendo advisory: no instala dependencias, no ejecuta el readiness probe
62
- pesado y no bloquea el prompt si CodeGraph no está disponible.
63
- - **Centinela de seguridad (`repo-harness security scan` + `security-sentinel.sh`).**
64
- Una verificación de solo lectura sobre las superficies de inyección de
65
- configuración de alto valor (`~/.claude/settings.json`, `~/.codex/hooks.json`,
66
- el `.vscode/tasks.json` repo-local y los adapters legacy a nivel de proyecto
67
- `.claude`/`.codex`). Marca patrones de comando sospechosos —pipes de remote
68
- shell, base64-decode-to-exec, `osascript`, persistencia con
69
- `launchctl`/`crontab`, netcat, ejecución inline de intérpretes—, además de
70
- hooks no gestionados y tareas `folderOpen` de ejecución automática, y nunca
71
- modifica ninguna configuración. El centinela de `SessionStart` toma una huella
72
- de este conjunto y solo reescanea cuando la huella cambia, para no generar
73
- ruido en el session-start. Auditoría bajo demanda:
74
- `repo-harness security scan --json`.
75
- - **Ciclo de vida draft-plan de Claude/Codex.** El Plan mode tiene explícitamente
76
- dos etapas: Draft y Approved. Los hooks reconocen la intención de crear un plan
77
- y rastrean la pending orchestration; un stop gate (`stop-orchestrator.sh`) exige
78
- que la sesión haga una pasada de autorevisión antes de terminar con el plan sin
79
- definir. Captura un borrador con `scripts/capture-plan.sh --slug <slug> --title
80
- <title> --status Draft`, después promociónalo a Approved y proyéctalo a
81
- ejecución con `--execute` o `scripts/plan-to-todo.sh --plan <plan>`. Los plans
82
- se convierten en la fuente de verdad a nivel de archivo en `plans/`.
50
+ En un repositorio adoptado, la superficie se mantiene pequeña:
51
+
52
+ | Surface | Propósito |
53
+ | --- | --- |
54
+ | `docs/spec.md` y `docs/reference-configs/` | Estándares compartidos e intención de producto estable que cada sesión de agente puede leer. |
55
+ | `plans/`, `plans/prds/` y `plans/sprints/` | Work packages decision-complete antes de empezar la implementación. |
56
+ | `tasks/contracts/`, `tasks/reviews/` y `.ai/harness/checks/` | Scope, verificación y evidencia de review para probar que el trabajo terminó. |
57
+ | `.ai/harness/handoff/` y `tasks/current.md` | Session journal y estado resumible, derivados de workflow artifacts en vez de chat memory. |
58
+
59
+ ## Novedades en 0.5.3
60
+
61
+ - **Runtime updates con versión fija.** `repo-harness update --version <version>` ahora instala el package `repo-harness@<version>` solicitado, en vez de ser interceptado por el shortcut global de versión de la CLI.
62
+ - **Version shortcut preservado.** `repo-harness --version` y `repo-harness -V` siguen mostrando la versión de la CLI cuando se usan en el nivel superior.
63
+ - **Patch-only surface.** No cambian hook routes, setup checks, security scan ni workflow contracts, salvo el fix del option del comando update.
83
64
 
84
65
  ## Qué hace el producto
85
66
 
@@ -301,7 +282,7 @@ El comando debería terminar imprimiendo `=== Migration Report ===`, e incluir:
301
282
  - `Host hook config target: user-level ~/.claude/settings.json and ~/.codex/hooks.json`: dónde está la capa del adapter
302
283
  - `Host hook adapters are user-level:`: recordatorio de instalar los global adapters y de confiar en `~/.codex/hooks.json`
303
284
  - `Workflow migration:`: el plan de creación o refresco de las repo-local harness surfaces
304
- - `Helper scripts:`: la cadena de herramientas operativa que obtendrás tras aplicar
285
+ - `Helper runtime:`: la cadena de herramientas operativa que obtendrás tras aplicar
305
286
  - `--- External Tooling ---`: el routing de gstack/Waza/gbrain más las advisory de instalación/actualización
306
287
 
307
288
  ### Los dos comandos siguientes
@@ -323,6 +304,22 @@ Si la salida del dry-run no es correcta, detente aquí primero y lee
323
304
  - Codex debe confiar en `~/.codex/hooks.json` en sus Settings para que los hooks se ejecuten.
324
305
  - Orden de depuración: user-level adapter config -> `repo-harness-hook` o el fallback `repo-harness hook` -> route registry -> `.ai/hooks/*`.
325
306
 
307
+
308
+ The installed adapter owns eight managed hook routes. The route tuple
309
+ `event + routeId + matcher` is the stable contract; script names are the current
310
+ implementation under `assets/hooks/` or a repo-pinned `.ai/hooks/` copy.
311
+
312
+ | Route | Matcher | Scripts | Function |
313
+ | --- | --- | --- | --- |
314
+ | `SessionStart.default` | all sessions | `session-start-context.sh`, `security-sentinel.sh` | Injects prior handoff, sprint status, and read-only config-security findings before work starts. |
315
+ | `PreToolUse.edit` | `Edit|Write` | `worktree-guard.sh`, `pre-edit-guard.sh` | Enforces worktree policy and plan/contract readiness before implementation edits. |
316
+ | `PreToolUse.subagent` | `Task|Agent|SendUserMessage` | `subagent-return-channel-guard.sh` | Keeps delegated work returning through the parent session instead of leaking completion claims. |
317
+ | `PostToolUse.edit` | `Edit|Write` | `post-edit-guard.sh` | Records edit traces, refreshes handoff/task status, and queues architecture drift when controlled files change. |
318
+ | `PostToolUse.bash` | `Bash` | `post-bash.sh` | Observes command results and captures verification evidence without replacing the command runner. |
319
+ | `PostToolUse.always` | all tools | `post-tool-observer.sh` | Provides low-noise always-on trace and runtime observation; stale pinned copies soft-skip with a refresh hint. |
320
+ | `UserPromptSubmit.default` | all prompts | `prompt-guard.sh` | Classifies prompt intent, routes planning/check/hunt hints, and renders host-safe workflow guidance. |
321
+ | `Stop.default` | session stop | `stop-orchestrator.sh` | Finalizes handoff and guards against ending with unresolved draft-plan or completion evidence gaps. |
322
+
326
323
  `SessionStart` ejecuta dos scripts ordenados antes de empezar el trabajo:
327
324
 
328
325
  ```mermaid
@@ -380,8 +377,8 @@ Guards habituales:
380
377
 
381
378
  ## Release actual
382
379
 
383
- - npm package: `repo-harness@0.5.1`
384
- - Generated workflow stamp: `repo-harness@0.5.1+template@0.5.1`
380
+ - npm package: `repo-harness@0.5.3`
381
+ - Generated workflow stamp: `repo-harness@0.5.3+template@0.5.3`
385
382
  - GitHub repository: `Ancienttwo/repo-harness`
386
383
  - Release history: [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
387
384
 
@@ -393,6 +390,13 @@ Guards habituales:
393
390
  - `scripts/inspect-project-state.ts`
394
391
  - `scripts/migrate-workflow-docs.ts`
395
392
  - `assets/workflow-contract.v1.json`
393
+ - Runtime mode is configurable with template vars:
394
+ - `{{RUNTIME_MODE}}`
395
+ - `{{RUNTIME_PROFILE}}`
396
+ - `{{RECOVERY_PROFILE}}`
397
+ - `{{STATE_PROFILE}}`
398
+ - Question-pack source of truth is in:
399
+ - `assets/initializer-question-pack.v4.json`
396
400
  - Los generated repos usan por defecto el repo-local harness flow:
397
401
  - `docs/spec.md -> plans/ -> tasks/contracts/ -> tasks/reviews/ -> .ai/context/context-map.json -> .ai/harness/*`
398
402
  - `repo-harness update` refresca las runtime pieces de usuario:
@@ -419,6 +423,17 @@ Gracias a [Garry Tan](https://x.com/garrytan), autor de gstack y gbrain. Ambos
419
423
  influyeron en el workflow de product discovery, plan/design review, release
420
424
  documentation, knowledge sync y handoff retrieval.
421
425
 
426
+
427
+ ### Atribución de contribuidor en GitHub
428
+
429
+ Cuando Codex contribuya materialmente a un commit, usa el trailer co-author estándar de GitHub al final del commit message:
430
+
431
+ ```text
432
+ Co-authored-by: codex <codex@openai.com>
433
+ ```
434
+
435
+ Mantén esta atribución opt-in y visible por commit. No la incorpores en scripts de commit ni hooks downstream de repo-harness salvo que ese repo adopte explícitamente la misma política.
436
+
422
437
  ## Action Command Skills
423
438
 
424
439
  Los command facades públicos están en `assets/skill-commands/`; preservan la
@@ -462,6 +477,23 @@ bun scripts/inspect-project-state.ts --repo . --format text
462
477
  bash scripts/migrate-project-template.sh --repo . --dry-run
463
478
  ```
464
479
 
480
+
481
+ ### Runtime reference docs
482
+
483
+ Generic repo-harness runtime/reference docs live in the installed package under
484
+ `assets/reference-configs/` and are resolved through the CLI:
485
+
486
+ ```bash
487
+ repo-harness docs list
488
+ repo-harness docs path harness-overview
489
+ repo-harness docs show harness-overview
490
+ ```
491
+
492
+ Generated and migrated repos still keep `docs/reference-configs/*.md`, but
493
+ those files are deterministic pointer stubs. Repo-local workflow state,
494
+ policy, checks, runs, handoff packets, context maps, and helper snapshots stay
495
+ under `.ai/`.
496
+
465
497
  ### Template assembly
466
498
 
467
499
  ```bash
@@ -478,7 +510,23 @@ bash scripts/check-task-workflow.sh --strict
478
510
  bun scripts/inspect-project-state.ts --repo . --format text
479
511
  bash scripts/migrate-project-template.sh --repo . --dry-run
480
512
  bash scripts/check-agent-tooling.sh --host both --check-updates
481
- bun run benchmark:skills --dry-run
513
+ bun run benchmark:skills --eval route-workflow-check
514
+ ```
515
+
516
+
517
+ ### Local benchmark skeleton
518
+
519
+ ```bash
520
+ bun run benchmark:skills --eval route-workflow-check
521
+ ```
522
+
523
+ Eval output is the release/readiness evidence path; dry-run benchmark wiring is only a smoke and is not skill-effectiveness evidence.
524
+
525
+
526
+ ### Run one eval across both Claude and Codex
527
+
528
+ ```bash
529
+ bun run benchmark:skills --eval repair-agents-task-sync
482
530
  ```
483
531
 
484
532
  ## Key Files
@@ -488,8 +536,54 @@ bun run benchmark:skills --dry-run
488
536
  - Plan mapping: `assets/plan-map.json`
489
537
  - Question-pack: `assets/initializer-question-pack.v4.json`
490
538
  - Shared hooks: `assets/hooks/`
539
+ - Runtime reference docs: `assets/reference-configs/` via `repo-harness docs`
491
540
  - Workflow contract: `assets/workflow-contract.v1.json`
492
541
  - Hook operations reference: `docs/reference-configs/hook-operations.md`
493
542
  - Template assembler: `scripts/assemble-template.ts`
494
543
  - State inspector: `scripts/inspect-project-state.ts`
544
+ - External tooling detector: `scripts/check-agent-tooling.sh`
545
+ - Scaffolding scripts:
546
+ - `scripts/init-project.sh`
547
+ - `scripts/create-project-dirs.sh`
495
548
  - Legacy-doc migrator: `scripts/migrate-workflow-docs.ts`
549
+
550
+ ## Generated vs Self-Hosted Hook Parity
551
+
552
+ - El comportamiento downstream de hooks lo define la salida generada desde `assets/hooks/` y `assets/reference-configs/`.
553
+ - Este repo dogfoodea el mismo contract, pero el comportamiento self-host no se sincroniza mágicamente con los generated repos; cada cambio debe actualizar explícitamente ambas superficies cuando aplique.
554
+ - Todo cambio de hook debe indicar si afecta a `self-host`, `generated` o `both`.
555
+
556
+ ## Package Manager Defaults
557
+
558
+ - Prioridad general por defecto: `bun > pnpm > npm`
559
+ - **Plan G/H** (Python-centric) usa **`uv`** como primary package manager por defecto.
560
+
561
+ ## Runtime Profiles
562
+
563
+ - `Plan-only (recommended)` (default)
564
+ - `Plan + Permissionless`
565
+ - `Standard (ask before each action)`
566
+
567
+ Se configura en `assets/initializer-question-pack.v4.json` y lo consume `scripts/initializer-question-pack.ts`.
568
+
569
+ ## Verification
570
+
571
+ Para release review usa el gate único equivalente a CI:
572
+
573
+ ```bash
574
+ bun run check:ci
575
+ ```
576
+
577
+ Ese gate se expande a los checks propios del repo; `bun run check:release` solo añade el preflight de npm unpublished-version antes de delegar al mismo gate.
578
+
579
+ ```bash
580
+ bun test
581
+ bash scripts/check-deploy-sql-order.sh
582
+ bash scripts/check-architecture-sync.sh
583
+ bash scripts/check-task-sync.sh
584
+ bash scripts/check-task-workflow.sh --strict
585
+ bun scripts/inspect-project-state.ts --repo . --format text
586
+ bash scripts/migrate-project-template.sh --repo . --dry-run
587
+ bash scripts/check-agent-tooling.sh --host both --check-updates
588
+ bun run benchmark:skills --eval route-workflow-check
589
+ ```
package/README.fr.md CHANGED
@@ -1,5 +1,9 @@
1
1
  # repo-harness
2
2
 
3
+ <p align="center">
4
+ <img src="docs/images/image.png" alt="One next button joining Claude and Codex under repo-harness workflow rules" width="760">
5
+ </p>
6
+
3
7
  `repo-harness` transforme les sessions de code Claude/Codex en workflow
4
8
  repo-local répétable. Il fournit un CLI et des hooks skill/runtime qui écrivent
5
9
  le contexte, les plans, les handoffs, les checks et les preuves de review dans le
@@ -43,45 +47,20 @@ Adresse du dépôt : `https://github.com/Ancienttwo/repo-harness`
43
47
  1 Ko ou interroge l'index, au lieu de dépenser des milliers de tokens à
44
48
  redécouvrir la structure.
45
49
 
46
- ## Nouveautés de la 0.2.1
47
-
48
- - **Commande d'initialisation globale (`repo-harness init`).** Une seule commande
49
- amorce l'environnement Claude global : essential plugins,
50
- policy hooks configurables (worktree guard, atomic commit/pending), LSP plugins
51
- optionnels selon le type de projet, et quatre hook profiles (`standard`,
52
- `minimal`, `biome`, `biome-strict`). Exécutez
53
- `npx -y repo-harness init` ; aucun clone du dépôt source n'est nécessaire.
54
- - **Commande d'adoption du dépôt (`repo-harness adopt`).** L'installation
55
- et le rafraîchissement des dépôts existants ont leur propre surface de commande,
56
- tout en conservant l'ancien chemin de migration repo-local et en gardant `init`
57
- dédié au runtime global.
58
- - **Auto-réparation de l'index CodeGraph.** Quand le prompt hook détecte une
59
- intention de navigation structurelle et que le dépôt n'a pas d'index
60
- `.codegraph`, il initialise l'index avec le binaire CodeGraph local ou visible
61
- dans PATH avant d'émettre l'indication de route. Cela reste advisory : pas
62
- d'installation de dépendances, pas de readiness probe lourd, et pas de blocage
63
- du prompt si CodeGraph est indisponible.
64
- - **Sentinelle de sécurité (`repo-harness security scan` +
65
- `security-sentinel.sh`).** Une vérification en lecture seule sur les surfaces
66
- d'injection de configuration à forte valeur (`~/.claude/settings.json`,
67
- `~/.codex/hooks.json`, le `.vscode/tasks.json` repo-local, ainsi que les adapter
68
- legacy de niveau projet `.claude`/`.codex`). Elle signale les motifs de commandes
69
- dangereux — pipes vers un remote shell, base64 décodé puis exécuté, `osascript`,
70
- persistance via `launchctl`/`crontab`, netcat, exécution d'interpréteur inline —
71
- ainsi que les hooks non gérés et les tâches `folderOpen` auto-exécutées, et elle
72
- ne réécrit jamais aucune configuration. La sentinelle `SessionStart` calcule une
73
- empreinte de cet ensemble de fichiers et ne rescanne que lorsque l'empreinte
74
- change, sans produire de bruit au démarrage de session. Audit à la demande :
75
- `repo-harness security scan --json`.
76
- - **Cycle de vie draft-plan Claude/Codex.** Le Plan mode se divise explicitement en
77
- deux étapes : Draft et Approved. Les hooks détectent l'intention de créer un plan
78
- et suivent le pending orchestration ; le stop gate (`stop-orchestrator.sh`) exige
79
- que la session fasse une passe d'auto-review avant de se terminer alors qu'un plan
80
- n'est pas finalisé. Capturez un brouillon avec
81
- `scripts/capture-plan.sh --slug <slug> --title <title> --status Draft`, puis
82
- passez en Approved après validation et projetez-le dans l'exécution avec
83
- `--execute` ou `scripts/plan-to-todo.sh --plan <plan>`. plans/ devient la source
84
- de vérité au niveau fichier.
50
+ Dans un dépôt adopté, la surface à comprendre reste volontairement réduite :
51
+
52
+ | Surface | Rôle |
53
+ | --- | --- |
54
+ | `docs/spec.md` et `docs/reference-configs/` | Standards partagés et intention produit stable lisibles par chaque session d'agent. |
55
+ | `plans/`, `plans/prds/` et `plans/sprints/` | Work packages decision-complete avant le début de l'implémentation. |
56
+ | `tasks/contracts/`, `tasks/reviews/` et `.ai/harness/checks/` | Scope, vérification et preuves de review pour démontrer que le travail est terminé. |
57
+ | `.ai/harness/handoff/` et `tasks/current.md` | Session journal et état resumable dérivés des workflow artifacts plutôt que de la chat memory. |
58
+
59
+ ## Nouveautés de la 0.5.3
60
+
61
+ - **Runtime updates épinglés.** `repo-harness update --version <version>` installe maintenant le package `repo-harness@<version>` demandé au lieu d'être intercepté par le raccourci global de version de la CLI.
62
+ - **Version shortcut préservé.** `repo-harness --version` et `repo-harness -V` continuent d'afficher la version CLI lorsqu'ils sont utilisés au niveau supérieur.
63
+ - **Patch-only surface.** Aucun changement de hook route, setup check, security scan ou workflow contract au-delà du fix de l'option du command update.
85
64
 
86
65
  ## Ce que fait le produit
87
66
 
@@ -307,7 +286,7 @@ La commande doit se terminer par `=== Migration Report ===` et inclure :
307
286
  - `Host hook config target: user-level ~/.claude/settings.json and ~/.codex/hooks.json` : où se trouve la couche adapter
308
287
  - `Host hook adapters are user-level:` : rappel d'installer les global adapters, et de faire confiance à `~/.codex/hooks.json`
309
288
  - `Workflow migration:` : le plan de création ou de rafraîchissement des repo-local harness surfaces
310
- - `Helper scripts:` : la chaîne d'outils opérationnels obtenue après application
289
+ - `Helper runtime:` : la chaîne d'outils opérationnels obtenue après application
311
290
  - `--- External Tooling ---` : le routing gstack/Waza/gbrain ainsi que les conseils d'installation/mise à jour advisory
312
291
 
313
292
  ### Les deux commandes à lancer ensuite
@@ -329,6 +308,22 @@ Si la sortie du dry-run est incorrecte, arrêtez-vous ici et lisez
329
308
  - Codex doit faire confiance à `~/.codex/hooks.json` dans Settings pour que les hooks s'exécutent.
330
309
  - Ordre de débogage : user-level adapter config -> `repo-harness-hook` ou fallback `repo-harness hook` -> route registry -> `.ai/hooks/*`.
331
310
 
311
+
312
+ The installed adapter owns eight managed hook routes. The route tuple
313
+ `event + routeId + matcher` is the stable contract; script names are the current
314
+ implementation under `assets/hooks/` or a repo-pinned `.ai/hooks/` copy.
315
+
316
+ | Route | Matcher | Scripts | Function |
317
+ | --- | --- | --- | --- |
318
+ | `SessionStart.default` | all sessions | `session-start-context.sh`, `security-sentinel.sh` | Injects prior handoff, sprint status, and read-only config-security findings before work starts. |
319
+ | `PreToolUse.edit` | `Edit|Write` | `worktree-guard.sh`, `pre-edit-guard.sh` | Enforces worktree policy and plan/contract readiness before implementation edits. |
320
+ | `PreToolUse.subagent` | `Task|Agent|SendUserMessage` | `subagent-return-channel-guard.sh` | Keeps delegated work returning through the parent session instead of leaking completion claims. |
321
+ | `PostToolUse.edit` | `Edit|Write` | `post-edit-guard.sh` | Records edit traces, refreshes handoff/task status, and queues architecture drift when controlled files change. |
322
+ | `PostToolUse.bash` | `Bash` | `post-bash.sh` | Observes command results and captures verification evidence without replacing the command runner. |
323
+ | `PostToolUse.always` | all tools | `post-tool-observer.sh` | Provides low-noise always-on trace and runtime observation; stale pinned copies soft-skip with a refresh hint. |
324
+ | `UserPromptSubmit.default` | all prompts | `prompt-guard.sh` | Classifies prompt intent, routes planning/check/hunt hints, and renders host-safe workflow guidance. |
325
+ | `Stop.default` | session stop | `stop-orchestrator.sh` | Finalizes handoff and guards against ending with unresolved draft-plan or completion evidence gaps. |
326
+
332
327
  `SessionStart` exécute deux scripts ordonnés avant le début du travail :
333
328
 
334
329
  ```mermaid
@@ -386,8 +381,8 @@ Guards courants :
386
381
 
387
382
  ## Release actuelle
388
383
 
389
- - npm package : `repo-harness@0.5.1`
390
- - Generated workflow stamp : `repo-harness@0.5.1+template@0.5.1`
384
+ - npm package : `repo-harness@0.5.3`
385
+ - Generated workflow stamp : `repo-harness@0.5.3+template@0.5.3`
391
386
  - GitHub repository : `Ancienttwo/repo-harness`
392
387
  - Release history : [`docs/CHANGELOG.md`](docs/CHANGELOG.md)
393
388
 
@@ -399,6 +394,13 @@ Guards courants :
399
394
  - `scripts/inspect-project-state.ts`
400
395
  - `scripts/migrate-workflow-docs.ts`
401
396
  - `assets/workflow-contract.v1.json`
397
+ - Runtime mode is configurable with template vars:
398
+ - `{{RUNTIME_MODE}}`
399
+ - `{{RUNTIME_PROFILE}}`
400
+ - `{{RECOVERY_PROFILE}}`
401
+ - `{{STATE_PROFILE}}`
402
+ - Question-pack source of truth is in:
403
+ - `assets/initializer-question-pack.v4.json`
402
404
  - Les generated repos utilisent par défaut le repo-local harness flow :
403
405
  - `docs/spec.md -> plans/ -> tasks/contracts/ -> tasks/reviews/ -> .ai/context/context-map.json -> .ai/harness/*`
404
406
  - `repo-harness update` rafraîchit les runtime pieces utilisateur :
@@ -425,6 +427,17 @@ Merci à [Garry Tan](https://x.com/garrytan), auteur de gstack et gbrain. Ils on
425
427
  influencé le workflow de product discovery, plan/design review, release
426
428
  documentation, knowledge sync et handoff retrieval.
427
429
 
430
+
431
+ ### Attribution GitHub des contributeurs
432
+
433
+ Lorsque Codex contribue matériellement à un commit, utilisez le trailer co-author standard de GitHub à la fin du commit message :
434
+
435
+ ```text
436
+ Co-authored-by: codex <codex@openai.com>
437
+ ```
438
+
439
+ Gardez cette attribution opt-in et visible commit par commit. Ne l'intégrez pas aux scripts de commit ni aux hooks repo-harness downstream sauf si ce dépôt adopte explicitement la même politique.
440
+
428
441
  ## Action Command Skills
429
442
 
430
443
  Les command facades publics se trouvent dans `assets/skill-commands/` ; ils
@@ -469,6 +482,23 @@ bun scripts/inspect-project-state.ts --repo . --format text
469
482
  bash scripts/migrate-project-template.sh --repo . --dry-run
470
483
  ```
471
484
 
485
+
486
+ ### Runtime reference docs
487
+
488
+ Generic repo-harness runtime/reference docs live in the installed package under
489
+ `assets/reference-configs/` and are resolved through the CLI:
490
+
491
+ ```bash
492
+ repo-harness docs list
493
+ repo-harness docs path harness-overview
494
+ repo-harness docs show harness-overview
495
+ ```
496
+
497
+ Generated and migrated repos still keep `docs/reference-configs/*.md`, but
498
+ those files are deterministic pointer stubs. Repo-local workflow state,
499
+ policy, checks, runs, handoff packets, context maps, and helper snapshots stay
500
+ under `.ai/`.
501
+
472
502
  ### Template assembly
473
503
 
474
504
  ```bash
@@ -485,7 +515,23 @@ bash scripts/check-task-workflow.sh --strict
485
515
  bun scripts/inspect-project-state.ts --repo . --format text
486
516
  bash scripts/migrate-project-template.sh --repo . --dry-run
487
517
  bash scripts/check-agent-tooling.sh --host both --check-updates
488
- bun run benchmark:skills --dry-run
518
+ bun run benchmark:skills --eval route-workflow-check
519
+ ```
520
+
521
+
522
+ ### Local benchmark skeleton
523
+
524
+ ```bash
525
+ bun run benchmark:skills --eval route-workflow-check
526
+ ```
527
+
528
+ Eval output is the release/readiness evidence path; dry-run benchmark wiring is only a smoke and is not skill-effectiveness evidence.
529
+
530
+
531
+ ### Run one eval across both Claude and Codex
532
+
533
+ ```bash
534
+ bun run benchmark:skills --eval repair-agents-task-sync
489
535
  ```
490
536
 
491
537
  ## Key Files
@@ -495,8 +541,54 @@ bun run benchmark:skills --dry-run
495
541
  - Plan mapping : `assets/plan-map.json`
496
542
  - Question-pack : `assets/initializer-question-pack.v4.json`
497
543
  - Shared hooks : `assets/hooks/`
544
+ - Runtime reference docs: `assets/reference-configs/` via `repo-harness docs`
498
545
  - Workflow contract : `assets/workflow-contract.v1.json`
499
546
  - Hook operations reference : `docs/reference-configs/hook-operations.md`
500
547
  - Template assembler : `scripts/assemble-template.ts`
501
548
  - State inspector : `scripts/inspect-project-state.ts`
549
+ - External tooling detector: `scripts/check-agent-tooling.sh`
550
+ - Scaffolding scripts:
551
+ - `scripts/init-project.sh`
552
+ - `scripts/create-project-dirs.sh`
502
553
  - Legacy-doc migrator : `scripts/migrate-workflow-docs.ts`
554
+
555
+ ## Generated vs Self-Hosted Hook Parity
556
+
557
+ - Le comportement downstream des hooks est défini par la sortie générée depuis `assets/hooks/` et `assets/reference-configs/`.
558
+ - Ce repo dogfoode le même contract, mais le comportement self-host ne se synchronise pas magiquement avec les generated repos ; un changement doit mettre à jour explicitement les deux surfaces lorsque nécessaire.
559
+ - Chaque changement de hook doit dire s'il affecte `self-host`, `generated` ou `both`.
560
+
561
+ ## Package Manager Defaults
562
+
563
+ - Priorité générale par défaut : `bun > pnpm > npm`
564
+ - **Plan G/H** (Python-centric) utilise **`uv`** comme primary package manager par défaut.
565
+
566
+ ## Runtime Profiles
567
+
568
+ - `Plan-only (recommended)` (default)
569
+ - `Plan + Permissionless`
570
+ - `Standard (ask before each action)`
571
+
572
+ Configuré dans `assets/initializer-question-pack.v4.json` et consommé par `scripts/initializer-question-pack.ts`.
573
+
574
+ ## Verification
575
+
576
+ Pour la release review, utilisez le gate unique équivalent CI :
577
+
578
+ ```bash
579
+ bun run check:ci
580
+ ```
581
+
582
+ Ce gate se développe vers les checks possédés par le repo ; `bun run check:release` ajoute seulement le preflight npm unpublished-version avant de déléguer au même gate.
583
+
584
+ ```bash
585
+ bun test
586
+ bash scripts/check-deploy-sql-order.sh
587
+ bash scripts/check-architecture-sync.sh
588
+ bash scripts/check-task-sync.sh
589
+ bash scripts/check-task-workflow.sh --strict
590
+ bun scripts/inspect-project-state.ts --repo . --format text
591
+ bash scripts/migrate-project-template.sh --repo . --dry-run
592
+ bash scripts/check-agent-tooling.sh --host both --check-updates
593
+ bun run benchmark:skills --eval route-workflow-check
594
+ ```