spec-lite — spec local durable + docs synchronisés par change

Une sous-procédure partagée pour les skills de la phase Chorus (proposal, develop, yolo) — le mode spec léger, modelé sur les superpowers (un spec durable qui persiste, plus des artefacts par effort) : un spec local durable par capability (.chorus/specs/<slug>/spec.md, édité sur place, jamais synchronisé — l'historique git est son 留痕), plus un dossier daté par change (.chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/ de docs typés Chorus — prd.md, … — qui sont mirrorés 1:1 dans les Chorus Documents persistants). Aucune CLI neuve, aucun tool MCP, backend, ou schéma — le mirroring réutilise les document tools existants.

Mode (comment tu es arrivé ici)

Le mode spec est calculé par le hook SessionStart (bin/resolve-spec-mode.sh), pas par toi — la section ## Spec Mode de ton contexte indique le CHORUS_SPEC_MODE résolu. Tu es ici parce qu'il s'est résolu en lite ; s'il est autre chose, ce skill est un no-op — retour à l'appelant. (Pour mémoire, la règle du hook : un CHORUS_SPEC_MODE explicite gagne, sinon OpenSpec si utilisable, sinon lite.)

Le spec local durable — `<slug>/spec.md`

.chorus/specs/<slug>/spec.md — <slug> (kebab-case) nomme une capability/feature, pas une seule change. C'est l'unique, cumulatif, source de vérité humaine "actuelle" de la capability : édité sur place par chaque change, jamais mirroré dans Chorus, porte aucun id Chorus. Frontmatter minimal seulement (slug, title, status: draft|active|done, created), puis prose naturelle — ## Intent, ## Requirements (prose + - [ ] points d'acceptance, pas de grammaire SHALL/scenario), ## Non-goals. Commence par le template inline spec.md durable ci-dessous. Son historique git est le registre complet — pas de section changelog, pas d'aller-retour Chorus. Ce fichier N'ENTRE JAMAIS dans la boucle mirror.

status décrit la capability, pas une seule change : active tant qu'une change est en vol, done quand la change actuelle est livrée et aucune n'est ouverte. Une nouvelle change contre une capability done la rouvre en active, retour à done à la livraison.

Template — le `spec.md` durable

---
slug: <kebab-case-capability>
title: <Capability title>
status: draft            # draft | active | done
created: <YYYY-MM-DD>
---

## Intent
<what this capability is for, in prose>

## Requirements
<prose, no SHALL/scenario grammar>
- [ ] <acceptance point>

## Non-goals
- <explicitly out of scope>

Dossiers datés par change — `<slug>/<YYYY-MM-DD>-<change-slug>/`

Chaque change est un dossier daté directement sous <slug>/ (pas de wrapper changes/), ex. .chorus/specs/<slug>/2026-09-08-add-export/. Date + slug pour que les changes du même jour ne collisionnent pas et que les dossiers se trient par date. Il contient les docs typés Chorus pour CETTE change — un fichier par type Document :

Fichier	`Document.type`	Requis ?
`prd.md`	`prd`	oui — le doc primaire par change
`tech_design.md`	`tech_design`	optionnel — le "comment"
`adr.md` / `guide.md` / `spec.md`	`adr` / `guide` / `spec`	optionnel

Ces fichiers SONT synchronisés — chacun mappe sur un Chorus Document persistant de son type. Leur frontmatter porte les ids de sync proposalUuid et documentUuid (le type est implicite dans le nom du fichier). Commence par le template document dossier-daté inline ci-dessous. Une change différente à la même capability est un dossier daté différent. Le dossier de la change actuelle est édité et re-mirroré tout au long de son effort (jusqu'à livraison) ; seuls les dossiers datés précédemment livrés restent gelés — tu ne reviens pas réécrire une change passée.

Deux fichiers nommés spec.md, rôles différents. Le <slug>/spec.md durable (local seulement, sans ids) N'EST PAS le même qu'un doc de type spec par change, qui vivrait à <slug>/<date>-<slug>/spec.md (synchronisé, porte des ids). Préfère prd.md comme doc primaire par change pour éviter la confusion.

Template — un document dossier-daté

Le type est implicite dans le nom du fichier (prd.md → prd, tech_design.md → tech_design, …), PAS une clé frontmatter.

---
title: <Document title as it appears in Chorus>
proposalUuid: <uuid>      # written on first mirror
documentUuid:             # empty until the draft materializes on approval
---

# <Document title>
<body — this file's bytes are the source of truth for the Chorus Document>

Flow (une change)

Confirme mode = lite (sinon no-op).
Crée le dossier daté <slug>/<YYYY-MM-DD>-<change-slug>/ et écris ses docs change synchronisés — prd.md (requis), tech_design.md etc. seulement si justifié (utilise le template document dossier-daté ci-dessus).
Mets à jour <slug>/spec.md sur place à la nouvelle vérité cumulative (Requirements, points d'acceptance, status) — local seulement, pas de sync.
Crée le conteneur proposal avec une ligne locator littérale dans description (ligne propre, sans ponctuation finale) pour que develop trouve la change : Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/
Mirrorize les docs du dossier daté dans Chorus (ci-dessous). Ajoute les tâches via chorus_pm_add_task_draft — pas de tasks.md, pas de CLI / validate / archive, pas de grammaire delta. Les tâches vivent dans Chorus.
Develop → continue d'éditer spec.md + les docs change, re-mirrorize les docs change à mesure que le travail arrive et coche les points d'acceptance. À la livraison, définis le status: done du spec.md durable.

Mirror — seulement les docs dossier-daté (jamais `spec.md`)

Chaque <type>.md dossier-daté mappe sur un Chorus Document persistant de ce type, suivi par documentUuid dans le frontmatter du fichier. Remplis content depuis les bytes du fichier avec --arg-file — ne retape jamais le body (dérive, brûle ~20k tokens). Un appel par fichier ; résous l'identité par documentUuid / (proposalUuid, type), jamais par title seul (une lookup trouvant zéro ou >1 DOIT halter). Garde chaque appel avec le helper halt-on-error chorus_check_response (openspec-aware §6). Pas de chorus sur PATH ? Bascule vers chorus-api.sh + json_encode_file (openspec-aware §3.6). <slug>/spec.md N'EST JAMAIS dans cette boucle.

Première fois qu'un doc est écrit (son dossier daté est nouveau) : écris proposalUuid dans le frontmatter, mirrorize dans un proposal draft — chorus mcp call chorus_pm_add_document_draft "{\"proposalUuid\":\"$P\",\"type\":\"prd\",\"title\":\"PRD: $TITLE\"}" --arg-file content=".chorus/specs/$SLUG/$DATED/prd.md". Édite le draft via chorus_pm_update_document_draft (returned draftUuid) avant approbation. À l'approbation, il se matérialise en Document persistant — résous par (proposalUuid, type) via chorus_get_documents, enregistre documentUuid dans le frontmatter, re-mirrorize une fois pour que local == Chorus.
Édits ultérieurs (un doc qui a déjà un documentUuid) : édite le fichier, puis chorus mcp call chorus_pm_update_document "{\"documentUuid\":\"$D\"}" --arg-file content=".chorus/specs/$SLUG/$DATED/<type>.md". Chaque mise à jour auto-incrémente la version du Document — cet historique de versions est le registre du doc change dans Chorus, aux côtés de git.

留痕: historique git + versions Document

git log -- .chorus/specs/$SLUG/ est la piste d'audit — les diffs du spec.md durable sur place plus les docs change de chaque dossier daté ; les versions auto-incrémentées des Documents mirrorés sont le registre parallèle dans Chorus. Aucune section changelog à maintenir. Seul .chorus/specs/ est version-controlé (.chorus/* + !.chorus/specs/).

Single-writer : le dossier est partagé — dans une vague multi-tâche seul l'orchestrator / agent principal édite + re-mirrorize ; les workers parallèles rapportent via chorus_report_work seulement, relisant avant toute écriture. L'état de tâche vit dans Chorus, pas les docs — les points - [ ] sont intention d'acceptance, pas un tracker.

spec-lite — spec local durable + docs synchronisés par change

Mode (comment tu es arrivé ici)

Le spec local durable — <slug>/spec.md

Template — le spec.md durable

Dossiers datés par change — <slug>/<YYYY-MM-DD>-<change-slug>/