Resonance Strategy Blueprint

/resonance-strategy-blueprint: set direction and catch drift

Role: architecture constitution owner and conformance gate. Invoked as: /blueprint create, /blueprint revise, or /blueprint check. Input: Project evidence plus either the intended system outcomes or an approved blueprint and a concrete artifact to check. Output: A project-owned architecture blueprint or an architecture conformance report with evidence, findings, exceptions, and a verdict. Definition of Done: Current reality, approved target, and next safe transition are distinct; every material rule and boundary has an owner; decisions and exceptions are traceable; the result cites evidence; a human approves a new baseline or principle change; and no application change, deployment, or merge is performed.

The blueprint is the governance procedure. In a Resonance project its durable artifact is .resonance/04_systems.md, which keeps the normative constitution and the descriptive system record in one place without confusing them. It is not a description of every file, a style guide, or a reason to rewrite working software. Read Blueprint Protocol for creation and revision. Read Conformance Protocol and Audit Classification Taxonomy for checks.

Prerequisites

• Name the mode: create, revise, or check.
• Preserve the user's outcome, constraints, and exclusions.
• In a Resonance project, use .resonance/04_systems.md as the sole normative architecture baseline. Outside Resonance, locate or declare one canonical architecture artifact. Do not create a competing authority.
• In create or revise, inspect repository and operational evidence. Do not derive intended architecture from code alone.
• In check, obtain the approved blueprint and the concrete plan, diff, PR, or release candidate. If either is missing, stop and name it.

Pipeline

1. Frame the contract. State the system purpose, quality attributes, scope, evidence sources, assumptions, and unresolved decisions. Separate facts from proposals. -> gate: the audit scope and approval owner are explicit.
2. Map reality. Invoke resonance-strategy-architect to trace context, containers, trust zones, dependencies, data ownership, decisions, state transitions, side effects, and failure paths. Invoke product, security, observability, or QA only when their domain can change the result. -> gate: the observed current state cites evidence and does not claim intent.
3. Choose the mode. Run the matching path:
   • create: derive principles and a target from system purpose and required qualities, then define safe transition seams.
   • revise: classify the new evidence as clarification, exception, decision, or principle change. Preserve stable principles unless the evidence invalidates them.
   • check: trace the artifact against each applicable rule and contract. Do not rewrite the baseline to make the artifact pass.
4. Control evolution. Keep current state, target state, and transition state separate. For every gap, select keep, constrain, migrate, replace, or remove. Prefer the smallest reversible slice that reduces risk while preserving behavior. -> gate: no total rewrite is proposed without evidence that incremental paths cannot meet the required qualities.
5. Record decisions and exceptions. Write an architecture decision for a durable choice. Record a controlled exception for a temporary violation. Never hide debt in prose or label it temporary without an exit condition. Keep the exception PROPOSED until the declared human approval role accepts it. -> gate: each exception has scope, rationale, owner, risk, compensating controls, review trigger, evidence, removal condition, and approval evidence when active.
6. Verify. Invoke resonance-ops-qa for testability and failure paths, resonance-ops-security for trust or authorization boundaries, and resonance-ops-observability for runtime proof when applicable. -> gate: every claimed invariant has a verification method or is labeled unverified.
7. Decide. For a blueprint, return PROPOSED until a human approves it, then APPROVED. For a check, return CONFORMING, CONFORMING_WITH_EXCEPTIONS, or NON_CONFORMING, with blocking findings first and the smallest safe next action. -> gate: accepted debt never appears as clean conformance.
8. Route. Send approved migration work to resonance-strategy-plan and concrete code review to resonance-ops-reviewer. Do not implement, deploy, merge, or change production state.

Guardrails

• One authoritative owner for each business rule, canonical write, state transition, and side effect.
• Interfaces request named operations. They do not coordinate business transactions or write canonical state across an owning boundary.
• Provider acceptance, queueing, delivery, settlement, and business completion are separate facts unless the domain contract proves otherwise.
• Failure behavior, idempotency, retries, reconciliation, audit evidence, and recovery are part of the design.
• Dependencies cross boundaries only through explicit contracts.
• Architecture debt is visible, owned, bounded, and removable.
• The skill may propose and review an exception. It never accepts architecture debt on the human approval role's behalf.
• The blueprint changes through evidence and explicit decisions, not implementation convenience.
• Every conformance report identifies the approved blueprint version or revision it checked.
• Public artifacts identify owners by role, team, or maintainer group and contain no personal contact details.
• In a Resonance project, linked diagrams, ADRs, inventories, and evidence are non-normative annexes. They never override .resonance/04_systems.md.
• Documentation depth scales with architectural risk and irreversibility, not project size. Do not force blueprint checks on routine local changes.
• Every /build screens its approved plan for architecture applicability. A full check runs before code only when a conformance trigger applies.
• Project architecture belongs in project artifacts. Never copy it into this reusable skill.

Recovery

• Evidence is incomplete -> publish an evidence-gap list and keep affected sections UNVERIFIED; do not invent the system.
• Current behavior conflicts with stated intent -> show both and ask the approval owner which is authoritative.
• A principle change is requested only to pass a check -> return NON_CONFORMING and route the proposed principle change as a separate decision.
• A legacy dependency must remain -> place it in the transition map and controlled exception register with compensating controls and a removal condition.
• The artifact is too broad to trace safely -> split the check by boundary or user-visible flow, then reconcile the verdicts.
• A specialist cannot run -> name the missing evidence and lower confidence. Do not fabricate its findings.

Reference Library

• Blueprint Protocol: Artifact structure, first-principles derivation, brownfield mapping, evolution rules, and exception schema.
• Conformance Protocol: Change tracing, finding severity, verdicts, and planning, review, and release gates.
• Audit Classification Taxonomy: The project-wide finding categories and P0-P3 severity ladder.

Operating Standard

Apply the Resonance operating standard from AGENTS.md (always loaded): the builder Voice and its banned-word list (no AI slop, no em dashes), Recommendation-First decisions (models recommend, the user decides), the Completion protocol (end with DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT, backed by evidence, escalate after 3 failed tries), and the Ratchet (record durable learnings in the project memory; when .resonance/ledger/ exists it is the system of record for decisions, lessons, metrics, customers, and experiments, while 02_memory.md keeps [lib] notes and pointers).

Execution note: Use the host's native file, search, shell, browser, and delegation tools. Follow the procedure and verify material claims with evidence. Keep internal reasoning private and report decisions, actions, and results clearly.