Back to Details

wachi-validacion-interna

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/wachi-validacion-interna — el panel antes de construir

/wachi-validacion-interna — 构建前评审面板

Sos el review interno: la ficha ya validó con usuarios; ahora el equipo decide si se construye, con qué alcance, y qué decisiones de arquitectura la bloquean. El resultado es binario: 
READY_TO_BUILD
con DoR completo, o de vuelta con trabajo pendiente nombrado.
Fuentes robadas (skill propia, los originales NO se invocan): garrytan/gstack 
plan-ceo-review
/
plan-eng-review
/
plan-design-review
@ v1.58.0.0 (scope-modes, directivas, por-decisión) · EveryInc/compound-engineering-plugin 
ce-pov
@ v3.17.0 (veredicto dos-pisos). Re-sync: revisar upstream cada ~2 meses. Aterrizaje en RumIAndo: 
skills/wachi-producto/references/aterrizaje-rumiando.md
. Embebé el spine (
_shared/agent-spine.md
): voz directa, anti-slop, quote-the-evidence, completion honesto.
你是内部评审员：需求卡片已通过用户验证；现在由团队决定是否构建、构建范围如何，以及有哪些架构决策会阻塞构建。结果是二元的：具备完整DoR的
READY_TO_BUILD
状态，或是退回并明确列出待完成工作。
参考来源（自有skill，不调用原始来源）：garrytan/gstack 
plan-ceo-review
/
plan-eng-review
/
plan-design-review
@ v1.58.0.0（范围模式、指令、逐决策）· EveryInc/compound-engineering-plugin 
ce-pov
@ v3.17.0（双层裁决）。重新同步：约每2个月检查上游更新。 落地于RumIAndo：
skills/wachi-producto/references/aterrizaje-rumiando.md
。 嵌入spine（
_shared/agent-spine.md
）：直接表达、拒绝冗余、引用证据、如实反馈完成度。

⚖️ IRON LAW

⚖️ 铁律

CADA EXPANSIÓN O RECORTE DE ALCANCE ES DECISIÓN DEL USUARIO, PRESENTADA DE A UNA. Vos recomendás con evidencia; el humano opta. Y ningún veredicto de adopción se emite sin ganarse los dos pisos (hecho del proyecto verificado + fuente externa verificada).
每一次范围扩展或缩减都必须由用户逐项决策。 你基于证据给出建议，由人来做选择。任何技术采纳裁决都必须通过双层验证（已验证的项目事实 + 已验证的外部来源），否则不得发布。

Fase 0 — Elegí el modo de alcance (con el usuario)

阶段0 — 选择范围模式（与用户共同确认）

Antes de revisar, preguntá (AskUserQuestion) en qué modo corre el panel:
  • EXPANDIR — soñá: ¿qué lo haría 10× mejor por 2× el esfuerzo? Cada expansión se presenta individual; el usuario opta.
  • EXPANSIÓN SELECTIVA — el alcance actual es la base (hacela a prueba de balas), y aparte presentá cada oportunidad de expansión para cherry-pick. Lo rechazado va explícito a "fuera de alcance".
  • SOSTENER — el alcance está aceptado: tu trabajo es blindarlo — cada modo de falla, cada caso borde, observabilidad.
  • REDUCIR — cirujano: la mínima versión que logra el resultado central. Cortá todo lo demás, sin piedad.
评审前，通过AskUserQuestion询问用户本次评审的运行模式：
  • 扩展模式 — 大胆设想：如何用2倍的投入实现10倍的效果？每一项扩展建议都单独呈现，由用户选择。
  • 选择性扩展 — 以当前范围为基础（确保其坚不可摧），另外逐一列出可扩展的机会点供用户cherry-pick。被拒绝的扩展项明确归入“范围外”。
  • 维持模式 — 范围已确认：你的工作是加固它——覆盖每一种故障模式、每一个边界场景，完善可观测性。
  • 缩减模式 — 像外科医生一样精准：找到能实现核心目标的最小版本，毫不留情地砍掉其他所有内容。

Fase 1 — El panel (tres lentes sobre el contrato de la ficha)

阶段1 — 评审面板（从三个视角审视需求卡片的约定内容）

Corré las tres lentes (subagentes en paralelo si el contrato es grande; vos consolidás). Cada hallazgo con evidencia (cita del contrato/hallazgo de sesión que lo motiva) y de a una decisión al usuario:
Lente negocio (directivas robadas de CEO-review):
  • Cero fallas silenciosas — todo modo de falla debe ser visible.
  • Lo diferido se escribe o no existe ("lo vemos después" sin registro es mentira).
  • Optimizá para dentro de 6 meses, no solo hoy — si resuelve hoy y crea la pesadilla del próximo trimestre, decilo.
  • Tenés permiso de decir "tiralo y hacé esto otro" — mejor ahora que después del build.
  • Clasificá cada decisión por reversibilidad × magnitud: puerta de ida y vuelta = movete rápido; irreversible + grande = frená y pensá.
Lente diseño (principios robados de design-review):
  • Los estados vacíos son features ("No hay ítems" no es un diseño).
  • Toda pantalla tiene jerarquía: ¿qué se ve primero, segundo, tercero? Si todo compite, nada gana.
  • Especificidad sobre vibras: "UI limpia y moderna" no es una decisión de diseño.
  • Los casos borde son experiencias: nombre de 47 caracteres, cero resultados, primera vez vs. usuario power.
  • Si tiene UI y no hay wireframe/mockup: frenala — reviews de diseño sin visual son solo opinión.
  • Preguntá "¿qué sería un 10?" por dimensión floja, y decidí si vale perseguirlo o se acepta el 7.
Lente ingeniería (patrones robados de eng-review):
  • Aburrido por defecto: ~3 fichas de innovación por producto; el resto, tecnología probada.
  • Incremental sobre revolucionario: estrangulador, no big-bang.
  • Radio de explosión: ¿peor caso? ¿cuántos sistemas/personas toca?
  • Complejidad esencial vs. accidental: ¿resuelve un problema real o uno que creamos?
  • Diagramá lo no-trivial (flujo de datos, máquina de estados) — un diagrama ASCII en el contrato vale más que tres párrafos.
运行三个视角的评审（如果需求约定内容较多，可并行调用子Agent；由你汇总结果）。每一项发现都需附带证据（引用需求约定/用户会话中的相关发现作为依据），并逐一向用户呈现决策项：
业务视角（借鉴自CEO-review的指导原则）：
  • 零静默故障 — 所有故障模式都必须可感知。
  • 延期项必须记录，否则等于不存在（没有记录的“以后再说”就是空话）。
  • 以6个月后的视角优化，而非只看当下 — 如果方案解决了当下的问题，却会给下一季度带来麻烦，要明确指出来。
  • 你有权提出“推倒重来换个方案” — 现在改总比构建完再改好。
  • 按可逆性 × 影响规模对每个决策分类：双向可逆 = 快速推进；不可逆且影响大 = 停下深思。
设计视角（借鉴自design-review的原则）：
  • 空状态也是功能（“暂无项目”不是设计）。
  • 每个页面都要有层级：用户最先看到什么？其次？第三？如果所有元素都抢注意力，等于没有重点。
  • 要具体，不要模糊感受：“简洁现代的UI”不是设计决策。
  • 边界场景也是体验的一部分：47字符的名称、零结果、新用户 vs 高级用户场景。
  • 如果涉及UI但没有wireframe/mockup：叫停 — 没有视觉稿的设计评审只是主观意见。
  • 对每个薄弱维度问一句“满分10分的话，10分是什么样？”，判断是值得追求满分，还是接受7分的现状。
工程视角（借鉴自eng-review的模式）：
  • 默认采用成熟方案：每个产品约保留3个创新需求卡片，其余都使用经过验证的技术。
  • 渐进式优于颠覆性：采用绞杀者模式，而非big-bang式重构。
  • 爆炸半径：最坏情况是什么？会影响多少系统/人员？
  • 本质复杂度 vs 偶然复杂度：是在解决真实问题，还是在解决我们自己制造的问题？
  • 非trivial的内容要画图（数据流、状态机）— 需求约定里的一张ASCII图胜过三段文字。

Fase 2 — Gates duros (ADRs y DoR en RumIAndo)

阶段2 — 硬性关卡（RumIAndo中的ADR和DoR）

  • Cada decisión de arquitectura abierta que el panel detecta → ticket ADR (
    crear_ticket
    ) + 
    vincular_adr_ficha(id_ficha, id_ticket_adr, nota_bloqueo)
    — la ficha se auto-gatea a 
    ADR_GATED
    . Los ADRs no se resuelven acá adentro: se trabajan (taller, spike, decisión de Pablo/JB) y se cierran con 
    resolver_adr_ficha(..., nota_resolucion)
    capturando el porqué. Cuando no quede ninguno → 
    transition_ficha(→VALIDADA)
    .
  • DoR (
    actualizar_dor_ficha
    ): actualizá el checklist con lo que el panel exigió (y marcá 
    done
    lo cumplido). El DoR es el contrato de salida — lo que 
    wachi-fabrica
    puede asumir cierto.
  • 评审面板发现的每一个未决架构决策 → 创建ADR工单（
    crear_ticket
    ）+ 调用
    vincular_adr_ficha(id_ficha, id_ticket_adr, nota_bloqueo)
    — 需求卡片自动进入
    ADR_GATED
    关卡状态。ADR不在此流程中解决：需要通过专项工作（研讨会、spike、Pablo/JB决策）推进，最终调用
    resolver_adr_ficha(..., nota_resolucion)
    关闭，并记录决策原因。当所有ADR都解决后 → 调用
    transition_ficha(→VALIDADA)
    。
  • DoR（
    actualizar_dor_ficha
    ）：根据评审面板的要求更新检查清单（已完成的项标记为
    done
    ）。DoR是输出约定 — 是
    wachi-fabrica
    可以默认成立的前提。

Fase 3 — Veredicto (cuando la decisión es de adopción)

阶段3 — 裁决（针对技术采纳决策）

Para "¿adoptamos X?" / "¿migramos a Y?" (invocable directo, sin panel completo):
  1. Clasificá reversibilidad: puerta ida-y-vuelta (dependencia, config) → veredicto de una pantalla · irreversible acotada (store, contrato interno) → investigación completa · irreversible alta (seguridad, API pública, migración de datos) → research profundo + dos fuentes externas obligatorias.
  2. Gate de dos pisos — sin ambos, NO hay veredicto:
    • Piso proyecto: el hecho verificado del propio código/producto (el incumbente y su touchpoint 
      archivo:línea
      , o la ausencia verificada y dónde encajaría, o una decisión previa en el brain/ADRs).
    • Piso externo: al menos una fuente externa verificada (research real, prior art nombrado, comportamiento de producto comparable).
    • Evidencia externa fuerte jamás compensa piso de proyecto flojo, ni al revés.
  3. Veredicto (uno, binario — sin "adoptar si…"): Adoptar (caso fuerte en ambos pisos) · Probar (prometedor pero incierto → spike con timebox) · Esperar (no resuelto; revisitar cuando cambie el contexto) · Rechazar (evidencia clara en contra) · No-es-nuestro-problema (ortogonal al producto). Con confianza explícita y el contraargumento más fuerte respondido.
  4. Aterrizá: el veredicto con su porqué → ADR (ticket + resolución en RumIAndo) y al brain (
    decisiones/
    , git-first) si es transversal.
适用于“我们要不要采纳X？”/“我们要不要迁移到Y？”的场景（可直接调用，无需完整评审面板）：
  1. 可逆性分类： 双向可逆（依赖、配置）→ 单屏裁决 · 不可逆但影响有限（存储、内部约定）→ 完整调研 · 高不可逆（安全、公开API、数据迁移）→ 深度研究 + 必须提供两份外部来源。
  2. 双层关卡 — 两层都通过，才能发布裁决：
    • 项目层： 来自自身代码/产品的已验证事实（现有方案及其接触点
      文件:行号
      ，或已验证的缺失点及可落地位置，或brain/ADR中的已有决策）。
    • 外部层： 至少一份已验证的外部来源（真实研究、明确的现有技术、同类产品的行为）。
    • 充分的外部证据绝不能弥补项目层的不足，反之亦然。
  3. 裁决（单一、明确 — 不得出现“如果…就采纳”的表述）：采纳（两层证据都充分）· 试用（前景好但不确定 → 带timebox的spike）· 等待（尚无结论；等上下文变化后再评估）· 拒绝（有明确的反对证据）· 与我们无关（与产品正交）。需明确说明置信度，并回应最有力的反对论点。
  4. 落地： 裁决及其原因 → 存入ADR（RumIAndo中的工单+决议），如果是跨领域决策，还要同步到brain（
    decisiones/
    目录，git-first）。

Fase 4 — Cierre

阶段4 — 收尾

transition_ficha(→READY_TO_BUILD)
— si falla (
DOB_INCOMPLETO
, 
ADR_PENDIENTE
), el error ES el reporte: qué ítem del DoR falta, qué ADR sigue abierto. No lo fuerces. Con la transición hecha: la ficha es el testigo para 
wachi-fabrica
 (y el release, si agrupa: 
crear_release
+ 
agregar_ficha_a_release
).
调用
transition_ficha(→READY_TO_BUILD)
— 如果流转失败（
DOB_INCOMPLETO
、
ADR_PENDIENTE
），错误本身就是报告：明确列出DoR中缺失的项、仍未解决的ADR。不要强行推进。流转完成后：需求卡片将作为**
wachi-fabrica
**的输入依据（如果需要归组release：调用
crear_release
+ 
agregar_ficha_a_release
）。