Notices: an ecosystem change, announced once

A change every repo should make — re-copy a template, raise a dependency floor — reaches a repo only if its agent reads the right page. A notice makes the board tell it (board #2548): every onboarded project's brief shows its owed notices until each is adopted or declared not applicable.

• A notice is a type:policy entry tagged targets:all or targets:<project>: what to change and why, with a link to the instructions. It's the inverse of a practice, which a project opts into.
• Checks are data, never commands. A check: tag names one of a fixed set of kinds the CLI runs in the repo; nothing a notice says is ever executed, so the board can't run code in every repo:
  • check:file-exists:<path>
  • check:file-equals:<path>@<sha256>: the file's bytes, pinned
  • check:file-contains:<path>|<text>
  • check:lock-resolves:<package>>=<version>: in bun.lock or package-lock.json
• Only where it applies. applies-if:<check> (the same kinds, e.g. applies-if:file-exists:.github/workflows/publish.yml) is checked in the repo too: where it fails, the notice is recorded not applicable, with that reason.
• Adoption is verified where it can be. virta notices runs the checks in the repo it's in; when they all pass it records adopted:<project>@<fingerprint> on the notice. A changed check is a new fingerprint, so adoption reopens. A notice with no checks is adopted by saying so (virta notices adopt #n), and any notice can be declared not-applicable:<project> with the reason.
• A project's own entry can override it (board #2497's precedence): an open entry with scope:<project> and overrides:#n releases that project, and the matrix says by which entry — never silently.
• It informs; the repo's agent acts. The board edits no repo, and a notice never enrolls a project: only projects on the board see them.

The notice's own tags are the adoption matrix: who has, who hasn't.