Artifact Pipeline
August 23, 2026 ยท View on GitHub
This file describes how protocol artifacts move from local build output to committed and published surfaces.
Canonical Flow
anchor build
-> local target/ output
-> scripts/sync-anchor-artifacts.mjs
-> artifacts/anchor/*
-> scripts/sync-package-protocol-assets.mjs
-> packages/protocol/src/generated/*
-> scripts/check-mainnet-program-artifacts.mjs (program-id + SHA-256 identity)
-> npm package build / dist
Rules
target/is local build output, not the public contractartifacts/anchor/*is the committed canonical public artifact surfacepackages/protocol/src/generated/*is a derived copy used to publish@tetsuo-ai/protocolscripts/idl/verifier_router.jsonis repo-owned verifier-router support data and belongs in the committed public surface
Commands
After a successful anchor build:
npm run artifacts:refresh
To verify committed artifacts:
npm run artifacts:check # existence/shape check โ passes without a local build
npm run artifacts:check:built # full check against the current build (--require-build)
CI (.github/workflows/idl-drift.yml) builds the program fresh, runs the built
check, and enforces the canary-IDL gate, so main cannot carry a drifting IDL.
Consumer Guidance
Downstream repos should consume released protocol artifacts from:
- a tagged/released artifact set that matches their target cluster, normally the
published
@tetsuo-ai/protocolpackage; or - this repo's committed artifact surface, which now matches the live revision-5 program.
The committed artifacts describe the live 101-instruction revision-5 surface
(deployed 2026-07-22). The previously published @tetsuo-ai/protocol@0.3.0
describes the superseded 99-instruction revision-4 wire; confirm the coordinated
revision-5 package (0.4.0) before consuming from npm.
They should not treat local target/ files or vendored copies in other repos as canonical.