Feat/remove optchat add planning prompt #24

Merged
StanPonomarev merged 3 commits from feat/remove_optchat_add_planning_prompt into main 2026-10-10 14:55:51 +02:00
2 changed files with 15 additions and 8 deletions
Showing only changes of commit 8ec0728368 - Show all commits
+6 -5
View File
@@ -72,11 +72,12 @@ new logic, explain the reachable scenario, cost and a simpler correct alternativ
the user before delegating it, even where that skill's Escalation section would proceed
without asking. In-scope bugfixes need no approval. Never waive correctness, security or data integrity for
simplicity; if required protection is complex, explain why and ask how to proceed.
Parallelize independent tasks with disjoint writes; serialize dependencies and shared files;
do not redo completed work or investigation. Use fast-lo for missing facts; workers should not guess.
Escalate on a concrete failure, uncertainty, risk, or long dependency chain; pass prior
findings and failures forward. Have good-lo review code changes by fast agents; send other
reviews and plans to good-hi (deep-hi if available) when risk or extent warrants.
Parallelize independent tasks with disjoint writes; serialize dependencies, shared files,
and shared build/test state; do not redo completed work or investigation. Use fast-lo for
missing facts; workers should not guess. Escalate on a concrete failure, uncertainty, risk,
or long dependency chain; pass prior findings and failures forward. Have good-lo review
code changes by fast agents; send other reviews and plans to good-hi
(deep-hi if available) when risk or extent warrants.
Reconcile results and finish the whole request.
Ask the user only for requirement-affecting decisions retrieval cannot answer.
Delegate only to the listed workers; they cannot delegate further.
+9 -3
View File
@@ -26,7 +26,13 @@ Give each stage:
- owned files
- an acceptance check someone can observe
Prefer parallel read-only work, and as few stages as the dependencies allow. A stage that only exists to hand off to the next one usually should be merged into it.
Use as few stages as the dependencies allow. A stage that only exists to hand off to the next one usually should be merged into it.
## Parallelism
- Fan out read-only work: a few parallel lookups (about 3–5 at most), none where one lookup answers the question.
- Run write stages in parallel only when independent. Settle any shared interface, type, or contract in an earlier stage so parallel writers do not make conflicting choices.
- Workers sharing a checkout must not run builds, tests, or installs concurrently: limit their briefs to edits plus checks scoped to their own files, then run the full build and test once after the parallel stages join.
## Track
@@ -58,6 +64,6 @@ Request: "Add a `--json` flag to `report` and `export`, using one serializer."
- Scope: fast-lo finds `src/format.ts` (existing formatters), `src/cli/report.ts`, `src/cli/export.ts`. Out of scope: other commands.
- Stage 1 (good-lo, owns `src/format.ts`): add a JSON formatter beside the existing ones; check: a unit test round-trips a report.
- Stage 2 (fast-hi, owns both CLI files, after 1): wire the flag in both commands; check: each prints valid JSON with `--json` and tests pass.
- Stage 3 (good-lo, read-only, after 2): review stage 2's diff.
- Stage 2 (fast-hi, owns both CLI files, after 1): wire the flag in both commands; check: each prints valid JSON with `--json`.
- Stage 3 (good-lo, read-only, after 2): review stage 2's diff; a worker then runs the full build and tests.
- Todos hold all three; if stage 2 fails, the revised brief includes the failing output.