Wolfenstein Modloader Buy me a coffeeKaffee spendieren

Wiki / Status and recordsStand und Protokolle

Feedback: agent-cache-orchestrator

ReferenceNachschlagewerk Original page in the GitHub wikiOriginalseite im GitHub-Wiki

In plain wordsIn einfachen Worten

This page is not about the games themselves but about the helper tool that split the reverse-engineering work among several AI workers. Based on two real runs (10 tasks with 8 workers, then 7 tasks with 6 workers), it confirms that all six earlier improvement requests were implemented. It reports three new defects, for example that a stopped worker stays marked as "stale" forever and that token counts showed 0 after about 2.5 million tokens of work. Its main lesson: work that changes a real game installation must be checked by a different worker, because an independent check found two critical errors that the coordinator's own check missed.

  • All 6 points from the first feedback round were fixed and verified.
  • New defects: no way to retire a dead worker, token counting stays at 0, config shows an old version.
  • An independent check found 2 critical errors in code that writes to a 40 GB installation.
  • One of them could have left the installation permanently unrecoverable after a failed write.
  • Key rule: every claim needs a check designed to fail if the claim is false.

Diese Seite handelt nicht von den Spielen selbst, sondern vom Hilfswerkzeug, das die Reverse-Engineering-Arbeit auf mehrere KI-Worker verteilt hat. Auf Basis zweier echter Durchläufe (10 Aufgaben mit 8 Workern, dann 7 Aufgaben mit 6 Workern) bestätigt sie, dass alle sechs früheren Verbesserungswünsche umgesetzt wurden. Sie meldet drei neue Mängel, etwa dass ein gestoppter Worker für immer als "stale" markiert bleibt und die Token-Zählung nach rund 2,5 Millionen Tokens Arbeit 0 zeigte. Die wichtigste Lehre: Arbeit, die eine echte Spielinstallation verändert, muss von einem anderen Worker geprüft werden, denn eine unabhängige Prüfung fand zwei kritische Fehler, die die eigene Prüfung des Koordinators übersehen hatte.

  • Alle 6 Punkte aus der ersten Rückmeldung wurden behoben und geprüft.
  • Neue Mängel: toter Worker lässt sich nicht abmelden, Token-Zählung bleibt 0, Konfiguration zeigt alte Version.
  • Eine unabhängige Prüfung fand 2 kritische Fehler in Code, der in eine 40-GB-Installation schreibt.
  • Einer davon hätte die Installation nach einem abgebrochenen Schreibvorgang dauerhaft unrettbar hinterlassen können.
  • Kernregel: Jede Behauptung braucht eine Prüfung, die fehlschlagen muss, wenn die Behauptung falsch ist.

Technical detailsTechnische Details

Der technische Teil ist auf Englisch – so, wie er im Wiki steht. Unterstrichene Begriffe haben eine Erklärung auf Deutsch.

Written for the further development of the Skill, not as a project documentation. Replaces the report for v3. The basis is two actual runs in the same project (Reverse Engineering of two game archive formats): v3 with 10 tasks and 8 Workers, followed by v3.1/v3.2 with 7 tasks and 6 Workers. For comparison, a prior run with 9 Agents entirely without an Orchestrator.

1. What was implemented from the first report

All six points, each verified:

Point Status
--owns overwrote instead of collecting Fixed, --owns/--after now collect
Slots only changeable via init config --slots, and init now reports state_preserved=yes
Host-ID and Busname are two namespaces register --host-id / bind, Dashboard shows the assignment
Task quality unregulated templates/worker-brief.md plus "the assignment is part of the engineering work"
schedule next --reserve gave everything at once --limit N, default now one task
Tokens not captured finish --tokens, usage

Additionally, without request: exclusive for single-threaded work, the Live Dashboard, and the sentence "A check that cannot fail under an incorrect implementation is not verification." in the Skill text. This had immediate effect in this project — see Section 3.

The Live Dashboard is the best ingredient. It solves exactly the problem I incorrectly described in the first report: I claimed I could not see if Workers followed the protocol. A single look sufficed.

2. New Defects

N1 — A killed Worker remains "stale" forever

Reproduced. Two Workers terminated per Host mechanism, then:

$ acbus schedule reconcile --apply
NO_CHANGES

$ acbus doctor
STALE w-patchverify-a1: 895s
STALE w-suite-a1: 967s

reconcile only acts after stale_seconds (default 600), and even then it only frees the task — the Worker entry remains and reports ATTENTION for the rest of the run. I had to manually retrieve the tasks with task retry.

The core: the Master knows immediately that the Worker is dead, but cannot tell the Bus. It lacks a worker retire <name> (or worker kill) command that closes the entry and frees the task without waiting for a time limit. As long as this is missing, doctor: ATTENTION after the first termination remains permanently noisy — and a health indicator that is always yellow is read by no one anymore.

N2 — Token capture exists but is unreachable on this host

$ acbus usage
TOTAL tokens=0

After approximately 2.5 million tokens of actual work. The reason is not an error in usage, but a break in the flow: Workers never call finish. In the Claude code flow, the subagent reports via the host-specific return channel, and the Master learns the numbers from the notification (subagent_tokens, tool_uses, duration_ms). The Bus sees nothing of this.

Thus finish is dead code in practice, along with token capture and the F state. Two exits:

  • Clarify in the Skill text that the Master calls finish with the numbers from the Host notification as soon as they arrive — then it belongs in the control cycle alongside task verify.
  • Or have task verify accept the numbers optionally (--tokens), because that is indeed the step the Master makes at this point.

Either way: As long as "per token" is claimed, the usual path should also deliver numbers.

N3 — config reports an outdated version

$ acbus init --slots 3
.agent-cache v3.2 initialized slots=3 retries=2 state_preserved=yes

$ acbus config
{"v":"3.1", "slots":7, ...}

The configuration file retains the version under which it was created. This leads astray in a bug report. init should increment v.

3. The most important finding: the check limit hangs on the Master, and the Master errs

This is not a defect in the bus, but a gap in the procedure, and it nearly cost money in this run.

A worker repaired five errors in the module that writes to a 40-GB installation. I personally verified — installation unchanged, all existing checks green, reproducing the worker's proof script — and set task verify. The task proceeded on D.

A later started, independent verification worker found two critical errors in the same repair. One of them would have left a permanently unrecoverable installation after a failure midway through writing: the rollback refused itself because the check treated its own write operations as part of a game update — and every subsequent attempt did too.

My verification only checked the happy paths. The second worker found it because its mandate forced it to build a counter-check for every assurance that was intentionally designed to fail.

Proposal, costs no lines of code: In the skill text, directly next to the sentence about checks that cannot fail —

For tasks that change persistent state outside the repository, the check must come from a different worker than the implementation. The Master is unsuitable for this: he wrote the task and shares its blind spots.

Optionally mechanical: capture task verify <id> --by <worker> and let doctor warn if a task with write access was taken by the Master or by the executing worker itself.

4. Smaller Observations

Reservation deadline against task length. reservation_seconds is set to 120. A viable task for a heavy operation in my experience is 40 to 60 lines; writing four of them takes longer than the deadline. --limit mitigates this. A sentence in the skill text would suffice: write tasks first, then reserve, then start.

doctor does not say what is wrong. The dashboard shows Health: ATTENTION (2) without listing the two findings. You must call doctor separately. Two lines inline would save the second call.

Truncated status line. The non-live dashboard truncates the CURRENT column to terminal width — in a pipe, this results in losing exactly the most informative data. An option --full or wrapping instead of truncation.

What proved to be the most valuable sentence in the task. Provable from this run: the combination of "build a counter-check for every assurance that is intentionally designed to fail" and "report failed hypotheses as failures, rather than smoothing them over". Every worker that had both in its mandate provided counter-checks; the finding from Section 3 came precisely from there. In templates/worker-brief.md, these two lines should go at the front, not under "Verification expectations" at the end.

5. Sorted by Utility

  1. N1 worker retire — without this, doctor remains permanently yellow after the first abort and is therefore useless.
  2. Section 3 in the skill text — free of cost, and in this run a 40-GB installation would have hung on it.
  3. N2 finish in the control cycle or verify --tokens. Without numbers, "per token" remains an assertion.
  4. N3 Version stamp raised in config.
  5. doctor findings inline in the dashboard.
  6. Note on reservation deadline in the skill text.

6. Conclusion

v3.2 is significantly better than v3, specifically at the points mentioned in the initial report. What remains is no longer a tool problem but a procedure problem: The bus manages tasks reliably, but the quality gate still hangs on a Master who shares the same blind spots as the task he wrote. The cheapest lever against this is a paragraph in the skill text, not more mechanics.