[callumalpass]

Part of the TaskNotes app-settings change. Order: tasknotes-spec rc.6 → this PR → tasknotes-model publish → TaskNotes App ships → TaskNotes plugin upgrades collections. Cross-links are added once all PRs exist.

The artifacts were generated with TASKNOTES_MODEL_DIR=<tasknotes-model PR branch> node scripts/sync-tasknotes-pack.mjs. The sync script now also writes the settings contract, schema and type.

Changes

• mdbase.app-settings 1.0.0: the contract and schema, copied byte for byte from mdbase Reader (apps/reader/mdbase/... on main), so both apps install the same contract.
• tasknotes.settings 1.0.0 and seed type tasknotes-settings v1 at _types/tasknotes-settings.md:
  • The schema is inline, as the catalog requires.
  • It implements both contracts and is unique on app (scope type).
  • It matches app: dev.tasknotes.
• tasknotes.task 0.3.0-rc.6 (digest sha256:c400ead6…) at _contracts/tasknotes.task/0.3.0-rc.6.md.
  • rc.5 stays managed at _contracts/tasknotes.task.md but is not provided, following the person 1.0.0 precedent.
  • This keeps types that still implement rc.5 valid: preserved edited types and plugin-written types. TaskNotes upgrades them itself.
  • Rc.3–rc.5 artifacts are unchanged.
• Pack 0.3.0-rc.19:
  • Seeds starter revision 6 (type v5) with upgrade_from revisions 5 to 1.
  • Seeds the settings type.
  • Updates the unversioned schema files to rc.6. Contracts inline their schemas, so the retained rc.5 contract does not depend on them.
  • rc.18 is now hidden.
• Tests:
  • an rc.12→rc.19 upgrade across all scenarios
  • TaskNotes 5.0 plugin collections install rc.19 without conflicts; a preserved type stays on rc.5 with its contract intact
  • the seeded settings type
  • no settings record is created by the pack
• README: a "TaskNotes settings record" section.

Known limitation (recorded in tests and README)

The rc.12→rc.19 generator-defaults scenario covers a collection that edited its status colours. It now conflicts on binding/status/definitions: arrays merge atomically, and rc.6 removes per-status fields from the same list. The upgrade is blocked for review and the collection keeps its rc.5 type. TaskNotes (plugin and app) upgrades such types itself and writes the record. The alternative was to keep the moved per-status fields in the rc.6 starter's definitions, which would contradict the move.

Checks

• MDBASE_TS_DIR=<mdbase-ts v0.3.0-rc.9 build> npm test: all pass (27 + 125 tests). Verified 27 contract and 15 pack installs with mdbase-ts.
• The Rust CLI verification (MDBASE_VERIFY_CLI) was not run.

Related PRs

• Spec: tasknotes.task 0.3.0-rc.6: move app behaviour to the TaskNotes settings record callumalpass/tasknotes-spec#11
• Contracts: TaskNotes rc.19: tasknotes.task rc.6 and the TaskNotes settings record #18
• Model: 0.3.0-rc.20: TaskNotes settings record and tasknotes.task rc.6 callumalpass/tasknotes-model#25 (0.3.0-rc.20, not published)
• TaskNotes App: TaskNotes settings record (dev.tasknotes, tasknotes.task rc.6) callumalpass/tasknotes-app#311
• Plugin: Move app behaviour to the TaskNotes settings record (tasknotes.task rc.6) callumalpass/tasknotes#2432

Order: contracts → model publish → App ships → plugin upgrades collections.