wn-dev-std is a small installable Python package and the
reference example for development standards.
wn_dev_std.cli.main owns parser construction and dispatch.
wn_dev_std.standards owns public standard data examples.
wn_dev_std.checks owns reusable conformance checks.
Extension profiles include cpp-library,
python-native-wasm, csharp-app,
javascript-web-app, python-js-app,
typescript-web-app, python-ts-app,
rust-app, rust-firmware, and
zephyr-firmware. The C++ profile captures preferred Bazel,
permitted CMake/Ninja, clang-format, clang-tidy, native tests, and ABI
rules. The mixed-mode profile builds on that for Geometer-style packages
that combine Python, Bazel- or CMake-owned C++,
platform wheels, and WASM outputs. The JavaScript profiles capture no-build
browser runtime, checked JS/JSDoc, deterministic JS tests, CSS tokens,
owned Web Components, JS-to-WASM smoke, vendor isolation, browser smoke,
and simple command-verb rules. The TypeScript profiles are the greenfield
browser default and capture strict compiler guardrails, typed public
boundaries, local tsconfig inheritance, package scripts, and migration
exceptions for existing checked-JS ports. The Rust profiles capture Cargo,
rustup, rustfmt, Clippy, rustdoc, Tree-sitter structural hygiene, ratchets,
unsafe policy, polyglot source roots, and embedded firmware metadata such
as target, memory layout, runner, panic, allocator, and hardware signoff.
The Zephyr profile captures west-based
firmware builds, app-owned source signoff, target toolchain notes, and
embedded C/C++ complexity gates.
Projects using this standard use Rack to make validation structure explicit. Rack names strata, lanes, concerns, and dependencies so a developer, CI system, or agent can tell whether a command is a fast edit-loop check, an integration test, or a release-facing gate. That structure avoids hiding critical checks behind one opaque script while still allowing each project to keep simple local commands.
In this repository, the reference Rack suite and signoff strata live under
tests/, with the suite manifest at
tests/rack.toml.
The signoff process is the release-facing layer of that model. Signoff checks are intentionally boring and repeatable: formatting, static analysis, complexity limits, documentation status, contracts, release metadata, and project-specific ratchets. They should fail when new code violates accepted rules, while baselines can make existing debt visible without blocking unrelated work.
Every project needs a signoff gate. In Rack this is normally an
L99_signoff stratum. The contents are profile-specific, but
standard signoff should include measurable checks such as complexity, file
size, function size, formatting, static analysis, docs, contracts, release
metadata, and project-local ratchets. Packages that adopt dev-std
governance should run dev-std audit . as part of that signoff
path.
Rack answers which validation lane is being run and why. Signoff answers whether this change is ready to merge or release. Keeping those ideas separate lets projects grow from a small local workflow into CI without changing the vocabulary reviewers and agents use.