KB-7081

Mega Gate — Host Cron vs Agent-API Decision Brief (recommendation-only)

12 min read Revision 1

Mega Gate — Host Cron vs Agent-API Executor Decision Brief

Date: 2026-06-18 · Workstream: LEGO-PILOT-SLICE-0-B2-MEGA-GATE-BUNDLE-2026-06-18 (Deliverable 5 of 20) · Editorial revision: rev1 Class: design-only / two-candidate comparison / 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_length are authoritative in AgentData metadata at read time; not pinned in this body.

Two-candidate lock. This brief compares the two candidate channels (host cron vs agent-api executor) head-to-head for an Owner decision. It is RECOMMENDATION_ONLY — NOT AUTHORITY — OWNER_GATE_REQUIRED — FUTURE_TECHNICAL_DESIGN_REQUIRED. It selects neither, wires neither, writes no scheduler/contract spec, and lets neither channel leak into B2's contract (B2-AC-7). Naming a winner as "the channel" is CHANNEL_AUTHORITY_DRIFT → HOLD.


0. Status and non-authorization

STATUS: PASS — engineering / design-only. This is a complete design-only head-to-head brief for the two candidate channels: a dimension-by-dimension comparison (blast radius, observability, governance fit, atomicity, replaceability, current readiness, rollback), the trade-off framing for an Owner decision, and the explicit non-selection statement.

Engineering PASS ≠ authority PASS. A PASS means the comparison is complete and fair on paper. It is not an Owner authorization to select, wire, promote, or build either channel. Default disposition: HOLD.

Pipeline position (downstream-only). Deliverable 5 of the Mega Gate Bundle; it deepens Deliverable 4's two-candidate recommendation into a head-to-head brief for an eventual Owner decision. It selects nothing.

Non-authorization (explicit). As Deliverable 4 §0 (no channel selected/wired; no pg_cron install; no contract promotion; no worker enable; no scheduler/contract spec). v0.1/FIX7 V3 not overwritten; v0.2 not authority.

Evidence basis — INHERITED_EVIDENCE. No runtime queried. Both channels' facts inherited from R2a + the channel decision packet. AgentData metadata authoritative at read time. CAV-3/CAV-4/CAV-5 bound liveness claims.

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

Give the Owner a focused head-to-head between the only two viable standing candidates, so the eventual channel decision is informed. The packet answers:

  1. How do host cron and agent-api compare per dimension? — §5 table.
  2. What is each one's strongest case? — §5 narrative.
  3. What is the trade-off the Owner must resolve? — §5 trade-off.
  4. Why is neither selected here? — §0 lock + §5.

The one rule, above all detail. Both are candidates; the comparison informs an Owner decision; B2's contract is channel-independent; neither is selected, and the chosen one stays inside B2.


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 channel decision packet §6 (host cron analysis) + §7 (agent-api analysis) + §11–§13 (replaceability/observability/rollback); R2a §3–§9 (substrate); the B2 TD-prep §11; Điều 32 §2.1; Điều 35 note (agent-api EXPLAIN pilot pattern); operating-rules (Assembly First).


3. Accepted baseline (carried, not re-derived)

  • host cron (carried): a host-crontab entry that periodically invokes the inspector pass — the same channel the sibling scanner DOTs already use (dot-orphan-scanner, dot-misclass-scanner, dot-nrm-*, dot-hc-executor). Lives outside the block; swappable; not transactional with the inspect_* writes; opaque to in-DB observability (visible only via the DB-captured wf_host_crontab_snapshot; no live crontab -l — CAV-3/CAV-4). The 0 6 slot is taken by dot-nrm-lifecycle, so a birth inspector would need its own slot.
  • agent-api executor :8090 (carried): dispatch the inspector via a dot_agent_api_contract binding to incomex-agent-api-executor (the KG EXPLAIN pilot's mechanism). The executor exists, healthy, Up 13 days, but is not bound to any birth DOT. Contract-bound and observable (in-DB); but shared infra (also serves the KG lane) and currently fail-closed (master switches OFF; a DRY_RUN→REAL_RUN promotion is itself Owner-gated — CAV-5 on the GUC layer).
  • Both are candidate; both keep the channel a replaceable internal (B2-AC-7). pg_cron/job_queue are risky/future-gated; manual one-shot is rejected.

4. Analysis — the axes that distinguish them

The two candidates are alike in the way that matters most (both keep the channel an external, swappable internal that does not change B2's contract) and differ on a small number of axes that the Owner must weigh: blast radius / speed to stand up, observability, governance fit (Điều 32 / Điều 35), atomicity with the writes, current readiness, and rollback cost. The comparison below is exactly those axes; it does not rank them into a single winner because the weighting (e.g. "prefer lowest blast radius" vs "prefer most governed") is an Owner value judgment.


5. Head-to-head comparison

Dimension host cron agent-api executor (:8090)
Blast radius / speed to stand up Lowest — one crontab line outside the block; the proven sibling-scanner channel; matches the inspector's periodic-scan nature Low — one dot_agent_api_contract row on an existing healthy runner; the executor is untouched
Observability Medium / indirect — provable only via the DB-captured wf_host_crontab_snapshot + per-run S7 evidence; no live crontab -l (CAV-3/CAV-4) Strong — in-DB contract + dispatch records + master-switch state + S7 evidence; the most observable channel
Governance fit (Điều 32 / Điều 35) Good — the cron wiring is part of the producer's governed build (never a manual crontab -e); aligns with "DOT is the gate" if the cron only invokes a governed producer Strong — contract-bound dispatch is the most Điều-32-promotable; aligns with "DOT is the gate" and §2.1 "no manual SQL / no curl bypass"
Atomicity with inspect_* writes No — not transactional; the producer must own its own per-stage atomicity and idempotency No — dispatch is out-of-band; same producer-owns-atomicity requirement
Shared-infra coupling None — a cron entry is birth-lane-local Some — shared with the KG lane; a birth binding must be per-DOT so it does not couple the lanes (AC-7 holds because contracts are per-DOT)
Current readiness Not wired — no birth cron entry; the substrate has host cron working for siblings, so adding an entry is the smallest net-new step Gated — executor healthy but master switches OFF and DRY_RUN→REAL_RUN promotion needed; the EXPLAIN pilot proves the dispatch pattern works
Rollback unit Remove the single cron entry; one producer run (S8) Unbind / disable the contract (→ DRY_RUN); one producer run (S8)
LEGO replaceability Best — smallest external artifact, lowest swap cost Strong — one contract row, unbindable; most observable

Each candidate's strongest case (recommendation-only).

  • host cron's case: lowest blast radius and fastest to stand up (Assembly First — reuse the channel the sibling scanners already use), best replaceability, no shared-infra coupling. Its cost is indirect observability (snapshot-only) and no in-DB transactionality.
  • agent-api's case: the most governed and observable channel (in-DB contract + dispatch records, Điều-32-promotable), reusing a proven, healthy runner and the EXPLAIN dispatch pattern. Its cost is the master-switch + DRY_RUN→REAL_RUN gating and the shared-infra coupling that must be kept per-DOT.

The trade-off the Owner must resolve (recommendation-only). The decision reduces to a single value judgment: lowest blast radius / fastest stand-up (host cron) vs. strongest governance / observability (agent-api). Both keep the channel a replaceable internal; both have a clean one-producer-run rollback; both require the producer to own its own atomicity. There is no dominant choice — the weighting is the Owner's. This brief recommends the trade-off be decided by the Owner; it selects neither.

Non-selection statement. Neither host cron nor agent-api is selected, used, wired, promoted, or built here. The brief is RECOMMENDATION_ONLY — NOT AUTHORITY — OWNER_GATE_REQUIRED — FUTURE_TECHNICAL_DESIGN_REQUIRED. The chosen channel stays inside B2 (B2-AC-7).


6. Owner-gated future work

Future work Gate required Forbidden now?
Decide host cron vs agent-api (the Owner's value judgment) Owner decision Yes
Wire host cron / bind+promote the agent-api contract Điều 32 (+ S2 owner; + DRY_RUN→REAL_RUN for agent-api) Yes
Prove the chosen channel's liveness Deliverable 6 proof-obligations Yes (not done here)
Confirm master-switch / transient GUC state (agent-api) Owner out-of-band (CAV-5) — read-only Yes (not done here)

7. What remains unresolved

  • Neither candidate selected (by design). The host-cron-vs-agent-api value judgment is the Owner's; this brief informs it. CHANNEL_AUTHORITY_DRIFT guarded.
  • Liveness unproven for both — substrate fail-closed (no birth cron; switches OFF). The proof-obligations are Deliverable 6.
  • CAV-3/CAV-4/CAV-5 carried — host-cron liveness is snapshot-only; the agent-api master-switch/transient-GUC layer is partly out-of-band.
  • Atomicity is a producer requirement, not a channel feature — neither channel is transactional with the inspect_* writes; the producer must own per-stage atomicity/idempotency regardless of channel.
  • 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 cron slot/command, the contract shape/dispatch payload, the master-switch sequence, any idempotency guard, any command sequence.

8. Ready for GPT/Codex review

Yes — as a design-only two-candidate brief, not a selection.

Core rule, kept above all detail: host cron (lowest blast radius / fastest / best replaceability) vs agent-api (strongest governance / observability), with the weighting an Owner value judgment; both keep the channel a replaceable internal; neither is selected, and the chosen one stays inside B2.

Default disposition: HOLD. Engineering PASS = a complete, fair head-to-head on paper; it is not an Owner authorization to select, wire, promote, or build either channel. No PASS authorizes writes. All blockers remain OPEN.

Back to Knowledge Hub knowledge/dev/laws-new/newlaws/consolidation/mega-gate-host-cron-vs-agent-api-decision-brief-2026-06-18.md