11 — Next Macro Decision (Workstream J)

PRIMARY: (1) AGENT_API_ENDPOINT_SERVICE_DEPLOY_AND_TRUE_DRYRUN

Decision rule applied: "if endpoint implemented/staged, choose true dry-run." The endpoint service is now authored, staged, and wiring-self-tested; the credential and egress exist. The single highest-leverage next move is to deploy it and run the first true DRY_RUN.

First actions of that macro (in order):

1. Owner authorizes reuse of the existing OpenAI credential for the new no-mutation executor.
2. Operator builds + deploys the staged container (internal-only) and runs the live selfcheck + a non-mock dispatch dry-run.
3. Operator binds endpoint_ref (sql/bind_endpoint.sql) and runs the DB true dry-run for one KG pair. After this, dot:kg moves plan_only_tested → dry_run_observed, the first non-zero DRY_RUN appears, and the dot:kg verified path (correlation → real run → owner → split) opens.

PARALLEL (no owner needed)

• (2) PROCESS_DISCOVERY_V7_UI_DEPLOY — fully ready; operator-only; surfaces endpoint/dry-run/ job:cut/dot:kg/policy/closeout status.
• (3) JOBCUT_AND_DOTKG_REGISTRATION_OWNER_DRAIN_WITH_PARALLEL_D1D2 — file the job:cut owner + registration (action='review'), continue D1/D2 content.

Not chosen, and why

• (4) INFORMATION_PIECE_CONTENT_WORK_RESUME — correct eventual destination (roadmap step 9) but premature while the first DRY_RUN is one deploy away.
• (5) AUTO_WORKFLOW_DISCOVERY_POLICY_SCHEDULER — policy is already operational over live views; only the scheduler integration remains, too narrow to be a primary.
• (6) ENDPOINT_BLOCKED_FALLBACK — rejected: the endpoint is no longer blocked by missing infra (credential + egress + hosting all present); it is deploy/authorization-gated. A "blocked fallback" macro would understate the live state.

Anti-tiny-loop guard

The primary is a deploy-and-execute macro, not an approval-only or rediscovery loop.