mit einem Klick
strategy-scaling-architecture
// Use when planning product scaling, adding GUI/server layers, multi-model support, adversarial reviews, live steering, telemetry, scheduling/triggers, or node-based pipeline editors to spectre-build
// Use when planning product scaling, adding GUI/server layers, multi-model support, adversarial reviews, live steering, telemetry, scheduling/triggers, or node-based pipeline editors to spectre-build
Use when modifying build loop code, debugging stats/token tracking, adding CLI features, changing iteration prompts, or understanding how spectre-build works end-to-end
Use when modifying the plan loop, debugging plan stages, changing clarification flow, scope isolation, or understanding how spectre-build --plan works end-to-end
Use when modifying the ship loop, debugging ship stages, changing clean/test/rebase behavior, or understanding how spectre-build --ship works end-to-end
Use when user wants to search for existing knowledge, recall a specific learning, or discover what knowledge is available.
Use when working with pipeline stages, completion strategies, build loop orchestration, or the web GUI for spectre-build
Use this skill when you see @name or /name patterns in user input without file identifiers. This means the user is trying to call a subagent or slash command using Spectre Agent Tools. The @ prefix dispatches to a subagent (e.g., '@tdd-agent write tests', '@code-reviewer check this file'). The / prefix executes a slash command (e.g., '/spectre:scope', '/spectre:plan'). Both require Spectre CLI to run specialized agents and predefined prompts.
| name | strategy-scaling-architecture |
| description | Use when planning product scaling, adding GUI/server layers, multi-model support, adversarial reviews, live steering, telemetry, scheduling/triggers, or node-based pipeline editors to spectre-build |
| user-invocable | false |
Trigger: scale, GUI, multi-model, model abstraction, event bus, orchestrator, async, adversarial review, live steering, telemetry, industrial, node editor, pipeline editor, multi-tenant, server layer, product scaling, scheduler, cron, triggers, webhooks, pipeline chaining, command center, Prose, OpenProse, semantic completion Confidence: high Created: 2026-02-18 Updated: 2026-02-18 Version: 2
In Feb 2026, a full E2E architecture review was conducted across all three pipelines (plan, build, ship) to identify what blocks scaling spectre-build from a CLI tool to an industrial-grade product with GUIs, pluggable models, adversarial reviews, live steering, and telemetry.
Full review document: docs/architecture-review-2026-02-18.md
The pipeline engine is the best part of the codebase:
completion.py:29-43) โ clean, extensible, zero coupling. Add new strategies (FunctionCallCompletion, ExitCodeCompletion) without touching existing code.executor.py) โ state machine with event system (5 event types) + lifecycle hooks (before/after stage). Already partially event-driven.stage.py) โ model-agnostic. Calls runner via injected interface, evaluates output via injected CompletionStrategy.loader.py:170-205) โ external pipelines with Pydantic validation. Cross-reference validation on transitions.Does 6 jobs: arg parsing, session mgmt, context assembly, orchestration, hook wiring, output formatting.
if plan โ elif ship โ elif validate โ branchingsave_session() called from 9 sites with 12 parametersprint(), sys.exit()main() (281 lines), run_plan_pipeline() (168 lines), run_resume() (133 lines)print() scattered across executor.py, stage.py, agent.py, stream.py, stats.py. No event bus for structured output. The event system (on_event) fires lifecycle events but NOT output events. GUI cannot subscribe to "what's happening" without parsing stdout.
subprocess.Popen blocks the entire process. No async/await anywhere. No cancellation mid-iteration (only between iterations via executor.stop()). No way to inject feedback into a running pipeline. GUI would freeze. Parallel pipelines require process-level parallelism.
Extract Orchestrator from cli.py:
class PipelineOrchestrator:
def __init__(self, event_bus: EventBus, session_store: SessionStore): ...
def run_build(self, config: BuildConfig) -> PipelineResult: ...
def run_plan(self, config: PlanConfig) -> PipelineResult: ...
def run_ship(self, config: ShipConfig) -> PipelineResult: ...
Add EventBus (replace print with structured events):
class EventBus:
def emit(self, event: Event) -> None: ...
def subscribe(self, event_type: type, handler: Callable) -> None: ...
# Event types: OutputEvent, StageTransitionEvent, ToolCallEvent, TokenUsageEvent, ErrorEvent
Type context dicts with Pydantic models:
class BuildContext(BaseModel):
tasks_file_path: str
progress_file_path: str
changed_files: str = "No files changed (first run)"
remediation_tasks_path: str = ""
# ... all fields documented and validated
Extract routing into single route_pipeline() function (eliminates 3x duplication).
AgentRunner protocol with RunConfig (timeout, denied_tools, model, temperature, max_tokens) and IterationResult (exit_code, output, stderr, usage, tool_calls)ClaudeStreamParser, OpenAIStreamParser behind StreamParser protocolModelRegistry.register("openai", OpenAIRunner)_MODEL_PRICING dict in stats.pyPOST /api/pipelines/build, WS /ws/pipelines/:idPipelineStateStore protocol: FileStateStore โ SQLiteStateStore โ PostgresStateStoreasyncio.create_subprocess_exec, propagate async through Stage โ Executorrun_serve() already stubbed in cli.py โ this is the pathexecutor.inject_feedback(text) โ populates {user_feedback} context varskip_stage(), retry_stage(), override_signal()ConsensusCompletion strategy: requires N of M reviewers to agreeStageMetrics(stage_name, iterations, wall_time, input_tokens, output_tokens, cost, tool_calls, errors)tasks_completed / total_tokens * 1_000_000 (tracked per pipeline type, per stage, over time)StageRegistry with StageDefinition(name, description, input_schema, output_schema, completion, default_model, category)load_pipeline() โ execute (no new engine code)The PipelineExecutor IS the workflow engine. CompletionStrategy IS the extensibility point. YAML loading IS the customization path. The work is extraction and layering, not replacement. Each phase ships independently. Each preserves backward CLI compat.
Stop adding to cli.py. New pipeline modes โ factory in loader.py + config dataclass. Not another 100-line function in the god module.
| Phase | Effort | Unblocks |
|---|---|---|
| 0: Foundation | 2-3 weeks | Everything |
| 1: Model Abstraction | 1-2 weeks | Multi-model, cost optimization |
| 2: Server Layer | 2-3 weeks | GUI, remote execution |
| 3: Live Steering | 1 week | Human-in-the-loop |
| 4: Adversarial | 1 week | Quality at scale |
| 5: Telemetry | 2 weeks | Optimization, SLAs |
| 6: Node Editor | 4-6 weeks | User customization |
Critical path (GUI product): Phase 0 โ Phase 2 โ Phase 6 Value path (operational excellence): Phase 0 โ Phase 5 โ Phase 1
| File | LOC | Scaling Concern |
|---|---|---|
cli.py | 1,587 | God module โ extract Orchestrator |
pipeline/executor.py | 295 | Sound โ replace print with events |
pipeline/stage.py | 252 | Sound โ already model-agnostic |
pipeline/completion.py | 223 | Excellent โ zero changes needed |
pipeline/loader.py | 705 | Hardcoded factories โ expose via YAML |
agent.py | 306 | Model-coupled โ extract stream parsers |
stats.py | 263 | Print-coupled โ add to_dict(), per-stage metrics |
stream.py | 109 | Claude-specific โ extract to parser protocol |
hooks.py | 253 | Stage-name coupled โ register hooks declaratively |