Merge branch 'claudedo/9e3071992eca4eb79057d2c675cc57ca'
This commit is contained in:
mika kuns
@@ -0,0 +1,165 @@
|
||||
# Handoff — List-handler run on list "Claude do", 2026-08-05
|
||||
|
||||
Repo: `C:\Private\ClaudeDo` · List id: `5f973815-050a-4136-94f0-1506a5d4560a` · Branch: `main` (nothing pushed)
|
||||
|
||||
Predecessor session ran the five-phase list handler over 11 briefed tasks and, along the way,
|
||||
absorbed the 9-child "Usage Monitor" unit. **Phases 0–3 are complete for the brief.** What is
|
||||
left is Phase 4 (review + merge) for three tasks, plus the Usage chain.
|
||||
|
||||
---
|
||||
|
||||
## 1. Do this first — three brief tasks sit in WaitingForReview
|
||||
|
||||
Merge in **this order** (the order was chosen with the user and matters):
|
||||
|
||||
| # | Task | Id | Note |
|
||||
|---|------|----|------|
|
||||
| 1 | Feat: Merge zurücknehmen — Merge-Commit festhalten + `revert_merge` | `9e307199-2eca-4eb7-9057-d2c675cc57ca` | Migration + new tool. Merge **before** #2 |
|
||||
| 2 | Feat: Verifikations-Gate nach dem Merge | `0b2fbb48-d44c-4155-8c21-d3464c0bd5c2` | Depends on #1's merge-SHA persistence; both edit `TaskMergeService.cs` |
|
||||
| 3 | Feat: Antwortfeld auf der Roadblock-Karte | `8c1c213004574c4fad6beb75b84b70d7` | UI + localization (en **and** de) |
|
||||
|
||||
For each one:
|
||||
|
||||
1. `get_task_diff(taskId, stat=true)`, then the full diff if non-trivial. Sanity-check against
|
||||
the task description (they are long and precise — the acceptance criteria are the checklist).
|
||||
2. `review_task(taskId, decision="approve", leaveConflictsInTree=true)`.
|
||||
3. On conflict: open the files under the returned `repoPath`, resolve keeping **both** sides'
|
||||
intent, then `continue_merge(taskId)`. Conflicts are expected and normal here.
|
||||
4. **After every merge, verify `main`** (see §4). This is non-negotiable — see §5.
|
||||
|
||||
Expected conflicts: `TaskMergeService.cs` between #1 and #2; `src/ClaudeDo.Worker/CLAUDE.md`
|
||||
and `src/ClaudeDo.Data/CLAUDE.md` in nearly every merge (doc bullet lists — trivial, keep both
|
||||
sides' entries).
|
||||
|
||||
## 2. Then the Usage Monitor unit
|
||||
|
||||
Parent `439a4daf166f4ab5b0fa415693d2c80d` ("Usage Monitor hinzufügen") is `WaitingForChildren`
|
||||
and has **no worktree of its own**. It has 9 children. Four are merged, one is in flight, four
|
||||
are Idle.
|
||||
|
||||
| Child | Id | State |
|
||||
|---|---|---|
|
||||
| #38 Data: Usage-Gate-Schwellen + Modell-Spalte | `c1c999b6-b800-4b6b-a821-fbc028c15772` | merged `b1efcdc` |
|
||||
| #39 Worker: OAuth-Usage-Client + Poller | `f657e316-ad72-4f45-8036-460841fc8997` | merged `b126a21` |
|
||||
| #40 Worker: UsageGate | `06a7cc32-6ab7-4758-98f4-bee77149b2bf` | merged `1ee21b5` |
|
||||
| #41 Worker: TranscriptUsageReader | `840fdb98-1c0e-4219-8062-c8769233fc14` | merged `334cf1e` |
|
||||
| #42 Worker: Hub-Surface für Usage | `c1df5b9a-b911-4fe8-aab4-5876d9d85793` | **re-queued, in flight — read §5 before touching** |
|
||||
| #43 UI: Usage-Pill | `f74b44d9-7e48-4bfe-9d89-075e194d1fc9` | Idle — queue once #42 is merged |
|
||||
| #45 UI: Gate-Schwellen im Settings-Modal | `06068810-5b5c-4635-80dd-62eeba89fb8c` | Idle — queue once #42 is merged (parallel with #43) |
|
||||
| #44 UI: Usage-Monitor-Modal | `82488d2a-8ff7-41b8-b791-367959a8f827` | Idle — needs #42 **and** #43 merged |
|
||||
| #46 Docs: Usage Monitor | `9c8cffe0-8f7b-401e-a4f0-33b937047082` | Idle — last, after everything is merged |
|
||||
|
||||
**The chain is strictly serial and you must respect it.** Every child forks from `main`, and each
|
||||
one's own description hard-requires the earlier ones. Queueing them all at once is exactly what
|
||||
produced the original roadblock: #40 ran, found its prerequisite types only on unmerged sibling
|
||||
branches, and returned `Done` having written **zero** code. So: merge a child → then queue the
|
||||
next → verify `main` → repeat.
|
||||
|
||||
When the last child is merged the parent surfaces for review by itself; approve it to close the
|
||||
unit (it has no worktree, so it approves straight to Done).
|
||||
|
||||
## 3. Cheap status polling — important
|
||||
|
||||
`list_tasks` and `batch_get_tasks` return full descriptions and **blow the token limit** on this
|
||||
list (`list_tasks` over 52 tasks = ~206,000 chars; that is literally one of the bugs this run
|
||||
fixed). Do not poll with them. Poll the DB read-only instead:
|
||||
|
||||
```bash
|
||||
PYTHONIOENCODING=utf-8 python - <<'EOF'
|
||||
import sqlite3
|
||||
c=sqlite3.connect("file:C:/Users/mika.kuns/.todo-app/todo.db?mode=ro",uri=True)
|
||||
for i,s in c.execute("select id,status from tasks"):
|
||||
print(s, i)
|
||||
EOF
|
||||
```
|
||||
|
||||
`list_worktrees` is also compact and safe. **New this run:** `wait_for_task_change(taskIds,
|
||||
timeoutSeconds)` is now merged and is the proper primitive — it returns as soon as any listed
|
||||
task leaves Queued/Running (server-clamped to 170 s). Prefer it over sleeping.
|
||||
|
||||
## 4. Verify main after every merge
|
||||
|
||||
```bash
|
||||
dotnet build src/ClaudeDo.Worker/ClaudeDo.Worker.csproj -c Release
|
||||
dotnet test tests/ClaudeDo.Worker.Tests/ClaudeDo.Worker.Tests.csproj -c Release
|
||||
dotnet test tests/ClaudeDo.Data.Tests/ClaudeDo.Data.Tests.csproj -c Release
|
||||
```
|
||||
|
||||
For the UI/localization task (#3 above, and children #43–#45) also:
|
||||
|
||||
```bash
|
||||
dotnet build src/ClaudeDo.App/ClaudeDo.App.csproj -c Release
|
||||
dotnet test tests/ClaudeDo.Ui.Tests/ClaudeDo.Ui.Tests.csproj -c Release
|
||||
dotnet test tests/ClaudeDo.Localization.Tests/ClaudeDo.Localization.Tests.csproj -c Release
|
||||
```
|
||||
|
||||
`.slnx` needs .NET 9 — build individual csproj files, `-c Release` (a running Worker locks Debug).
|
||||
|
||||
Baseline as of this handoff: Worker **753/753**, Data **143/143**, build 0 warnings.
|
||||
|
||||
## 5. The trap that cost this run the most time
|
||||
|
||||
Two children "failed" with `"Claude exited with code 1 and no result"`. **That is a CLI crash,
|
||||
not bad code.** In both cases the worktree held complete work that built with 0 warnings and
|
||||
passed the full suite (#40: 732/732, #42: 766/766) — the run just died before the auto-commit.
|
||||
|
||||
- **Never `reset_failed_task` on such a task** — it discards the worktree and destroys the work.
|
||||
- Instead: `cd` into the worktree, `git status`, build + test it. If green, set the task
|
||||
`Queued`. The worktree is preserved and the agent resumes its own session (`--resume`),
|
||||
finds its work and commits it. That is how #40 was recovered.
|
||||
- #42 is mid-recovery right now via exactly this route. If it failed again, verify its worktree
|
||||
(`C:\Private\.claudedo-worktrees\claude-do\c1df5b9a-b911-4fe8-aab4-5876d9d85793`) before
|
||||
doing anything destructive.
|
||||
|
||||
Second trap: git merges cleanly and the **compiler** still breaks. It happened again this run —
|
||||
`Usage/UsageModels.cs` was an add/add conflict, and `src/ClaudeDo.Worker/CLAUDE.md` merged
|
||||
"cleanly" into a file with the `Usage/` folder documented **twice**. Always read what a clean
|
||||
merge produced, and always run §4.
|
||||
|
||||
## 6. Phase 0–3 decisions already made (do not redo)
|
||||
|
||||
Dedupe: four candidate pairs examined, **nothing cancelled**. Decisions:
|
||||
|
||||
- `05827da5` ↔ `81e37801` — kept both, and `05827da5` was **re-scoped**: its "lean status query"
|
||||
half was removed because `81e37801`'s wait tool covers it. `05827da5` now owns only the
|
||||
brief-description rendering. Both are merged.
|
||||
- `a76d9547` ↔ `99732497` — kept both, `99732497` merged first. Done.
|
||||
- `0b2fbb48` ↔ `9e307199` — kept both, `9e307199` merges first. **This is item #1/#2 in §1.**
|
||||
- `20c78c95` ↔ `a76d9547`(b) — kept both, different actors. Done.
|
||||
|
||||
Phase 2: all 11 tasks carry acceptance criteria, real file+line references and out-of-scope
|
||||
sections. Three that were one-liners were researched and rewritten after asking the user
|
||||
(ConPTY fix approach, maxTurns-only scope, roadblock reply-box design).
|
||||
|
||||
Run config: `maxParallelExecutions` = **3**. No list config exists, so effective max turns was
|
||||
the global **100**; it was raised to **200** per-task on the five heaviest via `set_task_config`.
|
||||
`0b2fbb48`, `9e307199` and `8c1c2130` still carry that override.
|
||||
|
||||
## 7. Open follow-ups worth new tasks
|
||||
|
||||
1. **`~/.todo-app/prompts/planning.md` shadows the planning prompt.** `PromptFiles.EnsureExists`
|
||||
only writes a default when the file is absent, and that file exists (dated Jun 2). The
|
||||
`maxTurns` guidance merged in `65db1cd` therefore **does not reach real planning sessions**
|
||||
until that file is updated by hand. `system.md` and `agent.md` are shadowed too.
|
||||
`merge-helper-system.md`/`merge-helper-initial.md` do **not** exist, so this run's handler
|
||||
prompt changes are live.
|
||||
2. **MCP task DTOs expose no parent/child link.** The 9-child Usage unit had to be reconstructed
|
||||
from `sortOrder` and creation timestamps. `get_task`/`list_tasks` should return
|
||||
`parentTaskId` / `blockedByTaskId`.
|
||||
3. **Visual verification open** on: the ConPTY fix (open a tile on a task whose description
|
||||
contains `->`), and — once merged — the roadblock reply box and the verify-gate field in the
|
||||
list settings modal.
|
||||
4. **`"exited with code 1 and no result"` is too common.** Three runs died that way today, two
|
||||
with finished work. Worth investigating whether the auto-commit step can be made to survive
|
||||
a late CLI crash.
|
||||
5. Nothing has been **pushed**. `main` is 22 commits ahead of `8d7ba1e`.
|
||||
|
||||
## 8. Rules this session operated under
|
||||
|
||||
- Drive merges through the MCP tools. Never raw `git merge` / `reset` / `checkout`.
|
||||
- Hand-resolve only markers the tools left behind, then `continue_merge`. When committing by
|
||||
hand is unavoidable, stage **explicit paths** — never `git add -A`: the main checkout is
|
||||
shared with other sessions.
|
||||
- For a parent/children unit merge, pass the **parent** id to `continue_merge` / `abort_merge`.
|
||||
- Ask the user on anything ambiguous, risky, or destructive.
|
||||
- Never `delete_task` to dedupe — `Cancelled` keeps it visible and resettable.
|
||||
@@ -0,0 +1,196 @@
|
||||
# Usage-Optimierung — Befunde und Messmethodik
|
||||
|
||||
Stand: 2026-08-05. Ausgangsfrage: Wie lassen sich autonome ClaudeDo-Agents
|
||||
token-effizient betreiben? Abrechnung läuft über **Abo-Session-Limits, nicht über
|
||||
die API** — relevant ist roher Token-Verbrauch gegen 5h-/7d-Fenster, nicht Geld.
|
||||
|
||||
Dieses Dokument ist bewusst kompakt gehalten. Was eine Session früh in den Prefix
|
||||
lädt, wird mit jeder weiteren Nachricht multipliziert (siehe Befund 5) — ein
|
||||
30k-Handover-Dokument würde das Problem reproduzieren, das es beschreibt.
|
||||
|
||||
---
|
||||
|
||||
## 1. Verbrauchsstruktur
|
||||
|
||||
Gemessen über alle Transcripts unter `C:\Users\mika.kuns\.claude\projects`.
|
||||
|
||||
| Posten | Roh-Token | Anteil |
|
||||
|---|---:|---:|
|
||||
| Cache-Read | 3.118.025.644 | 95,6 % |
|
||||
| Cache-Write | 140.783.227 | 4,3 % |
|
||||
| Output | 22.466.702 | 0,7 % |
|
||||
| Input frisch | 141.496 | 0,0 % |
|
||||
|
||||
**Kontext-Resend = 99,3 % des Rohverbrauchs.** Auch unter API-Preisgewichtung
|
||||
(read 0,1× / write 1,25× / out 5×) bleibt es bei 81,3 %. Die Rangfolge ist gegen
|
||||
jede plausible Gewichtung robust.
|
||||
|
||||
Verstärkung: ~3,6 Mio einzigartiger Inhalt → 1,59 Mrd abgerechnete Prompt-Token
|
||||
in ClaudeDo-Sessions. **Jeder Kontext-Token wird im Schnitt ~425× erneut
|
||||
abgerechnet.**
|
||||
|
||||
## 2. Scope-Split — wer verbraucht
|
||||
|
||||
| Scope | Roh-Token | Anteil |
|
||||
|---|---:|---:|
|
||||
| INTERAKTIV (Mikas eigene Sessions) | 2.690.028.785 | **81,6 %** |
|
||||
| AGENT (ClaudeDo-Runs) | 606.222.055 | **18,4 %** |
|
||||
|
||||
Interaktiv nach Modell: opus-4-8 33,0 % · opus-5 28,5 % · sonnet-5 14,0 % ·
|
||||
fable-5 5,2 %. Agent-Runs fahren überwiegend sonnet-5 — der Default greift, die
|
||||
Modelldisziplin auf Agent-Seite ist in Ordnung.
|
||||
|
||||
**Konsequenz:** ClaudeDo-Optimierung adressiert maximal 18 % des Limits. Der
|
||||
größere Block sind die eigenen Opus-Sessions.
|
||||
|
||||
## 3. Session-Länge ist der Treiber
|
||||
|
||||
Verbrauch ≈ Nachrichten × Ø-Kontext, und der Kontext wächst mit den Nachrichten →
|
||||
**quadratisch**. Eine Session in k Teile schneiden bringt grob 1/k.
|
||||
|
||||
Interaktiv: **Top 20 von 255 Sessions = 55,9 % des Verbrauchs.**
|
||||
|
||||
| Roh-Token | Msgs | Ø Kontext | Modell |
|
||||
|---:|---:|---:|---|
|
||||
| 199.516.097 | 716 | 278.653 | opus-4-8 |
|
||||
| 138.020.247 | 440 | 313.682 | opus-5 |
|
||||
| 123.586.522 | 463 | 266.925 | opus-4-8 |
|
||||
|
||||
## 4. Was den Kontext füllt
|
||||
|
||||
| Tool | Anteil (Agent) | Anteil (interaktiv) |
|
||||
|---|---:|---:|
|
||||
| Read | 59,8 % | 68,2 % |
|
||||
| Bash | 16,3 % | 15,4 % |
|
||||
| Grep | 8,3 % | 5,2 % |
|
||||
|
||||
Read ohne `offset`/`limit`: **57 % (Agent) / 62 % (interaktiv)**.
|
||||
Re-Reads derselben Datei in derselben Session: 18 % der Read-Calls.
|
||||
Subagent-Nutzung: nur 40 Calls bei 1.325 Reads (Agent-Seite) — die
|
||||
Kontext-Firewall ist praktisch ungenutzt. Interaktiv sind Subagent-Sessions
|
||||
dagegen 20 % des Verbrauchs.
|
||||
|
||||
Teuerste Read-Ziele sind God-Files: `TasksIslandViewModel.cs` (1121 Z.),
|
||||
`ExternalMcpService.cs` (1002 Z.), `WorkerHub.cs` (979 Z.).
|
||||
|
||||
## 5. Prefix-Größe × Nachrichtenzahl schlägt alles
|
||||
|
||||
Fallstudie an der Analyse-Session selbst (136 Msgs, 43.492.835 Roh-Token):
|
||||
|
||||
```
|
||||
msg 1 : 39.914
|
||||
msg 3 : 273.822 (+233.908) <-- claude-api-Skill geladen
|
||||
msg 136: 380.327
|
||||
```
|
||||
|
||||
Der Skill in Nachricht 3 wurde danach 136× mitgelesen: **31,8 Mio Token = 73 %
|
||||
der Session**. Zum Vergleich: **alle tool_results zusammen = 21.600 Token
|
||||
(0,05 %)**.
|
||||
|
||||
Discovery ist praktisch gratis, wenn man aggregiert statt Dateien dumpt. Teuer ist
|
||||
ausschließlich, was früh und groß in den Prefix wandert. Derselbe Block in
|
||||
Nachricht 120 geladen hätte ein Zwanzigstel gekostet.
|
||||
|
||||
## 6. Amortisation von Planungssessions
|
||||
|
||||
| Posten | Token |
|
||||
|---|---:|
|
||||
| Analyse-Session gesamt | 43,5 Mio |
|
||||
| davon vermeidbarer Prefix-Ballast | −31,8 Mio |
|
||||
| echte Planungsleistung | ≈ 11,7 Mio |
|
||||
|
||||
Gegenrechnung: **10 von 37 Tasks brauchten einen Retry (27 %)**, 13 von 54 Runs
|
||||
sind Wiederholungen. Ein Agent-Run liegt im Schnitt bei ~11 Mio Roh-Token — ein
|
||||
vermiedener Retry spart also grob eine ganze Planungssession. Dazu ersparte
|
||||
Rediscovery: ein Fund von ~8k Token, den ein Agent in Turn 10 eines 60-Turn-Runs
|
||||
selbst machen müsste, wird danach ~50× mitgelesen = ~400k pro Fund.
|
||||
|
||||
**Fazit: gründliche Planung rechnet sich — aber nur bei schlankem Prefix.**
|
||||
|
||||
---
|
||||
|
||||
## Was NICHT hilft (geprüft und verworfen)
|
||||
|
||||
- **`--effort` senken.** Thinking ist 12.536 Token über alle interaktiven
|
||||
Sessions = **0,00 %** des Verbrauchs. Effort zu senken spart nichts und kostet
|
||||
Qualität. Endgültig erledigt.
|
||||
- **Skill-Trigger entschärfen.** Der `claude-api`-Skill kostete in einer Session
|
||||
73 % — feuerte aber nur **2× in 3 Wochen** (2026-07-14, 2026-08-05). Erwarteter
|
||||
Nutzen vernachlässigbar, Risiko (Antworten aus veraltetem Prior) real. Er hat
|
||||
sich in dieser Session sogar bezahlt gemacht: der Hinweis, dass `input_tokens`
|
||||
nur der uncached Rest ist, hat den Accounting-Bug aufgedeckt.
|
||||
- **God-Files splitten.** Eigenes Risiko; Read-Disziplin entschärft das Symptom
|
||||
billiger.
|
||||
|
||||
## Offene Hebel — noch nicht untersucht
|
||||
|
||||
- Interaktive Session-Hygiene: ab wann lohnt `/clear`, messbar an Ø-Kontext?
|
||||
- Modellrouting interaktiv (opus-4-8 + opus-5 = 61,5 % des Accounts).
|
||||
- Subagent-Ökonomie: Firewall-Nutzen gegen Eigenverbrauch (20 % interaktiv).
|
||||
- MCP-Tool-Definitionen im Prefix: Umfang bei ~200 deferred Tools nicht gemessen.
|
||||
- Kalibrierung der tatsächlichen Limit-Gewichtung gegen die Rohtoken-Zahlen
|
||||
(braucht `/usage`-Ausgabe; der OAuth-Endpoint ist für Claude nicht zugänglich,
|
||||
weil `~/.claude/.credentials.json` hart blockiert ist).
|
||||
|
||||
---
|
||||
|
||||
## Messmethodik (reproduzierbar)
|
||||
|
||||
Datenquelle: `C:\Users\mika.kuns\.claude\projects\**\*.jsonl`, ein Record je
|
||||
Message, Verbrauch in `message.usage`.
|
||||
|
||||
```python
|
||||
raw = (u.get('input_tokens',0) + u.get('output_tokens',0)
|
||||
+ u.get('cache_read_input_tokens',0) + u.get('cache_creation_input_tokens',0))
|
||||
```
|
||||
|
||||
Kontextgröße einer Message = `input_tokens + cache_read + cache_write` (ohne
|
||||
Output). Der Verlauf über die Session zeigt Prefix-Sprünge.
|
||||
|
||||
### Fallstricke
|
||||
|
||||
1. **Scope-Filter.** NICHT nach Pfadname `claudedo` filtern — das zieht
|
||||
interaktive Sessions im ClaudeDo-Repo mit rein und verfälscht den Split massiv
|
||||
(53 % statt korrekt 18,4 %). Agent-Runs erkennt man an `claudedo-worktrees`
|
||||
oder `sandbox` im Projektordner, so wie es `TranscriptUsageReader` macht.
|
||||
2. **`<synthetic>`-Messages** überspringen — keine echten API-Calls.
|
||||
3. **`task_runs.tokens_in` ist unbrauchbar** — liest nur `input_tokens`, also den
|
||||
uncached Rest. Lag bei einer 79-Mio-Token-Session bei 200 (Faktor ~400.000).
|
||||
`tokens_out` zusätzlich 3,8× zu niedrig. Siehe Task `38394081`.
|
||||
4. **In Bash absolute Pfade verwenden** — `$HOME`/`~` zeigt auf dieser Maschine
|
||||
auf das P:-Laufwerk, nicht auf `C:\Users\mika.kuns`.
|
||||
5. **DB nie direkt lesen** während die App läuft — Kopie ziehen (`todo.db` +
|
||||
`todo.db-wal`).
|
||||
6. **Grundrate prüfen, bevor ein Hebel empfohlen wird.** Ein teurer Einzelfall ist
|
||||
kein Muster (siehe Skill-Trigger oben).
|
||||
|
||||
---
|
||||
|
||||
## Abgeleitete Tasks (Liste „Claude do")
|
||||
|
||||
Empfohlene Reihenfolge:
|
||||
|
||||
| # | ID | Titel |
|
||||
|---|---|---|
|
||||
| 1 | `1b599d67` | Prompt-Dateien frieren Default ein — `SuggestImprovement`/`AskUser` tot |
|
||||
| 2 | `38394081` | Limit-Verbrauch pro Run sichtbar machen (Cache-Token in `task_runs`) |
|
||||
| 3 | `0d0aa8b0` | Read-Disziplin + Explorer-Subagent im System-Prompt |
|
||||
| 4 | `2de2f008` | `max_turns` deckeln (Ceiling, Defaults, UI-Warnung) |
|
||||
| 5 | `87105f5e` | UsageGate: Parallelität stufenweise drosseln |
|
||||
|
||||
(1) zuerst, weil es ein echter Funktionsbug ist und Voraussetzung dafür, dass (3)
|
||||
den Nutzer überhaupt erreicht. (2) als Nächstes, weil ohne korrektes Accounting
|
||||
nichts messbar ist.
|
||||
|
||||
### Ist-Zustand zum Zeitpunkt der Analyse
|
||||
|
||||
- `app_settings`: `default_model` = sonnet, `default_max_turns` = 100,
|
||||
`max_parallel_executions` = 3, `model_presets` = **null** (fällt auf Defaults
|
||||
zurück: haiku 20 / sonnet 30 / opus 40 / fable 25 — greifen faktisch nie).
|
||||
- 15 Tasks überschreiben `max_turns` nach oben: 10× auf 100, 5× auf 200.
|
||||
- UsageGate existiert bereits: 5h @ 80 %, 7d @ 90 %
|
||||
(Migration `20260805074906_AddUsageGateAndRunModel`, dieselbe Migration hat auch
|
||||
die `model`-Spalte auf `task_runs` gebracht).
|
||||
- `~/.todo-app/prompts/system.md` stammt vom 2026-06-04 und weicht vom
|
||||
`SystemDefault` in `PromptFiles.cs` ab; `agent.md` und `planning.md` dort sind
|
||||
verwaiste Reste eines alten Namensschemas.
|
||||
Reference in New Issue
Block a user