speckit-architecture-guard-architecture-workflow

name	speckit-architecture-guard-architecture-workflow
description	Run a single architecture workflow that prefers memory-first context and can incorporate security review when available.
compatibility	Requires spec-kit project structure with .specify/ directory
metadata	{"author":"github-spec-kit","source":"architecture-guard:commands/architecture-workflow.md"}

Architecture Workflow Command

You are running architecture-guard as the single orchestration entry point for architecture review.

Use this command when the user wants one pass that covers architecture review, memory-first context when available, Security Review handoff when available, and optional performance mode without manually chaining multiple commands. When flash-mem is available, prefer memory-synthesis.md first and keep any token-savings banner visible if that output is enabled. If flash-mem is available, use the MCP-backed context preparation flow exposed by flash-mem; otherwise treat the legacy prepare-context alias as a compatibility path. Compatibility tool names such as speckit_memory_* are provided by flash-mem when the host still expects them.

This command accepts the same normalized command context as architecture-review, including semantic and dot-style aliases.

The workflow is serial and ownership-aware:

1. Read flash-mem context and specs/<feature>/memory-synthesis.md first when they are available.
2. Normalize mode and focus from the incoming command.
3. Run the architecture review against the Constitution, memory synthesis, and generic architecture principles.
4. If mode=performance, keep the pass advisory and route output to Performance Insights only.
5. Route security-first findings to Security Review instead of duplicating them here.
6. If mode=architecture and a Constitution Update Proposal is warranted, surface it and leave application to architecture-apply.
7. Produce refactor tasks or an apply recommendation for architecture findings.

Goal

Review the current specification, plan, task list, or implementation with a single workflow and produce the most useful next step.

Inputs To Consider

Review any available artifacts from these common locations. IMPORTANT: You MUST read these files explicitly using your file-reading tools (absolute or relative paths). Do not rely solely on workspace search or semantic indexers, as these files are often in .gitignore:

1. Governance & Security Constitution:

   • .specify/memory/constitution.md
   • .specify/memory/security_constitution.md

2. Architecture Constitution:

   • .specify/memory/architecture_constitution.md

3. Feature-Specific Context:

   • specs/<feature>/security-constraints.md
   • specs/<feature>/memory-synthesis.md
   • spec.md, plan.md, tasks.md, data-model.md
   • Stored architecture decisions from flash-mem, if present.
   • Security Review findings, if present.
   • Optional preset guidance, if present.

Workflow

1. Read flash-mem context first if it is available in the project or workflow context.
2. Review the current work against the Constitution and generic architecture principles.
3. Identify whether any finding is primarily security-related.
4. If a finding is security-related, flag it as a handoff to Security Review rather than treating it as a core architecture finding.
5. Produce refactor tasks or an apply recommendation as needed.
6. Prefer a single concise summary that tells the user what to fix next.

Rules

• Do not invent framework-specific conventions.
• Do not invent unsupported Spec Kit APIs.
• Do not block implementation by default.
• Do not replace Security Review; route security-first findings to Security Review when available.
• Do not require flash-mem; treat it as optional read-only context only.
• Do not duplicate Security Review findings in the architecture output unless the issue is specifically an architectural boundary problem.
• Do not write security follow-up items into architecture tasks or plan updates.
• Do not write memory conclusions into architecture follow-up items.

When mode=performance, do not produce violations or refactor tasks.

Output Format

All governance reports MUST follow this standard template:

# Architecture Governance Report

## Input Summary
- **Artifacts Scanned**: [list]
- **Extensions Used**: [`flash-mem`: yes/no, Security Review: yes/no]
- **Mode**: [architecture/performance]
- **Focus**: [general/db/api/async]

## Findings

### Violations
[Table format with: ID | Category | Severity | Location | Summary | Evidence]

### Refactor Tasks (if any)
[Task list or "None"]

### Constitution Update Proposals (if any)
[Proposals or "None"]

## Context Applied
- **`flash-mem`**: [Used context or "Not available"]
- **Security Review**: [Findings routed or "Not available"]

## Recommended Next Step
[Single clear action]