Split out of #207 rather than fixed there, because the fix is a persistence change and persistence is ask-first.
What
The per-period evidence list marks a period saved only when the run's step carries full-fiscal-year-zip-downloaded. That signal is emitted by fullFiscalYearCleanupCompletedStep at completion and is transient: a later re-summarisation builds its step from the ledger through completeFullFiscalYearStep, which does not carry it.
So a run whose ZIP downloaded and cleaned successfully shows every period as Captured once the panel is reopened, with the status line saying the ZIP is not confirmed.
Why it is not fixed by reading the ledger
zipPhase: "cleaned" looks like the durable form of the same fact and is not. Three paths reach it:
downloaded-cleanup-pending — a confirmed deliveryno-artifacts-cleanup-pending — a run that produced no ZIP at alllegacy-cleanup-pending — a retained staging cleared on upgrade, never exported
The distinguishing phase is overwritten by the transition, so the origin cannot be recovered afterwards. #207 tried this inference and it reported never-exported legacy files as Saved — the exact overclaim the column exists to prevent.
What a fix needs
A durable record that the ZIP reached the browser, surviving the phase transition. That is a new persisted field, which AGENTS.md lists under Ask first — so it needs a decision rather than a patch.
It is not taxpayer data: it is one boolean about one run. But the rule is about widening what is persisted, not only about what kind of data, and this repository has already had one field added today without that conversation.
Current behaviour is the safe direction
Understating is correct for an evidence column: Pack genuinely cannot prove, after a restart, that the browser still holds a file it handed over. AGENTS.md requires guards to fail closed and never treat "could not determine" as "matches". So this is a real degradation in usefulness, not a correctness bug, and it can wait for the decision.
Split out of #207 rather than fixed there, because the fix is a persistence change and persistence is ask-first.
What
The per-period evidence list marks a period
savedonly when the run's step carriesfull-fiscal-year-zip-downloaded. That signal is emitted byfullFiscalYearCleanupCompletedStepat completion and is transient: a later re-summarisation builds its step from the ledger throughcompleteFullFiscalYearStep, which does not carry it.So a run whose ZIP downloaded and cleaned successfully shows every period as Captured once the panel is reopened, with the status line saying the ZIP is not confirmed.
Why it is not fixed by reading the ledger
zipPhase: "cleaned"looks like the durable form of the same fact and is not. Three paths reach it:downloaded-cleanup-pending— a confirmed deliveryno-artifacts-cleanup-pending— a run that produced no ZIP at alllegacy-cleanup-pending— a retained staging cleared on upgrade, never exportedThe distinguishing phase is overwritten by the transition, so the origin cannot be recovered afterwards. #207 tried this inference and it reported never-exported legacy files as Saved — the exact overclaim the column exists to prevent.
What a fix needs
A durable record that the ZIP reached the browser, surviving the phase transition. That is a new persisted field, which
AGENTS.mdlists under Ask first — so it needs a decision rather than a patch.It is not taxpayer data: it is one boolean about one run. But the rule is about widening what is persisted, not only about what kind of data, and this repository has already had one field added today without that conversation.
Current behaviour is the safe direction
Understating is correct for an evidence column: Pack genuinely cannot prove, after a restart, that the browser still holds a file it handed over.
AGENTS.mdrequires guards to fail closed and never treat "could not determine" as "matches". So this is a real degradation in usefulness, not a correctness bug, and it can wait for the decision.