Per-tag wiki prompts

[kenforthewin]

Summary

The most-repeated community request (asked 5× on Discord): a tag can now carry its own wiki generation/update prompts, overriding the global Settings → Prompts values for that tag's article only. Right-click a tag → Wiki Prompt… — the named use cases (a "Todo Summary" wiki over unchecked tasks, a "Diary" wiki over daily notes, per-meeting summary wikis) all work by writing one prompt on one tag.

Design

• Precedence, resolved once in build_wiki_strategy_context (the single funnel both strategies and the update path already flow through): tag override → global custom prompt → built-in default. The update chain takes the tag's generation prompt as its middle term so a deliberately-shaped article keeps its shape through incremental updates.
• Prompts stay off the Tag payload (the tree ships hundreds of rows; prompts run to kilobytes) — fetched on demand via GET/PUT /api/tags/{id}/wiki-prompts, blank-clears-override normalization server-side.
• Storage: nullable columns on tags — SQLite V25 (transactional, crash-safe) + Postgres 026 (additive, fleet-gated). migrate push copies them. On Postgres the columns are db_id-scoped, i.e. genuinely per-tenant.
• Agentic strategy: the research phase appends the custom prompt to its curation instructions so it selects the material the synthesis prompt will need.

Adversarial review

Four independent review passes (migrations/storage, wiki semantics, API/frontend, test adequacy) ran against the feature commit; every confirmed finding is fixed in the second commit. Highlights:

• V25 crash window (reproduced): two autocommitted ALTERs behind a first-column-only guard could permanently strand the schema — now one transaction, plus a debug_assert pinning user_version to LATEST_VERSION after the ladder.
• Precedence chain fully pinned: the e2e asserts on the system prompt the wiremock provider actually receives, for both halves (tag-wins and global-fallback) and for the update path — each verified to fail under the specific mutation it guards.
• CI gap closed: the Postgres job never ran e2e_wiki, e2e_tags_settings, or migrate_tests — their _postgres arms reported ok without executing. All three are now in the workflow; every previously-dormant arm was verified green against a real pg16 first. The frontend job also gains tsc --noEmit.
• Modal hardening: load state is keyed by tag id, so a failed fetch can never render one tag's prompts under another tag's title, and Save is gated on a successful load (PUT is a full replace — a blind save could otherwise clear prompts the user never saw).
• Also: the SQLite prompt read moved off the write mutex onto the read pool; PG db_id fencing, route auth, and 404-body consistency are each pinned by new tests; whitespace-only global prompts no longer shadow the built-in default.

Known limitations (deliberate)

• Entry point is the tag context menu only — unreachable on touch, like Rename/Delete (pre-existing platform gap; a wiki-reader affordance is a natural follow-up).
• The section-ops update machinery has no delete op, so a "Todo Summary" wiki can't shed completed items incrementally — full regeneration does that (pre-existing).
• The PUT body accepts unknown fields per the pinned missing-field-clears contract; no deny_unknown_fields.

Test plan

• cargo test -p atomic-core -p atomic-server — 36 suites green (SQLite).
• All PG-gated suites green against dockerized pg16: storage (83), pipeline (22), multi-db, migrate (5), server e2e incl. the 24 newly-executing wiki/tags arms.
• npm test (87) and npx tsc --noEmit clean.
• Storage round-trips, precedence, db_id fencing, auth, and 404 bodies each covered on both backends.

🤖 Generated with Claude Code