1. Run the immutable 90-second demo

Start with the immutable demo release v1.0.1. It needs Python 3.9 or newer and no third-party packages.

git clone --branch v1.0.1 --depth 1 \
  https://github.com/ExCoder/mergegrounds-demo.git
cd mergegrounds-demo
python3 demo.py

The deterministic run prints:

ADMITTED admitted             complete exact evidence
DENIED   stale-evidence       stale:evidence
DENIED   wrong-commit         revision_mismatch:unit-tests
DENIED   incomplete-scope     scope_mismatch:static-analysis
DENIED   survived-mutant      survived_mutant
DENIED   missing-producer     missing_producer:static-analysis
DEMO PASSED: 1 admitted control; 5 negative controls denied

This is an educational model, not a production verifier or assurance claim. It demonstrates one admitted control and five negative controls without grading a real repository.

2. Clone the reviewed core release

git clone --branch v1.0.0 --depth 1 \
  https://github.com/ExCoder/mergegrounds.git

Core bootstrap needs Python 3.11 or newer. For an existing Git repository, follow steps 3–4 without --allow-non-git. For a new non-Git project, use only the separate empty-directory path in step 5. Compare the release archive against its published checksums before use. Keep the clone intact: the skill, runner, policy schemas, workflows, and reference material form one versioned control plane.

3. Preview an existing Git repository; change nothing

python3 -I /absolute/path/to/mergegrounds/scripts/bootstrap.py \
  --target /absolute/path/to/your-repository

Preview reports only CREATE and CONFLICT planning results. It changes no files, prints Dry run only, and exits 0 on a successful preview. The reviewed reference run reported Plan: conflict=5, create=43; counts depend on the target. This is a file plan, not a security verdict.

4. Review, then apply to the existing Git repository

python3 -I /absolute/path/to/mergegrounds/scripts/bootstrap.py \
  --target /absolute/path/to/your-repository \
  --apply

Apply only after a real owner has reviewed every CREATE and CONFLICT entry. Replace deliberate ownership placeholders, inspect adapter commands, pin toolchains, and connect machine-readable coverage and mutation reports. Do not weaken a failed control merely to get green.

5. Alternative: start a new empty directory

Create the directory first and leave it completely empty:

mkdir /absolute/path/to/new-empty-project

Preview without writing:

python3 -I /absolute/path/to/mergegrounds/scripts/bootstrap.py \
  --target /absolute/path/to/new-empty-project \
  --allow-non-git

Review every CREATE and CONFLICT entry, then apply with the same explicit permission:

python3 -I /absolute/path/to/mergegrounds/scripts/bootstrap.py \
  --target /absolute/path/to/new-empty-project \
  --allow-non-git \
  --apply

--allow-non-git is restricted to an existing, completely empty directory. Never use it for an existing Git repository or a non-empty directory; bootstrap rejects both cases. Initialize Git in that exact directory only after applying and reviewing the starter.

6. Seal, verify, and expect red

python3 -I scripts/mergegrounds.py seal --write
python3 -I scripts/mergegrounds.py doctor
python3 -I scripts/mergegrounds.py verify-repo --strict

Commit the reviewed controls and their seal separately. The full profile remains red until the project-specific fuzz harness and authoritative evidence producers are connected. Understand the expected-red result before changing any policy.

7. Configure external enforcement

Repository files alone are not an active security boundary. Maximum assurance requires a separately administered verifier, required checks bound to its identity, protected owners, and a ruleset with no alternate write path.

Start from the separately versioned reference verifier and its canonical schemas. It is a decision core, not a hosted trust boundary; operators must supply independent administration, identities, isolation, and protected GitHub settings.