Skip to content

Adoption and onboarding

These guides cover bringing an existing or new repository under Praetor governance: scaffolding the manifest and agent harness, choosing archetypes and facets, and checking what adoption declared.

Read Fast adoption first: its prerequisites, the one-step path and the table of what adoption writes. Then Repository onboarding for the staged workflow behind it.

  • Fast adoption: prerequisites, one-step adoption through praetorctl adopt, the standards_adopt MCP tool or the GitHub Action, and what each scaffolds.
  • Repository onboarding: the quickstart, staged onboarding with init, the flavor table, flavor detection, the manifest, the agent harness, the technical-debt baseline and verification, step by step.
  • Adoption verification commands: what the adoption report's verification object declares, and why adoption never runs a project's own scripts.
  • Archetype and facet authoring: defining profiles and facets, and how the lattice joins them.
  • Go API compatibility gate: the hosted check the api:public-contract facet adds where git tracks a go.mod, which compares every Go module's exported API with a base.
  • clang-tidy coverage gate: the audit check the clang-tidy linter of native-gpu-systems enables, which names every tracked C/C++ translation unit no declared clang-tidy lane reads, and the top-level exceptions list that excuses one.
  • Build-warnings gate: the HISS-10 audit check that fails a workflow lane compiling C, C++, Rust or Go code without its toolchain's warnings-as-errors form, and the exceptions entry for a lane that cannot use it yet.
  • Supply-chain gate: how the audit measures the SLSA level, cosign signing and SBOM generation the release workflows reach, and the HISS-11 exceptions entry adoption records when the declared supply chain exceeds them.
  • Workflow trigger audit: the HISS-18 warnings the audit prints for a push that runs on every branch and a pull request job that runs on drafts, and the exceptions entry that declares a workflow which must run everywhere.
  • Licensing gates: the reuse lint jobs adoption writes into a repository that declares REUSE, and the audit's REUSE.toml annotation order and root licence checks.
  • Generated artefacts: declaring the files a repository renders from other files, why a pull request leaves them alone, and the one regeneration change per batch that renders them.
  • Effective audit policy: how the CLI, MCP and adoption loops resolve complexity limits from one implementation.
  • Independent review and single-maintainer operation: the branch-protection review_mode and reviewer minimums.
  • Live Actions checks: how the audit compares the declared Actions workflow permissions with the forge and reports each workflow's recent runs.
  • Planning-artifact onboarding: the planning-artifacts archetype for research, concept and preparation repositories.
  • Framework capability evidence: what praetorctl needs report measures, which is dependency mapping availability, not migration readiness.