04 — VPS code SSOT patch plan

A. SSOT target (not local-only)

• CODE SSOT = VPS /opt/incomex (host vmi3080463, branch feat/s177-sprint1-round-a, no git remote). Confirmed via SSH this turn.
• File to patch: /opt/incomex/dot/bin/dot-apr-execute (v2.2.0). Read from the SSOT this turn; local web-test copy is v1.0.0 (staging only, NOT SSOT) — the patch is authored against the VPS content, not the local copy.
• The staged patch records the VPS function/dispatch shape it extends (file 01 §A.1/§A.2).

B. Exact change set (additive, 2 hunks)

1. dispatch_handler(): insert one case arm "dot-apr-execute:authorize_build_step") → execute_authorize_build_step "$APR", immediately before the *) default.
2. New function execute_authorize_build_step() placed beside execute_patch_ops_code. Both are in staged-artifacts/patches/dot-apr-execute-authorize_build_step.handler.additive-design.md.

The version/changelog header should bump (e.g. v2.3.0, "implement authorize_build_step C1 dry-run grant handler"). No other line changes.

C. Deploy mechanism (DOT-approved, no manual edit)

The patch is applied via the governed patch_ops_code path that already exists (handler dot-apr-execute:patch_ops, implemented v2.1.0). Flow:

1. Propose a patch_ops_code APR (request_type=fix_repair_dot, action_code=patch_ops_code) with proposed_action = {dot_code:"DOT-310", file_path:"/opt/incomex/dot/bin/dot-apr-execute", patch_mode:"full_replace", new_content_base64:<patched file>, session_code:<unique>, test_plan:<see file 09>}.
2. Approve to high-risk quorum (patch_ops_code is risk=high ⇒ 1 human president + 2 ai_council).
3. dot-apr-execute applies it: execute_patch_ops_code does flock → backup .bak-<session> → base64 decode → bash -n syntax gate → atomic mv → vps_deploy_log. Self-patch is explicitly supported (changelog notes the "handler patches itself" self-paradox + admin_fallback).
   • Self-edit caveat (disclosed): dot-apr-execute patches its own file. The atomic mv swaps the file after the running process has already sourced it, so the in-flight run is unaffected; the new handler is live on the NEXT invocation. The runbook (file 09) runs a no-op dot-apr-execute pass after deploy to load the new code before any grant APR.
   • Alternative: operator governed deploy (scp + restart) — same file, same content, also authority-approved. Either is acceptable; patch_ops_code is preferred (fully DOT-100%).

D. What must NOT change (invariants)

• The 4 existing handlers and their arms — untouched.
• The *) fail-closed default — untouched (still catches an unbound/typo handler_ref).
• The "unimplemented") SKIP arm — untouched (still the safe state pre-binding).
• quorum_passed, trg_apr_block_unimplemented, fn_process_axis_execute_guarded_action — no DB function change. process_axis_action_vocabulary — NOT touched (W7 path doesn't use it).
• governance_build_authorization schema — NO DDL (all needed columns already exist).
• The executor at /opt/incomex/deploy/agent-api-executor/ (W6) — out of scope here.
• C2..C7 — not referenced.

E. Why this is staged-against-SSOT, not local-only

The patch names the VPS file path, the VPS version, and uses the VPS-resident patch_ops_code handler as the deploy vehicle. The local web-test tree holds only the evidence package; it is not the apply target. ⇒ completion item "patch staged against VPS code SSOT path" satisfied.

No code is deployed this turn. 0 production writes.