Slice #22.4: Define toolkit asset update mechanism for consuming projects

[dieterbaier]

Parent: #22

Goal

Define how projects that copy architecture-knowledge-toolkit assets can detect and apply toolkit updates over time.

Background

The example/ drift found in #22 is a local instance of a broader problem: bootstrapped projects copy scripts, templates, metamodel schemas, skills, and instructions from the toolkit. Once copied, they can silently drift from the toolkit's current contracts and generators.

Scope

Design and document a lightweight update mechanism for consuming projects. Possible direction:

• Add a toolkit asset manifest that records copied source paths, toolkit version or commit, and checksums.
• Provide a report-only command that compares copied assets against the current toolkit release or main.
• Distinguish upstream-managed copied assets from intentional local overrides.
• Document update modes:
  • report drift only;
  • apply non-conflicting asset refreshes;
  • prepare a PR with copied asset updates.
• Decide whether example/ should become a CI fixture for detecting local toolkit/example drift.

Acceptance Criteria

• A documented update strategy exists for bootstrapped projects.
• The strategy covers scripts, templates, metamodel schemas, skills, and semantic contracts.
• Intentional local overrides are not silently overwritten.
• There is a proposed place for version/checksum metadata in consuming projects.
• The project records whether example/ drift should be checked in CI.