docs(theming): el índice de git es COMPARTIDO — verificar el árbol indexado no basta

Ocho sesiones sobre el mismo worktree y un solo .git/index. La técnica que esta
rama daba por segura —construir el índice desde HEAD con sólo tus hunks y
comprobarlo con git diff --cached— protege del árbol de trabajo ajeno, no de la
ventana entre MIRAR y CONFIRMAR: si otra sesión hace su reset + add en ese
hueco, tu commit fotografía SU índice.

Ocurrido dos veces en una tarde. edc019515 salió con tres fragmentos de
rating-group dentro y sin la mitad de los suyos. Y la reparación cosió dos
bloques dejando una coma de más en el ledger, con lo que HEAD lleva cuatro
commits con el fichero sin parsear (arreglado en 88a208644): el guard no queda
en rojo, queda muerto, y sólo se ve al hacer checkout limpio.

La regla que sustituye a la vieja: verificación y confirmación en la MISMA
invocación de shell, encadenadas, nunca en dos turnos. Y al cerrar una tanda,
comprobar HEAD —no el árbol— parseando el fichero compartido.

Corolario medido el mismo día: un árbol con restos de una sesión ya terminada
hace mentir al instrumento sin tocar ningún commit. El guard de card daba 0/98
—la firma del instrumento ciego— por un theming-sentinel.ts sucio con el bloque
de chat-log DUPLICADO; desde copia limpia de HEAD, 49/98 y verde.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/next-features.md

@@ -1443,6 +1443,34 @@ Lo que `chart` destapó (2026-08-22):
   chevron, con lo que los dos tokens de reposo del trigger leen muertos. Miden
   bien con el panel CERRADO. No hay arreglo dentro de una corrida: el
   instrumento sólo puede estar en un estado a la vez; se adjudica.
+- **⚠⚠ EL ÍNDICE DE GIT ES COMPARTIDO: VERIFICAR EL ÁRBOL INDEXADO NO BASTA**
+  (medido 2026-08-24, con ocho sesiones sobre el mismo worktree). Hay UN solo
+  `.git/index`. La técnica que esta rama daba por segura —construir el índice
+  desde HEAD con sólo tus hunks y comprobarlo con `git diff --cached`— protege
+  del árbol de trabajo ajeno, **no de la ventana entre mirar y confirmar**: si
+  otra sesión hace su `reset` + `add` en ese hueco, tu `git commit` fotografía
+  SU índice. Ocurrido dos veces en una tarde:
+
+  - `edc019515` (toggle) salió con tres fragmentos de `rating-group` dentro, y
+    sin la mitad de los suyos; hizo falta `007c2af52` para repararlo.
+  - La reparación cosió el bloque de `rating-group` con el de `toggle` y dejó
+    **`},,`** en el literal del ledger: cuatro commits de HEAD con
+    `theming-sentinel-exceptions.ts` **que no parsea**. El guard R-5.4 no queda
+    en rojo, queda MUERTO, y sólo se ve al hacer checkout limpio (arreglado en
+    `88a208644`).
+
+  **La regla que sustituye a la vieja**: verificación y confirmación tienen que
+  ir en la MISMA invocación de shell (`git reset && … && git commit` encadenado),
+  nunca en dos turnos. Y al cerrar una tanda, comprobar HEAD —no el árbol— con
+  un parseo del fichero compartido.
+
+  **Corolario del mismo día**: un árbol de trabajo con restos de una sesión ya
+  terminada hace MENTIR al instrumento sin tocar ningún commit. El guard de
+  `card` daba `0/98` —la firma del instrumento ciego— por un
+  `theming-sentinel.ts` sucio con el bloque de `chat-log` DUPLICADO; desde una
+  copia limpia de HEAD, `49/98` y verde. Antes de creer un `0/N`, comprobar que
+  el instrumento coincide con HEAD.
+
 - **⚠ UN COMPONENTE BARRE DESCENDIENTES Y SE COME EL TOKEN DE SUS HUÉSPEDES**
   (medido 2026-08-24 en `chat-composer` dentro de `file-upload`, verificado en
   la supervisión). `file-upload` declara