Mega Gate — B3/B4 Compatibility Readiness
Mega Gate — B3/B4 Compatibility Readiness
Date: 2026-06-18 · Workstream: LEGO-PILOT-SLICE-0-B2-MEGA-GATE-BUNDLE-2026-06-18 (Deliverable 9 of 20) · Editorial revision: rev1
Class: design-only / compatibility readiness / decision-support · READ-ONLY · NON-ENACTING · NON-AUTHORIZING · NOT remediation · NOT technical design · NOT implementation · 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.
Compatibility-readiness lock. This packet states what must be re-confirmed (read-only) about the B3 inspect-result stud and the B4 certify consumer before B2 TD, and the coupling rules that must hold. It changes no contract (B3 is the load-bearing stud), couples B2 to no B4 internals, runs no producer, and writes no TD. B3/B4 are dependency/interface surfaces referenced here, not redesigned.
0. Status and non-authorization
STATUS: PASS — engineering / design-only. This is a complete design-only compatibility-readiness packet for the two surfaces B2 plugs into: B3 (the inspect_* data contract) and B4 (the certify consumer). It states what a future read-only re-confirmation must show, the coupling rules that must hold, the no-contract-drift constraint, and the Owner-gated future work.
Engineering PASS ≠ authority PASS. A PASS means the compatibility readiness is fully specified on paper. It is not an Owner authorization to change B3, re-verify at runtime, or build B2. Default disposition: HOLD.
Pipeline position (downstream-only). Deliverable 9 of the Mega Gate Bundle; it is the narrow B3/B4 prerequisite (Option F) deepened — the focused subset of the read-only re-verification (Macro-1) that retires GATE-2. It changes nothing.
Non-authorization (explicit). As Deliverable 1 §0, and specifically: it changes no B3 contract; couples B2 to no B4 internals; runs no producer/certify; writes no TD. B5/B7 not opened. v0.1/FIX7 V3 not overwritten; v0.2 not authority.
Evidence basis — INHERITED_EVIDENCE. No runtime queried. B3/B4 facts inherited from the R2 readiness scope + the block-contract/interface packets. 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
State the B3/B4 compatibility prerequisites for B2 TD (GATE-2 / PO-5). The packet answers:
- What is the B3 stud, and what must a read-only re-confirm show? — §5 B3.
- What is the B4 consumer, and what must a read-only re-confirm show? — §5 B4.
- What coupling rules must hold across B2/B3/B4? — §5 coupling.
- What would a contract drift look like, and how is it guarded? — §5 no-drift.
The one rule, above all detail. B3 is the load-bearing stud that lets B2 (producer) and B4 (consumer) stay decoupled — "healthy but starved" proves it. B2 TD must design to the existing B3 shape and must not couple to B4's internals or change B3 except by a coordinated B2+B4 change. This packet states the readiness; it changes nothing.
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 R2 readiness scope §3/§5/§6 (the birth_registry schema; only fn_birth_auto_certify names inspect_* and only reads them; inspect-named triggers = 0); the block-contract packet (B3/B4 contracts, AC-3); the interface packet (B4 reads production inspect_* only); the Điều 0-G rule-set (the all-three-present certify rule); Điều 4 note (B4's certified=true is TEMP-stage completeness, not canonical).
3. Accepted baseline (carried, not re-derived)
- B3 — Inspect result (contract surface) [PARTIAL]: the three
inspect_*timestamp columns (inspect_pen,inspect_stamp,inspect_gate) — the stud between producer (B2) and consumer (B4). Shape present; unpopulated for the 1.21M backlog. B3 carries meaning and order, no behavior. - B4 — Certify consumer [EXISTS — healthy, starved]:
trg_birth_auto_certify → fn_birth_auto_certify(ENABLED) flipscertified=true, certified_atatomically per row once all threeinspect_*are present. It only readsinspect_*; it never produces them (AC-3). It is "healthy but starved" because no producer writes the stamps. - Runtime grounding (carried): exactly one live function names
inspect_*(fn_birth_auto_certify) and only reads them; inspect-named triggers = 0; no live PG setter; 192 birth triggers (191 enabled) mintcertified=false. - Canonical caveat (Điều 4 note): B4's
certified=trueis a TEMP-stage completeness signal, not canonical status; canonical/kernel entities need a fail-closed promote checker + Owner gate (Mức 3 / Đ32) at promote — B2's stamps must not be construed as canonicalization. - Blockers — all OPEN. Tool/packet lock carried.
4. Analysis — why B3/B4 readiness is a narrow but load-bearing prerequisite
B3 is the single interface B2's whole design hangs on: if its shape/order/semantics are not exactly what B2 writes and B4 reads, the producer and consumer silently disagree. The decoupling is already proven (B4 healthy-but-starved), which is the strongest possible evidence that the stud works — but the bundle's evidence is INHERITED, so GATE-2 asks for a read-only runtime re-confirmation of the stud and the consumer before B2 TD commits to them. The re-confirm is write-free (catalog/information_schema/pg_proc reads); it is the narrow subset of Macro-1. The point is not to re-design B3/B4 (they are fine) but to convert "carried shape" into "current evidence."
5. B3/B4 compatibility readiness
5.1 B3 (inspect-result stud) — what a read-only re-confirm must show (GATE-2)
| # | What the read-only re-confirm must show | Why | Read-only-provable? |
|---|---|---|---|
| B3-1 | The three columns inspect_pen/inspect_stamp/inspect_gate exist with the expected types (timestamptz) |
B2 writes into this exact shape | Yes (information_schema.columns) |
| B3-2 | The PEN→STAMP→GATE meaning/order is fixed (the stud's semantics) | B2 must respect the order; B4 reads it | Yes (carried Đ0-G; shape via catalog) |
| B3-3 | No "complete" signal exists on a partial set (B3 carries no behavior) | a partial set must not drive certify | Yes (catalog: inspect-named triggers = 0) |
| B3-4 | The schema may carry extra columns (e.g. status, canonical_address, owner, jsonb_profile) that B2 must not touch |
B2 writes only the three inspect_* columns |
Yes (information_schema; carried R2 readiness §3) |
B3 readiness verdict: READY in shape (carried); a read-only re-confirmation of B3-1…B3-4 is the GATE-2 obligation. No B3 change is proposed; B3 evolves only by a coordinated B2+B4 change.
5.2 B4 (certify consumer) — what a read-only re-confirm must show (GATE-2)
| # | What the read-only re-confirm must show | Why | Read-only-provable? |
|---|---|---|---|
| B4-1 | trg_birth_auto_certify → fn_birth_auto_certify is ENABLED and fires only when all three inspect_* are present (atomic per row) |
B2 completing all three legitimately triggers B4 | Yes (pg_trigger/pg_proc) |
| B4-2 | fn_birth_auto_certify only reads inspect_* (it is the sole live function naming them) — it never produces them (AC-3) |
preserves the producer/consumer decoupling | Yes (pg_proc source search — carried R2 readiness §5) |
| B4-3 | B4 reads production inspect_* only — never a staging candidate |
staging must not trigger a production certify (Deliverable 12) | Yes (carried staging IO contract §7) |
| B4-4 | B4's certified=true is TEMP-stage completeness, not canonical (no promote-checker bypass) |
B2's stamps must not be read as canonicalization | Yes (carried Điều 4 note) |
B4 readiness verdict: READY (carried as healthy-but-starved); a read-only re-confirmation of B4-1…B4-4 is the GATE-2 obligation. No B4 change is proposed; B2 never calls B4 and never depends on B4 internals.
5.3 Coupling rules that must hold (B2 ↔ B3 ↔ B4)
| Rule | Statement | Grounded in |
|---|---|---|
| C-1 | B2 writes only the three inspect_* columns (the B3 surface); never certified/canonical/identity/KG |
B2-AC-1…4; §5.1 |
| C-2 | B4 reads inspect_* and flips certified only; it never produces inspect evidence |
AC-3; §5.2 |
| C-3 | B2 never calls B4; B4 never calls B2 — they meet only at B3 | the decoupling that makes B4 testable / "healthy but starved" |
| C-4 | The downstream certify is an effect through the stud, not a call — completing all three inspect_* triggers B4 independently |
carried; surfaced for S8 (Deliverable 17) |
| C-5 | B3 changes only by a coordinated B2+B4 change — never unilaterally | the stud is the interface; the coupling is intentional and explicit, not hidden |
5.4 No-contract-drift constraint
B2 TD must not: widen the output beyond the three inspect_* columns; add a "complete" signal on a partial set; change B3 except by a coordinated B2+B4 change; couple to B4's internals; or let a staging candidate reach B4 (Deliverable 12). Any of these is a contract drift and is rejected. This packet proposes no B3/B4 change; it states the readiness and the coupling rules only.
6. Owner-gated future work
| Future work | Gate required | Forbidden now? |
|---|---|---|
| Run the read-only re-confirmation of B3-1…B3-4 / B4-1…B4-4 (closes GATE-2) | Owner authorizes a read-only pass (Macro-1 / Option F) | Yes |
| Change the B3 contract (only by a coordinated B2+B4 change) | Điều 32 + a coordinated B2+B4 design | Yes |
| Build B2 to write into B3 | Điều 32 + S2 + channel + staging | Yes |
Re-verify B4 by exercising it (set inspect_*, expect certify) |
Điều 32 + a built/governed producer + staging fixture | Yes |
7. What remains unresolved
- GATE-2 is Partial — the B3/B4 shape is carried, not runtime-reconfirmed; the read-only re-confirm is owed (Macro-1 / Option F).
- B3 is PARTIAL (unpopulated backlog) — the columns exist but are unset for the 1.21M uncertified rows; that is the B2 gap, not a B3 defect.
- The downstream-certify interaction (C-4) is surfaced for S8 (Deliverable 17) — completing all three
inspect_*triggers B4; the rollback unit must account for it (HOLD-2 open). - Canonical caveat (B4-4) — B4's
certified=trueis not canonical; canonical needs a promote-checker + Owner gate; B2's stamps must not be read as canonicalization. - 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): the re-confirmation queries; any B3 change; the B2 producer; any certify exercise.
8. Ready for GPT/Codex review
Yes — as a design-only compatibility-readiness packet, not a contract change.
Core rule, kept above all detail: B3 is the load-bearing stud; B4 is the healthy-but-starved consumer; B2 TD designs to the existing B3 shape, never couples to B4 internals, and changes B3 only by a coordinated B2+B4 change. A read-only re-confirmation of B3-1…B3-4 / B4-1…B4-4 retires GATE-2; no B3/B4 change is made, and no producer is run.
Default disposition: HOLD. Engineering PASS = a complete compatibility readiness on paper; it is not an Owner authorization to re-verify at runtime, change B3, or build B2. No PASS authorizes writes. All blockers remain OPEN.