/ln-21-system-design-baseline-builder

name: ln-21-system-design-baseline-builder
description: "Defines measurable architecture drivers and constraints before system design; edits architecture docs only."

System Design Baseline Builder

**Goal:** Create or update one durable source of truth for the project's architecture-driving requirements and constraints. Change only the approved architecture document; do not design the solution, review a plan, audit implementation, edit product code, or invent missing targets.

**Execution contract:** The checklist defines completion. Track each item internally as `PENDING`, `PROVEN` with evidence, `CLEARED` with evidence its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile after each section. Before returning, resolve all `PENDING`, count only `PROVEN` and `CLEARED`, and apply verdict and approval rules to every gap. Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method. Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims. On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.

Tool Routing

| Need | Preferred capability | Fallback | |---|---|---| | Repository rules and document conventions | Native file reads plus focused search | User-provided convention with an explicit limitation | | Existing requirements and architecture artifacts | Narrow repository search and direct reads | Conversation evidence marked with its source | | Current workload or service evidence | Metrics, dashboards, logs, manifests, or checked-in reports | Mark `UNKNOWN`; never manufacture production numbers | | Current external limits or standards | Official documentation or specifications | Mark the claim `UNVERIFIED` | | Document mutation | Minimal patch to the approved Markdown artifact | Return `BLOCKED` if no safe writable path is authorized |

Use external research only when a time-sensitive fact changes a constraint. Do not browse for values that must come from product owners, operators, the repository, or measured workload.

Artifact Rules

• Prefer an existing unambiguous architecture-requirements document.
• Otherwise use `docs/architecture/system-design-baseline.md`.
• Read before writing, preserve unrelated content, and update facts in place instead of creating parallel truth.
• Classify applicability separately as `APPLICABLE` or `NOT_APPLICABLE`, with evidence for exclusions.
• Rank each applicable item as `DRIVER`, `SUPPORTING`, or `INFORMATIONAL`.
• Classify evidence separately as `CONFIRMED`, `ASSUMED`, or `UNKNOWN`.
• Separate observed current values, required targets, hard limits, and future evolution triggers.
• Express quality attributes through observable scenarios and response measures; record undecided targets as missing decisions rather than inventing numbers.
• Treat the baseline as versioned project knowledge, not an immutable promise.

Checklist

1. Establish Scope and Destination

• [ ] Resolve the project, business outcome, intended readers, approved documentation scope, and language.
• [ ] Read applicable repository instructions and inspect Git state so unrelated changes remain untouched.
• [ ] Search for existing requirement, architecture, SLO, recovery, security, cost, and ownership documents.
• [ ] Select one canonical artifact: reuse a clear equivalent or choose the default path; explain why no duplicate will be created.
• [ ] Return `BLOCKED` if the destination is ambiguous and choosing one could split project truth.

2. Build the Evidence Ledger

• [ ] Collect business goals, actors, journeys, scope, non-goals, and decision horizon with their sources and confidence for the driver analysis; do not create a second context inventory.
• [ ] Record sources for current workload, data volume, service behavior, platform limits, and existing commitments.
• [ ] Separate repository facts from stakeholder choices and estimates.
• [ ] Detect contradictions between documents, code, configuration, and stated requirements; preserve both claims until resolved.
• [ ] Ask only for choices whose absence materially changes architecture; mark all other gaps `UNKNOWN`.

3. Define and Prioritize Architecture Drivers

• [ ] **Business and scope:** Record actors, critical journeys, business horizon, scope, non-goals, and externally committed outcomes.
• [ ] **Demand and data scale:** Record current and target users, rates, concurrency, payloads, growth, retention, and forecast horizon where relevant.
• [ ] **User-observable service quality:** Define SLIs and SLOs for availability, latency, throughput, error rate, correctness, or freshness with measurement windows.
• [ ] **Data semantics and recovery:** Define consistency, ordering, idempotency, reconciliation, durability, backup, RTO, RPO, and acceptable data loss at affected boundaries.
• [ ] **Security, privacy, and compliance:** Define trust boundaries, data classification, residency, access, audit, and destructive-action constraints.
• [ ] **Operations and economics:** Define ownership, operational capacity, cost envelope, supported regions, delivery cadence, and platform or vendo