> ## 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.

# Softcrum Suite — documentación interna

> La fuente de verdad de ingeniería: la constitución, los estándares, las decisiones de arquitectura y el sistema de specs con el que se construye cada módulo.

Estas páginas y el repositorio son los mismos archivos. Un agente los lee desde `docs/internal/`;
tú los lees renderizados acá. Cuando ambos difieren, manda el repositorio — por eso un cambio de
documentación es parte del cambio de código, nunca algo que se hace después.

<Columns cols={2}>
  <Card title="Fundamentos" icon="landmark" href="/es/constitution/overview">
    Las reglas que no cambian sin una enmienda: la constitución, siete estándares y veintidós
    decisiones de arquitectura.
  </Card>

  <Card title="Módulos" icon="cubes" href="/es/modules/overview">
    Cinco bounded contexts, cada uno con su PRD, su spec técnico vivo y sus feature specs — la
    unidad que realmente entregamos.
  </Card>

  <Card title="Ejecución" icon="rocket" href="/es/task-specs/overview">
    Los task specs desde los que trabaja un agente, los runbooks que sigue una persona cuando algo
    se rompe, y las especificaciones de diagramas.
  </Card>

  <Card title="Registro de diseño" icon="clipboard-list" href="/design/decision-registry-v1">
    Cada decisión cerrada con su id `DEC-*`, y las preguntas que siguen abiertas.
  </Card>

  <Card title="Legal" icon="scale-balanced" href="/legal/overview">
    Borradores de trabajo del paquete de protección de datos. Sin revisar — un abogado firma antes
    de que algo de acá salga de este sitio.
  </Card>

  <Card title="Glosario" icon="book" href="/es/glossary">
    El vocabulario que esta documentación da por sabido: tenant, contacto, member, contacto
    comercializable.
  </Card>
</Columns>

## En qué estado está el trabajo

|                            |                                                                       |
| -------------------------- | --------------------------------------------------------------------- |
| Módulos descompuestos      | 5 de 5 — identidad, núcleo de clientes, fidelización, mensajería, CRM |
| Feature specs escritos     | 51, más 5 PRD                                                         |
| Estado de los specs        | 41 `draft` · 15 `review` · **0 `approved`**                           |
| Decisiones de arquitectura | 22 ADR, de los cuales 8 son reconstrucciones por validar              |
| Preguntas abiertas         | 70, agrupadas por quién las decide                                    |
| Código de aplicación       | ninguno todavía — empieza en TS-001                                   |

El cero de la tercera fila es el cuadro completo. La regla **R-S1** dice que no se mergea código
de una feature cuyo spec no esté `approved`, y no hay nada aprobado, así que los specs no esperan
más escritura. Esperan decisiones.

## Qué está bloqueado en el dueño

<Steps>
  <Step title="Validar la constitución fundacional">
    En especial [la Parte 2, las seis categorías de puerto](/es/constitution/founding-constitution):
    cada línea ahí es inferida, y TS-002 define adaptadores contra ella. Confirmar o corregir seis
    líneas ahora es barato; hacerlo cuando los adaptadores existan, no.
  </Step>

  <Step title="Revisar la enmienda A1 línea por línea">
    [Agrega dos categorías de puerto](/es/constitution/amendment-A1-ports-and-standards) a una lista
    cerrada, que es exactamente el tipo de cambio que la constitución exige que haga una persona.
  </Step>

  <Step title="Responder el grupo A de las preguntas abiertas">
    [52 preguntas](/design/open-questions-v2), cada una con su recomendación. Responderlas mueve 37
    specs hacia `approved`.
  </Step>

  <Step title="Aprobar los quince documentos de fidelización en revisión">
    Están en `0.2.0`. La aprobación es lo que los vuelve `1.0.0` y desbloquea el primer slice.
  </Step>
</Steps>

## Cómo una decisión llega al código

```
DEC-*  ──►  ADR  ──►  PRD  ──►  Spec de módulo  ──►  FS  ──►  TS (opcional)  ──►  PR
 la         el       qué es     qué existe          la      cómo lo ejecuta     y el PR
 decisión   por qué  y para     hoy                 unidad  el agente           enlaza
            detrás   quién                          de                          de vuelta
                                                    entrega                     al FS
```

Cada eslabón de esa cadena se verifica en CI. Un feature spec que cita un `DEC-*` inexistente
rompe el build; una tabla de un spec de módulo que ningún feature spec reclama se reporta como
sin cobertura. La mecánica está en [el sistema de specs](/es/modules/overview).

<Note>
  Este sitio es un espejo de un repositorio privado y no está indexado. La versión en inglés es una
  traducción fiel de los mismos archivos: el inglés es autoritativo para los documentos de
  ingeniería, y el español para el paquete legal y el registro de diseño.
</Note>