Describes a single rule, its required value, and its rationale.
Collects the current Python profile, required files, required docs, and strict rules.
Enumerates the supported standard profile names.
Returns the current strict Python package profile.
Returns the current profile by name. The default profile is
python-package.
Renders the current profile for human or machine use.
Renders a named profile for human or machine use.
python-package is the pure Python baseline. Native-backed
projects use the python-native-wasm profile documented in
Mixed Mode Standard. Native C++ projects use
the cpp-library profile documented in
C++ Standard. C# applications and host
plugins use the csharp-app profile documented in
C# Standard. Browser apps use the
javascript-web-app profile, and Python-served browser apps use
the python-js-app profile documented in
JavaScript Web App Standard.
Contract versions may use dates, semantic identifiers, or hardware-style stepping names such as A0, A1, B0, or B1. Each contract must document compatibility rules. Optional additive fields are usually compatible when old parsers ignore unknown fields. Required, renamed, removed, or semantic changes are breaking.
HTML design docs must carry a machine-readable
data-doc-status marker. Accepted pages describe current
contract or standard behavior. Draft and proposal pages may guide active
implementation, but release signoff must review them explicitly before
treating them as accepted contract evidence. See
Documentation Standard.
Repositories with known legacy names, environment variables, setup shims, or
compatibility aliases should declare a [compatibility_pruning]
table in wn-dev-std.toml. The check scans the configured root
for forbidden_patterns and reports file and line locations when
old surfaces return.
[compatibility_pruning]
root = ".."
forbidden_patterns = [
"\\bWN_LIBZ_ROOT\\b",
"\\bwn_pcb\\b",
]
excluded_parts = ["test_cases", "fixtures"]
Captured fixtures, generated outputs, and tool caches should be excluded deliberately. New compatibility shims need an explicit design reason and a signoff ratchet so they do not become permanent hidden API surface.
Public repositories should install the shared GitHub PR hygiene workflow
and PR template from docs/templates/github/, then opt into
local validation with a [pr_hygiene] table. The workflow
requires a filled Linked issue: line that resolves to an
existing same-repo issue, Conventional Commit form for PR titles and commit
subjects, commit subjects of 72 characters or fewer, and no WIP,
emoji, or AI-vendor attribution in PR metadata or commit messages.
[pr_hygiene]
enabled = true