Files
codewhale/docs/HARNESS_PROFILE_CUTLINE.md
T
Hunter Bown e60eeb8162 feat(config): add dormant harness profile resolver
Add a pure HarnessProfile resolver for provider/model routes while keeping runtime provider/model routing, prompts, tools, auth, context, and persisted config unchanged.\n\nVerification:\n- cargo test -p codewhale-config harness_profile --locked\n- cargo fmt --all --check\n- git diff --check\n- cmp -s CHANGELOG.md crates/tui/CHANGELOG.md\n- ./scripts/release/check-versions.sh\n- ./scripts/release/check-ohos-deps.sh
2026-06-06 01:58:17 -07:00

80 lines
3.7 KiB
Markdown

# Harness Profile Cutline
This note defines the v0.9.0 order for HarnessProfile work. The automatic
Harness Creator must not run before the profile schema, resolver, seed
profiles, and user-visible status surfaces are explicit and tested.
## Decision
For v0.9.0, CodeWhale should treat harness profiles as typed policy data first.
Automatic profile evolution is deferred until replay evidence, candidate
manifests, and promotion gates exist.
The first implementation lane stops at:
1. `HarnessPosture` enum and policy knobs.
2. `HarnessProfile` schema and registry.
3. Deterministic profile resolver.
4. Seed profiles for common model families.
5. Repo constitution overlay input.
6. Status/UX display of the resolved provider, model, profile, and repo law.
Only after those surfaces are visible and tested should CodeWhale add evidence
stores, candidate manifests, promotion gates, or an agentic Harness Creator.
## Required Seed Profiles
| Model family | Intended posture | Notes |
| --- | --- | --- |
| DeepSeek V4 Pro / Flash | cache-heavy | Preserve prefix stability and large-context continuity. |
| Xiaomi MiMo v2.5 Pro / Flash | cache-heavy | Similar long-context/cache posture, but route and auth remain distinct from DeepSeek. |
| Arcee Trinity Thinking | cache-heavy or explicit Arcee profile | Direct Arcee IDs such as `trinity-large-thinking` must not be hidden behind OpenRouter aliases. |
| Hugging Face / local / open-weight routes | lean | Prefer smaller context packs, stricter tool surfaces, and subagent-oriented decomposition. |
| Generic OpenAI-compatible gateways | standard unless matched | Do not infer provider-specific posture from a bare endpoint alone. |
Provider route, endpoint, model id, HarnessProfile, and repo constitution must be
separately visible. A profile resolver may choose a profile, but it must not
silently change provider auth, base URLs, model IDs, tool allowlists, or repo
permissions.
## Repo Constitution Boundary
`.codewhale/constitution.json` is local repo law, not another provider profile.
The resolver may read it as an input after project trust checks, but profile
selection must show both:
- the model-facing posture, such as `cache-heavy` or `lean`;
- the repo-law source, such as `.codewhale/constitution.json` or none.
## Automatic Evolution Boundary
AHE/GEPA-style profile evolution is future work. It can be referenced as
inspiration only after the text distinguishes these stages:
1. candidate proposal from recorded evidence;
2. replay/eval against a weaker or constrained student;
3. promotion-gate decision with required tests and policy checks;
4. inspectable overlay update or rollback.
No v0.9.0 harness profile should be silently promoted, mutated, or written to a
cached-main overlay by the schema/resolver/display lane.
## Smoke Evidence
Before v0.9.0 ships with HarnessProfile runtime behavior beyond schema parsing
and pure resolver checks, the acceptance matrix should record evidence for:
- DeepSeek V4 resolving to a cache-heavy profile;
- Xiaomi MiMo resolving to a cache-heavy profile without sharing DeepSeek auth;
- Arcee direct `trinity-large-thinking` resolving through the direct `arcee`
route, not the OpenRouter `arcee-ai/trinity-large-thinking` alias;
- a generic/HF/local model resolving to a lean or standard profile;
- the TUI or runtime status surface showing provider, model, profile, and repo
constitution separately;
- no automatic profile mutation during normal Agent or WhaleFlow runs.
For v0.9.0, pure resolver tests may satisfy the profile-selection evidence, but
status display and runtime use remain deferred until separate PRs wire those
surfaces deliberately. Release notes should still call HarnessProfile a typed
schema/resolver foundation rather than an automatic harness creator.