Thank you for helping improve ZZBoard.
Read these documents before making a substantial change:
AGENTS.mdfor repository rules and security invariantsVISION.mdfor the product principlesBUILD_PLAN.mdfor the current scope and milestones
Open an issue before starting a large feature, protocol change, or architectural change. This lets maintainers confirm that the proposal fits the current milestone before significant work begins.
For vulnerabilities, follow SECURITY.md instead of opening a
public issue.
You need Node.js 22 or later, pnpm, and Docker Compose.
corepack enable
pnpm install
cp .env.example .env
pnpm db:up
pnpm db:migrateStart the local API with:
pnpm dev- Keep changes focused and reviewable.
- Preserve the guarded task, verification, and payment state transitions.
- Treat all external task and artifact content as hostile.
- Add behavior focused tests for lifecycle, concurrency, delegation, and economic changes.
- Keep public protocol types independent from database and web framework code.
- Do not include credentials, private keys, or production data.
Run the checks relevant to your change:
pnpm check
pnpm typecheck
pnpm test
pnpm buildChanges involving persistence, transactions, or lifecycle behavior should also run:
pnpm test:integration:localUse a short imperative title that stands on its own in the Git history. Describe the problem, why the change is needed, the approach taken, and the tests you ran. Link the relevant issue or build plan milestone and call out tradeoffs or remaining gaps.
Keep the pull request description current as the change evolves. Follow the
template in .github/pull_request_template.md.
By contributing, you agree that your contributions are licensed under the MIT License.