chore(ci): bootstrap Product pull-request workflow

[seonghobae]

Problem

main@f4f440dd58c77d7cd90dff8a1eb2eeb9a9940425 has no .github/workflows/product.yml. Foundation #1 defines Product CI only on its feature head, so GitHub cannot start the repository-owned pull_request Product workflow from the protected base. Exact-head Product evidence therefore cannot exist before the workflow is first integrated; this is a bootstrap dependency, not a product-code failure.

Minimal causal repair

Add only the pull-request form of the current Foundation Product workflow to main. It checks out the event's exact PR head, verifies the SHA, runs the repository CI-contract checker, Rust format/Clippy/tests/rustdoc, exact owned coverage, Draft 2020-12 fixtures, lockfile freshness, and clean-tree checks. Checkout credentials remain disabled and action revisions remain pinned.

Queue-conservation successor a31ae0c2df920f2794f7ddb456795b04797ab472 removes converted_to_draft and closed, which created runs whose only Rust job was guaranteed not to execute. opened, synchronize, reopened, and ready_for_review remain.

Current exact-head evidence — 2026-09-06

The head remains a31ae0c2df920f2794f7ddb456795b04797ab472, open/non-Draft/mergeable on base main@f4f440dd58c77d7cd90dff8a1eb2eeb9a9940425.

Repository workflow evidence on this unchanged head remains mixed: Security Scan 33938445660 and SAST Semgrep 33938445673 are terminal success; CodeQL PR 33938445642, Required OpenCode Review 33938445067, and Strix 33938445050 are terminal failure. Required Noema workflow 33938445009 completed, but its submitted review remains a blocking CHANGES_REQUESTED. Required PR Review Merge Scheduler 33938445033 succeeded. No qualifying independent APPROVE has been established.

CodeQL/OpenCode owner admission remains central

The old CodeQL dispatch .github run 33961083940 failed after acquiring ubuntu-24.04 and exchanging the app token because client_payload.matrix was bound directly to env: as an array. .github#1926 repaired that owner defect normally as merge 3f88e13af9dcde4b9da6958c02a78ce3b5c85800 by serializing the matrix before existing JSON validation. The old #35 failure is not retroactively GREEN; fresh authenticated exact-head CodeQL evidence is still required.

Required leaf run 33938445067 had already validated the exact #35 head, obtained OIDC/repository-scoped app credentials, and dispatched owner-controlled execution before failing closed because no current-head verdict existed. Its corresponding central OpenCode run .github 33977685099 acquired ubuntu-24.04, completed app-token exchange, then failed Bind workflow inputs to live organization pull request metadata; downstream coverage/substantive review work was skipped.

Central #1932 is merged and supports a comma-separated trusted-identity list. Current .github#1929 remains open. Fresh owner evidence distinguishes three observed producer identities: OpenCode/CodeQL app-token dispatches use opencode-agent[bot]; a legacy/scheduler path has emitted github-actions[bot]; and measured review-fix dispatches used the human account seonghobae. The least-widening repair is not to add the human account to a machine-dispatch allowlist. Migrate the review-fix producer off the user PAT identity onto the repository-scoped GitHub App identity (or another dedicated machine principal), then reconcile OPENCODE_REPOSITORY_DISPATCH_ACTOR only to machine identities fresh producer inventory proves are intentionally retained. Preserve actor == sender plus exact repository/PR/base/head/wake binding. Acceptance requires fresh current-central-head canaries from OpenCode, CodeQL, and review-fix to reach substantive jobs while an otherwise identical human-account dispatch remains rejected.

Protected central .github/main is fb2ae81dbeaacb0c630e51e9d772c6919fa220cf after #1949 merged. #1949 is a real review-sidecar reliability repair: it treats the model catalog as candidates, lazily fills toward eight ready routes within a bounded probe budget, skips an account after repeated 429s, and no longer lets known-dead catalog entries permanently occupy served slots. This helps the historical Strix/Noema reliability lane but does not establish machine-principal dispatch authorization.

Fresh current-central-head CodeQL specimen 34013909079 is now terminal failure, not queued. It was dispatched by opencode-agent[bot], obtained an ubuntu-24.04 runner, successfully exchanged the OpenCode app token, then failed Bind workflow inputs to live organization pull request metadata; the substantive CodeQL dispatch scan was skipped. The specimen targets pg-erd-cloud#1089, so it is owner-plane evidence rather than #35 exact-head evidence, but it proves the current central head still has the same admission-class failure and that #1929 cannot be treated as repaired. Do not replay the old ConceptWeave handles or no-op push #35 merely to consume this owner evidence.

Base-drift semantics remain separate

.github#1931 separately tracks queue-time base_sha drift. Exact head_sha binding remains mandatory. The original #35 OpenCode specimen did not drift because ConceptWeave protected main and #35 head remain unchanged, so #1931 is not its explanation.

Noema finding remains unresolved at owner

Noema review 5120903874 requested changes because it asserted cargo generate-lockfile --locked is unsupported. Official Cargo documentation and the recorded Cargo 1.98.0 help output contradict that premise; verification COMMENT 5120921180 records the evidence. The review is retained rather than dismissed. .github#1924 remains open and owns the generic contradicted-external-capability contract. Merged .github#1944 improves failed Noema artifact capture but does not repair the false-capability adjudication semantics.

Strix routing reliability advanced, but this exact #35 evidence remains failed

Strix 33938445050 reached trusted gateway execution but its substantive session failed after repeated gateway HTTP 500s. Since that historical run, contextual-orchestrator#1081 merged as protected main@414f22973658c4ddc3d4320fcf7acd9b4e8ba991, removing multiplicative transport retries beneath _invoke's own retry-then-failover loop. Central review-sidecar successors, including #1949, now also improve catalog readiness selection. These are real owner-path repairs, not retroactive #35 GREEN.

contextual-orchestrator#1049 remains open at 87612a68b3af1f305bb7b09bd0be860bad1b7fd6 for passthrough retryable 502/network failover and typed attempt evidence. A fresh Strix execution using the current central trusted workflow and pinned owner code is required before deciding whether the historical #35 HTTP-500 failure class is closed or whether a narrower status-classification/attempt-evidence defect remains. ConceptWeave does not hard-code providers/models or add a leaf fallback.

Safety / merge gate

Keep exact #35 head stable unless a real leaf defect requires a causal source change. No no-op push, blind rerun, self-approval, review dismissal, force push/rebase, protection weakening, provider bypass, or admin merge.

Required before normal merge: central machine-principal dispatch reconciliation plus authenticated current-head OpenCode execution; fresh terminal CodeQL evidence through the repaired current central path; correction/re-evaluation of the contradicted Noema finding; a fresh current-owner Strix result after the CO and central review-sidecar reliability repairs; and one qualifying independent approval. After #35 integrates, Foundation #1 can receive real protected-base Product evidence and then advance Client/Source Observation normally.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 8fe88470-4d73-4133-828e-eae81acdbec9

📥 Commits

Reviewing files that changed from the base of the PR and between daa543c and a31ae0c.

📒 Files selected for processing (1)

• .github/workflows/product.yml

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/product.yml

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

Product GitHub Actions 워크플로의 pull request 이벤트 목록을 축소합니다. rust-quality 작업은 draft pull request만 건너뜁니다. 기존 품질, 커버리지, 계약 및 저장소 검증 단계는 변경하지 않습니다.

Changes

Product CI 워크플로

Layer / File(s)	Summary
워크플로 트리거 및 실행 조건 .github/workflows/product.yml	opened, synchronize, reopened, ready_for_review 이벤트에서만 워크플로를 실행합니다. converted_to_draft와 closed 이벤트를 제거합니다. rust-quality 작업은 draft pull request만 건너뜁니다. 기존 검증 단계는 유지합니다.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to a31ae

This change adjusts Product pull-request workflow triggers and draft-job behavior while retaining the stated validation steps. No concrete merge-blocking risk is identified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	제목은 Product pull-request workflow의 부트스트랩이라는 주요 변경을 명확하고 간결하게 설명합니다.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/product-ci-bootstrap

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

현재 bootstrap workflow가 converted_to_draft와 closed에도 기동하지만 유일한 rust-quality job은 조건식에서 두 상태를 실행하지 않습니다. 즉 해당 이벤트는 의미 있는 검증 없이 workflow run만 생성합니다. 현재 중앙 runner admission이 장시간 queued인 상황에서는 불필요한 run 생성 자체가 비용입니다. pull_request.types는 opened, synchronize, reopened, ready_for_review로 좁히고 job 조건은 draft 여부만 검사하는 것이 기존 bootstrap 목적을 보존하는 최소 수리입니다. 이 finding은 기존 queued check를 GREEN으로 대체하지 않습니다.

[seonghobae]

Fresh control-plane correction (2026-09-05): protected ContextualWisdomLab/.github/main advanced to bc59c07c448dcfa1b8fbc64b601550d232697f24 through merged #1890, which added a 15-minute timeout to the synchronous Noema model step and a 30-minute enclosing-job timeout. That is incompatible with the current CWL LLM contract (model timeout default null, long-running Noema/OpenCode/Strix allowed, and user-cancel/provider-end/admin-timeout kept distinct). Owner repair .github#1891@9dc149e7f093c6069dc6e85ae55186e4af033923 is now open Draft and restores the exact four pre-#1890 owner blobs without provider/model/gate changes. Treat #35's already-created central runs as evidence for their own exact workflow revisions only; do not call #35 integration-ready while the required Noema owner path on protected .github/main is known policy-incompatible. Normal owner integration or a verified successor to #1891 is now an additional control-plane prerequisite; no no-op rerun or bypass is requested.

[cwl-noema-review]

Noema LLM review

The new Product pull-request workflow is generally well-structured with pinned action SHAs, minimal permissions, and a concurrency guard. However, the 'Lockfile freshness' step invokes cargo generate-lockfile --locked, which is an invalid flag combination for that subcommand and will cause the step to fail on every run, blocking the entire workflow. This must be fixed before approval.

Reviewed changed lines

• .github/workflows/product.yml:25 (RIGHT): Checkout action is pinned to a known immutable SHA for actions/checkout v7.0.0 and uses fetch-depth 0 with persist-credentials false, which is correct for CI.
• .github/workflows/product.yml:63 (RIGHT): The pinned nightly-2026-08-20 toolchain exists and is installed via rustup, which is reproducible and matches the coverage workflow intent.
• .github/workflows/product.yml:89 (RIGHT): cargo generate-lockfile --locked is not a valid invocation: --locked is not accepted by the generate-lockfile subcommand. This will always fail, breaking the workflow.

Adversarial validation

• .github/workflows/product.yml:89 (RIGHT) confirmed: cargo generate-lockfile --locked will fail because --locked is not a valid flag for the generate-lockfile subcommand. — Cargo's CLI documentation and runtime behavior confirm that --locked is only supported by build/check/test commands, not generate-lockfile. The command produces an error about an unexpected argument.
• .github/workflows/product.yml:25 (RIGHT) falsified: The pinned checkout SHA might be stale or invalid, causing workflow resolution to fail. — The SHA matches the published immutable ref for actions/checkout v7.0.0, so runtime resolution is safe.
• Residual risk: The blocker at line 89 prevents the workflow from ever completing successfully. Once fixed (e.g., remove --locked and rely on the subsequent git status check), the workflow should be re-verified; no other residual risks were identified.

Findings

• [high] .github/workflows/product.yml:89 (RIGHT): cargo generate-lockfile --locked is an invalid command; --locked is not supported by the generate-lockfile subcommand. This will cause the 'Lockfile freshness' step to fail on every run, rendering the workflow non-functional. Use cargo generate-lockfile (without --locked) to generate the lockfile, and then verify freshness with a git status check as currently done.

• Result: REQUEST_CHANGES
• Head SHA: a31ae0c2df920f2794f7ddb456795b04797ab472
• Reviewer credential: noema-review-github-app-refresh
• Actor: cwl-noema-review[bot]

[seonghobae]

Rechecking Noema review 5120903874 on exact head a31ae0c2df920f2794f7ddb456795b04797ab472: the claimed unsupported cargo generate-lockfile --locked flag is not reproducible on the pinned production toolchain.

cargo +1.98.0 --version reports cargo 1.98.0 (797e8a9bc 2026-08-05). cargo +1.98.0 generate-lockfile --help exits 0 and lists --locked under Manifest Options. The official cargo-generate-lockfile documentation also documents it and its fail-closed behavior when dependency resolution would change the existing lockfile. The exact-head workflow retains the subsequent tracked-file and clean-lockfile checks.

Please reassess this finding against the toolchain-specific evidence. I have not removed the guard, dismissed the review, resolved a reviewer thread, or treated a successful Noema execution check as approval. This validates flag availability, not a hosted Product run or all dependency-freshness behavior. Exact-head checks and independent approval remain required.

[seonghobae]

Current-head finding verification: the Noema CHANGES_REQUESTED claim that cargo generate-lockfile --locked is an invalid flag combination is false against the current official Cargo reference. cargo-generate-lockfile(1) explicitly lists --locked under Manifest Options and specifies that it asserts the existing Cargo.lock can be reused without dependency-resolution changes, which is exactly the intended CI freshness contract here. The current workflow line is therefore retained. This COMMENT does not approve the PR, dismiss the Noema review, or convert the still-failing/pending CodeQL evidence into GREEN. Current authoritative blockers remain the authenticated terminal CodeQL outcome and qualifying independent approval. Primary reference verified 2026-09-05: https://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.html

[seonghobae]

Central-head correction after the prior authority refresh: protected ContextualWisdomLab/.github/main has advanced to f250638827f8252b0d9e5cb2601f4d333f96162f via #1922 (fix(ci): restore scheduler CI isolation and contract selection). This does not retroactively alter #35's already-created exact-head workflow provenance or justify a no-op retrigger. The current #35 gate remains authenticated terminal CodeQL plus correction/re-evaluation of the false Noema finding and qualifying independent approval.

[seonghobae]

Fresh Strix RCA on unchanged head a31ae0c2df920f2794f7ddb456795b04797ab472: Required Strix run 33938445050 did acquire runners, admit the exact PR head, materialize the one-file workflow scope, provision the trusted contextual-orchestrator sidecar, and pass its gateway preflight. The failing job is 101256562088, step Run Strix (quick).

Downloaded immutable artifact strix-reports (9969701340, sha256:689e780747d5a2d7b1f5857f7d2a8900cd166b6694e6fa3a324c49c2e53ccf06) shows orchestrator/free admitted 62 free routes with three-account diversity, selected 12, and plain-chat preflight found 3 ready candidates. The real Strix session then made 17 model requests, repeatedly received gateway 500 internal_error, exhausted Strix/OpenAI retries and lifecycle replay over ~7,014 s, and failed closed as STRIX_PROVIDER_UNAVAILABLE; the final SARIF contains zero findings because analysis did not complete.

This is a gateway/provider-failover owner defect, not evidence for changing the Product workflow diff and not a successful security verdict. The exact specimen is handed to contextual-orchestrator#1045 (comment 5552624035) so its existing virtual-model failover/typed-attempt contract covers retryable 500 as well as the already-recorded 502 class. Keep this #35 head stable; do not add leaf provider/model fallback or treat the failed scan as GREEN.

[seonghobae]

Fresh owner-state correction for the unchanged a31ae0c2df920f2794f7ddb456795b04797ab472 head:

• Central .github#1939 has now merged normally as f2f91b806122ed233e3a0e2a325246077c2e15e4. It repairs the exact bounded sidecar-catalog bias visible in this PR's failed Strix run 33938445050: that run discovered/admitted three free credential accounts but selected 8 nvidia_nim + 4 nvidia_nim_sub routes and no OpenRouter within the 12-route bound. #1939 fills each cost/ZDR tier round-robin across accounts instead, retaining tier ordering/caps/limits.
• The existing Strix handle is not valid acceptance evidence for that repair. Job 101256562088 records trusted workflow source .github@8272e4f95c253ab067592460cc9288581bf3a422; reusing the old run handle would remain evidence for that frozen owner source, not #1939@f2f91b.... Acceptance therefore needs a newly emitted same-consumer-head run against current trusted workflow source, not a blind rerun/no-op source push.
• .github#1929 has also moved from an unresolved choice to an owner decision: preserve both legitimate bot producers and set the exact actor allowlist to github-actions[bot],opencode-agent[bot], while excluding the diagnostic user-token identity and retaining actor==sender/live-PR/head checks. I cannot read or mutate that repository Actions variable through the available connector, and there is no post-change successful chore(ci): bootstrap Product pull-request workflow #35 dispatch evidence here, so this remains owner-plane reconciliation rather than a ConceptWeave source fix.
• Do not promote #1939 alone to full Strix GREEN. contextual-orchestrator#1049@87612a68b3af1f305bb7b09bd0be860bad1b7fd6 remains the runtime failover owner, and this PR's terminal specimen is HTTP 500. The previously requested 500→next-candidate success / bounded all-500 exhaustion contract is still not integrated on that owner head.

Keep #35 source stable. The next useful evidence is a newly emitted current-workflow exact-head dispatch after owner-plane authorization convergence; old-handle replay would not test the repaired owner source.

[seonghobae]

Fresh owner-plane reconciliation, 2026-09-06: central .github/main has advanced to protected fe827e133e7d867015d088777553e22736344c55. This includes merged #1939 (f2f91b806122ed233e3a0e2a325246077c2e15e4), which repairs bounded sidecar catalog selection to round-robin across admitted credential accounts, and merged #1944 (fe827e...), which uploads sanitized Noema sidecar stderr/preflight evidence when verdict preparation fails. #1944 is observability only; it does not resolve the ConceptWeave false Cargo capability finding tracked by .github#1924, which remains open.

The dispatcher authorization owner issue .github#1929 also remains open. A new current-workflow/current-central-head specimen now removes the remaining ambiguity about whether #1932 alone made the app-token producer executable: CodeQL dispatch run 33997332726 on .github/main@fe827e..., actor opencode-agent[bot], acquired a hosted Ubuntu 24.04 runner, successfully exchanged the OpenCode app token, then failed Bind workflow inputs to live organization pull request metadata in validate-dispatch job 101390037190; its matrix scan job 101395191995 was skipped. This is not an old-handle rerun. I handed that exact evidence to .github#1929 as comment 5555579541. The connector still cannot read/write the Actions variable, so I am not inferring its value; owner acceptance remains an explicit two-bot variable reconciliation followed by a newly emitted dispatch that passes validation and produces a terminal verdict.

No newer #35 PR-triggered run is visible on unchanged #35 head a31ae0c2df920f2794f7ddb456795b04797ab472; the existing CodeQL/OpenCode/Strix failures therefore remain historical failures under older owner state, not post-repair GREEN. Do not rerun the old handles or no-op push the leaf merely to pick up central changes.

Strix catalog diversity and CO runtime failover remain distinct: #1939 closes the account-selection bias, while contextual-orchestrator#1049 is still the runtime failover owner for the observed HTTP-500 specimen until its success/exhaustion contract is integrated and released. Keep #35 source stable until owner-plane prerequisites can produce fresh authenticated current-head evidence.

[seonghobae]

2026-09-06 fresh central-owner evidence strengthens the existing #1929 blocker without changing this ConceptWeave head. Post-#1932 runtime logs now directly show the effective dispatch allowlist at execution time: ALLOWED_DISPATCH_ACTOR=github-actions[bot], while app-token dispatches arrive as actor=opencode-agent[bot] sender=opencode-agent[bot]. The latest owner census reports 83/83 completed OpenCode Review Dispatch runs since 2026-09-05T17:00Z failed; opened specimens 33997789163 and 33997714687 both terminate in validate-pr-metadata on that exact authorization rejection. This upgrades the earlier consumer-side inference to direct runtime evidence that the live setting is still single-valued after the comma-list parser repair.

Keep #35@a31ae0c2df920f2794f7ddb456795b04797ab472 unchanged. A consumer no-op push or replay of an old failed handle cannot repair this owner setting. Acceptance remains owner-side reconciliation of OPENCODE_REPOSITORY_DISPATCH_ACTOR to exactly github-actions[bot],opencode-agent[bot] while preserving actor==sender and live repository/PR/head checks, followed by a newly emitted current-workflow dispatch that reaches substantive OpenCode/CodeQL work and produces a terminal authenticated verdict. Existing #35 CodeQL/OpenCode failures remain historical failures, not GREEN.