| 1 | # Harness Profile Cutline |
| 2 | |
| 3 | **Status (2026-07-12): Current cutline.** The schema/resolver lane is |
| 4 | implemented (`crates/config/src/harness.rs`: `HarnessPostureKind`, |
| 5 | `HarnessProfile`, seed profiles); the status/UX display and runtime use remain |
| 6 | deferred, and automatic profile evolution stays future work. |
| 7 | |
| 8 | This note defines the next-major order for HarnessProfile work. The automatic |
| 9 | Harness Creator must not run before the profile schema, resolver, seed |
| 10 | profiles, and user-visible status surfaces are explicit and tested. |
| 11 | |
| 12 | ## Decision |
| 13 | |
| 14 | For v0.9.0, CodeWhale should treat harness profiles as typed policy data first. |
| 15 | Automatic profile evolution is deferred until replay evidence, candidate |
| 16 | manifests, and promotion gates exist. |
| 17 | |
| 18 | The first implementation lane stops at: |
| 19 | |
| 20 | 1. `HarnessPosture` enum and policy knobs. |
| 21 | 2. `HarnessProfile` schema and registry. |
| 22 | 3. Deterministic profile resolver. |
| 23 | 4. Seed profiles for common model families. |
| 24 | 5. Repo constitution overlay input. |
| 25 | 6. Status/UX display of the resolved provider, model, profile, and repo law. |
| 26 | |
| 27 | Only after those surfaces are visible and tested should CodeWhale add evidence |
| 28 | stores, candidate manifests, promotion gates, or an agentic Harness Creator. |
| 29 | |
| 30 | ## Required Seed Profiles |
| 31 | |
| 32 | | Model family | Intended posture | Notes | |
| 33 | | --- | --- | --- | |
| 34 | | DeepSeek V4 Pro / Flash | cache-heavy | Preserve prefix stability and large-context continuity. | |
| 35 | | Xiaomi MiMo V2.5 Pro / UltraSpeed / V2.5 | cache-heavy | Similar long-context/cache posture, but route and auth remain distinct from DeepSeek. Older V2 Flash names are historical examples, not current direct-provider defaults. | |
| 36 | | Arcee Trinity Thinking | cache-heavy or explicit Arcee profile | Direct Arcee IDs such as `trinity-large-thinking` must not be hidden behind OpenRouter aliases. | |
| 37 | | Hugging Face / local / open-weight routes | lean | Prefer smaller context packs, stricter tool surfaces, and subagent-oriented decomposition. | |
| 38 | | Generic OpenAI-compatible gateways | standard unless matched | Do not infer provider-specific posture from a bare endpoint alone. | |
| 39 | |
| 40 | Provider route, endpoint, model id, HarnessProfile, and repo constitution must be |
| 41 | separately visible. A profile resolver may choose a profile, but it must not |
| 42 | silently change provider auth, base URLs, model IDs, tool allowlists, or repo |
| 43 | permissions. |
| 44 | |
| 45 | ## Repo Constitution Boundary |
| 46 | |
| 47 | `.codewhale/constitution.json` is local repo law, not another provider profile. |
| 48 | The resolver may read it as an input after project trust checks, but profile |
| 49 | selection must show both: |
| 50 | |
| 51 | - the model-facing posture, such as `cache-heavy` or `lean`; |
| 52 | - the repo-law source, such as `.codewhale/constitution.json` or none. |
| 53 | |
| 54 | ## Automatic Evolution Boundary |
| 55 | |
| 56 | AHE/GEPA-style profile evolution is future work. It can be referenced as |
| 57 | inspiration only after the text distinguishes these stages: |
| 58 | |
| 59 | 1. candidate proposal from recorded evidence; |
| 60 | 2. replay/eval against a weaker or constrained student; |
| 61 | 3. promotion-gate decision with required tests and policy checks; |
| 62 | 4. inspectable overlay update or rollback. |
| 63 | |
| 64 | No v0.9.0 harness profile should be silently promoted, mutated, or written to a |
| 65 | cached-main overlay by the schema/resolver/display lane. |
| 66 | |
| 67 | ## Smoke Evidence |
| 68 | |
| 69 | Before v0.9.0 ships with HarnessProfile runtime behavior beyond schema parsing |
| 70 | and pure resolver checks, the acceptance matrix should record evidence for: |
| 71 | |
| 72 | - DeepSeek V4 resolving to a cache-heavy profile; |
| 73 | - Xiaomi MiMo resolving to a cache-heavy profile without sharing DeepSeek auth; |
| 74 | - Arcee direct `trinity-large-thinking` resolving through the direct `arcee` |
| 75 | route, not the OpenRouter `arcee-ai/trinity-large-thinking` alias; |
| 76 | - a generic/HF/local model resolving to a lean or standard profile; |
| 77 | - the TUI or runtime status surface showing provider, model, profile, and repo |
| 78 | constitution separately; |
| 79 | - no automatic profile mutation during normal Agent or Workflow runs. |
| 80 | |
| 81 | For v0.9.0, pure resolver tests may satisfy the profile-selection evidence, but |
| 82 | status display and runtime use remain deferred until separate PRs wire those |
| 83 | surfaces deliberately. Release notes should still call HarnessProfile a typed |
| 84 | schema/resolver foundation rather than an automatic harness creator. |
| 85 |