Four of our tools stand alone. The fifth doesn't, on purpose.

Every tool CorvidLabs has shipped so far was built to stand on its own. You can drop fledge into a repo that has none of the others and get one CLI for the whole lifecycle. You can run spec-sync with nothing else and get specs that fail the build when they drift from the code. augur scores a diff's risk with no API key and no siblings. attest records who reviewed a change into git notes, alone, today. Four tools, four islands, and that was deliberate. I did not want anyone to have to buy the whole set to get value from one.

Then I built atlas, and for the first time I shipped a tool that does not stand alone. That is the interesting part.

Why atlas can't be an island

Atlas renders your specs, your code, and the gap between them as one interactive map: a coverage treemap, a spec-and-code graph, a dependency DAG, a churn-vs-coverage view. To do that it has to read your specs. Not "works better with specs," needs them. Point atlas at a repo with no spec layer and there is nothing to map.

That means atlas has a hard dependency on spec-sync. The other four don't depend on each other at all. This one does. So the question was never "should atlas be standalone or a plugin," it was "where does a tool that requires spec-sync actually belong."

So it's a fledge plugin, not a binary

fledge is already the surface that spec-sync lives on. fledge spec is how you run the contract check; the two are coupled by design. A tool that can't work without spec-sync belongs inside that same surface, not beside it as a fifth thing to install and wire up.

So atlas ships as a fledge plugin:

fledge plugins install CorvidLabs/fledge-plugin-atlas

There is no brew install, no release tag to fetch. As a plugin it inherits fledge's runner, its config, and its CI wiring for free, and it sits next to spec-sync where its dependency already is. The same Rust engine also compiles to WASM, so the browser version maps any public repo with no sign-in, and there is a GitHub Action:

uses: CorvidLabs/fledge-plugin-atlas@v1
with:
  path: .
  output-dir: _site/badges

That renders your coverage as a self-contained SVG badge and publishes it to Pages on every push, so a README badge and the coverage dashboard track your main branch automatically. One tool, three shapes, all off the same core.

The gate, then the map

Here is where standalone-by-default and depends-on-purpose stop being in tension. The four islands turn out to compose into one gate when you want them to: spec-sync says the contract holds, fledge runs the lifecycle, augur says the risk is under threshold, attest records the trust. Contract, lifecycle, risk, trust. That is a single CI gate you can turn on per repo.

Atlas is the map on top of that gate. It is not a gate step, it does not block anything. It takes the result the four produce and makes it visible, to a human skimming a README badge and to an agent reading coverage.json. The gate decides; the map shows. Atlas only has something to show because the other tools ran, which is exactly why it earns its dependency instead of apologizing for it.

The proof is that we run on it

I trust this because we live in it. This site dogfoods the whole toolchain it documents: every pull request runs the fledge verify lane plus the trust gate, and if someone deletes the standing toolchain rules the build fails. The same gate runs across our repos, and atlas maps all of them on one board.

As of early July 2026 that board reads: six repos governed, 98% average spec coverage, 129 specs enforced, 167 review attestations recorded. fledge sits at 99% coverage, spec-sync at 97%, augur and attest at 100%, atlas at 100% of its own 3,988 lines. Those are not numbers I typed into a slide. They are generated by the tools, on our own code, on every push. The apps we are building move faster because the plumbing underneath them is the same plumbing we ship.

Stand alone when you can, compose when you should

If you are building your own tooling, this is the takeaway I would hand you. Build each tool so it can stand alone, because that is what lets someone adopt one without swallowing all of them. But when a tool has a real dependency, don't fight it into false independence. Let it depend, and ship it as a plugin on the spine you already have, not as one more island. The four gates prove each tool is worth something by itself. Atlas proves the set is worth more than the sum.

Map your own repo in the browser at corvidlabs.xyz/atlas, or read how the whole gate wires together at /integrate/.