ci: vendor governance-enforce — this repo was never in the A_BLOCK ruleset

[yakimoto]

Adds the governance-enforce A_BLOCK gate (secrets / hardcoded-paths, diff-scoped) to this repo. Part of claude-workstation#1624 E4 T4.9a, following the wave-av/cli#20 pilot.

Why this repo had no secrets scan

The org ruleset governance-a-block-enforce (17901847) requires an enforce check across the fleet. Its scope is an explicit include list of 112 hand-maintained repository names — and every one of them matches wave-*.

The 16 public repos absent from that list are exactly the 16 not named wave-*: .github, adk, api-spec, cli, companion-module-wave, create-wave-app, crest-console, dispatch-edge, examples, mcp-server, obs-wave-plugin, sdk, sdk-python, sdks, vmix-wave-integration, workflow-sdk.

Read the intersection: the repos that publish our npm packages are precisely the repos running with no A_BLOCK secrets scan. Nobody excluded them. A naming convention silently became a security boundary, and it drew the line in the worst possible place.

Why the workflow lands before the ruleset entry

Adding a repo to a required_status_checks ruleset before it emits that check is a permanent deadlock — a required check that never reports can never go green, and every PR on the repo becomes unmergeable. So the order is: vendor the workflow, observe it green, then extend the list. Doing it the intuitive way round would have bricked all sixteen.

This PR is also its own liveness drill. The workflow triggers on pull_request, so it runs on the PR that adds it. If enforce reports green here, the vendored shape works in this repo. If it does not, nothing was required and nothing is blocked — which is the point of this ordering.

Proven before fan-out, not assumed

@wave-av/governance is an internal-visibility package owned by claude-workstation, so whether a public repo's GITHUB_TOKEN can read it was the one real assumption. Rather than fan out on the inference, it was piloted on a single repo first:

wave-av/cli#20 — workflow run 31011943790, conclusion success.

That is the receipt this PR rides on. The shape is copied verbatim from wave-av/wave-moq-edge (public, 12/12 green), which matters because auto-approve.yml fails silently on every public repo — it calls a reusable workflow in the private wave-foundation, and a public repo cannot do that (parse-time failure, zero jobs, no annotation). This workflow calls nothing cross-repo, so that trap does not apply.

Security properties, unchanged from the source:

• actions SHA-pinned (actions/checkout@df4cb1c, actions/setup-node@48b55a0)
• persist-credentials: false on checkout
• least privilege: contents: read + packages: read
• isolated install into RUNNER_TEMP, --no-save, so nothing touches this repo's dependency tree
• the .npmrc is written with a literal ${NODE_AUTH_TOKEN} (single-quoted printf) which npm expands at run time — no secret value is ever written to disk or a log
• both ${{ }} inputs (base.sha, event.before) are routed through env: and read as "$VAR", never interpolated into the script body

Diff-scoped by design: it blocks new violations without failing on legacy debt.

Refs wave-av/claude-workstation#1624.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.}

---

Note

Add governance enforcement workflow to scan diffs on PRs and pushes to main

Adds governance-enforce.yml, which runs @wave-av/governance@0.4.6 on pull requests, merge groups, and pushes to main/master. The enforcer scans only changed files using a computed diff base; if no valid base is found, it falls back to the empty tree and scans the full repository. Push and merge group runs are not cancelable to ensure no committed ranges are skipped.

^{Macroscope summarized b56c93d.}

---

Note

Low Risk
CI-only addition with least-privilege permissions and no application or runtime code changes; main operational risk is workflow misconfiguration before the ruleset is enabled, which the PR explicitly gates on a green run.

Overview
Adds .github/workflows/governance-enforce.yml, bringing this repo into the org A_BLOCK fan-out (secrets, Doppler policy, hardcoded paths) via @wave-av/governance on PRs and pushes to main/master. The job installs @wave-av/governance@0.4.6 in an isolated temp dir, runs enforce.mjs against the PR/push diff, and is intended to go green here before the repo is added to the governance-a-block-enforce ruleset.

The vendored workflow includes five hardening fixes from the org rollout: registry token scoped only to the npm install step, --ignore-scripts, an exact package pin (avoiding a version that could report pass with zero files scanned), push concurrency so cancelled push runs do not leave commits un-scanned, and a fail-closed diff base (empty tree full scan when no base SHA resolves, instead of diffing HEAD against itself).

^{Reviewed by Cursor Bugbot for commit 43766c3. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_a78470ea-a4a7-4e3d-970a-bcca079bb509)

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 44 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

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: ASSERTIVE

Plan: Pro Plus

Run ID: 47ca449a-d935-4499-81fa-e29dfa4dceca

📥 Commits

Reviewing files that changed from the base of the PR and between 8c55aee and b56c93d.

📒 Files selected for processing (1)

• .github/workflows/governance-enforce.yml

---

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

[qodo-code-review]

PR Summary by Qodo

CI: add diff-scoped governance-enforce A_BLOCK gate (secrets + hardcoded paths)

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Add a GitHub Actions workflow that enforces A_BLOCK governance checks on PR diffs.
• Install and run @wave-av/governance in an isolated temp directory via GitHub Packages.
• Publish an enforce status check for org ruleset compatibility without merge deadlocks.

Diagram

graph TD
  A([GitHub event]) -->|"pull_request / push"| B["governance-enforce workflow"] --> C["checkout (full history)"] --> D["setup-node 22"] --> E["npm install @wave-av/governance"] --> F["compute BASE SHA"] --> G["run enforce.mjs --changed BASE"] --> H(["Status check: enforce"])
  subgraph Legend
    direction LR
    _evt([Event]) ~~~ _wf["Workflow/step"] ~~~ _chk(["Status check"])
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin an exact @wave-av/governance version

• ➕ Fully reproducible enforcement behavior across runs
• ➕ Avoids surprise changes from new minor releases under caret range
• ➖ Requires manual bump PRs when governance rules evolve
• ➖ Slightly slower rollout of urgent rule fixes

2. Publish a dedicated GitHub Action for governance enforcement

• ➕ Simplifies workflow YAML (no custom npm install + path wiring)
• ➕ Can encapsulate base-SHA resolution and reporting consistently across repos
• ➖ Additional artifact to maintain and version
• ➖ Still needs GitHub Packages access strategy for public repos

Recommendation: The current approach is appropriate for safe fan-out: it avoids cross-repo reusable-workflow pitfalls in public repos, keeps permissions minimal, and emits the enforce check expected by the ruleset. Consider pinning @wave-av/governance to an exact version (or using a lockfile-like mechanism) if deterministic enforcement is more important than automatic minor updates.

Files changed (1) +59 / -0

Other (1) +59 / -0

governance-enforce.ymlAdd A_BLOCK governance-enforce CI gate (diff-scoped) +59/-0

Add A_BLOCK governance-enforce CI gate (diff-scoped)

• Introduces a GitHub Actions workflow that runs on pull requests and mainline pushes to enforce secrets and hardcoded-path rules only on changed files. The workflow installs @wave-av/governance from GitHub Packages in an isolated temp directory, computes an appropriate base SHA for diffing, and runs the enforcer to produce the 'enforce' status check.

.github/workflows/governance-enforce.yml

[macroscopeapp]

Approvability

Verdict: Needs human review

Unable to check for correctness in b56c93d. New CI workflow for security enforcement (secrets scanning). One open comment raises a valid technical question about whether the empty-tree fallback works correctly with the governance package. Given this is security infrastructure, human verification of that edge case is warranted.

^{You can customize Macroscope's approvability policy. Learn more.}

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Unpinned governance install ✓ Resolved 🐞 Bug ⛨ Security

Description

The workflow installs @wave-av/governance using a caret range (^0.4.4), so the gate’s behavior can
change (or break) without any PR in this repo. This reduces determinism for a required security
check and increases the runtime supply-chain risk surface.

Code

.github/workflows/governance-enforce.yml[R47-48]

+          printf '@wave-av:registry=https://npm.pkg.github.com\n//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}\n' > .npmrc
+          npm install @wave-av/governance@^0.4.4 --no-save --no-audit --no-fund

Evidence

The workflow currently installs the enforcer via a semver range, meaning future publishes can change
what runs in CI without any repo change. This repo’s existing public-repo-guard workflow explicitly
documents a preference for deterministic, reviewable scanning and version pinning + integrity
verification, highlighting the mismatch for a security gate.

.github/workflows/governance-enforce.yml[44-49]
.github/workflows/public-repo-guard.yml[9-15]
.github/workflows/public-repo-guard.yml[47-51]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`npm install @wave-av/governance@^0.4.4` allows dependency drift over time; for a required security gate this means policy can change without review in this repository.

## Issue Context
This workflow is intended to be an enforcement gate; other gates in this repo emphasize determinism and pinning.

## Fix Focus Areas
- .github/workflows/governance-enforce.yml[47-48]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. No explicit job timeout ✓ Resolved 🐞 Bug ☼ Reliability

Description

The new enforce job does not set timeout-minutes, so it can run until GitHub Actions’ default job
limit (potentially hours) if npm install or the enforcer hangs. This can significantly delay a
required check’s feedback loop and consume runner capacity longer than necessary.

Code

.github/workflows/governance-enforce.yml[R31-35]

+jobs:
+  enforce:
+    runs-on: ubuntu-latest
+    env:
+      NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Evidence

The new workflow defines the enforce job without timeout-minutes. In this repo, the lint
workflow uses an explicit job timeout, indicating an established practice to bound CI runtime.

.github/workflows/governance-enforce.yml[31-36]
.github/workflows/lint.yml[12-16]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `enforce` job lacks an explicit `timeout-minutes`, so failures that hang (network stall, npm registry issues, etc.) can run until the platform default limit.

## Issue Context
Other CI jobs in this repo set explicit timeouts.

## Fix Focus Areas
- .github/workflows/governance-enforce.yml[31-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context used

✅ Compliance rules (platform): 3 rules

Review mode: ⚖️ Balanced: This adds a security-sensitive CI enforcement workflow that installs and executes a package, handles credentials and diff-base selection, and affects repository governance; one focused hunk is not enough to justify extended, nor is it low-risk enough for lite.

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[qodo-code-review]

Qodo Fixer

✅ Merged (0) · ☑ Fixed (0)

Process

• No fixes were applied (no_fixes_applied)

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_6d3700c5-5a7c-4079-b1b6-7dbe9524a948)

[macroscopeapp]

🟠 High workflows/governance-enforce.yml:80

When github.event.before is missing or unreachable on a push event, the fallback resolves BASE to HEAD~1, so only the single latest commit is scanned. A force-push or newly-created branch can introduce many commits, and all files added or changed in earlier commits are omitted from the diff and bypass the secrets/path gate. When no push base is resolvable, the base should fall through to the empty-tree scan (as the final fallback already does) instead of stopping at HEAD~1.

-            BASE="$(git rev-parse --verify --quiet 'HEAD~1' || true)"
+            : # no resolvable push base — fall through to the empty-tree scan below

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @.github/workflows/governance-enforce.yml around lines 80-801940:

When `github.event.before` is missing or unreachable on a push event, the fallback resolves `BASE` to `HEAD~1`, so only the single latest commit is scanned. A force-push or newly-created branch can introduce many commits, and all files added or changed in earlier commits are omitted from the diff and bypass the secrets/path gate. When no push base is resolvable, the base should fall through to the empty-tree scan (as the final fallback already does) instead of stopping at `HEAD~1`.

Evidence trail:
`.github/workflows/governance-enforce.yml:3-5, 42-45, 68-93` at `REVIEWED_COMMIT`; `git_diff MERGE_BASE REVIEWED_COMMIT -- .github/workflows/governance-enforce.yml`.

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🔍 Empty-tree fallback assumes the enforcer diffs with a two-dot range

The fallback sets BASE to the empty-tree object id and passes it to --changed. That only works if the enforcer runs a two-dot diff (git diff <base> HEAD); a three-dot range (git diff <base>...HEAD), the more common CI shape, requires a commit on the left-hand side and will abort with fatal: not a commit. Note the surrounding guard (git cat-file -e "$BASE^{commit}") explicitly checks for commit-ness for the normal path, then the fallback deliberately supplies a non-commit. Since 0.4.6 is documented here as failing closed on git errors, the worst case is a confusing red job rather than a silent pass, but it would be worth confirming the enforcer's diff invocation accepts a tree id.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[blacksmith-sh]

Verified against the @wave-av/governance@0.4.6 source: both enforce.mjs and enforce-ramp.mjs build their diff via changedArgs() in lib/git-files.mjs, which emits the two-argument form git diff <flags> <base> HEAD and documents that it was chosen specifically because the CI empty-tree fallback supplies a tree object that A...B would reject. The lister also fails closed on git errors, so the fallback path is designed-for, not assumed.