[danielmlr]

Phase 1 of the content-freshness plan: the bugs that would have shipped. Stacked on #9, which is stacked on #8. Merge those first with merge commits, then delete their branches, and GitHub retargets this PR to main.

Nothing is published, so the storage layout and settings keys change without a migration. No changeset: a changeset would make the release workflow open a version PR and publish to npm. The first changeset comes with the release.

What was broken

The plugin had only ever run in-process. Running it through the sandboxed test host showed most of this.

• Sandboxed, every admin surface with findings answered 502 (INVALID_BLOCK_RESPONSE).

  • The stats blocks sent stats instead of items.
  • The table had no page_action_id.
  • The settings form sent elements instead of fields and submit.

  EmDash validates only sandboxed responses. Blocks are now typed with @emdash-cms/blocks 0.39.0 (types only), and tests load every surface through the sandboxed host.

• A cron run made 16 bridge calls against the sandbox's 10. Seven were KV reads for settings, then one per collection cursor, a cron.list and a log line. Settings and sweep state are now one KV key each. tests/budget.test.ts counts every invocation's worst case (measured below).

• The report showed at most 100 findings, and not the most urgent ones. It asked storage for 200 rows, got at most 100 and sorted those. Findings are now one row per entry with an indexed rank, and the table pages through them most urgent first.

• Rows of trashed or deleted entries, and of removed collections, stayed forever. A finished sweep removes every row it did not confirm, and content:afterDelete removes an entry's row at once.

• A fix showed only after the next nightly audit. Publish, unpublish, schedule, unschedule and restore now re-check the entry. content:afterSave stays unhooked: it fires on every autosave, which for a sandboxed install means a new isolate every few seconds while someone types.

• The nightly audit was never scheduled for plugins listed in astro.config.mjs. plugin:activate only fires on a runtime enable or install. The dashboard widget and the report now schedule it on first view.

• A missed scheduled update of a published entry went unreported. The rule now also covers published entries, after an hour of grace for EmDash's own scheduler.

• Two settings problems. "Entries per run" accepted 200 where content.list returns 100. An invalid cron expression was stored and only failed later; now the form keeps the old schedule and says why.

• A malformed page cursor made the report route answer 400. It now falls back to the first page.

Findings now store the rule and its values instead of an English sentence, so the report can be localised (Phase 2) without touching stored data.

Code review

/code-review high ran on the first commit before this PR was opened. It reported 10 findings.

Fixed in the second commit, each with a test that fails when its fix is removed (checked one by one):

1. A failing content.list wiped a collection's findings. The error counted as "collection deleted", so cleanup removed every finding of a collection that was never audited. Now only a collection that schema.getCollection no longer knows is skipped. Any other error propagates before the state is written, and the next scheduled run retries the page.
2. The audit was never scheduled again after a reinstall. An uninstall keeps KV but deletes cron tasks, so a stale record blocked scheduling. Activation now always schedules.
3. An admin request could overwrite a cron run's progress by writing the whole sweep state back. The registered schedule is now recorded in the settings key, which only admin requests write. (No test: it's a race.)
4. A scheduling error took down every admin page. Page loads now log it and render. The settings form reports the scheduler's own reason instead of calling every failure an invalid expression.
5. "Load more" after the cursor's row was removed returned an empty page. It now falls back to the first page.
6. The status route's counts had no names. They now come as entriesBySeverity: { high, medium, low, total }.

Not changed:

• Migrating rows and settings from the old format (2 findings). Never published or deployed; the only installs were local development databases.
• A trashed entry rewritten by a run that listed it moments before. The window is the milliseconds between content.list and putMany inside one run, and the next sweep removes the row.
• No changeset. See above.

The review also looked at whether dropping the cron.list guard allows parallel sweeps, and concluded it doesn't: the cron runner processes due tasks one at a time, and a doubled chain merges back after one run.

Verified

• 65 tests (was 38), emdash-plugin validate, typecheck and build. The bundle is 12.7 KB.

• scripts/compat-matrix.sh 0.39.0 0.39.1 0.40.0 on top of the 0.40.1 baseline: content-freshness 65 and analytics 288 on every version.

• Bridge calls per invocation:

  Invocation	Calls
  Run that starts a sweep	8
  Follow-up	7
  Cleanup	6
  Content hook	3
  First dashboard view	8
  First report view	9
  Paging, Audit now, saving settings	at most 7

  The limit is 10.