Artifact And Vendor Governance

Artifact and vendor governance separates source-controlled project intent from transient local build state. The standard gives packages a way to identify committed binaries, release bundles, vendored source, generated source, public reference assets, private fixture sets, and release channels without treating every local compiler output as a durable artifact.

Catalogs

dev-std.toml remains the package policy switchboard. Detailed inventories live in authored governance catalogs under docs/governance/.

Artifact Classes

Artifact governance distinguishes transient build output, package distribution output, committed runtime artifacts, application/plugin bundles, fixture data, public reference assets, vendored runtime artifacts, generated source, oracle outputs, and release evidence.

Default audit is tracked-file-first. Ignored local paths such as build/, output/, temp/, rack_results/, and local staging under dist/ do not fail the default audit. Explicit release or evidence modes may inspect produced outputs, checksums, licenses, and channel inclusion.

Vendored Code

Vendored source under roots such as vendor/ or third_party/ requires a machine-readable vendor entry. Vendor entries identify upstream name, version or commit, source URL or archive, checksum when available, license file, local patches or pruning, consumers, update command, and owner.

The shared governance catalog for new work is docs/governance/vendors.toml. Each [[vendors]] entry identifies an id, kind, name, upstream_url, version, license, owner, update_command, covered paths, and consumers. The catalog is the package source of truth for committed vendored source, minified JavaScript, WASM, fonts, generated support bundles, and similar retained third-party drops.

Package-local JSON files such as vendor_manifest.a0.json are compatibility inputs when an existing tool already consumes them. They may continue to use a root schema field, but they do not replace the shared vendor catalog unless the package explicitly documents an adapter or compatibility path that maps the local manifest into docs/governance/vendors.toml.

Generated Source

Committed generated source is an artifact class. Its catalog entry records the source of truth, regeneration command, retention policy, and verification refs. This keeps generated code visible without asking normal source-domain audits to treat it as hand-owned implementation.

Release Channels

A configured package distribution such as pypi requires a release catalog. Release channels describe the publication process for PyPI, GitHub releases, native or WASM bundles, app/plugin packages, object store uploads, and future package-manager automation.

Each release channel must identify both a process_doc and a build_doc. The process document explains how the channel is published. The build document explains required tools, setup, invocation, packaging outputs, and the distinction between local build output and promoted release artifacts. A package may use the same document for both fields when the setup and release process are intentionally combined. Canonical package build documentation is audited by docs.build and should normally live at docs/build.html or docs/build.md.

Native and WASM paths such as dist/native/windows-x64/ and dist/wasm/browser/ are useful conventions when a package promotes those outputs. They are not mandatory for every mixed/native package.

Release channels may declare promoted payloads with nested [[channels.promoted_artifacts]] tables. Default audit validates declaration shape, unique ids, known artifact kinds, boolean required flags, contained bounded paths, and license refs without reading payload files. Release mode is explicit: dev-std audit . --scope docs.release --mode release. 

[[channels.promoted_artifacts]]
id = "wheel"
kind = "package_distribution"
paths = ["dist/wn_dev_std-*.whl"]
required = true
build_profile = "release"
license_refs = ["LICENSE"]

Date-versioned packages should normally use bounded globs for build outputs. Literal version, source_commit, and sha256 values are optional assertions for pinned or already promoted payloads. When declared, the version is compared to pyproject.toml project metadata, the source commit is prefix-matched against git rev-parse HEAD, and the checksum is computed from the matched file. A declared checksum requires exactly one matched artifact.

Promoted roots are derived from the static directory prefix before the first wildcard, or from the parent directory for exact paths. File matching uses repository-relative POSIX paths and the same fnmatch semantics as artifact catalog coverage, so declared files and uncataloged promoted payload detection use one matching model. Uncataloged detection is catalog-wide, allowing multiple release channels to share a staging root such as dist/ without flagging each other's declared payloads.

Audit Scopes