Les décisions sont la source de vérité. L'architecture, les spécifications, les plans et l'exécution en sont des conséquences, gouvernés à travers douze principes canoniques et une unité de travail atomique.
L'artefact
À quoi ressemble un decision record
Chaque choix sur ce site est consigné comme un decision record, ou DEC. En voici un réel issu de ce dépôt, rendu tel quel.
Every response carries a security header baseline (CSP, HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy), applied at the edge by Cloudflare Pages.
Décision
Ship the baseline through public/_headers. The CSP allows only the site's real origins and rolls out report-only first, then enforces after live verification.
Résultat
Defense against clickjacking, MIME sniffing, and injected scripts, with a clear record of why each allowed origin exists.
Un DEC réel issu de ce dépôt. Le site tourne sur le framework qu'il décrit.
États du sliceplannedin-flightmergedblock
Les 12 principes canoniques
Retirez-en un seul et le résultat n'est plus SliceOps. Ils tiennent sur n'importe quel runtime, n'importe quel langage, n'importe quelle taille d'équipe.
Pourquoi
Pourquoi la construction agentique et probabiliste a besoin d'un contrôle déterministe et auditable avec une autorité humaine, pour que l'effet de levier de l'IA ne coûte jamais ni la justesse, ni la redevabilité, ni la confiance.
Comment
Les mécanismes de construction qui font tenir l'intégrité des décisions.
Quoi
La discipline rendue tangible, sans s'attacher à aucun modèle ni runtime.
Le modèle canonique
Le travail s'organise en trois niveaux structurels, plus une vue calculée à partir du graphe de dépendances.
Block
Un regroupement logique de slices au périmètre cohérent. Il se ferme par une rétrospective et calibre la vélocité ensuite, ni un sprint, ni un epic, ni un milestone.
Section
Un domaine fonctionnel à l'intérieur d'un block, le segment SEC de l'identifiant d'un slice. Stable d'un block à l'autre : le domaine est structurel, pas temporel.
Slice
L'unité de travail atomique, verticale et de bout en bout : un chat d'agent, un PR, un résultat cohérent. Ni une story, ni un ticket, ni une task.
Stage
Une vue calculée du graphe de dépendances, quels slices sont mergeables maintenant. Dérivée, jamais engagée en cérémonie. Ni un sprint ni une phase.
BL-XX.SEC-XX.SL-XXX
Chaque slice porte cet identifiant à travers sa branche, ses commits, le titre du PR et ses decision records, le fil de provenance qui relie tout le système.
Chaque interaction est une Session
Le slice est un type de Session, celui du développement, celui qui se termine par un PR. La plupart du travail avec l'IA ne produit jamais de PR, et SliceOps refuse de le laisser sans audit : chaque interaction est une Session, classifiée et à l'intérieur du plan d'audit.
slice ⊂ session, tout slice est une session ; toute session n'est pas un slice.
Huit Session-Types
SliceDéveloppement complet de bout en bout qui livre un PR.
ArtifactUne sortie bornée (un script, un template, une config ou un doc) en deçà d'un slice complet.
SupportIncidents et assistance, en interne ou face au client.
InfraOpérations d'infrastructure, de déploiement et d'environnement.
MetaGouvernance : fondations, planification, décisions de framework et de projet.
AuditVérification, contrôle et travail de compliance.
LearningExploration et recherche qui alimentent le prochain agent.
OrchestrateCoordination d'autres sessions.
Session est la treizième entité du catalogue cognitif, le modèle machine-readable sur lequel raisonnent les agents : Decision Record, Insight Record, Outcome Record, Capability, Goal, Learning Pattern, Cognitive Framework, Context Pack, Active Priority, Relationship Context, Preference, Value et Session.
Anatomie d'un slice
Un slice est la plus petite unité qui soit indépendante, testable et utile, et il porte son résultat complet avec lui.
Indépendant
Mergeable sans casser l'existant. Une seule préoccupation architecturale, s'il en couvre plusieurs, on le découpe.
Testable
Validé par au moins un test avant de pouvoir merger.
Utile
Apporte une valeur incrémentale, pas du refactor pour le refactor.
Périmètre · décision · code · tests · preuves · merge, un chat, un PR.
Un slice a deux tailles
Les confondre est l'erreur num éro un des équipes qui font tourner des agents. Un axe est le throughput, ce que vous payez. L'autre est l'empreinte de pointe, la possibilité même qu'un modèle exécute le slice.
Token-band · throughput → coût
Travail total en tokens billed-equivalent (input plus cache, pondéré par le prix), pas des totaux bruts, qui gonflent. Gouverne le forecast et le budget.
XS
< 2M tokens
S
2–5M tokens
M
5–10M tokens
L
10–20M tokens
XL
> 20M, un signal d'alerte pour découper
Context-band · empreinte de pointe → viabilité
Le maximum de contexte chargé sur un seul tour. Décide quels modèles peuvent exécuter le slice. Une fenêtre plus petite que l'empreinte ne le peut tout simplement pas.
XS
< 32K tokens
S
32–128K tokens
M
128–200K tokens
L
200–512K tokens
XL
> 512K tokens
Les axes sont orthogonaux. Un slice peut être XL-token / S-context (beaucoup d'output, petit working set) ou S-token / XL-context (peu d'output, un gros codebase à charger). Le coût et la viabilité sont des modes de défaillance distincts, ils ont besoin de bands distinctes.
Calibrées, pas inventées
Les bands ne sont pas des suppositions. Le toolkit inclut un script déterministe qui lit vos propres logs de session d'agent et calcule vos bands, mêmes logs, même script, même résultat. Recalibrez quand le paysage des modèles bouge.
Script de calibration, dans le toolkit.
Model Triage
Quel modèle doit exécuter un slice ? SliceOps y répond comme il répond à tout, de façon explicite, et sur le registre. Cinq axes, appliqués dans l'ordre des filtres :
1 · Context-band
Le filtre primaire, seuls les modèles dont la fenêtre couvre l'empreinte de pointe du slice sont éligibles.
2 · Sensibilité → localité
Les slices sensibles sont routés vers un modèle local automatiquement, jamais vers une API externe, quels que soient le coût ou la vitesse.
3 · Complexité
Le token-band et le type de slice fixent le niveau de raisonnement dont le travail a réellement besoin.
4 · Latence
Le travail interactif et le batch en arrière-plan ont des besoins de vitesse différents.
5 · Coût
Au sein de l'ensemble éligible, le modèle adéquat le moins cher l'emporte.
Chaque recommandation associe un modèle à un mode d'exécution : API frontier, local-via-API, un forfait déjà payé, ou un modèle embarqué dans l'IDE.
Compliance par construction
L'axe 2 est celui que les équipes régulées ressentent en premier. « Les données sensibles restent locales » cesse d'être une politique que vous espérez voir respectée et devient une règle de routage qui s'exécute, et le modèle, le mode et la justification sont consignés sur la session. Les outils fermés hard-codent un modèle ou routent de façon invisible ; SliceOps rend la décision explicite et auditable.
Le Context Router
Le contexte d'un codebase sérieux ne fait que croître. La question n'est pas comment en avoir besoin de moins, c'est comment bien l'utiliser. Le router ne charge que ce dont une session a réellement besoin.
Au lieu du corpus complet, il n'active que les context-experts pertinents, les décisions, entités et modules que la session touche. Il s'inspire du MoE, mais au niveau de l'orchestration : il gouverne quel contexte l'agent reçoit, pas la façon dont le modèle attend en interne.
Efficacité de synthèse
L'autre moitié, c'est la production. Un modèle qui dit la même chose en moins de tokens (sans perdre l'idée) empêche l'empreinte de demain de gonfler. La création verbeuse d'aujourd'hui est de la dette composée plus tard. Le but est une densité qui passe quand même le gate d'acceptation, pas la concision pour la concision.
C'est la Discipline de contexte (P12) rendue tangible : le contexte comme source de vérité unique et gouvernée, routée sélectivement, jamais supposée.
Preuves par construction
Chaque slice produit des preuves dans quatre catégories obligatoires, plus un gate de sécurité. Les slices sans preuves ne mergent pas.
Fonctionnel
Les tests passent.
Qualité
Linters et métriques : couverture, format, complexité.
Décision
Decision records et insight records.
Provenance
Slice ID, agent, timestamps, commit SHA.
La sécurité a son propre gate par slice : scan de secrets, SAST, vérifications de dépendances et de supply-chain, pas un audit périodique.
Le plan d'audit : les Decision Records
Aucun outil de qualité de code, moniteur de runtime ou plateforme de compliance n'audite le plan des décisions : ce qui a été décidé, par qui, pourquoi, et avec quelle chaîne de supersession. Cette couche est le coin de SliceOps.
01Chaque décision architecturale est un Decision Record avec un frontmatter qui correspond à un modèle d'entités cognitives sur lequel les agents peuvent raisonner.
02Les registres sont append-only, jamais supprimés, jamais réécrits en silence. La supersession est une arête bidirectionnelle et acyclique : le nouveau registre déclare ce qu'il remplace, l'ancien pointe vers l'avant.
03Chaque registre remonte au slice qui l'a produit et reste atteignable depuis lui.
04La CI rejette tout PR qui casse le schema, laisse une décision orpheline ou laisse une chaîne de supersession incohérente.
Cycle de vieproposed → accepted → superseded / deprecated
Stage comme vue dérivée du DAG
Les slices déclarent leurs dépendances par des arêtes explicites. Un Stage se calcule en parcourant ce graphe : le Stage N, c'est ce qui est débloqué à l'étape N. Le parallélisme découle de la topologie, pas d'une réunion de planning. Le forecast et les rétrospectives se font au niveau du block ; il n'y a pas de burndown charts ni de « nous nous sommes engagés sur N slices ce sprint ».
Quatorze gates de merge
Les R-rules canoniques (R1–R14) sont des gates de CI durs, chacune remonte à un principe. Les adopters ajoutent les leurs à partir de R15.
R1Aucun secret dans le markdown ou le YAML.
R2Aucune cross-reference cassée.
R3Frontmatter requis et valide.
R4Cohérence du registre de décisions : chaque décision citée a son registre.
R5Les transitions de cycle de vie sont atomiques : déplacement, statut et les deux arêtes de supersession dans un seul PR.
R6Aucun TODO/FIXME/HACK dans les décisions ou specs gelées.
R7Provenance des sources externes préservée.
R8Discipline SemVer : les versions du plan et de la spec avancent en lockstep.
R9Le contexte d'agent cross-repo reste synchronisé.
R10Les fichiers archivés sont immuables.
R11Classification de confidentialité présente et dans les bornes.
R12Imports restreints à un arbre de sources autorisé.
R13Le ledger de slices est mis à jour à chaque PR de clôture.
R14Aucun contenu hors du périmètre déclaré du dépôt.
La Phase 2.5 ajoute des validateurs de cohérence au-dessus des R-rules (comptes de principes, comptes d'entités, unités de token-band et un gate de coût de LLM) pour que la dérive dénormalisée ne s'accumule pas en silence. Ils arrivent comme des checks de CI drop-in dans le toolkit.
La facture de LLM est une ressource finie
Faire tourner des agents en CI coûte de l'argent réel, et le mode de défaillance est silencieux. Vous l'apprenez quand la facture tombe. SliceOps traite l'inférence comme toute autre ressource partagée : énumérée, plafonnée, sous gate. Cinq leviers :
Prompt-caching
Mettez en cache les blocs stables ; l'omettre peut laisser 40–60% du coût sur la table.
Niveau de modèle
Utilisez le niveau adéquat le moins cher ; le top-tier « au cas où » revient à peu près à 3× de pénalité sans gain.
Contexte diff-only
Envoyez le diff et quelques lignes autour ; ne récupérez le fichier entier que lorsque le raisonnement l'exige.
Minimalisme des triggers
Auditez à l'open, au reopen et au ready, pas à chaque push. La vélocité ne devrait pas multiplier la facture.
Gate de draft
Sautez les jobs coûteux sur les drafts, mais terminez en vert ; un check requis en « skipped » bloque le PR pour toujours.
Déterminisme plutôt que régénération
Si quelque chose se répète, matérialisez-le une fois (un script, un validateur, une R-rule) au lieu de demander à un modèle de le régénérer à chaque fois. Le code déterministe est moins cher, plus rapide et produit une preuve qui ne dérive pas. Faites écrire l'outil une fois par l'IA, puis réutilisez-le.
Decision-driven, pas spec-driven
Les toolchains spec-first supposent que la spec est juste dès le départ et que toute divergence est un bug. SliceOps suppose que vous apprenez pendant que vous construisez, donc la source de vérité est le corpus de décisions et de code mergé, et le registre du pourquoi la spec a changé est lui-même l'artefact qui vaut la peine d'être conservé.
Il enveloppe votre flux, il ne le concurrence pas
Spec-first, test-first, contract-first, ce sont des styles de rédaction. SliceOps est le plan de discipline autour de n'importe lequel d'entre eux. Utilisez votre flux préféré pour passer de l'intention au code ; utilisez SliceOps pour rendre l'ensemble atomique, auditable et auto-améliorant. Il se place au-dessus de Spec Kit, pas contre lui.
Acceptance-first, par convention
Convention plutôt que configuration : le défaut assumé est que chaque slice déclare ses critères d'acceptation à l'avance, idéalement sous forme de tests exécutables. Un seul artefact ancre le périmètre au début et clôt le slice comme preuve à la fin. Un défaut, pas une obligation.
Trois coins
Plan d'audit
La couche des décisions architecturales qu'aucun outil existant n'audite.
Parallélisme multi-agents
Piloté par le DAG, de cinq à treize agents simultanés comme mode de fonctionnement normal.
Ingénierie lisible par l'IA
Chaque artefact est structuré pour que le prochain agent puisse en apprendre.