|
|
|
@@ -0,0 +1,61 @@
|
|
|
|
|
# Automaton Framework — Issues Log (from Investor Flow pilot)
|
|
|
|
|
|
|
|
|
|
Discovered while piloting the automaton framework on a real 26-slice decomposition. Each issue is categorized for the self-improvement loop. The user is concurrently developing ~/.automaton in a separate session.
|
|
|
|
|
|
|
|
|
|
## P0 — Blocking: cannot dispatch implementation via pi
|
|
|
|
|
|
|
|
|
|
### Issue 1: Guard blocks ALL pi-driven edits on decomposed tasks
|
|
|
|
|
**Symptom:** `pi --print` headless dispatch (the only pi-native way to drive a model) is blocked by the automaton-guard-pi plugin. The guard resolves the "primary task" as the decomposed parent (alphabetically first among implement-phase tasks), finds `DECOMPOSITION.md`, and blocks: *"Task has a DECOMPOSITION.md — broken into sub-tasks for the loop runner."* Even if the guard resolved to the sub-task, it finds `PARENT_SPEC.md` and blocks: *"sub-task reserved for the loop runner."*
|
|
|
|
|
**Root cause:** The guard has no way to know WHICH sub-task a headless pi instance is working on. `checkCanEdit` calls `status.py --can-edit` without `--task`, so it picks the first implement-phase task (the parent). The guard's DECOMPOSITION.md/PARENT_SPEC.md checks then block both parent and sub-task paths.
|
|
|
|
|
**Impact:** Cannot use `pi --print --model <model>` to implement sub-tasks. The only dispatch path that works is the loop-runner daemon via `opencode run` — which uses a different model config than pi.
|
|
|
|
|
**Fix direction:** The guard should accept a `--task` argument from the pi process (e.g. via env var `AUTOMATON_TASK=<sub-task-name>`) so headless pi instances can declare which sub-task they're implementing. When `--task` points to a sub-task in implement phase, allow edits regardless of PARENT_SPEC.md.
|
|
|
|
|
|
|
|
|
|
### Issue 2: Loop runner only dispatches via opencode, not pi
|
|
|
|
|
**Symptom:** `loop-runner.py`'s `_invoke_harness` defaults to `["opencode", "run", "--dir", "{cwd}", "{prompt_content}"]`. There is no pi-native dispatch path.
|
|
|
|
|
**Impact:** Pi's configured models (omlx/Qwythos-9B, remote/ornith, etc.) are invisible to the loop runner. Opencode has its own separate model config (`~/.config/opencode/opencode.json`) with different provider names. To use pi-configured models, the user must either (a) mirror the config into opencode, or (b) the loop runner needs a pi dispatch mode.
|
|
|
|
|
**Fix direction:** Add a `pi` harness option in loop.json: `{"harness": {"command": ["pi", "--print", "--approve", "--model", "{model}", "{prompt_content}"]}}`. Or make the harness command configurable per-loop in the template.
|
|
|
|
|
|
|
|
|
|
## P1 — Phase graph friction
|
|
|
|
|
|
|
|
|
|
### Issue 3: design:approved cannot transition to decomposition
|
|
|
|
|
**Symptom:** `status.py --transition decomposition` from `design:approved` fails: *"Legal transitions from design:approved are: test_design, implement."* The canonical flow `research → decomposition → design` was skipped (we went `research → design`), and there's no way back.
|
|
|
|
|
**Impact:** DECOMPOSITION.md written during design phase is an "out-of-order artifact" that blocks transitions to test_design and implement. Required shuffling files in/out of the task folder to satisfy the gate.
|
|
|
|
|
**Fix direction:** Either (a) allow `design:approved → decomposition` as a legal transition, or (b) allow DECOMPOSITION.md as a valid artifact in the design phase (not just decomposition), or (c) document that decomposition must always precede design and enforce it at research:approved.
|
|
|
|
|
|
|
|
|
|
### Issue 4: Parent task stuck in implement after orchestrate_finalize
|
|
|
|
|
**Symptom:** `automaton_orchestrate_finalize` creates sub-tasks but fails to transition the parent to `complete`: *"Failed to transition parent task."* The parent stays in `implement` forever.
|
|
|
|
|
**Impact:** Dashboard shows the parent as a permanently in-progress task. Confusing for the user.
|
|
|
|
|
**Fix direction:** `automaton_orchestrate_finalize` should transition the parent to `complete` (or a new `decomposed` state) after sub-tasks are created.
|
|
|
|
|
|
|
|
|
|
## P2 — DX / usability
|
|
|
|
|
|
|
|
|
|
### Issue 5: dashboard.sh wrapper has a syntax error
|
|
|
|
|
**Symptom:** `dashboard.sh` uses `exec python3 -c "..."` without parentheses — Python 3 SyntaxError. Workaround: run `PYTHONPATH=~/.automaton python3 -m automaton.dashboard` directly.
|
|
|
|
|
**Fix:** Change `exec python3 -c` to `exec python3 -c` → actually the issue is bash `exec` syntax: `exec python3 -c "code"` should be `exec python3 -c "code"` — wait, the error is `SyntaxError: Missing parentheses in call to 'exec'` which is a Python error inside the heredoc, not bash. The inline Python code itself has a syntax error.
|
|
|
|
|
|
|
|
|
|
### Issue 6: No generic "implement-decomposition" loop template
|
|
|
|
|
**Symptom:** Only `ci-triage` and `self-improvement` loop templates ship. No template for "pick up the next new sub-task from an approved decomposition and implement it."
|
|
|
|
|
**Fix direction:** Ship an `implement-decomposition` loop template with `work_source: {kind: "decomposition"}` that picks the next `new` sub-task, transitions it through research→implement, dispatches the implementer, then advances to code_review.
|
|
|
|
|
|
|
|
|
|
### Issue 7: Slice sizing mismatch — vertical slices too large for single model dispatch
|
|
|
|
|
**Symptom:** A "vertical slice" in DECOMPOSITION.md (e.g. slice #1 = 20 files across schema/adapter/cache/queue/API/auth/UI/tests) is too large for one headless model dispatch. Both Qwythos-9B (drifted into meta-exploration) and Ornith-35B (read files but produced no code in 3 min) stalled.
|
|
|
|
|
**Fix direction:** The framework should support a "micro-dispatch" layer between slices and model dispatch — each slice decomposes into 1-4 file micro-dispatches sized for the model's coherence window. Or document this as an orchestrator responsibility (which is what we did in DESIGN.md Section 8).
|
|
|
|
|
|
|
|
|
|
### Issue 8: automaton_status shows project as "trader-flow" despite rename
|
|
|
|
|
**Symptom:** After renaming the repo dir `trader-flow → investor-flow` (with a symlink back), `automaton_status` still reports `Project: trader-flow`. The project name is cached somewhere and doesn't follow the symlink.
|
|
|
|
|
**Fix direction:** Resolve the project name from the real path (resolve symlink) or from `.automaton/project-name.md`.
|
|
|
|
|
|
|
|
|
|
## P3 — Documentation / expectations
|
|
|
|
|
|
|
|
|
|
### Issue 9: No documentation that the guard blocks pi --print on decomposed tasks
|
|
|
|
|
The guard is designed to reserve sub-tasks for "the loop runner" — but there's no documentation that this means pi --print CANNOT be used to implement sub-tasks, and that only the opencode-based loop runner can. This caused significant confusion during the pilot.
|
|
|
|
|
|
|
|
|
|
### Issue 10: automaton_orchestrate_finalize should warn about guard implications
|
|
|
|
|
When `automaton_orchestrate_finalize` creates sub-tasks with PARENT_SPEC.md, it should warn that these sub-tasks are now guard-blocked for direct pi edits and can only be worked via the loop runner.
|
|
|
|
|
- [ ] 🟠 Dead ternary in YFinanceAdapter (noted by qwopus35b backend review) — separate fix task TBD
|
|
|
|
|
- [ ] 🟡 Unused import in app/src/app/page.tsx (qwopus35b fix-spa review nit) — remove
|
|
|
|
|
- [ ] 🟡 Unused useRef import in app/src/app/page.tsx (qwopus35b fix-spa review nit) — remove
|
|
|
|
|
- [ ] 🟡 Unused `Defs` import in ChartLabPanel.tsx (qwopus35b re-review nit) — remove
|
|
|
|
|
- [ ] 🟡 Slice 16: add rate-limit timing test (qwopus35b approved w/ minor note) — follow-up
|
|
|
|
|
- [ ] 🟠 EdgarAdapter full_text_search does not cache ETags (qwopus found; filings_index/company_facts do) — fix adapter + tests still 1 failing
|
|
|
|
|
- [ ] 🟡 Slice 6: add tests for 13f_holdings + form4_tx (qwopus noted; bug fix approved, tests are follow-up)
|
Investor Flow Build