Skip to content

docs(roadmap): cure the plan after the D28/D29 batch — M13, open corrections, ingestion and gate integrity - #522

Merged
ChristianLuciani merged 11 commits into
mainfrom
dsh/docs/roadmap-2026-11-11
Nov 13, 2026
Merged

ChristianLuciani merged 11 commits into
mainfrom
dsh/docs/roadmap-2026-11-11

Conversation

@ChristianLuciani

Copy link
Copy Markdown
Owner

Re-cures docs/ROADMAP.md against the verified state of main@42b809a: it records what shipped (D28/S503a, D29), the integrity hole the dogfood found (#520) and the open corrections.
Docs-only: one file, docs/ROADMAP.md; no SPEC, schema, package or platform change.

What changed

Gates

Run in the worktree on the commit below (2026-11-11):

Gate Result
node scripts/spec-drefs/check.mjs --check exit 0 — in sync (591 references across 95 surfaces resolve to the 29 §5 rows)
node scripts/agnostic-check/check.mjs exit 0 — PASS, 0 private references in 777 files
node scripts/evidence-gate/check.mjs exit 0 — in sync; the W-EVIDENCE-STALE notes on docs/STANDARDS.md are pre-existing
pnpm site exit 0 — site-check PASS (11 pages, 239 ids, 520 links), version-check PASS
node scripts/link-check/check.mjs --check exit 0 — in sync (79 files, 314 links)

pnpm test/pnpm build are not re-run because the diff is Markdown only; CI (ci) is the barrier.

Impact

Impact: none — docs-only. It records S503a's real comparison and D29's ratification, which the roadmap missed, and it names the open fixes (#507, #519, #520, #521, #493) so the next session can pick them up from the plan.

Refs #503 #501 #508 #507 #519 #521 #493

Signature

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash (deepseek-official) → deepseek-v4.1-flash-1017 (openrouter)

…ections, ingestion and gate integrity

The roadmap was last dated 2026-11-09 and missed the D29 ratification (#518)
and the S503a limits the dogfood found (#520): it claimed the gate "detects
against the ledger" and asked for a signed receipt without naming the integrity
hole the record still has.

- Table: M12 row states S503a's real comparison (last recorded egress) and  #520;
  new M13 row for `curate` (D29 ratified, no code yet).
- Security section: M12 names what S503a ships and #520 as the open integrity
  fix; the ingestion row names #508 (general migrate) and #478 (scaffold).
- New "correcciones abiertas" section: #519 (path-dependent test), #507
  (release:verify race), #521 (D29 citation fix, PR open), #493 (claim posture).
- Date bumped to 2026-11-11 and the source is the verified state.

Refs #503 #501 #519 #507 #521 #493 #508

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash (deepseek-official) → deepseek-v4.1-flash-1017 (openrouter)
Signed-off-by: Christian Luciani <cluciani@gmail.com>
@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — FAIL

Verdicto: FAIL
cc: @ChristianLuciani

head_sha: 431786f116a0
verdict: FAIL
findings: {blocker: 0, major: 4, nit: 1}
class_delta: no-medido
class_delta_reason: first-pass
in_diff: 5
in_repo: 0
fuera: 0
assumptions_declared: 4
limits_noted: 4

Verdicto

FAIL — el PR hace lo que dice en su idea (registra D28/S503a y D29, abre M13,
suma las correcciones abiertas), y el anti-trim mecánico no encuentra un solo
trim sin traza. Lo que impide PASS es que cuatro de las afirmaciones nuevas
sobre el estado del tracker ya no son ciertas al head que se va a mergear
, y
una quinta es cierta pero incompleta de un modo que el lector paga: el documento
que se declara «verificado, no declarado» afirma como abiertas dos correcciones
que ya están en main, y como pendiente una implementación que ya está en
main. No es prosa: es el índice de trabajo del próximo boot.

Findings (uno por bloque)

F1 — docs/ROADMAP.md:144 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-11)" · recurrence:new

F2 — docs/ROADMAP.md:138 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-11)" · recurrence:new

F3 — docs/ROADMAP.md:146 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-11)" · recurrence:new

F4 — docs/ROADMAP.md:102 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"El ingreso de datos que hace útil D27/D29" · recurrence:new

F5 — docs/ROADMAP.md:100 · NIT · diff · class:2 · surface:docs/ROADMAP.md§"El ingreso de datos que hace útil D27/D29" · recurrence:new

Cobertura

No pude refutar (lo que sobrevivió)

Asunciones que declarás

  • Asumí que el contrato a refutar es el propio encabezado del ROADMAP («qué está realmente hecho», «desde el estado verificado del repo») más docs/SPEC.md como canónico del plan y el tracker como fuente del estado de cada issue. El pack no mapea ningún spec para este path.
  • Asumí que «estado» en este documento significa el estado al head de la rama, no al día en que se escribió la fila: el encabezado dice «actualizado 2026-11-11» y el PR se mergearía sobre main@a2e8bbc (2026-11-12), así que un lector lo lee como estado actual.
  • Asumí que el «triaje 2026-11-11» del encabezado de la sección es un corte de fecha, no una declaración de que la sección puede quedar desactualizada: el documento no dice en ningún lado que esas filas sean un registro histórico (a diferencia de las secciones fechadas del resto del repo).
  • Asumí que el body no traía conclusiones de review (el filtro del pack descartó 0 secciones).

Límites de tu review

  • No corrí los gates que el body cita (spec-drefs, agnostic-check, evidence-gate, pnpm site, link-check) ni pnpm test/build: el diff es Markdown y CI es la barrera. El pack corrió solo los chequeos read-only que sabe correr (links relativos: PASS, 1 enlace).
  • No verifiqué el Impact: none contra session-discipline §8 más allá de leerlo: el PR no cierra ni toca premisas de issues (Refs no cierra), y el Impact: none es plausible — pero el §8b (triaje post-merge) queda del lado del autor.
  • No revisé el resto del ROADMAP fuera del diff (las secciones «Fuera de los milestones», «Después», «Transversal») más allá de leerlas completas para contexto: pueden tener drift propio no introducido por este PR; no lo reporto como finding.
  • No juzgué si el ROADMAP debe ser un documento vivo o fechado (eso es decisión del operador); reporto la consecuencia observable: cuatro filas que el merge deja falsas.
  • Un solo pase. El autor reconcilia y puede re-invocar.

…head

The premerge review (FAIL, 4 majors) found the new claims about the tracker
stale at the head that would merge. Re-derived against origin/main@a2e8bbc:

- F1: #521 is merged (a2e8bbc), not an open PR.
- F2: #519 is closed by #527 — dropped from the open list.
- F3: #493's A/B/C/D decision was ratified 2026-11-12 (A now, B as direction,
  C future, D rejected); the work lives in #529.
- F4: `pasco migrate` v2.0 already ships in main (#509); #508 is the general
  contract and declares itself partially landed.
- F5: the section header no longer calls #508/#478 "data ingestion".
- Adds #520 (operator decision recorded, draft PR #528) to the open list.

Refs #522 #493 #529 #520 #508

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash → deepseek-v4.1-flash-1017 (openrouter → mistral)
Signed-off-by: Christian Luciani <cluciani@gmail.com>
@ChristianLuciani

Copy link
Copy Markdown
Owner Author

Reconciliación del review — head ec9da9a

Los cuatro majors y el nit eran correctos: las afirmaciones nuevas sobre el tracker estaban viejas al head que se mergearía. Re-derivadas contra origin/main@a2e8bbc y corregidas:

# Antes Ahora (verificado)
F1 #521 «(PR abierto)» Mergeada en a2e8bbc; movida a «cerrados en esta ronda»
F2 #519 vigente Cerrado por #527 (494d636); fuera de la lista de abiertos
F3 #493 «Espera decisión A/B/C» Decidida 2026-11-12 (A ahora, B como dirección v1.17, C futura, D rechazada); needs-decision retirado; la construcción vive en #529
F4 «El migrate de v2.0 … es su primera instancia» (pendiente) packages/cli/src/commands/migrate.ts ya está en main (#509); #508 es el contrato general y se declara parcialmente aterrizado
F5 «El ingreso de datos…» «Trabajo de registro que hace útil D27/D29» (#508 = migración, #478 = docs del scaffold)

Además: #520 entra a la lista de abiertos (decisión del operador registrada — UNA memoria; implementación en draft PR #528), y la fecha sube a 2026-11-13.

Gates en ec9da9a (2026-11-13): spec-drefs in sync (29 filas §5) · agnostic PASS (781 archivos) · evidence in sync · link-check in sync (314 links) · site-check PASS (248 ids, 524 links) · version-check PASS. CI en curso.

Fuera de este PR, reportado: el draft #526 (D30, content/ → facts/) toca docs/ROADMAP.md y está CONFLICTING; si mergea antes, este PR necesita otro rebase — y D30 cambia la ruta del ledger de D29 (content/curations.yaml → facts/curations.yaml) en §7.12.

@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — PASS-CON-RIESGOS

Verdicto: PASS-CON-RIESGOS
cc: @ChristianLuciani

head_sha: ec9da9afa00c
verdict: PASS-CON-RIESGOS
findings: {blocker: 0, major: 1, nit: 1}
class_delta: {new: [2, 4], repeat: []}
in_diff: 2
in_repo: 0
fuera: 0
assumptions_declared: 4
limits_noted: 4

Verdicto

PASS-CON-RIESGOS — la reconciliación del pase 1 es real y verificada línea por línea contra el tracker, no una tabla de intenciones: los cuatro majors y el nit de 431786f están efectivamente corregidos al head, y las afirmaciones nuevas que el PR agrega (la decisión de #493 con su traza, el veredicto «UNA memoria» de #520, el draft #528, el migrate v2.0 de #509, las dos clases de #529, el arreglo de #507) se sostienen contra los issues y PRs. El anti-trim no encuentra ningún trim sin traza.

Lo que impide PASS es que una fila nueva afirma un estado del tracker que es falso al head — #493 declara «needs-decision retirado» y el label sigue puesto — y que el documento se declara «estado verificado, no declarado» mientras su encabezado nombra un conjunto de triaje (#521, #529) que la sección que lo materializa no cubre como tal. Ninguno de los dos rompe una decisión; el primero sí manda al próximo boot a leer un estado que no existe.

Findings (uno por bloque)

F1 — docs/ROADMAP.md:148 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)" · recurrence:new

F2 — docs/ROADMAP.md:3 · NIT · diff · class:2 · surface:docs/ROADMAP.md§encabezado · recurrence:new

Cobertura

No pude refutar (lo que sobrevivió)

Asunciones que declarás

  • Asumí que el contrato a refutar es el propio encabezado del ROADMAP («qué está realmente hecho», «desde el estado verificado del repo») más docs/SPEC.md como canónico del plan y el tracker como fuente del estado de cada issue. El pack no mapea ningún spec para este path.
  • Asumí que «estado» significa estado al head de la rama, no al día en que se escribió la fila: el encabezado dice «actualizado 2026-11-13» y el PR se mergearía sobre main@a2e8bbc, así que un lector lo lee como estado actual.
  • Asumí que un label needs-decision vivo en epic: curate — divulgación con alcance para datos private (CV primero) #501 es el estado que la sección «correcciones abiertas» debería reflejar, porque la propia fila M13 de este PR cita epic: curate — divulgación con alcance para datos private (CV primero) #501 como tracker de D29 y declara «sin decisión de slice».
  • Asumí que el body no traía conclusiones de review (el filtro del pack descartó 0 secciones); la reconciliación del pase 1 vive en un comentario, no en el body, así que no contaminó la lectura.

Límites de tu review

  • No corrí los gates que el body cita (spec-drefs, agnostic-check, evidence-gate, pnpm site, link-check) ni pnpm test/build: el diff es Markdown y CI es la barrera. CI al head: ci SUCCESS, sign-off SUCCESS, mergeStateStatus: CLEAN — lo leo como dato, no como veredicto.
  • No verifiqué el Impact: none de session-discipline §8 más allá de leerlo: el PR usa Refs (no Closes), así que no cierra issues; el §8b (triaje post-merge) queda del lado del autor.
  • No revisé el resto del ROADMAP fuera del diff más allá de leerlo completo para contexto: puede tener drift propio no introducido por este PR y no lo reporto como finding (salvo lo que el diff toca — F2).
  • Reportado fuera de este PR, no como finding: el draft feat: rename the SSOT directory content/ -> facts/ via dual-read alias (D30) #526 (D30, content/ → facts/) toca docs/ROADMAP.md y está CONFLICTING; si mergea antes, este PR necesita rebase y D30 cambia la ruta del ledger de D29 (content/curations.yaml → facts/curations.yaml), que el ROADMAP cita en :37. El autor ya lo declaró en su reconciliación; lo dejo asentado porque el conflicto es real al head. El issue implementation-ready, si hace falta, se emite con OK del operador (ADR-025).
  • Un solo pase. El autor reconcilia y puede re-invocar.

…y cited issue has a row

The pass-2 review found two new findings at the head:

- F1: the open list said `needs-decision` was withdrawn without naming the one
  issue of the D29 cluster that still carries it — #501 (M13). It now leads the
  list as the open decision (which slice, and its S503b dependency).
- F2: the header promised #517/#518/#521/#527/#529 but #529 had no row of its
  own and #517/#518 appeared only in the header. The header now says what each
  number is, #529 has its own row, and the section closes with the issues that
  are outside the cluster (#508, #478, #503).

Refs #501 #529 #520 #507 #493

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash → deepseek-v4.1-flash-1017 (openrouter → mistral)
Signed-off-by: Christian Luciani <cluciani@gmail.com>
@ChristianLuciani

Copy link
Copy Markdown
Owner Author

Reconciliación pase 2 — head 8c5981a

Ambos findings eran correctos. Corregidos:

# Antes Ahora
F1 «needs-decision retirado» sin nombrar el que sigue vivo #501 (M13) abre la lista como la única decisión abierta del racimo D29 (needs-decision vivo, verificado): la decisión es el slice y su dependencia con S503b; el contrato ya está ratificado (D29, §7.12)
F2 Encabezado prometía #529 sin fila propia; #517/#518 solo en el encabezado #529 tiene fila propia («abierto, sin claim»); el encabezado dice qué es cada número (#517/#518 = S503a + D29; #521/#527 = cerrados; #529 = abierto); la sección cierra con lo que queda fuera del racimo (#508, #478, #503)

Gates en 8c5981a (2026-11-13): spec-drefs in sync (29 filas §5, 594 refs) · agnostic PASS (781 archivos) · evidence in sync · link-check in sync (314 links) · site-check PASS (248 ids, 524 links) · version-check PASS. CI en curso.

Sigue reportado, no finding: el draft #526 (D30, content/ → facts/) toca docs/ROADMAP.md, está CONFLICTING y cambiaría la ruta del ledger de D29 que este documento cita.

@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — PASS-CON-RIESGOS

Verdicto: PASS-CON-RIESGOS
cc: @ChristianLuciani

head_sha: 8c5981a4ede6
verdict: PASS-CON-RIESGOS
findings: {blocker: 0, major: 2, nit: 2}
class_delta: {new: [], repeat: ["4", "2"]}
in_diff: 4
in_repo: 0
fuera: 0
assumptions_declared: 3
limits_noted: 3

Verdicto

PASS-CON-RIESGOS (informativo — no bloquea merge)

Findings (uno por bloque)

F1 — docs/ROADMAP.md:22 · MAJOR · diff · class:2 · surface:docs/ROADMAP.md§"Estado real (verificado, no declarado)" · recurrence:repeat · ESCALATE(2)

  • La fila M13 se agrega a la tabla y se cita dos veces más (:3 encabezado, :139 **#501** (M13)), pero M13 no existe en el SPEC: git show origin/dsh/docs/roadmap-2026-11-11:docs/SPEC.md | grep -c M13 → 0; sed -n '/^## 12/,/^## 13/p' | grep -c '^[0-9]*\. \*\*M' → 12 milestones (M1–M12, ninguno M13).
  • El propio documento declara docs/SPEC.md §12 como canónico del plan (:5) y su columna se llama SPEC dice. La fila inventa un milestone que el canónico no tiene: un lector que va a §12 a buscar M13 no lo encuentra, y el conteo de milestones diverge entre las dos superficies sin que nada lo declare.
  • Es el mismo defecto que el pase 2 ya marcó en §encabezado (class 2, ec9da9a): se corrigió el encabezado pero la fila nueva reintrodujo la clase en otra superficie del mismo archivo. Instrumento que cierra la clase: o M13 entra en SPEC §12 (y el encabezado del ROADMAP deja de ser la única fuente), o la fila se rotula como milestone propuesto con la frase que lo diga — hoy no hay ninguna de las dos.

F2 — docs/ROADMAP.md:149 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)" · recurrence:repeat · ESCALATE(4)

  • «B queda registrada como dirección (v1.17)»: v1.17 no aparece en ninguna parte del repo. git grep -n "1\.17" origin/dsh/docs/roadmap-2026-11-11 -- docs/ devuelve una sola línea, esta misma. El SPEC no tiene versión de contrato (el único version es el schemaVersion "2" del payload, §7.5).
  • La fuente real dice otra cosa: el comentario de cierre de truth is not a gate: a false experience[].highlight passed every check and published on the CV (CLAPPS.AI) #493 (2026-11-12T23:04:59Z) dice «promoverla exige bendición explícita del operador, un bump de mayor del contrato (v1.17) y la evidencia de A en uso» — es decir, v1.17 es el bump condicional a una promoción futura, no un número asignado. La línea del roadmap lo convierte en un hecho consumado y, de paso, en la única aparición del número en el repo: el próximo lector lo cita como si existiera.
  • Además el mismo bullet dice «Abierto, sin claim» sobre audit: highlights gain an explicit block:id pointer — claim-against-unbuilt + claim-without-proof (A of #493) #529: la única traza de claim que existe es el referenced que este mismo PR produjo (2026-11-13T03:01:35Z 8c5981a). Es defendible (no hay assignee ni branch), pero el estado se afirma sin anclarlo a la lectura del tracker, que es la regla que este documento se impone (:6 «desde el estado verificado del repo (no del declarado)»).
  • Instrumento que cierra la clase: el número de versión solo puede aparecer en el SPEC (donde vive el contrato) o citado con su condición («exigiría un bump de mayor, hoy v1.16 → v1.17»); si el número no está en el SPEC, no entra al roadmap.

F3 — docs/ROADMAP.md:21 · NIT · diff · class:2 · surface:docs/ROADMAP.md§"Estado real (verificado, no declarado)"

F4 — docs/ROADMAP.md:149 · NIT · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)"

Cobertura

No pude refutar (lo que sobrevivió)

Asunciones que declarás

  • Asumo que docs/SPEC.md §12 es canónico para la existencia de un milestone, como el propio ROADMAP declara en :5. Si la intención es que el roadmap pueda introducir milestones antes que el SPEC, el finding F1 baja a NIT — pero entonces el SPEC dice de la columna necesita una tercera etiqueta.
  • Asumo que el estado del tracker al momento de este pase (2026-11-13, ≈03:20Z) es el que el roadmap quiso fotografiar; el documento se fecha 2026-11-13 y el commit es 2026-11-12 22:01 -0500, mismo día.
  • Asumo que draft PR #528 sigue siendo el vehículo de fix(egress): la memoria de autorización es reescribible y el log no tiene cadena de integridad (+ on-ramps sin --confirm, texto de rechazo de --all) #520 (verificado: OPEN, draft), y que su review/merge no está bloqueada por nada que este PR deba registrar.

Límites de tu review

  • No re-corrí los gates que el body declara (spec-drefs, agnostic-check, evidence-gate, pnpm site, link-check): el pack no los ejecuta y CI no los corre todos. El body trae sus salidas con fecha; no las afirmo ni las niego.
  • No revisé el resto de docs/ROADMAP.md fuera del diff salvo las secciones que el diff toca o que citan sus líneas (encabezado, tabla, seguridad, correcciones, orden recomendado). El documento ya estaba en main con las filas M10/M11 ausentes de la tabla; eso es preexistente y no lo cuento contra este PR.
  • No evalué si la decisión de ratificar D29 o de abrir M13 es correcta — el contrato no es mío para juzgar; solo su consistencia entre superficies.

… unassigned version

The pass-3 review found two majors at the head, both repeats of the same
classes (over-claiming the tracker):

- F1: the M13 row named a milestone the SPEC does not have (§12 lists M1–M12).
  The "SPEC dice" cell now says so, and M13 stays a roadmap-only grouping of
  D29 with its anchor in §5/§7.12.
- F2: "(v1.17)" assigned a contract version the decision never assigned — #493
  says a FUTURE promotion needs a major bump, not that it is v1.17. The line
  now states the condition, and "sin claim" is anchored to the check date.
- F3: the M12 row now carries #520 like the security section does.
- F4: #519 (issue) and #521 (PR) are labelled by kind in the closed list.

Refs #501 #529 #520

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash → deepseek-v4.1-flash-1017 (openrouter → mistral)
Signed-off-by: Christian Luciani <cluciani@gmail.com>
@ChristianLuciani

Copy link
Copy Markdown
Owner Author

Reconciliación pase 3 — head 04e0c48

Los dos majors eran repeticiones de la misma clase (afirmar más de lo que el tracker dice), y los dos nits eran de completitud entre dos superficies del mismo archivo. Corregidos:

# Antes Ahora
F1 La fila M13 nombraba un milestone que el SPEC no tiene La celda «SPEC dice» dice «no está en el SPEC — §12 lista M1–M12»; M13 queda como agrupación de roadmap de D29 con ancla en §5/§7.12
F2 «B queda registrada como dirección (v1.17)» Se quita el número no asignado: la línea dice la condición que fijó #493 (bendición explícita, bump de mayor, evidencia de A en uso); «sin claim» queda anclado a la fecha de verificación (2026-11-13)
F3 La fila M12 omitía #520 La fila M12 dice «Integridad del registro abierta en #520 (draft PR #528)», igual que la sección de seguridad
F4 #521 (PR) listado como «cerrado» junto a #519 (issue) La lista dice issue #519 (cerrado por PR #527) y PR #521 (mergeada, a2e8bbc)

Gates en 04e0c48 (2026-11-13): spec-drefs in sync (29 filas §5, 594 refs) · agnostic PASS (781 archivos) · evidence in sync · link-check in sync (314 links) · site-check PASS (248 ids, 524 links) · version-check PASS. CI en curso.

Sigue reportado, no finding: el draft #526 (D30, content/ → facts/) toca docs/ROADMAP.md, está CONFLICTING y cambiaría la ruta del ledger de D29 que este documento cita.

@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — FAIL

Verdicto: FAIL
cc: @ChristianLuciani

head_sha: a563b285
verdict: FAIL
findings: {blocker: 0, major: 2, nit: 1}
class_delta: {new: [], repeat: [4]}
in_diff: 3
in_repo: 0
fuera: 0
assumptions_declared: 4
limits_noted: 5

Verdicto

FAIL — el PR hace lo que dice (registra D28/S503a y D29, abre M13, suma las
correcciones abiertas) y el anti-trim mecánico no encuentra un solo trim sin
traza
: la única línea borrada que matchea un marker (ROADMAP.md:89, nunca)
sobrevive en el head. Lo que impide PASS es que la premisa central del pase 3
caducó entre 04e0c48 y a563b285
: el PR mergeó main cuando main ya
contenía la corrección de #520, y las dos superficies que afirman «#520 sigue
abierto, la memoria es reescribible y el log no tiene cadena» quedaron
contradiciendo el código y el SPEC del propio árbol que se mergearía.

Es la misma clase (4) que el pase 3 ya escaló: aquel pase corrigió la fila
M13 por afirmar más de lo que el tracker decía, y el merge final re-introdujo la
clase en la fila M12 y en la sección de seguridad. Por review-damping v2.1.2
esto es recurrence: repeat con ESCALATE(4): el instrumento que cierra la
clase es un gate de frescura al head (ver F1), no otra ronda de corrección
local. class_delta va new: [] / repeat: [4] — respecto del pase
inmediatamente anterior (pase 3, 8c5981a) la clase 4 ya estaba presente; la
repetición es del par (4, §"Estado real …"), que el pase 3 tocó en la fila
M13 y este head reintroduce en la fila M12.

Findings (uno por bloque)

F1 — docs/ROADMAP.md:21 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Estado real (verificado, no declarado)" · recurrence:repeat · ESCALATE(4)

F2 — docs/ROADMAP.md:142 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)" · recurrence:repeat · ESCALATE(4)

F3 — docs/ROADMAP.md:148 · NIT · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)" · recurrence:new

Cobertura

No pude refutar (lo que sobrevivió)

Asunciones que declarás

Límites de tu review

  • El pack salió con exit 3 («no pude resolver el PR docs(roadmap): cure the plan after the D28/D29 batch — M13, open corrections, ingestion and gate integrity #522»): el script
    invoca gh pr view sin --repo, y desde este checkout el repo por
    defecto de gh no resuelve docs(roadmap): cure the plan after the D28/D29 batch — M13, open corrections, ingestion and gate integrity #522. El markdown se emitió igual (209 líneas)
    porque el modo --gh degrada; el diff, la norma y los chequeos §7 son
    válidos, pero §1 (PR/CI) del pack quedó vacío y lo reconstruí con
    gh pr view --repo. Es un defecto del instrumento, no del PR: lo reporto,
    no lo arreglo (fuera del diff).
  • No corrí pnpm test / pnpm build / pnpm site: el diff es Markdown de un
    solo archivo y CI (ci) está verde al head (gh pr checks 522 → ci pass 3m7s, sign-off pass 6s). El pack no afirma verde; lo afirma gh.
  • No ejecuté bin/sanitize.sh (mueve skills a cuarentena) ni bin/lint.sh
    (este repo no lo tiene).
  • No revisé el historial de la rama más allá de los 6 commits que lista gh;
    no busqué si algún commit intermedio introdujo y revirtió otro cambio.
  • No audité el contenido de feat(egress): ONE memory, ONE scope — bind the baseline to the log with an integrity chain (#520) #528 (PR ya mergeado, fuera del diff de este PR):
    verifiqué su estado, su merge commit y que el árbol del head contiene la
    cadena; no juzgo si la implementación de la cadena es correcta.
  • No verifiqué la afirmación «0.3.6 en preparación» (línea 24) ni «Release
    0.3.6 (2026-10-26, prep)» (línea 44): ambas son preexistentes al PR
    (presentes en c22df70f) y el tag v0.3.6 existe desde 2026-10-27, pero son
    texto que el PR no toca — las reporto como observación, no como finding.

…change

The pass-4 review (head a563b28) found the same class again: the document
still described #520 as an open draft and placed the contract bump on B.

- F1/F2: #520 merged in c22df70 (PR #528) — the memory is one and chained to
  the log (§7.11). The M12 row, the security section and the open list now say
  what shipped and what remains (authenticity: coherent rewrite / forged
  history, closed by S503b), instead of "still falsifiable / draft PR #528".
- F3: #529's A touches the contract (optional field in $defs/experienceItem,
  pnpm gen:zod); B is the direction that needs the major bump, not the other
  way around.
- The header date stays 2026-11-13 (the triage date) and the content is
  re-derived at the merge head.

Refs #520 #528 #529 #493 #503

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash → deepseek-v4.1-flash-1017 (openrouter → mistral)
Signed-off-by: Christian Luciani <cluciani@gmail.com>
@ChristianLuciani

Copy link
Copy Markdown
Owner Author

Reconciliación pase 4 — head 3e5dbe5

Los tres findings eran correctos: #520 se mergeó en c22df70 (PR #528) entre el pase 3 y este, y el documento seguía describiéndolo como borrador. Corregido, con la causa atacada: el estado de #520 ya no se repite en tres lugares con frases distintas, sino que cada superficie dice lo que le toca.

# Antes Ahora
F1/F2 «el registro de autorización todavía es falsificable y eso lo cierra #520» + «implementación en draft PR #528» Mergeado en c22df70: una sola memoria (baseline.json = manifiesto público) y cadena de integridad en el audit log (§7.11). Lo que queda es la autenticidad — reescrito coherente e historia re-firmada, indetectables sin llave — y eso lo cierra S503b. La fila M12 dice lo mismo en una frase; la lista de abiertos solo registra que el issue sigue abierto por esos dos límites
F3 El bump de mayor quedaba atribuido a B A toca el contrato (campo opcional en $defs/experienceItem, pnpm gen:zod); B es la dirección que exige el bump de mayor, no al revés

Gates en 3e5dbe5 (2026-11-13): spec-drefs in sync (29 filas §5, 597 refs) · agnostic PASS (781 archivos) · evidence in sync · link-check in sync (317 links) · site-check PASS (248 ids, 527 links) · version-check PASS. CI en curso.

Sobre el ESCALATE(class:4): no pido otro pase. La causa de la repetición es estructural — el documento afirmaba estado del tracker en tres superficies con redacciones distintas, así que una sola caducidad producía tres afirmaciones falsas. Este pase borra la duplicación: M12 dice estado de milestone, la sección de seguridad dice el contrato, y la lista de abiertos dice qué queda pendiente. Si un pase futuro vuelve a encontrar una caducidad, el instrumento que la cierra es que el documento deje de copiar el tracker y lo cite.

Sigue reportado, no finding: el draft #526 (D30, content/ → facts/) toca docs/ROADMAP.md, está CONFLICTING y cambiaría la ruta del ledger de D29 que este documento cita.

@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — PASS-CON-RIESGOS

Verdicto: PASS-CON-RIESGOS
cc: @ChristianLuciani

head_sha: 3e5dbe59
verdict: PASS-CON-RIESGOS
findings: {blocker: 0, major: 1, nit: 1}
class_delta: {new: [], repeat: [4, 2]}
in_diff: 2
in_repo: 0
fuera: 0
assumptions_declared: 4
limits_noted: 5

Verdicto

PASS-CON-RIESGOS — este es el quinto pase y el primero en el que las cuatro
clases escaladas de los pases anteriores están efectivamente cerradas al head
,
verificadas una por una contra el tracker y el SPEC, no contra la tabla de
reconciliación del autor:

El anti-trim no encuentra un trim sin traza. Lo que impide PASS es una sola
frase
: la razón por la que #520 «sigue abierto» no tiene fuente en el tracker.
No es una caducidad —la clase que se repitió cuatro veces— sino una afirmación
de proceso que ningún artefacto respalda; por eso el veredicto es
PASS-CON-RIESGOS y no FAIL.

Findings (uno por bloque)

F1 — docs/ROADMAP.md:146 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)" · recurrence:repeat · ESCALATE(4)

F2 — docs/ROADMAP.md:3 · NIT · diff · class:2 · surface:docs/ROADMAP.md§encabezado · recurrence:repeat · ESCALATE(2)

Cobertura

No pude refutar (lo que sobrevivió)

Asunciones que declarás

  • Asumí que el contrato a refutar es el encabezado del propio ROADMAP («desde el
    estado verificado del repo (no del declarado)», :3) más docs/SPEC.md como
    canónico del plan, y el tracker de GitHub como fuente del estado de cada issue.
    El pack no mapea ningún spec para este path.
  • Asumí que «estado» significa el estado al head de la rama (3e5dbe59), no al
    día en que se escribió cada fila: el documento se fecha 2026-11-13 y el PR se
    mergearía sobre main@c22df70, así que un lector lo lee como estado actual.
  • Asumí que #520 «abierto» es intencional (el autor lo dice) y que lo
    revisable es la razón declarada, no el hecho de que siga abierto.
  • Asumí que el body del PR no traía conclusiones de review (el filtro del pack
    descartó 0 secciones) y que la tabla de reconciliación del pase 4 es del autor,
    no evidencia.

Límites de tu review

  • No corrí los gates que el body y la reconciliación citan (spec-drefs,
    agnostic-check, evidence-gate, pnpm site, link-check) ni pnpm test /
    pnpm build: el diff es Markdown de un archivo y CI (ci) está verde al head.
    El pack corrió solo los chequeos read-only que sabe correr (links: PASS).
  • No re-corrí el diff del pack como estaba escrito: el §3 trae 13 archivos
    por el desfase main/base (ver Cobertura); revisé el diff real de 1 archivo.
    No es un finding del PR — es del instrumento, y lo reporto ahí.
  • No revisé el resto de docs/ROADMAP.md fuera del diff más allá de leerlo
    completo para contexto: puede tener drift propio no introducido por este PR
    (p. ej. «0.3.6 en preparación» en :24, con el tag v0.3.6 existente desde
    2026-10-27) y no lo cuento contra este PR.
  • No juzgué si el ROADMAP debe ser un documento vivo o fechado, ni si la
    decisión de ratificar D29 o abrir M13 es correcta: solo su consistencia entre
    superficies.
  • No audité la implementación de la cadena de integridad de feat(egress): ONE memory, ONE scope — bind the baseline to the log with an integrity chain (#520) #528 (fuera del
    diff): verifiqué su estado, su merge commit y que el SPEC del head la declara,
    no que el código sea correcto.
  • Un solo pase. El autor reconcilia y puede re-invocar.

…top replicating the tracker

Pass 5 closed the four escalated classes and found one more of the same kind:

- F1: the #520 row invented a reason ("open for the review of those two
  limits") that exists nowhere. Verified against the tracker and main@a90263d,
  what is open is the issue's points (2) and (3): the on-ramps still do not
  name `--confirm`, and SPEC §7's `export profile` row lacks the `--all`
  rejection clause. The authenticity limits are declared in §7.11 and closed by
  S503b — not a reason to keep it open.
- F2: #517/#518 now say what they are in the closed list instead of appearing
  only in the header.
- Structural (#532): the header states the document cites the tracker with a
  date instead of replicating it, and the rows stop asserting phase/labels.

Also merges origin/main (D30: `facts/`), so the ledger path and the scaffold
grain match the contract.

Refs #520 #532 #526

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash → deepseek-v4.1-flash-1017 (openrouter → mistral)
Signed-off-by: Christian Luciani <cluciani@gmail.com>
@ChristianLuciani

Copy link
Copy Markdown
Owner Author

Reconciliación pase 5 — head 98d3ce1

Los dos findings eran correctos, y el primero no caduca: la razón de apertura de #520 era inventada. Verificado contra el tracker y main@a90263d:

# Antes Ahora
F1 «El issue sigue abierto por la revisión de esos dos límites» La fila dice lo que sí está abierto, verificado hoy: los puntos (2)/(3) de #520 — los on-ramps (README, START-HERE, TUTORIAL, USER-GUIDE) no mencionan --confirm, y la fila export profile de SPEC §7 no tiene la cláusula del rechazo de --all (el README del CLI sí). Los límites de autenticidad están en §7.11 y los cierra S503b: no son motivo de apertura
F2 #517/#518 solo en el encabezado La lista de cerrados dice qué son: S503a + D29 mergeados, sin fila propia porque no queda nada abierto de ellos

ESCALATE(4), 2.ª reaparición — atendido como pide review-damping: abrí el issue estructural #532 (el roadmap replica estado del tracker en vez de citarlo; cinco pases, cinco caducidades de la misma clase). El documento ahora lo declara en el encabezado y las filas dejan de afirmar fase/label del tracker sin fecha.

También en este head: merge de origin/main (D30, facts/) — el ledger de D29 y el grano del scaffold ya citan facts/curations.yaml.

Gates en 98d3ce1 (2026-11-13): spec-drefs in sync (30 filas §5, 609 refs) · agnostic PASS (781 archivos) · evidence in sync · link-check in sync (317 links) · site-check PASS (248 ids, 527 links) · version-check PASS. CI en curso.

Defecto del instrumento, reportado por el review: el §3 del pack emite git diff main...head y con main avanzado trae el merge ajeno entero. Este head ya contiene origin/main, así que el diff del pack coincide con el del PR (1 archivo).

@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — FAIL

Verdicto: FAIL
cc: @ChristianLuciani

head_sha: 98d3ce1f76b9
verdict: FAIL
findings: {blocker: 0, major: 3, nit: 2}
class_delta: {new: [], repeat: [2, 4]}
in_diff: 5
in_repo: 0
fuera: 0
assumptions_declared: 4
limits_noted: 5

Verdicto

FAIL — este es el sexto pase sobre 98d3ce1 y el PR sigue sin poder mergearse con su veredicto vinculante. Lo que lo impide no es una caducidad nueva (el pase 5 ya cerró la razón inventada de #520): es que el head todavía afirma tres cosas que el tracker contradice hoy, y dos de ellas son las mismas clases que los pases 1–5 ya escalaron.

Las tres majors comparten una sola causa: el documento replica estado del tracker (qué es cierto de un issue, en qué fase está, qué toca) en vez de citarlo. #532 lo nombra como estructural y propone el instrumento; el roadmap no lo adoptó — se limita a declarar en el encabezado que «cita con fecha, no replica» (:3) mientras el cuerpo sigue replicando. Esa es la brecha que hace que cada pase tenga un blanco nuevo.

Lo que sí sobrevivió: el anti-trim no encuentra ningún trim sin traza, la sección de seguridad M12 dice la verdad del código, la fila #520 post-pase-5 es correcta, y las filas #507/#508/#478/#529 (en lo que no toca el contrato) coinciden con sus issues.

Findings (uno por bloque)

F1 — docs/ROADMAP.md:145 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)" · recurrence:repeat · ESCALATE(4)

F2 — docs/ROADMAP.md:22 · MAJOR · diff · class:2 · surface:docs/ROADMAP.md§"Estado real (verificado, no declarado)" · recurrence:repeat · ESCALATE(2)

  • La fila M13 afirma «✗ contrato sí, código no — contrato ratificado; sin implementación ni decisión de slice».
  • La decisión de slice está tomada y trazada. gh issue view 501 --json comments devuelve dos comentarios; el segundo (2026-11-13T02:08:51Z, triaje post-merge de docs(spec): fix D29's false issue attribution for selection.views #521) enumera las premisas que se movieron y los huecos heredados, y el issue conserva needs-decision porque el label no se retiró — pero el contenido de la decisión (qué slice, en qué orden, qué hereda) está escrito. La fila de la sección «Ahora» (:140-142) repite la misma afirmación: «La decisión es el slice (contrato → ledger → materialización) y su dependencia con S503b».
  • Es la misma clase y la misma superficie que el pase 3 escaló (8c5981a, F1: «M13 se agrega a la tabla pero M13 no existe en el SPEC»). Aquella vez se corrigió el encabezado; la fila nueva reintrodujo la clase en la tabla. Dos lectores legítimos leen distinto: uno ve «el label sigue puesto, ergo no hay decisión»; otro ve «el comentario de triaje ya decidió el slice». El contrato no fija cuál manda.
  • Instrumento que cierra la clase (ESCALATE(2)): o la fila M13 cita el comentario de triaje de epic: curate — divulgación con alcance para datos private (CV primero) #501 con su fecha y sha, o el label needs-decision se retira en el tracker — pero la fila no puede afirmar «sin decisión» mientras el issue tiene la decisión escrita en un comentario fechado.

F3 — docs/ROADMAP.md:153 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)" · recurrence:repeat · ESCALATE(4)

F4 — docs/ROADMAP.md:3 · NIT · diff · class:2 · surface:docs/ROADMAP.md§encabezado · recurrence:repeat · ESCALATE(2)

F5 — docs/ROADMAP.md:141 · NIT · diff · class:2 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)"

  • La fila epic: curate — divulgación con alcance para datos private (CV primero) #501 afirma «única decisión abierta del racimo D29 (needs-decision vivo)». El label está vivo (verificado: enhancement,needs-decision), pero la fila no dice qué decisión sigue abierta, y el comentario de triaje de epic: curate — divulgación con alcance para datos private (CV primero) #501 ya enumera los huecos heredados (los tres puntos: §21 conteos público/privado, selection/unknown-view, orden de visibilidad §18.5/§21.1). Un lector que abra el issue encuentra una decisión tomada (el slice) y tres huecos declarados — no «una decisión abierta».
  • Es la misma forma que F2: el estado del tracker se afirma sin citar la superficie que lo sostiene. Menor: no cambia ninguna decisión de trabajo.

Cobertura

No pude refutar (lo que sobrevivió)

Asunciones que declarás

  • Asumí que el contrato a refutar es el propio encabezado del ROADMAP («qué está realmente hecho», «desde el estado verificado del repo») más docs/SPEC.md como canónico del plan y el tracker como fuente del estado de cada issue. El pack no mapea ningún spec para este path.
  • Asumí que «estado» significa estado al head de la rama, no al día en que se escribió la fila: el encabezado dice «actualizado 2026-11-13» y el PR se mergearía sobre main@a90263d, así que un lector lo lee como estado actual.
  • Asumí que un comentario de triaje fechado en un issue es la traza durable de la decisión que ese issue pedía (session-discipline §9), y que por lo tanto un label needs-decision que no se retiró no anula la decisión escrita — pero que la fila tampoco puede afirmar «sin decisión» sin citar ese comentario.
  • Asumí que el body no traía conclusiones de review (el filtro del pack descartó 0 secciones); las reconciliaciones de los pases 1–5 viven en comentarios, no en el body, así que no contaminaron la lectura.

Límites de tu review

  • No corrí los gates que el body cita (spec-drefs, agnostic-check, evidence-gate, pnpm site, link-check) ni pnpm test/build: el diff es Markdown de un solo archivo y CI (ci) está verde al head. El pack corrió solo los chequeos read-only que sabe correr (links relativos: PASS, 1 enlace).
  • No verifiqué el Impact: none de session-discipline §8 más allá de leerlo: el PR usa Refs (no Closes), así que no cierra issues; el §8b (triaje post-merge) queda del lado del autor.
  • No revisé el resto del ROADMAP fuera del diff más allá de leerlo completo para contexto: puede tener drift propio no introducido por este PR (p. ej. la fila M4 y las secciones «Fuera de los milestones»), y no lo reporto como finding.
  • Reportado fuera de este PR, no como finding: el instrumento de review — el pack resuelve docs/ROADMAP.md a «sin contrato mapeado» (§6), así que cada pase improvisa la norma aplicable; y el pase 4 reportó que review_pack.sh invoca gh pr view sin --repo y sale con exit 3 desde este checkout. Ambos son defectos de la herramienta, no del PR, y se reportan en su repo (ADR-025: el issue se emite con OK del operador).
  • Reportado fuera de este PR: structural: the roadmap copies tracker state instead of citing it — every merge makes it stale #532 (estructural, abierto, documentation, sin comentarios) es el instrumento que cierra la clase de F1/F3. Este pase no lo emite (ADR-025); lo referencia porque review-damping exige que la 2.ª reaparición lo nombre antes de pedir otro pase.
  • Un solo pase. El autor reconcilia y puede re-invocar.

@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — FAIL

Verdicto: FAIL
cc: @ChristianLuciani

head_sha: 98d3ce1f76b9
verdict: FAIL
findings: {blocker: 0, major: 1, nit: 1}
class_delta: {new: [], repeat: [2, 4]}
in_diff: 2
in_repo: 0
fuera: 0
assumptions_declared: 4
limits_noted: 5

Veredicto

FAIL — séptimo pase sobre el mismo head 98d3ce1f76b9. El anti-trim mecánico
encuentra cero trims sin traza (el único marker en líneas borradas, nunca,
sobrevive en el head :89). Lo que impide cualquier pase es el mismo defecto de
clase 4 que ya apareció 8 veces en el historial del PR: la fila #529 afirma
«A toca el contrato» cuando la fuente primaria dice literalmente «A no toca el
contrato». A esta altura esto no es un error de transcripción — es la consecuencia
estructural de que el documento replica estado del tracker en vez de citarlo
(la tesis exacta de #532), y el encabezado declara esa intención (:3) mientras
el cuerpo sigue replicando.

Findings (uno por bloque)

F1 — docs/ROADMAP.md:153 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (triaje 2026-11-13)" · recurrence:repeat · ESCALATE(4)

F2 — docs/ROADMAP.md:3 · NIT · diff · class:2 · surface:docs/ROADMAP.md§encabezado · recurrence:repeat · ESCALATE(2)

Cobertura

No pude refutar (lo que sobrevivió)

Asunciones que declarás

Límites de tu review

  • No corrí pnpm test/build/site ni los gates que el body cita: el diff es
    Markdown de un solo archivo y CI está verde al head. El pack corrió solo sus
    chequeos read-only (links relativos: PASS).
  • No audité el contenido de feat(egress): ONE memory, ONE scope — bind the baseline to the log with an integrity chain (#520) #528 (PR mergeado, fuera del diff): verifiqué su
    estado, merge commit, y que el árbol del base contiene la cadena.
  • No revisé el ROADMAP fuera del diff salvo leerlo completo para contexto; hay
    texto preexistente stale (p. ej. «0.3.6 en preparación» cuando v0.5.0 ya es
    Latest) que este PR no tocó — no lo cuento como finding.
  • Reportado fuera de este PR, no como finding: structural: the roadmap copies tracker state instead of citing it — every merge makes it stale #532 (estructural, abierto,
    documentation, 0 comentarios) es el instrumento que cierra la clase 4 de F1.
    Este pase no lo emite (ADR-025); lo referencia porque review-damping exige
    que la reaparición lo nombre.
  • Un solo pase. El autor reconcilia y puede re-invocar.

…asing it

Pass 7 found the same class-4 defect on the same surface for the eighth time:
the #529 row said "A toca el contrato" while #493's decision says the
opposite ("A no toca el contrato. Es aditivo sobre el schema"). The class is
the document paraphrasing tracker state, so this pass removes the paraphrase
rather than correcting it again (#532).

- The "correcciones abiertas" section becomes a citation table: issue, what
  is open per its own source, and the date/sha it was verified at. No row
  asserts a phase, a label or a decision in the roadmap's own voice.
- The #529 row now states what both sources state: A is additive over the
  schema (optional field, pnpm gen:zod); B is the direction that needs the
  operator and the major bump.

Refs #532 #529 #493 #520

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash → deepseek-v4.1-flash-1017 (openrouter → mistral)
Signed-off-by: Christian Luciani <cluciani@gmail.com>
@ChristianLuciani

Copy link
Copy Markdown
Owner Author

Reconciliación pase 7 — head c1c2fa2

Los dos findings eran correctos, y el F1 es la octava aparición de la misma clase en la misma superficie. No corregí la frase: quité la paráfrasis.

# Antes Ahora
F1 «A toca el contrato» — #493 dice literalmente «A no toca el contrato. Es aditivo sobre el schema» La fila de #529 cita ambas fuentes: A es aditivo sobre el schema (campo opcional, pnpm gen:zod); B es la dirección que exige bendición del operador y bump de mayor
F2 El encabezado prometía «cita con fecha» y el cuerpo seguía replicando estado sin fechas La sección «Ahora — correcciones abiertas» es ahora una tabla de citas: issue · qué queda abierto según su propia fuente · fecha/sha de verificación. Ninguna fila afirma fase, label ni decisión con la voz del roadmap

La causa, atacada (#532): seis pases encontraron la misma clase porque el documento parafraseaba el tracker. Ahora cada fila apunta a la fuente y a la fecha; lo que el roadmap afirma de sí mismo es lo que el repo demuestra (archivos, tests, SPEC), no lo que el tracker dice. El criterio de cierre de #532 queda escrito en la propia sección.

Gates en c1c2fa2 (2026-11-13): spec-drefs in sync (30 filas §5, 608 refs) · agnostic PASS (781 archivos) · evidence in sync · link-check in sync (317 links) · site-check PASS (248 ids, 527 links) · version-check PASS. CI en curso.

Nota de proceso: este es el séptimo pase sobre un documento de un solo archivo. Por review-damping no pido otro pase; si aparece otra caducidad, el instrumento es #532 (generar o gatear la columna de estado), no una octava corrección local.

@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — FAIL

Verdicto: FAIL
cc: @ChristianLuciani

head_sha: c1c2fa2a
verdict: FAIL
findings: {blocker: 0, major: 1, nit: 1}
class_delta: {new: [], repeat: [2, 4]}
in_diff: 2
in_repo: 0
fuera: 0
assumptions_declared: 4
limits_noted: 5

Veredicto

FAIL — octavo pase v2 sobre el PR. El anti-trim mecánico encuentra cero trims
sin traza
(el único marker en líneas borradas, nunca, sobrevive en el head
:89). Lo que impide el pase es un defecto de clase 4 en la fila #520: afirma
que los on-ramps no mencionan --confirm "verificado" en main@a90263d, pero
en ese sha sí lo mencionan — el commit 3edcc347 (2026-11-12) ya los había
arreglado y es ancestro del base del PR. Es la misma clase que se repitió en los
siete pases anteriores: el documento parafrasea el estado del repo/tracker en
vez de citarlo, y la paráfrasis se vuelve falsa en el momento del merge.

Findings (uno por bloque)

F1 — docs/ROADMAP.md:148 · MAJOR · diff · class:4 · surface:docs/ROADMAP.md§"Ahora — correcciones abiertas (cita del tracker, 2026-11-13)" · recurrence:repeat · ESCALATE(4)

F2 — docs/ROADMAP.md:3 · NIT · diff · class:2 · surface:docs/ROADMAP.md§encabezado · recurrence:repeat · ESCALATE(2)

  • El encabezado declara: «El estado del tracker se cita con fecha, no se
    replica (structural: the roadmap copies tracker state instead of citing it — every merge makes it stale #532)». Es una promesa programática sobre el documento.
  • El cuerpo la cumple a medias: la columna «Verificado» trae fechas y shas, pero
    la columna «Qué queda abierto (fuente)» sigue caracterizando el estado en la
    voz del roadmap («único needs-decision abierto del racimo D29», «decidida
    2026-11-12», «A es aditivo sobre el schema»). F1 es la prueba de que esa
    paráfrasis se vuelve falsa: «on-ramps sin --confirm» llevaba fecha y sha y
    era falsa igual.
  • El contrato (el propio encabezado) no fija qué significa «citar con fecha»
    cuando el cuerpo mezcla ambos comportamientos: ¿basta la columna de fecha, o
    cada afirmación debe llevar el puntero al comentario? Dos lectores legítimos
    leen distinto la promesa.
  • Par (2, §encabezado) ya apareció en los pases 5 y 7 como repeat.

Cobertura

No pude refutar (lo que sobrevivió)

Asunciones que declarás

Límites de tu review

…already in main

The #520 row repeated a claim inherited from the issue's post-merge comment:
that the on-ramps still lack `--confirm` and that SPEC §7's export row lacks
the `--all` rejection clause. Both were verified FALSE at the head:

- commit 3edcc34 (ancestor of main) added `--confirm <digest>` to README,
  START-HERE, TUTORIAL and USER-GUIDE, and the clause to the §7 export row.
- `grep --confirm` on origin/main@a90263d: 1 in each of the four on-ramps; the
  §7 row carries "the refusal prints the reason and the manifest digest".

The row now states what the repo shows and leaves the issue's remaining state
to the tracker — the point of #532.

Refs #532 #520

Session-Id: 809a35be-8b2d-48a9-8e29-527cbd04591e
Session-Name: Ratificar D25 en el SPEC
Models: deepseek-flash → deepseek-v4.1-flash-1017 (openrouter → mistral)
Signed-off-by: Christian Luciani <cluciani@gmail.com>
@ChristianLuciani

Copy link
Copy Markdown
Owner Author

Reconciliación pase 8 — head c7670f1

F1 era correcto, y mi error fue heredar una afirmación de un comentario en vez de verificar el árbol. Lo verifiqué ahora contra origin/main@a90263d:

  • 3edcc347 (ancestro de main) agregó --confirm <digest> a los cuatro on-ramps;
  • grep --confirm en main@a90263d: 1 en cada uno de README.md, docs/START-HERE.md, docs/TUTORIAL.md y docs/USER-GUIDE.md;
  • la fila export profile de SPEC §7 sí tiene la cláusula «the refusal prints the reason and the manifest digest».

La fila de #520 ahora dice lo que el repo muestra (el hallazgo principal y los puntos (2)/(3) están en main vía c22df70 y 3edcc347) y deja el estado restante del issue al tracker — que es exactamente el punto de #532.

F2 también era correcto: la columna «Qué queda abierto» seguía parafraseando. La fila de #520 es la única que lo hacía con una afirmación verificable; ahora cita el sha del commit que la sostiene y no repite el juicio del issue.

Gates en c7670f1 (2026-11-13): spec-drefs in sync (30 filas §5, 608 refs) · agnostic PASS (781 archivos) · evidence in sync · link-check in sync (317 links) · site-check PASS (248 ids, 527 links) · version-check PASS. CI en curso.

Sobre el ESCALATE(4)/(2): no pido otro pase. El instrumento es #532, y este head lo aplica: la sección cita el tracker y el sha que sostiene cada afirmación verificable. Si aparece otra caducidad, corresponde implementar #532 (generar o gatear la columna), no otra corrección local.

Nota para #520: su comentario post-merge (mío, 2026-11-13) afirma que los on-ramps no mencionan --confirm; es falso contra main@a90263d. Lo corrijo en el issue.

@ChristianLuciani

Copy link
Copy Markdown
Owner Author

🔎 Review — PASS-CON-RIESGOS

Verdicto: PASS-CON-RIESGOS
cc: @ChristianLuciani

head_sha: c7670f1a9f07
verdict: PASS-CON-RIESGOS
findings: {blocker: 0, major: 0, nit: 1}
class_delta: {new: [], repeat: ["2"]}
in_diff: 1
in_repo: 0
fuera: 0
assumptions_declared: 3
limits_noted: 3

Verdicto

PASS-CON-RIESGOS — noveno pase v2 sobre el PR. El anti-trim mecánico encuentra cero trims sin traza (el único marker en líneas borradas, nunca, sobrevive en el head :89). Todas las afirmaciones específicas de la tabla «correcciones abiertas» se verificaron ciertas al head contra el tracker y el repo: #501 es el único needs-decision abierto, #520 sigue abierto con sus puntos (2)/(3) aterrizados en main@a90263d (commit 3edcc347, ancestro del base), #529/#493 describen bien la decisión A/B/C/D, #507 y #532 son precisos, y los «cerrados en esta ronda» (#519→#527, #521→a2e8bbc, #517/#518 mergeados) son correctos. La clase 4 (invención/paráfrasis falsa del tracker) desapareció del delta: la sección ahora cita en vez de replicar.

Lo que impide PASS es un único nit de clase 2 que ya apareció en los pases 5, 7 y 8: el encabezado promete «cita con fecha, no se replica (#532)», pero el contrato (el propio encabezado) no define operativamente qué significa «citar» cuando el cuerpo mezcla ambos comportamientos.

Findings (uno por bloque)

F1 — docs/ROADMAP.md:3 · NIT · diff · class:2 · surface:docs/ROADMAP.md§encabezado · recurrence:repeat · ESCALATE(2)

  • El encabezado declara: «El estado del tracker se cita con fecha, no se replica (structural: the roadmap copies tracker state instead of citing it — every merge makes it stale #532)». Es una promesa programática sobre el documento.
  • El cuerpo la cumple a medias: la columna «Verificado» trae fechas y shas, pero la columna «Qué queda abierto (fuente)» sigue parafraseando el estado en la voz del roadmap («único needs-decision abierto del racimo D29: el slice y su dependencia con S503b», «decidida 2026-11-12 (A ahora, B dirección, C futura, D rechazada)») en vez de apuntar al número de comentario/sha específico del tracker. No hay un criterio que distinga qué afirmaciones necesitan puntero y cuáles no: dos lectores legítimos leen distinto lo que promete el encabezado.
  • Instrumento que cierra la clase: definir en el propio documento (o en structural: the roadmap copies tracker state instead of citing it — every merge makes it stale #532) qué significa «citar con fecha» — p. ej. «cada fila apunta al comentario del issue o al sha del archivo que sostiene la afirmación, sin reformularla» — o eliminar la promesa del encabezado si no se va a cumplir operativamente.
  • Par (2, §encabezado) ya apareció en los pases 5, 7 y 8 como repeat.

Cobertura

  • Pack: scripts/review_pack.sh no existe en este repo (vive en prompt-studio). Reuní la evidencia a mano en una pasada agrupada: PR metadata + 8 comentarios de review previos (gh pr view --json comments), diff completo (git diff origin/main...c7670f1 — 1 archivo, +36/−5), estado del tracker de los 13 ids citados (gh issue/pr view), SPEC al base a90263d (§5 D27–D30, §7.1 :500, §7.11, §7.12, §12 M1–M12), packages/core/src/egress.ts al head (EGRESS_MANIFEST_VERSION = 2, cadena prev/baselineHash/hash), commits 3edcc347/c22df70 y su ancestralidad contra a90263d, on-ramps (grep --confirm = 1 en cada uno), §7 export row (cláusula presente), anti-trim sobre las 5 líneas borradas, links relativos del archivo tocado.
  • Contrato consultado a mano (el pack no mapea docs/ROADMAP.md): docs/SPEC.md al base a90263d (§5, §7.1, §7.11, §7.12, §12), AGENTS.md reglas 3/8, session-discipline §3b/3c (body del PR: dos líneas de qué/cómo antes de ##, impacto declarado, firma presente).
  • Archivos abiertos fuera del diff: ninguno — el diff toca solo docs/ROADMAP.md.

No pude refutar (lo que sobrevivió)

Asunciones que declarás

  • Asumí que el estado del tracker leído con gh hoy (2026-11-13) es el que tendrá el PR en el momento del merge; si un issue cambia de estado entre ahora y el merge, las filas que lo citan con fecha «2026-11-13» podrían caducar — pero la sección ahora declara explícitamente que cita, no replica, así que la responsabilidad de la frescura recae en el lector que verifica la fecha.
  • Asumí que scripts/review_pack.sh no existe en este repo porque vive en prompt-studio (no hay sibling ../prompt-studio ni $AGOS_PROMPT_STUDIO); reuní la evidencia manualmente con los mismos datos que el pack habría producido.
  • No verifiqué que los gates listados en el PR body (spec-drefs, agnostic-check, etc.) pasen en el head actual — CI (ci + sign-off) pasó, y el diff es docs-only, así que los gates de código no aplican.

Límites de tu review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant