Mega Gate — R2-D2 Channel Authority Recommendation (recommendation-only)
Mega Gate — R2-D2 Channel Authority Recommendation
Date: 2026-06-18 · Workstream: LEGO-PILOT-SLICE-0-B2-MEGA-GATE-BUNDLE-2026-06-18 (Deliverable 4 of 20) · Editorial revision: rev1
Class: design-only / channel recommendation / 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.
Channel-authority lock — the central lock of this packet. This packet states a RECOMMENDATION_ONLY — NOT AUTHORITY — OWNER_GATE_REQUIRED — FUTURE_TECHNICAL_DESIGN_REQUIRED preference among the candidate channels. It does not select, use, implement, wire, or promote any channel. No channel is made authority. The channel is a replaceable internal of B2 (B2-AC-7); whichever the Owner later chooses must stay inside the block so the contract is unaffected. If any wording here reads as a selection, that is
CHANNEL_AUTHORITY_DRIFTand must be corrected to recommendation-only.
0. Status and non-authorization
STATUS: PASS — engineering / design-only. This is a complete design-only channel recommendation packet: the carried 5-channel classification, the recommendation-only preference among the two candidates, the explicit non-selection statement, the anti-overreach guardrails, and a Codex check-list for whether the recommendation overreaches.
Engineering PASS ≠ authority PASS. A PASS means the recommendation is complete and fair on paper. It is not an Owner authorization to select, wire, install, promote, or build any channel. Default disposition: HOLD.
Pipeline position (downstream-only). Deliverable 4 of the Mega Gate Bundle; it carries forward the accepted R2-D2 channel decision packet (Deliverable A of the planning bundle) as a recommendation for an eventual Owner decision. It selects nothing and opens no package.
Non-authorization (explicit). As Deliverable 1 §0, and specifically: it does not select or wire a channel; does not install pg_cron or any extension; does not promote any agent-api contract DRY_RUN→REAL_RUN; does not enable any queue worker/master switch; writes no scheduler/runner/cron spec. v0.1/FIX7 V3 not overwritten; v0.2 not authority.
Evidence basis — INHERITED_EVIDENCE. No runtime queried. Channel facts inherited from R2a + the accepted channel decision packet. AgentData metadata authoritative at read time. CAV-3/CAV-4/CAV-5 bound what is provable about each channel.
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 third question: which channel should be recommended for an Owner decision, without becoming authority? The packet answers:
- What is the carried 5-channel classification? — §3.
- What is the recommendation-only preference, and why? — §5.
- What makes this a recommendation and not a selection? — §5 + §0 lock.
- What would constitute overreach, and how is it guarded? — §5 + §7.
- What must Codex check? — §8.
The one rule, above all detail. The channel is a replaceable internal, not the block boundary. B2's contract (read uncertified → write inspect_* only, fail-closed) is channel-independent. This packet may recommend; it may not select, and it may not let any channel leak into the contract.
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 accepted R2-D2 channel decision packet (Deliverable A — the 5-channel matrix, dispositions, recommendation-only posture, B2-AC-7); R2a root-cause (the channel substrate evidence); the B2 TD-prep §11 channel matrix + its Codex review ("channel matrix conceptual only; no channel selected as authority"); Điều 32 (DOT-100% / no manual SQL / no curl bypass); operating-rules (Assembly First).
3. Accepted baseline (carried, not re-derived)
The carried 5-channel classification (from the accepted channel decision packet, Deliverable A §15; dispositions unchanged):
| Channel | Carried disposition | Carried reason (substance) |
|---|---|---|
| host cron | candidate | lowest blast radius; the proven channel for the sibling scanner DOTs; matches the inspector's periodic-scan nature; best LEGO replaceability; opaque to in-DB observability (visible only via the DB-captured wf_host_crontab_snapshot); not transactional with the inspect_* writes |
agent-api executor (:8090) |
candidate | existing healthy runner (Up 13 days); contract-bound and most observable / Điều-32-promotable; gated by master switches OFF + a DRY_RUN→REAL_RUN promotion; shared infra with the KG lane (must not couple the lanes) |
| pg_cron | risky / future-gated | clean in-DB atomicity but a net-new extension install (not installed today) → higher infra blast radius |
| job_queue worker | risky / future-gated | decoupled, but the substrate is disabled/idle and the undrained-queue failure mode (event_outbox ~215k undrained) is already present |
| manual one-shot | reject as standing channel | not testable/replaceable/rollbackable as a block; violates Điều 32 §2.1 (no manual SQL / no curl bypass); is the 2026-03-21 fused-INSERT vehicle; the only legitimate residual one-shot is B5, a separate Owner-gated backlog pass |
Carried runtime substrate (INHERITED_EVIDENCE, R2a): master switches OFF (execute_enabled/real_run_enabled=false, dry_run_only=true; queue.worker.enabled=false; queue.job_substrate.enabled=false); pg_cron NOT installed; queue idle since 2026-05-26; no host-cron birth entry (the 0 6 slot is dot-nrm-lifecycle); the inspector DOTs DOT-TAC-BIRTH-VERIFY/-GATE are unwired stubs; the agent-api executor serves only the KG EXPLAIN DRY_RUN pilot today.
Carried Codex acceptance: "The channel matrix is conceptual only. … No channel is selected as authority." (B2 TD-prep + planning-bundle Codex reviews.)
4. Analysis — recommendation vs. selection
A recommendation ranks the candidates and explains the trade-offs for an Owner who will decide; a selection would name one channel as the channel B2 uses. The line between them is the channel-authority lock. This packet stays on the recommendation side by:
- ranking only the two
candidatechannels (host cron, agent-api executor) and explaining their trade-off (Deliverable 5 deepens this), while leaving the choice explicitly to the Owner; - not naming a channel as "the" channel, not writing any wiring/contract/install spec, and not implying any default that bypasses the Owner;
- keeping
pg_cron/job_queueas risky/future-gated andmanual one-shotas rejected, unchanged from the carried matrix; - restating B2-AC-7: whichever channel is later chosen stays inside B2; the contract does not change with the channel.
The recommendation is information for a decision, not the decision.
5. Channel recommendation (recommendation-only)
RECOMMENDATION_ONLY — NOT AUTHORITY — OWNER_GATE_REQUIRED — FUTURE_TECHNICAL_DESIGN_REQUIRED.
| Channel | Disposition (carried) | Authority status |
|---|---|---|
| host cron | candidate — lowest blast radius; proven for the sibling scanner DOTs; best LEGO replaceability | Not selected |
agent-api executor (:8090) |
candidate — existing healthy runner; most observable / Điều-32-promotable; gated by master switch + DRY_RUN→REAL_RUN promotion |
Not selected |
| pg_cron | risky / future-gated — net-new extension install (not installed today) | Not selected |
| job_queue worker | risky / future-gated — idle/undrained substrate; undrained-queue failure mode already present | Not selected |
| manual one-shot | reject as standing channel — Điều 32 §2.1 violation; fused-INSERT vehicle; only legitimate residual one-shot is B5 (separate) | Rejected as standing channel |
The recommendation, stated as a preference for an Owner decision (not a selection):
- If the Owner later opens B2's technical design, the two viable standing candidates are host cron and the agent-api executor. These are the two
candidatechannels;pg_cronandjob_queue workerare risky/future-gated;manual one-shotis rejected as a standing channel. - Expectation (recommendation-only): host cron may be the fastest / lowest-blast-radius option — a single crontab entry outside the block, the proven channel for the sibling scanner DOTs, matching the inspector's periodic-scan nature, with the smallest swap cost.
- Expectation (recommendation-only): the agent-api executor may be the more governed / observable option — contract-bound (in-DB), Điều-32-promotable, with dispatch records — at the cost of being gated by the master switches and a
DRY_RUN→REAL_RUNpromotion, and of sharing infra with the KG lane (which must not couple the lanes). - No channel is selected, used, wired, installed, promoted, or built. The choice between the two candidates (and the trade-off between speed/blast-radius and governance/observability) is an Owner decision, deepened in Deliverable 5 and gated by the proof-obligations in Deliverable 6. Whichever is chosen stays inside B2 (B2-AC-7).
Forbidden wording check (self-applied). This packet uses none of: "Selected channel:", "Use this channel:", "Implement this channel:", "Wire this channel:", "Promote this channel:". It uses only the recommendation-only formula above. Any drift to a selection is CHANNEL_AUTHORITY_DRIFT → HOLD.
6. Owner-gated future work
Every action below is forbidden now (OWNER_GATE_REQUIRED). Listing is scoping, not authorization.
| Future work | Gate required | Forbidden now? |
|---|---|---|
| Select the B2 invocation channel (Owner's act, informed by this recommendation) | Owner decision | Yes |
| Wire host cron for the inspector | Điều 32 + S2 owner | Yes |
Bind/promote the agent-api contract (DRY_RUN→REAL_RUN) |
Điều 32 + S2 + contract promotion | Yes |
| Install pg_cron (extension) | Điều 32 + infra/extension approval | Yes |
| Enable the job_queue worker / master switch | Điều 32 + master-switch flip | Yes |
| Prove the chosen channel's liveness | the Deliverable 6 proof-obligations (read-only where possible) | Yes (not done here) |
7. What remains unresolved
- CHANNEL not selected (by design). This packet recommends; the Owner decides.
CHANNEL_AUTHORITY_DRIFTguarded. - Substrate currently fail-closed. Switches OFF, queue idle, no birth cron, pg_cron absent — every standing channel that uses the runner/queue substrate is disabled and would require an Owner-gated enable.
- CAV-3 / CAV-4 / CAV-5 carried. Channel liveness is provable only via DB-captured snapshots (no
crontab -l/systemctl/docker exectool;/opt/incomex/dot/bin+ env unreadable); the transient GUC layer is unreadable. No overclaim is made about any channel's live state. - Overreach risk noted. The single overreach risk in a recommendation like this is letting "the two candidates are host cron and agent-api" harden into "use host cron." This packet guards it by stating both as candidates, recommending the trade-off be decided by the Owner, and writing no wiring/spec — but Codex must verify (Deliverable 19 / §8).
- 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): any scheduler/runner/cron implementation, contract shape, dispatch payload, extension-install plan, worker-enable plan, or command sequence.
8. Ready for GPT/Codex review
Yes — as a design-only channel recommendation, not a selection.
Codex must check (anti-overreach):
- Is the recommendation stated as
RECOMMENDATION_ONLY — NOT AUTHORITYthroughout, with no channel marked "selected"/"use"/"wire"/"promote"? - Are both host cron and agent-api kept as candidates (no premature collapse to one)?
- Are
pg_cron/job_queuekept risky/future-gated andmanual one-shotrejected, unchanged? - Is B2-AC-7 (channel = replaceable internal) restated, with no channel leaking into the contract?
- Is any scheduler/runner/cron/contract/install spec present? (Must be none.)
- Does the recommendation overreach by implying a default that bypasses the Owner? (Must be no.)
Core rule, kept above all detail: the two candidate channels (host cron, agent-api executor) are recommended for an Owner decision; the speed/blast-radius vs. governance/observability trade-off is the Owner's to resolve; no channel is selected as authority, and whichever is chosen stays inside B2.
Default disposition: HOLD. Engineering PASS = a complete, fair recommendation on paper; it is not an Owner authorization to select, wire, install, promote, or build a channel. No PASS authorizes writes. All blockers remain OPEN.