bump-revision

name

bump-revision

description

Update revision date and version metadata across one or many SOPs in the current project, then optionally recompile. Reads the Typst frontmatter (or a leading metadata block) of each target document, increments the revision (semver-style: minor by default, patch/major on request), updates the date to today, and writes back. Use when the user has reviewed a set of procedures and wants to mark them as a fresh revision.

bump-revision

Bump revision metadata across one or more SOPs.

Inputs to gather

1. Targets — one of:
   • A specific file path
   • A glob (sops/*.typ)
   • A binder name from binders.yaml (bumps every doc in that binder)
   • all — every .typ SOP in the project (confirm before doing this)
2. Bump level — patch (default — 1.0 → 1.0.1), minor (1.0 → 1.1), or major (1.0 → 2.0).
3. Note (optional) — a short revision-note string to append to the doc's revision history block.
4. Recompile? (default yes) — after bumping, run compile on each affected doc and rebuild any binder that references it.

What to do

1. Resolve targets to a concrete file list. Confirm with the user if all was requested or the list is large (>10 files).
2. For each file:
   • Parse the leading metadata. Plugin convention is a Typst block at the top:

     #let meta = (
       title: "Rocket & Missile Alert Response",
       revision: "1.2",
       date: "2026-04-01",
       audience: "household members",
       source: "Home Front Command",
     )
     

   • Bump revision per the requested level.
   • Set date to today's ISO date.
   • If a revisions: history list exists, append (version: "<new>", date: "<today>", note: "<note>").
   • Write back.
3. If recompile: invoke compile for each updated .typ. If any of them belong to a binder defined in binders.yaml, also rebuild that binder.
4. Print a summary: which files were bumped (old → new version), and which PDFs were regenerated.

Notes

• Be conservative parsing the metadata block — if a doc doesn't follow the convention, skip it and report it; don't try to invent metadata.
• The metadata convention is plugin-recommended, not required. Documents without it are still valid SOPs; they just opt out of bump-revision.
• Revision strings are free-form in the source — common patterns: "1.0", "2024.04", "r3". Prefer semver-ish but accept whatever's already there and increment numerically where possible. If unparseable, ask.