fix(ci): unblock scopeweave central gates (coverage evidence, trivy-fs, Semgrep)

[seonghobae]

Every scopeweave PR is currently blocked by three pre-existing central-gate failures on develop. Each fails on every PR (repo-wide scans / base materialization), so the whole queue is stuck. This PR remediates all three at base.

1. coverage-evidence (OpenCode review) — stray pnpm-lock.yaml

The central materializer (ContextualWisdomLab/.github → scripts/ci/materialize_base_javascript_packages.py) hard-fails (exit 1) when a base pnpm-lock.yaml exists whose sibling package.json does not pin an exact packageManager: pnpm@X.Y.Z. scopeweave is an npm project (server-tests.yml / fuzz.yml use cache: 'npm' + npm ci; package-lock.json is canonical; no workflow/Dockerfile/compose references pnpm), so the committed pnpm-lock.yaml is a vestigial second lockfile that only misleads the materializer into pnpm mode.

Fix: remove pnpm-lock.yaml. The materializer then reports "no pnpm locks" and the sandbox installs via npm ci --ignore-scripts.

2. trivy-fs — real MEDIUM CVE in @hono/node-server

trivy-fs reports GHSA-frvp-7c67-39w9 (security-severity 5.9) — a Windows path-traversal in @hono/node-server < 2.0.5 (encoded %5C decodes to \, bypassing middleware to read protected static files). scopeweave was pinned to 1.19.14.

Fix: bump the existing runtime dependency (not a new one — the two-runtime-deps contract is preserved) to ^2.0.12. @hono/node-server 2.x declares peerDependencies { hono: "^4" }, already satisfied (hono ^4.12.27), and scopeweave only uses the stable serve({ fetch, port }, cb) entry point. Verified locally (Node v22.22.2): npm install → 0 vulnerabilities, npm run test:unit and npm run test:api (which boots the Hono app through serve()) both pass.

3. Semgrep — verified false-positive ReDoS in the MS Project parser

Semgrep blocks on one WARNING: detect-non-literal-regexp at cloud-sync.js:743, inside parseMsProjectXml's tag() helper. This is a verified false positive: the non-literal argument name is only ever a hardcoded literal tag ('UID', 'Name', 'OutlineLevel', ...), never user input, and the [^<]* body is a single linear character-class star (no nested quantifiers) → no catastrophic backtracking, no injection surface.

Fix: a narrow, documented nosemgrep directive on the finding line, with the reasoning in-line. The gate is designed to honor suppressions (it filters SARIF results whose suppressions array is non-empty). tests/unit/msproject.test.mjs still passes.

Why this is safe

No central gate is weakened — the pnpm supply-chain rule and Semgrep engine are untouched; the trivy finding is genuinely remediated, not ignored. All three changes align scopeweave with its own documented toolchain and remove real security debt. Local verification: test:unit + test:api pass, npm install reports 0 vulnerabilities.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SEAGtwNR96cia2djq7XFCo

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 7 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ec68b243-6085-4aff-888a-65def24b2460

📥 Commits

Reviewing files that changed from the base of the PR and between a756b7e and de680cd.

⛔ Files ignored due to path filters (2)

• package-lock.json is excluded by !**/package-lock.json
• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (2)

• cloud-sync.js
• package.json

---

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

[opencode-agent]

Pull request overview

OpenCode cannot approve yet because required coverage evidence did not pass.

Review outcome

1. HIGH .github/workflows/opencode-review.yml:1 - Coverage evidence did not prove required test/docstring evidence

• Problem: The required coverage-evidence job result was failure, so OpenCode cannot establish approval sufficiency for this head.

• Root cause: Automated approval is only valid when the same-head coverage-evidence job proves supported repository test suites passed and configured docstring gates passed or were advisory, or reports not applicable because no supported source files or package manifests exist. Missing, failed, skipped, unavailable, or unsupported-tooling test evidence is a blocker.

• Fix: Install or configure the repository test/docstring evidence tooling when source files or package manifests exist, rerun the current-head coverage-evidence job, and approve only after it reports success with required evidence or explicit no-source not-applicable evidence.

• Regression test: Keep the approval branch checking needs.coverage-evidence.result == success before posting APPROVE, and publish REQUEST_CHANGES when coverage-evidence blocker states such as cancelled, skipped, failed, unsupported-tooling, or below-100 evidence are present.

• Result: REQUEST_CHANGES

• Reason: coverage-evidence result was failure, so required test/docstring evidence was not proven for current head de680cd002392f436362d129d6a64a1c0163ac90.

• Head SHA: de680cd002392f436362d129d6a64a1c0163ac90

• Workflow run: 30501351847

• Workflow attempt: 1

Coverage evidence

Coverage evidence job did not run or did not publish coverage evidence.

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file (4 files)"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file (4 files)"]
  R1 --> V1["required checks"]

Loading

[opencode-agent]

OpenCode Review Overview

• Head SHA: de680cd002392f436362d129d6a64a1c0163ac90
• Workflow run: 30501351847
• Workflow attempt: 1
• Gate result: REQUEST_CHANGES (approval step)

Pull request overview

OpenCode cannot approve yet because required coverage evidence did not pass.

Review outcome

1. HIGH .github/workflows/opencode-review.yml:1 - Coverage evidence did not prove required test/docstring evidence

• Problem: The required coverage-evidence job result was failure, so OpenCode cannot establish approval sufficiency for this head.

• Root cause: Automated approval is only valid when the same-head coverage-evidence job proves supported repository test suites passed and configured docstring gates passed or were advisory, or reports not applicable because no supported source files or package manifests exist. Missing, failed, skipped, unavailable, or unsupported-tooling test evidence is a blocker.

• Fix: Install or configure the repository test/docstring evidence tooling when source files or package manifests exist, rerun the current-head coverage-evidence job, and approve only after it reports success with required evidence or explicit no-source not-applicable evidence.

• Regression test: Keep the approval branch checking needs.coverage-evidence.result == success before posting APPROVE, and publish REQUEST_CHANGES when coverage-evidence blocker states such as cancelled, skipped, failed, unsupported-tooling, or below-100 evidence are present.

• Result: REQUEST_CHANGES

• Reason: coverage-evidence result was failure, so required test/docstring evidence was not proven for current head de680cd002392f436362d129d6a64a1c0163ac90.

• Head SHA: de680cd002392f436362d129d6a64a1c0163ac90

• Workflow run: 30501351847

• Workflow attempt: 1

Coverage evidence

Coverage evidence job did not run or did not publish coverage evidence.

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file (4 files)"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file (4 files)"]
  R1 --> V1["required checks"]

Loading

[seonghobae]

coverage-evidence blocker is a base-fix bootstrap, not a head-side defect

OpenCode's REQUEST_CHANGES on de680cd is driven solely by coverage-evidence: failure. The job log for run 30501351847 shows the failure is at base materialization, before any test runs:

PR_BASE_SHA: a756b7e (develop)   PR_HEAD_SHA: de680cd
##[error]Could not materialize base JavaScript package locks: trusted base
package manifest package.json must declare an exact pnpm packageManager version

scripts/ci/materialize_base_javascript_packages.py reads the base SHA, and develop still contains the stray root pnpm-lock.yaml that this PR removes. So the fix cannot clear its own coverage-evidence until it is on develop — the same base-fix bootstrap that required an admin bypass-merge for the central coverage fixes #642–647 earlier today. Base history is immutable from the PR, so there is no head-side change that makes this pass first.

The three head-side changes are verified locally (Node v22.22.2):

• Removed stray pnpm-lock.yaml — the repo is npm-only (server-tests.yml/fuzz.yml use cache: 'npm' + npm ci; zero pnpm refs anywhere); this is the exact file the base materializer chokes on.
• @hono/node-server → ^2.0.12 (remediates trivy-fs MEDIUM GHSA-frvp-7c67-39w9): npm install → 0 vulnerabilities; npm run test:unit and npm run test:api (boots the Hono app via serve()) both pass.
• nosemgrep on cloud-sync.js:743 for the verified false-positive detect-non-literal-regexp (the arg is only ever a hardcoded literal tag; [^<]* is linear): tests/unit/msproject.test.mjs passes.

Resolution: this needs the same bypass-merge path as #642–647. Once it lands on develop, coverage-evidence materializes cleanly for every scopeweave PR (no stray pnpm lock), and the repo's central gates go green org-wide.

---

Generated by Claude Code

[seonghobae]

Superseded by #379, which carries the same three base-clearing fixes and goes a bit further:

• trivy-fs — same @hono/node-server ^2.0.12 bump (GHSA-frvp-7c67-39w9).
• Semgrep detect-non-literal-regexp — fix(security): bump @hono/node-server to ^2.0.12 (GHSA-frvp-7c67-39w9) #379 removes the dynamic new RegExp(...) in parseMsProjectXml's tag() helper (indexOf slicing with identical semantics) instead of suppressing it with nosemgrep, clearing the finding at source, and adds changed-code regression tests for the three new defensive branches.
• coverage-evidence — same pnpm-lock.yaml removal. Note the root cause has since been narrowed: the base materializer already treats a vestigial pnpm-lock.yaml (npm sibling, no exact packageManager) as npm-owned (fix(review): treat npm project's stray pnpm-lock.yaml as npm, not fail-closed .github#658), and the runtime coverage runner is being brought into agreement in fix(review): activate 3 declared github-models as review fallback candidates .github#651, so this is also fixed centrally for every repo. Removing the stray lock here is the immediate repo-side unblock.

Closing to avoid two competing PRs contending for the same base and the rate-limited reviewer. All work continues on #379.

---

Generated by Claude Code