feat(episode): DEPURA_hallazgo-statefact-guard-es-posttooluse_S20260718.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD
Skill: NONE | Type: design
Summary: EPISODIO 1 — MNEMO_PRE_DIGEST: 🛑 Hallazgo: `statefact-guard` es **PostToolUse**
This commit is contained in:
parent
22a174a1d1
commit
428a5d6237
1 changed files with 27 additions and 0 deletions
|
|
@ -0,0 +1,27 @@
|
||||||
|
---
|
||||||
|
episode_id: "c02d4ced-f91c-4914-b3c4-c815644a6401"
|
||||||
|
puente_flat: "DEPURA_hallazgo-statefact-guard-es-posttooluse_S20260718.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
|
||||||
|
session_code: "S20260718.ECC_TOOLBOX_SURFACER"
|
||||||
|
acto_dialogico: "informar"
|
||||||
|
actor_flujo: "multi_actor"
|
||||||
|
criticidad_aegis: "low"
|
||||||
|
skill_dominante: "NONE"
|
||||||
|
fase_proyecto: "operations"
|
||||||
|
tipo_semantico: "design"
|
||||||
|
summary_one_line: "EPISODIO 1 — MNEMO_PRE_DIGEST: 🛑 Hallazgo: `statefact-guard` es **PostToolUse** — no puede "
|
||||||
|
source_type: "claude_code"
|
||||||
|
trust_boundary: "internal"
|
||||||
|
created_at: "2026-07-18T22:49:12.911112+00:00"
|
||||||
|
relectura_tagged: false
|
||||||
|
forgejo_commit_sha: "pending"
|
||||||
|
---
|
||||||
|
|
||||||
|
**PARA — la comprensión ecosistémica acaba de evitar un error serio.** Leí el hook antes de tocarlo, y encontré algo que cambia la ejecución:
|
||||||
|
|
||||||
|
## 🛑 Hallazgo: `statefact-guard` es **PostToolUse** — no puede denegar per-write
|
||||||
|
|
||||||
|
El hook `mega-hook-statefact-guard.py` está registrado en **PostToolUse** (Write/Edit/Bash) + Stop + SessionStart. Un hook PostToolUse **corre DESPUÉS de que el write ya ocurrió** — en Claude Code, el "deny" real solo existe en **PreToolUse** (bloquear antes). El draft T-11 asumió un simple "flip advisory→deny", pero eso es **estructuralmente imposible** en este hook sin re-arquitecturarlo. No es un bug del draft — es información que solo se ve leyendo el hook (exactamente la clase de cosa que esta sesión viene enseñando: verificar antes de actuar). Me detengo aquí en vez de fabricar un deny falso o re-arquitecturar un hook vivo a las bravas. Tu GO fue "promover", pero el mecanismo que asumimos no aplica — así que necesito tu decisión sobre **cómo** hacer que doc-lifecycle muerda de verdad. ## 📖 La historia de esta decisión (mecanismo de enforcement)
|
||||||
|
|
||||||
|
**Lo que realmente se decide** (reframe): no es "no se puede promover". Es **"¿con qué mecanismo hacemos que doc-lifecycle bloquee de verdad, dado que su hook corre *después* del write?"** El intent tuyo (que muerda) sigue vivo; solo cambia el *cómo*. **Consecuencias por camino:**
|
||||||
|
|
||||||
|
- 🔴 **A — Fabricar un guard PreToolUse nuevo** que deniegue cada Write/Edit a un carrier de hecho-de-estado que introduzca drift. *Es el deny per-write "puro".* **Blast radius ALTO:** corre antes de cada write de doc; un falso positivo te bloquea trabajo legítimo. Es una **fabricación nueva** (AR-AP7 consultar grafo de hooks + definir con precisión "qué drift merece bloqueo" + fail-open + override TTL + ≥5 tests).
|
||||||
Loading…
Reference in a new issue