Isolate Squad product assets from team state

.changeset/identity-neutral-squad-templates.md

@@ -0,0 +1,10 @@
+---
+"@bradygaster/squad-cli": patch
+"@bradygaster/squad-sdk": patch
+---
+
+Make shipped Squad templates, build inputs, CI policy, and issue-routing
+automation independent of the repository's current team state so teams can be
+re-cast without changing package artifacts or required checks. Product-owned
+skills now have one exact canonical set, while live-team tests and stale
+cast-specific configuration are removed.

.dockerignore

@@ -9,7 +9,7 @@ docs/dist
 coverage
 .git
 .github
-.squad/.scratch
+.squad
 *.log
 *.tsbuildinfo
 .env

.github/PR_REQUIREMENTS.md

@@ -90,7 +90,8 @@ Requirements are ordered by review flow. All marked **REQUIRED** must be satisfi
 - [ ] `docs/src/navigation.ts` updated if a new docs page is added
 - [ ] Docs build test updated if a new feature page is added (`test/docs-build.test.ts`, run via `npm test`)
 
-**Enforced by**: Manual PR review (FIDO, Flight) + future automated checks in #104
+**Enforced by**: Manual review by the current Quality and Lead role owners +
+future automated checks in #104
 
 ### e) Package / Exports (REQUIRED for new modules — manual review)
 
@@ -149,25 +150,27 @@ Add to PR description under a `## Waivers` section:
 
 - Item waived: (d) Documentation CHANGELOG entry
 - Reason: Security fix needs urgent release (CVE-2024-XXXXX)
-- Approval by: [Flight/FIDO to be stated in PR review comment]
+- Approval by: [current Lead/Quality role owner, stated in a PR review comment]
 ```
 
 ### Waiver Approval Authority
 
-- **Flight (architecture decisions)**: Internal refactors, infrastructure, module reorganization
-- **FIDO (quality decisions)**: Bug fixes, test improvements, samples, CI changes
+- **Lead role owner (architecture decisions)**: Internal refactors,
+  infrastructure, module reorganization
+- **Quality role owner (quality decisions)**: Bug fixes, test improvements,
+  samples, CI changes
 - **Both**: External API changes, breaking changes
 
 ### Waiver Approval Examples
 
 | Scenario | Waivable Items | Approver |
 |----------|----------------|----------|
-| Internal refactor (no API change) | Documentation, Samples | Flight |
-| Security fix | Documentation, Samples (with follow-up issue) | FIDO |
-| Test infrastructure change | Documentation, Exports, Samples | FIDO |
-| CI/GitHub Actions update | Documentation, Exports, Samples | FIDO |
-| Documentation-only change | Code Quality (tests), Exports, Samples | FIDO |
-| Non-breaking SDK bugfix | Samples | FIDO |
+| Internal refactor (no API change) | Documentation, Samples | Lead role owner |
+| Security fix | Documentation, Samples (with follow-up issue) | Quality role owner |
+| Test infrastructure change | Documentation, Exports, Samples | Quality role owner |
+| CI/GitHub Actions update | Documentation, Exports, Samples | Quality role owner |
+| Documentation-only change | Code Quality (tests), Exports, Samples | Quality role owner |
+| Non-breaking SDK bugfix | Samples | Quality role owner |
 
 ### Self-Waiving Is Not Allowed
 
@@ -214,7 +217,8 @@ For migration PRs (> 20 files): include test output summary in the PR descriptio
 
 **Automation dependency**: 9 of 18 requirements are manual-only. Issue #104 (PR completeness gates) is the critical path to automated enforcement. Until #104 ships, this spec depends on reviewer discipline.
 
-**Mitigation**: Phase 4 (Flight/FIDO checklist) codifies consistent judgment. Regular enforcement audits catch drift.
+**Mitigation**: The Lead/Quality review checklist codifies consistent judgment.
+Regular enforcement audits catch drift.
 
 ### 2. Theater Risk
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -51,4 +51,4 @@
 <!-- Any backward-incompatible changes. "None" if clean. -->
 
 ### Waivers
-<!-- If skipping any REQUIRED item: 1) Request waiver in this section, 2) Named reviewer must approve in PR comments BEFORE merge. Format: "Waived: {item}, reason: {why}, approved by: {Flight|FIDO}" -->
+<!-- If skipping any REQUIRED item: 1) Request waiver in this section, 2) The current Lead or Quality role owner must approve in PR comments BEFORE merge. Format: "Waived: {item}, reason: {why}, approved by: {reviewer name and role}" -->

.github/agents/squad.agent.md

@@ -176,11 +176,11 @@ For each squad member with assigned issues, note them in the session context. Wh
 
 **The user should never see a blank screen while agents work.** Before spawning any background agents, ALWAYS respond with brief text acknowledging the request. Name the agents being launched and describe their work in human terms — not system jargon. This acknowledgment is REQUIRED, not optional.
 
-- **Single agent:** `"Fenster's on it — looking at the error handling now."`
+- **Single agent:** `"Runtime Engineer is on it — looking at the error handling now."`
 - **Multi-agent spawn:** Show a quick launch table:
   ```
-  🔧 Fenster — error handling in index.js
-  🧪 Hockney — writing test cases
+  🔧 Runtime Engineer — error handling in index.js
+  🧪 Quality Engineer — writing test cases
   📋 Scribe — logging session
   ```
 
@@ -214,12 +214,12 @@ When spawning agents, include the role emoji in the `description` parameter to m
 4. If no match, use 👤 as fallback
 
 **Examples:**
-- `name: "keaton"`, `description: "🏗️ Keaton: Reviewing architecture proposal"`
-- `name: "fenster"`, `description: "🔧 Fenster: Refactoring auth module"`
-- `name: "hockney"`, `description: "🧪 Hockney: Writing test cases"`
+- `name: "lead"`, `description: "🏗️ Lead: Reviewing architecture proposal"`
+- `name: "runtime-engineer"`, `description: "🔧 Runtime Engineer: Refactoring auth module"`
+- `name: "quality-engineer"`, `description: "🧪 Quality Engineer: Writing test cases"`
 - `name: "scribe"`, `description: "📋 Scribe: Log session & merge decisions"`
 
-The `name` parameter generates the human-readable agent ID shown in the tasks panel — it MUST be the agent's lowercase cast name (e.g., `"eecom"`, `"fido"`). Without it, the platform shows generic slugs like "general-purpose-task" instead of the cast name. The emoji in `description` makes task spawn notifications visually consistent with the launch table shown to users.
+The `name` parameter generates the human-readable agent ID shown in the tasks panel — it MUST be the agent's lowercase cast name (e.g., `"runtime-engineer"`, `"quality-engineer"`). Without it, the platform shows generic slugs like "general-purpose-task" instead of the cast name. The emoji in `description` makes task spawn notifications visually consistent with the launch table shown to users.
 
 ### Directive Capture
 
@@ -234,7 +234,7 @@ The `name` parameter generates the human-readable agent ID shown in the tasks pa
 **NOT directives** (route normally):
 - Work requests ("build X", "fix Y", "test Z", "add a feature")
 - Questions ("how does X work?", "what did the team do?")
-- Agent-directed tasks ("Ripley, refactor the API")
+- Agent-directed tasks ("Runtime Engineer, refactor the API")
 
 **When you detect a directive:**
 
@@ -288,7 +288,7 @@ The routing table determines **WHO** handles work. After routing, use Response M
 
 | Signal | Action |
 |--------|--------|
-| Names someone ("Ripley, fix the button") | Spawn that agent |
+| Names someone ("Experience Engineer, fix the button") | Spawn that agent |
 | Personal agent by name (user addresses a personal agent) | Route to personal agent in consult mode — they advise, project agent executes changes |
 | "Team" or multi-domain question | Spawn 2-3+ relevant agents in parallel, synthesize |
 | Human member management ("add {name} as PM", routes to human) | Follow Human Team Members (see that section) |
@@ -654,7 +654,7 @@ prompt: |
 1. **Never role-play an agent inline.** If you write "As {AgentName}, I think..." without dispatching via the platform's 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. Dispatch to the real agent and let it respond.
 3. **Never skip dispatching (via `task` or `runSubagent`) 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 `name` or `description`.** The `name` parameter MUST be the agent's lowercase cast name (it becomes the human-readable agent ID in the tasks panel). The `description` parameter MUST include the agent's name. `name: "general-purpose-task"` is wrong — `name: "dallas"` is right. `"General purpose task"` is wrong — `"Dallas: Fix button alignment"` is right.
+4. **Never use a generic `name` or `description`.** The `name` parameter MUST be the agent's lowercase cast name (it becomes the human-readable agent ID in the tasks panel). The `description` parameter MUST include the agent's name. `name: "general-purpose-task"` is wrong — `name: "experience-engineer"` is right. `"General purpose task"` is wrong — `"Experience Engineer: 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

.github/dependabot.yml

@@ -8,7 +8,7 @@ updates:
       time: "08:00"
       timezone: "Etc/UTC"
     open-pull-requests-limit: 5
-    labels: ["dependencies", "squad:belanna"]
+    labels: ["dependencies"]
     commit-message:
       prefix: "deps"
     groups:
@@ -37,7 +37,7 @@ updates:
       time: "08:00"
       timezone: "Etc/UTC"
     open-pull-requests-limit: 5
-    labels: ["dependencies", "squad:belanna"]
+    labels: ["dependencies"]
     commit-message:
       prefix: "deps"
     groups:
@@ -67,7 +67,7 @@ updates:
       time: "08:00"
       timezone: "Etc/UTC"
     open-pull-requests-limit: 5
-    labels: ["dependencies", "squad:belanna"]
+    labels: ["dependencies"]
     commit-message:
       prefix: "deps"
     groups:
@@ -85,7 +85,7 @@ updates:
       time: "08:00"
       timezone: "Etc/UTC"
     open-pull-requests-limit: 5
-    labels: ["dependencies", "squad:belanna"]
+    labels: ["dependencies"]
     commit-message:
       prefix: "deps"
     groups:
@@ -103,7 +103,7 @@ updates:
       time: "08:00"
       timezone: "Etc/UTC"
     open-pull-requests-limit: 5
-    labels: ["dependencies", "squad:belanna"]
+    labels: ["dependencies"]
     commit-message:
       prefix: "deps"
     groups:
@@ -121,7 +121,7 @@ updates:
       time: "08:00"
       timezone: "Etc/UTC"
     open-pull-requests-limit: 5
-    labels: ["dependencies", "squad:belanna"]
+    labels: ["dependencies"]
     commit-message:
       prefix: "deps"
     groups:
@@ -145,7 +145,7 @@ updates:
       time: "08:00"
       timezone: "Etc/UTC"
     open-pull-requests-limit: 5
-    labels: ["dependencies", "squad:belanna"]
+    labels: ["dependencies"]
     commit-message:
       prefix: "ci"
     groups:

.github/instructions/squad-routing-guard.instructions.md

@@ -39,33 +39,31 @@ Does the work type match a specialist domain? (See §3 + .squad/routing.md)
 
 ## Step 3 — Routing Table
 
-Read `.squad/routing.md` for the project-specific routing table. For generic Squad questions:
-
-| Work type | Route to | Examples |
-|-----------|----------|---------|
-| Core runtime, adapter, spawn orchestration | **EECOM** | CopilotClient, session pool, tools module |
-| Prompt architecture, coordinator logic | **Procedures** | Agent charters, spawn templates, response tier selection |
-| Type system, TypeScript strictness | **CONTROL** | Discriminated unions, generics, tsconfig |
-| SDK integration | **CAPCOM** | @github/copilot-sdk usage, CopilotSession lifecycle |
-| Tests & quality, CI/CD | **FIDO** | Test coverage, Vitest, edge cases, CI/CD gates |
-| Docs, README, API docs | **PAO** | README, getting-started, demos, contributor recognition |
-| Architecture, product direction, review | **Flight** | Architectural decisions, code review, scope/trade-offs |
-| Session logging, decision merge, DispatchGuard audit | **Scribe** | Auto — never needs explicit routing |
-| Work queue, backlog, DispatchGuard verdict alerts | **Ralph** | GitHub issues, PR state, idle-watch, violations |
-
-**Full project routing table:** `.squad/routing.md`
+Read `.squad/routing.md` and use its current `Work Type` and `Route To`/`Agent`
+columns. That file is the only authoritative work-to-agent mapping. Do not cache
+agent names in this instruction file or infer ownership from a previous cast.
+
+Before routing:
+
+1. Confirm the destination appears in the active `## Members` table in
+   `.squad/team.md`.
+2. Use the member name exactly as written there when constructing a
+   `squad:{slug}` label or spawning the agent.
+3. If no routing row matches, use the active Lead identified by role in
+   `team.md`. If no Lead exists, handle the task as generic work rather than
+   inventing an owner.
 
 ### Examples — what NOT to grab
 
 ```
 ❌ "Fix the TypeScript compilation error in src/adapter/"
-   → Core runtime → Route to EECOM
+   → Look up the current runtime owner in routing.md
 
 ❌ "Add tests for the casting module"
-   → Tests & quality → Route to FIDO
+   → Look up the current quality owner in routing.md
 
 ❌ "Update the README with the new CLI flags"
-   → Docs → Route to PAO
+   → Look up the current documentation owner in routing.md
 
 ✅ "What does .squad/routing.md say about label taxonomy?"
    → Trivial lookup question — answer directly
@@ -80,11 +78,12 @@ Read `.squad/routing.md` for the project-specific routing table. For generic Squ
 
 When you determine a task belongs to a specialist, do NOT silently attempt it. Instead:
 
-1. **State clearly** which agent owns it and why:
-   > "This task (TypeScript type error) belongs to **CONTROL**. I'll note the routing and stop here."
+1. **State clearly** which current agent owns it and why:
+   > "This task matches the type-system route and belongs to **{current member name}**."
 
 2. **Surface the routing path** to the user:
-   > To proceed: apply the `squad:control` label on issue #NNN, or spawn CONTROL directly with the task context.
+   > To proceed: apply that member's current `squad:{slug}` label on issue #NNN,
+   > or spawn the member directly with the task context.
 
 3. **Do not partially complete the task** then hand off — partial work in the wrong agent context creates merge conflicts and inconsistency.
 

.github/workflows/squad-ci.yml

@@ -178,6 +178,10 @@ jobs:
           GH_TOKEN: ${{ github.token }}
       - name: Build
         run: npm run build
+      - name: Type-check
+        run: npm run lint
+      - name: Lint source and tests
+        run: npm run lint:eslint
       - name: Run tests
         run: npm test
 
@@ -269,8 +273,9 @@ jobs:
           # require a changeset (or CHANGELOG update). The top-level templates/ tree is
           # the primary sync target of .squad-templates/ (see scripts/sync-templates.mjs) —
           # an append-only superset whose entire tree is governed squad scaffolding, not
-          # unrelated content. Agent charters under .squad/agents/ are likewise governed.
-          SDK_CLI_PATH_REGEX='^packages/squad-(sdk|cli)/src/|^packages/squad-(sdk|cli)/templates/|^\.squad-templates/|^templates/|^\.squad/agents/.+/charter\.md$'
+          # unrelated content. Live .squad/ team state is deliberately excluded:
+          # re-casting a team must not require a product package changeset.
+          SDK_CLI_PATH_REGEX='^packages/squad-(sdk|cli)/src/|^packages/squad-(sdk|cli)/templates/|^\.squad-templates/|^templates/'
           SDK_CLI_CHANGED=$(echo "$CHANGED" | grep -E "$SDK_CLI_PATH_REGEX" || true)
           if [ -z "$SDK_CLI_CHANGED" ]; then
             echo "✅ Not applicable (no SDK/CLI source or template changes)" >> "$GITHUB_STEP_SUMMARY"

.github/workflows/squad-heartbeat.yml

@@ -97,19 +97,19 @@ jobs:
       - name: Check triage script
         id: check-script
         run: |
-          if [ -f ".squad/templates/ralph-triage.js" ]; then
+          if [ -f "templates/ralph-triage.js" ]; then
             echo "has_script=true" >> "$GITHUB_OUTPUT"
           else
             echo "has_script=false" >> "$GITHUB_OUTPUT"
-            echo "⚠️ ralph-triage.js not found — run 'squad upgrade' to install"
+            echo "⚠️ product-owned ralph-triage.js not found"
           fi
 
       - name: Ralph — Smart triage
         if: steps.check-script.outputs.has_script == 'true'
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          node .squad/templates/ralph-triage.js \
+          node templates/ralph-triage.js \
             --squad-dir .squad \
             --output triage-results.json