KB-1868

01 — Current authorize_build_step + handler architecture (VPS SSOT) 2026-06-23

5 min read Revision 1
c1-legoauthorize-build-stephandler-architecturedot-apr-execute

01 — Current authorize_build_step + handler architecture (VPS SSOT, 2026-06-23)

A. Handler architecture — RECONSTRUCTED FROM ACTUAL CODE/FUNCTIONS

A.1 The dispatcher is dot-apr-execute (DB-driven case)

VPS SSOT /opt/incomex/dot/bin/dot-apr-execute v2.2.0 (host vmi3080463, branch feat/s177-sprint1-round-a, read via SSH). It selects approved, not-yet-applied approval_requests, looks up apr_action_types.handler_ref by proposed_action_code, and routes through dispatch_handler():

case "$HANDLER_REF" in
  "unimplemented")               echo "SKIP:handler=unimplemented"; return 0 ;;
  "dot-apr-execute:create")      execute_create_item  ... ;;
  "dot-apr-execute:update")      execute_update_item  ... ;;
  "dot-apr-execute:add_field")   execute_add_field    ... ;;
  "dot-apr-execute:patch_ops")   execute_patch_ops_code "$APR" ;;
  *)                             echo "SKIP:handler_unknown:${HANDLER_REF}" ;;   # fail-closed default
esac

On handler OK it PATCHes the APR to status='applied'. Handlers are bash functions named execute_<verb>; handler_ref is the routing key dot-apr-execute:<verb>. There is NO separate handler registry table — the dispatch surface is this case.

A.2 The four implemented handlers and their write channels

action_code handler_ref write channel _dot_origin
create_item dot-apr-execute:create Directus POST /items/{coll} MIGRATION
update_item dot-apr-execute:update Directus PATCH /items/{coll}/{id} MIGRATION
add_field dot-apr-execute:add_field Directus POST /fields/{coll} MIGRATION
patch_ops_code dot-apr-execute:patch_ops run_pg + filesystem (execute_patch_ops_code) MIGRATION

execute_patch_ops_code is the precedent that matters: it writes a raw PG table (vps_deploy_log) via run_pg "INSERT …" (docker exec postgres psql), NOT via Directus. The C1 grant handler follows this exact pattern, because the grant table is also a raw PG table.

A.3 Self-patch path exists

execute_patch_ops_code patches files matching ^/opt/incomex/dot/bin/dot- (flock → backup .bak-{session} → apply → bash -n syntax gate → atomic mv → vps_deploy_log). So dot-apr-execute can be patched through a governed patch_ops_code APR — the DOT-approved code-deploy path for the new handler function (see file 04).

B. DB-enforced gates (fail-closed) — pg_get_functiondef

  • trg_apr_block_unimplemented = BEFORE UPDATE ON approval_requests WHEN (new.status='applied' AND old.status<>'applied')fn_apr_block_unimplemented_handler():
    1. IF NOT quorum_passed(NEW.code) THEN RAISE (apply-time quorum re-proof, fail-closed);
    2. IF handler_ref='unimplemented' THEN RAISE 'Action % … Reserve-only, cannot execute.'
  • quorum_passed(code) (STABLE): proposer self-excluded (INV-1); any reject ⇒ false (INV-3); highpresident≥1 (human, approver ILIKE '%president%') AND ai_council≥2; medium ⇒ president≥1; low ⇒ total≥1.
  • fn_process_axis_execute_guarded_action(action,kind,subj,actor,actor_type) is the axis-UI path (Gate A president-only-human, Gate B implemented-handler, Gate C human-president vote; EXECUTED-NOOP, writes no canon). It first does SELECT … FROM process_axis_action_vocabulary WHERE action_code=…; authorize_build_step is absent from that vocabulary (0 rows) ⇒ this path returns unknown action_code. The W7 grant path does NOT use this function — it uses dot-apr-execute (§A), which consults apr_action_types only. ⇒ no need to touch process_axis_action_vocabulary; smaller blast radius.

C. authorize_build_step live row (apr_action_types)

action_code = authorize_build_step
handler_ref = unimplemented        <-- the blocker
risk_level  = high
status      = active
_dot_origin = PG:sb1-gov-vocab     (reserve-only by design)

Existing approval_requests with proposed_action_code='authorize_build_step': 0.

D. What must change to unblock W7 (exactly two things)

  1. Implement the domain handler execute_authorize_build_step (net-new bash function) — file 03/04.
  2. Bind apr_action_types.authorize_build_step.handler_ref unimplemented → dot-apr-execute:authorize_build_step — file 05. Both are STAGED here; neither is applied. The handler architecture is found and provenC1_AUTH_HANDLER_HOLD_HANDLER_ARCHITECTURE_UNCLEAR does not fire.
Back to Knowledge Hub knowledge/dev/laws-new/reports/c1-authorize-build-step-handler-minimal-lego-patch/01-current-authorize-build-step-and-handler-state-2026-06-23.md