Skip to main content

Adopt It

Start with a bounded project and the controls appropriate to its data, risks and delivery environment. Adoption can be incremental, but a required protection does not become optional because the installation is partial. A synthetic prototype and a real-data pilot have different obligations.

The adoption path​

  1. Establish context and authority. Identify the repository, business owner, approved scope, data classification and current delivery constraints. Select the method, stack/model and risk profiles. Preserve existing organizational rules.
  2. Inspect before installing. Read the kit's setup/ADOPTION-TRIAL.md and run setup/bootstrap.sh <project-root> --dry-run against the authorized target. The complete kit and Python 3.9+ are required. Review the proposed files and configuration; a dry run does not activate anything.
  3. Merge the instruction layer. Keep project commands and context in one maintained home. Link to normative controls instead of copying their full text. Add the task-scoped skills and reviewers that apply; instructions guide behavior but do not enforce it.
  4. Install and check preservation. Trial the installation and an edited-file upgrade in a disposable project first. The installer preserves existing settings and local edits, with proposed updates for review. An unexplained recovery lock requires investigation, not deletion.
  5. Verify each host integration. Test event matching, execution root, diagnostic delivery and blocking behavior with harmless positive and adverse cases. The post-edit lint check is advisory; the session-end verification reminder writes debug output and does not prove tests ran. The pre-push quality gate covers recognized tool calls, not every way to push.
  6. Assess server-side controls separately. Configure the actual project gate and expected test selection. Review repository permissions, required check identities and authorized exceptions. A workflow file alone does not prove that a failing result prevents a merge.
  7. Run a bounded pilot and review the evidence. Record installed/configured/runtime-verified states separately, along with missing checks and intentional exclusions. Approve wider adoption only within the demonstrated scope.

Text equivalent: selection and review precede installation; installation precedes runtime checks; the pilot produces evidence for an owner decision. This is an adoption procedure, not a shipped automatic approval service.

Minimal vs. full adoption​

A useful starting point is a small set of project instructions, the relevant lifecycle skills and a meaningful verification command. Add supported hooks, specialist review and curated memory as their value becomes clear. Keep current context identifiable and audience-appropriate; memory is not a substitute for approved decisions.

An installed component may still be unconfigured or unverified. Keep that distinction visible, and do not use a partially assessed setup for work requiring stronger controls.

Where to next​