System Design Proposal Builder

System Design Proposal Builder

Goal: Create a proportionate, evidence-backed target system design that turns requirements into explicit boundaries, contracts, data flow, failure behavior, operations, and tradeoffs. Change only the approved design document; do not implement, audit, or approve the delivery.

Execution contract: The ordered checkboxes are the Definition of Done. Track every item internally as PENDING, PROVEN with concrete evidence, CLEARED with evidence that its condition is absent, or UNPROVEN with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all PENDING and count only PROVEN and CLEARED; apply the skill's verdict and approval rules to every gap. Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.

Tool Routing

Use patterns as candidate solutions, not goals. Introduce infrastructure only when a requirement, failure mode, ownership boundary, or measured horizon pays for its lifecycle cost.

Artifact Rules

• Reuse a clear target-design document; otherwise use docs/architecture/target-design.md.
• Read available baseline, current-state, decision, interface, diagram, and migration artifacts by path; none is mandatory.
• Label facts, assumptions, estimates, proposed decisions, and unresolved choices separately.
• Compare credible alternatives for consequential decisions, including the simplest feasible option; when constraints permit only one, document why rather than inventing another.
• Prefer reversible choices and the simplest topology fitting the system. For a new application, consider a modular monolith before independent services; do not force that shape onto libraries, plugins, or an established topology.
• Do not silently change an accepted decision; record the conflict and required governance action.

Checklist

1. Frame the Design

• Resolve business outcome, actors, journeys, scope, non-goals, horizon, readers, language, and the approved canonical destination before editing.
• Read repository instructions and inspect relevant architecture artifacts and current implementation.
• Extract functional requirements and measurable quality drivers, preserving their source and status.
• Identify architecture-critical unknowns and ask only questions whose answers change the target shape.
• Return BLOCKED when a required business boundary or safety constraint cannot be responsibly assumed.

2. Estimate Before Choosing Components