As decisões são a fonte de verdade. A arquitetura, as especificações, os planos e a execução são consequências delas, governadas ao longo de doze princípios canónicos e uma unidade de trabalho atómica.
O artefacto
Como é um decision record
Cada escolha neste site é registada como um decision record, ou DEC. Este é um real deste repositório, mostrado tal como está.
Every response carries a security header baseline (CSP, HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy), applied at the edge by Cloudflare Pages.
Decisão
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.
Resultado
Defense against clickjacking, MIME sniffing, and injected scripts, with a clear record of why each allowed origin exists.
Um DEC real deste repositório. O site corre sobre o framework que descreve.
Estados do sliceplannedin-flightmergedblock
Os 12 princípios canónicos
Retire qualquer um e o resultado já não é SliceOps. Sustentam-se em qualquer runtime, qualquer linguagem, qualquer dimensão de equipa.
Porquê
Porque é que a construção agêntica e probabilística precisa de controlo determinístico e auditável com autoridade humana, para que a alavancagem da IA nunca custe correção, responsabilização ou confiança.
Como
Os mecanismos de construção que sustentam a integridade das decisões.
O quê
A disciplina tornada tangível, sem se prender a nenhum modelo nem runtime.
O modelo canónico
O trabalho organiza-se em três níveis estruturais, mais uma vista calculada a partir do grafo de dependências.
Block
Um agrupamento lógico de slices com âmbito coerente. Fecha com um retrospective e calibra a velocidade depois, não é um sprint, epic nem milestone.
Section
Um domínio funcional dentro de um block, o segmento SEC do identificador do slice. Estável entre blocks: o domínio é estrutural, não temporal.
Slice
A unidade de trabalho atómica, vertical e de ponta a ponta: um chat de agente, um PR, um resultado coeso. Não é uma story, ticket nem task.
Stage
Uma vista calculada do grafo de dependências, que slices são mergeáveis agora. Derivada, nunca comprometida numa cerimónia. Não é um sprint nem uma fase.
BL-XX.SEC-XX.SL-XXX
Cada slice carrega este identificador pela sua branch, commits, título do PR e decision records, o fio de proveniência que amarra todo o sistema.
Cada interação é uma Session
O slice é um tipo de Session, o de desenvolvimento, o que termina num PR. A maior parte do trabalho com IA nunca produz um PR, e o SliceOps recusa-se a deixá-lo sem auditar: cada interação é uma Session, classificada e dentro do plano de auditoria.
slice ⊂ session, todo o slice é uma session; nem toda a session é um slice.
Oito Session-Types
SliceDesenvolvimento completo de ponta a ponta que entrega um PR.
ArtifactUma saída delimitada (um script, template, config ou doc) aquém de um slice completo.
SupportIncidentes e apoio, interno ou de frente para o cliente.
InfraOperações de infraestrutura, deploy e ambientes.
MetaGovernação: fundamentos, planeamento, decisões de framework e de projeto.
AuditVerificação, controlo e trabalho de compliance.
LearningExploração e investigação que alimenta o próximo agente.
OrchestrateCoordenação de outras sessions.
Session é a décima terceira entidade do catálogo cognitivo, o modelo machine-readable sobre o qual os agentes raciocinam: Decision Record, Insight Record, Outcome Record, Capability, Goal, Learning Pattern, Cognitive Framework, Context Pack, Active Priority, Relationship Context, Preference, Value e Session.
Anatomia de um slice
Um slice é a menor unidade que é independente, testável e útil, e carrega consigo o seu resultado completo.
Independente
Mergeável sem partir o que existe. Uma só preocupação arquitetónica, se abranger mais, divide-se.
Testável
Validado por pelo menos um teste antes de poder fazer merge.
Útil
Acrescenta valor incremental, não refactor por refactor.
Âmbito · decisão · código · testes · evidência · merge, um chat, um PR.
Um slice tem dois tamanhos
Confundi-los é o erro número um das equipas a correr agentes. Um eixo é throughput, o que paga. O outro é o footprint de pico, se um modelo consegue sequer correr o slice.
Token-band · throughput → custo
Trabalho total em tokens billed-equivalent (input mais cache, ponderado por preço), não totais em bruto, que inflacionam. Governa o forecast e o orçamento.
XS
< 2M tokens
S
2–5M tokens
M
5–10M tokens
L
10–20M tokens
XL
> 20M, sinal de alerta para dividir
Context-band · footprint de pico → viabilidade
O máximo de contexto carregado num único turno. Decide que modelos conseguem correr o slice. Uma janela menor que o footprint simplesmente não consegue.
XS
< 32K tokens
S
32–128K tokens
M
128–200K tokens
L
200–512K tokens
XL
> 512K tokens
Os eixos são ortogonais. Um slice pode ser XL-token / S-context (muito output, working set pequeno) ou S-token / XL-context (pouco output, um codebase grande a carregar). Custo e viabilidade são modos de falha distintos, precisam de bands distintas.
Calibradas, não inventadas
As bands não são palpites. O toolkit inclui um script determinístico que lê os seus próprios logs de sessão de agente e calcula as suas bands, mesmos logs, mesmo script, mesmo resultado. Recalibre quando o panorama dos modelos mudar.
Script de calibração, no toolkit.
Model Triage
Que modelo deve correr um slice? O SliceOps responde como responde a tudo, explicitamente, e no registo. Cinco eixos, aplicados por ordem de filtro:
1 · Context-band
O filtro primário, só os modelos cuja janela acomoda o footprint de pico do slice são sequer elegíveis.
2 · Sensibilidade → localidade
Os slices sensíveis vão para um modelo local automaticamente, nunca para uma API externa, seja qual for o custo ou a velocidade.
3 · Complexidade
A token-band e o tipo de slice fixam o nível de raciocínio que o trabalho realmente precisa.
4 · Latência
O trabalho interativo e o batch em segundo plano têm necessidades de velocidade diferentes.
5 · Custo
Dentro do conjunto elegível, ganha o modelo mais barato que chega.
Cada recomendação emparelha um modelo com um modo de execução: API frontier, local-via-API, um plano de tarifa plana já pago, ou um modelo embutido no IDE.
Compliance por construção
O eixo 2 é o que as equipas reguladas sentem primeiro. “Os dados sensíveis ficam locais” deixa de ser uma política que espera que as pessoas cumpram e torna-se uma regra de roteamento que se executa, e o modelo, o modo e o rationale ficam registados na session. As ferramentas fechadas fazem hard-code de um modelo ou roteiam de forma invisível; o SliceOps torna a decisão explícita e auditável.
O Context Router
O contexto de um codebase sério só cresce. A questão não é como precisar de menos dele, é como usá-lo bem. O router carrega apenas o que uma session realmente precisa.
Em vez do corpus completo, ativa apenas os context-experts relevantes, as decisões, entidades e módulos que a session toca. É inspirado em MoE, mas ao nível da orquestração: governa que contexto o agente recebe, não como o modelo atende internamente.
Eficiência de síntese
A outra metade é a produção. Um modelo que diz o mesmo em menos tokens (sem perder a ideia) evita que o footprint de amanhã inche. A criação verbosa de hoje é dívida composta mais tarde. A meta é densidade que ainda assim passa o gate de aceitação, não concisão pela concisão.
Isto é a Disciplina de contexto (P12) tornada tangível: o contexto como uma fonte de verdade única e governada, encaminhada seletivamente, nunca assumida.
Evidência por construção
Cada slice produz evidência em quatro categorias obrigatórias, mais um gate de segurança. Os slices sem evidência não fazem merge.
Funcional
Os testes passam.
Qualidade
Linters e métricas: cobertura, formato, complexidade.
Decisão
Decision records e insight records.
Proveniência
Slice ID, agente, timestamps, commit SHA.
A segurança é o seu próprio gate por slice: scan de secrets, SAST, verificações de dependências e supply-chain, não uma auditoria periódica.
O plano de auditoria: Decision Records
Nenhuma ferramenta de qualidade de código, monitor de runtime nem plataforma de compliance audita o plano de decisões: o que foi decidido, por quem, porquê e com que cadeia de supersessão. Essa camada é a cunha do SliceOps.
01Cada decisão arquitetónica é um Decision Record com frontmatter que mapeia para um modelo de entidades cognitivas sobre o qual os agentes conseguem raciocinar.
02Os registos são append-only, nunca apagados, nunca reescritos em silêncio. A supersessão é uma aresta bidirecional e acíclica: o novo registo declara o que substitui, o antigo aponta para a frente.
03Cada registo traça de volta ao slice que o produziu e mantém-se alcançável a partir dele.
04O CI rejeita qualquer PR que parta o schema, deixe uma decisão órfã ou deixe uma cadeia de supersessão inconsistente.
Ciclo de vidaproposed → accepted → superseded / deprecated
Stage como vista derivada do DAG
Os slices declaram as suas dependências com arestas explícitas. Um Stage calcula-se percorrendo esse grafo: o Stage N é o que está desbloqueado no passo N. O paralelismo sai da topologia, não de uma reunião de planning. O forecast e os retrospectives acontecem ao nível do block; não há burndown charts nem “comprometemo-nos a N slices este sprint”.
Catorze gates de merge
As R-rules canónicas (R1–R14) são gates duros de CI, cada uma traça de volta a um princípio. Os adopters acrescentam as suas a partir de R15 em diante.
R1Sem secrets em markdown ou YAML.
R2Sem cross-references partidas.
R3Frontmatter obrigatório e válido.
R4Consistência do registo de decisões: cada decisão citada tem o seu registo.
R5As transições de ciclo de vida são atómicas: mover, status e ambas as arestas de supersessão num PR.
R6Sem TODO/FIXME/HACK em decisões ou specs congeladas.
R7Proveniência de fontes externas preservada.
R8Disciplina de SemVer: as versões de plano e spec movem-se em lockstep.
R9O contexto de agente cross-repo mantém-se em sync.
R10Os ficheiros arquivados são imutáveis.
R11Classificação de confidencialidade presente e dentro do intervalo.
R12Imports restritos a uma árvore de fontes autorizada.
R13O ledger de slices é atualizado em cada PR de fecho.
R14Nenhum conteúdo fora do âmbito declarado do repo.
A Fase 2.5 acrescenta validators de coerência por cima das R-rules (contagens de princípios, contagens de entidades, unidades de token-band e um gate de custo de LLM) para que o drift desnormalizado não se acumule em silêncio. Vêm como checks de CI drop-in no toolkit.
A fatura de LLM é um recurso finito
Correr agentes em CI custa dinheiro real, e o modo de falha é silencioso. Descobre-o quando chega a fatura. O SliceOps trata a inferência como qualquer outro recurso partilhado: enumerada, limitada, com gate. Cinco alavancas:
Prompt-caching
Cacheie os blocos estáveis; saltá-lo pode deixar 40–60% do custo em cima da mesa.
Nível de modelo
Use o nível mais barato que chega; top-tier “só por precaução” é cerca de uma penalização de 3× sem ganho.
Contexto só-diff
Envie o diff e umas linhas à volta; vá buscar o ficheiro completo só quando o raciocínio precisar.
Triggers mínimos
Audite em open, reopen e ready, não em cada push. A velocidade não deve multiplicar a fatura.
Gate de draft
Salte os jobs caros nos drafts, mas termine a verde; um check obrigatório em “skipped” bloqueia o PR para sempre.
Determinismo sobre regeneração
Se algo se repete, materialize-o uma vez (um script, um validator, uma R-rule) em vez de pedir a um modelo que o regenere de cada vez. O código determinístico é mais barato, mais rápido e produz evidência que não deriva. Deixe a IA escrever a ferramenta uma vez, depois reutilize-a.
Decision-driven, não spec-driven
As toolchains spec-first pressupõem que a spec está certa à partida e qualquer divergência é um bug. O SliceOps pressupõe que se aprende enquanto se constrói, por isso a fonte de verdade é o corpus de decisões e o código merged, e o registo do porquê de a spec ter mudado é, ele próprio, o artefacto que vale a pena guardar.
Envolve o seu fluxo, não compete
Spec-first, test-first, contract-first, esses são estilos de autoria. O SliceOps é o plano de disciplina à volta de qualquer um deles. Use o seu fluxo preferido para ir da intenção ao código; use o SliceOps para tornar o conjunto atómico, auditável e auto-melhorável. Assenta sobre o Spec Kit, não contra ele.
Acceptance-first, por convenção
Convenção sobre configuração: o default opinativo é que cada slice declara os seus critérios de aceitação à partida, idealmente como testes executáveis. Um artefacto ancora o âmbito no início e fecha o slice como evidência no fim. Um default, não um mandato.
Três cunhas
Plano de auditoria
A camada de decisões arquitetónicas que nenhuma ferramenta existente audita.
Paralelismo multiagente
Conduzido pelo DAG, de cinco a treze agentes em simultâneo como modo normal de operação.
Engenharia legível por IA
Cada artefacto está estruturado para que o próximo agente aprenda com ele.