Mega Gate — Next-3 Macro Roadmap (avoid fragmented prompts)
Mega Gate — Next-3 Macro Roadmap
Date: 2026-06-18 · Workstream: LEGO-PILOT-SLICE-0-B2-MEGA-GATE-BUNDLE-2026-06-18 (Deliverable 3 of 20) · Editorial revision: rev1
Class: design-only / sequencing roadmap / decision-support · READ-ONLY · NON-ENACTING · NON-AUTHORIZING · NOT remediation · NOT technical design · NOT implementation · NO channel selected · NO blocker resolved · NO runtime touched.
Metadata convention. Editorial revision (rev1) only. AgentData storage revision and
content_lengthare authoritative in AgentData metadata at read time; not pinned in this body.
Roadmap lock. This packet sequences future Owner-gated macros so the work proceeds in fewer, larger, well-bounded steps instead of many fragmented prompts. It authorizes none of them, opens nothing, and selects no channel. Each macro on the roadmap remains a separate Owner gate; sequencing is recommendation-only.
0. Status and non-authorization
STATUS: PASS — engineering / design-only. This is a complete design-only roadmap: a recommended next-three-macro sequence (each macro still Owner-gated), the LEGO rule that keeps each macro a separate control surface, the anti-fragmentation rule (scale prompt size, not coupling), and the hard stop before any write-enabled tier.
Engineering PASS ≠ authority PASS. A PASS means the sequencing is complete and safe on paper. It is not an Owner authorization to open any macro. Default disposition: HOLD.
Pipeline position (downstream-only). Deliverable 3 of the Mega Gate Bundle; it answers "how to avoid another cycle of small fragmented prompts" by sequencing the remaining design-only and (later) Owner-gated work. It opens no macro.
Non-authorization (explicit). As Deliverable 1 §0 (no DB write/DDL/DML; no runtime mutation; no inspect/certified writes; no gate flip; no owner assignment; no contract promotion; no pg_cron/queue enable; no source/prior-report patch; no current/staging corpus; no TD; no implementation; no blocker resolved; no channel selected; v0.1/FIX7 V3 not overwritten; v0.2 not authority).
Evidence basis — INHERITED_EVIDENCE. No runtime queried. AgentData metadata authoritative at read time. CAV-3/CAV-4/CAV-5 carried.
Reading discipline (Codex caveat, honored). All sources read directly from AgentData KB, bounded/sequential, by the main process — no parallel/background reader-agents, no sub-agents, no local-prose inference. /tmp = decode-scratch only, never SSOT.
1. Purpose
Answer the macro's eighth question: how to avoid another cycle of small fragmented prompts while still respecting every gate. The packet answers:
- What is the recommended next-three-macro sequence? — §5.
- How does each macro stay a separate LEGO control surface? — §5 + §4.
- What is the anti-fragmentation rule (bigger prompt, not bigger coupling)? — §4.
- Where is the hard stop before any write? — §6.
The one rule, above all detail. Scale prompt size and deliverable count, never system coupling. A larger macro must still produce separate, independently reviewable, independently discardable deliverables; it must never merge planning→TD→implementation or fuse blocks. The roadmap is a recommendation; each macro is a separate Owner gate.
2. Sources read
All 25 required sources read first-hand from AgentData KB, by the main process, sequentially; none SOURCE_NOT_READ (full list in Deliverable 20 §2). Used principally: the planning bundle + its Codex review (the next-step menu); Deliverable B (readiness gate); Phase-1B (the R1–R5 macro framing; "big enough to save time but does not merge remediation/TD/implementation"); the mandatory preamble's scale rule (carried as the anti-fragmentation rule); operating-rules (out-of-scope-blocker STOP).
3. Accepted baseline (carried, not re-derived)
- Phase-1B already established the macro discipline: five named remediation macro packages (R1–R5), each "a future, separate, Owner-gated workstream," with an explicit "does not merge remediation, technical design, or implementation into itself." This roadmap inherits that discipline for the B2 path.
- The accepted bundle's next-step menu (carried): Owner chooses among (a) open actual B2 TD with a selected channel, (b) a standalone R2-D2 channel decision, (c) a sibling design-only TD-prep. This roadmap orders those (and the read-only re-verify) into a sequence.
- Aggregate B2 TD is No-Go (Deliverable 2); the roadmap front-loads the closure routes that retire the No-Go/Partial criteria before TD.
- Blockers — all OPEN. Tool/packet lock carried.
4. Analysis — anti-fragmentation without coupling
The fragmentation problem. Doing each prerequisite as its own tiny prompt (one for channel, one for Đ0-G, one for B3/B4, one for staging, …) multiplies orchestration overhead and review cycles. The fix is to scale the prompt, not the coupling: a single larger macro can carry many separate deliverables (this 20-file bundle is the pattern) as long as:
- Each deliverable stays a separate control surface — independently reviewable, replaceable, discardable (the LEGO invariant).
- No deliverable depends on another's internals — they integrate only through explicit references, never a hidden shared write surface.
- No automatic transition — planning does not auto-become TD; TD does not auto-become implementation; each tier is a separate Owner gate.
- The primary-block lock holds — B2 stays the only primary block; B5/B7 stay dependency-only; the channel stays internal and unselected.
Smell test for any future macro (carried from the preamble): if the macro produces one merged mega-plan that makes all pieces depend on each other, or a mega-registry / mega-graph / mega-birth pipeline, or a hidden shared write surface, or an automatic planning→TD or TD→implementation transition — it is NOT_LEGO_COMPATIBLE and must return HOLD. A big macro that produces N separate gated deliverables is fine; a big macro that fuses them is not.
5. Recommended next-three-macro sequence (recommendation-only)
Each macro below is a separate Owner gate; the Owner opens at most one at a time; none is authorized here. The sequence front-loads write-free closure (Macro-1), then the Owner-decision/out-of-band prerequisites (Macro-2), then the staging-build readiness-to-build boundary (Macro-3). Actual B2 TD is a fourth gate beyond this roadmap, opened only when the entry gate (Deliverable 7) is Go.
| # | Macro (recommended) | Tier | What it produces (separate deliverables) | What it must NOT do | Closes / advances | Owner gate |
|---|---|---|---|---|---|---|
| Macro-1 | Read-only runtime re-verification (Option E / F) | read-only evidence | A read-only re-confirmation report: B3 inspect_* types/order; B4 consumer fires only on all-three and only reads; switches/queue/cron/pg_cron state; counts; persisted GUC empty. Each finding a separate evidence item. |
Mutate anything; treat verify as authorization; read transient GUC (out-of-band) | G-2 (Go); refresh evidence for G-7/G-8/G-10 | Owner authorizes the read-only pass (same class as Phase-1) |
| Macro-2 | Channel decision + Đ0-G source authority + S2 owner (Options B + D + G-5), as separate deliverables in one macro | decision / out-of-band | (a) the Owner's channel selection record (the Owner's act, informed by Deliverables 4/5/6); (b) the Đ0-G recovery/acceptance record (external S6); (c) the S2 owner-assignment decision (Điều 37 → Điều 32, decision only). Three separate control surfaces. | Let the macro select the channel (it records the Owner's choice); wire/install/write anything; treat working-source as authoritative silently | G-4 (selection), G-3, G-5 (decisions) | Owner takes each decision; writing any of them is a further gate |
| Macro-3 | Staging build readiness → (separate gate) staging build (Option C) | readiness → write-gated build | The staging build-readiness package (Deliverables 11/12/13 deepened into a build-go checklist), then — behind a separate gate — the actual disposable staging surface. | Create staging schema/corpus/SQL or extract live data in the readiness step; promote staging→production | G-6 (staging surface) | Readiness is design-only; the build is a separate Điều 32 gate |
| (beyond roadmap) | Actual B2 TD | TD | Only after Deliverable 7 entry gate is Go (G-3/G-4/G-5/G-6 closed; G-2/G-7/G-8/G-9/G-10 at least Partial-acceptable) | Start automatically from Macro-3; write any DDL/SQL/function/cron | — | A distinct Owner gate, not part of this roadmap |
Why this order (recommendation-only). Macro-1 is write-free and retires the largest block of INHERITED_EVIDENCE → strongest risk reduction per unit of effort. Macro-2 packages the three Owner-only/out-of-band prerequisites together (they are independent decisions, so bundling them as separate deliverables in one macro saves cycles without coupling them). Macro-3 builds the workshop last, once the contract inputs are frozen. Actual TD is deliberately outside the three-macro window so the planning→TD transition stays a conscious Owner gate, never automatic.
Anti-fragmentation note. Each macro is "big enough to save time" (multiple deliverables) but each deliverable remains a separate, discardable control surface — exactly the pattern of this 20-file bundle and of Phase-1B's R1–R5 framing. No macro merges tiers; no macro fuses blocks; no macro selects a channel as authority.
6. Owner-gated future work — and the hard stop
Every macro on the roadmap is forbidden now (OWNER_GATE_REQUIRED). Listing the sequence is scoping, not authorization.
| Future macro | Gate required | Forbidden now? |
|---|---|---|
| Macro-1 read-only re-verification | Owner authorizes a read-only pass | Yes |
| Macro-2 channel/Đ0-G/owner decisions | Owner decision per item (+ external S6 for Đ0-G) | Yes |
| Macro-3 staging build readiness | Điều 32 (readiness design-only; build a separate gate) | Yes |
| Actual B2 TD (beyond roadmap) | Owner decision after Deliverable 7 entry gate Go | Yes |
| Any write-enabled remediation / producer build | Điều 32 + S2 + channel + staging + rollback + runtime-verification plan, in order | Yes |
The hard stop (carried). No PASS — engineering or Codex — authorizes a write. The write-enabled tier opens only after, in order: a design-only package → Codex review → Owner approval → a rollback plan → a runtime-verification plan. No automatic TD. No automatic write-enabled remediation.
7. What remains unresolved
- No macro is opened or authorized here. The roadmap is recommendation-only; the Owner opens one gate at a time.
- Actual B2 TD is outside the three-macro window by design — the planning→TD transition stays a conscious Owner gate.
- CHANNEL not selected (Macro-2 (a) is the Owner's act; this packet selects nothing —
CHANNEL_AUTHORITY_DRIFTguarded). - B5/B7 not opened — they are not on the roadmap as design (
B5_B7_SCOPE_CREEPguarded); they remain separate future Owner-gated packages. - Blockers — all OPEN, none resolved: CONS-002, CONS-003, CELL-003/004/007, HOLD-1, HOLD-2, RISK-BYPASS, GOV-016/017, GOV-REUSE-001, Điều 39 runtime-EMPTY, Điều 35 production-readiness FAIL.
- FUTURE_TECHNICAL_DESIGN_REQUIRED (NOT written here): every macro's internal mechanics.
8. Ready for GPT/Codex review
Yes — as a design-only sequencing roadmap, not an authorization.
Core rule, kept above all detail: scale the prompt, not the coupling. The recommended sequence — Macro-1 (read-only re-verify) → Macro-2 (channel/Đ0-G/owner decisions as separate deliverables) → Macro-3 (staging build readiness → separate build gate) → (separate gate) actual B2 TD — keeps every macro a separate Owner gate and every deliverable a separate control surface. No tier transitions automatically; no channel is selected; no write is authorized.
Default disposition: HOLD. Engineering PASS = a complete roadmap on paper; it is not an Owner authorization to open any macro. No PASS authorizes writes. All blockers remain OPEN.