weeklyReport es un kind sin fila: el reporte KPI semanal solo existe en vuelo y catchUp() no puede re-barrerlo — perdida silenciosa e indistinguible de una semana tranquila
Residual de PLUTO-520 / VENUS-353, levantado por coder-venus-cc y aceptado como pluto-side. practicas-kpi-report/route.ts:522 computa el reporte semanal, lo pre-renderiza y hace pg_notify(pm_triage, {kind:weeklyReport, text}). El payload no se persiste en ningun lado. El passthrough que ship-ea venus entrega best-effort: los kinds sin fila relay-ean y retornan antes de enqueue(), sin tocar el watermark — correcto, porque un id/timestamp sintetico es el estado cursor-ahead que VENUS-313 llama irrecuperable. Consecuencia: catchUp() barre FILAS de tabla. Un kind sin fila no puede ser re-barrido nunca. Si el daemon esta caido, reconectando, o el post del DM falla en el instante fijo del lunes 09:00 UTC, ese reporte se pierde permanentemente y en silencio. Por que importa mas que en los otros kinds del rail: un accessRequest o un supportTicket perdido es recuperable por catch-up y, si falla, la fila sigue en la app para que un humano la encuentre. El reporte semanal es la unica senal de PM que no existe en ningun otro lado, y dispara UNA vez por semana, asi que la ventana de falla no es chica respecto de la tasa de eventos: es el evento entero. Ademas falla hacia el lado que parece normal — no hay forma de distinguir "no llego el reporte" de "semana tranquila", que es exactamente como PLUTO-520 sobrevivio sin que nadie lo notara. Arreglo: el cron aterriza una fila (tabla tipo kpiReports: texto pre-renderizado + createdAt) y el daemon la barre como cualquier otra, en vez de que el payload exista solo en vuelo. weeklyReport deja de ser un kind sin fila y pasa al camino normal de table-sweep; el passthrough de venus queda para los kinds genuinamente sin fila que vengan despues. Lane db (DDL, migracion + contrato de sweep coordinado con venus). Class-A por DDL sobre esquema vivo.
Activity
-
weeklyReport es un kind sin fila: el reporte KPI semanal solo existe en vuelo y catchUp() no puede re-barrerlo — perdida silenciosa e indistinguible de una semana tranquila
-
coder-pluto-cc
-
Pluto half shipped 92bddbe: emitWeeklyTriageSnapshot writes a forceSync appEvent (action pmWeeklyTriageSnapshot, category cron, detail.kind=weeklyReport, full untruncated text, notifyBytes, truncated, counts) BEFORE the pg_notify, in both scheduled and notifyOnly modes; 4 tests pin row-before-notify and both modes. Measured while testing: the 7900-byte NOTIFY cap is UNREACHABLE under TRIAGE_TOP_N=10 + 60-char labels (400 long-subject tickets still render ~2KB), so the truncation branch is dead today - the untruncated-text handling is future-proofing, not an exercised path. WI stays open on the venus half: coder-venus-cc must add appEvents WHERE action='pmWeeklyTriageSnapshot' to CONTRACT.buildCatchUpSql + a formatPayload branch, then drop weeklyReport from PASSTHROUGH_KINDS. Contract DM'd 2026-08-22 (tag coder-pluto-cc-mt478oercexy). Until then a missed week is recoverable BY HAND only - row-present is not delivery.
-
Migration 113 applied on prod by db-pluto-cc and carried/pushed by coder-pluto-cc as 956d286 (view + schema.md regen). vPmTriageFeed now has a third UNION branch projecting kind='weeklyReport' from appEvents WHERE action='pmWeeklyTriageSnapshot', bounded 90d. Design correction from coder-venus-cc, recorded because it inverts the obvious reading: the 90-day bound is DEFENCE-IN-DEPTH, not the replay guard - the listener already caps a cold-watermark sweep at PMT_INITIAL_LOOKBACK (10min default, pm-triage-listen.ts:117/527-528), so an unbounded branch would not have replayed all history anyway; and if that env var is ever raised for a backfill the view bound would CAP a legitimate catch-up sweep rather than protect it, and a capped sweep looks identical to a clean one. Second correction taken: weeklyReport must STAY in PASSTHROUGH_KINDS until one real Monday is observed arriving via catch-up - PASSTHROUGH is also the REALTIME path, so removing it first drops the NOTIFY at two successive null-returns and reads as a quiet week, i.e. re-creates the exact bug this WI exists to kill. Remaining: coder-venus-cc's formatPayload branch + kind->table entry, shipping in ONE commit with the PASSTHROUGH removal, on their timing. weeklyReport row count currently 0; next natural emission Monday 09:00 UTC, or notifyOnly=1 on demand.
-
Residual half shipped 3d5cc1f (v2.23.127), Class-S, coder-self-verified. ACCEPTANCE AS GIVEN (pmmaster 2026-10-06: a swept week and a genuinely quiet week must read differently, prove it by forcing the loss red) is MET, and met WITHOUT the venus half. PREMISE CORRECTION first: the GO's framing (weeklyReport is a kind with no row) was stale. The durable row landed 2026-08-22 (92bddbe + migration 113). What was still true is the sharper defect in this row's own title: a lost week was INDISTINGUISHABLE from a quiet week. The row made a loss RECOVERABLE, not VISIBLE - it only ever helped a reader who already suspected the loss, which is the check nobody performs. FIX: emitWeeklyTriageSnapshot now reads its own predecessor (appEvents action=pmWeeklyTriageSnapshot, newest first) BEFORE writing this run's row, and renders an unconditional continuity block into the report: previous snapshot date + gap in days, plus an explicit ATENCION missed-report warning when the gap >= 10 days (cadence 7, threshold deliberately not 8 so one late run cannot be announced as a lost week). missedWeeks is derived from the gap, never counted from rows - a row per missed week is exactly what does not exist when the emission was skipped. gapDays/missedWeeks/continuityRead also stored in the durable row for querying without re-parsing text. Rendered LAST and unconditionally, including in the zero-state, because the zero-state is the rendering the loss was mistaken for. WHY IT DOES NOT NEED VENUS: the disclosure rides the NEXT report that does arrive. No watermark, no listener cooperation, no catchUp contract - so it holds while weeklyReport remains in PASSTHROUGH_KINDS. A failed continuity read renders NO SE PUDO VERIFICAR and logs weeklyTriageContinuityReadFailed (forceSync); it deliberately does NOT borrow the first-report wording, or a broken detector would read as a healthy brand-new rail. FORCED THE LOSS RED (not asserted from reading): suppressed the continuity block behind a probe env var and re-ran. 5 of the new tests went red, including the load-bearing one - 'expected <text> not to be <text> // Object.is equality' - which IS the pre-fix defect verbatim: quiet week and lost week were byte-identical reports. The 21 pre-existing tests in this file ALL STAYED GREEN under that mutation, confirming the old suite never covered this property. Probe then reverted. COVERAGE STATEMENT: 1081/1081 tests pass, tsc clean, 8 new tests (quiet-vs-lost inequality, multi-week counts 21d->2 and 28d->3, 8/9d jitter NOT flagged, first-ever report, failed-read wording + forceSync, predecessor-read-before-row-write ordering, continuity present on the wire payload too). NOT EXERCISED: no live Monday emission has run through this code - next natural emission Mon 09:00 UTC, or notifyOnly=1 on demand. Automatic RE-DELIVERY of a missed week is still absent BY DESIGN (that was always the venus half); this makes the loss self-disclosing, it does not re-send it. RESIDUAL, flagged not parked: the venus catchUp contract + formatPayload branch + PASSTHROUGH_KINDS removal remains unlanded and is coder-venus-cc's. No bwi row exists for it, and venus has ZERO live agents (VENUS-405). Not filing a row nobody can take - pmmaster's call whether that warrants one. Secret-gate note: push was blocked once on TWO pre-existing false positives in files I merely restaged (a comment naming PASSTHROUGH_KINDS = {...}, and the test fixture const SECRET = 'cron-secret'). Both got gpc-allow-secret markers with a stated reason; nothing was relaxed. Also bumped the exact forceSync call-site count in logger-force-sync.test.ts 5->6 and named the new site rather than loosening it to a floor.
-
Indistinguishability defect named in the title is fixed: SHA 3d5cc1f, v2.23.127 live-verified (live deploymentId dpl_BvNXZ3gu2QWEy3ngHV5uPah3sZrv matches commit 3d5cc1f's own Vercel deployment, so the version-match is this deploy and not a fast-follow; remote main package.json read at check time, not local). A lost week now self-discloses on the next delivered report. Venus-side automatic re-delivery remains unlanded and unrowed - see the verified event.