feat: refactor architecture validation with architect.validate

- Add READ-ONLY adlc.architect.validate command for plan alignment checks
- Add extension hooks: before_plan (create ADRs), after_plan (validate)
- Simplify CLI: remove --tdd, --architecture; keep --contracts, --data-models
- Update spec-template.md with multi-line Framework Options format
- Move architecture validation from spec to plan level via hooks
- Add setup-architect.sh/ps1 validate actions with graceful skip
- Update docs: README.md, architecture.md, architect README.md
- Bump version to 0.0.114

Files changed: 18
Lines: +617, -230

Author: kanfil

CHANGELOG.md

@@ -7,6 +7,49 @@ All notable changes to the Specify CLI and templates are documented here.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to to [Semantic Versioning](https://semver.org/spec/v2.0.0/).
 
+## [0.0.114] - 2026-03-07
+
+### Added
+
+- **Architect Validation Integration**: Added READ-ONLY `adlc.architect.validate` command that validates plan alignment with architecture
+  - Validates 7 PILLAR checks: component alignment, interface contracts, data model consistency, context/functional/information/development view alignment
+  - Checks diagram consistency: system boundaries and data flows
+  - Returns structured JSON with blocking, high-severity, and warnings findings
+  - Gracefully skips when architecture doesn't exist (returns `{"status":"skipped"}`)
+
+- **Extension Hooks for Architect**: Added automatic extension hook integration for architect workflow
+  - `before_plan` hook: Creates feature-level ADRs using `adlc.architect.specify`
+  - `after_plan` hook: Validates plan alignment using `adlc.architect.validate --for-plan`
+  - Hooks execute automatically when `.specify/memory/adr.md` exists
+
+- **Multi-line Framework Options Format**: Updated spec-template.md to use multi-line format for clarity
+  ```
+  contracts={contracts}
+  data_models={data_models}
+  ```
+
+### Changed
+
+- **Simplified Framework Options**: Removed deprecated CLI flags (--tdd, --architecture)
+  - Retained only user-configurable flags: `--contracts`, `--no-contracts`, `--data-models`, `--no-data-models`
+  - TDD and architecture validation now handled via extensions (architect, tdd)
+
+- **Architecture Validation Workflow**: Moved validation from spec level to plan level
+  - Previous: validation in clarify.md (spec spec)
+  - New: validation via architect.validate command with after_plan hook (plan level)
+  - README.md and docs/architecture.md updated with new workflow
+
+- **Architect Extension Scripts**: Added validate action to setup-architect.sh and setup-architect.ps1
+  - bash: New `action_validate()` function with graceful skip behavior
+  - PowerShell: New `Invoke-Validate()` function with graceful skip behavior
+
+### Documentation
+
+- `extensions/architect/README.md`: Added validate command to commands table and hooks integration section
+- `extensions/architect/commands/validate.md`: Complete command documentation with flags and usage
+- `docs/architecture.md`: Updated workflow to describe hooks-based architecture validation
+- `README.md`: Added Framework Options section documenting simplified CLI flags
+
 ## [0.0.112] - 2026-03-06
 
 ### Fixed

README.md

@@ -199,40 +199,6 @@ specify init my-project --debug
 specify init my-project --github-token $GITHUB_TOKEN
 ```
 
-### Framework Options
-
-Fine-grained control over development approach available via command-line flags:
-
-```bash
-# Test-Driven Development
-/spec.specify --tdd (enabled by default)
-
-# Smart Contracts (API specifications)
-/spec.specify --contracts (enabled by default)
-
-# Data Models (entity relationships)
-/spec.specify --data-models (enabled by default)
-
-# Risk-Based Testing
-/spec.specify --risk-tests (enabled by default)
-```
-
-#### Auto-Detection System
-
-Framework options are automatically detected by downstream commands from spec.md metadata:
-
-- **`/spec.plan`**, **`/spec.tasks`**, **`/spec.implement`**, **`/spec.clarify`**, **`/spec.analyze`**, **`/spec.checklist`**: Auto-detect framework options from the current feature's spec.md
-- **`/architect.*`**: Option-agnostic (system-level architecture should not be constrained by feature-level options)
-
-#### Complete Example
-
-```bash
-specify init my-project \
-  --ai claude \
-  --script sh \
-  --team-ai-directives https://github.com/your-org/team-ai-directives.git
-```
-
 ### Optional Architecture Support
 
 The toolkit includes comprehensive architecture documentation support via the **Architect extension**. Architecture commands work in any project.
@@ -241,10 +207,11 @@ The toolkit includes comprehensive architecture documentation support via the **
 
 #### Two-Level Architecture System
 
-| Level | Location | ADR File | Architecture Description | Commands |
-|-------|----------|----------|--------------------------|----------|
-| **System** | Main branch | `memory/adr.md` | `AD.md` (root) | `architect.*` |
-| **Feature** | Feature branch | `specs/{feature}/adr.md` | `specs/{feature}/AD.md` | `spec.plan --architecture` |
+| Level | Location | ADR File | Architecture Description | Hook Timing |
+|-------|----------|----------|--------------------------|--------------|
+| **System** | Main branch | `memory/adr.md` | `AD.md` (root) | N/A |
+| **Feature** | Feature branch | `specs/{feature}/adr.md` | `specs/{feature}/AD.md` | before_plan with architect extension |
+| **Validation** | Plan level | READ-ONLY via architect.validate | Validates plan alignment | after_plan with architect extension |
 
 #### Architecture Workflow
 
@@ -264,10 +231,18 @@ The toolkit includes comprehensive architecture documentation support via the **
 # Then proceed with normal workflow
 /spec.specify "Feature within this architecture"
 
-# Or generate feature-level architecture during planning
-/spec.plan --architecture
+# Plan generation with architecture validation (if architect extension installed)
+/spec.plan
+  - **before_plan hook** (architect extension): Create feature ADRs using architect.specify/clarify/implement
+  - **after_plan hook** (architect extension): Validate plan alignment using architect.validate --for-plan
 ```
 
+**Architecture Integration via Hooks**:
+
+- **before_plan** (architect extension): Automatically creates feature ADRs if adr.md exists
+- **after_plan** (architect extension): Validates plan alignment with architecture (READ-ONLY)
+- Hooks only activate if architect extension installed and adr.md present
+
 #### Architecture Commands
 
 | Command | Description |
@@ -276,9 +251,12 @@ The toolkit includes comprehensive architecture documentation support via the **
 | `architect.specify` | Interactive PRD exploration to create system-level ADRs |
 | `architect.clarify` | Refine ADRs through targeted clarification questions |
 | `architect.implement` | Generate full Architecture Description (AD.md) from ADRs |
-| `architect.analyze` | Validate ADR <-> AD consistency and quality |
+| `architect.analyze` | Validate ADR ↔ AD consistency and quality |
+| `architect.validate` | READ-ONLY: Validate plan alignment with architecture (plan level) |
 
-**Feature Architecture**: Use `/spec.plan --architecture` or set `architecture=true` in spec.md Framework Options to generate feature-level architecture (`specs/{feature}/AD.md` and `specs/{feature}/adr.md`).
+**Feature Architecture Workflow**:
+
+Feature-level ADRs and AD.md are created automatically via architect extension hooks during `/spec.plan` execution (if architect is installed and system architecture exists). No manual --architecture flag needed for feature architecture generation.
 
 #### Architecture Configuration Options
 
@@ -332,6 +310,52 @@ The `architect.*` commands generate documentation covering:
 
 Plus cross-cutting **Perspectives**: Security, Performance & Scalability
 
+### Framework Options
+
+The spec-kit supports the following framework options, configurable during feature creation:
+
+| Option | Description | Default |
+|--------|-------------|---------|
+| `--contracts` | Enable service contracts (API schemas, test assertions) | Enabled |
+| `--no-contracts` | Disable service contracts | - |
+| `--data-models` | Generate data model documentation | Enabled |
+| `--no-data-models` | Skip data model generation | - |
+
+**Example**:
+```bash
+./create-new-feature.sh --contracts --no-data-models "User authentication"
+```
+
+**Usage Pattern**:
+
+Set flags during feature creation. The flags are stored in each `spec.md` file and auto-detected by all `/spec.*` commands.
+
+**Example in spec.md**:
+```markdown
+## Framework Options
+
+contracts=true
+data_models=false
+```
+
+**Workflow Integration**:
+
+| Feature | Architecture Location | Activation |
+|---------|----------------------|-------------|
+| Feature ADRs (pre-plan) | before_plan hook (architect extension) | Generates feature-level ADRs if adr.md exists |
+| Architecture validation (post-plan) | after_plan hook (architect extension) | architect.validate validates plan alignment |
+| Plan generation | plan.md core command | Executes data model + UX validation (inline) |
+
+**Advanced Features** (extension-based):
+
+| Feature | Extension | Activation |
+|---------|-----------|-------------|
+| Test-Driven Development (TDD) | tdd extension | Hooks activate after /spec.tasks, /spec.implement |
+| Architecture integration | architect extension | before_plan (create ADRs), after_plan (validate) |
+| Risk-based testing | tdd extension | Part of TDD workflow |
+
+These are extension-based, requiring explicit installation for opt-in behavior.
+
 ### 2. Establish project principles
 
 Launch your AI assistant in the project directory. The `/spec.*` commands are available in the assistant.
@@ -589,15 +613,6 @@ Skills configuration is stored in `~/.config/specify/config.json`:
 | `--team-ai-directives`       | Option   | Path or URL to team-ai-directives repository                                |
 | `--ai-skills`                | Flag     | Install Prompt.MD templates as agent skills in agent-specific `skills/` directory (requires `--ai`) |
 
-### `/spec.specify` Framework Options
-
-| Argument/Option | Type     | Description                                                                 |
-|-----------------|----------|-----------------------------------------------------------------------------|
-| `--tdd/--no-tdd` | Option | Enable/disable TDD (Test-Driven Development) |
-| `--contracts/--no-contracts` | Option | Enable/disable API contract generation |
-| `--data-models/--no-data-models` | Option | Enable/disable data model generation |
-| `--risk-tests/--no-risk-tests` | Option | Enable/disable risk-based test generation |
-
 ### `specify skill` Commands & Options
 
 The Skills Package Manager is accessed via the `specify skill` subcommand:

docs/architecture.md

@@ -185,16 +185,31 @@ The analyze command validates consistency between ADRs and AD.md:
 
 ## Integration with Spec Workflow
 
-Architecture commands work alongside specification commands:
+Architecture commands work alongside specification commands via extension hooks:
 
 ```
 /architect.specify --> /architect.clarify --> /architect.implement
-                                                      |
-                                                      v
-/spec.specify --> /spec.plan --architecture --> /spec.tasks --> /spec.implement
+                                                       |
+                                                       v
+                    /architect extension hooks (before_plan / after_plan)
+                                                       |
+                                                       v
+/spec.specify --> /spec.plan --> /spec.tasks --> /spec.implement
 ```
 
-The `--architecture` flag in `/spec.plan` generates feature-level architecture (AD.md and adr.md in `specs/{feature}/`).
+**Architecture Workflow** (architect extension hooks):
+
+| Hook | Timing | Purpose |
+|------|--------|---------|
+| **before_plan** | Before plan generation | Create feature ADRs using architect.specify/clarify/implement |
+| **after_plan** | After plan generation | Validate plan alignment using architect.validate --for-plan (READ-ONLY) |
+| **Activation** | adr.md exists | Hooks only fire if `.specify/memory/adr.md` present |
+
+**Feature Architecture Generation**:
+
+- Manual: Run `/architect.specify` → `/architect.clarify` → `/architect.implement` to create feature ADRs and AD.md
+- Automatic: architect extension before_plan hook executes same commands when adr.md exists
+- Validation: architect extension after_plan hook validates plan alignment with architecture (READ-ONLY via architect.validate)
 
 ## Configuration
 

docs/quickstart.md

@@ -11,35 +11,6 @@ This guide will help you get started with Spec-Driven Development using Agentic
 **Note:** Run these steps in a standard terminal before opening the Intelligent IDE.  
 **Alignment with 12 Factors:** This stage establishes the foundation guided by [I. Strategic Mindset](https://tikalk.github.io/agentic-sdlc-12-factors/content/strategic-mindset.html) and [II. Context Scaffolding](https://tikalk.github.io/agentic-sdlc-12-factors/content/context-scaffolding.html), positioning the developer as orchestrator and assembling necessary context for AI collaboration.
 
-### Framework Options
-
-Core workflow commands support fine-grained control over development approach:
-
-#### Configuration Options
-
-Fine-grained control over development approach via command-line flags:
-
-```bash
-# Test-Driven Development
-/spec.specify --tdd (enabled by default)
-
-# Smart Contracts (API specifications)
-/spec.specify --contracts (enabled by default)
-
-# Data Models (entity relationships)
-/spec.specify --data-models (enabled by default)
-
-# Risk-Based Testing
-/spec.specify --risk-tests (enabled by default)
-```
-
-#### Auto-Detection System
-
-Downstream commands automatically detect framework options from spec.md metadata:
-
-- **`/spec.plan`**, **`/spec.tasks`**, **`/spec.implement`**, **`/spec.clarify`**, **`/spec.analyze`**, **`/spec.checklist`**: Auto-detect framework options from the current feature's spec.md
-- **`/architect.*`**: Option-agnostic (system-level architecture should not be constrained by feature-level options)
-
 1. **Project Initialization (`/init`)**  
    **Action:** From the project root, run the Agentic SDLC Spec Kit `init` command (e.g., `specify init <project> --team-ai-directives https://github.com/your-org/team-ai-directives.git`) to configure local settings and clone the shared `team-ai-directives` modules.  
    **Purpose:** Creates the handshake that brings the repository into the managed Agentic SDLC ecosystem, wiring credentials, endpoints, and shared knowledge needed for subsequent commands.

evals/prompts/spec-prompt.txt

@@ -3,31 +3,6 @@ You are tasked with creating a detailed feature specification.
 USER REQUIREMENTS:
 {{ user_input }}
 
-MODE DETECTION: Check if the user input mentions "build mode" or "minimal spec":
-- If YES → Create a LEAN specification (STOP being comprehensive, be MINIMAL)
-- If NO → Create a COMPREHENSIVE specification (5+ user stories, detailed requirements)
-
-⚠️ LEAN MODE RULES (when "build mode" or "minimal spec" detected) ⚠️
-CRITICAL: This is NOT a comprehensive spec. Keep it SHORT, SIMPLE, and INFORMAL.
-
-HARD LIMITS (DO NOT EXCEED):
-- 2 user stories MAXIMUM (not 3, not 4, just 2)
-- 1-2 acceptance criteria per story MAXIMUM (not 3-5 per story)
-- 3-5 functional requirements TOTAL (FR-001 through FR-005 MAX)
-- 1-2 non-functional requirements TOTAL (skip specific metrics for simple features)
-- 2-3 edge cases TOTAL (brief, one sentence each)
-- 2-3 success criteria TOTAL
-- TOTAL OUTPUT: Aim for 30-40 lines of content (not counting section headers)
-
-LEAN MODE FORMATTING (less formal):
-- NO story IDs (no US-001, US-002) - just describe the stories
-- NO priority levels (no [P1], [P2], [P3])
-- NO formal "Acceptance Criteria:" headers - just bullet points
-- NO requirement IDs unless there are 4+ requirements (then use FR-001, FR-002...)
-- Simpler, more conversational language
-- Combine Overview + User Stories into one concise section if appropriate
-- Focus on CORE functionality only
-
 CRITICAL: First, identify if this is a SECURITY-CRITICAL feature by checking for:
 - Authentication/authorization systems
 - Payment processing, credit cards, financial transactions
@@ -39,29 +14,24 @@ If YES → Section 4 (Non-Functional Requirements) MUST comprehensively address
 
 INSTRUCTIONS:
 Create a feature specification document with the following structure.
-Adjust detail level based on mode (LEAN for build mode, COMPREHENSIVE otherwise).
 
 IMPORTANT: Use ## (level 2) markdown headers for ALL major sections below:
 
 ## 1. Overview Section
 Brief description of the feature
 
 ## 2. User Stories
-COMPREHENSIVE mode: 5+ prioritized user stories (P1, P2, P3) with detailed acceptance criteria, formal IDs (US-001, US-002)
-LEAN mode: 2 user stories maximum, simple format without IDs or priorities
+5+ prioritized user stories (P1, P2, P3) with detailed acceptance criteria, formal IDs (US-001, US-002)
    - Clear "As a [role], I want [feature], so that [benefit]" format
-   - LEAN mode: Brief bullet points (1-2 per story), no "Acceptance Criteria:" header, no Given/When/Then
-   - COMPREHENSIVE mode: Detailed acceptance criteria in Given/When/Then format with formal structure
+   - Detailed acceptance criteria in Given/When/Then format with formal structure
    - Independent testability for each story
 
 ## 3. Functional Requirements
-COMPREHENSIVE mode: Detailed coverage with IDs (FR-001, FR-002... up to FR-015+)
-LEAN mode: 3-5 core requirements ONLY, simple bullet points or use FR-001 to FR-005 if numbering helps clarity
+Detailed coverage with IDs (FR-001, FR-002... up to FR-015+)
 
 ## 4. Non-Functional Requirements
 Performance, security, scalability requirements (NFR-001, NFR-002, etc.)
-LEAN mode: 1-3 critical NFRs only, NO detailed metrics for simple features (health checks, basic CRUD)
-COMPREHENSIVE mode: Detailed NFRs with specific measurable targets
+Detailed NFRs with specific measurable targets
 
    🔒 SECURITY REQUIREMENTS (MANDATORY for authentication/payments/PII/healthcare):
    You MUST include ALL of the following security requirements:
@@ -83,8 +53,7 @@ COMPREHENSIVE mode: Detailed NFRs with specific measurable targets
 ## 5. Edge Cases
 MANDATORY SECTION - This section heading MUST appear in output with content below it.
 Document boundary conditions and error scenarios:
-COMPREHENSIVE mode: Detailed coverage with multiple scenarios per category
-LEAN mode: 2-3 key edge cases only (brief, 1-2 sentences each)
+Detailed coverage with multiple scenarios per category
 
    - For multi-step flows (checkout, onboarding, wizards), include:
      * Failed transitions between steps (payment declined, timeout, network errors)
@@ -100,8 +69,7 @@ LEAN mode: 2-3 key edge cases only (brief, 1-2 sentences each)
      * Partial failures and retry logic
 
 ## 6. Success Criteria
-COMPREHENSIVE mode: Comprehensive coverage with IDs (SC-001 to SC-010+)
-LEAN mode: 2-3 key success criteria ONLY, simple bullet points without SC-001, SC-002 IDs
+Comprehensive coverage with IDs (SC-001 to SC-010+)
 
 IMPORTANT CONSTRAINTS:
 - Do NOT include technical implementation details (no specific frameworks, libraries, or tech stack)
@@ -117,12 +85,4 @@ IMPORTANT CONSTRAINTS:
   * Edge cases for each transition (what happens if step fails, timeout, etc.)
   * Success criteria for the entire flow
 
-⚠️ FINAL REMINDER FOR LEAN MODE ⚠️
-If "build mode" or "minimal spec" was detected:
-- You are writing a MINIMAL, INFORMAL spec - NOT a comprehensive enterprise document
-- Use SIMPLE formatting: no US-001/FR-001/SC-001 IDs, no [P1]/[P2] priorities
-- STOP after 2 simple user stories, 3-5 functional reqs, 1-2 NFRs, 3 edge cases, 3 success criteria
-- Do NOT add formal headers like "Acceptance Criteria:" - just use bullet points
-- Your output should be ~30-40 lines of content, conversational and focused
-
-OUTPUT: A complete feature specification document.
+OUTPUT: A complete feature specification document.