Skip to content

docs(#265): AgDR-0029 framework packaging & distribution (proposed)#267

Closed
atlas-apex wants to merge 1 commit into
devfrom
docs/GH-265-framework-packaging-agdr
Closed

docs(#265): AgDR-0029 framework packaging & distribution (proposed)#267
atlas-apex wants to merge 1 commit into
devfrom
docs/GH-265-framework-packaging-agdr

Conversation

@atlas-apex

Copy link
Copy Markdown
Collaborator

Summary

Authors AgDR-0029docs/agdr/AgDR-0029-framework-packaging-and-distribution.md — proposing a packaging & distribution model for the ApexYard framework. Status: PROPOSED. Decision section is empty pending operator (Ahmed) comment with their pick.

Options compared

  1. Status quo — fork-as-install
  2. Release-tarball delivery (low-disruption, keeps fork)
  3. Layered install (.apexyard/ read-only dir + overlay) — current lean
  4. npm package (npx apexyard init)
  5. Homebrew formula
  6. One-line install script (curl | bash)
  7. Framework as git submodule

Plus combination plays: 2 + 3 staged, 3 + 4 layered, 3 + brand mitigation.

Recommendation

Option 3 (layered install) with brand-mitigation pattern — visible install dir name (apexyard/ not .apexyard/), registry stays at fork root, fork-root README.md names the framework. Rationale + tradeoffs in the AgDR's Recommendation section.

How to comment

Pick by commenting on this PR with the option number (e.g. "go with 3 + brand mitigation" or "prefer 2 → 3 staged"). Once decided I'll fill in the Decision and Consequences sections in a follow-up commit and re-request review.

Closes #265 once the operator pick is recorded.

Testing

  • AgDR renders cleanly on GitHub (frontmatter visible, table renders, links work)
  • Operator reviews and comments with picked option
  • Decision section gets updated in a follow-up commit after operator pick

Glossary

Term Definition
Fork-as-install The current model — adopter forks the framework repo on GitHub and treats the fork as their ops repo
Layered install A read-only framework dir (e.g. apexyard/) + adopter-customisation overlay outside it
Manifest A version + checksum file recording exactly which framework files are installed, enabling clean upgrades and apexyard uninstall
Brand visibility How easily a viewer of the adopter's GitHub org can tell they're running ApexYard
Release-cut model AgDR-0007 — dev for daily work, main for tagged releases only

- Lists 7 packaging options: status-quo fork, release-tarball, layered
  install, npm, Homebrew, install script, git submodule
- Pros / cons / migration cost per option
- Combination plays (2+3 staged, 3+4 layered, 3 + brand mitigation)
- Recommends option 3 (layered install) with brand-mitigation pattern
- Decision section left empty pending operator pick via PR comment

Refs #265

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

@atlas-apex atlas-apex left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review: PR #267

Commit: 2f59e7181a3c5d7a9991b18bcc607959c88037dd

Summary

Docs-only PR adding docs/agdr/AgDR-0029-framework-packaging-and-distribution.md at status proposed. Frames seven packaging-and-distribution options for the framework with a clear lean (option 3 + brand mitigation) and an intentionally empty Decision section pending operator pick.

Checklist Results

  • Architecture & Design: N/A (docs)
  • Code Quality: N/A (docs)
  • Testing: N/A (docs)
  • Security: Pass — no secrets, no private-project refs
  • Performance: N/A
  • PR Description & Glossary: Pass — Glossary present with 5 well-scoped terms
  • Technical Decisions (AgDR):Pass — the PR IS the AgDR
  • Adopter Handbooks: N/A (no code paths matched)

Issues Found

None.

Notes

  • Frontmatter shape is consistent with the extended AgDR schema used by recent records (AgDR-0021, AgDR-0023). It extends templates/agdr.md's minimal shape with id / timestamp / agent / model / session / trigger / status / category — matches established practice.
  • Linked records all resolve: AgDR-0007, AgDR-0021, AgDR-0023 exist at the referenced paths.
  • "Status: PROPOSED" + empty Decision section is intentional and clearly flagged in the body, the TL;DR quote block, and the Decision section itself. The reader cannot mistake this for a finalised decision.
  • Options table is well-shaped: pros / cons / migration cost per option, plus three combination plays called out separately. The recommendation explicitly names the option being rejected (status quo) and why.
  • Glossary terms are domain-specific and earn their place.
  • No leaks: no managed-project names referenced.

Suggestions

  • Once the operator picks, the Decision + Consequences sections will need a follow-up commit. Consider also flipping status: proposedstatus: accepted in the frontmatter at that point and adding the PR URL to Artifacts (currently (will be filled in once opened)).

Verdict

APPROVED (posted as COMMENT — Rex is the PR author and cannot self-approve via GraphQL). Awaiting operator pick to finalise the Decision section in a follow-up commit.


Reviewed by Rex (Code Reviewer Agent)
Reviewed commit: 2f59e7181a3c5d7a9991b18bcc607959c88037dd

@atlas-apex atlas-apex marked this pull request as draft May 17, 2026 23:30
@atlas-apex

Copy link
Copy Markdown
Collaborator Author

Parking this PR for now — converting to draft. The AgDR-0029 packaging decision can wait until after the v1.3.0 release cut; revisit when capacity allows. The diff and Decision section will stay intact (status: PROPOSED) and the AgDR is referenceable on dev once #265 is decided.

@atlas-apex

Copy link
Copy Markdown
Collaborator Author

Superseded by #343 — same scope (#265 packaging AgDR), correctly numbered AgDR-0047 (the #267 attempt used AgDR-0029 which is already taken on dev). Closing this draft.

@atlas-apex atlas-apex closed this May 20, 2026
@me2resh me2resh deleted the docs/GH-265-framework-packaging-agdr branch June 5, 2026 16:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants