Tarik Moussa
efee259d01
Some checks failed
gates / quality (push) Has been cancelled
Leader-Bootstrap (Planung) aus Template + Jetson-Meta-Prompt:
- ROADMAP-Board W1-W6 als Abhaengigkeits-DAG (Ready-Set = {W1})
- STATE mit disjunkter Datei-Ownership W2-W6
- CONVENTIONS Projekt-Vertrag (Profile, Pfade, Ports, Daemon-Env, num_ctx, DVC, Scope)
- manifests/requirements.md = kalt verifizierbares Review-Manifest (R-01..R-10)
- REVIEW.md Kalt-Review-Einstieg; ADR 0002 (Ollama-nativ, kein Swapper/Gateway)
- session-prompts/W1..W6 dispatch-fertig; .gitignore um Jetson-Ignores erweitert
- examples/walkthrough entfernt (Projekt hat eigenes gefuelltes Board)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
59 lines
2.6 KiB
Markdown
59 lines
2.6 KiB
Markdown
# Model-Routing — Zuweisung nach Aufgabentyp
|
|
|
|
Vollständige Entscheidungsmatrix. Kurzform in `docs/loops/feature-loop.md`.
|
|
|
|
> **Tier-Sprache statt feste Modellnamen:** Modellnamen veralten; die Tier-Logik
|
|
> (klein/mittel/hoch) bleibt. Konkrete Modell-IDs (z. B. Haiku 4.5, Sonnet 4.6,
|
|
> Opus 4.8) sind aktuelle Beispiele — beim Provider nachschlagen, wenn neue
|
|
> Versionen verfügbar sind.
|
|
|
|
## Tiers
|
|
|
|
| Tier | Eigenschaft | Aktuelle Beispiele (Anthropic Claude) |
|
|
|------|-------------|---------------------------------------|
|
|
| **klein** | schnell, günstig, ausreichend für klar spezifizierte, mechanische Arbeit | Haiku |
|
|
| **mittel** | ausgewogen; guter Coder bei klarer Spec | Sonnet |
|
|
| **hoch** | höchste Reasoning-Kapazität; für Unklarheiten, Mathe, Review | Opus |
|
|
|
|
## Routing-Matrix
|
|
|
|
| Aufgabe | Rolle · Tier |
|
|
|---|---|
|
|
| Mechanisch, lokal, kein Risiko: Docs, Umbenennen, Konstanten, CLI-Glue | klein |
|
|
| Faithful Translation von bekannter Referenz (Port, golden oracle) | Porter · mittel |
|
|
| Implementierung mit klarer Spec + Akzeptanzkriterien: Tests, Error-Handling | mittel |
|
|
| Numerik, Architektur, Mathe von Grund auf, irreversible Public-API-Entscheidungen | hoch |
|
|
| Formeln aus Papers ableiten, Validation-Strategie entwerfen | Theorist · hoch |
|
|
| Throwaway Proof-of-Correctness (Spike), bevor Produktionscode entsteht | Prototyper · hoch → mittel |
|
|
| Test-Batterie für abgeschlossene Implementierung | Validation · mittel |
|
|
| **Jede Review-Gate-Session** (unabhängig, kalt) | **Reviewer · hoch** |
|
|
| Docs polieren, Referenz-Listen, Tutorials | Scholar · klein |
|
|
| Branch/PR/CI/Rebase/Merge | Integrator · mittel |
|
|
| Fachliche Richtungsentscheidungen, Lizenz, Precision-Substrat | Human |
|
|
|
|
## Entscheidungsregel
|
|
|
|
**Nicht** „wie schwer ist das Finding/Feature", sondern:
|
|
**„Wie viel muss *verstanden* werden, um es richtig zu machen?"**
|
|
|
|
- Eine 1-Zeilen-Korrektur mit klarer Spec → mittel (auch wenn 🔴 Severity).
|
|
- Eine numerische Umformulierung mit Auswirkung auf Korrektheit → hoch
|
|
(auch wenn 🔵 Severity).
|
|
|
|
## Review-Gate-Regel
|
|
|
|
Die Review-Gate-Session ist **immer höchste Kapazitätsstufe und immer kalt**
|
|
(eigene Session, kein Vorkontext aus der Implement-Session). Implement-Tier ≠
|
|
Review-Tier ist keine Effizienzfrage, sondern eine Korrektheitseigenschaft.
|
|
|
|
## Routing Port vs. Research
|
|
|
|
```
|
|
Gibt es eine Referenz-Implementierung / goldene Werte?
|
|
JA → Port → Porter (Sonnet), golden-oracle parity-Tests Pflicht
|
|
NEIN → Research → Theorist (Opus) ableiten → Spike → GO/NO-GO
|
|
→ Research-Implementer (Opus→Sonnet) produktivisieren
|
|
```
|
|
|
|
Details zum Spike-Gate: `docs/loops/spike-gate.md`.
|