Initialize flower orchestrator daemon reset successor

next steps

—

key decisions

• Used timer_set with body field (not message) to poke predecessor after initial deserialization error.

open questions

—

next steps

—

key decisions

• Continue using existing worktree-to-Solo-project mapping (design=52, backend=53, foundation=54, wt1=55, wt2=56).
• Use fixed-cadence 13-minute poll timer for workers instead of idle-watchdogs to avoid churn on long-running tasks.
• Horizon reload to activate merged Slice A (#231) identity code is deferred and executed promptly after reset.

open questions

—

next steps

• Poll workers via get_process_output to detect completions
• Merge landed branches from clean master per protocol
• Dispatch #234 (Slice D) after #233 completes
• Dispatch #236 (Slice F) after #232, #233, #234 are merged

key decisions

• Self-cap at 4 concurrent workers (slots: 3 epic-lead manual dispatches + 1 auto_dispatch drain)
• Use auto_dispatch signal drain (#117) to fill the 4th slot
• Dispatched #230 as the 4th slot to validate the signal-drain path
• Branch names follow pattern flower/<brief-id>-<slug>

open questions

—

next steps

• Continue work-loop monitoring and merge cycles

key decisions

• Record state in Solo scratchpad for recoverability if orchestrator resets or interrupts
• Polling strategy: use fixed-cadence timer (13 min) rather than idle-watchdogs to avoid blip-churn on long xhigh workers

open questions

—

next steps

—

key decisions

—

open questions

—

next steps

• Prepare and dispatch Slice D and #237 (done in next segment)
• Eventually dispatch #236 (F) to complete epic #226
• Process the decisions-chain signals deliberately

key decisions

• Merged in order of least conflict risk: #230 (orthogonal UI), then #233 (C), then #235 (E), then #232 (B).
• Kept the C-worker (1143) warm for chaining Slice D to reuse context.

open questions

—

next steps

• Kickstart both workers with task instructions

key decisions

• Dispatch #234 to the backend worktree and #237 to the design worktree in parallel
• Chain Slice D onto the existing warm C-worker (process 1143) to reuse context rather than spawning a fresh worker

open questions

—

next steps

—

key decisions

• Hold further dispatches until epic-lead epic completes; order remaining decisions-chain signals (sibling PRs carry merge-conflict risk).

open questions

—

next steps

• Poll worker 1143 (Slice F) for completion; then consider dispatching remaining decisions-chain tasks.
• Monitor workers for #125 and #228 after kickoffs.

key decisions

• Chain Slice F onto warm C/D worker to reuse context.
• Dispatch #125 and #228 in parallel (independent and low conflict risk).
• Ignore parent epic #95 as a dispatch target; its children carry the work.

open questions

—

next steps

• Poll workers and merge landed branches

key decisions

• Merged Slice D (#234) and #237 before this dispatch session
• Held #124/#170 due to capacity and conflict risk against live epic-lead work
• Dispatched #125 and #228 sequentially with union-resolve plan for sibling-file overlap

open questions

—

next steps

—

key decisions

• Three workers were allowed to run to completion without interference.

open questions

—

next steps

—

key decisions

• Merge order: F first (orthogonal), then #125, then #228 (both decisions siblings, union-resolving overlap).
• Ran flower:horizon-reload after merge because #125 changed EmbedChunks job.
• Marked epic #226 as complete using brief_update_status.

open questions

—

next steps

• Poll workers for completion via get_process_output
• Merge landed branches from clean MAIN tree when workers finish
• Consider self-reset if context in 400-600k range at a clean lull

key decisions

• Use make-before-break self-reset strategy at a clean lull after workers complete
• Auto_dispatch queue drained; only #95 parent-epic misfire signal remains unactioned

open questions

—

next steps

• Merge #124 and #170 into master.
• Dispatch #241 to a worker.

key decisions

• force = auto-spawn (orchestrator must auto-spawn epic lead on pickup).
• Control shape = boolean toggle mirroring #230 auto-dispatch toggle.
• Gating on planned/epic-candidate briefs.
• Dispatch brief #241 now.

open questions

—

next steps

—

key decisions

• #170 requires PromptTemplateSeeder re-seed post-merge so new daemons render v5 bodies.

open questions

—

next steps

• Monitor worker progress.
• Merge #241 when complete, running full suite and post-merge steps.

key decisions

• Part A and Part B should be landed separately; Part B may be split if orchestrator-routing scope balloons.

open questions

—

next steps

—

key decisions

• Daemons must never use Claude Code's interactive AskUserQuestion; route to async decision_ask/brief_ask
• The rule should eventually be baked into the shared charter block (DaemonCharterDefaults)

open questions

—

next steps

• Operator to decide prioritization/dispatch for #243 (epic, design-pass, or queue).
• Refine #244's open questions (entity types, scope, format, resolver tool) before finalizing the convention rule.

key decisions

• Chose to file a brief for the review round rather than extend feedback #127 because the review is a substantive audit+update task, not a single convention line.
• The Refs index format uses the entity's canonical title (#NNN: <title>), not an ad-hoc paraphrase — confirmed by operator example with #230.

open questions

• Entity types: which #-addressable types get indexed (briefs, feedback, decisions, sessions, dispatch_requests)?
• Scope: every message or only checkpoints/handoffs/reports? Terse timer-tick acks probably excluded.
• Format: one-line vs bulleted list; cap on entries.
• Need for a tiny resolver helper/tool to resolve #->canonical short name from stored data.

next steps

• On timer, verify branch and merge #241 per protocol.
• After merge, self-reset at clean lull.

key decisions

• Set a check-back timer rather than idling a full cycle to merge #241 promptly.
• Confirmed worker #241 is complete and ready to merge.

open questions

—

next steps

• Merge worker #241 (next step).
• Self-reset at clean lull after merge.
• Implement durable code fix per brief #245.

key decisions

• Orchestrator must run full recall_signals drain (all kinds) every heartbeat - memory filed.
• Ops reset is highest priority; non-orch resets must not wait more than one heartbeat.
• Failed auto_dispatch #118 because brief #95 is a parent epic, not dispatchable.

open questions

—

next steps

• Self-reset orchestrator at clean lull.
• File follow-up brief for orchestrator auto-executing epic-lead spawn end-to-end (auto-provisioning).

key decisions

• Post-merge steps required: npm build (views changed) and PromptTemplateSeeder --force (AgentConventions charter changed).

open questions

—

next steps

—

key decisions

• Every heartbeat must recall_signals and drain all pending coordination signals, not just auto_dispatch opportunistically.
• Reset-kind signals are highest priority; a routine daemon reset must not wait more than one heartbeat.

open questions

—

next steps

—

key decisions

• Drain full recall_signals every heartbeat, not just auto_dispatch signals.
• No interactive AskUserQuestion (fb #127).
• Brief #245 filed for durable code fix: auto-complete reset signals, stale-signal sweep, regression tests.

open questions

—

next steps

• Resolve #229: either refine and build or defer/close it.

key decisions

• Moved #95 to in_progress to stop reconciler loop (more accurate than planned).
• Distinguished brief #123 (completed PR-7) from feedback #123 (coordination bug) – reinforces #244's fb#-prefixed convention.

open questions

—

next steps

• Execute pending auto_dispatch signals (#137, #138, #139) via DispatchService
• Check dispatch queue and poll in-flight workers
• Recall and process inbox
• Consider orchestrator self-reset if context permits

key decisions

• Deferred self-reset because user engaged with a question about brief #229
• Cleared stale signals from completed refine reset to keep queue clean

open questions

• Will the orchestrator eventually reset in a future work-loop?

next steps

• Kick off a design-loop (writer+reviewer) to resolve the 6 open questions on #229
• Build UI surfacing for stalled/buried refining briefs

key decisions

• Confirmed that no decision is blocking #229 – it simply lacks an advancement mechanism

open questions

• Should a new 'discussing' sub-state be added to decisions?
• How to surface stalled refining briefs without requiring a daemon redesign?

next steps

• Poll workers for completion when they finish
• Merge landed branches per protocol
• Dispatch #246 after #244's resolver is available
• Take orchestrator reset at next clean lull

key decisions

• Deferred #246 (Rooms active-refs rail) until #244 is merged to avoid duplication/conflict of the shared #→title resolver
• Left decision-wake signals #146/#147 for refine daemon 42 to ack (don't claim/complete; system re-enqueues until target acks)
• Spun up #229 as a separate design-loop worker (no inline design work) per the 'never run long design-loops inline' rule
• Filed feedback idea #132 about surfacing stalled/refining/awaiting-operator briefs in /briefs UI

open questions

—

next steps

• Wait for operator to restart Solo
• After restart, resume workers, merge completed branches (#244, #217), and resume #229 design review
• File the requested feedback/brief about the coordination procedure

key decisions

• Workers were instructed to commit WIP commits to preserve progress rather than risk losing uncommitted work during Solo restart
• A scratchpad snapshot was created as a fallback in case Solo's resume fails
• No new dispatches or merges were started while restart was pending to avoid mid-operation corruption

open questions

• Whether the decision_wake signals to refine (#69/#70) were not delivered due to the timer bug, as refine did not ack them despite a previous poke

next steps

• Create a feedback item or a brief describing the coordination procedure used in this session, including steps to commit workers, snapshot state, and resume after restart, so the process can be reused for future maintenance events.

key decisions

—

open questions

—