Fix OpenCode prompt template shell expansion

.github/workflows/opencode-review.yml

@@ -1891,7 +1891,7 @@ jobs:
             printf 'review_status=%s\n' "$1" >>"$GITHUB_OUTPUT"
           }
           prompt_file="${RUNNER_TEMP}/opencode-review-prompt.md"
-          cat >"$prompt_file" <<EOF
+          cat >"$prompt_file" <<'EOF'
           Review PR #${PR_NUMBER} in ${OPENCODE_SOURCE_WORKDIR}. The trusted workflow checkout is ${GITHUB_WORKSPACE}; inspect the pull request head source only from ${OPENCODE_SOURCE_WORKDIR}. Be general-purpose and meticulous: actively consult CodeGraph MCP for structural checks, DeepWiki for repo docs, Context7 for current library/API docs, and web_search for bounded external lookups such as action/tool release facts, industry standards, international standards, official platform specifications, and comparable issue or PR precedents when applicable. Do not rely on model memory for user-claimed concepts, standards, runtime support, or domain terminology when a search source is available. If a configured MCP source is unavailable or not applicable, say so briefly in the review summary. Inspect changed files and focused hunks directly when MCP evidence is insufficient. Do not claim repository docs, images, or reference assets are unavailable, missing, or absent unless the changed docs repository tree evidence proves it. If an external MCP source is unavailable, state that as a source limitation, not as a repository fact.
           Structural exploration is mandatory for every PR, including dependency-only, lockfile-only, workflow-only, docs-only, and no-source-code changes; inspect the relevant manifest, lockfile, workflow, config, docs, dependency edges, generated side effects, code-to-documentation consistency, documentation-to-code consistency, and test-command contracts. Docs-only changes still require CodeGraph, DeepWiki, Context7, or web_search evidence when they make claims about behavior, APIs, setup, workflows, dependencies, standards, or product/domain concepts. If changed documentation contradicts current code, generated behavior, official docs, repository docs, or reachable standards evidence, request changes with a source-backed fix direction: either fix the documentation claim or update the code/contract that makes the claim false. Never state that structural exploration, structural analysis, or structural review is not required or unnecessary. If structural exploration was not possible or changed files could not be inspected after reading bounded-review-evidence.md and the changed files, do not approve. If evidence is truncated, inspect focused hunks and changed files directly before deciding. Do not request changes solely because the prompt did not inline the full evidence.
           Use CodeGraph for blast-radius, call graph, and test-coverage questions before broad local reads. Prefer deletion, stdlib/native platform features, and already-installed dependencies before proposing new code or packages, but do not simplify away trust-boundary validation, data-loss handling, security, accessibility, or required tests. Follow the Review language evidence section: write human-readable review prose in Korean when the PR title or body is primarily Korean, and in English when it is primarily English. Keep file paths, code identifiers, commands, logs, quoted source, error text, numbers, and protocol literals unchanged. For Korean prose, preserve facts, identifiers, numbers, and quotes while removing only formulaic filler or translationese.
@@ -1915,6 +1915,7 @@ jobs:
           APPROVE only for no blockers, and when result is APPROVE the JSON findings value must be exactly [] with no advisory, informational, already-fixed, or positive findings. REQUEST_CHANGES findings require path,line,severity,title,problem,root_cause,fix_direction,regression_test_direction,suggested_diff. The line must be a positive line number from an actual changed or relevant local file; never use line 0. Failed-check findings must be line-specific and concrete; include the failed check label, exact failed log phrase, observable impact, and trigger condition that led to the line, then provide a minimal suggested diff that changes the identified line. The regression_test_direction should name an exact test target or verification command when the repository already provides one. The suggested_diff must be source-backed and GitHub suggestion-ready when possible: every removed line in the diff must exist in the cited current local file, so do not request changes for code you did not verify in the current source. Multiple Strix model reports must not be collapsed; preserve the model name, report title, severity, endpoint, and Code Locations/path:line evidence in each finding's problem or root_cause when present. One Strix model vulnerability report requires one distinct finding; do not combine duplicate titles or matching locations from different models into one finding. Unrelated speculative findings are invalid when failed-check evidence is present.
           Return only the review body.
           EOF
+          python3 "$GITHUB_WORKSPACE/scripts/ci/render_opencode_prompt_template.py" "$prompt_file"
           cd "$OPENCODE_REVIEW_WORKDIR"
           opencode_json_file="${OPENCODE_OUTPUT_FILE}.jsonl"
           opencode_export_file="${OPENCODE_OUTPUT_FILE}.session.json"
@@ -2018,7 +2019,7 @@ jobs:
             printf 'review_status=%s\n' "$1" >>"$GITHUB_OUTPUT"
           }
           prompt_file="${RUNNER_TEMP}/opencode-review-prompt.md"
-          cat >"$prompt_file" <<EOF
+          cat >"$prompt_file" <<'EOF'
           DeepSeek R1-0528 failed; review PR #${PR_NUMBER} in ${OPENCODE_SOURCE_WORKDIR} with DeepSeek V3-0324. The trusted workflow checkout is ${GITHUB_WORKSPACE}; inspect the pull request head source only from ${OPENCODE_SOURCE_WORKDIR}. Be general-purpose and meticulous: actively consult CodeGraph MCP for structural checks, DeepWiki for repo docs, Context7 for current library/API docs, and web_search for bounded external lookups such as action/tool release facts, industry standards, international standards, official platform specifications, and comparable issue or PR precedents when applicable. Do not rely on model memory for user-claimed concepts, standards, runtime support, or domain terminology when a search source is available. If a configured MCP source is unavailable or not applicable, say so briefly in the review summary. Inspect changed files and focused hunks directly when MCP evidence is insufficient. Do not claim repository docs, images, or reference assets are unavailable, missing, or absent unless the changed docs repository tree evidence proves it. If an external MCP source is unavailable, state that as a source limitation, not as a repository fact.
           Structural exploration is mandatory for every PR, including dependency-only, lockfile-only, workflow-only, docs-only, and no-source-code changes; inspect the relevant manifest, lockfile, workflow, config, docs, dependency edges, generated side effects, code-to-documentation consistency, documentation-to-code consistency, and test-command contracts. Docs-only changes still require CodeGraph, DeepWiki, Context7, or web_search evidence when they make claims about behavior, APIs, setup, workflows, dependencies, standards, or product/domain concepts. If changed documentation contradicts current code, generated behavior, official docs, repository docs, or reachable standards evidence, request changes with a source-backed fix direction: either fix the documentation claim or update the code/contract that makes the claim false. Never state that structural exploration, structural analysis, or structural review is not required or unnecessary. If structural exploration was not possible or changed files could not be inspected after reading bounded-review-evidence.md and the changed files, do not approve. If evidence is truncated, inspect focused hunks and changed files directly before deciding. Do not request changes solely because the prompt did not inline the full evidence.
           Use CodeGraph for blast-radius, call graph, and test-coverage questions before broad local reads. Prefer deletion, stdlib/native platform features, and already-installed dependencies before proposing new code or packages, but do not simplify away trust-boundary validation, data-loss handling, security, accessibility, or required tests. Follow the Review language evidence section: write human-readable review prose in Korean when the PR title or body is primarily Korean, and in English when it is primarily English. Keep file paths, code identifiers, commands, logs, quoted source, error text, numbers, and protocol literals unchanged. For Korean prose, preserve facts, identifiers, numbers, and quotes while removing only formulaic filler or translationese.
@@ -2042,6 +2043,7 @@ jobs:
           APPROVE only for no blockers, and when result is APPROVE the JSON findings value must be exactly [] with no advisory, informational, already-fixed, or positive findings. REQUEST_CHANGES findings require path,line,severity,title,problem,root_cause,fix_direction,regression_test_direction,suggested_diff. The line must be a positive line number from an actual changed or relevant local file; never use line 0. Failed-check findings must be line-specific and concrete; include the failed check label, exact failed log phrase, observable impact, and trigger condition that led to the line, then provide a minimal suggested diff that changes the identified line. The regression_test_direction should name an exact test target or verification command when the repository already provides one. The suggested_diff must be source-backed and GitHub suggestion-ready when possible: every removed line in the diff must exist in the cited current local file, so do not request changes for code you did not verify in the current source. Multiple Strix model reports must not be collapsed; preserve the model name, report title, severity, endpoint, and Code Locations/path:line evidence in each finding's problem or root_cause when present. One Strix model vulnerability report requires one distinct finding; do not combine duplicate titles or matching locations from different models into one finding. Unrelated speculative findings are invalid when failed-check evidence is present.
           Return only the review body.
           EOF
+          python3 "$GITHUB_WORKSPACE/scripts/ci/render_opencode_prompt_template.py" "$prompt_file"
           cd "$OPENCODE_REVIEW_WORKDIR"
           opencode_json_file="${OPENCODE_OUTPUT_FILE}.jsonl"
           opencode_export_file="${OPENCODE_OUTPUT_FILE}.session.json"
@@ -2146,7 +2148,7 @@ jobs:
             printf 'review_status=%s\n' "$1" >>"$GITHUB_OUTPUT"
           }
           prompt_file="${RUNNER_TEMP}/opencode-review-prompt.md"
-          cat >"$prompt_file" <<EOF
+          cat >"$prompt_file" <<'EOF'
           DeepSeek R1-0528 and DeepSeek V3-0324 failed; review PR #${PR_NUMBER} in ${OPENCODE_SOURCE_WORKDIR} with GPT-5. The trusted workflow checkout is ${GITHUB_WORKSPACE}; inspect the pull request head source only from ${OPENCODE_SOURCE_WORKDIR}. Be general-purpose and meticulous: actively consult CodeGraph MCP for structural checks, DeepWiki for repo docs, Context7 for current library/API docs, and web_search for bounded external lookups such as action/tool release facts, industry standards, international standards, official platform specifications, and comparable issue or PR precedents when applicable. Do not rely on model memory for user-claimed concepts, standards, runtime support, or domain terminology when a search source is available. If a configured MCP source is unavailable or not applicable, say so briefly in the review summary. Inspect changed files and focused hunks directly when MCP evidence is insufficient. Do not claim repository docs, images, or reference assets are unavailable, missing, or absent unless the changed docs repository tree evidence proves it. If an external MCP source is unavailable, state that as a source limitation, not as a repository fact.
           Structural exploration is mandatory for every PR, including dependency-only, lockfile-only, workflow-only, docs-only, and no-source-code changes; inspect the relevant manifest, lockfile, workflow, config, docs, dependency edges, generated side effects, code-to-documentation consistency, documentation-to-code consistency, and test-command contracts. Docs-only changes still require CodeGraph, DeepWiki, Context7, or web_search evidence when they make claims about behavior, APIs, setup, workflows, dependencies, standards, or product/domain concepts. If changed documentation contradicts current code, generated behavior, official docs, repository docs, or reachable standards evidence, request changes with a source-backed fix direction: either fix the documentation claim or update the code/contract that makes the claim false. Never state that structural exploration, structural analysis, or structural review is not required or unnecessary. If structural exploration was not possible or changed files could not be inspected after reading bounded-review-evidence.md and the changed files, do not approve. If evidence is truncated, inspect focused hunks and changed files directly before deciding. Do not request changes solely because the prompt did not inline the full evidence.
           Use CodeGraph for blast-radius, call graph, and test-coverage questions before broad local reads. Prefer deletion, stdlib/native platform features, and already-installed dependencies before proposing new code or packages, but do not simplify away trust-boundary validation, data-loss handling, security, accessibility, or required tests. Follow the Review language evidence section: write human-readable review prose in Korean when the PR title or body is primarily Korean, and in English when it is primarily English. Keep file paths, code identifiers, commands, logs, quoted source, error text, numbers, and protocol literals unchanged. For Korean prose, preserve facts, identifiers, numbers, and quotes while removing only formulaic filler or translationese.
@@ -2170,6 +2172,7 @@ jobs:
           APPROVE only for no blockers, and when result is APPROVE the JSON findings value must be exactly [] with no advisory, informational, already-fixed, or positive findings. REQUEST_CHANGES findings require path,line,severity,title,problem,root_cause,fix_direction,regression_test_direction,suggested_diff. The line must be a positive line number from an actual changed or relevant local file; never use line 0. Failed-check findings must be line-specific and concrete; include the failed check label, exact failed log phrase, observable impact, and trigger condition that led to the line, then provide a minimal suggested diff that changes the identified line. The regression_test_direction should name an exact test target or verification command when the repository already provides one. The suggested_diff must be source-backed and GitHub suggestion-ready when possible: every removed line in the diff must exist in the cited current local file, so do not request changes for code you did not verify in the current source. Multiple Strix model reports must not be collapsed; preserve the model name, report title, severity, endpoint, and Code Locations/path:line evidence in each finding's problem or root_cause when present. One Strix model vulnerability report requires one distinct finding; do not combine duplicate titles or matching locations from different models into one finding. Unrelated speculative findings are invalid when failed-check evidence is present.
           Return only the review body.
           EOF
+          python3 "$GITHUB_WORKSPACE/scripts/ci/render_opencode_prompt_template.py" "$prompt_file"
           cd "$OPENCODE_REVIEW_WORKDIR"
           opencode_json_file="${OPENCODE_OUTPUT_FILE}.jsonl"
           opencode_export_file="${OPENCODE_OUTPUT_FILE}.session.json"
@@ -2296,7 +2299,7 @@ jobs:
             opencode_json_file="${candidate_output_file}.jsonl"
             opencode_export_file="${candidate_output_file}.session.json"
             prompt_file="${RUNNER_TEMP}/opencode-review-${model_candidate//\//-}-prompt.md"
-            cat >"$prompt_file" <<EOF
+            cat >"$prompt_file" <<'EOF'
           DeepSeek R1-0528, DeepSeek V3-0324, and GPT-5 did not produce a usable review. Review PR #${PR_NUMBER} in ${OPENCODE_SOURCE_WORKDIR} with ${model_candidate}. The trusted workflow checkout is ${GITHUB_WORKSPACE}; inspect the pull request head source only from ${OPENCODE_SOURCE_WORKDIR}.
           CodeGraph MCP is mandatory for structural checks. Also use DeepWiki for repo docs, Context7 for current library/API docs, and web_search for bounded external lookups such as user-claimed concepts, industry standards, international standards, official platform specifications, and comparable issue or PR precedents when applicable. Do not rely on model memory for concepts, standards, runtime support, or domain terminology when a search source is available.
           Read ./bounded-review-evidence.md first, follow its Review language evidence for the final review language, then inspect changed files and focused hunks under the PR head worktree. Cover security/privacy boundaries, auth/authz and tenant isolation, workflow contracts, developer experience, user-facing behavior, tests, coverage/docstring evidence, cross-file compatibility, runtime-version matrix compatibility, package/build/test/lint/security contract completeness, repository conventions, accessibility/i18n, dependency license and supply-chain risk, IaC/cloud/Docker behavior, performance/resource usage, observability, deployment evidence, git history, breaking-change/backcompat impact, and regression risk. Read the Review execution contracts section before choosing commands; if source exists without a package, build, test, coverage, lint, or security contract, flag the packaging/operability gap with affected language and sample files. Compare repository-local patterns before judging DX or UX: preserve helpful automation, review, setup, documentation, and product-flow patterns from sibling repositories when they reduce cognitive load or user friction, and flag patterns that only add noise, false failures, misleading status, repeated waiting, or URL-only diagnostics. For schema, migration, database, API, workflow, security, or compliance changes, compare against nearby implementation, code conventions, reserved words, naming rules, applicable standards, and production deployment evidence before approving.
@@ -2310,6 +2313,7 @@ jobs:
           -->
           APPROVE only for no blockers, and when result is APPROVE the JSON findings value must be exactly [] with no advisory, informational, already-fixed, or positive findings. Put all required Verification posture labels inside the JSON summary string itself, not only in prose after the control block. REQUEST_CHANGES findings require path,line,severity,title,problem,root_cause,fix_direction,regression_test_direction,suggested_diff. Use line-specific, source-backed findings only. Return only the review body.
           EOF
+            PROMPT_MODEL_CANDIDATE="$model_candidate" python3 "$GITHUB_WORKSPACE/scripts/ci/render_opencode_prompt_template.py" "$prompt_file"
 
             for opencode_attempt in $(seq 1 "$opencode_attempts"); do
               rm -f "$opencode_json_file" "$opencode_export_file" "$candidate_output_file"