| 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
- 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.
- 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).
- 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.
- 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.
