chore(metodo): llegan los 3 nucleos de sesion (orquestadora, ejecucion, exploracion)
El metodo de las sesiones deja de estar repartido por frentes: cada nucleo es la UNION de lo que cada uno aprendio. Los apendices de proyecto NO viajan. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
sirxavor
parent
6cd714959d
commit
63fa2d68ba
@ -1,4 +1,7 @@
|
||||
b3aa1294777afebe63d4e914e555849c3435c3c08e45533b99c96b096fcda9ad metodo.md
|
||||
896a92488d149cd16be26cf126e32db58591f640c463ef25a7badd56d71ee25d bin/metodo
|
||||
a65fcd72ed8b6ed87ee35fb06d16796c55a2f138f31d35ba27f116b25dc1bde2 bin/metodo
|
||||
f89b71bdf31028b05075636c1763c964e379bc37a00e0357d1c23a4dd19c09aa workflows/README.md
|
||||
6871c5f29642ccec3e60109324de1e5bab8fa5ee73792360d85277bde3323aea workflows/comunicacion-entre-sesiones.md
|
||||
2b9037f6dd57b5598c70a676cb728556654f05d1c5b024e7b716864659f7b884 workflows/sesion-ejecucion.md
|
||||
f35dda490674d37da4a8f9412a2463ea37c42c02af4f63d642e06c8a3f9cfc90 workflows/sesion-exploracion.md
|
||||
4db06b6b4d0dcfd2493a7a5d9a36d98f05aeac63729671bdc30ae20d2fd51db3 workflows/sesion-orquestadora.md
|
||||
|
||||
@ -271,7 +271,7 @@ check_headings() {
|
||||
# ⛔ `workflows/` entró el 2026-08-30: sus enlaces NO los miraba nadie, y por eso
|
||||
# `comunicacion-entre-sesiones.md` llevaba 2 enlaces ROTOS en la matriz Y en los 27 repos.
|
||||
# Un fichero cuyo único trabajo es LLEVAR al Método apuntaba a un sitio que no existe.
|
||||
for f in "$ROOT"/*.md "$ROOT"/doc/*.md "$ROOT"/workflows/*.md; do
|
||||
for f in "$ROOT"/*.md "$ROOT"/doc/*.md "$ROOT"/workflows/*.md "$ROOT"/workflows/apendices/*.md; do
|
||||
[ -f "$f" ] || continue
|
||||
# Un encabezado ## no lleva emoji de ESTADO (el estado vive en las casillas).
|
||||
# ⚠️ se excluye a propósito: en un título es "bandera/aviso", no estado de sección.
|
||||
@ -290,7 +290,7 @@ check_links() {
|
||||
# ⛔ `workflows/` entró el 2026-08-30: sus enlaces NO los miraba nadie, y por eso
|
||||
# `comunicacion-entre-sesiones.md` llevaba 2 enlaces ROTOS en la matriz Y en los 27 repos.
|
||||
# Un fichero cuyo único trabajo es LLEVAR al Método apuntaba a un sitio que no existe.
|
||||
for f in "$ROOT"/*.md "$ROOT"/doc/*.md "$ROOT"/workflows/*.md; do
|
||||
for f in "$ROOT"/*.md "$ROOT"/doc/*.md "$ROOT"/workflows/*.md "$ROOT"/workflows/apendices/*.md; do
|
||||
[ -f "$f" ] || continue
|
||||
dir=$(dirname "$f")
|
||||
# process substitution (< <(...)) para que el while corra en ESTE shell y bad() cuente
|
||||
@ -795,11 +795,16 @@ cmd_init() {
|
||||
_wf_no_viaja "$(basename "$_wf")" && continue
|
||||
cp "$_wf" "$md/workflows/$(basename "$_wf")"
|
||||
done
|
||||
# Y RETIRA lo que ya no debe estar: una exclusión que sólo deja de copiar no limpia lo
|
||||
# Y RETIRA lo que ya no debe estar. ⛔ El criterio es **ausencia en el MÁSTER**, no
|
||||
# pertenencia a la lista de exclusión: un workflow RETIRADO o RENOMBRADO en la matriz
|
||||
# tampoco debe sobrevivir aquí. Con el criterio antiguo se quedaba vivo Y fuera de
|
||||
# CHECKSUMS ⇒ `check` decía «copia íntegra, rc=0» con un fichero fantasma dentro.
|
||||
# (Medido 2026-08-30 por la sesión que construyó los núcleos, con control positivo.)
|
||||
# que un bucle anterior ya depositó. Sin esto, el fichero mal vendorizado sobrevive.
|
||||
for _old in "$md"/workflows/*.md; do
|
||||
[ -e "$_old" ] || continue
|
||||
_wf_no_viaja "$(basename "$_old")" && rm -f "$_old"
|
||||
_b=$(basename "$_old")
|
||||
if _wf_no_viaja "$_b" || [ ! -e "$SELF_ROOT/workflows/$_b" ]; then rm -f "$_old"; fi
|
||||
done
|
||||
local mver adopt
|
||||
mver=$(grep -E '^version:' "$SELF_ROOT/.metodo/VERSION" 2>/dev/null | sed 's/version:[[:space:]]*//')
|
||||
@ -841,11 +846,16 @@ cmd_update() {
|
||||
_wf_no_viaja "$(basename "$_wf")" && continue
|
||||
cp "$_wf" "$md/workflows/$(basename "$_wf")"
|
||||
done
|
||||
# Y RETIRA lo que ya no debe estar: una exclusión que sólo deja de copiar no limpia lo
|
||||
# Y RETIRA lo que ya no debe estar. ⛔ El criterio es **ausencia en el MÁSTER**, no
|
||||
# pertenencia a la lista de exclusión: un workflow RETIRADO o RENOMBRADO en la matriz
|
||||
# tampoco debe sobrevivir aquí. Con el criterio antiguo se quedaba vivo Y fuera de
|
||||
# CHECKSUMS ⇒ `check` decía «copia íntegra, rc=0» con un fichero fantasma dentro.
|
||||
# (Medido 2026-08-30 por la sesión que construyó los núcleos, con control positivo.)
|
||||
# que un bucle anterior ya depositó. Sin esto, el fichero mal vendorizado sobrevive.
|
||||
for _old in "$md"/workflows/*.md; do
|
||||
[ -e "$_old" ] || continue
|
||||
_wf_no_viaja "$(basename "$_old")" && rm -f "$_old"
|
||||
_b=$(basename "$_old")
|
||||
if _wf_no_viaja "$_b" || [ ! -e "$SELF_ROOT/workflows/$_b" ]; then rm -f "$_old"; fi
|
||||
done
|
||||
local mver adopt
|
||||
mver=$(grep -E '^version:' "$SELF_ROOT/.metodo/VERSION" 2>/dev/null | sed 's/version:[[:space:]]*//')
|
||||
|
||||
128
.metodo/workflows/sesion-ejecucion.md
Normal file
128
.metodo/workflows/sesion-ejecucion.md
Normal file
@ -0,0 +1,128 @@
|
||||
# Workflow: sesión de EJECUCIÓN — núcleo
|
||||
|
||||
<!-- metodo:puntero -->
|
||||
⛔ **Antes de tocar nada, lee el Método: [`repos/metodo/metodo.md`](../metodo.md)** — los
|
||||
raíles transversales, completos y con sus cicatrices. Si trabajas **dentro de un repo**, la copia que
|
||||
te toca es la suya (`.metodo/metodo.md`), que va sellada y la mide `metodo check`.
|
||||
⇒ Y **`§7`**: al arrancar se leen `AVISOS.md`, `decisiones.md` y `backlog.md`; **la bitácora NO**, se
|
||||
consulta por su índice. Arrancar cuesta ~400 k tokens en un frente maduro y **la bitácora es el 79 %**.
|
||||
⇒ *Este bloque existe porque el 2026-08-29 se midió que **7 de los 9 workflows del árbol no llevaban
|
||||
al Método**, incluidos los dos más usados. Una constitución sólo gobierna si algo lleva a ella: es su
|
||||
propio raíl `§8` —* ***un aviso que nadie lee no es un mecanismo de contención.***
|
||||
<!-- /metodo:puntero -->
|
||||
|
||||
> **Esto es el NÚCLEO: el método de aplicar un cambio ya decidido, sin el frente.** Viaja a cada
|
||||
> repo con `.metodo/`. Qué máquinas hay, qué comandos, qué es intocable y dónde se documenta vive
|
||||
> en su **apéndice**, que **no viaja**: se lee sobre este núcleo, no en su lugar.
|
||||
|
||||
Para tareas que **aplican cambios reales**. Si la tarea es solo leer, comparar o diagnosticar sin
|
||||
tocar nada, la que toca es la de **exploración** (`sesion-exploracion.md`) — tiene menos
|
||||
salvaguardas porque no las necesita.
|
||||
|
||||
⛔ **Esta sesión no decide diseño: ejecuta lo ya decidido, con cuidado.** El "qué" se acordó antes;
|
||||
lo suyo es el "cómo". Si al llegar la realidad no coincide con lo que el encargo daba por cierto,
|
||||
**para y reporta** — no improvisa (`§6` del Método: la premisa del prompt también se mide).
|
||||
|
||||
## Cuándo se usa
|
||||
|
||||
Cuando ya se ha decidido **qué** cambiar y **cómo** —normalmente fruto de una exploración previa
|
||||
más la conversación con el usuario— y toca aplicarlo. El disparador concreto de cada frente, y qué
|
||||
cuenta allí como "cambio real", están en su apéndice.
|
||||
|
||||
## Qué debe llevar el prompt
|
||||
|
||||
1. **Punto de partida obligatorio**: qué leer antes de nada — el `CLAUDE.md` del sitio, el corpus
|
||||
del frente (`doc/AVISOS.md` **primero**, `doc/decisiones.md`, `doc/backlog.md`) y el análisis o
|
||||
discusión previa **donde se tomó la decisión**.
|
||||
2. **Las tareas exactas, copiadas literalmente** de donde vivan, **marcadas como ya decididas** —
|
||||
el prompt debe dejar claro que no hace falta volver a preguntar el "qué". *«Literalmente»
|
||||
cierra la puerta a que el prompt parafrasee la tarea, que es de donde salen las premisas
|
||||
rancias.*
|
||||
3. **Para cada tarea**: qué cambiar exactamente, **en qué orden** si hay dependencias, y qué hacer
|
||||
si la realidad encontrada no coincide con lo documentado (parar y preguntar, nunca improvisar
|
||||
sobre algo en producción).
|
||||
4. ⛔ **El reparto de riesgo, explícito y en dos montones**: qué es de **bajo riesgo** —se aplica
|
||||
tras verificar el estado actual, sin confirmación paso a paso— y qué toca **algo que no se
|
||||
puede permitir perder** (el acceso de administración, la conectividad activa, los datos).
|
||||
**Eso segundo exige plan de reversión ANTES de aplicar**, y si algo no es como se esperaba,
|
||||
parar en vez de avanzar.
|
||||
5. ⛔ **Quién ejecuta cada paso, y con qué credencial.** Un paso no está especificado hasta que
|
||||
dice **quién** lo hace y quien lo escribe ha comprobado que **puede**. Si la respuesta es «el
|
||||
humano», **se dice en el encargo** y se le deja el bloque listo para su terminal.
|
||||
|
||||
⚠️ **Y un plan de reversión que nadie ha visto disparar es una promesa, no una red.** Si se puede
|
||||
ensayar barato, se ensaya; si no, se dice que no está ensayado. Su ventana hace indistinguible
|
||||
*«aún no ha disparado»* de *«ha fallado»*.
|
||||
|
||||
## Qué hace la sesión
|
||||
|
||||
1. Lee lo que el encargo manda leer, **en ese orden**.
|
||||
2. **Captura el estado ANTES** (`show running-config`, `get -o yaml`, `wg show`, lo que
|
||||
corresponda), **aplica el cambio**, **captura el estado DESPUÉS**, y **compara**. Los dos
|
||||
extremos, no solo el de después: sin el antes, el verde no prueba nada.
|
||||
3. ⛔ **Verifica el RESULTADO, no el estado declarado.** Un campo que dice que algo está arriba no
|
||||
es la prueba de que funcione: *un `gre_up: true` con `ospf_state: Down` **NO** es un éxito*. Se
|
||||
comprueba el comportamiento real —tráfico que pasa, la consulta que responde, el fichero que
|
||||
está donde tiene que estar—, y se exige el testigo que **discrimina**, no el que siempre sale
|
||||
verde (`§1` del Método).
|
||||
4. Si algo **no coincide** con lo esperado, **para y pregunta** — no decide sobre la marcha cómo
|
||||
resolverlo si afecta a producción.
|
||||
5. **Documenta lo aplicado** (antes/después, comandos usados) donde su frente documente, con el
|
||||
mismo formato que lo que ya hay ahí — no invente uno nuevo.
|
||||
6. **Actualiza el backlog**: `[x]` solo si se aplicó **y se verificó** de verdad, `[~]` si quedó
|
||||
parcial, `[ ]` con el motivo si no se pudo o si quedó como propuesta pendiente de confirmación
|
||||
humana.
|
||||
7. **Escribe en memoria el hecho persistente** (ver debajo).
|
||||
8. ⛔ **Si algo descubierto contradice una decisión escrita, lo dice explícitamente** en el resumen
|
||||
final — y si la contradice de frente, **PARA y reporta**: no se escribe otra decisión debajo
|
||||
(`§6` y `§7` del Método). Una arquitectura no se actualiza sola.
|
||||
|
||||
## Escribir en memoria tras ejecutar
|
||||
|
||||
**Por qué**: una tarea de ejecución cambia hechos que valen para **todas las sesiones futuras**, no
|
||||
solo para esta conversación. Por eso, además de documentarlo donde toque, se guarda en el sistema
|
||||
de memoria.
|
||||
|
||||
⭐ **Qué guardar, y es un PUNTERO**: guárdalo (`type: project` o `reference`) **apuntando** al
|
||||
backlog, al `readme.md` o al documento donde vive el detalle — **no dupliques el contenido en la
|
||||
memoria**. La memoria es el atajo para que una sesión futura sepa que algo existe y dónde mirarlo,
|
||||
no una segunda copia que derive de la primera (`§7`: escribirlo en dos sitios **no es prudencia, es
|
||||
crear la deriva**).
|
||||
|
||||
**Qué NO guardar**: si el dato ya es trivial de obtener leyendo la documentación —rutas, comandos
|
||||
exactos, credenciales—, no hace falta memoria aparte.
|
||||
|
||||
## Plantilla de prompt
|
||||
|
||||
*El esqueleto. El relleno —qué leer, qué máquinas, qué es intocable, dónde se documenta— lo pone
|
||||
el apéndice del frente.*
|
||||
|
||||
```
|
||||
Trabaja en <el sitio>.
|
||||
|
||||
Antes de nada, lee:
|
||||
- <el CLAUDE.md que aplique>
|
||||
- <doc/AVISOS.md del frente — PRIMERO>, <doc/decisiones.md>, <doc/backlog.md sección "<exacta>">
|
||||
- <el análisis/decisión previa donde se decidió esto>
|
||||
|
||||
Estas tareas YA ESTÁN DECIDIDAS (no preguntes el "qué", ejecuta el "cómo" con cuidado), en
|
||||
este orden:
|
||||
<cada tarea con su procedimiento exacto y, si depende de otra, en qué orden>
|
||||
|
||||
Reglas:
|
||||
1. Antes de cualquier cambio, captura el estado actual. Aplica. Vuelve a capturar y compara.
|
||||
2. Verifica el RESULTADO, no el estado declarado: exige el testigo que discrimina, no el que
|
||||
siempre sale verde.
|
||||
3. Si algo no coincide con lo documentado, PARA y pregúntame — no improvises sobre algo en
|
||||
producción.
|
||||
4. No toques nada que pueda cortar <el acceso que no se puede perder> sin dejar antes un plan
|
||||
de reversión o un camino alternativo. <Y di si ese plan está ensayado o no.>
|
||||
5. Documenta lo aplicado (antes/después) en <dónde>.
|
||||
6. Actualiza <el backlog>: [x] solo si se verificó, [~] si quedó parcial, [ ] con el motivo.
|
||||
7. Escribe en memoria el hecho resultante COMO PUNTERO — no dupliques contenido.
|
||||
8. Si algo contradice una decisión escrita, dilo explícitamente; si la contradice de frente,
|
||||
PARA y repórtamelo.
|
||||
|
||||
Al terminar, dame un resumen: qué se aplicó y verificó de verdad, qué quedó como propuesta
|
||||
pendiente de mi confirmación, y qué no se pudo hacer (y por qué).
|
||||
```
|
||||
110
.metodo/workflows/sesion-exploracion.md
Normal file
110
.metodo/workflows/sesion-exploracion.md
Normal file
@ -0,0 +1,110 @@
|
||||
# Workflow: sesión de EXPLORACIÓN — núcleo
|
||||
|
||||
<!-- metodo:puntero -->
|
||||
⛔ **Antes de tocar nada, lee el Método: [`repos/metodo/metodo.md`](../metodo.md)** — los
|
||||
raíles transversales, completos y con sus cicatrices. Si trabajas **dentro de un repo**, la copia que
|
||||
te toca es la suya (`.metodo/metodo.md`), que va sellada y la mide `metodo check`.
|
||||
⇒ Y **`§7`**: al arrancar se leen `AVISOS.md`, `decisiones.md` y `backlog.md`; **la bitácora NO**, se
|
||||
consulta por su índice. Arrancar cuesta ~400 k tokens en un frente maduro y **la bitácora es el 79 %**.
|
||||
⇒ *Este bloque existe porque el 2026-08-29 se midió que **7 de los 9 workflows del árbol no llevaban
|
||||
al Método**, incluidos los dos más usados. Una constitución sólo gobierna si algo lleva a ella: es su
|
||||
propio raíl `§8` —* ***un aviso que nadie lee no es un mecanismo de contención.***
|
||||
<!-- /metodo:puntero -->
|
||||
|
||||
> **Esto es el NÚCLEO: el método de mirar sin tocar, sin el frente.** Viaja a cada repo con
|
||||
> `.metodo/`. Qué se mira, con qué herramienta y por dónde se entra vive en su **apéndice**, que
|
||||
> **no viaja**: se lee sobre este núcleo, no en su lugar.
|
||||
|
||||
Para tareas de **lectura, medida y diagnóstico**: inventariar, leer, comparar, aislar una causa —
|
||||
**sin aplicar ningún cambio real**. Si la tarea sí implica cambiar algo, la que toca es la de
|
||||
**ejecución** (`sesion-ejecucion.md`), que tiene las salvaguardas que ésta no necesita.
|
||||
|
||||
⛔ **Solo-lectura no es "portarse bien": es una propiedad que hay que poder demostrar.** Todo lo de
|
||||
esta fase es reversible **por definición**, y por eso se puede iterar sin pedir permiso en cada
|
||||
paso — pero en el momento en que algo module estado, aunque sea "para confirmar la hipótesis", ya
|
||||
**no** es esta sesión (`§12` del Método).
|
||||
|
||||
## Cuándo se usa
|
||||
|
||||
Cuando la tarea consiste en inventariar, leer, comparar o diagnosticar, y **nunca** en modificar
|
||||
configuración real. El disparador concreto de cada frente está en su apéndice.
|
||||
|
||||
## Qué debe llevar el prompt
|
||||
|
||||
1. **Punto de partida obligatorio**: qué leer antes de nada — el `CLAUDE.md` del sitio y el corpus
|
||||
del frente (`doc/AVISOS.md` **primero**, `doc/decisiones.md`, `doc/backlog.md`), más el
|
||||
documento de arquitectura o análisis que aplique.
|
||||
2. **La tarea exacta, copiada literalmente** de donde viva (sección y checkboxes). *«Literalmente»
|
||||
cierra la puerta a que el prompt parafrasee la tarea, que es de donde salen las premisas
|
||||
rancias.*
|
||||
3. ⭐ **Criterios de validación**: si la fuente no los enumera, **cada sub-checkbox de la sección es
|
||||
por defecto un criterio**. Es lo que convierte un encargo en algo **evaluable** — sin esto, "he
|
||||
mirado" y "está comprobado" son indistinguibles.
|
||||
4. ⛔ **El encargo negativo, ENUMERANDO LOS VERBOS PROHIBIDOS** — no un genérico «no cambies nada».
|
||||
Se listan los gestos concretos que en ese frente sí modificarían estado *(instalar, aprobar,
|
||||
inicializar, aplicar, reiniciar, tocar el firewall…)*, porque un «no cambies nada» abstracto
|
||||
deja a la sesión decidiendo qué cuenta como cambio. La **forma** es del núcleo; **la lista la
|
||||
pone el apéndice**.
|
||||
⇒ Y con su cierre: si detecta algo mejorable, **lo documenta como hallazgo o recomendación, no
|
||||
lo aplica**.
|
||||
|
||||
## Qué hace la sesión
|
||||
|
||||
1. Lee lo que el encargo manda leer, **en ese orden**.
|
||||
2. Explora y mide lo necesario — puede conectarse a lo que haga falta **solo para leer**, nunca
|
||||
para configurar.
|
||||
3. **Documenta los hallazgos** donde su frente documente, con el mismo formato que lo que ya hay
|
||||
ahí (úsalo de plantilla). ⚠️ **No crea documento aparte** salvo que el hallazgo sea **sustancial
|
||||
y merezca su propio archivo** — un documento nuevo por cada exploración es ruido, no corpus.
|
||||
4. ⭐ **Evalúa honestamente, contra los criterios, si la tarea está completa, parcial o
|
||||
bloqueada.** No "ha ido bien": contra los criterios, uno a uno.
|
||||
5. **Actualiza el backlog**: marca cada checkbox (`[x]` **solo si se verificó de verdad**, `[~]` si
|
||||
quedó parcial, `[ ]` con el motivo si no se pudo) y enlaza lo que haya escrito.
|
||||
6. ⛔ **Si algo descubierto contradice una decisión escrita** —una arquitectura, una `D` cerrada—,
|
||||
**lo dice explícitamente** en el resumen final, y si la contradice de frente **PARA y reporta**
|
||||
(`§6` del Método). Nada se actualiza solo.
|
||||
7. ⛔ **Si lo explorado revela una tarea de configuración que convendría aplicar, la deja
|
||||
PROPUESTA — no la ejecuta.** Esa propuesta es la semilla de una futura sesión de **ejecución**,
|
||||
con su propio encargo.
|
||||
|
||||
⚠️ **Lo que este núcleo NO trae, y se dice en vez de disimularlo**: predicción, testigo y control
|
||||
negativo. Ninguno de los workflows de los que sale lo tenía — toda su disciplina es de efectos
|
||||
secundarios («qué no tocar», «para y pregunta»). Es un hueco **conocido y medido**, no un olvido, y
|
||||
se cierra por núcleo cuando toque.
|
||||
|
||||
## Plantilla de prompt
|
||||
|
||||
*El esqueleto. El relleno —qué leer, qué se mira, con qué herramienta, qué verbos están
|
||||
prohibidos— lo pone el apéndice del frente.*
|
||||
|
||||
```
|
||||
Trabaja en <el sitio>.
|
||||
|
||||
Antes de nada, lee:
|
||||
- <el CLAUDE.md que aplique>
|
||||
- <doc/AVISOS.md del frente — PRIMERO>, <doc/decisiones.md>, <doc/backlog.md sección "<exacta>">
|
||||
- <el documento de arquitectura/análisis que aplique>
|
||||
|
||||
Tarea a ejecutar (es de EXPLORACIÓN/LECTURA, no de configuración):
|
||||
<pegar aquí el bloque exacto, copiado literalmente>
|
||||
|
||||
Criterios de validación:
|
||||
<enumerarlos; si no los hay, cada sub-checkbox de la sección es un criterio>
|
||||
|
||||
Haz lo siguiente:
|
||||
1. Explora/mide lo necesario para cubrir cada punto. NO <lista de verbos prohibidos del
|
||||
frente: instalar, aprobar, inicializar, aplicar, reiniciar, tocar el firewall...> — aunque
|
||||
detectes algo mejorable, documéntalo como recomendación, no lo apliques.
|
||||
2. Documenta lo encontrado en <dónde>, siguiendo el formato de lo que ya hay ahí. No crees un
|
||||
documento aparte salvo que el hallazgo lo merezca.
|
||||
3. Vuelve a <el backlog> y marca cada checkbox: [x] solo si lo verificaste de verdad, [~] si
|
||||
quedó parcial, [ ] anotando el motivo. Enlaza lo que hayas escrito.
|
||||
4. Evalúa contra los criterios si la tarea queda completa, parcial o bloqueada — y dilo.
|
||||
5. Si algo contradice una decisión escrita, dilo explícitamente; si la contradice de frente,
|
||||
PARA y repórtamelo.
|
||||
6. Si descubres una tarea de configuración que convendría aplicar, DÉJALA PROPUESTA. No la
|
||||
ejecutes.
|
||||
|
||||
Al terminar, dame un resumen breve de qué se confirmó, qué se descartó, qué quedó propuesto y
|
||||
qué quedó pendiente.
|
||||
```
|
||||
202
.metodo/workflows/sesion-orquestadora.md
Normal file
202
.metodo/workflows/sesion-orquestadora.md
Normal file
@ -0,0 +1,202 @@
|
||||
# Workflow: sesión ORQUESTADORA — núcleo
|
||||
|
||||
<!-- metodo:puntero -->
|
||||
⛔ **Antes de tocar nada, lee el Método: [`repos/metodo/metodo.md`](../metodo.md)** — los
|
||||
raíles transversales, completos y con sus cicatrices. Si trabajas **dentro de un repo**, la copia que
|
||||
te toca es la suya (`.metodo/metodo.md`), que va sellada y la mide `metodo check`.
|
||||
⇒ Y **`§7`**: al arrancar se leen `AVISOS.md`, `decisiones.md` y `backlog.md`; **la bitácora NO**, se
|
||||
consulta por su índice. Arrancar cuesta ~400 k tokens en un frente maduro y **la bitácora es el 79 %**.
|
||||
⇒ *Este bloque existe porque el 2026-08-29 se midió que **7 de los 9 workflows del árbol no llevaban
|
||||
al Método**, incluidos los dos más usados. Una constitución sólo gobierna si algo lleva a ella: es su
|
||||
propio raíl `§8` —* ***un aviso que nadie lee no es un mecanismo de contención.***
|
||||
<!-- /metodo:puntero -->
|
||||
|
||||
> **Esto es el NÚCLEO: el método de coordinar, sin el frente.** Viaja a cada repo con `.metodo/`.
|
||||
> Lo que sea de un frente concreto —qué backlogs hay, qué rutas, qué máquinas, qué es intocable—
|
||||
> vive en su **apéndice**, y un apéndice **no viaja**: se lee sobre este núcleo, no en su lugar.
|
||||
> ⇒ En el árbol multi-repo el apéndice es `apendices/arbol-proyectos.md`; en un repo que se clona
|
||||
> solo, el frente es **ese repo** y su corpus (`doc/AVISOS.md` · `doc/decisiones.md` ·
|
||||
> `doc/backlog.md`).
|
||||
|
||||
Esta sesión es el **punto central de coordinación**. No ejecuta infraestructura directamente
|
||||
(salvo cambios menores y seguros), sino que:
|
||||
|
||||
1. Mantiene el contexto global entre sesiones de ejecución y exploración.
|
||||
2. Hace refinement del backlog a medida que llegan resultados.
|
||||
3. **Genera los prompts** de las sesiones satélite — su entregable *es* el prompt.
|
||||
4. Recibe sus resúmenes y decide el siguiente paso.
|
||||
5. Actualiza documentación, memoria y backlog cuando hace falta.
|
||||
|
||||
⛔ **Y su frontera no la decide «¿sé hacerlo?» ni «¿es peligroso?», sino «¿esto tiene un TIPO DE
|
||||
SESIÓN PROPIO?»** — si lo tiene, **se delega aunque sea texto, aunque sea barato y aunque sepas
|
||||
hacerlo** (`§7` del Método). Un documento que describe un tipo de sesión **se lee como un método que
|
||||
aplicar uno mismo**, y ése es el mecanismo del fallo.
|
||||
|
||||
## Cuándo se usa
|
||||
|
||||
Siempre que haya que coordinar en vez de ejecutar. Es el rol por defecto salvo que se diga otra
|
||||
cosa: las sesiones de exploración y ejecución son **satélites** que ésta lanza y recibe.
|
||||
⇒ El disparador concreto de cada frente está en su apéndice.
|
||||
## Cómo arranca una sesión orquestadora nueva
|
||||
|
||||
Cuando la sesión actual se agota de contexto, hay que abrir una nueva que retome
|
||||
exactamente el mismo rol. El prompt de continuación debe incluir:
|
||||
|
||||
1. **Leer CLAUDE.md** — acceso a infraestructura, siempre lo primero.
|
||||
2. **Leer MEMORY.md** — índice de hechos persistentes del proyecto.
|
||||
3. **Leer los backlogs vivos del frente** — estado de lo hecho, lo que está en curso y lo
|
||||
pendiente. **Cuáles son los tuyos lo dice el apéndice de tu árbol o el `CLAUDE.md` de tu repo**,
|
||||
no este fichero: el núcleo pone la **forma** (léelos antes de decidir nada), y **la lista es de
|
||||
quien la tiene**. *(Aquí iba una lista de tres rutas de un árbol concreto. Se retiró el
|
||||
2026-08-30 antes de repartirse: viajaba a 27 repos que no tienen ninguna de las tres, contra
|
||||
«viaja lo que sirve a un repo que sólo se tiene a sí mismo».)*
|
||||
4. **Estado de la sesión anterior**: qué prompts se lanzaron y cuáles están
|
||||
esperando respuesta. Si hay un prompt pendiente de resultado, indicarlo
|
||||
explícitamente para que la nueva sesión sepa que su primer input del usuario
|
||||
puede ser ese resultado.
|
||||
5. **Instrucción de rol**: "tu rol es el de sesión orquestadora — no ejecutes
|
||||
infraestructura directamente salvo cambios menores y seguros; genera prompts
|
||||
para las sesiones de exploración/ejecución siguiendo los workflows de esta
|
||||
carpeta".
|
||||
|
||||
## Qué hace la sesión orquestadora cuando recibe un resultado
|
||||
|
||||
Cuando el usuario pega el resumen de una sesión de exploración/ejecución:
|
||||
|
||||
1. Actualiza el backlog (`[x]`, `[~]`, `[ ]` con notas).
|
||||
2. Si la sesión produjo archivos nuevos, hace `git add + commit + push` al repo
|
||||
de Kubernetes (`git.c2et.com/SECOPS/kubernetes.git`).
|
||||
3. Actualiza o crea memorias si hay hechos nuevos persistentes.
|
||||
4. Decide el siguiente paso: ¿hay otra tarea lista para ejecutar? ¿hay que
|
||||
refinar algo antes? ¿hay un bloqueante que resolver con el usuario?
|
||||
5. Propone el siguiente prompt o pregunta al usuario qué quiere atacar.
|
||||
|
||||
## ⛔ Las cifras y los estados de un prompt SE MIDEN AL ESCRIBIRLO, no se recuerdan
|
||||
|
||||
Un prompt es una **afirmación**, y una afirmación rancia le cuesta tiempo a la sesión que la
|
||||
recibe. *(Cicatriz 2026-07-27, dos en el mismo encargo: dije «suite en 438 verdes» cuando iban por
|
||||
**572** —cifra de dos días antes— y monté un plan de verificación sobre dos hechos **incompatibles
|
||||
entre sí**: «la Raspberry es tu punto de vista» y «brume-5-1 no está emparejado». Sin hub, el plan
|
||||
sale vacío y allí solo se puede medir la ausencia. La sesión cazó las dos y preguntó, que es lo
|
||||
correcto — pero el coste fue suyo.)*
|
||||
|
||||
Antes de mandar un prompt: **mide** el número de tests, la versión instalada, qué device está
|
||||
emparejado, qué hay desplegado. Son dos comandos. Y si un dato no lo puedes medir, escríbelo como
|
||||
lo que es —*«creo que…, verifícalo»*— en vez de como un hecho.
|
||||
|
||||
⛔ **Y un paso de un encargo no está especificado hasta que dice QUIÉN lo ejecuta — y tú has
|
||||
comprobado que PUEDE.** Un prompt describe *qué* hacer; la capacidad del actor es una premisa más, y
|
||||
de las que no se ven hasta que la sesión llega allí y choca. *(Cicatriz 2026-08-12, y son **dos en el
|
||||
mismo hilo, con la misma forma**: (a) la orquestadora escribió en una decisión cerrada
|
||||
—`R16`— que el token de Vault lo **acuñaría `mcp-secrets`**, y esa herramienta solo sabe
|
||||
`harbor` y `git` (`TokenKind = Literal["harbor","git"]`) — y no podría saber más, porque **publica
|
||||
en Vault** y ése es justo el token que abre Vault; (b) el encargo siguiente decía «la sesión crea la
|
||||
política y el token con `kubectl exec vault-0`», y la sesión lo midió al llegar:
|
||||
`auth/token/create → deny`, `vault policy read → 403`. El único token que tiene contra Vault es el
|
||||
de ESO, **solo-lectura de KV**; el root vive en un GPG tras la passphrase DR que **por diseño** no
|
||||
entra en una sesión.)*
|
||||
⇒ Antes de escribir un paso, pregunta **con qué credencial se ejecuta** y si el que la tiene es
|
||||
quien va a estar delante. Si la respuesta es «el humano», **dilo en el encargo** y deja el bloque
|
||||
listo para su terminal — no lo redactes como si lo fuera a hacer la sesión.
|
||||
⇒ ⭐ Y el patrón que las une, que es el que hay que buscarse a uno mismo: **especificar el QUÉ sin
|
||||
medir el QUIÉN.** Las dos veces la mecánica era correcta y el actor no podía.
|
||||
|
||||
⛔ **Y un DIAGNÓSTICO heredado de otra sesión también es una afirmación, no un dato.** *(Tercera
|
||||
premisa falsa de la misma racha: el encargo de F11.13 decía «a `brume-5-1` le falta la zona `wgt`»
|
||||
—diagnóstico de la sesión anterior, copiado como hecho—. La zona **ya estaba**; lo que faltaba era
|
||||
la **ruta de vuelta** (`ospf: false`), y en el otro nodo igual.)* Cuando repitas la causa que otro
|
||||
encontró, **repítela como hipótesis**: *«la sesión anterior lo atribuyó a X — verifícalo antes de
|
||||
arreglar»*. Un diagnóstico correcto sobre un síntoma no es un diagnóstico verificado.
|
||||
|
||||
## ⭐ Cómo se prioriza la deuda: INERTE contra MORDIENDO *(Xavier, 2026-08-02)*
|
||||
|
||||
**`manabo` es una plataforma de aprendizaje, y que queden cosas a medias es el modo de
|
||||
funcionamiento, no un defecto.** Xavier rota prioridades entre proyectos **a propósito**.
|
||||
|
||||
⇒ Por eso *«hecho / a medias»* es un mal criterio para ordenar trabajo, y la orquestadora lo ha usado
|
||||
mal más de una vez —*«sin deuda antes de empezar la fase»*—. La distinción útil es otra:
|
||||
|
||||
> **¿está a medias e INERTE, o a medias y MORDIENDO?**
|
||||
|
||||
*(La medida que lo enseña, 2026-08-02: el **etcd** de `niflheim` llevaba **8 meses** a medias **sin
|
||||
molestar a nadie**. Su **apiserver** llevaba lo mismo, y se comía **un tercio de la admisión del
|
||||
cluster entero** —cert-manager, metallb, external-secrets, ingress-nginx— **en silencio**. Misma
|
||||
antigüedad, mismo «a medias», y uno de los dos era una avería en producción.)*
|
||||
|
||||
⇒ Lo que hay que preguntarse de cada cosa abierta no es cuánto lleva ahí, sino **qué está costando
|
||||
ahora mismo**. Y si la respuesta es «no se sabe», eso ya es la respuesta: **lo que no se mide, muerde
|
||||
en silencio**.
|
||||
|
||||
|
||||
|
||||
### ⛔ En una pieza con CARA HUMANA el gate tiene DOS MITADES, y ninguna sustituye a la otra *(Xavier, 2026-08-18)*
|
||||
|
||||
La orquestadora escribió en el encargo de `I11.10`: *«el criterio de aceptación no es una tabla de
|
||||
mutaciones: son gestos»*. **Sustitución, y Xavier la corrigió: es un COMPLEMENTO.**
|
||||
|
||||
**Porque cada mitad tapa el agujero de la otra:**
|
||||
- **Solo gestos** ⇒ un botón que hace **lo que no debe** también es un gesto. Pasa el listón con el
|
||||
sistema roto, y encima con la sensación de haber cumplido el criterio nuevo.
|
||||
- **Solo mutaciones** ⇒ una pantalla puede tener **todo en rojo cuando toca** y seguir costando
|
||||
cuatro gestos. Verde entero sobre algo que **nadie puede usar** — que es exactamente la deriva que
|
||||
`D23` vino a cortar.
|
||||
|
||||
⇒ **Las dos van en el entregable, y por separado**: la tabla de mutaciones dice que **es correcto**,
|
||||
el recuento de gestos dice que **es usable**. Ninguna de las dos es el gate por sí sola, y una verde
|
||||
con la otra roja **no es media pieza: es una pieza que no está**.
|
||||
## ⛔ Si una decisión DESBLOQUEA una pieza, el prompt sale EN EL MISMO TURNO
|
||||
|
||||
*(Xavier, 2026-08-18.)* No se espera a que lo pidan. Una decisión tomada y una pieza desbloqueada
|
||||
**es un encargo listo**, y dejarlo para el turno siguiente le cuesta al usuario un mensaje entero
|
||||
para decir *«adelante»* — que es tiempo suyo gastado en darle permiso a algo que ya había aprobado.
|
||||
|
||||
⭐ **La señal de que lo estás haciendo mal es literal y se busca en tu propio texto:** si el turno
|
||||
termina con **«dime y te lo escribo»**, **«cuando quieras te lo preparo»** o cualquier variante, es
|
||||
que **ya deberías haberlo escrito**. *(Cicatriz del mismo día: la orquestadora cerró así el turno
|
||||
inmediatamente anterior a que Xavier pidiera este raíl — la decisión estaba tomada, la pieza
|
||||
desbloqueada y el encargo sin escribir.)*
|
||||
|
||||
**Las dos excepciones, y solo esas dos:**
|
||||
- **Desbloquea VARIAS piezas** ⇒ se dice cuáles, se recomienda una **y se escribe la recomendada**.
|
||||
No se pregunta cuál antes de escribir ninguna.
|
||||
- **La pieza necesita un gesto que solo puede hacer el usuario** (firmar, generar una clave,
|
||||
conectarse por otra red) ⇒ el prompt se escribe **igual**, con ese gesto marcado como suyo y el
|
||||
hueco señalado. Un encargo al que le falta un dato del usuario sigue siendo un encargo.
|
||||
|
||||
⇒ Es `feedback-ejecutar-no-anunciar` un piso más arriba: **la tool call en el
|
||||
mismo turno** vale también para el entregable, y el entregable de la orquestadora **es el prompt**.
|
||||
|
||||
## Qué puede hacer directamente (sin sub-sesión)
|
||||
|
||||
Cambios menores, seguros y reversibles; consultas de solo lectura; documentación, memoria y
|
||||
backlog. **La lista concreta de lo que eso significa en tu frente está en su apéndice** — depende
|
||||
de qué máquinas hay y de qué se puede permitir perder.
|
||||
|
||||
> ⛔ **PERO NO mientras una sesión esté corriendo sobre esos mismos ficheros.** Mientras una
|
||||
> sub-sesión está viva, **los docs de su alcance son SUYOS**: su `backlog.md`, su `AVISOS.md`, su
|
||||
> `bitacora.md`. La orquestadora escribe **antes de lanzarla o después de que entregue** — nunca
|
||||
> durante.
|
||||
>
|
||||
> *(Cicatriz 2026-08-01: la orquestadora avisó por escrito de que «dos sesiones editando el mismo
|
||||
> backlog es como se pierde texto»… y acto seguido metió una ficha y una corrección en los ficheros
|
||||
> que una sesión viva estaba editando. Sobrevivieron **por suerte** —la herramienta llegó a avisar de
|
||||
> que el fichero había cambiado bajo sus pies—, y quedaron **sin commitear y mezcladas** con el
|
||||
> trabajo ajeno.)*
|
||||
>
|
||||
> **Los dos daños, y el segundo es peor que perder el texto:**
|
||||
> · La sesión puede tener en memoria una copia **anterior** y escribir encima ⇒ el cambio desaparece
|
||||
> sin que nadie lo note.
|
||||
> · Y aunque sobreviva, **aparece en el diff de la sesión como si fuera suyo** — o alguien lo
|
||||
> revierte por no reconocerlo.
|
||||
>
|
||||
> **Si el cambio no puede esperar**: no lo escribas — **mándaselo a la sesión** para que lo integre
|
||||
> ella, que es quien tiene el fichero. Y si ya lo escribiste, **dilo enseguida y enumera exactamente
|
||||
> qué tocaste**, para que su entrega se pueda reconciliar.
|
||||
|
||||
## Qué delega siempre a una sub-sesión
|
||||
|
||||
- Cualquier tarea que implique múltiples pasos en la infraestructura.
|
||||
- Análisis de compatibilidad o exploración de estado desconocido.
|
||||
- Instalaciones o configuraciones en servidores/nodos.
|
||||
- Cambios en Kubernetes que afecten a workloads en producción.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user