qa-staging

Der Browser-Test-Skill. Nicht “macht der Hugo-Build durch” (das macht CI), sondern: rendert die Seite korrekt im Browser, klickt alles richtig, gibt keine Konsole-Fehler, sieht auf Mobile auch noch ok aus.

Im Standard-Mode auch: was hat sich im Branch geaendert, und wurde das tatsaechlich besser?

Wann triggern

Vor Go-Live einer neuen Landing-Page / Hugo-Site-Aenderung.
Vor PR-Merge im av-website-Repo.
Nach Hugo-Theme-Update / Tailwind-Aenderung.
Periodisch ueber alle Properties (agenticventures.de, marvinkuehlmann.com etc.) — Smoke-Test.
Nach Email-Signatur-/Slide-Deck-Aenderung (sind auch HTML-Files in assets/firma/).

Nicht fuer:

Backend-MCPs ohne UI → security-audit + Smoke-Test
Tests im klassischen Sinn (Unit/Integration) → CI

Drei Tiers

Tier	Was	Wie lange
schnell	Smoke: Homepage + Top-5-Links, Konsole-Errors, Broken-Links	~1 Min
standard (default)	Diff-aware: Welche Pages aendert der Branch, jede getestet, plus Smoke der Adjacent-Pages	5-10 Min
tief	Exhaustive: jede reachable Page, Interaktionen, Mobile-Viewport, Auto-Fix-Loop	15-30 Min

Marvin kann “tief” sagen, sonst Standard. Bei “qa die seite kurz” → schnell.

Phase 1: Initialize

DATUM=$(date +%Y-%m-%d)
mkdir -p "intern/runs/${DATUM}-qa-<property-slug>/screenshots"
REPORT_DIR="intern/runs/${DATUM}-qa-<property-slug>"

Browser-Tool waehlen — in dieser Reihenfolge:

claude-in-chrome MCP — wenn extension connected (mcp__Claude_in_Chrome__list_connected_browsers → mind. 1 Browser).
mcp__Claude_Preview__preview_start — fuer lokale Hugo-Builds (hugo server o.ae.).
agent-browser CLI (compound-engineering Skill) — Fallback.

Wenn kein Browser-Tool verfuegbar → STOP, sag Marvin er soll Chrome-Extension aktivieren oder Preview-Server starten.

Phase 2: Stack-Detect + Property-Erkennung

Welche Property?

Schau in ”web-properties” — was wird hier getestet?

# Lokaler Dev-Server?
for port in 1313 3000 4000 8080 8888; do
  curl -s -o /dev/null -w "%{http_code}" "http://localhost:$port" 2>/dev/null | grep -q "200\|301\|302" && echo "Found: localhost:$port"
done

Wenn nichts laeuft + keine URL gegeben:

Im av-website-Repo? → hugo server -D --bind 0.0.0.0 starten und auf localhost:1313 testen.
Sonst Marvin fragen welche URL.

Stack-Detection

# Hugo?
ls config.toml hugo.toml config.yaml hugo.yaml 2>/dev/null
# Statisches HTML (Slides, Signaturen)?
ls index.html 2>/dev/null
# Frontmatter im HTML — Hint auf Generator
grep -m1 "generator" $(find . -name "*.html" -maxdepth 3 | head -1) 2>/dev/null

Speichere im Report-Metadata: framework: Hugo | static-html | mcp-html.

Phase 3: Authenticate (nur wenn noetig)

Marvin hat selten geschuetzte Bereiche. Falls doch:

Cookie-Datei: mcp__Claude_in_Chrome__navigate → mit cookie_file Param.
Login-Form: mit mcp__Claude_in_Chrome__form_input ausfuellen. NIE echte Passwords im Report — [REDACTED].
2FA: Marvin fragen, warten.

Phase 4: Orient — Application-Map

# Landing-URL
mcp__Claude_in_Chrome__navigate { url: <target> }
mcp__Claude_in_Chrome__screenshot → screenshots/initial.png
mcp__Claude_in_Chrome__read_console_messages → Errors-Output
mcp__Claude_in_Chrome__get_page_text → Strukturelle Uebersicht

Map der Navigation:

Welche Top-Level-Links existieren?
SPA oder klassisches Server-Render?
Fonts laden? (oft Hauptfehler-Quelle bei Hugo)
Welche externen Resourcen werden geladen (Analytics, Fonts, CDN)?

Speichere die Liste der gefundenen URLs als Test-Inventar fuer Phase 5.

Phase 5: Explore (Tier-abhaengig)

schnell-Tier: Smoke

Homepage screenshot + console-check.
Top-5-Links durchklicken (in der Reihenfolge ihrer Prominenz).
Pro Klick: screenshot, console-check, “ist die Page geladen oder 404?“.
Mobile-Viewport (375×812) — nur Homepage, ein Screenshot.

standard-Tier: Diff-aware

# Welche Files hat dieser Branch geaendert?
git diff main...HEAD --name-only
git log main..HEAD --oneline

Aus den geaenderten Files → welche Pages sind betroffen?

Geaenderter File-Typ	Betroffen
`content/<path>/index.md` (Hugo)	`/<path>/` URL
`layouts/_default/<name>.html`	alle Pages die das Layout nutzen
`assets/css/*.css`, `assets/tailwind.css`	alle Pages (style-affecting)
`assets/firma/email-signatures/*.html`	nicht im Browser, sondern lokal in `file://` testen
`assets/firma/slides/*.html`	Slide-Deck als standalone HTML testen
`static/*`	Direkt-URL `/<file>`

Pro betroffene Page:

Navigate.
Screenshot (annotated, mit Element-IDs).
Konsole-Errors.
Interaktive Elemente klicken (Buttons, Tabs, Akkordeons).
Mobile-Viewport-Check (375×812 → screenshot, dann zurueck auf 1280×720).
Adjacent-Page Smoke-Check (eine Page weiter — sind keine Regressionen?).

tief-Tier: Exhaustive

Standard + alle weiteren Pages (Links die aus Phase 4 gemapped wurden).

Plus pro Page:

Forms: durchfuellen mit Test-Daten (empty / invalid / edge cases).
Navigation: hin und zurueck per Browser-Back, Page-State checken.
Konsole nach JEDER Interaktion neu pruefen.

Phase 6: Document — Issues immer sofort schreiben

Pro Finding direkt in den Report — nicht erst am Ende sammeln (verliert Kontext).

Format

## Issue N: <kurztitel>

Severity: CRIT (blockiert User) | HIGH (sichtbarer Bug) | MED (UX-Problem) | LOW (cosmetic)
Page: <URL>
Category: Console | Link | Visual | Functional | UX | Performance | Content | Accessibility

Was ist los
<2-3 Saetze, beobachtbar (kein "ich glaube" — was hast du SEHEN koennen).>

Repro
1. <Schritt>
2. <Schritt>
3. Erwartet: <X>. Beobachtet: <Y>.

Evidence
- screenshots/issue-N-step-1.png
- screenshots/issue-N-result.png

Source-Hinweis (wenn klar)
<file:line oder Pattern wo der Fix hingehoert>

Evidence-Pflicht

JEDES Issue braucht mindestens ein Screenshot. Bei Interaktions-Bugs: vorher + nachher. Bei Static-Bugs: ein annotated Shot mit Element-Highlight (snapshot -a Aequivalent).

Phase 7: Health-Score

Aggregiere die Befunde:

Kategorie-Scoring (jeweils 0-100)

Kategorie	Gewicht	Berechnung
Console	15%	0 Errors → 100, 1-3 → 70, 4-10 → 40, 10+ → 10
Links	10%	0 broken → 100, pro broken -15 (min 0)
Visual	10%	Start 100, pro CRIT -25, HIGH -15, MED -8, LOW -3
Functional	20%	dito
UX	15%	dito
Performance	10%	dito
Content	5%	dito
Accessibility	15%	dito

Final = Summe(Kategorie × Gewicht)

Output:

Health-Score: 73/100
  Console: 70 (1 Error)
  Links:   85 (1 broken)
  Visual:  88
  Functional: 65 (1 CRIT + 1 HIGH)
  UX: 92
  Performance: 100
  Content: 100
  Accessibility: 76 (3 MED)

Phase 8: Triage

Sortier alle Findings nach Severity.

Tier	Fix-Scope
schnell	nichts fixen — nur reporten
standard	CRIT + HIGH fixen, MED/LOW als “deferred” markieren
tief	alle inkl. cosmetic fixen

Findings die nicht aus Source-Code fixbar sind (Third-Party-Widget, Browser-Bug, Hosting-Problem) → “deferred”, unabhaengig vom Tier.

Phase 9: Fix-Loop (nur standard + tief)

Pro fixbares Issue, in Severity-Reihenfolge:

9a. Source lokalisieren

# Error-Message
grep -rn "<error-string>" --include="*.html" --include="*.css" --include="*.js" --include="*.md" .
# Component / Section-Name
grep -rn "<component-id>" --include="*.html" .
# Hugo-Shortcode-Probleme
grep -rn "<shortcode>" content/ layouts/

9b. Minimal-Fix

Nicht das ganze File neu schreiben.
Smallest-Change-Possible.
Pro Fix: 1 Commit (atomic) — Marvin will diffen koennen.

9c. Re-QA das betroffene Page

mcp__Claude_in_Chrome__navigate { url: <fixed-page> }
mcp__Claude_in_Chrome__screenshot → screenshots/issue-N-after.png
mcp__Claude_in_Chrome__read_console_messages

Verify-Schritt MUSS sein — Fix-blind-commit ohne Re-QA ist verboten.

9d. Falls Fix nichts bringt

Issue zurueck in “deferred”, aber notiere im Report: “Fix-Versuch mit brachte keine Verbesserung — Wurzel-Ursache unklar”.

Phase 10: Final-QA Pass

Nach allen Fixes: kompletter Re-Run der ursprueglich gefundenen Issues + Smoke-Test der gesamten Site.

Speichere alle Final-State-Screenshots als screenshots/final-*.png.

Phase 11: Report

intern/runs/<datum>-qa-<property>/report.md:

---
id: run-<datum>-qa-<property>
type: run
date: <YYYY-MM-DD>
duration_min: <N>
tier: schnell | standard | tief
property: <agenticventures.de | marvinkuehlmann.com | ...>
url: <getestete URL>
framework: Hugo | static-html | ...
visibility: internal
---
 
# QA-Lauf <Datum> — <Property>
 
## Summary
- Health-Score: <vorher>/100 → <nachher>/100
- Issues gefunden: <N>
- Issues gefixt: <N>
- Issues deferred: <N>
- Pages getestet: <N>
- Screenshots: <N>
 
## Top-3 Fixes (gemacht)
1. ...
2. ...
3. ...
 
## Deferred / TODO
- <Issue, Severity, warum nicht gefixt>
 
## Konsole-Health
<Aggregate Liste aller Konsole-Errors die ueberlebt haben>
 
## Per-Page Details
<Iteration durch die getesteten Pages mit Screenshot-Links>
 
## Regression vs Baseline (wenn baseline existierte)
- Fixed seit Baseline: <Liste>
- Neu seit Baseline: <Liste>
- Score-Delta: <+/-N>

Speichere parallel baseline.json fuer den naechsten Lauf.

Wichtige Regeln

Screenshots im Report anzeigen. Nach jedem Screenshot-Tool-Call: Read das File so dass Marvin es inline sieht. Ohne das sind die Screenshots unsichtbar.
Repro verifizieren. Issues vor dem Schreiben einmal retry — nicht zufaellige Flakes als Bug ausweisen.
Nie Credentials in Report. [REDACTED].
Source-Code lesen NUR fuer Fix-Loop. In Phase 5 (Explore) und 6 (Document) bist du User, nicht Developer.
Konsole nach JEDER Interaktion checken. JS-Errors die nicht visuell auffallen sind trotzdem Bugs.
Mobile-Viewport ist Pflicht bei Hugo-Sites mit Marketing-Content. 375×812 (iPhone 12-Standard).
Nicht refusing. Auch wenn der Diff “keine UI-Aenderung” zu sein scheint — Backend-/Config-Aenderungen ko0nnen sichtbare Effekte haben. Browser auf, testen.
Hugo-spezifisch: Pruefe auf 404 bei Permalinks-Changes (Frontmatter slug oder url geaendert → alte URL bleibt aktiv?). Pruefe Image-Pipeline (hugo --gc --minify lokal vs prod). Pruefe RSS/Sitemap-XML (haeufig vergessen).

Stack-spezifische Hinweise

Hugo (av-website + Landing-Pages)

Konsole-Errors haeufig durch fehlende static/-Assets bei Permalinks-Changes.
hugo server -D zeigt Drafts (Production zeigt sie nicht) — Unterschied beachten.
Image-Processing-Fehler durch nicht-existierende resources — sichtbar als <img src="">.
Hreflang / Sitemap-Issues nach Section-Restruktur.

Static-HTML (Slide-Decks, Email-Signaturen)

Email-Signatures: file://-Test reicht nicht — auch in Gmail-Compose preview-en (siehe extern/outbound/... Email-Test-Workflow).
Slide-Decks: oft mit reveal.js / impress.js — testen ob Next/Prev funktioniert, ob alle Slides rendern.

MCP-Endpoint-HTML (claude.ai Pro Custom Connector Landing)

Nicht Public-Browser-zugaenglich (HTTPS-only von Scalekit-OAuth-Flow). Testen via Custom-Connector-Setup in claude.ai.

Run-Log

Pro Lauf: intern/runs/<YYYY-MM-DD>-qa-<property>/. Cross-Ref in ”_index”.

Quelle

Methodik adaptiert von garrytan/gstack /qa — Phasen-Struktur, Health-Score-Rubrik und Fix-Loop-Pattern. Hier komprimiert + auf den AV-Stack (Hugo, static-HTML, claude-in-chrome MCP) zugeschnitten.

Agentic Ventures Wiki

Explorer

SKILL