Found during review of #345 (closed). Independent of that PR.
What is uncovered
The "everything this year" flow does not export through the completeRun / exportFullFiscalYearZip path that docs/PUBLICATION_READINESS.md describes. It runs a separate orchestration:
filed-returns-all-supported-full-fiscal-year.ts:161 continueSavedAllSupportedFullFiscalYearRun(...)
filed-returns-all-supported-full-fiscal-year.ts:343 return exportAllSupportedFinalZip(deps, ledger)
filed-returns-all-supported-full-fiscal-year.ts:474 if (!nextTarget) return exportAllSupportedFinalZip(deps, ledger)
with its own ledger and its own zip phases. No row in the recovery matrix enters it, because every row is keyed to a single return type and artifact type.
So restart behaviour and idempotence of the combined final ZIP are untested: whether a resumed all-supported run rebuilds the final archive without repeating portal targets, and whether a partially-exported combined ZIP is detected rather than treated as complete.
Why it matters
This is the flow the panel presets actually offer. A user running "everything this year" is on this path, not the per-selection one, and it is the path that assembles a full year across every return type into one archive — the largest and longest-running operation Pack performs, and therefore the one most certain to be interrupted by MV3 worker termination.
What would close it
An evidence row (or rows) for the all-supported run itself, distinct from the per-selection matrix, recording at minimum:
- resumed run after service-worker restart rebuilds the final ZIP without repeating targets
- resumed run after browser restart does the same, with the offscreen document torn down
- a partially-exported combined ZIP is not reported as complete
Worth deciding alongside #347, since both concern the export window and the same instrument.
Not blocking
No known defect — this is missing coverage, not a reported failure. Recorded so the gap is deliberate rather than accidental.
Found during review of #345 (closed). Independent of that PR.
What is uncovered
The "everything this year" flow does not export through the
completeRun/exportFullFiscalYearZippath thatdocs/PUBLICATION_READINESS.mddescribes. It runs a separate orchestration:with its own ledger and its own zip phases. No row in the recovery matrix enters it, because every row is keyed to a single return type and artifact type.
So restart behaviour and idempotence of the combined final ZIP are untested: whether a resumed all-supported run rebuilds the final archive without repeating portal targets, and whether a partially-exported combined ZIP is detected rather than treated as complete.
Why it matters
This is the flow the panel presets actually offer. A user running "everything this year" is on this path, not the per-selection one, and it is the path that assembles a full year across every return type into one archive — the largest and longest-running operation Pack performs, and therefore the one most certain to be interrupted by MV3 worker termination.
What would close it
An evidence row (or rows) for the all-supported run itself, distinct from the per-selection matrix, recording at minimum:
Worth deciding alongside #347, since both concern the export window and the same instrument.
Not blocking
No known defect — this is missing coverage, not a reported failure. Recorded so the gap is deliberate rather than accidental.