Kronuz/campaign

Campagne

Le chef (la session principale) transforme les objectifs du propriétaire en quêtes. Un agent contributeur complète chaque quête sur sa propre branche ; le travail machine va dans une file d'attente de jobs qui l'exécute sur des commits exacts sans qu'aucun agent n'attende. Un agent réviseur examine une quête dans un contexte frais lorsque son risque le nécessite. campaign land place une quête sur main uniquement lorsque ses vérifications ont réussi sur ce code exact, que chaque critère dispose des preuves qu'il nomme, et que chaque revue requise a été acceptée pour le code qu'elle a vu. Tout ce qui compte est dans le dépôt, donc n'importe quel agent, y compris le chef, peut être remplacé.

goals ─► PLAN ─► quests ─► campaign start ─► contributor ─► jobs (quiet) ─► evidence
                                                  │                              │
                                                  └─► reviewer (by risk) ─► accept ─► campaign land

Invariants

1. Preuves, pas de récit. Une vérification ne compte que lorsqu'un job l'a exécutée sur le code en cours d'intégration ; une ligne de journal ou une affirmation d'un réviseur n'est jamais un test valide.
2. Un seul rédacteur par ensemble de fichiers. campaign start refuse les ensembles de fichiers qui se chevauchent ; land refuse les modifications en dehors de l'ensemble de la quête et les modifications des fichiers du chef.
3. Critères avant le code. Le chef rédige les critères d'acceptation de chaque quête et les preuves dont chacun a besoin ; les contributeurs ne les modifient jamais, et un fichier de quête modifié annule les acceptations antérieures.
4. La revue suit le risque. Un réviseur frais par risque qui en nécessite un ; une acceptation couvre le code que sa revue a vu et le contenu exact de la revue.
5. Rien ne s'affaiblit en silence. Abaisser un risque, supprimer une lentille ou une vérification, renoncer à une revue, intégrer sans CI ou enregistrer une intégration faite à la main nécessite une raison, que l'outil enregistre.
6. L'état vit dans les fichiers. .campaign/<campagne>/ et git contiennent le fonctionnement de la campagne ; ce qu'est le produit va dans docs/ du dépôt qu'il décrit.
7. Les agents n'attendent jamais les machines, et les mesures ne s'exécutent jamais sans isolation.
8. Le propriétaire décide des objectifs, du périmètre, et de toute suppression ou restriction du comportement visible par l'utilisateur. Le chef décide du reste et l'enregistre dans PLAN.md. La campagne ne loue jamais de machines ni ne crée aucune autre ressource facturable.

Rôles

Rôle	Fait	Écrit
Propriétaire (une personne)	Objectifs, non-objectifs, décisions réservées	Objectifs de PLAN.md
Chef (la session principale)	Planifie les quêtes, lance les agents, accepte les revues, intègre, rend compte au propriétaire	state.json (uniquement via campaign), fichiers de quête, PLAN.md, main
Contributeur (agent campaign-contributor)	Une quête ou une tâche, selon son affectation	Sa branche et son journal
Réviseur (agent campaign-reviewer)	Une quête à travers une lentille, depuis un contexte frais	Un fichier de revue

L'affectation d'un contributeur nomme le type de travail ; chacun, sauf l'implémentation, a une méthode dans references/assignments/<nom>.md. Le chef nomme l'affectation, le niveau de modèle et l'effort à chaque lancement, en choisissant selon le travail, jamais par habitude :

Affectation	Pour	Niveau, effort
implémentation	fonctionnalités et correctifs avec des critères concrets	économique, moyen pour risque faible et normal ; fort, élevé pour risque élevé et critique, ou après qu'une tentative économique ait calé
conception	listes de quêtes pour des plans conséquents ; formats, protocoles, durabilité, concurrence	fort, élevé ; max pour une conception sur le point de geler
recherche	rarement : le mécanisme lui-même est la limite	fort, max
performance	profilage et optimisation	fort, élevé
exploration	une cible d'un lot d'exploration, ou une question rapide	économique, moyen
documentation	docs, guides, READMEs	économique, moyen
maintenance	un changement mécanique à travers les dépôts	économique, moyen

Les réviseurs utilisent le niveau fort avec un effort élevé (max pour les quêtes critiques) ; pour les quêtes critiques et le défi du plan, un réviseur d'une autre famille de modèles lorsque le harnais en propose un. Les modèles de chaque harnais pour les niveaux se trouvent dans references/harness.md. Modifiez une valeur par défaut en fonction des résultats (campaign usage, critères satisfaits, reprise), jamais uniquement sur le prix. Le chef effectue lui-même les petites modifications (un correctif de cinq lignes, un conflit trivial) : un lancement coûte plus cher.

Démarrer une campagne

1. Dans le checkout principal du dépôt d'origine : campaign init --name NOM [--ci github]. Le propriétaire rédige les Objectifs, Non-objectifs, Contraintes et Décisions réservées dans .campaign/<campagne>/PLAN.md.
2. Décomposez les objectifs en quêtes : campaign new ID --title T --risk R --files GLOBS [--needs IDS] [--after IDS] [--provides C] [--consumes C] [--milestone M] --check NOM[:NIVEAU[:MIN]]=CMD. Remplissez chaque fichier de quête (.campaign/<campagne>/quests/ID.md) : résultat, critères A1... chacun avec les preuves dont il a besoin (Preuves, ci-dessous), contrats, décisions, ce qui peut être intégré tôt.
3. Lorsque l'architecture est conséquente, un réviseur (lentille design) conteste le plan et la liste des quêtes avant que quoi que ce soit ne soit construit. C'est la seule revue qui vaille la peine d'attendre.

Quêtes

• Taille : le plus petit changement qui apporte un comportement complet et significatif qu'un réviseur peut garder à l'esprit, généralement de quelques centaines à environ 1 500 lignes. Divisez les plus grandes ; pliez un changement qui ne vaut pas sa propre intégration dans la quête qu'il sert.
• needs doit être intégré avant qu'une quête ne commence ; after doit être intégré avant qu'elle ne soit intégrée. Une quête peut commencer par rapport à une dépendance after uniquement parce que le fichier de quête de cette dépendance fixe le contrat.
• Contrats (--provides, --consumes) nomment les API, formats et protocoles, afin que campaign check voie deux quêtes en toucher un.
• Tâches : rédacteurs parallèles au sein d'une quête (campaign start ID --task T --files GLOBS), fusionnés dans la branche de quête par le chef. La quête est toujours examinée une fois.
• Incréments : campaign land ID --upto COMMIT --reason R intègre un préfixe que la section « Peut être intégré tôt » du fichier de quête autorise (refactorisations préservant le comportement, tests, API internes inutilisées, code derrière un commutateur désactivé). Jamais tôt : les octets sur le disque ou le réseau, l'API publique, le comportement visible par l'utilisateur, ou la partie pour laquelle la revue existe.
• Travail multi-dépôts correspond à plusieurs quêtes (--repo CHEMIN) ordonnées par after, avec un job d'intégration qui épingle le commit de chaque dépôt (--ref NOM=CHEMIN@REF). L'intégration est ordonnée, jamais atomique : chaque état intermédiaire doit fonctionner.
• Messages : un agent qui a une constatation pour une quête sur laquelle il ne travaille pas, dans toute campagne sur la machine, envoie campaign message NOM:ID "texte" --from QUI. La quête ne peut pas être intégrée tant que l'un de ses journaux n'y a pas répondu par son identifiant (msg-N) ou que le chef ne l'a pas fermée (campaign message ID --close msg-N --reason R) ; NOM: écrit au chef de cette campagne et ne bloque jamais une intégration. Détails et autres machines : references/host.md, Messages.
• Changements de périmètre : une nouvelle demande va d'abord dans le fichier de quête (un critère, ou sa propre quête si elle peut être intégrée seule), puis au contributeur ; le travail remplacé est campaign set ID status=dropped reason=....

Chemin direct d'abord

Seulement ce qui décide de la prochaine étape la bloque. Les vérifications de porte d'une quête (--check : le build, les tests et les preuves requises par son risque) bloquent son intégration. Ses vérifications différées (--later : autres plateformes, trempages longs, matrices complètes, fuzzing étendu) sont mises en file d'attente à faible priorité sur le code intégré et doivent être réussies avant la fermeture du jalon. Une vérification en échec est une erreur dans campaign check : corrigez en avant ou annulez, puis campaign verify ID --deferred les relance sur main. Les preuves dont un risque élevé ou critique a besoin (TSan pour la concurrence, fuzzing pour un décodeur, le modèle de crash pour la durabilité) sont toujours une porte. Les workflows CI lents peuvent être rendus non-bloquants de la même manière (campaign config ci_later=NOM,...).

Exécuter une quête

1. campaign start ID crée quest/<campagne>/ID dans son propre espace de travail avec un journal. Lancez un contributeur en arrière-plan, afin qu'il puisse être repris par message, avec l'invite « Contributeur » (references/prompts.md) ; exécutez les quêtes en parallèle uniquement lorsqu'elles sont prêtes, disjointes et n'attendent pas sur la même machine.
2. Le contributeur travaille dans son espace de travail, tient son journal à jour et produit des preuves sous forme de jobs : campaign job submit --quest ID --level L --minutes M -- CMD et campaign verify ID. Lorsqu'il ne reste que des jobs, il enregistre leurs identifiants et met fin à son tour.
3. Le chef attend avec un campaign wait --commits en arrière-plan (pas de jetons jusqu'à ce qu'un job se termine, qu'une branche bouge ou qu'un message arrive), puis reprend le contributeur par message pendant que son contexte est petit (environ 150 000 jetons). Un contexte plus grand, ou un harnais qui ne peut pas le reprendre, obtient un nouveau contributeur avec l'invite « Reprendre », qui reconstruit à partir du journal et des enregistrements de jobs.
4. Lorsque le journal indique « prêt pour la revue », le chef définit status=review et lance les réviseurs requis par le risque ; chacun écrit .campaign/<campagne>/reviews/ID-LENTILLE.md. Le chef relaie les constatations bloquantes au contributeur par identifiant.
5. campaign accept ID LENTILLE une fois qu'une revue approuve, ou après CHANGEMENTS avec les jobs de confirmation (Risque et revue) ; il valide le fichier de revue avec l'acceptation. Ensuite campaign land ID, qui supprime également les espaces de travail de la quête, les branches fusionnées et l'emplacement de build, et nomme ce qui a été conservé.

Lots d'exploration

Pour une liste qui vaut la peine d'être explorée (les lignes perdantes d'un benchmark frais, les points chauds d'un profil, du code faiblement prouvé, un arriéré de petits bugs), envoyez plusieurs contributeurs économiques à la fois, une cible chacun, les cibles provenant d'une mesure fraîche sur le main actuel : references/assignments/exploration.md. Taille du lot en fonction de ses cibles et de ce que le chef peut examiner et intégrer, jamais en fonction d'un quota inactif.

Risque et revue

Risque (la première correspondance gagne)	Avant de construire	Avant l'intégration finale
critique : irréversible (geler un format ou un protocole pour une version, migrer les données des utilisateurs, supprimer un comportement visible par l'utilisateur)	approbation du propriétaire ; une revue design	la revue à haut risque, plus les preuves d'acceptation que le réviseur a lui-même exécutées
élevé : formats persistants, protocoles réseau, durabilité, concurrence, surfaces de sécurité, API publiques partagées	une revue design lorsqu'une décision est coûteuse à annuler	une revue par la lentille du risque dominant (durability, security ou correctness)
normal : fonctionnalités et correctifs ordinaires	—	une revue correctness, ou --waive RAISON pour un petit changement avec des preuves solides
faible : docs, tests, outils, modifications mécaniques, refactorisations préservant le comportement	—	vérifications vertes ; le chef lit le diff

• Un réviseur par défaut, portant chaque question de risque que la quête soulève (l'invite en nomme trois à cinq). Un second uniquement pour une question qui nécessite une expertise ou une indépendance séparée.
• Une revue est liée à ce qu'elle a vu. Elle nomme le commit qu'elle a examiné (Commit:), un verdict et un tableau de constatations avec un ID, Bloquant (oui ou non) et Type (défaut, lacune, détail) par ligne. Un APPROUVE couvre le code de ce commit ; les commits qui ne touchent que .campaign/ le conservent. Modifier la revue après acceptation annule l'acceptation.
• Les correctifs sont confirmés par des jobs, pas par de nouvelles revues. Pour chaque constatation bloquante, réexécutez sa sonde ou le nouveau test en tant que job sur le commit corrigé, puis campaign accept ID LENTILLE --confirm C1=JOB --confirm C2=JOB. Un job ne confirme que s'il a réussi sur le code accepté dans le dépôt de la quête ; un défaut bloquant nécessite du code modifié ; l'outil enregistre si la même sonde a échoué sur le commit examiné. Un correctif qui modifie des fichiers que la revue n'a jamais vus revient au réviseur (la revue nomme le commit corrigé et approuve), sauf si --fix-scope RAISON explique pourquoi il n'ajoute aucun mécanisme (un test de régression pour une constatation).
• Deux tours de correction, puis arrêtez. Un troisième signifie que la quête ou la conception est erronée : re-planifiez ou demandez au propriétaire. Les constatations non bloquantes deviennent une quête de suivi ou sont abandonnées avec une raison.
• Une conception est examinée une fois. Résolvez un comportement contesté avec un modèle exécutable ou un test, pas un autre échange de texte.
• Ce qu'une quête doit réussir ne change que sur enregistrement : campaign set ID ... --weaken RAISON abaisse son risque, supprime une lentille, ou supprime, modifie ou reporte une vérification ; le changement est conservé dans son historique, affiché par campaign status ID, et annule ses acceptations. La revue dont un risque a besoin (une revue de code au-dessus de faible, une revue de conception pour critique) ne peut pas être supprimée, et une renonciation est refusée une fois qu'une revue existe.
• Revue système sur événements, pas sur un calendrier : lorsque campaign check signale deux quêtes modifiant un même fichier ou un même contrat, demandez à un réviseur (lentille system) cette question spécifique.
• Rendement : campaign status --reviews compte les verdicts et les défauts bloquants. Une revue facultative (risque normal) qui ne trouve rien de substantiel après environ cinq quêtes d'un type est abandonnée pour ce type ; les revues élevées et critiques ne sont jamais abandonnées en raison du rendement.

Preuves

Chaque critère dans un fichier de quête nomme les preuves dont il a besoin ; le tableau des Preuves du journal donne une ligne par critère, et l'intégration vérifie chaque ligne sur le code en cours d'intégration :

Critère	Sa ligne doit nommer
- A1 ... (sans étiquette)	un job qui a réussi sur ce code (lui-même, ou le même job relancé)
- A2 [artifact] ...	un chemin validé dans le dépôt de la quête
- A3 [decision] ...	un identifiant dans le tableau des Décisions de PLAN.md
- A4 [manual] ...	qui a vérifié quoi, à la main ; affiché comme manuel, jamais comme preuve automatisée

La preuve est proportionnelle à l'affirmation (references/review.md) : les tests vérifient les valeurs, pas les comptages ; un correctif a un test qui échoue sans lui ; une affirmation a un mutant qu'un test tue ; les sanitizers dans des builds séparés. Les affirmations de performance suivent references/measurement.md : avant et après sur des commits nommés, exclusive pour les nombres qui décident quoi que ce soit, magnitude honnête.

Travail machine

Niveau	Pour	Isolation (quiet)
none	petites sondes monothread	pas de retenue
light	builds, suites de tests, fuzzing	quelques-uns à la fois, nice 19
strict	timings de fumée, exécutions comportementales	ses propres cœurs sous Linux ; seul sous macOS
exclusive	nombres qui comptent	un seul utilisateur du socket ;