fix(tests): run the architecture test on Windows

[Fluory]

Warum

Fixes #78

Arbeitsstand

• Ziel: Der Architektur-Test läuft auf Windows wie auf Linux; pnpm verify kann lokal grün werden.
• Nicht-Ziele: Änderung der Architekturregeln.
• Erledigt: dependency-cruiser wird über node mit dem Paket-Einstieg gestartet; eigenes Zeitlimit (20 s) für den Block nach dem Review.
• Offen: Merge.
• Annahmen: keine.
• Nächster kleinster Schritt: Merge.

Was ist passiert (Klartext)

Ein Test, der die Modulgrenzen der Anwendung prüft, ließ sich unter Windows gar nicht starten – er rief ein Linux-Skript auf. Deshalb waren auf jedem Windows-Rechner sechs Tests rot, obwohl am Code nichts falsch war, und die lokale Gesamtprüfung konnte nie grün werden. Jetzt startet der Test das Prüfwerkzeug direkt über Node. Die Regeln selbst sind unverändert.

Plan-Pflicht (SYSTEM.md §4)

• Kein Auslöser – keine Modulgrenze, öffentliche API, Migration, Auth/Rechte, kein Zahlungs-/Daten-/Infrapfad, höchstens zwei Module, keine Architekturvarianten, umkehrbar
• Auslöser zutreffend – Impact Manifest ausgefüllt (Plan vor Code)

Geändert

• tests/architecture/dependency-rules.test.ts: spawnSync(process.execPath, [node_modules/dependency-cruiser/bin/dependency-cruiser.mjs, …]) statt node_modules/.bin/depcruise; describe(…, { timeout: 20_000 })

Nachweis (SYSTEM.md §11)

• verify:changed: grün – vitest tests/architecture/dependency-rules.test.ts 6/6 unter Windows; vorher rot (6/6, spawnSync status null / ENOENT – Ursache im Issue belegt); ein erster Fix-Versuch mit falschem Dateinamen (dependency-cruise.mjs) blieb rot mit MODULE_NOT_FOUND, korrigiert auf dependency-cruiser.mjs
• verify: lokal Unit 232/232 (erstmals ohne Windows-Ausnahme); Architektur-Block dreimal 6/6 in 11,4 / 12,2 / 12,5 s (≈ 2 s je Fall, Limit 20 s); CI am PR (Linux) grün
• verify:full / E2E-Spec: nicht betroffen
• Manueller Prüfnachweis: nicht nötig – automatisiert belegt
• Frischer Review (P1 vor Ready-for-review; Architektur/API/DB immer): siehe PR-Kommentar – changes requested (Timeout-Risiko unter Windows, gemessen), behoben

Doku-Entscheidung (genau eine)

• Keine langlebige Doku betroffen – Begründung: reine Test-Infrastruktur, kein Produktverhalten; die Doku erwähnt die Windows-Ausnahme nicht
• Doku betroffen und im selben PR aktualisiert:
  • Produktdoku (P0: README): –
  • Technische Doku: –
  • Architekturkarte: –
  • ADR: –
  • CHANGELOG [Unreleased] (sichtbares Feature oder Verhalten – im selben PR, nie „später")

Entferntes oder Umbenanntes: docs/ + README gegrept, Treffer bereinigt: nichts entfernt

Dateigrößen und neue Bausteine (SYSTEM.md §7)

Dateien über 500 Zeilen im Diff (Ausnahmen: generierter Code, Lockfiles, Fixtures, Migrationen, Schemas, Ressourcen, Doku, Konfiguration):

• keine
• bewusst belassen – Begründung: –
• im selben PR nach fachlicher Verantwortung geteilt
• Folge-Issue –

Über 800 Zeilen mit neuer Fachlogik oder über 1000 Zeilen (P1/P2): nicht betroffen

Neue Shared-Komponente, Utility-Datei, Adapter oder fachlicher Service:

• nein
• ja – gesucht nach: –

Subagent-Einsätze

Keine.

Risiken / offene Punkte

• Der Pfad hängt am Layout des Pakets dependency-cruiser (bin/dependency-cruiser.mjs); ändert ein Update es, schlägt der Test laut fehl statt still.

---

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
requestflow	Ready	Preview	Sep 27, 2026 10:04pm UTC
requestflow-ai	Ready	Preview	Sep 27, 2026 10:04pm UTC

[Fluory]

Frischer Review (/review-pr) – unabhängiger Reviewer-Agent ohne Umsetzungskontext, 2026-09-27

1. [Important] – tests/architecture/dependency-rules.test.ts, describe-Block. Das Projekt unit in vitest.config.ts setzt kein testTimeout, also gilt der Vitest-Default von 5 s. – Unter Windows dauert jeder dependency-cruiser-Lauf 2,0–4,7 s. Dreimal isoliert gelaufen: ein Lauf scheiterte mit „Test timed out in 5000ms“ (Fall gamma, 6075 ms), zwei liefen 6/6 grün. In CI (Linux) braucht ein Fall etwa 0,8 s. – Das Akzeptanzkriterium „pnpm test passes on Windows“ ist damit nur wackelig erfüllt; unter voller Last steigt das Risiko. – Empfehlung: für diesen describe einen expliziten Timeout setzen (z. B. { timeout: 20_000 }) und im PR mehrere Windows-Läufe mit Laufzeiten belegen. Keine Assertion wird dadurch schwächer.

Ohne Befund geprüft: AK 1 erfüllt (process.execPath + bin/dependency-cruiser.mjs, kein shell: true); nichts abgeschwächt; Assertions greifen weiter (Status ≠ 0 und Regelname; Fixtures alpha, delta, epsilon, zeta, eta mit je einem Verstoß; gamma verlangt Status 0); CI grün; Doku-Entscheidung ehrlich; Klartext verständlich.

Urteil: changes requested – das zweite Akzeptanzkriterium (Windows grün) ist nachweislich nicht verlässlich erfüllt; der Fix ist eine Zeile.

---

Bearbeitung: Timeout 20 s für den Block gesetzt; unter Windows dreimal 6/6 in 11,4 s, 12,2 s und 12,5 s (≈ 2 s je Fall), volle Unit-Suite 232/232.

[Fluory]

Merge auf Freigabe des Orchestrators (2026-09-27: „mach das“ für die offenen Issues).