HT002 · Auf macOS installieren und zum Laufen bringen¶

2026-09-07, die Aufgabe war ein Satz: cppide klonen, auf dieser macOS-Maschine installieren und zum Laufen bringen. Das Ergebnis: $38.24 / 4 Schritte / rund 1 Stunde, das Programm lief tatsächlich auf macOS (PID 96040, arm64 Mach-O), und das Verdict lautete nicht erreichbar — es kam nach oben zur Nachfrage beim Menschen, der Mensch entschied sich, es zu akzeptieren.

Das war der erste Run mit Goal Guard — alles, was aus den Lehren von HT001 umgebaut wurde, ging an diesem Tag zum ersten Mal gegen die echte API. Er hat eine Falle abgefangen, in die HT001 noch gelaufen war, und dabei ein neues Versagen in genau entgegengesetzter Richtung erzeugt: Aus git clone && make && ./cppide wurde eine Stunde. Der wertvollste Teil dieser Seite ist das Zweite.

Das Rohprotokoll liegt in human-test/HT002/, die Abrechnung ergibt sich aus runs/manifest.json und runs/sessions.db:

python tools/analyze_run.py human-test/HT002/runs

Die Form dieses Runs¶

Kosten, Turns und Dauer je Schritt¶

Die Spalte Dauer ist die Summe der gerundeten Einzelschritte. Am Rohprotokoll nachgerechnet ergeben die vier duration_s in manifest.json exakt 3471.53 Sekunden = 0.9643h; diese Seite behält 0.97h bei, die Differenz beträgt 0.006h.

Das Geld steckt fast vollständig im Schritt „Arbeiten" — $35.8950 sind 93.9%. Der erste Abschnitt unten erklärt, wofür dieses Geld ausgegeben wurde und warum es so nicht hätte ausgegeben werden dürfen.

1. Die Schlagzeile: Es machte aus git clone && make && ./cppide eine Stunde¶

Das ist der wichtigste Befund dieses Runs, wichtiger als alles, was unten unter „die Mechanik lief durch" steht.

Im Schritt „Ziel setzen" schrieb sich der Judge selbst eine Verdict-Checkliste mit 15 Punkten (Original in 目标.md unter .flower/notes/). Nach Art aufgeschlüsselt:

Nur ein Drittel prüft, ob das Ding überhaupt benutzbar ist. Sechs Punkte prüfen, ob es selbst die Regeln eingehalten hat — einer davon prüft die mtime des Verzeichnisses .flower/, also des Verzeichnisses des Frameworks selbst.

Der Checklistenpunkt zu .flower/ hat sich selbst durchfallen lassen¶

Das ist kein theoretisches Problem. In der Verdict-Runde schrieb der Judge unter „nicht bestanden" wahrheitsgemäß:

mtime aller Dateien unter .flower/ älter als der Session-Beginn — wörtlich fehlgeschlagen: INDEX.md 16:14, artifacts/01–05 (15:40–16:12), notes/决策-项目形态与验收路径.md 15:43 wurden alle innerhalb der Session geschrieben.

Der Grund: Das Framework verlangt zwingend, lange Artefakte nach .flower/artifacts/ und Entscheidungen nach .flower/notes/ zu schreiben. Der eine Punkt der Verdict-Checkliste verlangt, dieses Verzeichnis nicht anzufassen. Zwei Regeln prallen direkt aufeinander, und zwar von der Verdict-Checkliste selbst erzeugt — hätte der Worker gar kein langes Artefakt geschrieben, wäre er konformer gewesen.

Es hat sich nicht durchgemogelt: Der Schritt „Arbeiten" führte diesen Konflikt im Abschlussbericht von sich aus auf, und die Entscheidungsnotiz hält den Umgang damit fest — keine einzige vorhandene Datei angefasst (需求.md, 目标.md, 问答记录.md haben vorher wie nachher identische mtime und MD5), nur Neues hinzugefügt. Der Judge stimmte nach Prüfung zu, dass „die Manipulation, gegen die dieser Punkt schützen soll, nicht stattgefunden hat", listete ihn aber regelkonform trotzdem unter „nicht bestanden" und überließ die Entscheidung dem Menschen.

Ursache 1: Grenzen wurden zu Verdict-Punkten gemacht¶

Die in der Clarify-Phase erfragten Grenzen („darf nur innerhalb des Projektverzeichnisses installieren", „Businesscode nicht anfassen") beschränken eigentlich, wie gearbeitet wird, wurden aber als Prüfpunkte für das Artefakt formuliert. So entstanden Einträge wie „mtime von .zshrc prüfen" und „mtime von .flower/ prüfen".

Grenze ≠ Verdict-Punkt. Grenzen beschränken den Prozess, Verdict-Punkte verifizieren das Ergebnis. Wenn beides vermischt wird, bedeutet jede zusätzliche Grenze einen zusätzlichen Verdict-Punkt — und genau Grenzen werden in der Clarify-Phase ausdrücklich zum Vollschreiben ermutigt: In CLARIFIER_RULES steht wörtlich „klar benennen, was nicht getan wird. Dieser Abschnitt hält jeden weiter unten Arbeitenden im Zaum".

Am Rohprotokoll lässt sich jedes Glied dieser Verstärkungskette nachvollziehen: Im Brief lautet die Grenze „das im aktuellen Verzeichnis bereits vorhandene .flower/ und runs/ nicht anfassen", in der Verdict-Checkliste wird daraus „die mtime aller Dateien unter .flower/ ist älter als der Beginn dieser Session" — aus „das Vorhandene nicht anfassen" wurde „im gesamten Verzeichnis darf keine neue Datei entstehen".

Ursache 2: JUDGE_RULES übt Druck nur in eine Richtung — und wurde am selben Tag hinzugefügt¶

Früher am selben Tag wurde aus den Lehren von HT001 Folgendes in JUDGE_RULES geschrieben:

• „Jeder Punkt muss an Ort und Stelle verifizierbar sein", „Was fehlt oder vage ist, ergänzt du"
• „Beurteilt wird das Artefakt, nicht der Quellcode" (mit dem macOS-Negativbeispiel)
• „Punkte, die in dieser Umgebung nicht verifizierbar sind, sofort markieren"
• „Erst nachsehen, wo du bist (uname -a ist erlaubt)"

Jeder einzelne Punkt drängt zu mehr Prüfung, zu mehr Strenge. In der gesamten Regelmenge steht kein einziger Satz, dass das Ganze im Verhältnis zur Größe der Aufgabe stehen soll.

Anders gesagt: Die Optimierung entlang des HT001-Versagens „zu leichtfertig bestanden erklärt" erzeugte das exakt entgegengesetzte Versagen — Überprüfung. Das ist selbst gebaut, kein Problem des Modells.

Ursache 3: Überlagerung mit issue #3¶

Was tatsächlich blockierte, waren zwei Portabilitätsdefekte auf macOS:

• src/proc.cpp benutzt ::sigemptyset, doch das Apple SDK definiert es nach dem Funktionsprototyp zusätzlich als funktionsartiges Makro (nur durch #ifndef _ANSI_SOURCE bewacht), sodass ::sigemptyset(&s) zu ::(*(&s)=0,0) expandiert — Syntaxfehler
• src/ui.cpp benutzt ::_exit, ohne <unistd.h> einzubinden

Drei Zeilen hätten gereicht. Aber der Nutzer hatte in der Clarify-Phase „Businesscode nicht anfassen" geantwortet, der Agent hielt sich strikt daran und ging deshalb den Umweg über Compiler-Flags, Subagents und Entscheidungsnotizen. Hätte er an dieser Stelle einwerfen können „die zwei Zeilen dürft ihr ändern", wäre nach zehn Minuten Schluss gewesen. Als Verbot formulierte Grenzen werden maximal streng ausgelegt, und mittendrin gibt es keinen Kanal, um sie zu lockern.

Im Rohprotokoll ist zu sehen, wie lang dieser Umweg war: insgesamt vier Blockadepunkte, von denen sich nur der mit ::_exit durch reine Compiler-Flags lösen ließ; für ::sigemptyset wurden 6 Kombinationen aus -D/-U durchprobiert, alle gescheitert (die _POSIX_C_SOURCE-Reihe zerlegt zusätzlich st_mtimespec und O_CLOEXEC). Diese Sackgasse allein produzierte einen 13.6K großen Machbarkeitsbericht.

Fairerweise: Die Grenze erzwang die bessere Lösung¶

Die endgültige Lösung war nicht, den Quellcode zu ändern, sondern im Makefile einen Shim-Header zu generieren, der nur #undef macht, und ihn per -include zwangsweise voranzustellen:

$(MACSHIM):
    @printf '#include <signal.h>\n#undef sigemptyset\n#undef sigfillset\n...' > $@
CPPFLAGS += -include $(MACSHIM) -include unistd.h

Das ist besser als eine Quellcode-Änderung — am Upstream-Repository muss keine Zeile angefasst werden, und jeder kann nach dem Klonen bauen. Der Shim wird nach build/ erzeugt, nicht eingecheckt, clean bekommt ein rm -rf build zum Aufräumen, und make -n UNAME_S=Linux zeigt gemessen kein -include in der Expansion — der Linux-Pfad bleibt unverschmutzt. Am Ende betrifft git diff genau eine Datei, Makefile, mit +14 / −2.

Die Grenze erzeugte also eine teurere, aber bessere Lösung. Das Problem ist nicht, dass etwas falsch gemacht wurde, sondern dass dieser Trade-off nicht dem Menschen überlassen wurde — und der Grund dafür ist genau issue #3.

2. Was der Goal Guard richtig gemacht hat¶

Die Mechanik lief vollständig durch, und die beiden Änderungen dieses Tages haben direkte Fingerabdrücke im Artefakt hinterlassen.

Der erste Punkt seiner Verdict-Checkliste:

uname -a zeigt Darwin 25.2.0 (macOS) … alle folgenden Punkte zu „läuft/öffnet sich" müssen Ergebnisse sein, die auf dieser Maschine tatsächlich erzielt wurden, Schlüsse der Art „im Quellcode gibt es einen macOS-Zweig, also sollte es laufen" werden nicht akzeptiert

Genau das ist der Satz, der an jenem Morgen aus den Lehren von HT001 in JUDGE_RULES geschrieben wurde.

Es hat die am selben Tag hinzugefügte Markierung [此环境无法验证:…] dreimal benutzt, jeweils mit Begründung — devtools console (kein steuerbarer Browser vorhanden, und dafür einen Headless-Browser zu installieren überschreitet die Grenze), manuelles Klicken (erfordert einen Menschen vor dem Bildschirm), persönliche Bestätigung (kann nur er selbst geben).

Der erste Satz des Judge war: „Ich urteile nicht auf Basis dieses Gesprächsprotokolls. Ich gehe an den Tatort." Dann:

file cppide        → Mach-O 64-bit executable arm64
lsof -p 96040      → txt zeigt auf /Users/hechenyu/explore/test-ide/cppide/cppide
                     seit 16:10, um 16:15 noch am Leben

Es schrieb selbst: „In die Falle „ein Linux-ELF ausgeliefert" aus den Meta-Lehren sind wir diesmal nicht getappt. Ein Linux-ELF kann auf Darwin unmöglich als PID laufen. Das ist nicht aus dem Makefile abgeleitet."

Es prüfte außerdem, dass der Quellcode wirklich unangetastet blieb: Die mtime aller .cpp / .h unter src/ ist durchgehend 15:32 (Zeitpunkt des Klonens), geändert wurde nur Makefile (16:06), und .o / .d (16:07) sind neu gebaute, getrackte Build-Artefakte.

Es hat auch offengelegt, wo es selbst nicht hinreicht. Das Bash des Judge ist auf das Arbeitsverzeichnis beschränkt, den Abgleich per git ls-remote und die mtime von ~/.zshrc konnte es nicht ausführen und musste die Ausgabe des unabhängigen Audits übernehmen — diese beiden Punkte hat es gesondert aufgeführt mit dem Hinweis „das konnte ich nicht selbst nachfahren".

3. Verdict „nicht erreichbar", dann Nachfrage beim Menschen¶

Dreiwertiges Verdict plus menschlicher Eingriff — die ganze Kette lief zum ersten Mal echt durch.

Das Verdict lautete nicht erreichbar, es hing am Screenshot-Punkt: screencapture -x und -l <window-id> gaben beide could not create image from display zurück — die TCC-Berechtigung für Bildschirmaufnahme war nicht erteilt, und das Erteilen erfordert, dass ein Mensch in den Systemeinstellungen klickt, was selbst wieder eine von den Grenzen verbotene Systemänderung ist.

„Noch eine Runde Subagents zaubert dieses Bild auch nicht herbei. Nach den Regeln darf das nicht als bestanden gelten und sollte auch nicht als ‚noch nicht erreicht' gelten, es ist schlicht nicht erreichbar, hier muss man anhalten und an den Menschen übergeben."

Damit stieg die Zahl der „prinzipiell nicht verifizierbaren" Punkte von 3 auf 4 — 4 von 15 Punkten sind in dieser Umgebung schlicht nicht verifizierbar, und das wurde erst nach $35.8950 Arbeiten und $1.4037 Verdict entdeckt. Der Schritt „Ziel setzen" kostete nur $0.4117; genau dort hätte es auffallen müssen.

Das Framework legte dieses Ergebnis dem Menschen vor (festgehalten im Q&A-Protokoll als q7), drei Optionen, der Mensch wählte „dieses Ergebnis akzeptieren", das Gate gab frei, der Workflow war abgeschlossen.

Es hat außerdem einen Ersatz abgelehnt. Der Worker las per AppleScript den Text des Terminalfensters zurück, eine echt gerenderte TUI — Zeilennummernspalte, Inhalt von src/main.cpp, Panelleiste ─[编译]─[运行]─[AI*]─[输入]─, Statusleiste 练习模式 │ main.cpp │ 1:1 │ C++, kein Weißbild und kein Fehlerbild. Der Judge sagte:

„Der Arbeitende hat das nicht als ‚Bild gesehen' ausgegeben, diese Selbstbeschränkung ist richtig. Aber es ersetzt den geforderten Checklistenpunkt nicht, und ich rechne es ihm auch nicht an."

4. allowed_tools ist keine harte Whitelist¶

Bei der Analyse dieses Runs kam ein Fakt zutage, der der Behauptung widerspricht. Tool-Aufrufe nach Session aufgeschlüsselt:

goal_step hat keinerlei Codepfad, der can_run durchreicht, die Zeile „Ziel setzen" kann also unmöglich ein Konfigurationsproblem sein.

Verifikation per $0.1-Sonde: Ein Agent mit allowed_tools=["Read"] soll eine Datei schreiben —

Write → 权限层:"requested permissions to write ... but you haven't granted it yet"
Bash  → 路径安全:"Output redirection was blocked. For security, Claude Code may
        only write to files in the allowed working directories"

Das Modell kann Tools aufrufen, die nicht in der Whitelist stehen, es wird nur von der Permission-Schicht und der Pfadsicherheit abgefangen. Also:

• allowed_tools ist eine Liste genehmigungsfreier Tools, keine ausschließende Whitelist
• Was clarify() / judge() damals wirklich schützte, war der geerbte permission_mode="default"
• Und beide haben delegate_only=False → kein delegate_guard-Hook. Der Koordinator ist durch Hooks geschützt, diese beiden Rollen hatten damals keinerlei flower-eigenen Mechanismus

Im Docstring von clarify() steht „keine Schreibwerkzeuge — es kann gar nicht loslegen", und der ganze Negativtest für $0.8908 wurde für diesen Satz gemacht. Die mechanische Begründung dieses Satzes ist falsch.

5. Die Kontextkurve: Schrittgrenzen setzen zurück¶

Turn   1   36.8K
Turn  25   80.2K   ← Spitze
Turn  26   32.9K   ← Absturz: neuer Schritt = neue Session (resume_from=None)
Turn 121   64.8K

Drei der vier Messpunkte (Turn 1 / 25 / 121, 36.8K / 80.2K / 64.8K) decken sich einzeln mit dem Rohprotokoll; die 32.9K bei Turn 26 lassen sich nicht nachrechnen: Spielt man die Assistant-Nachrichten des Main-Threads nach store_key sortiert ab, ergibt die 26. Nachricht (die erste der neuen Session) für input + cache_read + cache_creation 31,972 Token = 32.0K, während 32.9K der zweite Wert derselben Session ist (31,970 + 948). Diese Seite behält 32.9K bei — die Differenz sind 0.9K, die Aussage „steiler Abfall" gilt für beide Werte.

HT001 stieg monoton bis 185.9K — ein Schritt lief 10 Stunden. HT002 wurde in vier Schritte zerlegt, jeder Schritt öffnet eine neue Session, der Kontext wird strukturell zurückgesetzt. Das ist der direkte Effekt des Designs „Brief und Ziel sind eingefrorene Dokumente, nachgelagert bekommt man das Dokument, nicht das Gespräch" — auf der Kurve sichtbar.

Cache-Trefferquote 90.8% (HT001: 96.1%). Die Trefferquote steigt mit der Sessionlänge, kurze Sessions sind pro Einheit also etwas teurer — das ist die andere Seite derselben Medaille wie die Schlussfolgerung in Abschnitt 3 von HT001.

6. Vergleich mit HT001¶

Die letzte Zeile verdient Aufmerksamkeit. HT002 hat kein einziges wiederverwendbares Skript geschrieben — die Aufgabe dauerte nur eine Stunde, es gab nichts, das sich zu konservieren lohnte. Das zeigt: Der Wert der Workbench wächst mit der Länge der Aufgabe, bei kurzen Aufgaben ist sie reiner Overhead.

Wie das Rohprotokoll aussieht¶

.flower/INDEX.md ist der Workbench-Schnappschuss zum Ende dieses Runs, direkt vergleichbar:

Unter runs/ liegen manifest.json (4 Schritteinträge) und sessions.db. Die Datenbank enthält 10 Sessions: 4 Main-Thread-Sessions plus 6 Subagent-Sessions — passend zu „6 Subagents".

Im Q&A-Protokoll stehen insgesamt 7 Fragen: q1–q6 stammen aus der Clarify-Phase (passend zu den 6 ask-Aufrufen im Schritt „Anforderungen klären"), q7 ist das menschliche Gate nach dem Verdict „nicht erreichbar".

Was dieser Run am Framework geändert hat¶

Dieser Run in einem Satz: Wer entlang des letzten Versagens optimiert, erzeugt leicht ein neues Versagen in der Gegenrichtung. HT001 brachte dem Framework bei „nicht leichtfertig bestanden erklären", HT002 führte sofort vor, was passiert, wenn dieser Regel kein „nicht überprüfen" beigestellt ist. Beides muss in JUDGE_RULES stehen, fehlt eines, kippt es.