Skip to content

Latest commit

 

History

History
63 lines (43 loc) · 1.66 KB

File metadata and controls

63 lines (43 loc) · 1.66 KB

Contributing to GuardMesh

GuardMesh is intentionally small and focused. Contributions are welcome when they preserve that clarity.

Working principles

  • Keep the alpha narrow and credible.
  • Prefer explicit, inspectable behavior over clever abstractions.
  • Add the smallest surface area that solves a real problem.
  • Avoid turning GuardMesh into a full platform, control plane, or enterprise policy suite.

Local workflow

npm install
npm run check

npm run check is the main contributor gate. It runs:

  • build
  • unit tests
  • policy-pack linting
  • example-pack expectation tests

When changing behavior

If you change evaluation semantics, validation, parsing, or linting:

  • update or add tests in tests/
  • update the affected example pack expectations
  • update docs/policy-spec.md if the artifact format changes
  • update README.md if the CLI or programmatic API changes

Policy pack guidance

Example packs act as both demos and regression fixtures.

  • Keep them realistic and easy to read.
  • Prefer a few good examples over many redundant ones.
  • Add decision.expected.json for every runnable pack.
  • Use _shared/ only for reusable base files, not runnable packs.

Pull requests

Good PRs usually include:

  • a concise problem statement
  • the smallest coherent implementation
  • tests or expectations covering the change
  • any necessary documentation updates

Scope guardrails

Please avoid introducing:

  • databases
  • dashboards
  • long-running control-plane services
  • speculative enterprise features
  • broad DSL complexity without a clear alpha use case

If a change is valuable but expands scope, prefer landing a simpler stepping stone first.