diff --git a/.ai-team/agents/fenster/history.md b/.ai-team/agents/fenster/history.md
index 617894422..40446580a 100644
--- a/.ai-team/agents/fenster/history.md
+++ b/.ai-team/agents/fenster/history.md
@@ -123,3 +123,9 @@ _Summarized from initial architecture review (2026-02-07). Full entries in `hist
 - **Docs template extraction — inline→external files.** Refactored `docs/build.js` to read HTML template, CSS, and JS from external files instead of generating them inline via `getCSS()`, `getJS()`, and `getTemplate()` string-building functions. Created `docs/assets/template.html` (HTML shell with `{{title}}`, `{{nav}}`, `{{content}}`, `{{searchIndex}}`, `{{basePath}}` placeholders), `docs/assets/style.css`, and `docs/assets/script.js`. Build reads template once at startup, does placeholder replacement per page. CSS/JS are linked externally (`<link>` / `<script src>`), search index remains inlined as page-specific `<script>` block. The existing `copyDir` of `docs/assets/` → `_site/assets/` handles deploying CSS/JS automatically. Key paths: `docs/assets/template.html`, `docs/assets/style.css`, `docs/assets/script.js`.
 
 - **Copilot CLI agent manifest YAML frontmatter validation (issue #59).** The `version` field in squad.agent.md's YAML frontmatter was not a supported property per the [GitHub Copilot CLI agent manifest specification](https://docs.github.com/en/copilot/reference/custom-agents-configuration). Supported properties are: `name`, `description`, `tools`, and `mcp-servers` (org/enterprise only). Unsupported properties like `version`, `model`, `argument-hint`, and `handoffs` cause the Copilot CLI parser to throw "error: too many arguments" because it interprets them as command-line arguments. Fixed by moving version tracking from YAML frontmatter to an HTML comment (`<!-- version: X.Y.Z -->`) immediately after the frontmatter closing `---`. Updated `stampVersion()` and `readInstalledVersion()` in index.js to work with the new HTML comment format (with backward compatibility fallback for upgrade scenarios). The agent name was also simplified from `Squad (v0.0.0-source)` to just `Squad` in the frontmatter. This pattern applies to all custom agent manifests — only use officially supported YAML properties to avoid parser errors.
+
+📌 Team update (2026-02-15): YAML frontmatter validation — unsupported properties removed from squad.agent.md, version moved to HTML comment. Sidebar logo sized to 40px. Docs build templates extracted to external files (template.html, style.css, script.js) for editor support — Fenster
+
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/hockney/history.md b/.ai-team/agents/hockney/history.md
index 416e2a430..071da6767 100644
--- a/.ai-team/agents/hockney/history.md
+++ b/.ai-team/agents/hockney/history.md
@@ -86,3 +86,6 @@ _Summarized from initial assessment (2026-02-07). Full entries in `history-archi
     - **FAIL: "ask_user referenced in Init Mode"** — The prompt never mentions `ask_user` or any explicit tool for getting confirmation. Without this, the LLM has no mechanism to yield control back to the user.
   - **Pattern: Prompt structure testing.** These are not runtime LLM behavior tests — they verify the text content of generated prompt files. The pattern is: run `node index.js` in a temp dir, read the generated `.github/agents/squad.agent.md`, extract sections by heading, assert on text patterns (regex + string search). This catches prompt regressions without needing an LLM in the loop.
   - **Key insight:** The current prompt relies on step numbering alone to create a pause point. Step 5 says "Ask: Look right?" and step 6 says "On confirmation, create..." — but without an explicit STOP instruction or ask_user reference, LLMs treat steps 4-6 as a single execution block. The fix needs both: (a) an explicit STOP/WAIT directive, and (b) an ask_user tool reference to force the LLM to yield.
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/keaton/history.md b/.ai-team/agents/keaton/history.md
index b59f9bb9e..a48529a83 100644
--- a/.ai-team/agents/keaton/history.md
+++ b/.ai-team/agents/keaton/history.md
@@ -293,4 +293,10 @@ _Summarized 2026-02-10+ learnings (full entries available in session logs):_
   - **Key prompt pattern: numbered lists cause LLMs to skip pauses.** When a pause/confirmation step appears mid-list, the model generates the question text but immediately proceeds to the next numbered step. The completion impulse is stronger than conversational turn-taking instinct. This is a general anti-pattern — any multi-step prompt that requires a mid-sequence pause must use structural breaks (section boundaries, separate headings) or tool-based gates (ask_user), not inline text instructions.
   - **Key prompt pattern: contradictory behavioral directives compound.** "What can I launch RIGHT NOW?" + "don't wait for user input" + "proceed immediately" in Team Mode sections bleed into Init Mode behavior. LLMs don't scope instructions to labeled modes — they absorb the full prompt as behavioral priors. Init Mode exceptions must be explicitly stated in the competing sections.
   - **Recommended fix: two-phase Init Mode split + Eager Execution exception.** Split Init Mode into Phase 1 (propose roster, end response) and Phase 2 (create files on user reply) with a section boundary between them. Add explicit Init Mode exception to Eager Execution Philosophy. Tighten implicit-yes clause to require "reply to step 5" not original message.
-  - **Key file paths:** .ai-team/decisions/inbox/keaton-init-confirmation-bug.md (full analysis)
\ No newline at end of file
+  - **Key file paths:** .ai-team/decisions/inbox/keaton-init-confirmation-bug.md (full analysis)
+
+📌 Team update (2026-02-15): Init Mode optimization and confirmation skip fixes consolidated — Keaton's compression work (2026-02-13) merged with detailed UX fix analysis (2026-02-15), including five root causes and four proposed fixes for confirmation skip issue.
+
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/kobayashi/history.md b/.ai-team/agents/kobayashi/history.md
index 8268afd35..2b0534006 100644
--- a/.ai-team/agents/kobayashi/history.md
+++ b/.ai-team/agents/kobayashi/history.md
@@ -70,3 +70,6 @@ _Summarized from sessions through 2026-02-09. Full entries in `history-archive.m
 
 📌 Team update (2026-02-12):Cross-client sub-agent API research complete — squad.agent.md uses task tool exclusively for CLI platform, VS Code uses runSubagent, no unification planned — research by Kujan
 📌 Team update (2026-02-13): go:/release: label automation shipped — Four-workflow system enforces label namespace integrity (go:* triage verdicts, release:* version targets). Workflows: squad-label-enforce.yml (mutual exclusivity), sync-squad-labels.yml (sync 8 static labels), squad-triage.yml (default go:needs-research), squad-heartbeat.yml (detect label gaps). Labels-as-state-machine is foundational to GitHub-native workflow. — decided by Fenster
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/kujan/history.md b/.ai-team/agents/kujan/history.md
index c83f3b2ee..c62c33720 100644
--- a/.ai-team/agents/kujan/history.md
+++ b/.ai-team/agents/kujan/history.md
@@ -119,3 +119,6 @@ _Summarized 2026-02-10 learnings (full entries in session logs and proposals):_
   - **Output:** `team-docs/proposals/034a-model-background-parity.md`, commented on Issue #34.
 📌 Team update (2026-02-14): VS Code Model & Background Parity — Phase 1 (v0.4.0): accept session model, use runSubagent. Phase 2 (v0.5.0): generate model-tier agent files. runSubagent lacks model param; use prompt-level detection in squad.agent.md. — decided by Kujan
 
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/mcmanus/history.md b/.ai-team/agents/mcmanus/history.md
index 2cc7b61ad..3f7907d25 100644
--- a/.ai-team/agents/mcmanus/history.md
+++ b/.ai-team/agents/mcmanus/history.md
@@ -203,3 +203,6 @@ _Summarized from initial assessment, messaging overhaul, demo script, and README
 
 - **CONTRIBUTING.md created (2026-02-13)** — Proper contributor's guide with complete branch model education. Structure: Getting Started (fork/clone/install/test) → Branch Model (three-tier diagram + naming convention) → What's Protected (unmissable section on `.ai-team/` and `team-docs/` blocks, guard workflow behavior) → PR Process (step-by-step from feature branch through guard checks with remediation) → File Matrix (quick reference table) → Guard Mechanism (how it works, transparent) → Running Tests → Commit Conventions (conventional commits) → Code Style (2-space, camelCase, minimal comments) → Labels (taxonomy brief) → FAQ (10 common questions) → Summary. Key strategy: make `.ai-team/` rule unmissable through repetition, visual emphasis (🚫 emoji, bold, multiple sections), and concrete examples. Guard workflow is explained as a helper not a blocker. Branch protection motivated by "keeps biting us" — human reason, not dogma. Updated `docs/community.md` "How to Contribute" section with prominent CONTRIBUTING.md link.
 
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/redfoot/history.md b/.ai-team/agents/redfoot/history.md
index 92f1b9be7..fa5885d70 100644
--- a/.ai-team/agents/redfoot/history.md
+++ b/.ai-team/agents/redfoot/history.md
@@ -76,3 +76,6 @@
 📌 Team update (2026-02-10): Proposal migration uses three-wave approach — active first, shipped second, superseded/deferred last. — decided by Keaton
 
 📌 Team update (2026-02-11): Per-agent model selection implemented with cost-first directive (optimize cost unless writing code) — decided by Brady and Verbal
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/scribe/history.md b/.ai-team/agents/scribe/history.md
index 8a8d3eff0..bcaaf286d 100644
--- a/.ai-team/agents/scribe/history.md
+++ b/.ai-team/agents/scribe/history.md
@@ -67,3 +67,6 @@
 
 📌 Team update (2026-02-13): CI/CD workflows and team branching infrastructure consolidated — Three workflows shipped (squad-ci.yml, squad-preview.yml, squad-release.yml), CI guard added (squad-main-guard.yml) to block .ai-team/** and internal team-docs/** from main/preview, release process documented comprehensively in docs/scenarios/release-process.md. CONTRIBUTING.md guide created for external contributors (branch model, protected files, guard explanation, PR process). All enforcements via GitHub Actions CI gates, not just .gitignore. — decided by Kobayashi and McManus
 
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/strausz/history.md b/.ai-team/agents/strausz/history.md
index 6a8e2c6e4..acf717357 100644
--- a/.ai-team/agents/strausz/history.md
+++ b/.ai-team/agents/strausz/history.md
@@ -42,3 +42,6 @@
 - Multi-root workspaces have known bugs with path resolution and `grep_search` (vscode#264837, vscode#293428). Single-root is the supported configuration
 - VS Code's silent success bug on `editFiles` (vscode#253561) mirrors Squad's P0 bug — keep Response Order workaround in spawn prompts
 - **Key architectural insight:** Squad's instruction-level abstraction (describing operations, not tool names) is the correct pattern. It naturally works across both CLI and VS Code because the agent maps operation descriptions to available tools
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/agents/verbal/history.md b/.ai-team/agents/verbal/history.md
index 582617abb..02ded2260 100644
--- a/.ai-team/agents/verbal/history.md
+++ b/.ai-team/agents/verbal/history.md
@@ -197,3 +197,6 @@ _Summarized from sessions through 2026-02-09. Full entries in `history-archive.m
 
 📌 Team update (2026-02-13): Client Compatibility section added to squad.agent.md with platform detection logic, VS Code spawn adaptations, and feature degradation table — decided by Verbal
 
+
+📌 Team update (2026-02-15): Directory structure rename planned — .ai-team/ → .squad/ starting v0.5.0 with backward-compatible migration; full removal in v1.0.0 — Brady
+
diff --git a/.ai-team/decisions.md b/.ai-team/decisions.md
index 120a00438..d5a6c17f3 100644
--- a/.ai-team/decisions.md
+++ b/.ai-team/decisions.md
@@ -1651,14 +1651,182 @@ Created `docs/scenarios/client-compatibility.md` as the single source of truth f
 **What:** Added MCP Integration section to squad.agent.md, MCP context block to spawn template, and `.copilot/mcp-config.json` sample generation to `squad init` and `squad upgrade`.
 **Why:** Issue #11 — enable Squad to use MCP services (Trello, Aspire, etc.). Squad doesn't own MCP server lifecycle; it teaches agents awareness and provides a sample config with the `EXAMPLE-` prefix pattern so users know where to configure. The upgrade migration ensures existing installs get the sample config.
 
-### 2026-02-13: Context window optimization — spawn template dedup and Init Mode compression
+### 2026-02-15: Init Mode — optimization and confirmation skip fixes (consolidated)
 
 **By:** Keaton
 
-**What:** Applied two surgical optimizations to squad.agent.md (Issue #37): (1) Removed two redundant spawn templates (Background and Sync), replaced with single generic template plus mode selection notes. Saved ~3,600 tokens. (2) Compressed Init Mode from 84 lines to ~48 lines by replacing file tree example with one-liner reference, condensing post-setup input sources to bulleted list, tightening casting state init. Saved ~670 tokens. Total savings: ~4,270 tokens per coordinator message.
+*Note: This decision consolidates two related Init Mode improvements from 2026-02-13 (compression) and 2026-02-15 (confirmation UX fix). The 2026-02-13 decision on context window optimization is superseded by this consolidated entry.*
 
-**Why:** squad.agent.md is loaded on every coordinator spawn (every user message). Init Mode occupies context space on all messages but is only used once per repo lifetime (when .ai-team/team.md doesn't exist). The three spawn templates were 95% identical — same sections (charter, history, decisions, OUTPUT HYGIENE, RESPONSE ORDER, skill extraction), differing only in mode parameter and example agent names (Ripley, Dallas, {Name}). This redundancy consumed context window space without adding value — developers only need one reference template with mode selection guidance, not three full examples. Init Mode's file tree example (lines 55-75) duplicated .ai-team-templates/ content. Post-setup input sources (lines 97-111) repeated the same "If yes, follow..." pattern 4 times. Both optimizations preserve all behavior and all required sections while eliminating prose redundancy.
+**Why:** Issue #66 — this is a recurring UX problem that undermines user control during team setup
 
+---
+
+## Root Cause Analysis
+
+The Init Mode confirmation skip is a **prompt design problem**, not a logic error. The coordinator prompt has all the right steps in the right order — but the surrounding prompt context creates overwhelming pressure for the LLM to execute the full sequence in a single turn. There are **five reinforcing causes**.
+
+#### Cause 1: Numbered List Completion Impulse
+
+Init Mode steps 1–8 are a single numbered list. LLMs are trained to complete sequences. When the model reaches step 5 ("Ask: Look right?"), it generates the question text — but the next token prediction sees step 6 right there in context. The model treats the numbered list as a **procedure to execute**, not a **conversation to have**. It "asks" the question as output text, then immediately proceeds to step 6 because that's what comes next in the sequence.
+
+This is the **primary driver**. The model doesn't distinguish between "emit this question and stop" vs "emit this question as part of completing the list."
+
+#### Cause 2: Step 6 Phrasing — "On confirmation" is Ambiguous
+
+> `6. On confirmation (or if the user provides a task instead, treat that as implicit "yes"), create the .ai-team/ directory structure`
+
+"On confirmation" reads as a **conditional within the same execution frame**, not as a "wait for the next user message." The parenthetical "(or if the user provides a task instead, treat that as implicit 'yes')" further weakens the gate — the model can rationalize that the user's *original message* (e.g., "I'm building a Node.js API") constitutes a task, triggering the implicit-yes bypass.
+
+There is no explicit instruction to **stop generating**, **end the turn**, or **wait for user input**. The word "confirmation" is doing all the gate-keeping work, and it's not enough.
+
+#### Cause 3: Eager Execution Philosophy Creates Contradictory Pressure
+
+Line 16:
+> **Mindset:** **"What can I launch RIGHT NOW?"** — always maximize parallel work
+
+Line 480-486 (Eager Execution Philosophy):
+> The Coordinator's default mindset is **launch aggressively, collect results later.**
+> ...launch follow-up agents without waiting for the user to ask.
+
+Line 848:
+> DO NOT stop. Do NOT wait for user input.
+
+These are Team Mode instructions, but they're in the **same prompt context** during Init Mode. The model doesn't scope instructions to modes — it absorbs the entire prompt as its behavioral baseline. The repeated "don't wait," "launch immediately," "don't stop" instructions create a strong prior against pausing for any reason.
+
+#### Cause 4: The Parenthetical Escape Hatch
+
+Step 5:
+> *"(Or just give me a task to start!)"*
+
+Step 6:
+> *(or if the user provides a task instead, treat that as implicit "yes")*
+
+Step 8 (post-setup):
+> *These are additive. Don't block — if the user skips or gives a task instead, proceed immediately.*
+
+These three parentheticals collectively communicate: "confirmation is optional, proceeding is fine." The model reads "Or just give me a task" as license to treat the user's initial project description as that task. Combined with step 6's implicit-yes clause, the model has a clean logical path from "user said what they're building" → "that's a task" → "implicit yes" → "create everything."
+
+#### Cause 5: No Structural Turn Boundary
+
+The prompt has no mechanism that **forces** a turn boundary between step 5 and step 6. In a multi-turn conversation, the only thing that creates a real pause is:
+1. The model choosing to stop generating (weak — easily overridden by completion impulse)
+2. A tool call like `ask_user` that structurally requires user input before continuing
+3. An explicit "END YOUR RESPONSE HERE" instruction
+
+Init Mode relies on option 1 alone. Given causes 1-4, option 1 consistently fails.
+
+---
+
+## Proposed Fixes
+
+#### Fix A: Explicit STOP Gate (Minimum viable fix)
+
+Replace the current step 5-6 boundary with a hard stop instruction:
+
+```markdown
+5. Propose the team roster (step 4 above), then ask:
+   *"Look right? Say **yes**, **add someone**, or **change a role**."*
+
+   **⚠️ STOP HERE. End your response. Do NOT proceed to step 6.**
+   Wait for the user's reply before creating any files.
+
+6. **[ONLY after the user replies]** On confirmation (explicit "yes", "looks good",
+   or similar affirmative — OR if the user provides a task instead of confirming),
+   create the `.ai-team/` directory structure.
+```
+
+**Pros:** Minimal change, preserves existing flow.
+**Cons:** Still relies on the model obeying a text instruction. LLMs can and do ignore "STOP" instructions, especially with competing pressure from the Eager Execution sections.
+
+#### Fix B: Structural Turn Break via Two-Phase Init (Recommended)
+
+Split Init Mode into two clearly separated phases with an explicit turn boundary:
+
+```markdown
+## Init Mode — Phase 1: Cast the Team
+
+No team exists yet. Propose one.
+
+1. **Identify the user.** Run `git config user.name` and `git config user.email`.
+2. Ask: *"What are you building? (language, stack, what it does)"*
+3. **Cast the team** (see Casting & Persistent Naming algorithm).
+4. Propose the team roster.
+5. Ask: *"Look right? Say **yes**, **add someone**, or **change a role**."*
+
+**Your response for Phase 1 ENDS here. Do not create any files or directories.**
+
+---
+
+## Init Mode — Phase 2: Create the Team
+
+**Trigger:** User replied to the Phase 1 roster with confirmation or a task.
+
+6. Create the `.ai-team/` directory structure...
+7. Say: *"✅ Team hired..."*
+8. Post-setup input sources...
+```
+
+**Pros:** The section boundary (horizontal rule + new heading) creates a structural signal that these are separate response turns. The model is much less likely to "complete" across section breaks than within a numbered list.
+**Cons:** Slightly more verbose prompt. Requires the model to re-enter Init Mode Phase 2 on the next turn (but `team.md` doesn't exist yet, so the Init Mode check still triggers).
+
+#### Fix C: `ask_user` Tool Instruction (Strongest guarantee)
+
+If the platform supports an `ask_user` tool that forces a turn boundary:
+
+```markdown
+5. Propose the team roster, then call the `ask_user` tool with:
+   *"Look right? Say **yes**, **add someone**, or **change a role**."*
+   The `ask_user` tool will pause execution until the user responds.
+   Do NOT proceed to step 6 until `ask_user` returns.
+```
+
+**Pros:** Structural guarantee — the tool call mechanism forces a real pause. The model cannot "complete past" a tool call the way it can ignore text instructions.
+**Cons:** Depends on `ask_user` being available on all platforms (CLI, VS Code, etc.). May not exist in all Copilot client contexts. Needs a fallback for platforms without `ask_user`.
+
+#### Fix D: Remove Competing Signals (Complementary — do with A, B, or C)
+
+Add an Init Mode exception to the Eager Execution section:
+
+```markdown
+#### Eager Execution Philosophy
+
+> **Exception:** Eager Execution does NOT apply during Init Mode.
+> Init Mode requires explicit user confirmation before creating the team.
+> See Init Mode step 5 for the required pause.
+
+The Coordinator's default mindset is **launch aggressively, collect results later.**
+```
+
+Also tighten the step 6 implicit-yes clause to prevent the original message from qualifying:
+
+```markdown
+6. On confirmation (explicit "yes"/"looks good"/affirmative in response to step 5's question,
+   OR if the user's **reply to step 5** is a task instead of confirming), create...
+```
+
+The key change: "reply to step 5" — not the original message.
+
+---
+
+## Recommendation
+
+**Implement Fix B (two-phase split) + Fix D (remove competing signals).**
+
+Fix B is the most robust text-only solution because it uses structural formatting (section breaks, separate headings) to create a turn boundary, rather than relying on the model obeying an instruction it has competing reasons to ignore. Fix D removes the contradictory pressure that causes the model to rationalize skipping the pause.
+
+Fix C (`ask_user`) is the strongest technical guarantee but has platform portability concerns. Add it as an enhancement once client parity (Issue #10) is resolved — at that point, we'll know which clients support `ask_user`.
+
+Fix A alone is insufficient. The model already has an instruction to ask and wait (step 5). Adding more emphasis to the same instruction pattern is unlikely to change behavior when the root causes (completion impulse, eager execution pressure, implicit-yes escape hatch) remain.
+
+---
+
+## Validation Approach
+
+After implementing the fix:
+1. Test with 5+ fresh repos (no `.ai-team/` directory) across CLI and VS Code
+2. Verify the coordinator stops after proposing the roster and does NOT create files
+3. Test the implicit-yes path: respond to the roster with a task instead of "yes" — files should be created
+4. Test modification: respond with "add a designer" — coordinator should re-propose, not create
 ### 2026-02-15: Plugin Marketplace Integration
 
 **Date:** 2026-02-15
@@ -1866,3 +2034,51 @@ Created `CONTRIBUTING.md` at repo root with:
 - If guard violations continue, this guide can be extended with real scenario walkthroughs ("You committed team-docs/sprint-plan.md, here's how to remove it")
 - Could link to GitHub's guide on branch protection best practices as reference material
 
+
+### 2026-02-14: Copilot CLI agent manifest YAML frontmatter must use only supported properties
+
+**By:** Fenster
+
+**What:** The `version` field was removed from squad.agent.md's YAML frontmatter because it is not a supported property per the GitHub Copilot CLI agent manifest specification. Version tracking was moved to an HTML comment format.
+
+**Why:** Unsupported YAML frontmatter properties (like `version`, `model`, `argument-hint`, `handoffs`) cause the Copilot CLI parser to display "error: too many arguments" above the textbox in the CLI. The parser interprets unsupported properties as command-line arguments, resulting in a persistent error message that degrades UX. The only supported properties for GitHub Copilot CLI agents are: `name`, `description`, `tools`, and `mcp-servers` (org/enterprise level only). Moving version to an HTML comment preserves version tracking without conflicting with the parser.
+
+**Reference:** https://docs.github.com/en/copilot/reference/custom-agents-configuration
+
+**Impact:** All custom agent manifests should validate their YAML frontmatter against the official specification. Version or other metadata that isn't supported should be tracked in HTML comments or the Markdown body, not in YAML.
+
+### 2026-02-15: Sidebar Logo Sizing
+
+**By:** Fenster
+
+## Context
+
+The 500×500px `squad-logo.png` was rendering at ~248px tall in the sidebar header because `.sidebar-logo-img` used `max-width:100%; height:auto` — it filled the full sidebar width minus padding.
+
+## Decision
+
+Changed `.sidebar-logo-img` from `max-width:100%; height:auto` to `height:40px; width:auto`.
+
+- **40px height** sits well within the sidebar-header's vertical space (padding: 20px top + 12px bottom) and matches typical docs site header logos (36–48px range).
+- **width:auto** preserves the logo's aspect ratio — the 500×500 square image will render at 40×40px.
+- No markup changes were needed; the flex layout in `.sidebar-header` already handles alignment.
+
+## Alternatives Considered
+
+- `max-width:48px` — would also work but constraining height is more conventional for header logos since vertical space is the scarce dimension.
+- Adding a `width` + `height` attribute on the `<img>` tag — avoided to keep sizing in CSS where it belongs.
+
+
+### 2026-02-15: Docs build template extraction — inline to external files
+
+**By:** Fenster
+**What:** Extracted inline HTML template, CSS, and JS from `docs/build.js` into separate files at `docs/assets/template.html`, `docs/assets/style.css`, and `docs/assets/script.js`. Build reads these at startup and does placeholder replacement. CSS and JS are now linked externally in the HTML output.
+**Why:** Inline string-building made the build script ~310 lines with CSS/JS/HTML interleaved. Extracting to real files means: (1) editors provide syntax highlighting and linting for CSS/JS/HTML, (2) designers can edit styling without touching Node.js, (3) images and other static assets can be added to `docs/assets/` naturally, (4) the template is visible and diffable as a standalone HTML file. The `docs/assets/` → `_site/assets/` copy was already in place, so CSS/JS deploy with zero extra logic.
+
+### 2026-02-15: Rename .ai-team/ to .squad/
+**By:** Brady (via Copilot)
+**What:** The team state directory will be renamed from `.ai-team/` to `.squad/` starting in v0.5.0, with a backward-compatible migration path. Full legacy removal in v1.0.0.
+**Why:** `.squad/` is branded, shorter, follows conventions like `.github/` and `.vscode/`, and eliminates ambiguity about which tool owns the directory.
+
+
+
diff --git a/.ai-team/decisions/inbox/copilot-directive-rename-to-squad.md b/.ai-team/decisions/inbox/copilot-directive-rename-to-squad.md
deleted file mode 100644
index a4d7bd682..000000000
--- a/.ai-team/decisions/inbox/copilot-directive-rename-to-squad.md
+++ /dev/null
@@ -1,4 +0,0 @@
-### 2026-02-15: Rename .ai-team/ to .squad/
-**By:** Brady (via Copilot)
-**What:** The team state directory will be renamed from `.ai-team/` to `.squad/` starting in v0.5.0, with a backward-compatible migration path. Full legacy removal in v1.0.0.
-**Why:** `.squad/` is branded, shorter, follows conventions like `.github/` and `.vscode/`, and eliminates ambiguity about which tool owns the directory.
diff --git a/.ai-team/decisions/inbox/fenster-docs-template-extraction.md b/.ai-team/decisions/inbox/fenster-docs-template-extraction.md
deleted file mode 100644
index 83d5bfae6..000000000
--- a/.ai-team/decisions/inbox/fenster-docs-template-extraction.md
+++ /dev/null
@@ -1,5 +0,0 @@
-### 2026-02-15: Docs build template extraction — inline to external files
-
-**By:** Fenster
-**What:** Extracted inline HTML template, CSS, and JS from `docs/build.js` into separate files at `docs/assets/template.html`, `docs/assets/style.css`, and `docs/assets/script.js`. Build reads these at startup and does placeholder replacement. CSS and JS are now linked externally in the HTML output.
-**Why:** Inline string-building made the build script ~310 lines with CSS/JS/HTML interleaved. Extracting to real files means: (1) editors provide syntax highlighting and linting for CSS/JS/HTML, (2) designers can edit styling without touching Node.js, (3) images and other static assets can be added to `docs/assets/` naturally, (4) the template is visible and diffable as a standalone HTML file. The `docs/assets/` → `_site/assets/` copy was already in place, so CSS/JS deploy with zero extra logic.
diff --git a/.ai-team/decisions/inbox/fenster-logo-sizing.md b/.ai-team/decisions/inbox/fenster-logo-sizing.md
deleted file mode 100644
index 00dbed70c..000000000
--- a/.ai-team/decisions/inbox/fenster-logo-sizing.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# Decision: Sidebar Logo Sizing
-
-**Author:** Fenster (Core Dev)  
-**Date:** 2025-01-27  
-**Status:** Implemented
-
-## Context
-
-The 500×500px `squad-logo.png` was rendering at ~248px tall in the sidebar header because `.sidebar-logo-img` used `max-width:100%; height:auto` — it filled the full sidebar width minus padding.
-
-## Decision
-
-Changed `.sidebar-logo-img` from `max-width:100%; height:auto` to `height:40px; width:auto`.
-
-- **40px height** sits well within the sidebar-header's vertical space (padding: 20px top + 12px bottom) and matches typical docs site header logos (36–48px range).
-- **width:auto** preserves the logo's aspect ratio — the 500×500 square image will render at 40×40px.
-- No markup changes were needed; the flex layout in `.sidebar-header` already handles alignment.
-
-## Alternatives Considered
-
-- `max-width:48px` — would also work but constraining height is more conventional for header logos since vertical space is the scarce dimension.
-- Adding a `width` + `height` attribute on the `<img>` tag — avoided to keep sizing in CSS where it belongs.
diff --git a/.ai-team/decisions/inbox/fenster-yaml-frontmatter-validation.md b/.ai-team/decisions/inbox/fenster-yaml-frontmatter-validation.md
deleted file mode 100644
index 8ff45a3d3..000000000
--- a/.ai-team/decisions/inbox/fenster-yaml-frontmatter-validation.md
+++ /dev/null
@@ -1,11 +0,0 @@
-### 2026-02-14: Copilot CLI agent manifest YAML frontmatter must use only supported properties
-
-**By:** Fenster
-
-**What:** The `version` field was removed from squad.agent.md's YAML frontmatter because it is not a supported property per the GitHub Copilot CLI agent manifest specification. Version tracking was moved to an HTML comment format.
-
-**Why:** Unsupported YAML frontmatter properties (like `version`, `model`, `argument-hint`, `handoffs`) cause the Copilot CLI parser to display "error: too many arguments" above the textbox in the CLI. The parser interprets unsupported properties as command-line arguments, resulting in a persistent error message that degrades UX. The only supported properties for GitHub Copilot CLI agents are: `name`, `description`, `tools`, and `mcp-servers` (org/enterprise level only). Moving version to an HTML comment preserves version tracking without conflicting with the parser.
-
-**Reference:** https://docs.github.com/en/copilot/reference/custom-agents-configuration
-
-**Impact:** All custom agent manifests should validate their YAML frontmatter against the official specification. Version or other metadata that isn't supported should be tracked in HTML comments or the Markdown body, not in YAML.
diff --git a/.ai-team/decisions/inbox/keaton-init-confirmation-bug.md b/.ai-team/decisions/inbox/keaton-init-confirmation-bug.md
deleted file mode 100644
index eba3a5765..000000000
--- a/.ai-team/decisions/inbox/keaton-init-confirmation-bug.md
+++ /dev/null
@@ -1,173 +0,0 @@
-### 2026-02-15: Init Mode confirmation skip — root cause analysis
-**By:** Keaton
-**What:** Analysis of why Init Mode skips user confirmation, with proposed fixes
-**Why:** Issue #66 — this is a recurring UX problem that undermines user control during team setup
-
----
-
-## Root Cause Analysis
-
-The Init Mode confirmation skip is a **prompt design problem**, not a logic error. The coordinator prompt has all the right steps in the right order — but the surrounding prompt context creates overwhelming pressure for the LLM to execute the full sequence in a single turn. There are **five reinforcing causes**.
-
-### Cause 1: Numbered List Completion Impulse
-
-Init Mode steps 1–8 are a single numbered list. LLMs are trained to complete sequences. When the model reaches step 5 ("Ask: Look right?"), it generates the question text — but the next token prediction sees step 6 right there in context. The model treats the numbered list as a **procedure to execute**, not a **conversation to have**. It "asks" the question as output text, then immediately proceeds to step 6 because that's what comes next in the sequence.
-
-This is the **primary driver**. The model doesn't distinguish between "emit this question and stop" vs "emit this question as part of completing the list."
-
-### Cause 2: Step 6 Phrasing — "On confirmation" is Ambiguous
-
-> `6. On confirmation (or if the user provides a task instead, treat that as implicit "yes"), create the .ai-team/ directory structure`
-
-"On confirmation" reads as a **conditional within the same execution frame**, not as a "wait for the next user message." The parenthetical "(or if the user provides a task instead, treat that as implicit 'yes')" further weakens the gate — the model can rationalize that the user's *original message* (e.g., "I'm building a Node.js API") constitutes a task, triggering the implicit-yes bypass.
-
-There is no explicit instruction to **stop generating**, **end the turn**, or **wait for user input**. The word "confirmation" is doing all the gate-keeping work, and it's not enough.
-
-### Cause 3: Eager Execution Philosophy Creates Contradictory Pressure
-
-Line 16:
-> **Mindset:** **"What can I launch RIGHT NOW?"** — always maximize parallel work
-
-Line 480-486 (Eager Execution Philosophy):
-> The Coordinator's default mindset is **launch aggressively, collect results later.**
-> ...launch follow-up agents without waiting for the user to ask.
-
-Line 848:
-> DO NOT stop. Do NOT wait for user input.
-
-These are Team Mode instructions, but they're in the **same prompt context** during Init Mode. The model doesn't scope instructions to modes — it absorbs the entire prompt as its behavioral baseline. The repeated "don't wait," "launch immediately," "don't stop" instructions create a strong prior against pausing for any reason.
-
-### Cause 4: The Parenthetical Escape Hatch
-
-Step 5:
-> *"(Or just give me a task to start!)"*
-
-Step 6:
-> *(or if the user provides a task instead, treat that as implicit "yes")*
-
-Step 8 (post-setup):
-> *These are additive. Don't block — if the user skips or gives a task instead, proceed immediately.*
-
-These three parentheticals collectively communicate: "confirmation is optional, proceeding is fine." The model reads "Or just give me a task" as license to treat the user's initial project description as that task. Combined with step 6's implicit-yes clause, the model has a clean logical path from "user said what they're building" → "that's a task" → "implicit yes" → "create everything."
-
-### Cause 5: No Structural Turn Boundary
-
-The prompt has no mechanism that **forces** a turn boundary between step 5 and step 6. In a multi-turn conversation, the only thing that creates a real pause is:
-1. The model choosing to stop generating (weak — easily overridden by completion impulse)
-2. A tool call like `ask_user` that structurally requires user input before continuing
-3. An explicit "END YOUR RESPONSE HERE" instruction
-
-Init Mode relies on option 1 alone. Given causes 1-4, option 1 consistently fails.
-
----
-
-## Proposed Fixes
-
-### Fix A: Explicit STOP Gate (Minimum viable fix)
-
-Replace the current step 5-6 boundary with a hard stop instruction:
-
-```markdown
-5. Propose the team roster (step 4 above), then ask:
-   *"Look right? Say **yes**, **add someone**, or **change a role**."*
-
-   **⚠️ STOP HERE. End your response. Do NOT proceed to step 6.**
-   Wait for the user's reply before creating any files.
-
-6. **[ONLY after the user replies]** On confirmation (explicit "yes", "looks good",
-   or similar affirmative — OR if the user provides a task instead of confirming),
-   create the `.ai-team/` directory structure.
-```
-
-**Pros:** Minimal change, preserves existing flow.
-**Cons:** Still relies on the model obeying a text instruction. LLMs can and do ignore "STOP" instructions, especially with competing pressure from the Eager Execution sections.
-
-### Fix B: Structural Turn Break via Two-Phase Init (Recommended)
-
-Split Init Mode into two clearly separated phases with an explicit turn boundary:
-
-```markdown
-## Init Mode — Phase 1: Cast the Team
-
-No team exists yet. Propose one.
-
-1. **Identify the user.** Run `git config user.name` and `git config user.email`.
-2. Ask: *"What are you building? (language, stack, what it does)"*
-3. **Cast the team** (see Casting & Persistent Naming algorithm).
-4. Propose the team roster.
-5. Ask: *"Look right? Say **yes**, **add someone**, or **change a role**."*
-
-**Your response for Phase 1 ENDS here. Do not create any files or directories.**
-
----
-
-## Init Mode — Phase 2: Create the Team
-
-**Trigger:** User replied to the Phase 1 roster with confirmation or a task.
-
-6. Create the `.ai-team/` directory structure...
-7. Say: *"✅ Team hired..."*
-8. Post-setup input sources...
-```
-
-**Pros:** The section boundary (horizontal rule + new heading) creates a structural signal that these are separate response turns. The model is much less likely to "complete" across section breaks than within a numbered list.
-**Cons:** Slightly more verbose prompt. Requires the model to re-enter Init Mode Phase 2 on the next turn (but `team.md` doesn't exist yet, so the Init Mode check still triggers).
-
-### Fix C: `ask_user` Tool Instruction (Strongest guarantee)
-
-If the platform supports an `ask_user` tool that forces a turn boundary:
-
-```markdown
-5. Propose the team roster, then call the `ask_user` tool with:
-   *"Look right? Say **yes**, **add someone**, or **change a role**."*
-   The `ask_user` tool will pause execution until the user responds.
-   Do NOT proceed to step 6 until `ask_user` returns.
-```
-
-**Pros:** Structural guarantee — the tool call mechanism forces a real pause. The model cannot "complete past" a tool call the way it can ignore text instructions.
-**Cons:** Depends on `ask_user` being available on all platforms (CLI, VS Code, etc.). May not exist in all Copilot client contexts. Needs a fallback for platforms without `ask_user`.
-
-### Fix D: Remove Competing Signals (Complementary — do with A, B, or C)
-
-Add an Init Mode exception to the Eager Execution section:
-
-```markdown
-### Eager Execution Philosophy
-
-> **Exception:** Eager Execution does NOT apply during Init Mode.
-> Init Mode requires explicit user confirmation before creating the team.
-> See Init Mode step 5 for the required pause.
-
-The Coordinator's default mindset is **launch aggressively, collect results later.**
-```
-
-Also tighten the step 6 implicit-yes clause to prevent the original message from qualifying:
-
-```markdown
-6. On confirmation (explicit "yes"/"looks good"/affirmative in response to step 5's question,
-   OR if the user's **reply to step 5** is a task instead of confirming), create...
-```
-
-The key change: "reply to step 5" — not the original message.
-
----
-
-## Recommendation
-
-**Implement Fix B (two-phase split) + Fix D (remove competing signals).**
-
-Fix B is the most robust text-only solution because it uses structural formatting (section breaks, separate headings) to create a turn boundary, rather than relying on the model obeying an instruction it has competing reasons to ignore. Fix D removes the contradictory pressure that causes the model to rationalize skipping the pause.
-
-Fix C (`ask_user`) is the strongest technical guarantee but has platform portability concerns. Add it as an enhancement once client parity (Issue #10) is resolved — at that point, we'll know which clients support `ask_user`.
-
-Fix A alone is insufficient. The model already has an instruction to ask and wait (step 5). Adding more emphasis to the same instruction pattern is unlikely to change behavior when the root causes (completion impulse, eager execution pressure, implicit-yes escape hatch) remain.
-
----
-
-## Validation Approach
-
-After implementing the fix:
-1. Test with 5+ fresh repos (no `.ai-team/` directory) across CLI and VS Code
-2. Verify the coordinator stops after proposing the roster and does NOT create files
-3. Test the implicit-yes path: respond to the roster with a task instead of "yes" — files should be created
-4. Test modification: respond with "add a designer" — coordinator should re-propose, not create
diff --git a/.ai-team/log/2026-02-15-catch-up.md b/.ai-team/log/2026-02-15-catch-up.md
new file mode 100644
index 000000000..fc7ae3dd4
--- /dev/null
+++ b/.ai-team/log/2026-02-15-catch-up.md
@@ -0,0 +1,19 @@
+# Session: 2026-02-15 Catch-Up
+
+**Requested by:** Brady (bradygaster)  
+**Session resumed after OOM crash**
+
+## Context
+
+Coordinator provided catch-up summary on session restoration:
+- v0.4.0 sprint complete
+- 14 open issues identified
+- 5 inbox decision files pending merge
+
+## Work Completed
+
+- Merged 5 decision inbox files into decisions.md
+- Deduplicaated exact entries
+- Consolidated overlapping decisions
+- Propagated updates to affected agent histories
+- Committed all .ai-team/ changes
diff --git a/.github/agents/squad.agent.md b/.github/agents/squad.agent.md
index 2c133f812..d52cea4df 100644
--- a/.github/agents/squad.agent.md
+++ b/.github/agents/squad.agent.md
@@ -254,17 +254,10 @@ After routing determines WHO handles work, select the response MODE based on tas
 agent_type: "general-purpose"
 model: "{resolved_model}"
 mode: "background"
-description: "{Name}: {brief task summary}"
+description: "{emoji} {Name}: {brief task summary}"
 prompt: |
   You are {Name}, the {Role} on this project.
 
-  TEAM ROOT: {team_root}
-
-  **Requested by:** {current user name}
-
-  TASK: {specific task description}
-  TARGET FILE(S): {exact file path(s)}
-
   Do the work. Keep it focused — this is a small scoped task.
 
   If you made a meaningful decision, write it to:
@@ -288,7 +281,7 @@ For read-only queries in Lightweight mode, use the explore agent for speed:
 ```
 agent_type: "explore"
 model: "{resolved_model}"
-description: "{Name}: {brief query}"
+description: "{emoji} {Name}: {brief query}"
 prompt: |
   You are {Name}, the {Role}. Answer this question about the codebase:
   {question}
@@ -359,7 +352,7 @@ Pass the resolved model as the `model` parameter on every `task` tool call:
 agent_type: "general-purpose"
 model: "{resolved_model}"
 mode: "background"
-description: "{Name}: {brief task summary}"
+description: "{emoji} {Name}: {brief task summary}"
 prompt: |
   ...
 ```
@@ -382,6 +375,25 @@ When spawning, include the model in your acknowledgment:
 
 Include tier annotation only when the model was bumped or a specialist was chosen. Default-tier spawns just show the model name.
 
+**`{emoji}` resolution for `description` field:** Use the same role-based emoji in the `description` parameter of the `task` tool. Resolve `{emoji}` from the agent's role:
+
+| Role | Emoji |
+|------|-------|
+| Lead / Architect | 🏗️ |
+| Frontend Dev | ⚛️ |
+| Backend Dev / Core Dev | 🔧 |
+| Tester / QA | 🧪 |
+| Prompt Engineer | ⚡ |
+| DevRel / Writer | 📝 |
+| Copilot SDK Expert | 🔍 |
+| Git & Release Engineer | 🚀 |
+| Designer / Visual | 🎨 |
+| VS Code Extension Expert | 💻 |
+| Scribe | 📋 |
+| Ralph | 🔄 |
+
+If a role isn't listed, use the closest match or a generic 🔹.
+
 **Valid models (current platform catalog):**
 
 Premium: `claude-opus-4.6`, `claude-opus-4.6-fast`, `claude-opus-4.5`
@@ -626,7 +638,7 @@ Each entry records: agent routed, why chosen, mode (background/sync), files auth
 
 - **`agent_type`**: `"general-purpose"` (always — this gives agents full tool access)
 - **`mode`**: `"background"` (default) or omit for sync — see Mode Selection table above
-- **`description`**: `"{Name}: {brief task summary}"` (e.g., `"Ripley: Design REST API endpoints"`, `"Dallas: Build login form"`) — this is what appears in the UI, so it MUST carry the agent's name and what they're doing
+- **`description`**: `"{emoji} {Name}: {brief task summary}"` (e.g., `"🔧 Ripley: Design REST API endpoints"`, `"⚛️ Dallas: Build login form"`) — this is what appears in the UI, so it MUST carry the agent's emoji + name and what they're doing. Use the same role-based emoji shown in the launch table acknowledgment.
 - **`prompt`**: The full agent prompt (see below)
 
 **⚡ Inline the charter.** Before spawning, read the agent's `charter.md` (resolve from team root: `{team_root}/.ai-team/agents/{name}/charter.md`) and paste its contents directly into the spawn prompt. This eliminates a tool call from the agent's critical path. The agent still reads its own `history.md` and `decisions.md`.
@@ -643,7 +655,7 @@ Each entry records: agent routed, why chosen, mode (background/sync), files auth
 agent_type: "general-purpose"
 model: "{resolved_model}"
 mode: "background"
-description: "{Name}: {brief task summary}"
+description: "{emoji} {Name}: {brief task summary}"
 prompt: |
   You are {Name}, the {Role} on this project.
   
@@ -723,7 +735,7 @@ prompt: |
 1. **Never role-play an agent inline.** If you write "As {AgentName}, I think..." without calling the `task` tool, that is NOT the agent. That is you (the Coordinator) pretending.
 2. **Never simulate agent output.** Don't generate what you think an agent would say. Call the `task` tool and let the real agent respond.
 3. **Never skip the `task` tool for tasks that need agent expertise.** Direct Mode (status checks, factual questions from context) and Lightweight Mode (small scoped edits) are the legitimate exceptions — see Response Mode Selection. If a task requires domain judgment, it needs a real agent spawn.
-4. **Never use a generic `description`.** The `description` parameter MUST include the agent's name. `"General purpose task"` is wrong. `"Dallas: Fix button alignment"` is right.
+4. **Never use a generic `description`.** The `description` parameter MUST include the agent's emoji and name. `"General purpose task"` is wrong. `"⚛️ Dallas: Fix button alignment"` is right.
 5. **Never serialize agents because of shared memory files.** The drop-box pattern exists to eliminate file conflicts. If two agents both have decisions to record, they both write to their own inbox files — no conflict.
 
 ### After Agent Work
@@ -775,7 +787,7 @@ After each batch of agent work:
 agent_type: "general-purpose"
 model: "claude-haiku-4.5"
 mode: "background"
-description: "Scribe: Log session & merge decisions"
+description: "📋 Scribe: Log session & merge decisions"
 prompt: |
   You are the Scribe. Read .ai-team/agents/scribe/charter.md.
   
@@ -914,7 +926,7 @@ Ceremonies are structured team meetings where agents align before or after work.
 ```
 agent_type: "general-purpose"
 model: "{resolved_model}"
-description: "{Facilitator}: {ceremony name} — {task summary}"
+description: "{emoji} {Facilitator}: {ceremony name} — {task summary}"
 prompt: |
   You are {Facilitator}, the {Role} on this project.
 
@@ -1632,7 +1644,7 @@ Squad can ingest a Product Requirements Document (PRD) and use it as the source
 ```
 agent_type: "general-purpose"
 model: "{resolved_model}"
-description: "{Lead}: Decompose PRD into work items"
+description: "{emoji} {Lead}: Decompose PRD into work items"
 prompt: |
   You are {Lead}, the Lead on this project.