1. GitHub Issue is the ticket
One canonical issue abstraction avoids a redundant ticket skill while leaving room for future tracker adapters.
Expert review · confirmed 2026-07-12
Issue-Backed GitHub Delivery Architecture
The architecture packet is approved. The review found no surviving correctness, security, architecture, testing, dependency, or specification findings that block or qualify implementation.
Confirmation date: 2026-07-12
Confirmed artifacts: briefing-slides/github-delivery-architecture.html, tasks/roadmap.md, and tasks/todo.md.
Approval source: the user's request to review and approve the existing packet, followed by an evidence-backed expert review of all five gates.
This record is finished and current for this approval cycle. Later evidence may amend it only after the prior confirmed page is archived and the amendment is highlighted.
Verdict
APPROVED
The packet defines a coherent replacement for direct-to-primary mutation delivery. It centralizes fragile GitHub operations in three low-freedom base subskills, makes issue/branch/PR reuse deterministic, preserves stop-on-ambiguity behavior, and keeps merge separate from ordinary shipping.
The design is intentionally additive to existing safety boundaries: quality evidence remains mandatory before publication; merge remains gated; release and deploy continue to require clean, current primary; production deployment still requires explicit confirmation.
Approved decisions
2. Every tracked mutation gets a branch and PR
GitHub-backed work reuses or creates one issue, one non-primary branch, and one PR; it never defaults to a primary push.
3. Shipping stops at ready for review
ship, ship-end, and Codex exec may publish or update a ready PR, but cannot merge by default.
4. Release and deploy wait for merge
Only a clean, current primary branch is releasable or deployable; an open PR is not equivalent to merged state.
5. GitHub failure never weakens primary
Missing remotes or authentication preserve safe local non-primary work and surface a blocker instead of falling back to primary.
Evidence matrix
| Gate | Repository evidence | Review conclusion |
|---|---|---|
| Universal safety layer | packs/base/PACK.md installs base skills independently of optional packs. | The three GitHub subskills can be universally available without cross-pack routing failures. |
| Replace direct-primary delivery | Current ship, ship-end, and commit-and-push-by-feature contracts explicitly land work on primary. | The packet targets the actual shared mutation boundary rather than requiring hundreds of domain-skill rewrites. |
| Separate publication and merge | branch-lifecycle already defines strict conflict, check, approval, and unresolved-finding merge gates. | Moving merge behind github-pr merge preserves and clarifies the strict gate. |
| Preserve release/deploy safety | release and deploy already require primary, clean state, and current remote state; production remains explicitly confirmed. | Deferring them until merge is consistent with existing preflights. |
| Fail safely | Packet rules stop on ambiguous dirty trees, secrets, conflicts, missing remotes, or unauthenticated GitHub state. | No failure path authorizes a weaker direct-primary fallback. |
Findings
Critical: none
High: none
Medium: none
Low: none
Spec conformance: no divergences
Documented decisions — no action needed
The architecture deliberately changes the repository's former direct-to-primary default. It deliberately does not auto-merge, close issues when PRs merely open, deploy from PR branches, or create a second generic ticket abstraction.
Positive observations
The serial three-phase rollout is appropriately ordered: safety primitives and regression policy first, orchestrators second, provisioning and dogfood last. The migration's own ready-PR dogfood criterion is a strong end-to-end proof.
Residual risks and implementation checks
No architecture-level blocker remains. Implementation must still prove issue/PR deduplication, dirty-tree ownership, default-branch resolution, review/check status handling, and idempotent retry behavior with executable fixtures.
These are acceptance criteria already represented in the roadmap, not reasons to withhold architecture approval.
Sources reviewed
Implementation handoff
Proceed serially with Phase 1: create and validate mirrored github-issue, github-branch, and github-pr base subskills plus the canonical GitHub delivery contract before modifying any shipping orchestrator.