KasGraph is infrastructure, not a product. The bar for changes is correctness, determinism, and forward-compatibility with KIP-20 / KIP-16 / vProgs. The structure for getting there is laid out per-phase in PLAN.md.
- Read
PLAN.mdfirst. Every PR slots into a phase. If your change doesn't fit a phase, open an issue first so we can figure out where it belongs (or extend the plan). - Read one fully-landed component before extending it.
kasgraph-poiis the smallest, most complete example today — real logic, real tests, conventions other crates will follow. - Determinism is non-negotiable. Indexers that produce different state from the same chain are bugs. POI hashes are the regression gate.
git clone https://github.com/trillskillz/KasGraph && cd KasGraph
npm install
npm run verify # tsc -b + vitest + cargo test --workspaceCI runs the same commands on every push and PR.
- Drop into
docs/references/<TOPIC>.md. - Cite the source-of-truth upstream (rusty-kaspa source, KIP text, The Graph docs, etc.) by URL + commit SHA where stable.
- Document at least one example query / message / data shape.
- Cross-link from
STATUS.md"What's done" once landed.
For each crate change:
- New surface lives in
src/<module>.rswith a doc-comment header citing the relevant PLAN.md task (e.g. "PerPLAN.mdPhase 2.4"). - Public types get
#[derive(Debug)]minimally. AddCloneonly when needed; addSerialize/Deserializeonly when crossing a wire boundary. - Errors are
thiserror-derived enums per crate. Noanyhowin library crates. - Cargo unit tests live inline (
#[cfg(test)] mod tests). Integration tests live under each crate'stests/directory. - Update the crate's
Cargo.tomldescription if the responsibilities change.
- GraphQL changes must update
@kasgraph/apiand the resolver generation rules in lockstep. - MCP changes must update both
mcp/src/index.ts(typed tool list) ANDtests/sdk.test.ts"exposes the canonical MCP tool set" assertion. The test fails on drift on purpose. - KasStream changes require backpressure + cancellation tests; latency-sensitive consumers depend on this.
- Every new CLI command needs a vitest test in
tests/covering stdout, exit code, and error paths. @kasgraph/sdkis the public API. Breaking changes require a version bump inpackage.jsonAND a CHANGELOG.md entry.
- Live under
examples/<name>/. - Must include:
subgraph.yaml,schema.graphql,src/mapping.ts, aREADME.mddocumenting what queries the subgraph supports. - Reference subgraphs are the dogfooding surface — if your subgraph can't run on
kasgraph-node, neither can a user's.
<type>(<scope>): <one-line summary>
<blank line>
<body explaining the why, not just the what>
Types:
feat— new crate, new surface, new subgraph.fix— bugfix without API change.docs— docs only (PLAN.md, STATUS.md, reference docs, READMEs).test— test-only.ci— CI workflow / drift gates.chore— workspace plumbing.refactor— internal reshaping; no behavior change.
For commit bodies, the diff shows the what. The body should say why this design and what's hard about it.
- CI green: TS typecheck + vitest + cargo build + cargo test.
- For new crates: a unit test that exercises the public surface, not just
assert!(true). - For new RPC / Postgres / WASM surfaces: an integration test against a fixture, not just unit tests.
- Update
STATUS.mdif your change shifts a phase status. - Update
NEXT_SESSION.mdif your change clears or rephrases queued work.
By contributing, you agree your work is licensed under the MIT license that covers the rest of the repository.