blueprint-variants

/architect:blueprint-variants

Generates 3-5 viable architecture options for a project based on constraints. Instead of a single "one-size-fits-all" blueprint, users see: baseline (recommended), cost-optimized, performance-optimized, and other variants with explicit trade-offs.

Trigger

/architect:blueprint-variants
/architect:blueprint-variants [--count 5]           # show 5 options instead of 3
/architect:blueprint-variants [--baseline-only]     # just show recommended, no variants
/architect:blueprint-variants [--constraints file.json]  # load constraints from JSON

Purpose

Most teams have constraints (budget, team size, timeline, compliance needs). A single blueprint doesn't account for these. Blueprint-variants generates multiple architectures, each showing:

• Cost ($X/month)
• Complexity (1-10 scale)
• Team ramp time (weeks)
• Ops overhead (high/medium/low)
• Risk profile (low/medium/high)
• Key trade-offs vs. baseline

Users can compare, choose what fits their situation, and understand exactly what they gain/lose with each option.

Input

Context loading: Read architecture-output/_state.json first if it exists (project, tech_stack, components) — fall back to solution.sdl.yaml per the global SDL reading procedure only for details not already in _state.json.

If neither _state.json nor solution.sdl.yaml exists: "I need a project blueprint to generate variants from. Run /architect:blueprint first, then come back here."

Required: Project context from /architect:blueprint output (or provide interactively):

• Project type (web app, API, mobile backend, data pipeline, hybrid)
• Team expertise (startup, growing, mature)
• Primary concern (speed, cost, scale, compliance)

Optional: Constraint file (JSON):

{
  "budget_monthly": 5000,
  "team_size": 3,
  "timeline_weeks": 8,
  "ops_maturity": "startup",
  "compliance_required": ["GDPR"],
  "target_users": 10000
}

Output Files

1. architecture-output/options-comparison.md (always generated)