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.
Greenfield browser apps use typescript-web-app, and
Python-served TypeScript browser apps use python-ts-app,
documented in
TypeScript Standard. Host Rust apps
and libraries use rust-app, and embedded Rust firmware uses
rust-firmware, documented in the
Rust 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.
JSON payload identity follows the
JSON Contract Standard. Durable
object payloads should use root type plus
version, nested variants should use kind, and
config-like or compatibility files may use a documented root
schema field. Pydantic is an implementation and validation
mechanism for Python and FastAPI-style services; exported Pydantic JSON
Schema must still match the accepted contract docs and fixtures.
The wn-dev-std reference package supports normal GIL-enabled
CPython 3.12 through 3.14 with
requires-python = ">=3.12,<3.15". CI exercises the newest
supported interpreter, and release signoff checks clean installation on
the lower supported minors. Free-threaded Python builds require separate
compatibility evidence and are not currently included.
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 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.
Reviewed public PRs should squash merge into main and avoid
non-linear public history unless a project-specific release exception
documents why branch history must be preserved.
[pr_hygiene]
enabled = true