| name | update |
| description | Use when a system has changed and its blueprint needs to reflect the change — new behaviour, modified flows, revised rules, or resolved questions. |
Incrementally update an existing blueprint after a system change. Read only affected sections, make targeted edits, record the change — without rewriting the entire blueprint.
Inputs: blueprint directory path, description of what changed.
Open README.md: current state, sections, version, completion tier.
Targeted loading is the point of the multi-file format.
Consult . Does this change reveal other stale sections?
Edit affected files. Follow . Preserve existing accurate content.
Add entry per delta protocol: | [version] | [date] | [author] | [one sentence per change] |
If decisions were made — terminology resolutions, scope boundaries, rule changes — record with rationale.
In README.md: bump version, update date, update section statuses, update tier if advanced.
Convene 5-panellist quick review (product owner, engineer, user advocate, completeness advocate, simplicity advocate). For trivial changes (typo, single open question), use 3 panellists.
Output: updated section files, updated changelog.md, updated decisions.md (if applicable), updated README.md manifest.
