chore(facts): waive a disclosure false positive on the troubleshooting env-var reference

[yakimoto]

The new disclosure gate (wave-av/wave-context#157) flags an environment-variable name appearing near a state verb, because that pattern is how deployed configuration state leaks into published content.

Here it is a false positive, and worth recording rather than silencing: the README's troubleshooting section tells the reader to check their own environment. The variable belongs to the person installing the MCP server; it says nothing about any WAVE deployment.

Waivers are scoped to rule and match together, so this excuses exactly this identifier and cannot quietly cover a genuine deployed value added later. The finding stays printed on every run — only the exit code ignores it, so the exception cannot outlive its justification unnoticed.

Unrelated, and not addressed here

This repo already fails the policy gate on a pre-existing disallowed-url finding — an npm link outside the @wave-av scope — which predates this change and this PR does not touch. Flagging it so it is not mistaken for fallout from the new gate.

---

---

Note

Low Risk
Config-only changes to waiver metadata and description; no application or security logic is modified.

Overview
Updates .wave/repo.json so WAVE facts/disclosure gates can pass with documented exceptions.

Adds a description string for the MCP server package metadata. Introduces policyWaivers for www.npmjs.com/package/@anthropic-ai so README links to the Claude Agent SDK install package are allowed without tripping disallowed-url rules. Adds disclosureWaivers for rule config-state with match WAVE_API_KEY, documenting that troubleshooting’s echo $WAVE_API_KEY refers to the installer’s env, not deployed WAVE config.

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

Note

Waive WAVE_API_KEY disclosure false positive in WAVE repo scan config

Adds a disclosureWaivers entry in repo.json to suppress a false positive triggered by the WAVE_API_KEY environment variable reference used in troubleshooting docs. Also adds a policyWaivers entry for the @anthropic-ai npm package path and a project description string.

^{Macroscope summarized d8672f7.}

[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_7972715e-2a59-4988-a6f4-a4a35461e615)

[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: 38 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: 5dbf099c-ae74-4d37-8df5-bb983a714ab7

📥 Commits

Reviewing files that changed from the base of the PR and between 8411936 and d8672f7.

📒 Files selected for processing (1)

• .wave/repo.json

---

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

[devin-ai-integration]

Devin Review found 1 potential issue.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

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

[qodo-code-review]

PR Summary by Qodo

Waive disclosure gate false positive for README troubleshooting env var

⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Add a narrowly-scoped disclosure waiver for config-state matching WAVE_API_KEY.
• Document why this match is a false positive (reader-owned env var in troubleshooting).
• Keep the finding visible while preventing it from failing the policy gate exit code.

Diagram

graph TD
  G["Disclosure policy gate"] --> R["README.md content"] --> D{"Waiver match?"} --> X["Fail build"]
  G --> F[".wave/repo.json"] --> W["disclosureWaivers"] --> D
  D --> P["Pass (exit 0)"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Rewrite troubleshooting docs to avoid the env-var identifier

• ➕ Eliminates the triggering pattern without policy exceptions
• ➕ Keeps policy signal-to-noise high by avoiding waivers
• ➖ Degrades troubleshooting clarity for users
• ➖ Does not address other legitimate mentions of required env vars in docs

2. Fix/tune the disclosure rule upstream (heuristic improvement)

• ➕ Reduces false positives across all repos using the gate
• ➕ Avoids accumulating repo-specific waivers over time
• ➖ Higher effort and longer lead time than a repo-local waiver
• ➖ May still require waivers for edge cases even after tuning

3. Add a more specific suppression mechanism (e.g., per-file/section suppression)

• ➕ More granular than rule+match when the same token is used legitimately elsewhere
• ➕ Can keep the gate strict while allowing targeted documentation patterns
• ➖ Adds complexity to the policy system and its configuration model
• ➖ Requires tooling/support work beyond this repo

Recommendation: The current approach (rule+match-scoped waiver with an explicit reason) is the best tradeoff here: it preserves clear user-facing troubleshooting guidance, prevents this known false positive from failing CI, and remains narrowly bounded so it can’t silently excuse future genuine disclosure regressions.

Files changed (1) +7 / -0

Other (1) +7 / -0

repo.jsonAdd disclosure waiver for 'config-state'/'WAVE_API_KEY' false positive +7/-0

Add disclosure waiver for 'config-state'/'WAVE_API_KEY' false positive

• Introduces a 'disclosureWaivers' section that waives the 'config-state' rule when matching 'WAVE_API_KEY'. Includes a detailed rationale explaining the reference is user-owned troubleshooting guidance ('echo $WAVE_API_KEY') rather than deployed WAVE configuration state.

.wave/repo.json

[qodo-code-review]

Qodo Fixer

No findings are available for this PR yet. Findings appear here once Qodo has reviewed the PR.

[macroscopeapp]

Approvability

Verdict: Needs human review

Unable to check for correctness in d8672f7. Unresolved review comments raise substantive concerns that the disclosureWaivers match for WAVE_API_KEY may be broader than intended, potentially silently disabling disclosure checks for all mentions of the token rather than just the troubleshooting command. Narrowing the match scope as suggested would reduce latent risk.

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

[cubic-dev-ai]

All reported issues were addressed across 1 file

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[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_ced9f66c-c50f-42f1-b612-55c456671cd0)