diff --git a/memory/architecture.md b/memory/architecture.md
new file mode 100644
index 000000000..dfd637b71
--- /dev/null
+++ b/memory/architecture.md
@@ -0,0 +1,416 @@
+# Architecture Description: [SYSTEM_NAME]
+
+**Version**: 1.0 | **Created**: [DATE] | **Last Updated**: [DATE]  
+**Architect**: [AUTHOR/AI] | **Status**: Draft | Review | Approved
+**ADR Reference**: [memory/adr.md](memory/adr.md)
+
+---
+
+## 1. Introduction
+
+### 1.1 Purpose
+
+[Describe why this system exists - the business/technical problem it solves]
+
+### 1.2 Scope
+
+**In Scope:**
+
+- [Feature/capability 1]
+- [Feature/capability 2]
+
+**Out of Scope:**
+
+- [Explicitly excluded feature/capability 1]
+- [Explicitly excluded feature/capability 2]
+
+### 1.3 Definitions & Acronyms
+
+| Term | Definition |
+|------|------------|
+| AD | Architecture Description - this document |
+| ADR | Architecture Decision Record - documented architectural decisions |
+
+---
+
+## 2. Stakeholders & Concerns
+
+| Stakeholder | Role | Key Concerns | Priority |
+|-------------|------|--------------|----------|
+| [STAKEHOLDER_1] | [e.g., Product Owner] | [e.g., Feature delivery, cost control] | High |
+| [STAKEHOLDER_2] | [e.g., Operations Team] | [e.g., System uptime, deployability] | High |
+| [STAKEHOLDER_3] | [e.g., Security Officer] | [e.g., Data protection, compliance] | Critical |
+| [STAKEHOLDER_4] | [e.g., End Users] | [e.g., Performance, usability] | High |
+
+---
+
+## 3. Architectural Views (Rozanski & Woods)
+
+### 3.1 Context View
+
+**Purpose**: Define system scope and external interactions
+
+#### 3.1.1 System Scope
+
+[High-level description of what the system does and its boundaries]
+
+#### 3.1.2 External Entities
+
+| Entity | Type | Interaction Type | Data Exchanged | Protocols |
+|--------|------|------------------|----------------|-----------|
+| [ENTITY_1] | User/System/API | [e.g., REST API, UI] | [e.g., User credentials] | [e.g., HTTPS] |
+| [ENTITY_2] | [External System] | [Integration method] | [Data format] | [Protocol] |
+
+#### 3.1.3 Context Diagram
+
+```mermaid
+graph TD
+    Users["Users"]
+    System["System<br/>(Main Application)"]
+    Database["Database"]
+    ExternalAPI["External APIs"]
+    
+    Users -->|Requests| System
+    System -->|Queries| Database
+    System -->|Integrates| ExternalAPI
+    
+    classDef systemNode fill:#f47721,stroke:#333,stroke-width:2px,color:#fff
+    classDef externalNode fill:#e0e0e0,stroke:#333,stroke-width:1px
+    
+    class System systemNode
+    class Users,Database,ExternalAPI externalNode
+```
+
+#### 3.1.4 External Dependencies
+
+| Dependency | Purpose | SLA Expectations | Fallback Strategy |
+|------------|---------|------------------|-------------------|
+| [DEPENDENCY_1] | [Purpose] | [e.g., 99.9% uptime] | [e.g., Cache, degraded mode] |
+
+---
+
+### 3.2 Functional View
+
+**Purpose**: Describe functional elements, their responsibilities, and interactions
+
+#### 3.2.1 Functional Elements
+
+| Element | Responsibility | Interfaces Provided | Dependencies |
+|---------|----------------|---------------------|--------------|
+| [COMPONENT_1] | [e.g., User authentication] | [e.g., REST /auth/*] | [e.g., Database] |
+| [COMPONENT_2] | [Responsibility] | [Interfaces] | [Dependencies] |
+
+#### 3.2.2 Element Interactions
+
+```mermaid
+graph TD
+    APIGateway["API Gateway"]
+    AuthService["Authentication<br/>Service"]
+    BusinessLogic["Business Logic<br/>Layer"]
+    DataAccess["Data Access<br/>Layer"]
+    
+    APIGateway -->|Routes| AuthService
+    APIGateway -->|Routes| BusinessLogic
+    AuthService -->|Validates| BusinessLogic
+    BusinessLogic -->|Queries| DataAccess
+    
+    classDef serviceNode fill:#4a9eff,stroke:#333,stroke-width:2px,color:#fff
+    classDef dataNode fill:#66c2a5,stroke:#333,stroke-width:2px,color:#fff
+    
+    class APIGateway,AuthService,BusinessLogic serviceNode
+    class DataAccess dataNode
+```
+
+#### 3.2.3 Functional Boundaries
+
+**What this system DOES:**
+
+- [Functionality 1]
+- [Functionality 2]
+
+**What this system does NOT do:**
+
+- [Excluded functionality 1]
+- [Excluded functionality 2]
+
+---
+
+### 3.3 Information View
+
+**Purpose**: Describe data storage, management, and flow
+
+#### 3.3.1 Data Entities
+
+| Entity | Storage Location | Owner Component | Lifecycle | Access Pattern |
+|--------|------------------|-----------------|-----------|----------------|
+| [ENTITY_1] | [e.g., PostgreSQL] | [e.g., UserService] | [e.g., Create-Update-Archive] | [e.g., Read-heavy] |
+
+#### 3.3.2 Data Flow
+
+**Key Data Flows:**
+
+1. **[Flow Name]**: [Source] -> [Transformation] -> [Destination]
+2. **[Flow Name]**: [Description of data movement]
+
+#### 3.3.3 Data Quality & Integrity
+
+- **Consistency Model**: [e.g., Eventual, Strong, ACID]
+- **Validation Rules**: [Key data validation points]
+- **Retention Policy**: [Data lifecycle requirements]
+- **Backup Strategy**: [Backup approach]
+
+---
+
+### 3.4 Concurrency View
+
+**Purpose**: Describe runtime processes, threads, and coordination
+
+#### 3.4.1 Process Structure
+
+| Process | Purpose | Scaling Model | State Management |
+|---------|---------|---------------|------------------|
+| [PROCESS_1] | [e.g., API Server] | [e.g., Horizontal - stateless] | [Stateless/Stateful] |
+
+#### 3.4.2 Thread Model
+
+- **Threading Strategy**: [e.g., Thread pool, Event-driven async]
+- **Async Patterns**: [e.g., Async/await, reactive streams]
+- **Resource Pools**: [e.g., Database connection pool]
+
+#### 3.4.3 Coordination Mechanisms
+
+- **Synchronization**: [e.g., Distributed locks via Redis]
+- **Communication**: [e.g., Message queues, event bus]
+- **Deadlock Prevention**: [e.g., Lock ordering, timeouts]
+
+---
+
+### 3.5 Development View
+
+**Purpose**: Constraints for developers - code organization, dependencies, CI/CD
+
+#### 3.5.1 Code Organization
+
+```text
+project-root/
+├── src/
+│   ├── api/              # API endpoints
+│   ├── services/         # Business logic
+│   ├── models/           # Data models
+│   └── repositories/     # Data access
+├── tests/
+│   ├── unit/
+│   ├── integration/
+│   └── e2e/
+└── infra/                # Infrastructure as code
+```
+
+#### 3.5.2 Module Dependencies
+
+**Dependency Rules:**
+
+- API layer depends on Services layer (not vice versa)
+- Services layer depends on Repositories layer
+- No circular dependencies allowed
+
+#### 3.5.3 Build & CI/CD
+
+- **Build System**: [e.g., npm, gradle, cargo]
+- **CI Pipeline**: [Key stages]
+- **Deployment Strategy**: [e.g., Blue-green, rolling]
+
+#### 3.5.4 Development Standards
+
+- **Coding Standards**: [e.g., ESLint config, PEP 8]
+- **Review Requirements**: [e.g., 2 approvals]
+- **Testing Requirements**: [e.g., 80% coverage]
+
+---
+
+### 3.6 Deployment View
+
+**Purpose**: Physical environment - nodes, networks, storage
+
+#### 3.6.1 Runtime Environments
+
+| Environment | Purpose | Infrastructure | Scale |
+|-------------|---------|----------------|-------|
+| Production | Live users | [e.g., AWS EKS] | [e.g., 10 nodes] |
+| Staging | Pre-release | [e.g., AWS EKS] | [e.g., 3 nodes] |
+| Development | Dev testing | [e.g., Docker Compose] | [e.g., 1 node] |
+
+#### 3.6.2 Network Topology
+
+```mermaid
+graph TB
+    subgraph "Production"
+        LB["Load Balancer"]
+        
+        subgraph "App Tier"
+            Web1["Web Server 1"]
+            Web2["Web Server 2"]
+        end
+        
+        subgraph "Data Tier"
+            DB["Database"]
+            Cache["Cache"]
+        end
+    end
+    
+    Internet["Internet"] -->|HTTPS| LB
+    LB --> Web1
+    LB --> Web2
+    Web1 --> DB
+    Web2 --> DB
+    Web1 --> Cache
+    Web2 --> Cache
+```
+
+#### 3.6.3 Hardware Requirements
+
+| Component | CPU | Memory | Storage |
+|-----------|-----|--------|---------|
+| Web Server | [e.g., 2 cores] | [e.g., 4GB] | [e.g., 20GB] |
+| Database | [Specs] | [Specs] | [Specs] |
+
+---
+
+### 3.7 Operational View
+
+**Purpose**: Operations, support, and maintenance in production
+
+#### 3.7.1 Operational Responsibilities
+
+| Activity | Owner | Frequency | Automation |
+|----------|-------|-----------|------------|
+| Deployment | DevOps | On-demand | Automated |
+| Backup | Operations | Daily | Automated |
+| Monitoring | SRE | Continuous | Automated |
+
+#### 3.7.2 Monitoring & Alerting
+
+- **Key Metrics**: [e.g., Latency, error rate, throughput]
+- **Alerting Rules**: [e.g., Error rate > 1% -> Page on-call]
+- **Logging Strategy**: [e.g., ELK stack, 30-day retention]
+
+#### 3.7.3 Disaster Recovery
+
+- **RTO**: [e.g., 1 hour]
+- **RPO**: [e.g., 15 minutes]
+- **Backup Strategy**: [e.g., Daily snapshots]
+
+#### 3.7.4 Support Model
+
+- **Tier 1**: Help desk
+- **Tier 2**: Application support
+- **Tier 3**: Engineering
+- **On-call**: [Rotation schedule]
+
+---
+
+## 4. Architectural Perspectives (Cross-Cutting Concerns)
+
+### 4.1 Security Perspective
+
+**Applies to**: All views
+
+#### 4.1.1 Authentication & Authorization
+
+- **Identity Provider**: [e.g., OAuth2 via Auth0]
+- **Authorization Model**: [e.g., RBAC, ABAC]
+- **Session Management**: [e.g., JWT with 1-hour expiry]
+
+#### 4.1.2 Data Protection
+
+- **Encryption at Rest**: [e.g., AES-256]
+- **Encryption in Transit**: [e.g., TLS 1.3]
+- **Secrets Management**: [e.g., AWS Secrets Manager]
+- **PII Handling**: [e.g., Data minimization]
+
+#### 4.1.3 Threat Model
+
+| Threat | View Affected | Likelihood | Impact | Mitigation |
+|--------|---------------|------------|--------|------------|
+| [THREAT_1] | [View] | [H/M/L] | [H/M/L] | [Mitigation] |
+
+---
+
+### 4.2 Performance & Scalability Perspective
+
+**Applies to**: Functional, Concurrency, Deployment views
+
+#### 4.2.1 Performance Requirements
+
+| Metric | Target | Measurement |
+|--------|--------|-------------|
+| Response time (p95) | [e.g., <200ms] | [e.g., APM] |
+| Throughput | [e.g., 1000 req/s] | [e.g., Load tests] |
+| Concurrent users | [e.g., 10,000] | [Method] |
+
+#### 4.2.2 Scalability Model
+
+- **Horizontal Scaling**: [Approach and limits]
+- **Vertical Scaling**: [Approach and limits]
+- **Auto-scaling Triggers**: [e.g., CPU > 70%]
+
+#### 4.2.3 Capacity Planning
+
+- **Current Capacity**: [e.g., 5,000 concurrent users]
+- **Growth Projections**: [e.g., 20% YoY]
+- **Bottlenecks**: [Identified constraints]
+
+---
+
+## 5. Global Constraints & Principles
+
+### 5.1 Technical Constraints
+
+- [CONSTRAINT_1 - e.g., "Must run on AWS"]
+- [CONSTRAINT_2 - e.g., "Python 3.11+ only"]
+- [CONSTRAINT_3 - e.g., "Max deployment size: 50MB"]
+
+### 5.2 Architectural Principles
+
+- [PRINCIPLE_1 - e.g., "API First"]
+- [PRINCIPLE_2 - e.g., "Share-nothing architecture"]
+- [PRINCIPLE_3 - e.g., "Immutable infrastructure"]
+- [PRINCIPLE_4 - e.g., "Defense in depth"]
+
+---
+
+## 6. ADR Summary
+
+Detailed Architecture Decision Records are maintained in [memory/adr.md](memory/adr.md).
+
+**Key Decisions:**
+
+| ID | Decision | Status | Impact |
+|----|----------|--------|--------|
+| ADR-001 | [Title] | Accepted | [High/Med/Low] |
+| ADR-002 | [Title] | Accepted | [High/Med/Low] |
+
+---
+
+## Appendix
+
+### A. Glossary
+
+| Term | Definition |
+|------|------------|
+| [TERM] | [Definition] |
+
+### B. References
+
+- [Architecture documentation]
+- [External standards]
+- [Relevant ADRs]
+
+### C. Tech Stack Summary
+
+**Languages**: [e.g., Python 3.11, TypeScript]  
+**Frameworks**: [e.g., FastAPI, React]  
+**Databases**: [e.g., PostgreSQL, Redis]  
+**Infrastructure**: [e.g., Kubernetes, Terraform]  
+**Cloud Platform**: [e.g., AWS]  
+**CI/CD**: [e.g., GitHub Actions]  
+**Monitoring**: [e.g., Datadog]
diff --git a/scripts/bash/setup-architecture.sh b/scripts/bash/setup-architecture.sh
index 0f8f9653b..3507f07d2 100755
--- a/scripts/bash/setup-architecture.sh
+++ b/scripts/bash/setup-architecture.sh
@@ -4,6 +4,7 @@ set -e
 
 JSON_MODE=false
 ACTION=""
+TEAM_SIZE=""
 ARGS=()
 VIEWS="core"
 ADR_HEURISTIC="surprising"
@@ -33,6 +34,20 @@ while [[ $# -gt 0 ]]; do
             ADR_HEURISTIC="${1#*=}"
             shift
             ;;
+        --team-size=*)
+            TEAM_SIZE="${arg#--team-size=}"
+            ;;
+        --team-size)
+            # Next arg will be the value, handled below
+            TEAM_SIZE="__NEXT__"
+            ;;
+        small|medium|large)
+            if [[ "$TEAM_SIZE" == "__NEXT__" ]]; then
+                TEAM_SIZE="$arg"
+            else
+                ARGS+=("$arg")
+            fi
+            ;;
         init|map|update|review|specify|implement|clarify)
             ACTION="$1"
             shift
@@ -437,7 +452,7 @@ $diagram_code
 # Action: Specify (greenfield - interactive PRD exploration to create ADRs)
 action_specify() {
     local adr_file="$REPO_ROOT/memory/adr.md"
-    local adr_template="$REPO_ROOT/.specify/templates/adr-template.md"
+    local adr_template="$SPECKIT_TEMPLATES_DIR/adr-template.md"
     
     echo "📐 Setting up for interactive ADR creation..." >&2
     
@@ -518,7 +533,7 @@ action_clarify() {
 action_implement() {
     local adr_file="$REPO_ROOT/memory/adr.md"
     local ad_file="$REPO_ROOT/AD.md"
-    local ad_template="$REPO_ROOT/.specify/templates/AD-template.md"
+    local ad_template="$SPECKIT_TEMPLATES_DIR/AD-template.md"
     
     if [[ ! -f "$adr_file" ]]; then
         echo "❌ ADR file does not exist: $adr_file" >&2
@@ -573,7 +588,7 @@ action_init() {
         echo "❌ Template not found: $AD_TEMPLATE_FILE" >&2
         exit 1
     fi
-    
+
     echo "📐 Initializing architecture from template..." >&2
     
     # Scan existing docs for deduplication
diff --git a/templates/AD-template-lean.md b/templates/AD-template-lean.md
new file mode 100644
index 000000000..1424f1def
--- /dev/null
+++ b/templates/AD-template-lean.md
@@ -0,0 +1,135 @@
+# Architecture Description: [SYSTEM_NAME]
+
+**Version**: 1.0 | **Created**: [DATE] | **Last Updated**: [DATE]
+**Author**: [AUTHOR/AI] | **Status**: Draft | Review | Approved
+**ADR Reference**: [memory/adr.md](memory/adr.md)
+
+> This is a lean architecture description for small-to-medium teams.
+> For the full Rozanski & Woods template, use `AD-template.md`.
+
+---
+
+## 1. Risks, Gaps & Recommendations
+
+> The most actionable section — what's missing, what could break, and what to fix first.
+
+### Critical (Address Soon)
+
+| Finding | Impact | Recommendation |
+|---------|--------|----------------|
+| [FINDING] | [IMPACT] | [RECOMMENDATION] |
+
+### Important (Plan For)
+
+| Finding | Impact | Recommendation |
+|---------|--------|----------------|
+| [FINDING] | [IMPACT] | [RECOMMENDATION] |
+
+### Nice to Have
+
+| Finding | Impact | Recommendation |
+|---------|--------|----------------|
+| [FINDING] | [IMPACT] | [RECOMMENDATION] |
+
+---
+
+## 2. System Overview
+
+[2-3 sentences: What does this system do? Who uses it? What problem does it solve?]
+
+---
+
+## 3. Context Diagram
+
+**Purpose**: The system and everything it talks to
+
+```mermaid
+graph TD
+    Users["Users"]
+    System["[SYSTEM_NAME]"]
+    Database["Database"]
+    ExternalAPI["External APIs"]
+
+    Users -->|Requests| System
+    System -->|Queries| Database
+    System -->|Integrates| ExternalAPI
+
+    classDef systemNode fill:#f47721,stroke:#333,stroke-width:2px,color:#fff
+    classDef externalNode fill:#e0e0e0,stroke:#333,stroke-width:1px
+
+    class System systemNode
+    class Users,Database,ExternalAPI externalNode
+```
+
+### External Dependencies
+
+| Dependency | Purpose | Failure Impact |
+|------------|---------|----------------|
+| [DEPENDENCY] | [PURPOSE] | [WHAT BREAKS] |
+
+---
+
+## 4. Key Data Flows
+
+Describe the 2-3 most important paths through the system in narrative form.
+
+### [Flow 1 Name] (e.g., "User Authentication")
+
+[Source] -> [Step 1] -> [Step 2] -> [Destination]
+
+Brief narrative: what happens, what data moves, what can go wrong.
+
+### [Flow 2 Name] (e.g., "Core Business Operation")
+
+[Source] -> [Step 1] -> [Step 2] -> [Destination]
+
+Brief narrative.
+
+---
+
+## 5. Deployment Topology
+
+**Purpose**: How the system runs in production
+
+```mermaid
+graph TB
+    subgraph "Production"
+        LB["Load Balancer"]
+        App["Application"]
+        DB["Database"]
+    end
+
+    Internet["Internet"] -->|HTTPS| LB
+    LB --> App
+    App --> DB
+```
+
+| Environment | Infrastructure | Notes |
+|-------------|----------------|-------|
+| Production | [e.g., AWS EC2, Docker] | [e.g., Single instance] |
+| Staging | [e.g., Same as prod] | [Optional] |
+| Development | [e.g., Docker Compose] | [Local dev setup] |
+
+---
+
+## 6. Tech Stack Summary
+
+| Category | Technology | Notes |
+|----------|------------|-------|
+| Language | [e.g., TypeScript] | |
+| Framework | [e.g., Next.js] | |
+| Database | [e.g., PostgreSQL] | |
+| ORM | [e.g., Prisma] | |
+| Cloud | [e.g., AWS] | |
+| CI/CD | [e.g., GitHub Actions] | |
+| Monitoring | [e.g., None / Datadog] | |
+
+---
+
+## ADR Summary
+
+Detailed Architecture Decision Records are maintained in [memory/adr.md](memory/adr.md).
+
+| ID | Decision | Confidence |
+|----|----------|------------|
+| ADR-001 | [Title] | [HIGH/MED/LOW] |
diff --git a/templates/adr-template.md b/templates/adr-template.md
index 6bdc3061c..d38803a3f 100644
--- a/templates/adr-template.md
+++ b/templates/adr-template.md
@@ -103,6 +103,7 @@ State the decision that was made. Use active voice: "We will..." or "The system
 
 - **Proposed**: Decision under discussion
 - **Accepted**: Decision approved and in effect
+- **Discovered**: Inferred from existing codebase (used by `/architect.init`)
 - **Deprecated**: Decision no longer applicable
 - **Superseded**: Replaced by newer decision (reference successor ADR)
 - **Discovered**: Inferred from existing codebase (brownfield reverse-engineering)
@@ -115,6 +116,7 @@ State the decision that was made. Use active voice: "We will..." or "The system
 - Be honest about trade-offs and risks
 - Link related decisions for traceability
 - Update status when decisions evolve
+- For discovered ADRs: cite evidence, mark confidence levels, never fabricate rejection rationale
 
 **Integration with Architecture:**
 
diff --git a/templates/commands/architect.init.md b/templates/commands/architect.init.md
index 070654b51..5b84addfb 100644
--- a/templates/commands/architect.init.md
+++ b/templates/commands/architect.init.md
@@ -30,6 +30,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 - `"Django monolith with PostgreSQL, React frontend, AWS deployment"`
 - `"Node.js microservices with MongoDB and RabbitMQ"`
 - `"Legacy Java application, focus on understanding data layer"`
+- `"--team-size small"` — override auto-detected team size
 - Empty input: Scan entire codebase and infer architecture
 
 When users provide context, use it to focus the reverse-engineering effort.
@@ -61,8 +62,8 @@ You are acting as an **Architecture Archaeologist** uncovering implicit architec
 
 - **Scanning** codebase for technology choices and patterns
 - **Inferring** architectural decisions from code structure
-- **Documenting** discovered patterns as ADRs
-- **Identifying** gaps where decisions are unclear
+- **Documenting** only the decisions that add value (non-obvious, surprising, or risky)
+- **Identifying** gaps, risks, and technical debt
 
 ### Brownfield vs Greenfield
 
@@ -125,7 +126,55 @@ You are acting as an **Architecture Archaeologist** uncovering implicit architec
    | ORM migrations | Relational DB |
    | DynamoDB SDK usage | AWS DynamoDB |
 
-### Phase 2: Pattern Recognition
+### Phase 2: Context Calibration
+
+**Objective**: Determine project scale to calibrate output depth
+
+1. **Estimate team size** using these signals (in priority order):
+   - **User override**: If `--team-size small|medium|large` was passed, use that directly
+   - **Git history**: Count unique committers in `git log` (last 6 months)
+   - **Project docs**: Check for `CLAUDE.md`, `AGENTS.md`, `CONTRIBUTING.md` — team references, contributor guidelines
+   - **Repo indicators**: Number of active branches, PR volume
+
+2. **Assign tier**:
+
+   | Tier | Team Size | Characteristics |
+   |------|-----------|-----------------|
+   | **small** | 1-3 engineers | Startup, side project, solo dev. Everyone knows the codebase. |
+   | **medium** | 4-15 engineers | Growing team. Some specialization, onboarding matters. |
+   | **large** | 16+ engineers | Multiple teams. Formal processes, compliance needs. |
+
+3. **Output depth per tier**:
+
+   | Aspect | Small | Medium | Large |
+   |--------|-------|--------|-------|
+   | ADRs | Only surprising/non-obvious decisions | Key decisions + framework deviations | Comprehensive (all categories) |
+   | Architecture doc | Lean template (AD-template-lean.md) | Lean template + optional expanded sections | Full Rozanski & Woods (AD-template.md) |
+   | Gap analysis | **Primary output** — lead with this | Prominent section | Standard appendix |
+   | Alternatives section | Skip unless genuinely informative | Brief "Common Alternatives" | Full analysis |
+
+### Phase 3: Existing Documentation Scan
+
+**Objective**: Avoid duplicating what's already documented
+
+1. **Check for existing docs** at repo root and common locations:
+   - `CLAUDE.md`, `AGENTS.md` — AI agent instructions (often contain architecture/conventions)
+   - `CONTRIBUTING.md`, `README.md` — project conventions and setup
+   - `docs/` directory — existing documentation
+   - `.specify/` directory — existing spec framework artifacts
+
+2. **Extract already-documented information**:
+   - Coding conventions and style rules
+   - Architecture patterns (e.g., "UI -> API -> Service -> Model")
+   - Technology choices already explained
+   - Deployment and infrastructure details
+
+3. **Set deduplication context**: Store a summary of what's already documented. In Phase 7 (Output), you will:
+   - **Not repeat** conventions, patterns, or decisions already documented elsewhere
+   - **Add a complementary note** at the top of generated output referencing existing docs
+   - **Focus on gaps** — document what existing docs *don't* cover
+
+### Phase 4: Pattern Recognition
 
 **Objective**: Identify architectural patterns from code structure
 
@@ -187,16 +236,23 @@ You are acting as an **Architecture Archaeologist** uncovering implicit architec
 
 ### Phase 2: Pattern Detection
 
-**Objective**: Document discovered decisions as ADRs
+1. **A new engineer would be surprised by this choice** — it's not what you'd expect for this type of project
+2. **A reasonable person might be tempted to change it** — the decision needs context to understand why it was made
+3. **The decision goes against framework/ecosystem conventions** — e.g., CSR-only in Next.js, NoSQL for relational data, monorepo without a monorepo tool
+
+**Do NOT generate ADRs for:**
+
+- Standard/default technology choices that match the ecosystem norm (e.g., "PostgreSQL for relational data", "React for frontend when package.json shows React", "Winston for Node.js logging", "Nginx as reverse proxy", "Jest for testing in a Node.js project")
+- Choices that are obvious from the project type (e.g., "npm for package management" in a Node.js project)
+- Infrastructure defaults (e.g., "Docker for containerization" when there's a Dockerfile)
 
-For each discovered architectural decision:
+**For small teams**: Apply this filter aggressively. A 2-person team doesn't need an ADR explaining why they use PostgreSQL. Focus on decisions that would trip up a new hire or a future maintainer.
 
-1. **Identify the Decision**:
-   - What technology/pattern was chosen?
-   - What alternatives were available when this was built?
-   - What forces likely drove this decision?
+**For large teams**: Be more inclusive — document more decisions for compliance and onboarding purposes, but still skip truly obvious defaults.
 
-2. **Create ADR Entry**:
+#### ADR Template for Discovered Decisions
+
+For each ADR that passes the filter:
 
 ```markdown
 ## ADR-[NNN]: [Discovered Decision]
@@ -259,9 +315,13 @@ Legacy/Inferred
 
 ### Phase 5: Gap Analysis
 
-**Objective**: Identify areas where decisions are unclear
+#### Security Concerns
+- Secrets in code or config files
+- Missing CORS configuration
+- No input validation middleware
+- Authentication/authorization gaps
 
-After scanning, report:
+Format findings as **actionable items**, not just observations:
 
 ```markdown
 ## Architecture Discovery Report
@@ -309,9 +369,20 @@ After scanning, report:
 
 ### Phase 6: Output Generation
 
-**Objective**: Write discoveries to files
+**Objective**: Write discoveries to files, calibrated to team size
+
+1. **Add complementary note** if existing docs were found (Phase 3):
+
+   ```markdown
+   > This document complements existing project documentation ([CLAUDE.md], [README.md], etc.).
+   > Conventions and coding standards documented there are not repeated here.
+   ```
 
-1. **Write ADRs**:
+2. **Write Risks & Gaps** (most valuable content):
+   - For **small teams**: This goes at the TOP of `memory/architecture.md`, before architectural views
+   - For **medium/large teams**: This goes in a prominent section (not buried as an appendix)
+
+3. **Write ADRs**:
    - Create or update `memory/adr.md` with discovered ADRs
    - Mark ADRs as "Discovered (Inferred)" status ← USE THIS STATUS
    - Use "Common Alternatives" section with neutral trade-offs (no "Rejected because")
@@ -332,10 +403,23 @@ After scanning, report:
 
 ### Evidence-Based Documentation
 
-- **Only document what's found in code** - don't invent decisions
+- **Only document what's found in code** — don't invent decisions
 - **Cite specific evidence** for each ADR
 - **Mark confidence levels** honestly
 - **Flag uncertainties** explicitly
+- **Never fabricate rejection rationale** for alternatives in discovered ADRs
+
+### Surprise-Value Filter
+
+- **Skip obvious defaults** — don't document decisions that match ecosystem norms
+- **Document what surprises** — non-obvious choices, convention violations, unusual constraints
+- **Scale with team size** — small teams get fewer, more targeted ADRs
+
+### No Duplication
+
+- **Read existing docs first** — CLAUDE.md, README, CONTRIBUTING, etc.
+- **Don't repeat** what's already documented elsewhere
+- **Reference, don't reproduce** — link to existing docs instead of copying content
 
 ### Confidence Levels
 
@@ -370,10 +454,11 @@ After scanning, report:
 
 Recommended next steps:
 
-1. **Review Discoveries**: Verify inferred ADRs are accurate
-2. **Run `/architect.clarify`**: Fill gaps with human knowledge
-3. **Run `/architect.implement`**: Generate full AD.md from ADRs
-4. **Update As Needed**: Refine documentation as you learn more
+1. **Address Critical Gaps**: Fix any critical risks/gaps identified
+2. **Review Discoveries**: Verify inferred ADRs are accurate
+3. **Run `/architect.clarify`**: Fill gaps with human knowledge
+4. **Run `/architect.implement`**: Generate full AD.md from ADRs (for medium/large teams)
+5. **Update As Needed**: Refine documentation as you learn more
 
 ### When to Use This Command