Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
48 lines (34 loc) · 2 KB

CONTRIBUTING.md

File metadata and controls

48 lines (34 loc) · 2 KB

Contributing

Development approach

  • Work milestone-first: implement only the scoped behavior for the current milestone.
  • Keep pull requests focused; avoid speculative feature branches folded into one PR.
  • Prefer small, mergeable increments over broad framework design.

Testing expectations

  • Behavior changes require tests.

  • Run .NET build/test checks locally before opening a PR.

  • Prefer the automation-friendly repo entrypoint:

    export PATH="$HOME/.dotnet:$PATH"
./scripts/test-all.sh

  • The default script currently runs the full Firmament and Server suites plus Aetheris.Kernel.Core.Tests with Category!=SlowCorpus in a deterministic order. Use direct dotnet test ...csproj commands when you need broader or more targeted coverage.

  • If you need a narrower repro, run the individual test projects directly:

    export PATH="$HOME/.dotnet:$PATH"
dotnet test Aetheris.Kernel.Firmament.Tests/Aetheris.Kernel.Firmament.Tests.csproj --logger "console;verbosity=minimal"
dotnet test Aetheris.Server.Tests/Aetheris.Server.Tests.csproj --logger "console;verbosity=minimal"
dotnet test Aetheris.Kernel.Core.Tests/Aetheris.Kernel.Core.Tests.csproj --logger "console;verbosity=minimal"

  • Use Aetheris.slnx as the canonical solution file. Default automation targets net10.0 only. Legacy Firmament V1 and FrictionLab tests are opt-in with AETHERIS_RUN_LEGACY_TESTS=1 or ./scripts/test-legacy.sh; see docs/build-test-policy-net10-and-legacy-v1.md.

Frontend/display PR boundary checklist

Frontend/display PRs must state whether they change:

  • STEP import/export semantics;
  • BRep topology;
  • Firmament V2 lowering;
  • AIR lowering;
  • CIR authority;
  • DisplayIR server authority;
  • frontend rendering only.

Kernel discipline

  • Do not introduce ad hoc epsilon constants; use ToleranceContext + ToleranceMath and follow docs/numerics-policy.md.
  • Favor diagnostic/result-oriented kernel operations over exceptions for expected operation outcomes (future-facing rule).