Las decisiones son la fuente de verdad. La arquitectura, las especificaciones, los planes y la ejecución son consecuencias de ellas, gobernadas a través de doce principios canónicos y una unidad de trabajo atómica.
El artefacto
Cómo se ve un decision record
Cada decisión de este sitio se registra como un decision record, o DEC. Este es uno real de este repositorio, mostrado tal cual.
Every response carries a security header baseline (CSP, HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy), applied at the edge by Cloudflare Pages.
Decisión
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.
Un DEC real de este repositorio. El sitio corre sobre el framework que describe.
Estados de sliceplannedin-flightmergedblock
Los 12 principios canónicos
Quita cualquiera y el resultado ya no es SliceOps. Se sostienen en cualquier runtime, cualquier lenguaje, cualquier tamaño de equipo.
Por qué
Por qué la construcción agéntica y probabilística necesita control determinístico y auditable con autoridad humana, para que el apalancamiento de IA nunca cueste corrección, rendición de cuentas ni confianza.
Cómo
Los mecanismos de construcción que sostienen la integridad de decisiones.
Qué
La disciplina hecha tangible, sin atarse a ningún modelo ni runtime.
El modelo canónico
El trabajo se organiza en tres niveles estructurales, más una vista computada desde el grafo de dependencias.
Block
Un agrupamiento lógico de slices con alcance coherente. Cierra con un retrospective y calibra la velocidad después, no es un sprint, epic ni milestone.
Section
Un dominio funcional dentro de un block, el segmento SEC del identificador del slice. Estable entre blocks: el dominio es estructural, no temporal.
Slice
La unidad de trabajo atómica, vertical y de extremo a extremo: un chat de agente, un PR, un outcome cohesivo. No es una story, ticket ni task.
Stage
Una vista computada del grafo de dependencias, qué slices son mergeables ahora. Derivada, nunca comprometida en una ceremonia. No es un sprint ni una fase.
BL-XX.SEC-XX.SL-XXX
Cada slice carga este identificador por su branch, commits, título del PR y decision records, el hilo de procedencia que amarra todo el sistema.
Cada interacción es una Session
El slice es un tipo de Session, el de desarrollo, el que termina en un PR. La mayoría del trabajo con IA nunca produce un PR, y SliceOps se niega a dejarlo sin auditar: cada interacción es una Session, clasificada y dentro del plano de auditoría.
slice ⊂ session, todo slice es una session; no toda session es un slice.
Ocho Session-Types
SliceDesarrollo completo de extremo a extremo que envía un PR.
ArtifactUna salida acotada (un script, template, config o doc) que no llega a slice completo.
SupportIncidentes y soporte, interno o de cara al cliente.
InfraOperaciones de infraestructura, deploy y entornos.
MetaGobernanza: fundamentos, planeación, decisiones de framework y de proyecto.
AuditVerificación, control y trabajo de compliance.
LearningExploración e investigación que alimenta al próximo agente.
OrchestrateCoordinación de otras sessions.
Session es la decimotercera entidad del catálogo cognitivo, el modelo machine-readable sobre el que razonan los agentes: Decision Record, Insight Record, Outcome Record, Capability, Goal, Learning Pattern, Cognitive Framework, Context Pack, Active Priority, Relationship Context, Preference, Value y Session.
Anatomía de un slice
Un slice es la unidad mínima que es independiente, testeable y útil, y carga su outcome completo consigo.
Independiente
Mergeable sin romper lo que existe. Una sola preocupación arquitectónica, si abarca más, se divide.
Testeable
Validado por al menos un test antes de poder hacer merge.
Útil
Agrega valor incremental, no refactor por refactor.
Alcance · decisión · código · tests · evidencia · merge, un chat, un PR.
Un slice tiene dos tamaños
Confundirlos es el error número uno al correr agentes. Un eje es throughput, lo que pagas. El otro es el footprint pico, si un modelo puede correr el slice siquiera.
Token-band · throughput → costo
Trabajo total en tokens billed-equivalent (input más caché, ponderado por precio), no totales crudos, que inflan. Gobierna el forecast y el presupuesto.
XS
< 2M tokens
S
2–5M tokens
M
5–10M tokens
L
10–20M tokens
XL
> 20M, señal de alerta para dividir
Context-band · footprint pico → viabilidad
El máximo de contexto cargado en un solo turno. Decide qué modelos pueden correr el slice. Una ventana menor que el footprint simplemente no puede.
XS
< 32K tokens
S
32–128K tokens
M
128–200K tokens
L
200–512K tokens
XL
> 512K tokens
Los ejes son ortogonales. Un slice puede ser XL-token / S-context (mucho output, working set pequeño) o S-token / XL-context (poco output, un codebase grande que cargar). Costo y viabilidad son modos de falla distintos, necesitan bands distintas.
Calibradas, no inventadas
Las bands no son adivinanzas. El toolkit incluye un script determinístico que lee tus propios logs de sesión y computa tus bands, mismos logs, mismo script, mismo resultado. Recalibra cuando cambie el panorama de modelos.
Script de calibración, en el toolkit.
Model Triage
¿Qué modelo debería correr un slice? SliceOps lo responde como responde todo, explícitamente, y sobre el registro. Cinco ejes, aplicados en orden de filtro:
1 · Context-band
El filtro primario, solo los modelos cuya ventana cabe el footprint pico del slice son elegibles.
2 · Sensibilidad → localidad
Los slices sensibles van a un modelo local automáticamente, nunca a una API externa, sin importar costo o velocidad.
3 · Complejidad
El token-band y el tipo de slice fijan el nivel de razonamiento que el trabajo realmente necesita.
4 · Latencia
El trabajo interactivo y el batch en segundo plano tienen necesidades de velocidad distintas.
5 · Costo
Dentro del conjunto elegible, gana el modelo más barato que alcanza.
Cada recomendación empareja un modelo con un modo de ejecución: API frontier, local-vía-API, un plan de tarifa plana ya pagado, o un modelo embebido en el IDE.
Compliance por construcción
El eje 2 es el que los equipos regulados sienten primero. “Los datos sensibles se quedan locales” deja de ser una política que esperas que la gente cumpla y se vuelve una regla de ruteo que se ejecuta, y el modelo, el modo y el rationale quedan registrados en la session. Las herramientas cerradas hard-codean un modelo o rutean de forma invisible; SliceOps hace la decisión explícita y auditable.
El Context Router
El contexto de un codebase serio solo crece. La pregunta no es cómo necesitar menos, es cómo usarlo bien. El router carga solo lo que una session realmente necesita.
En vez del corpus completo, activa solo los context-experts relevantes, las decisiones, entidades y módulos que la session toca. Está inspirado en MoE, pero a nivel de orquestación: gobierna qué contexto recibe el agente, no cómo atiende el modelo internamente.
Eficiencia de síntesis
La otra mitad es la producción. Un modelo que dice lo mismo en menos tokens (sin perder la idea) evita que el footprint de mañana se infle. La creación verbosa de hoy es deuda compuesta después. La meta es densidad que igual pasa el gate de aceptación, no concisión por la concisión.
Esto es la Disciplina de contexto (P12) hecha tangible: el contexto como una fuente de verdad única y gobernada, enrutada selectivamente, nunca asumida.
Evidencia por construcción
Cada slice produce evidencia en cuatro categorías obligatorias, más un gate de seguridad. Los slices sin evidencia no hacen merge.
Funcional
Los tests pasan.
Calidad
Linters y métricas: cobertura, formato, complejidad.
Decisión
Decision records e insight records.
Procedencia
Slice ID, agente, timestamps, commit SHA.
La seguridad es su propio gate por slice: escaneo de secretos, SAST, chequeos de dependencias y supply-chain, no una auditoría periódica.
El plano de auditoría: Decision Records
Ninguna herramienta de calidad de código, monitor de runtime ni plataforma de compliance audita el plano de decisiones: qué se decidió, quién, por qué y con qué cadena de supersesión. Esa capa es la cuña de SliceOps.
01Cada decisión arquitectónica es un Decision Record con frontmatter que mapea a un modelo de entidades cognitivas que los agentes pueden razonar.
02Los registros son append-only, nunca se borran ni se reescriben en silencio. La supersesión es una arista bidireccional y acíclica: el nuevo registro declara qué reemplaza, el viejo apunta hacia adelante.
03Cada registro traza de vuelta al slice que lo produjo y queda alcanzable desde él.
04CI rechaza cualquier PR que rompa el schema, deje una decisión huérfana o deje una cadena de supersesión inconsistente.
Ciclo de vidaproposed → accepted → superseded / deprecated
Stage como vista derivada del DAG
Los slices declaran sus dependencias con aristas explícitas. Un Stage se computa recorriendo ese grafo: el Stage N es lo que está desbloqueado en el paso N. El paralelismo sale de la topología, no de una reunión de planning. El forecast y los retrospectives ocurren a nivel de block; no hay burndown charts ni “nos comprometimos a N slices este sprint”.
Catorce gates de merge
Las R-rules canónicas (R1–R14) son gates duros de CI, cada una traza de vuelta a un principio. Los adopters agregan las suyas desde R15 en adelante.
R1Sin secretos en markdown o YAML.
R2Sin cross-references rotas.
R3Frontmatter requerido y válido.
R4Consistencia del registro de decisiones: cada decisión citada tiene su registro.
R5Las transiciones de ciclo de vida son atómicas: mover, status y ambas aristas de supersesión en un PR.
R6Sin TODO/FIXME/HACK en decisiones o specs congeladas.
R7Procedencia de fuentes externas preservada.
R8Disciplina de SemVer: plan y spec versionan en lockstep.
R9El contexto de agente cross-repo se mantiene en sync.
R10Los archivos archivados son inmutables.
R11Clasificación de confidencialidad presente y dentro de rango.
R12Imports restringidos a un árbol de fuentes autorizado.
R13El ledger de slices se actualiza en cada PR de cierre.
R14Nada de contenido fuera del alcance declarado del repo.
La Fase 2.5 agrega validators de coherencia sobre las R-rules (conteos de principios, conteos de entidades, unidades de token-band y un gate de costo de LLM) para que el drift denormalizado no se acumule en silencio. Vienen como checks de CI drop-in en el toolkit.
La factura de LLM es un recurso finito
Correr agentes en CI cuesta dinero real, y el modo de falla es silencioso. Te enteras cuando llega la factura. SliceOps trata la inferencia como cualquier recurso compartido: enumerada, topada, con gate. Cinco palancas:
Prompt-caching
Cachea los bloques estables; saltártelo puede dejar 40–60% del costo sobre la mesa.
Nivel de modelo
Usa el nivel más barato que alcanza; top-tier “por si acaso” es como un 3× de penalización sin ganancia.
Contexto solo-diff
Manda el diff y unas líneas alrededor; trae el archivo completo solo cuando el razonamiento lo necesita.
Triggers mínimos
Audita en open, reopen y ready, no en cada push. La velocidad no debería multiplicar la factura.
Gate de draft
Salta los jobs caros en drafts, pero termina en verde; un check requerido en “skipped” bloquea el PR para siempre.
Determinismo sobre regeneración
Si algo se repite, materialízalo una vez (un script, un validator, una R-rule) en vez de pedirle a un modelo que lo regenere cada vez. El código determinístico es más barato, más rápido y produce evidencia que no deriva. Que la IA escriba la herramienta una vez, y reúsala.
Decision-driven, no spec-driven
Los toolchains spec-first asumen que la spec está bien desde el inicio y cualquier divergencia es un bug. SliceOps asume que aprendes mientras construyes, así que la fuente de verdad es el corpus de decisiones y el código merged, y el registro de por qué cambió la spec es el artefacto que vale la pena guardar.
Envuelve tu flujo, no compite
Spec-first, test-first, contract-first, esos son estilos de autoría. SliceOps es el plano de disciplina alrededor de cualquiera de ellos. Usa tu flujo preferido para ir de intención a código; usa SliceOps para hacer todo el proceso atómico, auditable y auto-mejorante. Se sienta encima de Spec Kit, no en contra.
Acceptance-first, por convención
Convención sobre configuración: el default opinado es que cada slice declara sus criterios de aceptación por adelantado, idealmente como tests ejecutables. Un solo artefacto ancla el alcance al inicio y cierra el slice como evidencia al final. Un default, no un mandato.
Tres cuñas
Plano de auditoría
La capa de decisiones arquitectónicas que ninguna herramienta existente audita.
Paralelismo multi-agente
Dirigido por el DAG, de cinco a trece agentes simultáneos como modo normal de operación.
Ingeniería legible por IA
Cada artefacto está estructurado para que el próximo agente aprenda de él.