See if new loop type Orchestrator can be fit into the overall loop types

[scgopi]

[scgopi]

[graphcode-fixer] Classified as enhancement (out of scope for automated bug fixing): this asks whether a new Orchestrator loop type should be added to LoopType, which is a new capability to design rather than a report of broken behaviour.

---

Generated by Claude Code

[scgopi]

Findings: an Orchestrator loop type does not fit the taxonomy — the role it names already exists, three ways

Verdict: recommend no new LoopType case. "Orchestrator" names a role (who coordinates work), while the loop taxonomy classifies by a different axis entirely — what a human hands off — and every meaning "Orchestrator" could carry is already implemented elsewhere in the system.

1. The taxonomy's axis is the hand-off, and it is closed by construction

The four types are one axis with four values (README.md:33, docs/index.md):

When you put an agent on repeat, you hand off one of four things: the check, the stop condition, the trigger, or the prompt itself. That's the space of loops possible.

Type	You hand off
Turn-based	the check
Goal-based	the stop condition
Time-based	the trigger
Composite	the prompt (a sub-graph runs it)

"Orchestrator" is not a fifth hand-off — an orchestrating agent still needs one of the four contracts above to be a loop at all (when does it pause? what resolves it? what re-triggers it?). Adding it as a peer case would put a role name on the hand-off axis, and every switch over LoopType would have no principled answer for it (what is its sessionPrompt? its runsUnattended? its canHost capability?).

2. Every reading of "Orchestrator" already has a home

If "Orchestrator" means…	It already exists as…
The thing that schedules loops, fires edges, routes models	graphcoded + the app — literally called "the orchestrator" throughout (graphcoded/Sources/main.swift:8, OrchestratorClient, docs/05). DaemonProtocol.swift:47: "there's no second execution engine, just the orchestrator running a graph inside a graph."
A node that runs a graph of other loops	.composite — LoopNode.swift:55 quotes docs/05 directly: "a proactive node is the orchestrator running a graph inside a graph." Sub-graph hosting, pilot-before-arm, state roll-up, stop cascade are all wired (GraphStore.runInSubGraph, rollUpComposite, pilotComposite/armComposite).
A cross-project dispatcher	The global graph scope (LoopGraphScope.global, graphcode://global) with cross-graph .spawn edges. Notably, its UI name was deliberately changed away from "Orchestrator" (LoopGraphScope.swift): the word "named the daemon-side machinery instead — a component nobody clicking a sidebar row is looking for."
A running agent that spawns and coordinates worker loops	Already a role any loop type can play, orthogonal to type: any session creates children via the CLI, with custody (NodeDraft.createdBy → delete/stop cascades, GraphStore comments say "deleting a coordinator must not strand the workers"), backend inheritance, an auto-drawn handoff edge, and each child handed its report-back route (graphcode node send <parent-id>) at birth.

The session briefing every loop receives even states the design position explicitly (SessionBriefing.swift:173): "Never create a loop whose job is to create more loops." Orchestration is what a loop does on top of its contract, not what kind of loop it is.

3. Cost if added anyway (for completeness)

A fifth case is not just an enum line. Full sweep of the cost surface:

• ~14 exhaustive switches (compiler-guided): sessionPrompt, NodeDraft.isValid, canHost, defaultModelTier, updateNode, appearance (accent/glyph/name), chooser blurbs ×2, form field views, recap sentence, backend-refusal copy, card fallback line, tab title, /loop-directive composition.
• ~25 silent equality conditionals — the real risk: LoopNode.runsUnattended (decides whether the daemon starts/revives the session at all), makeNode/reIdentified initial state, spawnInstance, goal-poller arming, composite drill-in vs terminal-open, SSH restore branch.
• Two more parsers with no compiler help: the CLI's --type string switch (GraphcodeCommand.swift:251) and the duplicated Python dict in the remote shim (RemoteGraphAccess.swift:376).
• A fifth accent colour: LoopTypeAppearance.swift records that the four current hues were CVD-validated as a set within one lightness band, with blue/orange already reserved for presence and attention — a fifth mutually-distinguishable hue may not exist under those constraints.
• A hard forward-compat constraint: LoopNode's decoder falls back only on a missing loopType key. A present but unknown raw value throws, and ProjectPersistence.loadGraph turns any decode failure into "no saved graph" — so to an older app/daemon/CLI (which the design explicitly allows to be a version behind, LoopType.swift:17-19), a graph containing one new-typed node reads as all loops wiped. A lenient decode would have to ship at least one release before anything writes the new value.
• 5+ test suites enumerate allCases (unique display names, non-empty distinct blurbs per type, per-type tier assertions, hostable-pairing launchability, raw-value pinning).

Recommendation

Close as won't-add. Concretely, for the use cases the name suggests:

• "I want a node that runs a pipeline of loops" → use Composite (this is exactly what it is).
• "I want an agent that decides at runtime what loops to create and steers them" → a goal-based (or time-based) loop whose prompt says to fan out; the CLI custody/fan-out machinery already makes it a first-class coordinator, and its stop condition is still what makes it a loop.
• "I want cross-project dispatch" → the global graph with .spawn edges.

If any gap remains after mapping a concrete use case onto those three, it's likely a missing capability on an existing type (e.g. richer composite triggers) rather than a missing type.

---

🤖 Investigated with Claude Code