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.
Project profiles describe a repository's primary implementation shape. Capabilities apply independently when their boundary exists. TypeSpec is the structural authority for new Wavenumber-owned contracts that cross a process or language boundary. The activity model is the preferred platform-neutral workflow architecture where independently registered units accept typed input and return typed results. Backend integration centralizes protocol mechanics behind semantic feature clients. Lit is the preferred, not required, component library for suitable new TypeScript web applications, paired with an application shell and swappable theme module.
The accepted source contracts are the TypeSpec Contract, Activity Application, Backend Client, and Lit Web Application standards. The browser implementation is evidence for the platform-neutral concepts; it does not make Lit or browser APIs part of the activity kernel.
docs/templates/typespec-contract/ demonstrates a TypeSpec
authority with generated projections and multi-runtime conformance.
docs/templates/web/lit-activity/ demonstrates the activity
stack, centralized backend boundary, Lit shell, theme separation, and
governed public assets.
build_hooks/template_resources.py packages filtered,
version-matched copies for dev-std template copy.
These are project starters, not shared application frameworks. A consumer copies a template and owns its resulting code. Template-local configuration and signoff keep their requirements independent from the root Python package while full repository signoff proves both references from clean copies.
The root product is a Python governance package and CLI, so it does not declare the web-application capability for its own runtime. It does apply the published model to its shipped examples: contract authority, generated ownership, activity boundaries, centralized transport, design tokens, executable tests, and packaging evidence are all checked in signoff.
Existing root CLI and configuration schemas predate the TypeSpec capability and remain governed by the JSON Contract Standard, runtime/schema parity, and compatibility tests. A new root contract family that crosses a language or process boundary must begin with TypeSpec, or record the scoped exception required by the TypeSpec Contract Standard. Extending an existing contract does not silently create a second authority.
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.