---
title: Spec Optimization-Target Pattern + verify-and-fix Assertions-Exit (Adoption 2026-05-18)
type: pattern
tags: [aria, spec, verify, optimization, kar-325, adoption]
date: 2026-05-18
status: aktiv
related: "[[02-Wissen/aria-manuel-heider-distribution-audit-2026-05-18]], [[CORRECTIONS]]"
confidence: high
description: Mini-Adoption aus IG-Reel 2 (Autonomous Mode, 2026-05-18). Spec.md kriegt Pflicht-Feld 'Optimization Target' (Metric+Threshold+Measurement), verify-and-fix kriegt explizites Exit-Statement und Optimization-Target-Re-Check.
---

# Spec Optimization-Target + verify-and-fix Assertions-Exit

## Trigger

Kais hat 2026-05-18 07:07 ein Reel geteilt (Autonomous Mode Pattern). Inhalt: GOAL → AGENT LOOP (plan/act/observe/verify) → MCP → OUTPUT. Plus "WHILE ¬done: loop until goal met, exit: all assertions == true". Plus "Optimization Target" mit Metric + Industry Benchmark.

Aria-First-Audit-Frage: was macht uns technisch besser? Adoption-würdig sind 2 Patterns:

1. **GOAL muss quantitative Metric haben**, nicht nur "feature works"
2. **Loop-Exit muss explizit als String stehen**, nicht "looks good"

Marketing-Patterns aus dem Reel (Architektur-Diagramm, PDF-Playbook, Live-Stats-Card) sind per Kais-Direktive "Marketing kommt später" rausgenommen.

## Was geändert wurde

### `/root/.claude/skills/spec/SKILL.md`

Neuer Pflicht-Punkt 4 in Phase 1 "Specify":

> **Optimization Target** (MANDATORY, neu seit 2026-05-18 / KAR-325) — quantitativ:
> - **Metric** — was wird gemessen?
> - **Baseline** — aktueller Wert vor Implementation
> - **Threshold** — bei welchem Wert ist Acceptance erfüllt?
> - **Industry Benchmark** (optional)
> - **Measurement** — wie wird der Wert nach Implementation tatsächlich gemessen?
>
> Statt vague "feature works" → harte Zahlen mit Mess-Methodik. Vorbedingung für `verify-and-fix` Pass.

Bisherige Punkte 4-6 verschoben auf 5-7.

### `/root/.claude/skills/verify-and-fix/SKILL.md`

Zwei neue Sektionen in der STATE.md-Template-Doku:

**1. Exit-Statement (Pflicht):**
```
EXIT: N of M assertions true (K failed: <ids>) → <verdict>
```
Kein freier Text, kein "looks good", kein "should be fine".

**2. Optimization-Target-Re-Check Tabelle:**
| Metric | Baseline | Threshold | Gemessen | Verdict |
|---|---|---|---|---|
| Page-Load-P95 | 720 ms | < 500 ms | 410 ms | ✅ |
| Test-Coverage | 0% | ≥ 80% | 92% | ✅ |

verify-and-fix muss zusätzlich zur Acceptance-Tabelle die Optimization-Target-Messung durchführen. Spec hat das Pflicht-Feld → STATE muss es ablesen.

## Beispiel — Anwendung auf KAR-310 Family-Dashboard

Wäre vor 2026-05-18 die Optimization-Target nicht da gewesen:

**Vorher (zu vage):**
> Acceptance: /family-Page rendert Leaderboard

**Nachher (quantitativ):**
> Optimization Target:
> - Metric: Initial Page-Load P95
> - Baseline: keine (Greenfield)
> - Threshold: P95 < 800 ms (Vercel Edge)
> - Measurement: `pnpm vitest run apps/web/src/app/(authed)/family/` + Lighthouse-CI lokal
> - Bonus-Threshold: 0 RLS-Leaks (manuell mit 2 verschiedenen Test-Usern verifiziert)

Plus verify-and-fix STATE.md Exit:
```
EXIT: all 6 acceptance + 2 metrics = true → ship-ready
```

## Warum lohnt sich das

1. **Pattern: spec.md vor `verify-and-fix`** ist heute schon Convention. Mit Optimization-Target wird der Cycle quantitativ statt qualitativ.
2. **Exit-Statement ist String-Matcher-Friendly** — wir können in Audits automatisiert die "EXIT:" Zeile greppen und Status extrahieren.
3. **Force-Multiplier** — jeder zukünftige BIG-Task läuft durch /spec, also greift die neue Pflicht ab heute überall.
4. **Self-Documenting** — wenn Tester Aria onboarded, sehen sie an STATE-Files sofort den Pass/Fail-Stand mit Zahlen statt Prosa.

## Warum NICHT übernommen (per Kais 2026-05-18 07:12)

- **Architektur-Diagramm** (SVG/PNG) — Marketing-Asset, später wenn Distribution-Story ernst wird
- **Playbook-PDF** — wie oben
- **Live-Stats-Card im Dashboard** — KAR-298 aria-control v3 deckt das bereits teilweise
- **Brand-Differenzierung** — siehe KAR-324 Audit der fremden Distribution; das ist Brand-Action, nicht Technik

## Adoption-Trail

Quelle: IG-Reel von 2026-05-18 07:07 (Telegram message_id 2580, attachment_file_id `BAACAgIAAxkBAAIKE2oKurqcjzeHF2d9Hv4CveIflnJkAAIDlwACUJRYSL5ttcMuwZSQOwQ`), 47 Sek, Autonomous Mode Pattern. Speaker verwendet Skill-Pattern das wir bereits haben (Agent-Loop, MCP, Mode-Gating) — neu war nur die explizite Pflicht-Quantifizierung der Acceptance + harte Exit-Strings.

## Verwandte Notes

- `[[02-Wissen/aria-manuel-heider-distribution-audit-2026-05-18]]` — Audit der fremden Distribution mit gleicher Quelle
- `[[02-Wissen/aria-user-guide-fundamentals]]` — R-K-A-C-F + Anfänger-Fallen Template
- `[[05-Referenzen/curriculum-poster/README]]` — KADiCon Aria Curriculum-Poster v1

## Verwandte KARs

- KAR-325 (dieses, neu)
- KAR-292 TDD-Guard — komplementär (Test-Discipline während Implementation)
- KAR-178 Aria User-Guide Fundamentals — komplementär (Workflow-Pattern für User)
- KAR-298 aria-control v3 — wird Live-Stats-Card teilweise abdecken