04 — Phase D: Approval packet (for REAL human president + REAL ai_council)

This packet describes WHAT must be approved and HOW. It records no approvals. Approvals must be cast by each real approver's own identity/channel. Fabrication is forbidden.

What is being asked

Approve APR-0415 so a future governed execution may deploy execute_authorize_build_step into dot-apr-execute (v2.2.0 → v2.3.0), unblocking C1 step W7.

field	value
APR code	APR-0415 (id 415), status pending
action_code	patch_ops_code
risk	high
purpose	Deploy the execute_authorize_build_step handler for C1 W7 only
target	file /opt/incomex/dot/bin/dot-apr-execute, patch_mode=full_replace, DOT-310
payload hash	patched sha256 a5f79847…f94ef7fca; base64 md5 3aa36821…f3d987 (len 46672)
expected file changed	dot-apr-execute only
expected handler added	execute_authorize_build_step (1 dispatch arm + 1 function)

Scope boundary (what approval does NOT authorize)

Approving APR-0415 authorizes only the additive code deploy. It does NOT bind handler_ref (separate governed migration), NOT mint any grant, NOT register dot-c1-grant-issue, NOT run W1–W9 or any dry-run, NOT touch C2–C7 or production corpus.

Forbidden effects (guaranteed by payload + handler design)

• Additive only: bash -n PASS (VPS bash 5.2.21); existing handlers untouched; *) fail-closed default intact.
• The deployed handler is scope-locked: refuses any action ≠ authorize_build_step, any scope ≠ C1 dry-run (DRYRUN-NS / dot:c1:vocab / DOT_C1_VOCAB_BUILD), any commit_allowed=true, any sovereign tier; commit_allowed/requires_sovereign_esign written literal false.

Rollback path

patch_ops_code execution does flock → .bak-<session> backup → bash -n gate → atomic mv → vps_deploy_log. Reverse = restore the .bak (file 08 of the minimal-lego-patch package). The patch is additive, so reverting only removes the new arm+function.

Required approvals (LIVE rule, from quorum_passed(text); risk=high)

• ≥ 1 human president — apr_approvals row: approver_type='human', approver ILIKE '%president%', decision='approve'.
• ≥ 2 ai_council — apr_approvals rows: approver_type='ai_council', decision='approve'.
• 0 rejects (any decision='reject' → quorum fails).
• Proposer excluded (no self-approve, INV-1).

Current approvals

seat	required	present
human president (approve)	≥1	0
ai_council (approve)	≥2	0
rejects	0	0
quorum_passed('APR-0415')	true	false

Missing approvals (exact)

• 1 human president approve
• 2 ai_council approve (Total 3 approvals, 0 rejects, by 3 distinct real identities — none of them the proposer.)

Exact approval mechanism (if available)

There is no agent-runnable approval CLI (no dot-apr-approve; dot-content-approve is unrelated content tooling). An approval is a row in apr_approvals: (apr_id=415, approver=<real identity>, approver_type∈{'human','ai_council'}, decision='approve', rationale=<...>), recorded by each real approver through their own authenticated identity/channel (e.g. the president and each ai_council seat under their own credentials). The proposing agent holds no president/council seat and will not record any vote.

NOTE (self-exclusion detail): APR-0415's source_context carries no proposer/created_by key, so quorum_passed evaluates v_proposer = NULL → it excludes no one. This is benign here because the proposer is the agent (source dot-c1-w7-authorize-build-step-handler-proposal), which holds no approver seat. Recommendation: the 3 approvers must each be a distinct real council/president identity (which they inherently are).

NOTE (carried context, not re-verified this turn): auto-council auto-approve was disabled 2026-06-06 (fn_auto_approve_add, P0 authority-bypass containment). There is therefore no automated path to quorum; the 3 approvals must be cast by real approvers.