Requires Go 1.26+. No external services needed.
task build
task validate- Open an issue or PR describing the change and why the current contract can't express what you need.
- A non-breaking addition (a new optional field) can land in
v1directly, with avalid/fixture exercising it. - A breaking change (removing or narrowing a field, changing a type) needs
a new
schemas/v2/tree (see the README's "Layout" section), so existing adapters and fireline-core don't break silently. - Every new constraint needs both a
valid/fixture showing correct usage and aninvalid/fixture showing what violates it.
gofmt, go vet, and golangci-lint cover tools/validate; run task lint.
Describe the why, not just the what: the diff already shows what changed.
docs/ is the source of truth for design rationale, trade-offs, and scope
decisions (use AGENTS.md/README.md for a repo with nothing in docs/ yet).
A code comment should point to it, not restate it: // see docs/<file>.md for why.
A doc comment says what a function or type does, in one to three lines. Add local why only for something the code can't already show: an edge case, a library quirk. Never a design decision or scope caveat; that belongs in docs/. Keep it plain: no "X, not Y" framing, no "deliberately," no hedges like "it's worth noting," and no em dashes.