Kjell Tore Guttormsen
6b30483304
NW3 (CC-26 §6 PoC): delegate trekplan Phase 7 synthesis to a synthesis-agent, adopt only if Δ main-context ≥30% with no quality loss. Operator chose the deterministic-proof path (live ≥3-run bake-off was env-blocked: no API key; installed plugin is a cache copy so a new agent is invisible to `claude -p`). Decisive structural finding: trekplan Phase 5 runs the swarm FOREGROUND, so its outputs are already resident in main before Phase 7. Delegating only Phase 7 evicts nothing → Δ_faithful = 0% (BASE-independent). The ≥30% saving needs an out-of-scope Phase-5 redesign (swarm-writes-to-disk / nested orchestrator). VERDICT: DECLINED per measurement. - agents/synthesis-agent.md — dormant, schema-conformant deliverable (NOT wired) - lib/plan/synthesis-digest-schema.mjs — digest output contract (+ tests) - scripts/synthesis-measure.mjs — deterministic Δ-accounting core (+ tests) - tests/fixtures/synthesis/ — 7 exploration outputs + representative digest - docs/T1-synthesis-poc-results.md — measurement + verdict (reproducible) - CLAUDE.md — agent table row (doc-consistency: 24 agents) Tests 670 → 695 (693 pass / 2 skip / 0 fail). `claude plugin validate` clean (only the pre-existing root-CLAUDE.md warning). commands/trekplan.md untouched. [skip-docs] rationale: no user-facing feature ships (NW3 declined; agent dormant and unwired). The substantive doc is docs/T1-synthesis-poc-results.md; the README/CHANGELOG roll-up for NW1–NW3 is the S13 coordinated release per docs/W1-narrow-wins-plan.md §S13. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LqBYc8Ltrk7LipyJmGxXiB
1.9 KiB
1.9 KiB
Risk & Failure-Mode Report — output of risk-assessor
Task: Add a per-wave concurrency cap to trekexecute headless launches.
Risks (ranked)
| # | Risk | Severity | Mitigation |
|---|---|---|---|
| R1 | A cap that is too low serializes independent waves, erasing the parallelism trekexecute exists to provide. | high | Default the cap to the batch size (no-op) and only clamp when the operator/profile asks; never silently throttle. |
| R2 | Bash semaphore bugs deadlock the wait (slots never released on subprocess crash). |
high | Prefer xargs -P <n> over a hand-rolled counting semaphore — release-on-exit is built in. Guard with a per-subprocess --max-turns/timeout already present. |
| R3 | The cap interacts with the proliferation classifier (S7 F4): a large parallel fan-out under auto/bypass is already scrutinised. A cap reduces this exposure, but mis-set to 0/negative could stall the pipeline. |
medium | Clamp to ≥ 1; reject 0/negatives with a stable error code (issue()), do not coerce. |
| R4 | Index-lock contention under high concurrency (multiple git subprocesses) is masked today by luck; raising the cap re-exposes it. |
medium | Document that GIT_OPTIONAL_LOCKS=0 is necessary-not-sufficient; the cap is the real fix. |
| R5 | Drift between the JS resolver default and the Bash template's actual -P value. |
low | Single source: prose passes the resolved integer into the template; a test asserts the template consumes $MAX_PARALLEL. |
Edge cases
- Wave of size 1 → cap is irrelevant (no fan-out).
- Cap ≥ batch size → must be a pure no-op (R1).
- Non-integer / missing flag → fall through resolver to profile default, not crash.
Complexity hotspots
The straddle between JS (resolver, testable) and Bash (launcher, hard to unit test) is the main hazard. Keep ALL arithmetic in the resolver; the template should only consume one already-validated integer.