DomainProfile is the boundary between the runner's architecture and
domain-specific knowledge.
The runner owns:
- phase execution and repair loops
- evidence arbitration
- final acceptance as the sole success gate
- oracle tri-state handling through
VerificationReport - recovery handoff generation
A profile owns:
- scaffold paths expected for the domain
- dependency readiness and the sanctioned setup requirement
- build oracle command recognition and compile-error parsing
- serve or behavior probe invocation
- invariants and deterministic repairs
- goal capability inference and evidence vocabulary hooks
Profile UltraPlan presets are explicit opt-ins rather than a global default.
UAT test0711_bs_004 exposed duplicate setup-step stagnation in preset
implementation phases, so qwen27, gemma-family, and unmatched planner models
currently default to none. Tier lookup and source recording still use the
resolved planner model regardless of whether it came from CLI, executor-model
fallback, or a named config preset. Set plan_preset = "profile" in config or
pass --plan-preset profile to opt in; explicit CLI always overrides config.
Profiles must not special-case runner control flow. If a new domain needs a
new lifecycle shape, extend DomainProfile first and keep the runner calling
the trait.
The compact registration workflow and pack-capability boundary are also mapped
in docs/dev/extension-catalog.md.
- Add a profile module under
src/planner/profiles/. - Implement
DomainProfilewith defaults for anything not applicable. - Add one entry to
PROFILE_DESCRIPTORSinsrc/planner/profile_descriptor.rs. - Keep dependency setup authority-gated and offline-aware.
- Return compile errors as
CompileErrorso existing repair targeting, rollback, and recovery handoff paths work unchanged. - Emit behavior evidence through the profile behavior probe, not by bypassing final acceptance.
- Add or update one row in the conformance matrix under
tests/conformance/. The row must exercise the profile through the normal plan or ultra-plan runner path with fake clients and probe overrides, then pass the reusable interface-contract checkers. - Add focused profile proof tests for domain-specific outputs only after the shared conformance row passes.
Do not add provider abstractions, profile-specific runner branches, or profile-specific repair loops.
An extension root can add a first-class draft profile at
profiles/<id>/manifest.toml. Select it with both --extension-root <DIR> and
--profile <id>; --doctor lists its exact-byte hash. External supply never
grants admission: a manifest that says admitted is forced to draft, has no
capability band or pack selection, and is capped at static with
profile_not_admitted.
For an admitted embedded manifest-backed profile, Issue #105 permits a single
profiles/<admitted-base-id>/overlay.toml. This produces a separate draft effective
profile and may only add artifacts, guidance variants, checks, and their local
evidence targets. Replacement, removal, weakening, overlay chaining, and base
identity mutation are rejected. Use an external draft when testing new
declarations; use the compiled workflow above when seeking admission.
Operators and extenders can inspect draft/source labels and the bounded pack lifecycle in the GUI extensions guide.
New entry points and execution boundaries must be registered in
tests/protection_coverage_audit.rs before they are used. Add or update the
declarative protection row for the affected category, including the site
predicate, required wrapper/type, and allowlist, then add a conformance pathway
row when the boundary can affect runner outcomes.
This rule exists because the instruction 92 parity-hole incidents showed the same failure class recurring at opt-in call sites: compile parsers received display excerpts instead of full command output, verify commands bypassed the shared normalizer, and terminal records were missing on some exit paths. New boundaries must make those bypasses type-impossible or CI-detected.
A new profile is not complete until cargo test --test conformance passes with
its matrix row. The conformance suite owns the shared runner/profile interface
contracts: earned assurance, monotonic rebind, authority symmetry,
detect/repair pairing, honest terminal records, oracle tri-state handling, and
degradation labeling. New profiles add rows, not bespoke copies of those
assertions.