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

# Flujo de trabajo y regla de docs

> Cómo se documenta una feature y qué obliga a actualizar el handbook.

Esta página cierra el círculo: dónde queda la historia de una feature antes
de escribirse, y qué obliga a que este handbook se mantenga al día con ella.

## Specs y planes

El trabajo de features se documenta primero. Toda feature no trivial
arranca como spec en `docs/superpowers/specs/` y se implementa a partir de
un plan derivado en `docs/superpowers/plans/`. Ambos usan el mismo formato
de nombre: `YYYY-MM-DD-nombre.md`.

## Roadmap

`roadmap.md`, en la raíz del repo, mantiene el estado de cada requerimiento
funcional — `RF-01` a `RF-20` — como una lista de tareas: qué está hecho,
qué sigue pendiente y en qué fase entra.

## Lint y formato

`npm run lint` corre Biome en modo `check --write`: lint, formato y
organización de imports en una sola pasada. No hay un comando de formato
separado — Biome hace las tres cosas a la vez.

## La regla de docs

Toda spec nueva en `docs/superpowers/specs/` incluye una sección
`## Impacto en docs` con una tabla de dos columnas, `Página del handbook |
Cambio`. Declarar `ninguna` es una respuesta válida, pero exige justificar
por qué esa feature no toca ningún acuerdo documentado aquí. El plan de
implementación que se deriva de la spec hereda esa obligación: la
actualización del handbook aparece ahí como una tarea del plan, con su
propio checkbox — no como una nota al margen que alguien puede saltarse.

<Note>
  El handbook vive en `docs/handbook/` y se publica en el sitio Mintlify
  público. La regla existe para que ese sitio no se quede desactualizado
  respecto al código.
</Note>

### Por qué existe esta regla

Al escribir este handbook nos topamos con una prueba directa de por qué
hace falta. La sección *Route handlers* de `CLAUDE.md` describía el cursor
de paginación de usuarios como "compuesto y codificado en base64url",
implementado en `src/lib/admin-users-cursor.ts`. Ese archivo no existe: se
eliminó en un refactor que simplificó el cursor a un `id` plano, igual que
en el resto de listados — pero la documentación nunca se actualizó para
reflejarlo.

Nadie mintió a propósito. El refactor simplemente no incluyó el paso de
"actualizar la doc que describe esto", porque no había ningún paso formal
que lo exigiera. Es la misma deriva la que aparece si una spec cambia un
permiso, agrega un endpoint o mueve un umbral de cobertura y nadie se
acuerda de tocar el handbook.

<Warning>
  Esta página documenta la regla, no la hace cumplir. Cumplirla depende de
  que cada spec nueva incluya su sección `## Impacto en docs` desde el
  principio.
</Warning>