# Direct Artifact Completion Stop Gate - Optimization ID: `direct-artifact-stop-gate-2026-07-27` - Owner: auto-oncall-services - Source reference: `APID-29214` historical replay review - Implementation status: deployed to staging - Effective status: `optimized_verified` ## Bounded problem Scenario classification runs before Jira attachments are materialized. A ticket can therefore retain `missingKeys=["execution_plan"]`, `evidenceRequired=true`, and an OP provider route even after the workspace contains a complete `EXPLAIN ANALYZE` or performance trace that answers the customer's direct slow-point question. In `APID-29214`, the supplied plan already showed that most of the roughly 486 ms execution was under `IndexLookUp` and `wait_table_lookup_build` (roughly 456 ms), rather than HashJoin or TiKV processing. The latest branch replay still entered provider exploration, executed repeated readiness/metrics/Slow Query operations, initially queried a misaligned time window, and did not separately assess the human-raised outer predicate candidate. ## Candidate change The runtime now performs a post-materialization objective reconciliation: - a complete plan or trace becomes a canonical `execution_plan` or `performance_trace` lookup key; - the current resolution becomes `direct_answer` with no missing keys, while an existing `human_required` safety boundary remains `human_required`; - a `direct-artifact-gate-v1` document makes provider access prohibited; - the direct Codex turn receives bounded inline ticket, plan/trace, manifest, replay, and reply-contract context; - the turn is read-only with network and web disabled, and its trace is rejected if it contains a command, MCP/provider call, web search, or file change; - query-tuning guidance distinguishes the observed sample bottleneck from an independent structural optimization candidate; - predicate pushdown and join/subquery rewrites must preserve result-set, NULL, duplicate, filter, join-condition, and placeholder semantics and remain candidates until representative before/after plan evidence passes. The gate does not suppress a later explicit human continuation with a new objective. Provider access remains available only when the runtime explicitly sets `providerPolicy=agent_read_only` for a load-bearing current-state gap. ## Current evidence - Old baseline run `a3306cf2-86b4-4f0c-8fce-1721733559b9` was partial: it answered the question but performed unnecessary exploration and lost diagnostic precision. - Branch replay `252ff0db-67a4-4011-b826-1658d7dc9a82` returned HTTP 200 after about 619 seconds and produced a technically useful direct bottleneck answer, but its classifier still claimed `execution_plan` was missing. - That run executed 42 commands, including repeated Wetech readiness, metrics, and Slow Query paths, even though its own reasoning said the materialized plan identified the direct slow point. - Post-change historical-cutoff replay `7770668d-e341-4a4e-b1a2-9251f6ac16e0` completed on 2026-07-27 at approximately 16:13 +08:00 with HTTP 200 in 131.24 seconds. It used the target human comment cutoff, included only comments 0, 1, and 2, and kept the target reply and later comments hidden. - The post-materialization gate recorded `status=passed`, `artifactTypes=["execution_plan"]`, and `providerPolicy=prohibited`. Classification contained canonical `execution_plan`, no missing keys, no required provider evidence, and `evidenceProvider=none`. - The high-reasoning analysis completed in 68.24 seconds. Its trace contained one agent message and zero command, MCP/provider, web-search, or file-change items. No Wetech, list-clusters, readiness, metrics, TopSQL, Statements, Slow Query, log, or provider evidence artifact was created. - The accepted result attributed the roughly 485.8 ms sample to the `IndexLookUp`/Cop fetch path, including `wait_table_lookup_build=456.1 ms`, while rejecting HashJoin computation and TiKV processing as the immediate bottleneck. It separately retained the outer full scan and outer-predicate/index rewrite as structural candidates, required semantic equivalence, and required a representative new `EXPLAIN ANALYZE` or Plan Replayer before treating a rewrite as an improvement. - The automatic comparison verdict was `ai_better`. It noted one non-blocking gap: the AI did not give the same concrete grouping-key predicate-pushdown example as the human reference. The branch replay still passed this optimization's bounded criterion because it identified the direct bottleneck, prohibited provider exploration, and evaluated the outer rewrite as a semantics-sensitive candidate rather than claiming it was already a fix. - Full repository tests passed 455/455, TypeScript typecheck passed, both changed skills passed `quick_validate`, and `git diff --check` passed. - The staging runtime started the deployed image at `2026-07-27T09:52:53.000Z`. Deployed read replay `9ac725f6-2a96-427e-877e-60b9edc62ec3` completed in 101.45 seconds with `ai_better`, selected `direct_answer`, used no provider, and attributed the 485.8 ms sample to `wait_table_lookup_build=456.1 ms` while keeping the structural rewrite as a separate semantics-sensitive candidate. - Deployed write replay `a00af2cd-98bc-40c3-b559-3c1626ff3cd6` updated the existing Jira internal comment `23256958` in place. Jira readback verified the exact comment ID and updated body. ## Unresolved gaps - Image-only plan completeness still depends on the model reading the supplied local image; the gate proves materialization and routing, not OCR accuracy. - A structural rewrite visible in one sample may be irrelevant or unsafe. It remains a verification candidate, not a claimed fix. ## Next validation action Treat the image-only OCR boundary as a separate future problem if it reproduces. For this bounded problem, monitor later matching signals as regressions rather than suppressing unrelated gaps on `APID-29214`.