fix(tests): resolve 16 pre-existing test failures

.squad/agents/fenster/history.md

@@ -1,3 +1,4 @@
+📌 Team update (2026-03-05T22:46:00Z): Azure Function samples require \main\ field and build step — decided by Fenster
 # Project Context
 
 - **Owner:** Brady
@@ -695,6 +696,8 @@ px tsx), it logs a test-mode warning but still validates config — useful for d
 - For TypeScript Azure Functions: always add a `build` step (`tsc`) and ensure `main` points to `dist/` output (e.g., `"main": "dist/functions/squad-prompt.js"`). The `start` script should chain build + func start: `npm run build && func start`.
 - A `prestart:func` npm script ensures `func start` always gets fresh compiled JS, preventing stale-build confusion.
 
+📌 Team update (2026-03-06): Fixed Azure Function sample — added missing `main` field to package.json, updated `start` script to build-then-run, added build documentation to README. Root cause was runtime couldn't discover function registration without `main` pointing to compiled output. — decided by Fenster
+
 📌 Team update (2026-03-06): Fixed Azure Function sample — added missing `main` field to package.json, updated `start` script to build-then-run, added build documentation to README. Root cause was runtime couldn't discover function registration without `main` pointing to compiled output. — decided by Fenster
 
 ## Issue #228 — Squad Guard vs Scribe Runtime State

.squad/decisions.md

@@ -2854,26 +2854,37 @@ This sample reinforces core Squad decisions:
 This sample is intentional: I'm designing it to compound future work. Once we have Azure Functions working, Lambda, GCP Cloud Functions, Vercel, and other serverless patterns become copy-paste variations. One good example beats a dozen half-baked ones.
 
 
-# Decision: Azure Function Squad Sample Pattern
 
-**Author:** Fenster  
-**Date:** 2026-03-06  
-**Status:** Implemented
 
-## Context
+### 2026-03-06T15:37:00Z: User directive — Quality is absolutely job #1
+**By:** Brady (via Copilot)
+**What:** Quality is the top priority from here on out. "Two mistakes and you're locked out" policy is now in effect — agents who produce broken work twice on the same artifact are locked out and a different agent must revise.
+**Why:** User request — recent work introduced regressions (remote control, aspire vanishing, nap vanishing). Trust is earned through correctness.
 
-Brady requested a new sample showing an Azure Function that takes an HTTP POST prompt and dispatches work to a squad. This is the first sample demonstrating the SDK-First builder pattern integrated with a cloud hosting platform.
 
-## Decision
+### 2026-03-06T15:37:00Z: User directive — Double/triple check one another
+**By:** Brady (via Copilot)
+**What:** Agents must cross-verify each other's work before shipping. Review gates are non-optional. Charters should be updated when agents realize their processes are producing errors.
+**Why:** User request — multiple features vanished or broke recently. Prevention over correction.
 
-- **Use case:** Content Review Squad — three agents (tone, technical, copy) review submitted content. Chosen for visual impact and demo clarity over alternatives (brainstorm, code review).
-- **Pattern:** Azure Functions v4 HTTP trigger → squad config via `defineSquad()` builders → mock agent handlers → JSON response. Handlers are mock/heuristic, not wired to the real Squad runtime — the point is demonstrating the SDK config pattern, not production agent execution.
-- **Config import path:** `@bradygaster/squad-sdk/builders` (subpath export). This is the canonical import for SDK-First mode.
-- **Dry-run test:** Sample includes `--dry-run` flag that validates config loading and handler execution without the Azure Functions runtime. All other samples should consider a similar zero-dependency validation path.
 
-## Impact
+### 2026-03-07: Phase 2 Sequential PR Merges (PR #232 + #212)
+**By:** Kobayashi (Git & Release)
+**Status:** Implemented
+**What:** Merge PR #232 (Scribe fix) and PR #212 (version stamp preservation) sequentially into dev. PR #232 merged cleanly (86598f4e). PR #212 required rebase after #232 merged (base changed), resolved conflicts, and merged cleanly (0fedcce).
+**Why:** Sequential merges may require rebase if base changes materially. Rebase that drops commits means the fix was already upstream - safe to proceed. Force-push after rebase is safe in isolated PR resolution.
+**Impact:** Both fixes now in dev. Zero state corruption.
 
-- New sample at `samples/azure-function-squad/` — 7 files, ~200 LOC
-- `samples/README.md` updated with entry #9
-- Sets the pattern for future cloud-platform integration samples (e.g., AWS Lambda, Google Cloud Functions)
+### 2026-03-07: Phase 2 Community PR Merge Process
+**By:** Keaton (Lead)
+**Status:** Completed
+**What:** Merge 3 community PRs from external contributors: PR #230 (EmmittJ - CLI wire-up), PR #217 (williamhallatt - TUI /init fix), PR #219 (williamhallatt - fork contribution docs). All showed UNSTABLE merge state but GitHub reported MERGEABLE. All merged cleanly.
+**Why:** Fork-first contributor workflow now standardized. External contributors can work in parallel with internal agents. Merge conflicts due to base drift, not code conflicts - low-friction, normal pattern.
+**Impact:** Fork contributor procedure documented in CONTRIBUTING.md (PR #219). Team ready to onboard more community contributors. 52+ tests passing across all 3 PRs.
 
+### 2026-03-07: Fix: squad.agent.md excluded from TEMPLATE_MANIFEST upgrade loop
+**By:** Fenster (Core Dev)
+**PR:** #212 (Closes #195)
+**What:** squad.agent.md excluded from the TEMPLATE_MANIFEST.filter(f => f.overwriteOnUpgrade) loop in upgrade.ts. Already handled explicitly with copy + stampVersion() earlier in function.
+**Why:** Manifest loop overwrites the version-stamped file with raw template, resetting version to 0.0.0-source. Caused isAlreadyCurrent to never pass - all 30+ files re-copied on every upgrade.
+**Impact:** Any future manifest entries requiring post-copy transformation must also be excluded and handled individually.

.squad/log/2026-03-05T22-10-00Z-sdk-first-docs-sample.md

@@ -0,0 +1,63 @@
+# Session: 2026-03-05T22:10:00Z SDK-First Docs & Sample
+
+## Who Worked
+
+- McManus (DevRel, Haiku)
+- Hockney (SDK Testing Lead, Sonnet)
+- Edie (TypeScript Strict, Sonnet)
+- Keaton (Architecture Lead, Haiku)
+- Fenster (Full-Stack, Sonnet)
+
+## What Was Done
+
+### 1. SDK-First Mode Documentation (McManus)
+- `docs/sdk-first-mode.md` (18.5 KB) — complete guide to 8 builders + CLI flags
+- `docs/reference/sdk.md` — builder quick reference
+- `README.md` — "SDK-First Mode" subsection
+- `CHANGELOG.md` — Phase 1 section with builders + docs updates
+- Experimental banner added; tone ceiling maintained
+
+### 2. Markdown → SDK Conversion Test Suite (Hockney)
+- `test/sdk-conversion.test.ts` — 29 unit + integration tests
+- Full coverage: all builders, config discovery, CLI flags, error cases
+- All tests passing; mocked LLM to avoid API calls in CI
+
+### 3. Builder Type Verification (Edie)
+- Added `description` field to all builder types
+- Converted `squad.config.ts` to use `defineSquad()` builder
+- Verified strict TypeScript across all builder usage
+- No unsafe indexing, full type safety
+
+### 4. Azure Function Sample Architecture (Keaton)
+- Filed issue #213 — "Content Review Squad Azure Function Sample"
+- Wrote proposal-first architecture decision
+- Scope: SDK-First config, serverless HTTP trigger, streaming response, cost tracking
+- Use case: Content Review Squad (tone, technical, SEO, copy agents)
+
+### 5. Azure Function Sample Implementation (Fenster)
+- `samples/azure-function-squad/` — 7 files, ~200 LOC
+- HTTP entry point, SDK-First config, mock handlers, response aggregation
+- Updated `samples/README.md` with entry #9
+- All tests passing; local dev setup included
+
+## Key Decisions
+
+1. **SDK-First Documentation Strategy** (McManus)
+   - Three-tier approach: dedicated guide + SDK reference + README quick ref
+   - Single source of truth; examples from actual source code
+
+2. **Azure Function Sample Pattern** (Keaton → Fenster)
+   - Content Review Squad use case (reusable for email, code, proposal review)
+   - SDK-First builders (no YAML scaffolding)
+   - Mock handlers (demonstrates config pattern, not production execution)
+   - Dry-run flag for zero-dependency validation
+
+## Status
+
+✅ All agents completed their work and committed to origin/dev (14af372)
+
+## Next Steps
+
+- PR review and integration with CI/CD
+- Azure Functions sample can serve as template for Lambda, GCP variants
+- Keaton to approve architectural fit; Brady to validate user experience

.squad/log/2026-03-05T22-46-00Z-azure-func-fix.md

@@ -0,0 +1,31 @@
+# Session Log — Azure Function Sample Fix
+
+**Date:** 2026-03-05T22:46:00Z  
+**Duration:** 2 agents, parallel  
+**Topic:** Azure Function sample — "No job functions found" error resolution  
+
+## Problem
+
+Brady encountered "No job functions found" error running the Azure Function sample. Root cause: missing `main` field in package.json. Azure Functions v4 requires `main` to discover function registrations.
+
+## Solution
+
+**Fenster (Core Dev):**
+- Added `"main": "dist/functions/squad-prompt.js"` to package.json
+- Updated `start` script to build before running: `npm run build && func start`
+- Documented both requirements in README.md + troubleshooting section
+- Committed at SHA 7970765
+
+**Hockney (Tester):**
+- Verified build succeeds
+- Confirmed `func start` dry-run passes
+- Confirmed sample structure correct
+- Approved for release
+
+## Decisions Made
+
+1. **Azure Function samples require `main` field and build step.** This pattern applies to all future serverless TypeScript samples. Merged to decisions.md.
+
+## Status
+
+✅ Complete. Sample is fixed and ready for v0.8.21 release. Brady can now run the sample successfully.