From 457b6339aba06c7b378162b28831d08e7eb7a724 Mon Sep 17 00:00:00 2001 From: Seongho Bae Date: Sun, 28 Jun 2026 19:32:47 +0900 Subject: [PATCH] Harden central review graph contract --- .github/workflows/opencode-review.yml | 12 +++---- docs/org-required-workflow-rollout.md | 45 +++++++++++++++------------ scripts/ci/test_strix_quick_gate.sh | 3 ++ 3 files changed, 34 insertions(+), 26 deletions(-) diff --git a/.github/workflows/opencode-review.yml b/.github/workflows/opencode-review.yml index 77ae9ec1a..c6a2dc01e 100644 --- a/.github/workflows/opencode-review.yml +++ b/.github/workflows/opencode-review.yml @@ -866,7 +866,7 @@ jobs: cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include - one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; do not use generic placeholder nodes like Changed surface or Main risk. + one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; emit every Mermaid node label as a quoted label such as `A["text"]` so spaces, punctuation, parentheses, and file counts render safely; do not use generic placeholder nodes like Changed surface or Main risk. Use an OpenCode-owned review structure compatible with Copilot Review and CodeRabbitAI formatting: include a concise pull request overview, then severity-ordered findings with actionable bullets, then any extra summary context after the findings. Keep raw tool logs out of the main review body. @@ -931,7 +931,7 @@ jobs: cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include - one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; do not use generic placeholder nodes like Changed surface or Main risk. + one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; emit every Mermaid node label as a quoted label such as `A["text"]` so spaces, punctuation, parentheses, and file counts render safely; do not use generic placeholder nodes like Changed surface or Main risk. Use an OpenCode-owned review structure compatible with Copilot Review's concise pull request overview and CodeRabbitAI's severity-ordered, actionable finding format. Put any extra summary context after findings, keep raw tool logs out of the main human-readable review body. @@ -1194,7 +1194,7 @@ jobs: 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. Cover security/privacy boundaries, tenant isolation, workflow contracts, developer experience, user-facing behavior, tests, cross-file compatibility, repository conventions, and regression risk. 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, git history, and deployment evidence before approving. For breaking changes, especially when bounded evidence shows production deployment records, comment on backward-compatibility impact, migration or bridge-module needs, rollout/rollback path, and lower-version compatibility. - Lead with findings ordered by severity. Distinguish blocking findings from important suggestions and nits. Request changes only for actionable blockers with clear problem, root cause, observable impact, trigger condition, minimal fix direction, and exact regression test or verification command when the repository already provides one. For Greptile-style specificity, include a P1/P2/P3 priority in each actionable finding, cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; do not use generic placeholder nodes like Changed surface or Main risk. Use an OpenCode-owned human-readable review structure compatible with Copilot Review's concise pull request overview followed by CodeRabbitAI's severity-ordered actionable finding format; put brief summary context after findings and do not depend on Copilot Review, CodeRabbitAI, or any human reviewer being present. + Lead with findings ordered by severity. Distinguish blocking findings from important suggestions and nits. Request changes only for actionable blockers with clear problem, root cause, observable impact, trigger condition, minimal fix direction, and exact regression test or verification command when the repository already provides one. For Greptile-style specificity, include a P1/P2/P3 priority in each actionable finding, cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; emit every Mermaid node label as a quoted label such as `A["text"]` so spaces, punctuation, parentheses, and file counts render safely; do not use generic placeholder nodes like Changed surface or Main risk. Use an OpenCode-owned human-readable review structure compatible with Copilot Review's concise pull request overview followed by CodeRabbitAI's severity-ordered actionable finding format; put brief summary context after findings and do not depend on Copilot Review, CodeRabbitAI, or any human reviewer being present. If bounded failed GitHub Check evidence contains active failed checks, treat it as a blocker until diagnosed. If every active failed-check block says the job was not started because the GitHub account is locked due to a billing issue, classify it as an external CI/account blocker with no repository source fix; do not invent source-backed REQUEST_CHANGES findings for it. If the evidence says no completed failed GitHub Checks were present, do not request changes solely from that section. A successful same-head manual workflow_dispatch Strix run may supersede a stale failed PR statusCheckRollup Strix context only when failed-check evidence explicitly lists it under Superseded failed checks with the exact target URL; otherwise treat failed rollup contexts as blockers. For Strix or other GitHub Checks, use the failed log excerpt and annotations to identify the exact local file line that must change, then provide a concrete from/to fix and suggested diff. When Strix evidence contains multiple model vulnerability reports, include every model-reported vulnerability as a separate evidence-backed finding, preserving each report's model name, title, severity, endpoint, and Code Locations/path:line evidence when present. When evidence supports it, name the concrete CWE/KISA-style class such as injection, auth/authz, secrets, crypto, path traversal/file upload, XSS/CSRF/SSRF, error disclosure, or debug/deployment config; do not invent a category without evidence. One Strix model vulnerability report requires one distinct finding; do not combine duplicate titles or matching locations from different models into one finding. Do not request changes with only a check URL, workflow name, or generic failure summary. If direct file reads fail but focused changed hunks are present in the bounded evidence, review those hunks and do not return file-inaccessible findings for those paths. Full failed-check evidence, when collected, is available as failed-check-evidence.md in the isolated review workspace; inspect it before emitting any failed-check or Strix finding. @@ -1320,7 +1320,7 @@ jobs: 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. Cover security/privacy boundaries, tenant isolation, workflow contracts, developer experience, user-facing behavior, tests, cross-file compatibility, repository conventions, and regression risk. 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, git history, and deployment evidence before approving. For breaking changes, especially when bounded evidence shows production deployment records, comment on backward-compatibility impact, migration or bridge-module needs, rollout/rollback path, and lower-version compatibility. - Lead with findings ordered by severity. Distinguish blocking findings from important suggestions and nits. Request changes only for actionable blockers with clear problem, root cause, observable impact, trigger condition, minimal fix direction, and exact regression test or verification command when the repository already provides one. For Greptile-style specificity, include a P1/P2/P3 priority in each actionable finding, cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; do not use generic placeholder nodes like Changed surface or Main risk. Use an OpenCode-owned human-readable review structure compatible with Copilot Review's concise pull request overview followed by CodeRabbitAI's severity-ordered actionable finding format; put brief summary context after findings and do not depend on Copilot Review, CodeRabbitAI, or any human reviewer being present. + Lead with findings ordered by severity. Distinguish blocking findings from important suggestions and nits. Request changes only for actionable blockers with clear problem, root cause, observable impact, trigger condition, minimal fix direction, and exact regression test or verification command when the repository already provides one. For Greptile-style specificity, include a P1/P2/P3 priority in each actionable finding, cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; emit every Mermaid node label as a quoted label such as `A["text"]` so spaces, punctuation, parentheses, and file counts render safely; do not use generic placeholder nodes like Changed surface or Main risk. Use an OpenCode-owned human-readable review structure compatible with Copilot Review's concise pull request overview followed by CodeRabbitAI's severity-ordered actionable finding format; put brief summary context after findings and do not depend on Copilot Review, CodeRabbitAI, or any human reviewer being present. If bounded failed GitHub Check evidence contains active failed checks, treat it as a blocker until diagnosed. If every active failed-check block says the job was not started because the GitHub account is locked due to a billing issue, classify it as an external CI/account blocker with no repository source fix; do not invent source-backed REQUEST_CHANGES findings for it. If the evidence says no completed failed GitHub Checks were present, do not request changes solely from that section. A successful same-head manual workflow_dispatch Strix run may supersede a stale failed PR statusCheckRollup Strix context only when failed-check evidence explicitly lists it under Superseded failed checks with the exact target URL; otherwise treat failed rollup contexts as blockers. For Strix or other GitHub Checks, use the failed log excerpt and annotations to identify the exact local file line that must change, then provide a concrete from/to fix and suggested diff. When Strix evidence contains multiple model vulnerability reports, include every model-reported vulnerability as a separate evidence-backed finding, preserving each report's model name, title, severity, endpoint, and Code Locations/path:line evidence when present. When evidence supports it, name the concrete CWE/KISA-style class such as injection, auth/authz, secrets, crypto, path traversal/file upload, XSS/CSRF/SSRF, error disclosure, or debug/deployment config; do not invent a category without evidence. One Strix model vulnerability report requires one distinct finding; do not combine duplicate titles or matching locations from different models into one finding. Do not request changes with only a check URL, workflow name, or generic failure summary. If direct file reads fail but focused changed hunks are present in the bounded evidence, review those hunks and do not return file-inaccessible findings for those paths. Full failed-check evidence, when collected, is available as failed-check-evidence.md in the isolated review workspace; inspect it before emitting any failed-check or Strix finding. @@ -1447,7 +1447,7 @@ jobs: 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. Cover security/privacy boundaries, tenant isolation, workflow contracts, developer experience, user-facing behavior, tests, cross-file compatibility, repository conventions, and regression risk. 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, git history, and deployment evidence before approving. For breaking changes, especially when bounded evidence shows production deployment records, comment on backward-compatibility impact, migration or bridge-module needs, rollout/rollback path, and lower-version compatibility. - Lead with findings ordered by severity. Distinguish blocking findings from important suggestions and nits. Request changes only for actionable blockers with clear problem, root cause, observable impact, trigger condition, minimal fix direction, and exact regression test or verification command when the repository already provides one. For Greptile-style specificity, include a P1/P2/P3 priority in each actionable finding, cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; do not use generic placeholder nodes like Changed surface or Main risk. Use an OpenCode-owned human-readable review structure compatible with Copilot Review's concise pull request overview followed by CodeRabbitAI's severity-ordered actionable finding format; put brief summary context after findings and do not depend on Copilot Review, CodeRabbitAI, or any human reviewer being present. + Lead with findings ordered by severity. Distinguish blocking findings from important suggestions and nits. Request changes only for actionable blockers with clear problem, root cause, observable impact, trigger condition, minimal fix direction, and exact regression test or verification command when the repository already provides one. For Greptile-style specificity, include a P1/P2/P3 priority in each actionable finding, cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; emit every Mermaid node label as a quoted label such as `A["text"]` so spaces, punctuation, parentheses, and file counts render safely; do not use generic placeholder nodes like Changed surface or Main risk. Use an OpenCode-owned human-readable review structure compatible with Copilot Review's concise pull request overview followed by CodeRabbitAI's severity-ordered actionable finding format; put brief summary context after findings and do not depend on Copilot Review, CodeRabbitAI, or any human reviewer being present. If bounded failed GitHub Check evidence contains active failed checks, treat it as a blocker until diagnosed. If every active failed-check block says the job was not started because the GitHub account is locked due to a billing issue, classify it as an external CI/account blocker with no repository source fix; do not invent source-backed REQUEST_CHANGES findings for it. If the evidence says no completed failed GitHub Checks were present, do not request changes solely from that section. A successful same-head manual workflow_dispatch Strix run may supersede a stale failed PR statusCheckRollup Strix context only when failed-check evidence explicitly lists it under Superseded failed checks with the exact target URL; otherwise treat failed rollup contexts as blockers. For Strix or other GitHub Checks, use the failed log excerpt and annotations to identify the exact local file line that must change, then provide a concrete from/to fix and suggested diff. When Strix evidence contains multiple model vulnerability reports, include every model-reported vulnerability as a separate evidence-backed finding, preserving each report's model name, title, severity, endpoint, and Code Locations/path:line evidence when present. When evidence supports it, name the concrete CWE/KISA-style class such as injection, auth/authz, secrets, crypto, path traversal/file upload, XSS/CSRF/SSRF, error disclosure, or debug/deployment config; do not invent a category without evidence. One Strix model vulnerability report requires one distinct finding; do not combine duplicate titles or matching locations from different models into one finding. Do not request changes with only a check URL, workflow name, or generic failure summary. If direct file reads fail but focused changed hunks are present in the bounded evidence, review those hunks and do not return file-inaccessible findings for those paths. Full failed-check evidence, when collected, is available as failed-check-evidence.md in the isolated review workspace; inspect it before emitting any failed-check or Strix finding. @@ -3109,7 +3109,7 @@ jobs: { printf 'GitHub Checks failed after the initial OpenCode review. Diagnose the failed checks and return a line-specific REQUEST_CHANGES review for PR #%s in %s.\n' "$PR_NUMBER" "$GITHUB_WORKSPACE" - printf 'Use the failed log excerpt and annotations below as evidence, follow the Review language evidence from bounded-review-evidence.md for the final review language, then inspect local source files and focused hunks to identify the exact line to edit. For each actionable Strix or GitHub Check failure, provide one finding with path,line,severity,title,problem,root_cause,fix_direction,regression_test_direction,suggested_diff. If PR mergeability evidence reports mergeStateStatus DIRTY, include merge-conflict repair direction that names base/head branches, tells the author to merge or rebase the latest base branch into the PR branch, resolve conflict markers, rerun focused checks, and push the same branch, including a compact command block with gh pr checkout, git fetch, merge or rebase, git status --short, and the normal or --force-with-lease push path. Use Greptile-style specificity: preserve a P1/P2/P3 priority, cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; do not use generic placeholder nodes like Changed surface or Main risk. The line must be a positive line number from an actual changed or relevant local file; never use line 0. Include the failed check label and exact failed log phrase in problem or root_cause; unrelated speculative findings are invalid. 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. The fix_direction must state the concrete from/to change, not only the workflow URL. 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. If Strix evidence contains multiple model vulnerability reports, include every model-reported vulnerability as a separate evidence-backed finding and preserve each report'\''s model name, title, severity, endpoint, and Code Locations/path:line evidence in problem or root_cause when present. When evidence supports it, name the concrete CWE/KISA-style class such as injection, auth/authz, secrets, crypto, path traversal/file upload, XSS/CSRF/SSRF, error disclosure, or debug/deployment config; do not invent a category without evidence. One Strix model vulnerability report requires one distinct finding; do not combine duplicate titles or matching locations from different models into one finding. If a failure is external infrastructure with no source fix, the finding must identify the exact external blocker, supporting log line, and why no repository line can fix it.\n\n' + printf 'Use the failed log excerpt and annotations below as evidence, follow the Review language evidence from bounded-review-evidence.md for the final review language, then inspect local source files and focused hunks to identify the exact line to edit. For each actionable Strix or GitHub Check failure, provide one finding with path,line,severity,title,problem,root_cause,fix_direction,regression_test_direction,suggested_diff. If PR mergeability evidence reports mergeStateStatus DIRTY, include merge-conflict repair direction that names base/head branches, tells the author to merge or rebase the latest base branch into the PR branch, resolve conflict markers, rerun focused checks, and push the same branch, including a compact command block with gh pr checkout, git fetch, merge or rebase, git status --short, and the normal or --force-with-lease push path. Use Greptile-style specificity: preserve a P1/P2/P3 priority, cite the evidence type behind the claim (nearby implementation, matching existing example, cross-file counterpart, current official docs, or failed check/log evidence), flag unrelated PR scope drift, make suggested diffs GitHub suggestion-ready minimal diffs when possible, and include one compact Mermaid DAG that names the changed file or surface and maps it to the affected execution path, main risk, and verification path; emit every Mermaid node label as a quoted label such as `A["text"]` so spaces, punctuation, parentheses, and file counts render safely; do not use generic placeholder nodes like Changed surface or Main risk. The line must be a positive line number from an actual changed or relevant local file; never use line 0. Include the failed check label and exact failed log phrase in problem or root_cause; unrelated speculative findings are invalid. 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. The fix_direction must state the concrete from/to change, not only the workflow URL. 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. If Strix evidence contains multiple model vulnerability reports, include every model-reported vulnerability as a separate evidence-backed finding and preserve each report'\''s model name, title, severity, endpoint, and Code Locations/path:line evidence in problem or root_cause when present. When evidence supports it, name the concrete CWE/KISA-style class such as injection, auth/authz, secrets, crypto, path traversal/file upload, XSS/CSRF/SSRF, error disclosure, or debug/deployment config; do not invent a category without evidence. One Strix model vulnerability report requires one distinct finding; do not combine duplicate titles or matching locations from different models into one finding. If a failure is external infrastructure with no source fix, the finding must identify the exact external blocker, supporting log line, and why no repository line can fix it.\n\n' printf 'Format the human-readable review with OpenCode-owned sections compatible with Copilot Review and CodeRabbitAI: start with a concise pull request overview, then list severity-ordered actionable findings without raw tool logs. Do not depend on those agents or a human reviewer being present.\n\n' printf 'Failed checks:\n' cat "$failed_checks_file" diff --git a/docs/org-required-workflow-rollout.md b/docs/org-required-workflow-rollout.md index 68f64ac23..0ad357b4a 100644 --- a/docs/org-required-workflow-rollout.md +++ b/docs/org-required-workflow-rollout.md @@ -1,6 +1,6 @@ # ContextualWisdomLab central required workflow rollout -Updated: 2026-06-26 17:42 KST +Updated: 2026-06-28 19:21 KST ## Decision @@ -17,7 +17,7 @@ Use an organization repository ruleset instead of copying workflow files into ea - `.github/workflows/opencode-review.yml` - `.github/workflows/pr-review-merge-scheduler.yml` - Required workflow ref: `refs/heads/main` -- Required workflow SHA: `807254a04efafd5f806e0f70cb067ecf050cfd11` +- Required workflow SHA: `f826d99badf98dca0d3be1b135cb2eb2e904b383` - Required workflow trigger support: `pull_request_target` This keeps Strix security evidence, OpenCode review evidence, and merge/update automation sourced from the central `.github` repository. Target repositories do not need local copies of these workflows for the organization required workflow rule. @@ -54,22 +54,22 @@ Do not centralize the scheduler by running a `.github` scheduled job against oth ## Scope -The active ruleset targets the public, non-fork, non-archived repositories found by live GitHub inventory on 2026-06-26. +The active ruleset targets the public, non-fork repositories found by live GitHub inventory on 2026-06-28. -| Repository | Default branch | Flow | Open PRs | Auto-merge | Existing workflow footprint | Existing rules/protection summary | +| Repository | Default branch | Flow | Open PRs | Default-branch workflow footprint | Local central-workflow copies | Rollout status | | --- | --- | --- | ---: | --- | --- | --- | -| `ContextualWisdomLab/.github` | `main` | GitHub Flow | 25 | on | OpenCode, scheduler, Strix, Copilot | central required workflows, lock default branch | -| `ContextualWisdomLab/ContextualWisdomLab.github.io` | `main` | GitHub Flow | 9 | on | OpenCode, scheduler, Strix, Pages, Copilot | central required workflows, lock default branch | -| `ContextualWisdomLab/appguardrail` | `develop` | Git Flow | 0 | on | OpenCode, scheduler, Strix, CodeQL, release/security workflows | central required workflows, lock default branch, PR ruleset | -| `ContextualWisdomLab/bandscope` | `develop` | Git Flow | 81 | on | many CI/security workflows, OpenCode, scheduler | central required workflows, lock default branch, classic branch protection | -| `ContextualWisdomLab/clearfolio` | `main` | GitHub Flow | 18 | off | OpenCode, scheduler, Strix, CodeQL | central required workflows, PR ruleset | -| `ContextualWisdomLab/codec-carver` | `main` | GitHub Flow | 11 | on | OpenCode, scheduler, Strix, Copilot | central required workflows, lock default branch | -| `ContextualWisdomLab/contextual-orchestrator` | `main` | GitHub Flow | 0 | off | Security, Dependabot Updates | central required workflows | -| `ContextualWisdomLab/hyosung-itx-slogan-brief` | `main` | GitHub Flow | 0 | off | OpenCode, scheduler, validation, Copilot | central required workflows, no-branch-delete ruleset | -| `ContextualWisdomLab/naruon` | `develop` | Git Flow | 7 | on | CI, security scans, OpenCode, PR Governance, scheduler, Strix | central required workflows, lock default branch, PR ruleset, classic protection | -| `ContextualWisdomLab/newsdom-api` | `develop` | Git Flow | 6 | on | CI/security/release/pages workflows, OpenCode, scheduler, Strix | central required workflows, lock default branch, mirror classic protection | -| `ContextualWisdomLab/pg-erd-cloud` | `main` | GitHub Flow | 15 | on | CI/security, OpenCode, autofix/fix scheduler, scheduler, Strix | central required workflows, lock default branch | -| `ContextualWisdomLab/scopeweave` | `develop` | Git Flow | 11 | on | security scans, OpenCode, scheduler, Strix, Pages | central required workflows, lock default branch | +| `ContextualWisdomLab/.github` | `main` | GitHub Flow | 32 | OpenCode, scheduler, Strix | central source; keep | central source repo | +| `ContextualWisdomLab/ContextualWisdomLab.github.io` | `main` | GitHub Flow | 15 | none | none | migrated; re-verify before final closure | +| `ContextualWisdomLab/appguardrail` | `develop` | Git Flow | 0 | security | none | migrated; re-verify before final closure | +| `ContextualWisdomLab/bandscope` | `develop` | Git Flow | 92 | OpenCode, scheduler, security | OpenCode, scheduler | rewrite local workflow contracts before removal | +| `ContextualWisdomLab/clearfolio` | `main` | GitHub Flow | 26 | none | none | migrated; re-verify before final closure | +| `ContextualWisdomLab/codec-carver` | `main` | GitHub Flow | 19 | OpenCode, scheduler, Strix | OpenCode, scheduler, Strix | quality uplift first: 100% test/docstring coverage is not yet proven | +| `ContextualWisdomLab/contextual-orchestrator` | `main` | GitHub Flow | 0 | security | none | no local central copies observed; verify inherited checks on next PR | +| `ContextualWisdomLab/hyosung-itx-slogan-brief` | `main` | GitHub Flow | 0 | validation | none | migrated; re-verify before final closure | +| `ContextualWisdomLab/naruon` | `develop` | Git Flow | 19 | OpenCode, scheduler, Strix, Pages/deploy, security | OpenCode, scheduler, Strix | complex local review/process contract; inspect #745-era behavior before removal | +| `ContextualWisdomLab/newsdom-api` | `develop` | Git Flow | 21 | OpenCode, scheduler, Strix, Pages/deploy, security | OpenCode, scheduler, Strix | rewrite local workflow/runtime-env tests before removal | +| `ContextualWisdomLab/pg-erd-cloud` | `main` | GitHub Flow | 25 | OpenCode, scheduler, Strix, security, autofix/fix | OpenCode, scheduler, Strix | preserve/autonomize autofix contract before removing local governance copies | +| `ContextualWisdomLab/scopeweave` | `develop` | Git Flow | 22 | OpenCode, scheduler, Strix, Pages/deploy, security | OpenCode, scheduler, Strix | rewrite docs/tests that treat local Strix/OpenCode files as the contract | ## Current policy @@ -94,6 +94,9 @@ The active ruleset targets the public, non-fork, non-archived repositories found - `.github` PR `#79` merged the central scheduler `pull_request_target` path and PR-scoped `--pr-number` lookup. - `.github` PR `#79` second current-head proof passed coverage evidence in 10s, Strix in 8m33s, and OpenCode review in 8m57s on head `17c62f3809c57ca4b1a9a63e14f325c9f2a1acdb`. - Organization ruleset `18156473` now requires `.github/workflows/strix.yml`, `.github/workflows/opencode-review.yml`, and `.github/workflows/pr-review-merge-scheduler.yml` from `.github@main` SHA `807254a04efafd5f806e0f70cb067ecf050cfd11`. +- `.github` PR `#85` installed target repository `requirements.txt` before Python coverage evidence, so central coverage measurement can run repo tests that require project dependencies. +- `.github` PR `#88` hardened the OpenCode output normalizer so the Python normalizer is part of the trusted approval gate path. +- On 2026-06-28 19:21 KST, ruleset `18156473` was re-pinned to `.github@main` SHA `f826d99badf98dca0d3be1b135cb2eb2e904b383` for all three required workflow paths. - `ContextualWisdomLab/naruon` reports inherited active ruleset `18156473` with all three required workflow paths, proving target-repository inheritance after the scheduler ruleset update. - `ContextualWisdomLab/ContextualWisdomLab.github.io` PR `#25` merged the thin central scheduler caller and repository-local bootstrap fixes. Its main Strix run `28217860369` passed. - The organization ruleset API reports the central required workflows ruleset as `active` and inherited by each public non-fork target repository. @@ -107,7 +110,9 @@ The active ruleset targets the public, non-fork, non-archived repositories found ## Risks and follow-up -- Existing open PRs may need a new push or base update before the newly required OpenCode check appears on their current head. -- The central Strix workflow still defaults to GPT-5 and falls back to DeepSeek models. The PR `#77` central required run passed in 9m25s, but earlier runs have been slower. If runtime or rate limits continue, adjust Strix model routing separately. -- Some repositories still have local Strix/OpenCode/scheduler workflows. Do not copy more workflows into repositories; instead, retire local copies after the organization ruleset proves the central required workflows stable on current heads. -- Some repositories use classic branch protection while others use rulesets. The next rollout pass should normalize branch protection into rulesets without removing repository-specific required application checks. +- Existing open PRs may need a new push or base update before the latest required workflow SHA appears on their current head. +- The central OpenCode workflow now retries DeepSeek R1, DeepSeek V3, GPT-5, and a catalog fallback pool. Keep model/tooling failures out of PR comments unless there is a source-backed failed-check diagnosis. +- Generated OpenCode review DAGs must use quoted Mermaid labels such as `A["text"]`; unquoted labels with spaces, punctuation, parentheses, or file counts can fail to render. +- Some repositories still have local Strix/OpenCode/scheduler workflows. Do not copy more workflows into repositories; retire local copies only after repository tests and docs are rewritten to the central required-workflow contract. +- Repositories with local autofix/update workflows, especially `pg-erd-cloud`, need an explicit central autofix contract before local workflows are removed. +- Some repositories use classic branch protection while others use rulesets. Normalize branch protection into rulesets without removing repository-specific required application checks. diff --git a/scripts/ci/test_strix_quick_gate.sh b/scripts/ci/test_strix_quick_gate.sh index 50ba84d43..6a57c317e 100755 --- a/scripts/ci/test_strix_quick_gate.sh +++ b/scripts/ci/test_strix_quick_gate.sh @@ -1194,6 +1194,9 @@ EOF assert_file_contains "$REPO_ROOT/.github/workflows/opencode-review.yml" "OPENCODE_CHANGED_FILES_FILE" "opencode workflow exports exact current-head changed files" assert_file_contains "$REPO_ROOT/.github/workflows/opencode-review.yml" 'diff --name-only --find-renames "$PR_MERGE_BASE" "$PR_HEAD_SHA" >"$OPENCODE_CHANGED_FILES_FILE"' "opencode workflow writes exact changed files for the normalizer" assert_file_contains "$REPO_ROOT/.github/workflows/opencode-review.yml" "changed-files.txt" "opencode workflow copies exact changed-file evidence into the isolated review workspace" + assert_file_contains "$REPO_ROOT/.github/workflows/opencode-review.yml" 'A["text"]' "opencode prompt requires quoted Mermaid labels" + assert_file_contains "$REPO_ROOT/.github/workflows/opencode-review.yml" 'S%s["%s"]' "opencode generated Mermaid surface labels are quoted" + assert_file_contains "$REPO_ROOT/.github/workflows/opencode-review.yml" 'R%s["Review risk: %s"]' "opencode generated Mermaid risk labels are quoted" cat >"$changed_files_file" <<'EOF' .github/workflows/opencode-review.yml