# RSN-1 — capture-resession's counters (the safety check of a destructive rewrite) mis-report in three reachable cases, and the schema pin can silently drop `captured_at` from an owned capture file

status: open · raised panel run 21 (2026-09-11, change-review catch on PR #152 — does NOT count toward the frontier cadence) · class: moat / instrument calibration (the guard that guards the crown-jewel data) · effort ~0.5 pd · horizon: before the next holiday-class ruling — Thanksgiving **2026-11-26** is a hard date (the backup GH cron fires Mon–Fri regardless of NYSE holidays; 06-19 and 07-03 already produced this class)

---

**Plain-language summary for an owner reading one paragraph.** The
2026-09-06 STAMP-1 ruling was executed by `thales capture-resession`, whose
apply-report counters ARE its verification step — the `dropped` counter is
what caught the first apply's real 892-row bug. This run's change review
verified the executed ruling clean (ledger totals sum exactly; dry-run at
HEAD says "nothing to do") — but the counters themselves are wrong in three
cases the NEXT ruling can reach, and one of them is not a counter bug but
silent data loss: with a pre-2026-09-02 legacy file as the first source,
the rewritten target file **silently loses the `captured_at` column** — the
column the module's own docstring calls "the truth" — from an
un-backfillable owned forward-capture file. A guard that lies during the
next destructive apply is the cardinal-rule class.

## Mechanism — ground truth verified this run at HEAD `fa55f0d`

All in `src/thales/data/resession.py`:
1. **Quarantine double-count** (:322-325) — when a quarantine parquet
   already exists for the date, the incoming part is concat-merged with it
   and `report["quarantined"] += part.height` re-counts the pre-existing
   quarantined rows on every apply. Fires on any future ruling touching an
   already-quarantined date; inflates the CAPTURES.md ledger totals.
2. **`dropped` conflation + mis-attribution** (:333-344) —
   `dropped = base.height + new.height − merged.height` counts
   pre-existing intra-base duplicates as collision drops, and under
   `keep="first"` an existing row can silently lose to its own twin
   (contradicting "existing rows win"); :342-344 then stamps the identical
   aggregate onto every move sharing the target, so a two-source→one-target
   ruling double-reports in the ledger.
3. **Schema pinned to `sources[0]`'s RAW columns** (:339 with :286,
   :297-298) — the rewritten target is
   `merged.select(src_frames[sources[0]].columns)`, and `src_frames` holds
   the raw read; the `captured_at` backfill mutates only the local `df`.
   A legacy source without raw `captured_at` → the column is silently
   dropped from the rewritten target. Converse: a `sources[0]`-only column
   raises `ColumnNotFound` mid-apply, and apply is only per-file atomic.
   The legacy-file scenario is exactly the scenario this tool exists for.

The 2026-09-06 ruling escaped all three only because it had no pre-existing
quarantine files, no intra-base dupes, single-source targets, and
homogeneous schemas.

## Fix shape (propose-only)

Count only rows moved **this apply** into `quarantined`; compute per-move
collision counts against base keys and report intra-base dedup separately
(or refuse a base with internal duplicates); write the union schema (or an
explicit per-stream stable schema) instead of `sources[0]`'s raw columns.

## Pre-registered kill criterion / done-when

Three regression tests, each red today:
1. Pre-existing quarantine file → `quarantined` equals rows moved this
   apply only.
2. Two moves into one target get their own collision counts, and a base
   with an internal duplicate reports zero collisions.
3. Legacy `sources[0]` without raw `captured_at` merging into a target
   that has it → `captured_at` **values** survive in the rewritten file
   (asserting presence alone does not satisfy), and a `sources[0]`-only
   column does not raise.

Idempotency test re-green after. Renaming counters without the per-case
semantics does not satisfy this row.