buildanything 1.8.0 → 2.1.1

package/.claude-plugin/marketplace.json

@@ -4,15 +4,15 @@
     "name": "Sujit"
   },
   "metadata": {
-    "description": "buildanything — one command to build an entire product. 73 agents, 2 commands, zero overwhelm.",
+    "description": "buildanything — one command to build an entire product. 44 agents, 2 commands, zero overwhelm.",
     "version": "1.0.0"
   },
   "plugins": [
     {
       "name": "buildanything",
       "source": "./",
-      "description": "Full product build pipeline with 73 specialist agents orchestrated across architecture, implementation, testing, and hardening phases. Includes /build (full factory) and /idea-sweep (parallel research).",
-      "version": "1.8.0"
+      "description": "Full product build pipeline with 44 specialist agents orchestrated across architecture, implementation, testing, and hardening phases. Includes /build (full factory) and /idea-sweep (parallel research).",
+      "version": "2.1.1"
     }
   ]
 }

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "buildanything",
-  "version": "1.8.0",
-  "description": "One command to build an entire product. 73 specialist agents orchestrated into a full engineering pipeline — from idea to shipped, tested, reviewed code.",
+  "version": "2.1.1",
+  "description": "One command to build an entire product. 44 specialist agents orchestrated into a full engineering pipeline — from idea to shipped, tested, reviewed code.",
   "author": {
     "name": "Sujit"
   },
@@ -13,5 +13,19 @@
     "build",
     "testing",
     "architecture"
-  ]
+  ],
+  "config": {
+    "sdkStateFile": ".buildanything/sdk-state",
+    "claudeCodeHostRange": ">=1.5.0 <3.0.0",
+    "sdkVersion": "0.2.114",
+    "maxSupportedSchemaVersion": 2
+  },
+  "mcpServers": {
+    "orchestrator": {
+      "command": "${CLAUDE_PLUGIN_ROOT}/bin/mcp-servers/orchestrator-mcp.js"
+    },
+    "graph": {
+      "command": "${CLAUDE_PLUGIN_ROOT}/bin/mcp-servers/graph-mcp.js"
+    }
+  }
 }

package/CHANGELOG.md

@@ -2,6 +2,63 @@
 
 All notable changes to `buildanything` are documented here.
 
+## [2.0.0] — 2026-04-18
+
+### Breaking Changes
+
+- **Requires Claude Code ≥ 1.5.0** — orchestrator now uses the Claude Agent SDK for all subagent dispatch. Older hosts do not support the SDK runtime.
+- **State files are forward-rejected** — `.build-state.json` files with `schema_version > 2` are rejected at startup rather than silently misread. Resume an older build with the same plugin version that wrote it.
+
+### Added — SDK Orchestration Infrastructure
+
+The orchestrator migrated from markdown-loop dispatch to the Claude Agent SDK. Four MCP handlers ship with the plugin and are wired at runtime:
+
+- **`scribe_decision` MCP** — single writer for `decisions.jsonl`; ensures concurrent phases cannot race-write the decision log
+- **`acquire_write_lease` / `release_write_lease` MCP** — prevents intra-phase file collisions; implementer dispatches must hold an exclusive lease before any Write/Edit operation
+- **`state_save` MCP** — atomic `.build-state.json` writes (write-to-.tmp + rename + SHA-256 integrity)
+- **`increment_cycle` MCP** — backward-routing cycle counter with re-entry halt at `max_cycles`
+
+### Added — Writer-Owner Enforcement
+
+- **PreToolUse hook** reads `phase-graph.yaml` (compiled to a JSON cache at session-start) and denies Write/Edit/MultiEdit when the current phase or subagent type is not the declared owner of the target path
+- **Default-deny** for all paths under protected prefixes (`docs/plans/`, `hooks/`, `src/orchestrator/`, etc.) that are not in the writer-owner table
+- **Hard-deny** for raw writes to `.build-state.json` — must route through `state_save` MCP
+- **Subagent-role enforcement** — `lrr/<chapter>.json` restricted to the 5 LRR chapter subagents; aggregator cannot write chapter files
+
+### Added — Sprint-Context Hoisting (Stage 6)
+
+Phase 4 implementation prompts now hoist the sprint context block into the static cache layer. Per-task refs blocks are replaced with a pointer. Measured: ~−15% cumulative token cost vs. markdown baseline on reference builds.
+
+### Added — Token Accounting
+
+- SubagentStart/Stop hooks record per-phase token usage into `.build-state.json`
+- Orchestrator surfaces cumulative cost at every phase boundary
+
+### Added — Anti-Slop Gates
+
+- gstack-inspired quality gates added to LRR: 7th Copy axis (does the output read like a template?), Goodwill Reservoir (does the output spend its reader's attention wisely?)
+- Reality Checker rewrite — stricter evidence requirements before shipping gate passes
+
+### Added — iOS Auto-Install
+
+`npx buildanything --ios` and `/buildanything:setup` now auto-install the iOS toolchain (XcodeBuildMCP, apple-docs-mcp, Maestro) without manual steps.
+
+### Fixed
+
+- Write-lease `releaseLease()` now removes ALL leases held by a task, not just the first
+- `persistLeases()` failure no longer creates a fail-closed scenario — disk and in-memory state are kept consistent
+- `gen-critic.ts` dead code wired into Stage 4 generator/critic separation flow
+- SubagentStop hook auto-releases all leases on dispatch return
+- Lease manager loads persisted leases from disk at runtime startup (survived process restart)
+
+### Changed
+
+- `task_id` derivation tightened to STRICT mode: derived only from `parent_tool_use_id` (per SDK subagent propagation), not from `tool_use_id` or env vars
+- Phase graph YAML is the authoritative runtime source for all routing, writer-owner, and dispatch tables — prose in `build.md` is narrative only
+- SSOT drift CI workflow enforces YAML/prose consistency on every push
+
+---
+
 ## [1.8.0] — 2026-04-04
 
 ### Added — iOS Mode (Swift-only)

package/README.md

@@ -2,9 +2,9 @@
 
 **One command to build an entire product.**
 
-buildanything is a Claude Code plugin that orchestrates 55 specialist AI agents into a full engineering pipeline — from idea to shipped, tested, reviewed code. You describe what you want to build. buildanything handles research, design, architecture, implementation, behavioral testing, and hardening.
+buildanything is a Claude Code plugin that orchestrates 48 specialist AI agents into a full engineering pipeline — from idea to shipped, tested, reviewed code. You describe what you want to build. buildanything handles research, design, architecture, implementation, behavioral testing, and hardening.
 
-No agent expertise required. No manual coordination. Just `/build`.
+Works for both **web apps** and **iOS/Swift apps**.
 
 ## Install
 
@@ -12,34 +12,42 @@ No agent expertise required. No manual coordination. Just `/build`.
 npx buildanything
 ```
 
-This installs the plugin, companion plugins, and [agent-browser](https://github.com/vercel-labs/agent-browser) for behavioral testing.
+This installs the plugin and companion tools (agent-browser for behavioral testing, Playwright for E2E).
 
-**Or manually in Claude Code:**
+For iOS builds, run the iOS setup instead:
 ```
-/plugin marketplace add sujitmeka/buildanything
-/plugin install buildanything@buildanything-marketplace
+npx buildanything --ios
 ```
 
+This additionally installs XcodeBuildMCP, apple-docs-mcp, and Maestro.
+
 ## Commands
 
 ### `/build` — Full Product Pipeline
 
-Takes an idea and builds it through 8 phases with quality gates, metric-driven iteration loops, and behavioral verification:
+Takes an idea and builds it through 8 phases (0–7) with quality gates, three-tier dispatch, per-feature behavioral verification, and a final launch review. iOS builds add a bootstrap phase (-1) for Xcode project + Maestro scaffold.
+
+0. **Discover** — Scans for existing work, detects project type (web vs iOS), checks prerequisites, replays prior-build learnings.
+1. **Plan** — Interactive brainstorming + 4 parallel research agents (market, tech, user, business) → PRD + product spec (canonical feature inventory: states, transitions, business rules, persona constraints, acceptance criteria) + per-project CLAUDE.md.
+2. **Architect** — 6-architect team (backend, frontend, data, security, accessibility, performance) cross-checking each other → architecture doc + sprint task DAG.
+3. **Design** — Competitive research, brand DNA card, component manifest, per-screen wireframes, living `/design-system` route, design critic loop targeting 195/240 across 7 DNA axes + 5 craft dimensions.
+4. **Build** — Three-tier dispatch: Product Owner sequences features → Briefing Officer per feature decomposes into structured task briefs → implementers query the graph for spec slices and execute. Per-task verify gate after each.
+5. **Audit** — Three orthogonal layers run in parallel:
+   - **Track A (engineering reality)** — 5 parallel auditors: API contract, performance, accessibility, security, brand drift.
+   - **Track B (product reality)** — one auditor per feature, runs 7 check classes (screen reachability, state coverage, transition firing, business-rule enforcement, happy path, persona walkthrough, manifest wiring) against the live app.
+   - **Cross-cutting** — Playwright E2E for multi-feature journeys, autonomous dogfooding for emergent issues, fake-data detector for hardcoded mocks.
 
-0. **Context & Pre-Flight** — Scans for existing work, checks prerequisites, initializes state.
-1. **Brainstorm & Research** — Interactive brainstorming + 5 parallel research agents (market, tech, user, business, risk). Writes CLAUDE.md as the product brain.
-2. **Architecture & Planning** — 4 parallel architecture agents + sprint planning with user journeys, NFRs, and behavioral acceptance criteria per task.
-3. **Design & Visual Identity** — Competitive research via Playwright, living style guide with every component rendered and interactive, visual QA scoring at 80/100. Anti-AI-template detection.
-4. **Foundation** — Scaffolding, design system from style guide, acceptance test stubs (TDD-style — tests fail until features are built).
-5. **Build** — Per-task: implement → cleanup → metric loop → behavioral smoke test (agent-browser) → 7-check verification. Each task verified before the next starts.
-6. **Harden** — 5 parallel audits (API, performance, accessibility, security, UX quality) → eval harness → metric loop → E2E tests from user journeys → autonomous dogfooding → fake data detector → Reality Checker with fix-and-retest loops.
-7. **Ship** — Requirements coverage report, documentation, learnings capture.
+   All findings consolidate at the feedback synthesizer, then route to a fix loop.
+6. **Launch Review** — 5 chapter judges (engineering quality, security, SRE, accessibility, brand) + aggregator that can route back to earlier phases on BLOCK.
+7. **Ship** — Documentation, deployment, learnings capture.
 
 ```
 /build a prediction market maker for Polymarket
 /build docs/plans/my-design.md --autonomous
 ```
 
+For iOS builds, the pipeline automatically routes to a Swift-native flow (SwiftUI, Swift 6.2, SwiftData, iOS 26 SDK).
+
 ### `/idea-sweep` — Parallel Research Sweep
 
 5 research agents evaluate an idea in parallel. Outputs a decision brief: GO / PIVOT / INVESTIGATE / KILL.
@@ -52,76 +60,64 @@ Takes an idea and builds it through 8 phases with quality gates, metric-driven i
 
 | Command | Use case |
 |---|---|
-| `/fix` | "The submit button doesn't work" — scoped bug fixing with agent-browser verification |
-| `/ux-review` | "The dashboard feels cramped" — UX audit against the living style guide, mobile checks |
-| `/add-feature` | "Add a pause button" — mini build cycle using existing design system and architecture |
+| `/fix` | "The submit button doesn't work" — scoped bug fixing with behavioral verification |
+| `/ux-review` | "The dashboard feels cramped" — UX audit against the design system |
+| `/add-feature` | "Add a pause button" — mini build cycle reusing the locked design system |
 | `/dogfood` | "Test everything" — autonomous exploratory testing of the running app |
-| `/verify` | "Does it all pass?" — quick 7-check health check |
-| `/refactor` | "Change the auth to OAuth" — architect plans the change, then incremental execution |
-
-All commands are argument-driven — they scope themselves to what you describe.
+| `/verify` | "Does it all pass?" — 7-check health check |
+| `/refactor` | "Change auth to OAuth" — architect plans, then incremental execution |
 
 ## How It Works
 
-### Behavioral Verification (agent-browser)
+### Single Source of Truth via Graph
 
-Every UI task is smoke tested after implementation. [agent-browser](https://github.com/vercel-labs/agent-browser) opens the app, clicks buttons, fills forms, and collects evidence:
+Phase 1 produces a canonical product spec (states, transitions, business rules, persona constraints, acceptance criteria). The plugin indexes it into a per-build graph. Phase 2-5 agents query the graph for typed slices instead of paraphrasing source markdown — closing the gap where product context gets lost between phases.
 
-- **Snapshot diffs** — verifies DOM actually changes when you click something
-- **Network inspection** — catches failed API calls and missing endpoints
-- **Console errors** — catches uncaught JS exceptions
-- **Annotated screenshots** — labeled visual evidence (Claude is multimodal)
-- **HAR capture** — full network traffic for fake data analysis
+### Behavioral Verification
 
-If a button doesn't work, the smoke test catches it immediately — not in Phase 6.
+Every UI task is smoke tested after implementation. [agent-browser](https://github.com/vercel-labs/agent-browser) opens the app, clicks buttons, fills forms, and collects evidence: snapshot diffs, network inspection, console errors, annotated screenshots. Track B (Phase 5) extends this to a full per-feature reality check.
 
-### Living Style Guide
+### Per-Project Brain
 
-Phase 3 builds a rendered, interactive style guide at `/design-system` with every component in every state. This ships with the product and is referenced at every stage:
+Phase 1 generates a `CLAUDE.md` file in your project root (<200 lines). This becomes auto-loaded context for every agent in subsequent phases — keeping product decisions, persona constraints, and architectural notes accessible without re-reading raw research.
 
-- Phase 4: Design system tokens match the style guide
-- Phase 5: Implementation agents reference it for UI tasks
-- Phase 6: UX audit compares every page against it
+### Living Design System
 
-### Feedback Loops
+Phase 3 builds `DESIGN.md` (brand DNA + tokens + component prose) and a rendered `/design-system` route. Implementation agents reference both; the brand guardian audits the built output against the locked DNA card.
 
-Every testing step feeds back into development:
+### Feedback Loops
 
-- Smoke test fails → fix agent + re-test (max 2 cycles)
-- Dogfood finds issues → classify + fix + re-dogfood (max 3 cycles)
-- Fake data detected → fix agent replaces with real API calls (max 2 cycles)
-- Reality Checker says NEEDS WORK → classify issues + fix + re-verify + re-check (max 2 cycles)
+- Per-task smoke test fails → fix + re-test (max 2 cycles)
+- Phase 5 findings → synthesizer classifies → fix loop → re-verify (max 2 cycles)
+- LRR Aggregator says BLOCK → routes back to the originating phase for re-work
 
 Nothing gets logged and ignored.
 
-## The 55 Agents
-
-### Design (8)
-Brand Guardian · Image Prompt Engineer · Inclusive Visuals Specialist · UI Designer · UX Architect · UX Researcher · Visual Storyteller · Whimsy Injector
+## The 48 Agents
 
-### Engineering (9)
-AI Engineer · Autonomous Optimization Architect · Backend Architect · Data Engineer · DevOps Automator · Frontend Developer · Mobile App Builder · Rapid Prototyper · Security Engineer · Senior Developer · Technical Writer
+### Design (7)
+Brand Guardian · Design Critic · Inclusive Visuals Specialist · UI Designer · UX Architect · UX Researcher · Visual Research
 
-### Marketing (8)
-App Store Optimizer · Instagram Curator · Reddit Community Builder · Social Media Strategist · TikTok Strategist · Twitter Engager · WeChat Official Account Manager · Xiaohongshu Specialist · Zhihu Strategist
+### Engineering (11)
+AI Engineer · Backend Architect · Data Engineer · DevOps Automator · Frontend Developer · Mobile App Builder · Rapid Prototyper · Security Engineer · Senior Developer · SRE · Technical Writer
 
-### Product (2)
-Behavioral Nudge Engine · Feedback Synthesizer
+### iOS (8)
+App Review Guardian · Foundation Models Specialist · StoreKit Specialist · Swift Architect · Swift Search · Swift UI Design · Swift Build Resolver · Swift Reviewer
 
-### Project Management (1)
-Experiment Tracker
+### Code Quality (7)
+A11y Architect · Code Architect · Code Reviewer · Code Simplifier · Refactor Cleaner · Security Reviewer · Silent Failure Hunter
 
-### Specialized (4)
-Agentic Identity & Trust Architect · Cultural Intelligence Strategist · Developer Advocate · Data Consolidation Agent · Report Distribution Agent · Sales Data Extraction Agent
+### Testing (5)
+API Tester · Evidence Collector · Performance Benchmarker · PR Test Analyzer · Reality Checker
 
-### Support (5)
-Analytics Reporter · Executive Summary Generator · Finance Tracker · Legal Compliance Checker · Support Responder
+### Planning & Research (4)
+Business Model · Feature Intel · Planner · Tech Feasibility
 
-### Testing (7)
-Accessibility Auditor · API Tester · Evidence Collector · Performance Benchmarker · Reality Checker · Test Results Analyzer · Tool Evaluator · Workflow Optimizer
+### Product Pipeline (4)
+Product Spec Writer · Product Owner · Briefing Officer · Product Reality Auditor
 
-### Research (5)
-market-intel · tech-feasibility · user-research · business-model · risk-analysis
+### Product & Marketing (2)
+App Store Optimizer · Feedback Synthesizer
 
 ## License
 

package/agents/a11y-architect.md

@@ -0,0 +1,168 @@
+---
+name: a11y-architect
+description: Accessibility Architect specializing in WCAG 2.2 compliance for Web and Native platforms. Use PROACTIVELY when designing UI components, establishing design systems, or auditing code for inclusive user experiences.
+model: opus
+effort: xhigh
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob", "Skill"]
+---
+
+You are a Senior Accessibility Architect. Your goal is to ensure that every digital product is Perceivable, Operable, Understandable, and Robust (POUR) for all users, including those with visual, auditory, motor, or cognitive disabilities.
+
+## Skill Access
+
+The orchestrator passes these variables into your dispatch prompt: `project_type`, `phase`, and (Phase 3+) `dna`.
+
+**Rules:**
+- Load skills from this shortlist ONLY. Never consult skills outside this list, even if familiar.
+- No defaulting. When no gate matches a skill, do NOT load it.
+- No substitutions.
+
+**Project-type gated:**
+- `project_type=web` → `skills/web/accessibility` — WCAG 2.2 Level AA implementation patterns
+- `project_type=web AND task involves charts/dataviz (Recharts, Tremor, custom SVG)` → `skills/web/chart-accessibility` — ARIA roles, keyboard nav, screen reader support for SVG charts
+- `project_type=ios` → `skills/ios/hig-platforms` — platform-specific a11y context (Phase 2)
+- `project_type=ios` → `skills/ios/hig-inputs` — gestures, Apple Pencil, keyboards, pointers, Digital Crown (Phase 3 input/a11y overlap)
+- Otherwise → DO NOT load `hig-*` skills on web projects
+
+**Mode-gated (same skill, different use — web):**
+- `project_type=web AND phase=3` (design review) → `skills/web/accessibility` — design-time a11y checklist and component patterns
+- `project_type=web AND phase=5` (runtime audit) → `skills/web/accessibility` — runtime WCAG audit patterns and evidence collection
+
+**Mode-gated (same skill, different use — iOS):**
+- `project_type=ios AND phase=4` (implementation) → `skills/ios/swift-accessibility` — first-draft accessibility for SwiftUI/UIKit/AppKit; Nutrition Label categories
+- `project_type=ios AND phase=5` (runtime audit) → `skills/ios/swift-accessibility` — runtime a11y audit (VoiceOver, Dynamic Type, contrast, Reduce Motion)
+
+**Forbidden defaults:**
+- Do NOT load `skills/ios/swift-concurrency` (older) — not a11y-relevant.
+
+## Your Role
+
+- **Architecting Inclusivity**: Design UI systems that natively support assistive technologies (Screen Readers, Voice Control, Switch Access).
+- **WCAG 2.2 Enforcement**: Apply the latest success criteria, focusing on new standards like Focus Appearance, Target Size, and Redundant Entry.
+- **Platform Strategy**: Bridge the gap between Web standards (WAI-ARIA) and Native frameworks (SwiftUI/Jetpack Compose).
+- **Technical Specifications**: Provide developers with precise attributes (roles, labels, hints, and traits) required for compliance.
+
+## Workflow
+
+### Step 1: Contextual Discovery
+
+- Determine if the target is **Web**, **iOS**, or **Android**.
+- Analyze the user interaction (e.g., Is this a simple button or a complex data grid?).
+- Identify potential accessibility "blockers" (e.g., color-only indicators, missing focus containment in modals).
+
+### Step 2: Strategic Implementation
+
+- **Apply the Accessibility Skill**: Invoke specific logic to generate semantic code.
+- **Define Focus Flow**: Map out how a keyboard or screen reader user will move through the interface.
+- **Optimize Touch/Pointer**: Ensure all interactive elements meet the minimum **24x24 pixel** spacing or **44x44 pixel** target size requirements.
+
+### Step 3: Validation & Documentation
+
+- Review the output against the WCAG 2.2 Level AA checklist.
+- Provide a brief "Implementation Note" explaining _why_ certain attributes (like `aria-live` or `accessibilityHint`) were used.
+
+## Output Format
+
+For every component or page request, provide:
+
+1. **The Code**: Semantic HTML/ARIA or Native code.
+2. **The Accessibility Tree**: A description of what a screen reader will announce.
+3. **Compliance Mapping**: A list of specific WCAG 2.2 criteria addressed.
+
+## Examples
+
+### Example: Accessible Search Component
+
+**Input**: "Create a search bar with a submit icon."
+**Action**: Ensuring the icon-only button has a visible label and the input is correctly labeled.
+**Output**:
+
+```html
+<form role="search">
+  <label for="site-search" class="sr-only">Search the site</label>
+  <input type="search" id="site-search" name="q" />
+  <button type="submit" aria-label="Search">
+    <svg aria-hidden="true">...</svg>
+  </button>
+</form>
+```
+
+## WCAG 2.2 Core Compliance Checklist
+
+### 1. Perceivable (Information must be presentable)
+
+- [ ] **Text Alternatives**: All non-text content has a text alternative (Alt text or labels).
+- [ ] **Contrast**: Text meets 4.5:1; UI components/graphics meet 3:1 contrast ratios.
+- [ ] **Adaptable**: Content reflows and remains functional when resized up to 400%.
+
+### 2. Operable (Interface components must be usable)
+
+- [ ] **Keyboard Accessible**: Every interactive element is reachable via keyboard/switch control.
+- [ ] **Navigable**: Focus order is logical, and focus indicators are high-contrast (SC 2.4.11).
+- [ ] **Pointer Gestures**: Single-pointer alternatives exist for all dragging or multipoint gestures.
+- [ ] **Target Size**: Interactive elements are at least 24x24 CSS pixels (SC 2.5.8).
+
+### 3. Understandable (Information must be clear)
+
+- [ ] **Predictable**: Navigation and identification of elements are consistent across the app.
+- [ ] **Input Assistance**: Forms provide clear error identification and suggestions for fix.
+- [ ] **Redundant Entry**: Avoid asking for the same info twice in a single process (SC 3.3.7).
+
+### 4. Robust (Content must be compatible)
+
+- [ ] **Compatibility**: Maximize compatibility with assistive tech using valid Name, Role, and Value.
+- [ ] **Status Messages**: Screen readers are notified of dynamic changes via ARIA live regions.
+
+---
+
+## Anti-Patterns
+
+| Issue                      | Why it fails                                                                                       |
+| :------------------------- | :------------------------------------------------------------------------------------------------- |
+| **"Click Here" Links**     | Non-descriptive; screen reader users navigating by links won't know the destination.               |
+| **Fixed-Sized Containers** | Prevents content reflow and breaks the layout at higher zoom levels.                               |
+| **Keyboard Traps**         | Prevents users from navigating the rest of the page once they enter a component.                   |
+| **Auto-Playing Media**     | Distracting for users with cognitive disabilities; interferes with screen reader audio.            |
+| **Empty Buttons**          | Icon-only buttons without an `aria-label` or `accessibilityLabel` are invisible to screen readers. |
+
+## Accessibility Decision Record Template
+
+For major UI decisions, use this format:
+
+````markdown
+# ADR-ACC-[000]: [Title of the Accessibility Decision]
+
+## Status
+
+Proposed | **Accepted** | Deprecated | Superseded by [ADR-XXX]
+
+## Context
+
+_Describe the UI component or workflow being addressed._
+
+- **Platform**: [Web | iOS | Android | Cross-platform]
+- **WCAG 2.2 Success Criterion**: [e.g., 2.5.8 Target Size (Minimum)]
+- **Problem**: What is the current accessibility barrier? (e.g., "The 'Close' button in the modal is too small for users with motor impairments.")
+
+## Decision
+
+_Detail the specific implementation choice._
+"We will implement a touch target of at least 44x44 points for all mobile navigation elements and 24x24 CSS pixels for web, ensuring a minimum 4px spacing between adjacent targets."
+
+## Implementation Details
+
+### Code/Spec
+
+```[language]
+// Example: SwiftUI
+Button(action: close) {
+  Image(systemName: "xmark")
+    .frame(width: 44, height: 44) // Standardizing hit area
+}
+.accessibilityLabel("Close modal")
+```
+````
+
+## Reference
+
+- See skill `accessibility` to transform raw UI requirements into platform-specific accessible code (WAI-ARIA, SwiftUI, or Jetpack Compose) based on WCAG 2.2 criteria.