Driver

Current distribution model is fork on GitHub + git pull upstream + /update. Adopter customisations (settings.json overrides, role-file tweaks, hook config) live in the same git tree as framework files, so every upstream sync risks merge conflicts on files the adopter has touched. No version pinning, no clean install/uninstall, no separation between read-only framework and adopter customisation layer.

Discussion surfaced the need for a designed packaging strategy. Operator leaning high-disruption (layered install) but wants all options compared in an AgDR before committing to implementation.

Scope

In scope:

• Author docs/agdr/AgDR-0029-framework-packaging-and-distribution.md (status: PROPOSED)
• List all candidate packaging models — fork-as-install (status quo), release-tarball delivery, layered install, npm package, Homebrew formula, one-line install script
• Pros / cons / migration cost for each
• Recommendation with rationale (operator-leaning: layered install)
• Open PR against dev for operator to comment with their pick

Out of scope:

• Any implementation work (separate ticket once option is picked)
• Final decision (operator decides via PR comment; AgDR Decision section gets updated post-pick)

Acceptance Criteria

• AgDR file written at docs/agdr/AgDR-0029-framework-packaging-and-distribution.md
• Frontmatter status is proposed, category architecture
• At least 5 packaging options in the Options Considered table
• Each option has Pros / Cons / Migration cost columns
• Decision section flags awaiting operator pick
• PR opened against dev and the AgDR renders on GitHub

Risks

• Layered install (if picked) is a breaking change for every existing adopter — migration path must be articulated before any implementation lands
• AgDR is reversible (supersedeable) but downstream implementation cost compounds; the AgDR must be honest about migration ergonomics