The repo moved to npm workspaces and CI followed the core package: there is a
job for typecheck, test, build, verify-dist and pack across three node
versions. Nothing runs the CLI's suite — roughly 2470 tests, including the 29
provider bridge suites that byte-compare against goldens captured before the
extraction. Issue #809 says every phase PR passes a byte-identical parity gate;
until now nothing enforced it.
Two things stood in the way. The CLI's test script was `vitest`, which is watch
mode — in CI that hangs a runner instead of failing. And the root test script
forwarded only to the CLI workspace, so core's guardrail suite never ran from
the command a contributor reaches for, while the CLI half of it could not run
from a clean checkout at all: core's exports resolve to dist, which is
gitignored.
The root script now builds core before running either suite. That costs a
build on every local run, which is a real annoyance, but the alternative is a
script that only works if you happen to have built core earlier.
The CLI job runs the suite on two node lines: the engines floor (22.13.x) and
24.x. The second leg is not matrix sprawl — the zed bridge parity suite seeds
its fixture with zlib's zstd, which only landed in 22.15, so a floor-only job
would silently skip the byte-compare gate this job exists to run and still go
green. The floor leg keeps the >=22.13 promise enforced; the 24.x leg makes
the parity gate actually execute. The job carries a 15-minute timeout —
measured wall time for the whole suite is ~2 minutes — so a hung run cannot
burn a runner for the default six hours, and the workspace-versions check runs
before npm ci: it only reads the three manifests and the lockfile, so a drift
fails in a second instead of after a full install.
The prototype-pollution rule has never fired. Its `paths.include` named the
pre-workspace layout (`/src/providers/*.ts`, `/src/parser.ts`) while the job
scans `packages/cli/src/...`, so the rule selected no files and the step was
green unconditionally.
Verified before and after: with the old rule and the old scan targets a
planted bracket-assign under packages/cli/src/providers/ reports 0 findings;
with this change the same violation is reported at the right file and line,
and the real tree scans 184 files clean.
Also brings packages/core/src/providers/** into scope. Provider decoding moved
there in the extraction, so that is where records from untrusted session logs
are now turned into maps — precisely what the rule exists to guard.
Two guard-rails so the step cannot silently go vacuous again:
- The step now fails when the scan selected no files. semgrep's --json
`paths.scanned` reflects what the rule actually selected, not the raw scan
targets (verified: with the include paths broken but the targets intact,
scanned drops to 0 while the step still exits 0). A low-water mark was
considered and rejected as brittle: the provider count is a moving target
by design and CI installs semgrep unpinned, so a magic number would need
constant bumping and would decay back into vacuity.
- The CLI providers glob is now recursive (`**/*.ts`) like core's. The
directory is flat today, but a future nested provider directory would be
scanned by CI and then silently excluded by the rule; a planted violation
under providers/nested/ is now reported. The narrow whitelist is
deliberate and unchanged in spirit: unrelated maps elsewhere in the tree
stay out of scope.
The build is `tsup && tsc`. tsup runs with clean:true, so it wipes dist and
writes JavaScript; if tsc then fails, dist holds .js with no declarations. The
build exits non-zero, but packages/core declared no prepublishOnly, so nothing
rebuilt at publish time and a later npm publish would ship it.
Reproduced: remove the declarations from a copy of dist and npm pack --dry-run
still succeeds, with all 41 exports subpaths pointing at files absent from the
tarball. npm pack was never the guard.
Adds prepublishOnly (build then verify) and scripts/verify-dist.mjs, which
asserts every exports target exists. CI runs verify-dist as well, so the guard
is exercised on every push rather than only on the rare publish.
The installer now downloads and verifies a .sha256 companion file
before extracting and launching the menubar app. Build script and
CI workflow generate the checksum alongside the zip. Adds SECURITY.md
with reporting instructions.
Addresses #215.
Adds pr-number input and workflow_dispatch trigger so existing open PRs
can be scanned without waiting for a new push. Leave pr-number empty to
loop all open PRs; supply a number to rescan one.
Runs on every PR open/reopen/synchronize against getagentseal/firstlook
and fails the check when the author's score is 'unknown' (new or
untracked accounts). Skips bot accounts so dependabot and renovate pass
through.
This screens the same drive-by pattern that landed in PR #118 (octo-patch,
fresh automation account) without requiring a manual tier check on every
submission.
Three consecutive failed publish attempts on a live repo are not
acceptable. Reverting to manual `npm publish` from the laptop, which
has always worked. OIDC can be revisited later in a staging
environment, not on the production package.
Node 22 on GitHub's hosted runners currently pins to a broken npm
10.9.7 whose internal `promise-retry` module is missing from the
toolcache (runner-images#13883, nodejs/node#62430). Self-upgrading
via `npm install -g npm@latest` crashes before the install can run,
because `@npmcli/arborist` cannot start without that module.
Node 24 LTS bundles npm 11.x natively, which supports OIDC trusted
publishing out of the box (minimum is 11.5.1, per npm docs). Bumping
the runtime lets us delete the fragile upgrade step entirely.
Test: tag `v0.7.4-rc.2` after merge to validate the flow publishes
successfully with provenance.
Node 22 ships with npm 10.x, which does not know how to exchange the
GitHub OIDC id-token for a short-lived npm token. Without this upgrade,
the publish step silently falls back to the empty NODE_AUTH_TOKEN that
setup-node writes to .npmrc, and the registry returns 404.
First test publish (v0.7.4-rc.0) failed at exactly this point, even
though provenance signing via sigstore succeeded, confirming the OIDC
handshake with GitHub was fine and only the npm-side auth was broken.
Fix: `npm install -g npm@latest` before the publish step. Adds ~5s to
runtime.
New GitHub Actions check that scans every PR commit for
`Co-authored-by: ... claude ...` or `... anthropic ...` trailers and
fails the PR with a clear remediation message if found. Contributors
can still use AI tools; the trailer attribution must be removed before
the PR is eligible to merge, consistent with the project contributor
guidelines.
The workflow scans only commits introduced by the PR
(base.sha..head.sha), so existing history is untouched.
Triggers on v* tag push or manual dispatch. Builds, tests, then publishes
codeburn to npm with provenance attestation. Uses OIDC so no NPM_TOKEN is
stored in repo secrets. The npm-publish GitHub Environment gates the
publish step behind a required reviewer, so every release needs explicit
human approval before it reaches the registry.
Tag/package version mismatch fails fast before any build work. Tests run
before publish to prevent shipping a broken release.
Removes references to future signing decisions, dollar amounts, and
star thresholds from the menubar README, the CHANGELOG, the release
workflow (its YAML comments and the auto-generated release body), and
the packaging script. The technical description stays; the 'we are
not paying for X right now' framing is out.
Interactive TUI dashboard for Claude Code token observability.
13-category task classifier, per-project/model/tool breakdowns,
gradient bar charts, SwiftBar menu bar widget, CSV/JSON export.
