The about-page bundle had to add an About entry to the nav. The nav was already wired with Library, Stack, and Notes, but the exact structure of the component varied by render style: some nav implementations use a data array, others use inline JSX with anchor tags. The bundle had to handle both without knowing which one was in the repo today.
The shipped solution is a Python step that scans src/components/ for any .astro file referencing both /notes and one of /library or /stack. That’s the candidate set. For each candidate, the script tries Pattern 1 (regex for a data-array entry like { href: ‘/notes’, label: ‘Notes’ }), then Pattern 2 (regex for inline JSX like Notes). If either matches, the script clones the Notes entry, swaps /notes for /about, swaps the label, increments the number (08 to 09 for the mobile sheet), and inserts the new entry adjacent to the Notes one.
If neither pattern matches in any candidate file, the script prints a warning and exits with code 0:
WARN: pattern detection failed in all candidates. /about works via URL but is unlinked. Patch nav manually.
The ship continues. The page deploys. The about route is reachable by typing /about into the address bar. The only thing missing is the link in the nav, and adding that by hand takes thirty seconds.
The decision was to make the patch optional rather than required. If I had wired it as a precondition, the bundle would refuse to ship every time the nav structure drifted slightly. By treating it as a best-effort, the ship survives refactoring I haven’t told the agent about yet.
The principle: split your script into preconditions (fail loud, abort) and best-effort steps (warn, continue). Decide upfront which is which.