> ## Documentation Index
> Fetch the complete documentation index at: https://internal.softcrum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Frase nominal corta, no una oración

> Una frase: qué puede hacer un tenant o un member después de esta entrega que antes no podía. Si no puedes escribir esa frase, esto no es una feature — es una sección de otra.

> Traducción de la plantilla. Autoritativo:
> [`../../modules/TEMPLATE-feature-spec.md`](/modules/TEMPLATE-feature-spec).

## Contexto

Por qué existe ahora. La restricción, la regulación, la evidencia del benchmark, el DEC que lo exigió.
Qué se rompe o qué sigue siendo imposible si lo saltamos. Sin lenguaje de solución acá.

## Alcance *(normativo)*

Qué incluye esta entrega, como una lista que un revisor pueda ir marcando. Lo bastante específica como
para que "listo" no sea un juicio de valor.

## Fuera de alcance *(normativo)*

Qué NO incluye deliberadamente, y a dónde va en cambio (otro FS, una fase, una pregunta abierta). Esta
sección previene más retrabajo que cualquier otra — escríbela bien.

## Comportamiento *(normativo)*

Las reglas, en el orden en que aplican. Enunciar los invariantes que siempre deben cumplirse y los
modos de falla de forma explícita. Decir qué está PROHIBIDO, no solo qué se permite.

## Datos *(normativo)*

Tablas tocadas o creadas, sus invariantes clave, catálogos paramétricos y sus semillas `is_system`,
particionamiento, retención. Referenciar `standards/data.md` en vez de repetirlo — registrar solo lo
específico de esta feature.

## API *(normativo)*

Cada endpoint con su **único** permiso `{module}.{resource}.{action}`, su clase (Runtime o Management),
su presupuesto p95, y si exige `Idempotency-Key`. Sección vacía si la feature no expone endpoints —
decirlo en vez de borrar el encabezado.

## Eventos *(normativo)*

Eventos de dominio emitidos y consumidos, en forma `{context}.{entity}.{verbo_pasado}`. Anotar cuáles
están disponibles como webhooks salientes y si el payload lleva PII.

## Criterios de aceptación *(normativo)*

Numerados, cada uno verificable mecánicamente. Incluir los presupuestos de latencia como números.
Incluir al menos un test negativo — lo que NO debe ocurrir.

1.
2.
3.

## Ejecución

Se completa cuando la feature sale en un solo slice, y ahí se salta el TS por completo. Qué arquetipo
se sigue, qué archivos cambian, en qué orden. Si necesita más de un slice, borrar esta sección y abrir
una task spec — nombrarla acá.

## Preguntas abiertas

Cosas genuinamente sin decidir, cada una con quién decide y para cuándo. Un spec puede llegar a
`review` con preguntas abiertas; no puede llegar a `approved` con ninguna que afecte una sección
normativa.

## Changelog

| Versión | Fecha      | Cambio           | Por qué | Autor |
| ------- | ---------- | ---------------- | ------- | ----- |
| 0.1.0   | AAAA-MM-DD | Borrador inicial | —       |       |

## Registro de entrega

*Aún no implementado.*