KB-4BE0

Phase 3B — Next Main-Workflow Return Plan

7 min read Revision 1
dieu45phase-3bnext-packcarry-forwardsilent-gapreturn-plan2026-05-26

Phase 3B — Next Main-Workflow Return Plan

State at end of Phase 3B

  • Queue substrate (Phase 1) + governance heartbeat + lease/DLQ governance (Phase 2) + MARK/CUT-via-queue pilot for Điều 37 (Phase 3) + vocab gap closed + heartbeat ping wrapper added + queue D30/D31 pinned (Phase 3B).
  • All risk-bearing gates safe (queue.job_substrate.enabled=false, queue.worker.enabled=false, queue.notify.enabled=false, queue.dlq.replay_enabled=false, queue.lease.reaper_enabled=false, iu_core.composer_enabled=false). Only queue.heartbeat.enabled=true (Phase 2).
  • pg_cron NOT installed; LISTEN/NOTIFY only for kb_vector_sync.
  • §15.5 silent-gap surface visible AND protected against false-heal, but NOT yet operationally closed.

Carry-forward (in priority order)

CF-1 (HIGH) — Wire a real heartbeat caller for the route worker

The §15.5 silent gap remains operationally open. iu_outbound_default is the passive marker; it must stay frozen at 2026-05-22 11:31:41. To close the gap durably, a future pack should:

  1. Modify fn_iu_route_worker_run (or its operator wrapper) to call fn_queue_heartbeat_ping_external for a new executor_name (e.g. iu_outbound_default_active_v2) at every tick.
  2. Update fn_queue_stale_check() or v_queue_health to recognise the v2 executor as the "live" surface and the legacy iu_outbound_default as "historical-warn" (not double-counted in stale alerts).
  3. Run a one-shot operator ping in a smoke test to seed the v2 row, then enable the caller in the worker fn.

Recommended pack name: DIEU45_PHASE_3C_HEARTBEAT_CALLER_WIRING_ROUTE_WORKER_DRY_RUN_FIRST.

CF-2 (MEDIUM) — Decide on section orphan in dot_config

section is in dot_config vocab.section_type.* but NOT in tac_section_type_vocab. Phase 3 pilot used it as a remap target (reference_mapping → section, open_decision_list → section). With Phase 3B's widened vocab, those remaps are no longer necessary — future cuts can keep the original section_type.

Options for a future pack:

  • (A) Deprecate section in dot_config + add explicit deprecation reason; future fn_iu_create calls warn but accept.
  • (B) Remove section from dot_config after auditing all existing IUs with identity_profile.primary_section_type_ref='section' (count: 2 in Phase 3 pilot — #debt and #law-links) and either re-tagging them or leaving them historical.
  • (C) Add section to tac_section_type_vocab as a separate active code — would make the vocab fully convergent but adds a new governed value with no clear semantic distinction from paragraph/heading.

Recommend (A) deprecate-without-remove as the safest reversible step.

CF-3 (MEDIUM) — Refactor fn_iu_resolve_default to read from governed tables for selected vocabs

Phase 3B's data-side sync (add 5 dot_config rows) is durable but does not prevent future drift between tac_section_type_vocab and dot_config vocab.section_type.*. A more durable refactor would:

  • Modify fn_iu_resolve_default to accept an optional governed-table reference, OR
  • Add a per-namespace dispatcher (fn_iu_resolve_section_type, fn_iu_resolve_unit_kind, …) that reads from the governed table directly,
  • Keep the dot_config path as fallback for vocabs without a governed table.

fn_iu_section_type_vocab_sync_check() is the interim protection (callable manually or wired into pre-commit gates).

CF-4 (LOW) — Widen Phase 3B for non-Điều-37 sources

The queue-driven MARK/CUT path is proven for one law document. The next governed source — likely knowledge/dev/laws/dieu45-pg-native-queue-and-task-orchestration-law.md itself, or one of the DIEU-30/31/35 laws — should be cut via the queue path with Phase 3B vocab + heartbeat protection.

CF-5 (LOW) — fn_iu_create P-pub1/P-pub2 birth-gate warnings

Phase 3B observed 36+2 = 38 P-pub1/P-pub2 birth-gate warnings during the synthetic vocab probe (and the original 60 during Phase 3 pilot). These are §0-G non-blocking pilot warnings, but they pollute log streams. A future pack could:

  • Disable the warning at pilot stage via a dot_config flag, OR
  • Promote the gate to BLOCK in production with explicit P-pub1/P-pub2 setup before any law is cut.

CF-6 (LOW) — dieu45_phase3_pilot heartbeat row aging

dieu45_phase3_pilot executor in queue_heartbeat is from the Phase 3 pilot (last tick 2026-05-26 15:17:39). It is being flagged stale by fn_queue_stale_check whenever age > 300s (already 1655s during this Phase 3B run). Not a Phase 3B concern (Phase 3 pilot was terminal), but a future pack should either:

  • Move the pilot heartbeat to a separate queue_heartbeat_archive table, OR
  • Add a terminal=true flag on queue_heartbeat so the stale check skips known-finished pilots.

What Phase 3B did NOT do (intentional)

  • Did not install pg_cron.
  • Did not start any broad worker / daemon.
  • Did not modify fn_iu_create body (md5 unchanged).
  • Did not modify any MARK/CUT alias body (md5s pinned in [[04-queue-d30-regression-pack]]).
  • Did not modify tac_section_type_vocab.
  • Did not mutate event_outbox schema or rows.
  • Did not touch event_type_registry.
  • Did not touch Qdrant.
  • Did not touch production_documents (still absent).
  • Did not amend Điều 45.
  • Did not update queue.runtime.phase (still phase2_governance). A future pack that wires a real heartbeat caller should flip this to phase3_runtime or similar.

Suggested next pack

DIEU45_PHASE_3C_HEARTBEAT_CALLER_WIRING_ROUTE_WORKER_DRY_RUN_FIRST

Mission: implement CF-1 above, with the same dry-run-first / BEGIN-ROLLBACK-first / signal-only-payload discipline as Phase 1/2/3/3B. Open question: do we ship the wiring as a function-body modification of fn_iu_route_worker_run (Option B in this report) or as an external operator that ticks heartbeat then invokes the worker fn (closer to the HC pattern, [[feedback-hc-executor-last-run-is-proven-heartbeat-pattern]])?

Recommend Option B-external (operator wrapper) as lower-risk: no modification to existing worker fn, easier rollback, matches the proven HC pattern.

Return to main workflow

This Phase 3B run is terminal for the queue-cutter-hardening track. Next call to operator / Codex / Agent on this codebase should:

  1. Read this report folder (knowledge/dev/laws/dieu44-trien-khai/v0.6-dieu45-phase-3b-queue-cutter-hardening/) for context.
  2. Decide whether to proceed with CF-1 (next-pack candidate) or to surface other carry-forwards higher-priority first.
  3. Honor the gate-safe-at-exit contract (all 6 risk-bearing gates at false) — any pack flipping a gate must restore at exit unless the pack's mandate is durable activation.
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/v0.6-dieu45-phase-3b-queue-cutter-hardening/08-next-main-workflow-return-plan.md