speckit-architecture-guard-architecture-verify

name	speckit-architecture-guard-architecture-verify
description	Perform an architecture-aware verification gate validating implementation against spec.md, plan.md, tasks.md, and the Architecture Constitution.
compatibility	Requires spec-kit project structure with .specify/ directory
metadata	{"author":"github-spec-kit","source":"architecture-guard:commands/architecture-verify.md"}

Architecture Verification

Validate that the implementation fulfills all tasks in tasks.md while adhering to the defined architecture boundaries and the Architecture Constitution. This command acts as a post-implementation gate.

Flash-Mem-First Architecture Context Retrieval

When Flash-Mem is available, query it first for summary and metadata context before performing architecture analysis:

1. Search Flash-Mem for relevant architecture context:
   • architecture decisions
   • ADRs
   • design constraints
   • coding conventions
   • prior guard findings
   • approved exceptions
   • architectural patterns
2. Prefer summary-first retrieval:
   • use summaries
   • use metadata
   • use confidence
   • use tags
   • use related files
3. Load full memory content only when summaries are insufficient.
4. Reuse approved architectural decisions whenever possible.
5. Flag conflicts between proposed changes and existing architectural decisions.
6. After analysis, store durable architecture knowledge back into Flash-Mem:
   • new architecture decisions
   • approved exceptions
   • recurring violations
   • architectural constraints
   • project conventions
   • validated design patterns

If Flash-Mem is unavailable or the retrieved summaries are insufficient, continue with the repository artifacts and constitution files available in the workspace.

User Input

$ARGUMENTS

Goal

Perform a high-integrity verification of the implementation. Unlike a general review, this command explicitly maps tasks.md to code evidence and validates architectural compliance against the project's specific boundaries and standards.

Operating Constraints

• STRICTLY READ-ONLY: This is an analytical gate. Do not modify files.
• Evidence-Based: Every "Verified" or "Missing" status must cite specific files or code patterns.
• Constitution Authority: The architecture_constitution.md is the non-negotiable standard for this check.

Execution Steps

1. Initialize Context

1. Run ../scripts/bash/check-prerequisites.sh --json --paths-only from repo root to identify the active FEATURE_DIR.
2. Derive absolute paths for spec.md, plan.md, and tasks.md.
3. Load the Architecture Constitution: .specify/memory/architecture_constitution.md.

2. Semantic Modeling (Internal)

Build internal representations:

• Task-Boundary Map: Associate each task with its intended architecture layer (Entry, Application, Domain, Data, External).
• Implementation Evidence: For each completed task ([x]), scan referenced files for logic that addresses the task description.
• Contract Inventory: Extract planned API/Data signatures from plan.md.

3. Verification Checks

A. Task-Code Alignment

• Ghost Tasks: Tasks marked complete but with no evidence in the referenced files.
• Orphaned Code: Implementation logic present in files that wasn't planned in tasks.md.
• Missing Files: Files referenced in tasks that do not exist on disk.

B. Boundary Integrity

• Layer Violation: Logic from one layer (e.g., Database queries) appearing in another layer (e.g., Controllers/Entry).
• Dependency Drift: New dependencies introduced that violate the architecture's "Stable Abstractions" principle.

C. Constitution Compliance

• Rule Check: Does the implementation violate any "MUST" rules in the architecture_constitution.md?
• Pattern Match: Does the code follow the mandated architectural patterns (e.g., DTOs, Repositories, Events)?

D. Security Review on Implementation

• If spec-kit-security-review is available, run /speckit.security-review.branch against the verified implementation.
• If security findings are architecture-relevant, classify them as Security-Architecture Conflict.

4. Severity Assignment

• CRITICAL: Task marked done but implementation is missing; Constitution "MUST" violation; Boundary bypass (e.g., direct DB access from UI).
• HIGH: Contract mismatch; Missing error-handling/edge-cases from spec; Major boundary erosion.
• MEDIUM: Pattern drift; Task-referenced file exists but logic is incomplete.
• LOW: Naming inconsistencies; Minor structure drift.

Verification Report

ID	Category	Severity	Location(s)	Summary	Recommendation
V1	Task Integrity	CRITICAL	tasks.md:T01	Task marked complete but logic missing in src/auth.ts	Implement logic or uncheck task
V2	Boundary	HIGH	src/ctrl/user.ts	Database query found in Controller layer	Move query to Repository/Data layer

Task Status Analysis

For each task in tasks.md:

• Implemented?: [Yes/No/Partial]
• Evidence: [File path or logic pattern]
• Gap Analysis: If "No" or "Partial", explain why the task is incomplete and suggest the remediation.

Metrics

• Tasks Verified: [Completed / Total]
• Requirement Coverage: [e.g. 100%]
• Boundary Integrity: [Strong / Eroded / Breached]
• Constitution Score: [e.g. 100%]

Action Plan

1. Critical Gaps: Address missing implementation for tasks [IDs] immediately.
2. Architecture Alignment: Resolve boundary violations in [Files] using suggested refactor tasks.
3. Completion: If all CRITICAL/HIGH are resolved, you MUST automatically execute the durable-memory capture flow to preserve lessons. Do not just recommend it; let the formal capture flow propose entries and request user approval.

Next Step: [e.g. "Run /speckit.architecture-guard.architecture-apply to fix V2"]