You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CodeVetter already depends on proven components such as Playwright, Biome, c8, axe-core, MSW, Tree-sitter, and optional ast-grep, but the August 2026 tooling review is mostly an approval ledger rather than an implemented integration ledger. Live repository checks on 2026-08-31 also found CodeQL default setup unconfigured and GitHub secret scanning, push protection, Dependabot alerts, and Dependabot security updates disabled.
The owner wants CodeVetter to gain leverage from external tools instead of rebuilding commodity analysis. The first batch should improve the public repository and produce structured evidence without adding a production dependency, transmitting customer repositories, or allowing an external tool to issue the final CodeVetter verdict.
What
In scope
Connect the free public DeepWiki MCP to the owner's local Codex client as a maintainer navigation aid, and verify it is listed without reading credential-bearing configuration.
Enable eligible GitHub-native security features for the public CodeVetter repository: CodeQL default setup, Dependabot alerts/security updates, secret scanning, and push protection.
Turn the existing Biome installation into a reproducible SARIF-producing check.
Replace or supplement the handwritten tracked-file secret regex with the already-installed Gitleaks scanner, using redaction and machine-readable output.
Add a pinned zizmor GitHub Actions audit for workflow security, with least-privilege permissions and inspectable findings.
Capture before/after receipts and fix only concrete, in-scope findings surfaced by these tools.
Update the tooling documentation so approved, trialled, and currently wired tools are visibly distinct.
Out of scope
No DeepWiki or hosted analysis in the CodeVetter product runtime.
No customer repository upload or hosted verdict dependency.
No StrykerJS, OSV-Scanner, Schemathesis, Apple Containerization, libkrun, Semgrep registry rules, or Trivy product integration in this first batch; those require separately measured trials.
No new production dependency, deployment, release, migration, or automatic remediation.
No claim that enabling tools automatically proves product quality.
Design
External tools remain bounded collectors. Their output may block repository CI or become attributed evidence, but CodeVetter-owned normalization and executable checks remain authoritative.
flowchart LR
A[Public CodeVetter repository] --> B[GitHub security controls]
A --> C[Local and CI collectors]
C --> D[Biome SARIF]
C --> E[Gitleaks SARIF]
C --> F[zizmor SARIF]
B --> G[Reviewable findings]
D --> G
E --> G
F --> G
G --> H[Concrete fixes and enforced gates]
H -. does not replace .-> I[CodeVetter executable verdict authority]
J[DeepWiki MCP] --> K[Maintainer navigation only]
Loading
Affected surfaces are local Codex MCP configuration, GitHub repository security settings, root package scripts, GitHub Actions, Husky secret checks, and canonical tooling documentation. There is no deploy impact; workflow changes run only on repository events.
Specs
Requirement: Separate maintainer tooling from product dependencies
The implementation SHALL permit hosted tools against CodeVetter's public source only where they do not become a runtime dependency or customer-code path.
Scenario: DeepWiki is connected
WHEN a maintainer uses Codex on a public repository
THEN DeepWiki may provide navigation and Q&A
AND its responses are non-authoritative and must not create pass evidence.
The first batch SHALL add no production dependency and SHALL NOT send customer source, manifests, lockfiles, or evidence to a hosted provider.
Scenario: Product runtime executes
WHEN CodeVetter verifies a user repository
THEN none of the new maintainer-only hosted services are invoked.
Tasks
1. Record the clean-worktree baseline, current GitHub security states, installed tool identities, and existing CI/Husky coverage.
2. Connect and verify the public DeepWiki MCP in the local Codex client without inspecting credential-bearing configuration.
3. Enable and verify CodeQL default setup, Dependabot alerts/security updates, secret scanning, and push protection.
4. Add a repository-owned Biome SARIF command and verify its output against the current tree.
5. Integrate Gitleaks with redaction and structured output, preserving deliberate fixtures through explained configuration rather than broad exclusions.
6. Add a commit-SHA-pinned zizmor workflow with least-privilege permissions and run or locally reproduce its first audit.
7. Review and fix concrete findings surfaced by the enabled tools; document unresolved or false-positive cases explicitly.
8. Update third-party tooling documentation to distinguish approved, trialled, wired, and rejected tools; validate docs.
9. Run the smallest focused checks after each task, then the relevant lint/typecheck/tests and diff checks for the completed batch.
10. Record final receipts in this issue and leave StrykerJS, OSV-Scanner, Schemathesis, and container isolation as separate evidence-gated follow-ups.
Why
CodeVetter already depends on proven components such as Playwright, Biome, c8, axe-core, MSW, Tree-sitter, and optional ast-grep, but the August 2026 tooling review is mostly an approval ledger rather than an implemented integration ledger. Live repository checks on 2026-08-31 also found CodeQL default setup unconfigured and GitHub secret scanning, push protection, Dependabot alerts, and Dependabot security updates disabled.
The owner wants CodeVetter to gain leverage from external tools instead of rebuilding commodity analysis. The first batch should improve the public repository and produce structured evidence without adding a production dependency, transmitting customer repositories, or allowing an external tool to issue the final CodeVetter verdict.
What
In scope
Out of scope
Design
External tools remain bounded collectors. Their output may block repository CI or become attributed evidence, but CodeVetter-owned normalization and executable checks remain authoritative.
flowchart LR A[Public CodeVetter repository] --> B[GitHub security controls] A --> C[Local and CI collectors] C --> D[Biome SARIF] C --> E[Gitleaks SARIF] C --> F[zizmor SARIF] B --> G[Reviewable findings] D --> G E --> G F --> G G --> H[Concrete fixes and enforced gates] H -. does not replace .-> I[CodeVetter executable verdict authority] J[DeepWiki MCP] --> K[Maintainer navigation only]Affected surfaces are local Codex MCP configuration, GitHub repository security settings, root package scripts, GitHub Actions, Husky secret checks, and canonical tooling documentation. There is no deploy impact; workflow changes run only on repository events.
Specs
Requirement: Separate maintainer tooling from product dependencies
The implementation SHALL permit hosted tools against CodeVetter's public source only where they do not become a runtime dependency or customer-code path.
Scenario: DeepWiki is connected
Requirement: Enable native public-repository security
The public repository SHALL enable eligible GitHub security controls and record their post-change state.
Scenario: A vulnerable dependency or secret is introduced
Requirement: Produce structured local analysis evidence
Biome, Gitleaks, and zizmor checks SHALL emit deterministic or version-attributed machine-readable output with secrets redacted.
Scenario: A scanner finds no issue
Scenario: A scanner finds an issue
Requirement: Preserve local-first product boundaries
The first batch SHALL add no production dependency and SHALL NOT send customer source, manifests, lockfiles, or evidence to a hosted provider.
Scenario: Product runtime executes
Tasks