The daily aggregates go when their own retention window says so

[iderex]

Closes #315.

DailyAggregateRetentionDays was on the settings page, was validated and was stored, and no run read it. A daily aggregate was kept for ever whatever the number said, while the raw rows behind it went at ninety days by default — the opposite of the sentence the two settings carry about the two windows.

The means

C#, in the plugin assembly and its suite, because the artefact is a scheduled task inside a Jellyfin plugin and the store, the sweep and the vocabulary it extends are already there. Nothing here adds a language, a runtime or a dependency the tree does not carry, the properties are refusable by the suite that already runs, and every claim below carries the command that produced it. A second means would have meant a second apparatus for one deletion.

What is in it

• IPlayStore gains CountRollupsBefore and DeleteRollupsBefore, over days rather than moments, because a rollup is keyed to a calendar day. The deletion carries a bite for the reason the play deletion does.
• RetentionSweep takes a second cutoff and answers both windows in one run. A second scheduled task on the same schedule and the same store is how two windows drift apart until one is quietly not running.
• The day the aggregate window ends on is read in the zone the store states its rollups were counted in, not the machine's. A store that has keyed no rollup states no zone and is not asked for a day.
• The aggregates go before the play rows. A run stopped between the two leaves the rows the deleted aggregates were folded from in the file, so what went can be folded again; the other order takes those rows away first and makes the same deletion terminal on a server whose settings say it is not.
• The deletion is recorded as Retention, and DeletionClass says why on the member a reader of that vocabulary meets.
• Run returns what it removed per table rather than one sum.

Every guard was proven by breaking it

Each near miss below was applied to the working tree on its own, the suite run, and the edit reverted. dotnet test Jellyfin.Plugin.Stats.sln -f net9.0 -p:CollectCoverage=false, 1048 cases in the baseline:

near miss	result
WHERE Day < $day widened to <=	2 failed, 1046 passed
LIMIT $limit dropped from the delete	1 failed, 1047 passed
DeletionClass.Retention swapped to Corrective	1 failed, 1047 passed
the null-zone guard replaced by a fallback to TimeZoneInfo.Utc	1 failed, 1047 passed
the configuration held from the first run in a field	2 failed, 1046 passed
the two loops put in the other order	1 failed, 1047 passed

A case that claimed a window was read at the run did not prove it

This is a defect in what was already merged, and it is repaired here because the new case would otherwise have copied it. TheWindowIsReadAtTheRunAndNotHeldFromBefore moved a field on the configuration object it had already handed the task, so a task that read its configuration once and held it saw the mutation too and stayed green. Measured: the fifth near miss above left that case passing until it was rewritten. Both cases now hand a different object on the second run.

The suite and the gate

dotnet test Jellyfin.Plugin.Stats.sln
Bestanden!   : Fehler:     0, erfolgreich:  1048, ... (net9.0)
Bestanden!   : Fehler:     0, erfolgreich:  1049, ... (net10.0)
| Jellyfin.Plugin.Stats | 98.92% | 100%   | 96.25% |

The branch threshold in coverage.props is 100 and is met on both frameworks; the new branches are covered by the boundary case, the null-zone case and the cancellation case rather than by a threshold moving.

bash tools/invariants/lint.sh
21 rule(s) checked over the tree, no match.

bash tools/invariants/lint.sh --self-test
21 rule(s), each proved by a near miss of its own.

One invariant did fire during the work and the code changed rather than the rule: no-configuration-value-in-a-static-field read a private static PluginConfiguration AConfiguration(...) test helper as a static holding a setting. The helper is gone and each case writes its own object.

Size

850 insertions over 26 files, against the 400-line guide, and it is one readable thing rather than two changes. One property holds across it — a second window exists and is answered by the sweep that already exists — and 14 of the 26 files are the two new interface members arriving at the fakes that implement IPlayStore. Re-planning was considered and rejected: an interface member and its only implementation cannot land apart without an unimplemented interface in between, and the sweep, the class decision and the two documents are the same statement said in four places.

What this does not do

• It does not rekey a rollup when the zone setting moves. A store keeps the zone it first stated, which is A rebuild from the play rows, and what each class of deletion does to a rollup #253, and this deletion reads that stated zone rather than working around it.
• It does not refuse an aggregate window shorter than the play-row window. Both arrangements are legitimate; which one an operator has chosen decides whether the deletion is recoverable, and docs/configuration.md now says so where the number is typed.
• No second reader ran on this board tonight. The evidence above stands in place of one.

Scope

The issue declares Jellyfin.Plugin.Stats/ScheduledTasks/, Jellyfin.Plugin.Stats/Data/, docs/configuration.md and docs/plugin-data.md. The change also touches Jellyfin.Plugin.Stats.Tests/, which the issue's own done-conditions ask for and which its Scope: line does not name.