Entscheidungen sind die Quelle der Wahrheit. Architektur, Specs, Pläne und Ausführung sind ihre Konsequenzen, gesteuert über zwölf kanonische Prinzipien und eine atomare Arbeitseinheit.
Das Artefakt
Wie ein Decision Record aussieht
Jede Entscheidung auf dieser Website wird als Decision Record, oder DEC, festgehalten. Dies ist ein echter aus diesem Repository, unverändert dargestellt.
Every response carries a security header baseline (CSP, HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy), applied at the edge by Cloudflare Pages.
Entscheidung
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.
Ergebnis
Defense against clickjacking, MIME sniffing, and injected scripts, with a clear record of why each allowed origin exists.
Ein echter DEC aus diesem Repository. Die Website läuft auf dem Framework, das sie beschreibt.
Slice-Zuständeplannedin-flightmergedblock
Die 12 kanonischen Prinzipien
Nehmen Sie eines weg, und das Ergebnis ist nicht mehr SliceOps. Sie gelten auf jeder Runtime, in jeder Sprache, bei jeder Teamgröße.
Warum
Warum agentische, probabilistische Konstruktion deterministische, auditierbare Kontrolle mit menschlicher Autorität braucht, damit KI-Hebelwirkung nie Korrektheit, Rechenschaft oder Vertrauen kostet.
Wie
Die Konstruktionsmechanismen, die die Integrität der Entscheidungen tragen.
Was
Die Disziplin greifbar gemacht, an kein Modell, keine Runtime gebunden.
Das kanonische Modell
Arbeit ist in drei strukturelle Ebenen organisiert, plus eine Sicht, die aus dem Abhängigkeitsgraphen berechnet wird.
Block
Eine logische Gruppierung von Slices mit kohärentem Umfang. Er schließt mit einer Retrospektive und kalibriert die Velocity danach, kein Sprint, Epic oder Milestone.
Section
Eine funktionale Domäne innerhalb eines Blocks, das SEC-Segment der Kennung eines Slice. Stabil über Blocks hinweg: Die Domäne ist strukturell, nicht zeitlich.
Slice
Die atomare, vertikale, durchgängige Arbeitseinheit: ein Agenten-Chat, ein PR, ein zusammenhängendes Ergebnis. Keine Story, kein Ticket, keine Task.
Stage
Eine berechnete Sicht auf den Abhängigkeitsgraphen, welche Slices jetzt mergebar sind. Abgeleitet, nie in einer Zeremonie zugesagt. Kein Sprint und keine Phase.
BL-XX.SEC-XX.SL-XXX
Jeder Slice trägt diese Kennung durch seinen Branch, seine Commits, seinen PR-Titel und seine Decision Records, der Herkunftsfaden, der das ganze System zusammenbindet.
Jede Interaktion ist eine Session
Der Slice ist eine Art von Session, die Entwicklungsart, die in einem PR endet. Die meiste KI-Arbeit erzeugt nie einen PR, und SliceOps weigert sich, sie unauditiert zu lassen: Jede Interaktion ist eine Session, klassifiziert und innerhalb der Audit-Ebene.
slice ⊂ session, jeder Slice ist eine Session; nicht jede Session ist ein Slice.
Acht Session-Types
SliceVollständige durchgängige Entwicklung, die einen PR liefert.
ArtifactEin begrenztes Ergebnis (ein Skript, Template, eine Config oder ein Doc), unterhalb eines vollständigen Slice.
SupportVorfälle und Betreuung, intern oder kundenseitig.
InfraInfrastruktur-, Deploy- und Umgebungsoperationen.
MetaGovernance: Grundlagen, Planung, Framework- und Projektentscheidungen.
AuditVerifikation, Kontrolle und Compliance-Arbeit.
LearningExploration und Recherche, die den nächsten Agenten speist.
OrchestrateKoordination anderer Sessions.
Session ist die dreizehnte Entität im kognitiven Katalog, dem maschinenlesbaren Modell, über das Agenten schlussfolgern: Decision Record, Insight Record, Outcome Record, Capability, Goal, Learning Pattern, Cognitive Framework, Context Pack, Active Priority, Relationship Context, Preference, Value und Session.
Anatomie eines Slice
Ein Slice ist die kleinste Einheit, die unabhängig, testbar und nützlich ist, und er trägt sein gesamtes Ergebnis mit sich.
Unabhängig
Mergebar, ohne das Bestehende zu zerbrechen. Nur ein einziges architektonisches Anliegen, umfasst er mehr, teilen Sie ihn auf.
Testbar
Vor dem Merge durch mindestens einen Test validiert.
Nützlich
Fügt inkrementellen Wert hinzu, kein Refactoring um seiner selbst willen.
Umfang · Entscheidung · Code · Tests · Nachweise · Merge, ein Chat, ein PR.
Ein Slice hat zwei Größen
Sie zu verwechseln ist der häufigste Fehler von Teams, die Agenten betreiben. Eine Achse ist Durchsatz, was Sie zahlen. Die andere ist der Spitzenbedarf, ob ein Modell den Slice überhaupt ausführen kann.
Token-Band · Durchsatz → Kosten
Gesamtarbeit in abrechnungsäquivalenten Tokens (Input plus Cache, nach Preis gewichtet), keine Rohsummen, die aufblähen. Steuert Prognose und Budget.
XS
< 2M Tokens
S
2–5M Tokens
M
5–10M Tokens
L
10–20M Tokens
XL
> 20M, ein Warnsignal zum Aufteilen
Context-Band · Spitzenbedarf → Machbarkeit
Der größte Kontext, der in einem einzelnen Turn geladen wird. Entscheidet, welche Modelle den Slice überhaupt ausführen können. Ein Fenster, das kleiner ist als der Bedarf, kann es schlicht nicht.
XS
< 32K Tokens
S
32–128K Tokens
M
128–200K Tokens
L
200–512K Tokens
XL
> 512K Tokens
Die Achsen sind orthogonal. Ein Slice kann XL-Token / S-Context sein (viel Output, kleines Working Set) oder S-Token / XL-Context (wenig Output, eine große Codebase zu laden). Kosten und Machbarkeit sind unterschiedliche Fehlermodi, sie brauchen unterschiedliche Bands.
Kalibriert, nicht erfunden
Die Bands sind keine Schätzungen. Das Toolkit liefert ein deterministisches Skript, das Ihre eigenen Agenten-Session-Logs liest und Ihre Bands berechnet, dieselben Logs, dasselbe Skript, dasselbe Ergebnis. Rekalibrieren Sie, wenn sich die Modelllandschaft verschiebt.
Kalibrierungsskript, im Toolkit.
Model Triage
Welches Modell sollte einen Slice ausführen? SliceOps beantwortet das so, wie es alles beantwortet, explizit und dokumentiert. Fünf Achsen, in Filterreihenfolge angewendet:
1 · Context-Band
Der primäre Filter, nur Modelle, deren Fenster den Spitzenbedarf des Slice fasst, sind überhaupt zulässig.
2 · Sensitivität → Lokalität
Sensible Slices werden automatisch an ein lokales Modell geleitet, nie an eine externe API, ungeachtet von Kosten oder Geschwindigkeit.
3 · Komplexität
Token-Band und Slice-Typ legen die Reasoning-Stufe fest, die die Arbeit tatsächlich braucht.
4 · Latenz
Interaktive Arbeit und Hintergrund-Batch haben unterschiedliche Geschwindigkeitsanforderungen.
5 · Kosten
Innerhalb der zulässigen Menge gewinnt das günstigste angemessene Modell.
Jede Empfehlung paart ein Modell mit einem Ausführungsmodus: Frontier-API, lokal-via-API, ein bereits bezahlter Pauschalplan oder ein in die IDE eingebettetes Modell.
Compliance durch Konstruktion
Achse 2 ist diejenige, die regulierte Teams als Erstes spüren. „Sensible Daten bleiben lokal“ ist nicht länger eine Richtlinie, von der Sie hoffen, dass die Leute sie befolgen, sondern wird zu einer Routing-Regel, die ausgeführt wird, und das Modell, der Modus und die Begründung werden auf der Session festgehalten. Geschlossene Werkzeuge codieren ein Modell hart oder routen unsichtbar; SliceOps macht die Entscheidung explizit und auditierbar.
Der Context Router
Der Kontext einer ernsthaften Codebase wächst nur. Die Frage ist nicht, wie man weniger davon braucht, sondern wie man ihn gut nutzt. Der Router lädt nur das, was eine Session tatsächlich braucht.
Statt des gesamten Korpus aktiviert er nur die relevanten Context-Experts, die Entscheidungen, Entitäten und Module, die eine Session berührt. Er ist MoE-inspiriert, aber auf der Orchestrierungsebene: Er steuert, welchen Kontext der Agent erhält, nicht wie das Modell intern aufmerksam ist.
Synthese-Effizienz
Die andere Hälfte ist die Produktion. Ein Modell, das dasselbe in weniger Tokens sagt (ohne die Idee zu verlieren), verhindert, dass der Bedarf von morgen aufbläht. Wortreiche Erstellung heute ist später kumulierende Schuld. Das Ziel ist Dichte, die das Akzeptanz-Gate noch besteht, nicht Knappheit um ihrer selbst willen.
Das ist Kontextdisziplin (P12) greifbar gemacht: Kontext als gesteuerte, einzige Quelle der Wahrheit, selektiv zugeführt, nie angenommen.
Nachweise durch Konstruktion
Jeder Slice erzeugt Nachweise in vier verpflichtenden Kategorien, plus einem Security-Gate. Nicht nachgewiesene Slices werden nicht gemerged.
Funktional
Die Tests bestehen.
Qualität
Linter und Metriken: Coverage, Format, Komplexität.
Entscheidung
Decision Records und Insight Records.
Herkunft
Slice-ID, Agent, Zeitstempel, Commit-SHA.
Security ist ihr eigenes Gate pro Slice: Secrets-Scan, SAST, Abhängigkeits- und Supply-Chain-Prüfungen, kein periodisches Audit.
Die Audit-Ebene: Decision Records
Kein Werkzeug für Code-Qualität, kein Runtime-Monitor und keine Compliance-Plattform auditiert die Entscheidungsebene: was entschieden wurde, von wem, warum und mit welcher Supersession-Kette. Diese Ebene ist der Hebel von SliceOps.
01Jede architektonische Entscheidung ist ein Decision Record mit Frontmatter, das auf ein kognitives Entitätsmodell abbildet, über das Agenten schlussfolgern können.
02Records sind append-only, werden nie gelöscht und nie im Stillen umgeschrieben. Supersession ist eine bidirektionale, azyklische Kante: Der neue Record deklariert, was er ersetzt, der alte verweist nach vorn.
03Jeder Record führt zurück auf den Slice, der ihn erzeugt hat, und bleibt von ihm aus erreichbar.
04Die CI weist jeden PR zurück, der das Schema bricht, eine Entscheidung verwaisen lässt oder eine Supersession-Kette inkonsistent hinterlässt.
Slices deklarieren ihre Abhängigkeiten mit expliziten Kanten. Ein Stage wird durch das Durchlaufen dieses Graphen berechnet: Stage N ist alles, was im Schritt N entsperrt ist. Parallelität ergibt sich aus der Topologie, nicht aus einem Planungsmeeting. Prognose und Retrospektiven finden auf Block-Ebene statt; es gibt keine Burndown-Charts und kein „wir haben uns in diesem Sprint auf N Slices verpflichtet“.
Vierzehn Merge-Gates
Die kanonischen R-Rules (R1–R14) sind harte CI-Gates, jede führt zurück auf ein Prinzip. Anwender fügen ab R15 ihre eigenen hinzu.
R1Keine Secrets in Markdown oder YAML.
R2Keine gebrochenen Querverweise.
R3Frontmatter erforderlich und gültig.
R4Konsistenz des Entscheidungsregisters: Jede zitierte Entscheidung hat einen Record.
R5Lifecycle-Übergänge sind atomar: Verschieben, Status und beide Supersession-Kanten in einem PR.
R6Kein TODO/FIXME/HACK in eingefrorenen Entscheidungen oder Specs.
R7Herkunft externer Quellen bewahrt.
R8SemVer-Disziplin: Plan- und Spec-Versionen bewegen sich im Gleichschritt.
R11Vertraulichkeitsklassifizierung vorhanden und im zulässigen Bereich.
R12Imports auf einen autorisierten Quellbaum beschränkt.
R13Das Slice-Ledger wird bei jedem abschließenden PR aktualisiert.
R14Keine Inhalte außerhalb des deklarierten Umfangs des Repos.
Phase 2.5 fügt Kohärenz-Validatoren über die R-Rules hinzu (Prinzipienzählungen, Entitätszählungen, Token-Band-Einheiten und ein LLM-Kosten-Gate), damit denormalisierter Drift sich nicht im Stillen anhäufen kann. Sie kommen als einsatzfertige CI-Checks im Toolkit.
Die LLM-Rechnung ist eine endliche Ressource
Agenten in der CI zu betreiben kostet echtes Geld, und der Fehlermodus ist still. Sie erfahren es, wenn die Rechnung eintrifft. SliceOps behandelt Inferenz wie jede andere geteilte Ressource: aufgezählt, gedeckelt, gegated. Fünf Hebel:
Prompt-Caching
Cachen Sie stabile Blöcke; es zu überspringen kann 40–60 % der Kosten liegen lassen.
Modell-Tier
Nutzen Sie das günstigste angemessene Tier; Top-Tier „für alle Fälle“ ist etwa eine 3×-Strafe ohne Gewinn.
Diff-only-Kontext
Senden Sie das Diff und ein paar Zeilen drumherum; holen Sie die ganze Datei nur, wenn das Reasoning sie braucht.
Trigger-Minimalismus
Auditieren bei open, reopen und ready, nicht bei jedem Push. Velocity sollte die Rechnung nicht vervielfachen.
Draft-Gate
Überspringen Sie teure Jobs bei Drafts, aber schließen Sie grün ab; ein übersprungener erforderlicher Check blockiert den PR für immer.
Determinismus statt Regeneration
Wenn sich etwas wiederholt, materialisieren Sie es einmal (ein Skript, einen Validator, eine R-Rule), statt ein Modell zu bitten, es jedes Mal neu zu erzeugen. Deterministischer Code ist günstiger, schneller und erzeugt Nachweise, die nicht abdriften. Lassen Sie die KI das Werkzeug einmal schreiben und nutzen Sie es dann wieder.
Decision-driven, nicht spec-driven
Spec-first-Toolchains nehmen an, die Spec sei von vornherein richtig und jede Abweichung ein Bug. SliceOps nimmt an, dass Sie beim Bauen lernen, also ist die Quelle der Wahrheit das Korpus aus Entscheidungen und gemergtem Code, und der Record, warum sich die Spec geändert hat, ist selbst das Artefakt, das es aufzubewahren lohnt.
Es umhüllt Ihren Flow, es konkurriert nicht
Spec-first, test-first, contract-first, das sind Autorenstile. SliceOps ist die Disziplin-Ebene um jeden von ihnen herum. Nutzen Sie Ihren bevorzugten Flow, um von der Absicht zum Code zu gelangen; nutzen Sie SliceOps, um das Ganze atomar, auditierbar und selbstverbessernd zu machen. Es sitzt auf Spec Kit auf, nicht gegen es.
Acceptance-first, per Konvention
Konvention vor Konfiguration: Der vorgegebene Standard ist, dass jeder Slice seine Akzeptanzkriterien im Voraus deklariert, idealerweise als ausführbare Tests. Ein Artefakt verankert den Umfang am Anfang und schließt den Slice am Ende als Nachweis ab. Ein Standard, kein Mandat.
Drei Hebel
Audit-Ebene
Die Ebene architektonischer Entscheidungen, die kein bestehendes Werkzeug auditiert.
Multi-Agenten-Parallelität
DAG-getrieben, fünf bis dreizehn gleichzeitige Agenten als normaler Betriebsmodus.
KI-lesbare Entwicklung
Jedes Artefakt ist so strukturiert, dass der nächste Agent daraus lernen kann.