0x0LearnReferenceLibraries0x0.jmp0x1b.com

Source-Owned Tooling

Source-Owned Tooling means production-critical tool behavior is owned by 0x0

source and checked policy data. Python and shell may still appear in the

repository, but only as explicit host adapters for filesystem, process,

network-adapter, signing-adapter, or hardware-adapter boundaries.

Run the bounded closure gate:


make source-owned-tooling-closure-check

The gate does not run self-host, release verification, network publication, or

hardware jobs. It checks the source-owned manifest, host-shim classification,

support matrix, release helper manifest, and tooling-suite policy/dehost

reports.

Production-Critical Tooling

tooling/source-owned-tooling.tsv is the production-critical tooling manifest.

Every row must have:

The current manifest covers:

Host Adapters

tooling/host-shim-classification.tsv allows only:

OS-boundary work for source-owned rules.

temporary-host-shim is not allowed in the production-critical path. The

closure gate includes a negative fixture that rewrites a row to

temporary-host-shim and expects SOURCE_TOOL_TEMPORARY_SHIM.

Evidence

The closure evidence is:

The verifier also runs tools/tooling-suite.py policy-check and

tools/tooling-suite.py dehost-plan to prove the ordinary tooling policy and

de-host reports agree with the closure manifest.

Diagnostics

The gate reports stable JSON diagnostics:


SOURCE_TOOL_TEMPORARY_SHIM   temporary host shim remains
SOURCE_TOOL_MISSING_OWNER    source-owned `.0x0` owner is missing
SOURCE_TOOL_MANIFEST         source-owned tooling manifest is incomplete
SOURCE_TOOL_HOST_ADAPTER     host adapter path is missing
SOURCE_TOOL_GATE             Make gate is missing
SOURCE_TOOL_SUPPORT          support matrix has not been updated
SOURCE_TOOL_RELEASE_HELPERS  release helper manifest is missing the gate
SOURCE_TOOL_POLICY           tooling-suite policy/dehost command failed

Documentation Impact

Tooling behavior changes must update the source-owned manifest, tooling docs,

diagnostics, support matrix, release notes, and ADR/RFC records in the same

change. If no user-facing behavior changes, the ADR/RFC documentation impact

review must say why.