whats-next run bilansConversational co-CTO (v2: ONE agent in a chat loop — board intelligence, ticket curation against code reality, dispatch). See bots/whats-next/. Bilans before 2026-07-07 cover the v1 form state machine (survey → priorities form → roadmap → review form → emit → dispatch pickers).
:edge (fixes deployed mid-session up to 6a03866)createRun({file_path}) with no source, and handleLaunchRun rejects a
bare file_path in cloud; whats-next is a non-embedded bundle. Fixed:
handleLaunchRun/handleResumeRun now resolve a catalog bots/<name> path (or
bot_id) off the pod FS and carry BotID so the runner mirrors the bundle’s
skills — the same gesture the webhook/scheduler/board launchers use. SPA
passes bot_id.Skill(whats-next) → “Unknown skill” even though the mirror reported
skills mirrored=11: iterion mirrored flat <name>.md files, but Claude
Code’s Skill tool only discovers the directory form <name>/SKILL.md (Agent
Skills spec). Fixed: mirror always writes the directory form (satisfies both
claude_code and claw). Nexie ran WITHOUT its playbook skill until this
landed — it still functioned via board tools + bash, just degraded.bot_id is the clean cloud
path (no source upload). A repo-connected session (forge-synced board) is the
next thing to exercise — this one had an empty workspace.worktree-nexie-v2-conversational)iterion run from the feature worktree, --store-dir /home/jo/lab/ai/iterion/.iterion (operator-visible store + REAL board, 13 backlog items), claude_code + claude-opus-4-8 forfait. Turn 2 via iterion resume --answer message=…. Containment: no dispatch instructed; one explicitly-instructed close of a verified-obsolete ticket.chat) — the living co-CTO surface, reachable from the studio.source:evolve epics from real candidates, flagged 0bc0c9ab (Revi pass) as blocked (reviews branches that never ran) and 2304ee89 (Willy gap) as probably obsolete — citing the commits that obsoleted it (dc22b626 explore-mode, fb60b075 v2 rewrite, ADR-057) unprompted, recommended 2047e34d (deadline robustness) with a sharp rationale, and offered next steps as quick-reply chips. Recommendation-first, French-mirrored — the exact contract.2304ee89 → done with a trace comment (comment_issue + close_issue), touched nothing else. Guarded-curation behavior exactly as designed._session_id loop-edge mapping) — zero re-analysis.assistant_text narration events landed in the transcript (B2 works live); quick_replies/dispatched_ids emitted as real arrays after the prompt-contract fix."[\"…\"]") from claude_code’s formatting pass — first golden recording caught it. Hardened the studio quick_replies reader (server-side extractStringIDs already tolerated it) + pinned “real arrays” in the prompt. (c5960220e)worktree: none, got stamped Worktree=true with the session worktree as work_dir — close-time finalization would have created an iterion/run/* branch there and best-effort FF’d the operator’s checked-out main onto the feature branch’s HEAD. Root cause: runPersistWorkspace’s promotion matched ANY linked worktree, not just delegated ones. Fixed: promotion now requires explicit WithWorkDir delegation (dispatcher/studio paths keep it); pinned by TestRunPersistWorkspace_WorkspaceAuthority. (c01f96fd5; this run’s run.json neutralized by hand.)epic:evolve-2026h2 aux 10 source:evolve, c’est moi qui définis cet epic, vas-y”): list_labels FIRST (vocabulary ritual), then 10× set_labels, existing labels preserved — and the confirmation ritual adaptively skipped because the instruction itself was the confirmation (“vas-y” + enumerated scope). Defensible reading of the contract; noted, not fixed.ask_user with 3 structured options (close/downgrade/keep, free-text off) — the B1 envelope persisted on the pause and the CLI answer (--answer ask_user_response=close) resumed the SAME turn, which commented + closed the ticket. 30 s for the answer→close round-trip. The guarded-bulk ritual works end-to-end live.ready (bot whole-improve-loop + bot_args intact — parked for the next dispatcher session; none was running, by design of this dogfood), dispatched_ids emitted, and Nexie spontaneously warned about Willy’s watchexec footgun (live-tree edits under task studio:dev drain the run) — catalog knowledge surfacing exactly when relevant. 25 s turn.watched_issue_ids stays null on CLI-driven runs — the dispatched_ids→watch stamp is a runview-service hook; studio-launched sessions get the WatchPanel wiring.2047e34d in ready. Both cleanup closes (2304ee89, 0bc0c9ab) carry trace comments.iterion run (CLI; project store ~/.iterion/projects/…-bots-whats-next, surfaced in studio global-active). claw gpt-5.5 forfait (explore/propose/assign) + claude_code glm-5.2 via z.ai (emit_action). When z.ai’s 5h cap hit mid-emit_action, the node went fail_resumable → resumed on anthropic/opus forfait (.env flipped). Every gate driven via --answers-file.explore → ask_priorities → propose_roadmap → human_review → emit_action → ask_which_to_process → ask_continue(close) → finished. Captured the campaign priorities into a sharp roadmap and created 5 backlog tickets, incl. the standout native:dfb12ef5 “Make claude_code provider fallback swap provider-specific models” + native:dfb5f3f7 “Refresh z.ai GLM-5.x provider metadata”. Auto-hygiene archived 2 stale findings.fail_resumable (no graceful recovery-pause, unlike Adry’s reviewer which paused with acknowledge_recovery) → rate-limit handling is inconsistent across node types. (2) non-fatal Tool error: Skill — Unknown skill: whats-next (skills not registered as slash-skills; agent recovered by reading the mirrored dir). (3) finalize created a storage branch even for a board/memory-only bot.--answers-file with proper JSON types (bool/array) is reliable for every gate (context; approved+selected_titles; action:close)./whats-next (“Explore” focus), driven through every
human gate with Playwright. Backends: claw gpt-5.5 (explore, propose_roadmap,
assign_to_bots), claude_code opus-4.7 (emit_action, triage_board). No sandbox.
Workspace store (.iterion), no --store-dir. ~68k tokens counted, ~28 min wall
(mostly inter-gate human latency; cost not cleanly tracked for the claw+claude_code mix).explore → ask_priorities → propose_roadmap →
human_review → emit_action → (dispatch picker) → assign_to_bots → triage_board →
standby. Materialised 5 backlog issues (board 88→93), reassigned 1 via triage,
ended on standby (the intended reachable co-CTO state). Zero node failures.
Audit markdown was produced as a local run artifact (docs/plans/whats-next-20260613-130840.md)
and was not committed with this bot-run note.bots/*/main.bot paths,
the real stack (Go 1.26 / React 19 / pnpm10), even spotted .botz/review-pr/main.bot.
It even picked up the docs/bot-runs/<bot>.md bilan requirement I had committed
minutes earlier — i.e. it read the current CLAUDE.md, not a cache.source:sec-audit-self SSRF (pkg/server/runs_preview.go) + path-traversal
(pkg/server/runs_files.go) findings, with concrete acceptance criteria; correctly
referenced existing board items (native:f3a888dc, native:3a81df64,
native:26870) instead of always inventing new ones; correctly deferred board
cleanup to the in-session triage_board step rather than emitting it as a ticket.source:whats-next, horizon:{next-action,short-term,long-term},
axis:{security,reliability}) and per-item bot assignees; long-term themes left unassigned.set_bot/list_labels truly absent at runtime — STALE INSTALLED BINARY (medium
— dev-infra, ROOT-CAUSED). Both emit_action and triage_board routed the bot
via the human assignee field and reported “this board build registers no
set_bot/list_labels MCP tools”. The agent was correct, not confabulating. The
studio under task studio:dev runs via go run, whose os.Executable() is a
volatile build path, so proc.LocateIterionBinary() skips it and falls back to the
installed /usr/bin/iterion to serve the __mcp-board stdio MCP. That installed
binary was stale (commit 62aac3cc, pre-dating set_bot/list_labels) and its
tools/list advertises only 7 tools (assign_issue, close_issue, create_issue,
get_issue, list_issues, set_labels, transition_issue) — no set_bot, no
list_labels. Proof: ITERION_BOARD_CAPS=<6 caps> /usr/bin/iterion __mcp-board
tools/list → 7 tools; the freshly-built binary (current code) → all 9. So the
bot prompt (emit_action_system l.709-713 already maps item.assignee → set_bot)
and the iterion-board skill are correct; the agent faithfully used what the
stale board server offered (assignee fallback, which the dispatcher honours). Fix
is operational, not a bot/code change: refresh the installed binary
(sudo cp ./iterion /usr/bin/iterion) or run the studio with
ITERION_BIN=<fresh> so delegated subprocesses match the running code. This skew
affects EVERY delegated capability (board MCP, the sandboxed __claw-runner, the
__mcp-ask-user server) — see the CLAUDE.md note added under the live-dogfood
section. (The chained findings #2–#5 below are downstream of routing via assignee
and may differ once the binary is fresh and set_bot is used.)emit_action dedup miss (low-medium — bot improvement). It created a new
“Restore sec-audit-source scanner output under dispatcher sandbox” item even though
its own body says “Fix the existing backlog item native:f3a888dc” — duplicating
the pre-existing ticket instead of promoting/linking it. (It did correctly avoid
recreating native:3a81df64.) The promote-don’t-duplicate rule needs to be firmer.assign_to_bots move all 5 issues to ready this run; the
stale 2026-06-04 session’s identical empty reply moved nothing. Same input,
opposite outcome.[] watched item (low — UX). The empty dispatch submit created a 6th
“dispatched” watch entry rendered as [] → “API error 404: issue not found”,
spamming the console with repeated 404s.GET /api/runs/{id} 404 console error right after launch
(run.json flush race); the human-gate form lagged the backend pause by a moment
(a page reload always showed it).iterion-bot-catalog.md (regen runs before every Nexie launch)
grew a duplicate Revi / review-pr card — one for bots/review-pr/main.bot,
one for a stray gitignored .botz/review-pr/main.bot (a leftover iterion bundle
pack artifact, also surfaced in Nexie’s own survey). pkg/botregistry treats both
bots/ and .botz/ as discovery roots but does not dedupe by bundle name, so a
local packed copy of a source bot shows up twice in the catalog Nexie routes from.
Worked around locally by removing the stray .botz/review-pr + restoring the regen
artifact; the proper fix is dedupe-by-bundle-name (precedence bots/ > .botz/) in
pkg/botregistry discovery — deferred to a focused follow-up.go run serves __mcp-board (and the claw runner / ask-user MCP) from the
stale installed /usr/bin/iterion, which silently lacks capabilities added since
the last install (set_bot/list_labels here). Code is correct; refresh the binary
or set ITERION_BIN. Documented in CLAUDE.md so it doesn’t re-bite the campaign.pkg/botregistry cross-root dedupe (finding #7): FIXED — discoverBots now
dedupes by normalized bundle name across roots (precedence bots/ > .botz/), with
a regression test (TestList_DedupesSameBotAcrossRoots). So a stray packed .botz/
copy can no longer duplicate a catalog card.bot field (not assignee) is set on materialised issues."all"; do not submit empty
(ambiguous + creates the phantom [] watch).