adopt

name	adopt
description	Use when bringing the harness method to a NEW or non-sentropic repo — maps the repo's conventions into a harness profile so the same scope/branch/verify kernel applies anywhere.

harness/adopt

Native repo-onboarding. The harness engine (parser, C1/C2 checks, verify) is generic; all repo-specific policy is DATA in a profile. adopt maps a foreign repo onto that SPI so the method runs unchanged.

Steps

1. Scaffold — harness init [--profile sentropic|stub] [--json] prints a profile descriptor. Save it as harness.profile.json at the repo root and edit it to fit:
   • forbiddenPathDefaults — globs forbidden unless a BRANCH.md explicitly Allows them.
   • exceptionIdPattern — the grammar of a valid scope-exception id (e.g. ^BR\d+-EX\d+$).
   • conditionalRequiresException — whether a Conditional path needs a matching declared exception.
   • branchMatch — exact or prefix for the C1 branch check.
2. Map the repo's reality — translate the repo's conventions, not sentropic's: which paths are off-limits, what its BRANCH.md grammar is (or whether one must be introduced), the command runner (make vs npm/nx), and the environment data-lifecycle (which envs are disposable vs protected).
3. Audit — harness audit --staged-files "<changed files>" --branch-md <path> --json diffs the repo against the active profile and emits a VerificationRun (static) listing drift: forbidden touches, undeclared (unknown) paths, missing scope declaration.
4. Wire — add a scope-check/verify step to the repo's pre-commit or CI using the profile, so the method is enforced, not just documented.

Principle

A second stub profile diverging from sentropic on a checked dimension is the proof-of-genericity: the same kernel yields different, correct verdicts per profile. Adoption succeeds when a third repo can declare its OWN profile and the unchanged engine governs it.