voyage/docs/voyage-vs-cc-balance-charter.md

Voyage-vs-CC Balance Analysis — Charter

Status: Launch-spec. MANDATERT start på neste sesjon (operatør 2026-06-20). Dette er ANALYSE-scope — anbefalinger only, operatør-gated FØR enhver implementasjon.

Spørsmålet

Moderne Claude Code (2.1.183) gjør nativt mye av det Voyage en gang differensierte på (sub-agent-nesting, Workflow-tool, native effort:, plan mode, resume/state, Artifacts). Finn balansen der:

• (Tilgjengelighet) en bruker som IKKE er CC-ekspert fortsatt får Voyages verdi — Voyage koder beste praksis så du slipper å kunne harnessen.
• (Ikke-duplisering) Voyage IKKE reimplementerer CC-features som CC gjør bedre nativt.

Anker-funn fra S29 (ikke re-deriver): CC-26/CC-27 konkluderte at orkestrerings-substratet i økende grad er nativt; CLAUDE.md innrømmer selv at «swarm relieves context»-påstanden er umålt (Δ ≈ 0), og at strukturerte artefakt-handovers + multi-sesjon-disiplin er den bærende verdien. Operatørens egen primærbruk: store oppgaver over flere sesjoner.

De to beslutnings-aksene

For hver Voyage-capability:

• Akse A — Duplikasjon: Gjør dagens CC dette nativt? Gjør CC det bedre?
• Akse B — Ekspertise-bar: Lar Voyages innpakning en ikke-CC-ekspert få verdien uten å kunne CC-internals?

Disposition-vokabular (per capability):

Disposition	Når
KEEP	Voyage-unik verdi (eller klart bedre), ikke duplikat.
THIN-WRAP	CC gjør jobben; Voyages verdi er å senke ekspertise-baren / opinionated defaults. Behold et tynt lag, deleger motoren til CC.
DROP→NATIVE	CC gjør det bedre OG ingen reell ekspertise-gap. Fjern fra Voyage; dokumentér den native veien.
SIMPLIFY	Behold, men kast kompleksitet CC nå håndterer.

Spenningen som MÅ løses eksplisitt: en feature CC gjør «bedre» rått kan likevel fortjene THIN-WRAP hvis rå CC krever ekspertise. Tilgjengelighet kan rettferdiggjøre en wrapper; den kan ikke rettferdiggjøre en re-implementasjon.

Metode (faset — «alt av metoder» autorisert: agent-swarm / Workflow / web-research)

• Phase 0 — Evidensbase (ikke re-deriver). Les: CC-NN-matrisen (docs/cc-upgrade-2.1.181-decision-matrix.md), docs/subagent-delegation-audit.md, docs/T1-*/docs/T2-*-resultater, CLAUDE.md design-prinsipp-innrømmelsen, CC-26/27-dispositionene. Kjør den utsatte post-2.1.181-delta-sjekken (2.1.182→siste, via claude-code-guide/WebSearch) — matrisen stopper på 2.1.181.
• Phase 1 — Voyage capability-inventar. Enumerér hver distinkte capability: 7 commands, 24 agenter, de 7 handovers, session-dekomponering, state/resume (/trekcontinue//trekendsession), review-gates (plan-critic/scope-guardian/brief-reviewer/reviewere), framing-gate, rendering+annoterings-HTML, profiler, observability, autonomy-gates (--gates), headless/-p, lib-validatorer. Én rad per capability. (Fan ut lesere over commands/agents/lib/docs.)
• Phase 2 — CC-overlap-mapping. Per capability: dagens CC-native ekvivalent (feature + versjon) + dom «gjør CC det bedre».
• Phase 3 — Dobbel-akse-klassifisering + adversarisk pass. Klassifisér hver på A×B → disposition. Et contrarian/critic-pass utfordrer HVER KEEP («virkelig ikke duplikat?») og HVER DROP→NATIVE («virkelig ingen ekspertise-gap — ville en ikke-ekspert mistet verdien?»). Registrér utfordringene + verdiktene.
• Phase 4 — Syntese. Mål-form for Voyage + en prioritert endrings-backlog (handling per capability), som skiller ikke-breaking fra breaking (Trinity Handover-1-kontrakten + operatør-pinnede beslutninger er harde constraints — flagg, ikke bryt i stillhet). Operatør-gated.

Output-artefakt: docs/voyage-vs-cc-balance-analysis.md.

Eksekvering — Dynamic Workflow (operatør-autorisert 2026-06-20)

Substrat: CC Workflow-tool (Dynamic Workflow) — IKKE ad-hoc Agent-kall, og IKKE dogfood via Voyages egen pipeline (/trekbrief→/trekplan; avvist av operatør). Begrunnelse: analysen er en capability-for-capability audit med adversarisk utfordring + syntese = Workflow-toolets kanoniske mønster, som gir (i) deknings-garanti (pipeline over hele capability-lista → ingen rad faller ut, jf. Verifisering #1), (ii) innebygd adversarisk-verify (parallelle skeptikere per disposition, jf. #5), (iii) parallellitet + typede schemas.

Hybrid-form (per Workflow-toolets egen anbefaling «scout inline først, deretter pipeline over arbeidslista»):

1. Scout inline (main-context): Phase 0 evidens-lesing + post-2.1.181-delta (1 research-agent) + Phase 1 capability-inventar → produserer arbeidslista (capability-rader). Dømmekraft-tungt; fan-outes IKKE.
2. Workflow pipeline() per capability: stage A = Phase 2 CC-overlap-map (m/ schema) → stage B = Phase 3 dobbel-akse-klassifisering (disposition-schema) → stage C = adversarisk verify (parallel() skeptikere som utfordrer KEEP/DROP→NATIVE).
3. Syntese inline (main-context): Phase 4 — skriv docs/voyage-vs-cc-balance-analysis.md + backlog fra de verifiserte radene. Dømmekraft-tungt; fan-outes IKKE.

Avgrensning: Workflow dekker KUN den parallelliserbare, verifiserbare kjernen (Phase 2–3) — speiler CC-27-funnet «~80 % glue, ~20 % fan-out». Meta-bonus: å kjøre analysen på Workflow-toolet gir førstehånds-evidens til analysens egen CC-27-rad (er Workflow-toolet et godt substrat?) — dogfooding av Workflow-toolet, ikke av Voyage.

Verifisering (testbare kriterier)

1. Dekning: hver capability fra Phase 1 opptrer nøyaktig én gang i Phase 3-matrisen med disposition + begrunnelse + evidens-ref. (Inventar-antall == matrise-rad-antall.)
2. Hver «CC duplikat / gjør bedre» siterer en spesifikk CC-feature + versjon.
3. Hver «senker ekspertise-bar» navngir de konkrete CC-native stegene en ikke-ekspert ellers måtte gjort.
4. Post-2.1.181-delta faktisk kjørt: siste CC-versjon oppgitt + hvert nytt item triagert.
5. Adversarisk pass utfordret ≥ 1 KEEP og ≥ 1 DROP→NATIVE, registrert med verdikt.
6. Output ender med en prioritert endrings-backlog, hvert item tagget breaking/ikke-breaking og operatør-gated.

Harde constraints (ikke bryt)

• Trinity-asymmetri: Voyage forblir uvitende om Tier 2/3; Handover 1 (brief-schema) er eneste integrasjonspunkt. Ingen anbefaling kan bryte den uten å flagges som public-contract breaking change.
• Operatør-pinnede beslutninger (premium default-profil, 24 agenter opus-pinnet, etc.): analysen MÅ gjerne utfordre dem, men må merke dem operatør-pinnet, ikke overstyre i stillhet.
• Kun analyse: anbefalinger + backlog. Ingen implementasjon uten egen operatør-gate (scope-guard).

Kickoff (neste sesjon)

På kald start: les dette charteret + STATE, bekreft tilnærmingen (eller la operatør justere aksene/scope), start så Phase 0 (inline scout). Eksekver Phase 2–3 via Dynamic Workflow per «Eksekvering»-seksjonen (operatør-autorisert 2026-06-20). Charteret er skrevet S29 — ennå ikke committet (på disk i docs/, lesbart uansett).