npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

coreartifact

v0.2.0

Published

The local-first evidence ledger for agent-built software: what ran, what it cost, what changed, and what proves it correct.

Readme

Your agent says the tests passed. Prove it.

a local-first evidence ledger for Claude Code sessions — what your agents actually ran, recorded as evidence on your machine. This is coreartifact.

Dashboard: 3 of 5 delegated sessions verified

What you're looking at:

  • Verified — the session has a passing check bound to it: an exit code recorded at execution time as belonging to the session that ran it. Not a summary. Evidence.
  • Failing — the session has bound evidence, and it failed. You know now, not at review.
  • Unverified — the session claims whatever it claims; no evidence either way. This is where all your delegated work lives today.

Quickstart

Requires Node >= 22.13.

npm install -g coreartifact
cd your-repo
cart init

init registers the repo and installs two things: a capture hook that records every Claude Code session in this repo to a local, append-only file, and a skill that tells your agents to record proof of their work as they go. (cart and coreartifact are the same binary — cart is the blessed short form.)

Now delegate something real:

claude -p "fix the flaky retry test, then run the suite"

The session verifies itself: the skill has the agent run its gates through coreartifact, so the passing suite lands as evidence bound to that session — no flags, no ceremony, nothing for you to remember.

cart open

Your session is verified — and you can click into the exact command, output, and exit code that make it so. That's the product: delegation stays cheap, verification becomes a query.

Verify anything yourself

Along the way: cart log lists every captured session; cart show <session-id> is one session in detail.

cart check test -- pnpm test

check runs your command unchanged, records its output and exit code as evidence, and passes the exit code through. Binding is explicit: inside an agent session the skill binds the check to that session; from your own terminal, pass --session <id> to attach it to a session — without a target it records standalone, in the ledger but bound to nothing. Other verbs: cart doctor (what can't currently be derived, and why), cart open --port <n> --no-browser, cart uninstall.

The laws

These are not preferences. They are the product.

  • Nothing leaves your machine. No code, no transcripts, no telemetry by default. The only network call in the product is an explicit opt-in ping, and it carries an install id — never your code.
  • The raw capture is ground truth forever. The ledger is a pure projection: delete it and re-ingest, and you get the same answers.
  • Absence is honest. When a fact can't be verified from captured evidence, it records as ABSENT — with the reason — never fabricated, never silently zero, never guessed.
  • Capture never breaks the host. The capture hook appends payloads verbatim, exits 0, and knows nothing about schemas or versions. Your Claude Code session cannot be broken by it.

Pre-1.0. Interfaces may change without notice and there is no support commitment. Issues are welcome; see CONTRIBUTING.md.

How it works

A Claude Code hook appends every session event, verbatim, to a local spool — an append-only file at .coreartifact/spool.jsonl that is never rewritten. Ingestion (run by log/show or the dashboard) projects the spool into a SQLite ledger: sessions, commands, file touches, test results, checks, cost (derived from a pinned price table and labeled as derived). The dashboard reads the ledger over a local HTTP seam and renders the headline above.

Tested range and platforms

Everything the ledger derives is verified against Claude Code 2.1.208 – 2.1.220 (dated findings in docs/recording-pass.md). Outside that range, capture still records everything; some derived facts may record ABSENT until the range catches up, and cart doctor names which ones and why. Nothing is ever guessed to preserve the appearance of support.

Proven on macOS and Linux (CI runs both). WSL counts as Linux; native Windows is untested (out of scope until a real user asks or a Windows contributor arrives with evidence). On Node 22.x you may see a one-line ExperimentalWarning about node:sqlite on stderr — cosmetic, gone on Node 24.

License

Apache-2.0. See LICENSE and NOTICE.