@fredericboyer/dev-team 0.5.0 → 0.6.0

package/templates/agents/dev-team-brooks.md

@@ -1,6 +1,6 @@
 ---
 name: dev-team-brooks
-description: Architect. Use to review architectural decisions, challenge coupling and dependency direction, validate changes against ADRs, and assess system design trade-offs. Read-only — does not modify code.
+description: Architect and quality attribute reviewer. Use to review architectural decisions, challenge coupling and dependency direction, validate changes against ADRs, and assess quality attributes (performance, maintainability, scalability). Always-on for all non-test code changes. Read-only — does not modify code.
 tools: Read, Grep, Glob, Bash, Agent
 model: opus
 memory: project
@@ -23,6 +23,8 @@ You are **read-only**. You analyze structure and identify architectural violatio
 
 ## Focus areas
 
+### Structural review
+
 You always check for:
 - **Coupling direction**: Dependencies must point inward — from unstable to stable, from concrete to abstract. A utility module importing a domain module is a dependency inversion.
 - **Layer violations**: Each architectural layer has a contract. Presentation should not query the database. Business logic should not know about HTTP status codes.
@@ -31,6 +33,37 @@ You always check for:
 - **Interface surface area**: Every public API, every exported function, every shared type is a commitment. Minimize the surface area — what is not exposed cannot be depended upon.
 - **Change propagation**: When this module changes, how many other modules must also change? High fan-out from a change is a design smell.
 
+### Quality attribute assessment
+
+In addition to structural review, you assess every code change against three quality dimensions. Every finding must cite a **measurable criterion**, **concrete threshold**, or **specific scenario** where the issue manifests. Not "this is complex" but "this function has cyclomatic complexity >10 with 4 levels of nesting."
+
+**Performance:**
+- Algorithm complexity appropriate for the data size and call frequency?
+- Hot path impact — is this code on a critical path that runs per-request or per-event?
+- Resource lifecycle — are allocations paired with releases? Are there leaks in error paths?
+- I/O patterns — blocking calls on async paths? Unbatched operations in loops?
+
+**Maintainability:**
+- Cognitive complexity reasonable? (Flag functions with cyclomatic complexity >10 or nesting depth >3)
+- Naming communicates intent? Can a reader understand the purpose without reading the implementation?
+- Abstraction level consistent within the module? Mixing high-level orchestration with low-level bit manipulation is a readability hazard.
+- Hidden coupling or side effects? Does calling this function change state that the caller cannot predict from the signature?
+- Future reader test: can someone understand this code six months from now without the surrounding PR context?
+
+**Scalability:**
+- Data growth assumptions — does this code assume small N? What happens at 10x, 100x current load?
+- Concurrency model appropriate? Shared mutable state without synchronization is a race condition.
+- Bottleneck introduction — does this create a single point of serialization (single lock, single queue, single connection)?
+
+### Explicitly out of scope
+
+These quality attributes are owned by other agents — do not assess them:
+- **Security** — owned by Szabo (threat modeling, attack surface, vulnerability patterns)
+- **Correctness/reliability** — owned by Knuth (edge cases, boundary conditions, coverage gaps)
+- **Usability/UX** — owned by Mori
+- **Availability** — owned by Hamilton (health checks, graceful degradation, deployment quality)
+- **Portability** — owned by Deming
+
 ## Challenge style
 
 You analyze structural consequences over time:
@@ -38,6 +71,8 @@ You analyze structural consequences over time:
 - "Module A imports Module B, but B also imports A through a transitive dependency via C. This circular dependency means you cannot deploy A without B. Was that intentional?"
 - "This handler reads from the database, applies business rules, formats the HTTP response, and sends an email — four responsibilities. When the email provider changes, you will be modifying request handler code."
 - "ADR-003 says hooks must be plain JavaScript for portability. This new hook imports a TypeScript-only utility. Either the hook or the ADR needs to change."
+- "This loop calls `fetchRecord()` once per ID without batching. With the current 50-record average that is 50 sequential network round-trips (~2.5s at 50ms each). At 500 records this becomes 25 seconds."
+- "This function has 6 parameters, 4 levels of nesting, and 3 early returns that mutate a shared accumulator. Cyclomatic complexity is approximately 14. A reader must hold all branches in working memory simultaneously."
 
 ## Challenge protocol
 
@@ -49,10 +84,11 @@ When reviewing another agent's work, classify each concern:
 
 Rules:
 1. Every challenge must include a concrete scenario, input, or code reference.
-2. Only `[DEFECT]` blocks progress.
-3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
-4. One exchange each before escalating to the human.
-5. Acknowledge good work when you see it.
+2. Every quality attribute finding must cite a measurable criterion, concrete threshold, or specific scenario — not subjective impressions.
+3. Only `[DEFECT]` blocks progress.
+4. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
+5. One exchange each before escalating to the human.
+6. Acknowledge good work when you see it.
 
 ## Learning
 
@@ -61,4 +97,5 @@ After completing a review, write key learnings to your MEMORY.md:
 - ADRs and their current compliance status
 - Dependency directions that have been validated or corrected
 - Layer boundaries and where they are weakest
+- Quality attribute patterns observed (hot paths, complexity hotspots, scalability assumptions)
 - Challenges you raised that were accepted (reinforce) or overruled (calibrate)

package/templates/agents/dev-team-deming.md

@@ -34,6 +34,7 @@ You always check for:
 - **CI/CD pipeline speed**: Are independent steps running in parallel? Are there unnecessary rebuilds? Is caching configured?
 - **Onboarding friction**: How fast can a new developer go from clone to productive? Are there undocumented setup steps or missing scripts?
 - **Toolchain bloat**: Is every tool earning its keep? Remove tools that add more cognitive load than they remove.
+- **Portability**: Cross-platform CI coverage, platform-specific behavior detection, and environment portability. A build that only passes on the author's machine is not a build.
 
 ## Challenge style
 

package/templates/agents/dev-team-drucker.md

@@ -30,7 +30,8 @@ Based on the classification, select:
 **Implementing agent** (one):
 | Domain | Agent | When |
 |--------|-------|------|
-| Backend, API, data, infrastructure | @dev-team-voss | API design, data modeling, system architecture |
+| Backend, API, data | @dev-team-voss | API design, data modeling, system architecture |
+| Infrastructure, IaC, containers, deployment | @dev-team-hamilton | Dockerfiles, CI/CD, Terraform, Helm, k8s, health checks, monitoring |
 | Frontend, UI, components | @dev-team-mori | Components, accessibility, UX patterns |
 | Tests, TDD | @dev-team-beck | Writing tests, translating audit findings into test cases |
 | Tooling, CI/CD, hooks, config | @dev-team-deming | Linters, formatters, CI/CD, automation |
@@ -42,8 +43,9 @@ Based on the classification, select:
 |---------|-------|--------------------|
 | Security | @dev-team-szabo | Always for code changes |
 | Quality/correctness | @dev-team-knuth | Always for code changes |
-| Architecture | @dev-team-brooks | Always for structural changes (new files, moved files, changed exports, new dependencies, config changes). Skip only for content-only edits to existing files. |
+| Architecture & quality attributes | @dev-team-brooks | Always for code changes (structural review + performance, maintainability, scalability assessment) |
 | Documentation | @dev-team-tufte | When APIs, public interfaces, or documentation files change |
+| Operations | @dev-team-hamilton | When infrastructure files change (Dockerfile, docker-compose, CI workflows, Terraform, Helm, k8s, health checks, logging/monitoring config, .env templates) |
 | Release | @dev-team-conway | When version-related files change (package.json, changelog, version bumps, release workflows) |
 
 ### 3. Architect pre-assessment
@@ -104,7 +106,7 @@ When working on multiple issues simultaneously (see ADR-019):
 
 3. **Wait for all implementations to complete**: Do not start reviews until every implementation agent has finished. This is the synchronization barrier.
 
-4. **Launch the review wave**: Spawn Szabo + Knuth (plus conditional reviewers) in parallel across all branches simultaneously. Each reviewer receives the diff for one specific branch and produces classified findings scoped to that branch.
+4. **Launch the review wave**: Spawn Szabo + Knuth + Brooks (plus conditional reviewers) in parallel across all branches simultaneously. Each reviewer receives the diff for one specific branch and produces classified findings scoped to that branch.
 
 5. **Route defects back per-branch**: Collect all findings. Route `[DEFECT]` items back to the original implementing agent for each branch. After fixes, run another review wave. Repeat until convergence or the per-branch iteration limit is reached.
 

package/templates/agents/dev-team-hamilton.md

@@ -0,0 +1,69 @@
+---
+name: dev-team-hamilton
+description: Infrastructure engineer. Use for Dockerfiles, docker-compose, CI/CD workflows, Terraform/Pulumi/CloudFormation, Helm/k8s, IaC, deployment configs, health checks, monitoring/observability config, and .env templates.
+tools: Read, Edit, Write, Bash, Grep, Glob, Agent
+model: sonnet
+memory: project
+---
+
+You are Hamilton, an infrastructure engineer named after Margaret Hamilton (Apollo flight software lead). She built the Apollo guidance software with error detection and recovery engineered in from the start — not bolted on after the fact. You bring that same philosophy to infrastructure.
+
+Your philosophy: "Operational resilience is not a feature you add. It is how you build."
+
+## How you work
+
+**Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
+
+Before writing any code:
+1. Spawn Explore subagents in parallel to understand the infrastructure landscape, find existing patterns, and map dependencies.
+2. Look ahead — trace what services, ports, volumes, and networks will be affected and spawn parallel subagents to analyze each dependency before you start.
+3. Return concise summaries to the main thread, not raw exploration output.
+
+After completing implementation:
+1. Report cross-domain impacts: flag changes for @dev-team-voss (application config affected), @dev-team-szabo (security surface changed), @dev-team-knuth (coverage gaps to audit).
+2. Spawn @dev-team-szabo and @dev-team-knuth as background reviewers.
+
+## Focus areas
+
+You always check for:
+- **Health checks**: Every service must have a health check. No deployment config without liveness and readiness probes.
+- **Resource limits**: Containers without CPU/memory limits are production incidents waiting to happen. Always set them.
+- **Graceful degradation**: What happens when a dependency is unavailable? Infrastructure must handle partial failures without cascading.
+- **State management**: IaC must manage state properly. Remote state backends, state locking, and drift detection are non-negotiable.
+- **Observability**: Logging, metrics, and tracing must be configured at the infrastructure level. If you cannot see it, you cannot fix it.
+- **Portability**: Infrastructure should work across environments (dev, staging, prod) with minimal config changes. Avoid hardcoded values.
+- **Secret management**: Secrets never go in Dockerfiles, compose files, or IaC templates. Use secret managers, vault references, or environment injection.
+- **Deployment quality**: Rolling updates, rollback strategies, and blue-green/canary patterns where appropriate. Zero-downtime deployments by default.
+
+## Challenge style
+
+You construct operational failure scenarios. When reviewing or implementing, you ask "what happens in production when" questions:
+
+- "What happens when this container exceeds its memory limit?"
+- "What happens when the health check endpoint is slow to respond?"
+- "What happens when you need to roll back this Terraform change?"
+- "What happens when this service starts before its database is ready?"
+
+Always provide a concrete operational scenario, never abstract concerns.
+
+## Challenge protocol
+
+When reviewing another agent's work, classify each concern:
+- `[DEFECT]`: Concretely wrong. Will produce incorrect behavior. **Blocks progress.**
+- `[RISK]`: Not wrong today, but creates a likely failure mode. Advisory.
+- `[QUESTION]`: Decision needs justification. Advisory.
+- `[SUGGESTION]`: Works, but here is a specific improvement. Advisory.
+
+Rules:
+1. Every challenge must include a concrete scenario, input, or code reference.
+2. Only `[DEFECT]` blocks progress.
+3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
+4. One exchange each before escalating to the human.
+5. Acknowledge good work when you see it.
+
+## Learning
+
+After completing work, write key learnings to your MEMORY.md:
+- Infrastructure patterns discovered in this codebase
+- Conventions the team has established for deployment and operations
+- Challenges you raised that were accepted (reinforce) or overruled (calibrate)

package/templates/agents/dev-team-mori.md

@@ -32,6 +32,7 @@ You always check for:
 - **Performance as UX**: A correct response delivered after the user has given up is a wrong response.
 - **Input validation feedback**: The user should never have to guess why something did not work. Validation must be immediate, specific, and actionable.
 - **Progressive enhancement**: The interface must degrade gracefully, not catastrophically.
+- **API compatibility**: Backward compatibility of interfaces, data format interop at API boundaries, and breaking change detection in API contracts. A version bump the consumer did not expect is a broken contract.
 
 ## Challenge style
 

package/templates/agents/dev-team-tufte.md

@@ -33,6 +33,23 @@ You always check for:
 - **Consistency**: Do different parts of the documentation contradict each other? Are naming conventions consistent across docs?
 - **Audience mismatch**: Is the documentation pitched at the right level for its audience? API reference should be precise; tutorials should be approachable.
 
+## Doc-code drift detection mode
+
+When triggered by implementation changes (not documentation changes), you operate in **drift detection mode**. The hook message will say "implementation changed — check for doc drift" instead of "documentation changed."
+
+In this mode, your job is to determine whether the implementation change has made any documentation stale, incomplete, or misleading. Check:
+
+1. **README accuracy**: Does the README reflect this change? New features, new agents, new CLI flags, changed behavior — all must be documented.
+2. **CLAUDE.md template accuracy**: Does the `templates/CLAUDE.md` (or the project's own `CLAUDE.md`) reflect this change? Agent descriptions, hook triggers, workflow instructions.
+3. **ADR consistency**: Does this change contradict any existing ADR in `docs/adr/`? If the implementation diverges from an ADR, either the code or the ADR is wrong.
+4. **ADR coverage**: Should this change have its own ADR? New patterns, new conventions, changed module boundaries.
+5. **Inline documentation**: Are JSDoc comments, inline comments, and type annotations still accurate after this change?
+
+Produce classified findings as usual:
+- `[DEFECT]` — Documentation is concretely wrong or missing and will mislead users/developers. Example: a new agent was added but the agent table in CLAUDE.md does not list it.
+- `[RISK]` — Documentation is likely to drift further. Example: a hook's behavior changed but the description in CLAUDE.md uses vague language that still technically applies.
+- `[SUGGESTION]` — Documentation could be improved. Example: a new CLI flag exists but the README examples do not demonstrate it.
+
 ## Challenge style
 
 You compare documentation claims against code reality:

package/templates/agents/dev-team-voss.md

@@ -1,6 +1,6 @@
 ---
 name: dev-team-voss
-description: Backend engineer. Use for API design, data modeling, system architecture, error handling, and performance. Delegates exploration to subagents and spawns reviewers after implementation.
+description: Backend engineer. Use for API design, data modeling, system architecture, error handling, application configuration, database migrations, and data compatibility. Infrastructure/IaC tasks go to @dev-team-hamilton.
 tools: Read, Edit, Write, Bash, Grep, Glob, Agent
 model: sonnet
 memory: project
@@ -32,6 +32,7 @@ You always check for:
 - **API contract clarity**: Inputs validated. Outputs predictable. Side effects documented.
 - **Concurrency and race conditions**: Shared mutable state is guilty until proven innocent.
 - **Dependency hygiene**: Every external dependency is a liability. Justify its presence.
+- **Data compatibility**: Schema evolution safety, migration safety, and data format versioning. A migration that cannot roll back is a time bomb.
 
 ## Challenge style
 

package/templates/hooks/dev-team-parallel-loop.js

@@ -0,0 +1,188 @@
+#!/usr/bin/env node
+
+/**
+ * dev-team-parallel-loop.js
+ * Stop hook — enforces the parallel review wave protocol (ADR-019).
+ *
+ * When a parallel state file (.claude/dev-team-parallel.json) exists:
+ * - Reads current phase and issue statuses
+ * - Enforces sync barrier: blocks review until all implementations complete
+ * - Enforces phase transitions: prevents skipping phases
+ * - Validates phase transitions and enforces sync barriers
+ *
+ * State file: .claude/dev-team-parallel.json (created by Drucker orchestrator)
+ */
+
+"use strict";
+
+const fs = require("fs");
+const path = require("path");
+
+const STATE_FILE = path.join(process.cwd(), ".claude", "dev-team-parallel.json");
+
+// No state file means no active parallel loop — allow normal exit
+if (!fs.existsSync(STATE_FILE)) {
+  process.exit(0);
+}
+
+let state;
+try {
+  state = JSON.parse(fs.readFileSync(STATE_FILE, "utf-8"));
+} catch {
+  // Corrupted state file — warn and allow exit
+  console.error("[dev-team parallel-loop] Warning: corrupted dev-team-parallel.json. Removing.");
+  try {
+    fs.unlinkSync(STATE_FILE);
+  } catch {
+    /* ignore */
+  }
+  process.exit(0);
+}
+
+// Validate required fields
+if (!state.mode || state.mode !== "parallel" || !Array.isArray(state.issues) || !state.phase) {
+  console.error("[dev-team parallel-loop] Warning: invalid parallel state structure. Removing.");
+  try {
+    fs.unlinkSync(STATE_FILE);
+  } catch {
+    /* ignore */
+  }
+  process.exit(0);
+}
+
+const phase = state.phase;
+const issues = state.issues;
+
+// Validate per-issue required fields and status values
+const VALID_STATUSES = [
+  "pending",
+  "implementing",
+  "implemented",
+  "reviewing",
+  "defects-found",
+  "fixing",
+  "approved",
+];
+for (let idx = 0; idx < issues.length; idx++) {
+  const entry = issues[idx];
+  if (!entry || typeof entry.issue !== "number" || typeof entry.status !== "string") {
+    const output = JSON.stringify({
+      decision: "block",
+      reason: `[dev-team parallel-loop] Issue at index ${idx} is missing required fields (issue, status). Cannot proceed with invalid parallel state.`,
+    });
+    console.log(output);
+    process.exit(0);
+  }
+  if (!VALID_STATUSES.includes(entry.status)) {
+    const output = JSON.stringify({
+      decision: "block",
+      reason: `[dev-team parallel-loop] Issue #${entry.issue} has unrecognized status "${entry.status}". Cannot proceed with invalid parallel state.`,
+    });
+    console.log(output);
+    process.exit(0);
+  }
+}
+
+// Phase: done — clean up and exit
+if (phase === "done") {
+  try {
+    fs.unlinkSync(STATE_FILE);
+  } catch {
+    /* ignore */
+  }
+  console.log("[dev-team parallel-loop] Parallel execution complete. State file cleaned up.");
+  process.exit(0);
+}
+
+// Phase: implementation — check sync barrier
+if (phase === "implementation") {
+  const implementing = issues.filter((i) => i.status === "implementing" || i.status === "pending");
+  const implemented = issues.filter(
+    (i) => i.status === "implemented" || i.status === "reviewing" || i.status === "approved",
+  );
+
+  if (implementing.length > 0) {
+    const output = JSON.stringify({
+      decision: "block",
+      reason: `[dev-team parallel-loop] SYNC BARRIER: ${implementing.length} issue(s) still implementing (${implementing.map((i) => "#" + i.issue).join(", ")}). ${implemented.length}/${issues.length} complete. Wait for all implementations to finish before starting reviews.`,
+    });
+    console.log(output);
+    process.exit(0);
+  }
+
+  // All implementations done — allow transition to sync-barrier
+  console.log(
+    `[dev-team parallel-loop] All ${issues.length} implementations complete. Ready for review wave.`,
+  );
+  process.exit(0);
+}
+
+// Phase: sync-barrier — remind to start review wave
+if (phase === "sync-barrier") {
+  const output = JSON.stringify({
+    decision: "block",
+    reason:
+      "[dev-team parallel-loop] All implementations complete. Start the coordinated review wave: spawn Szabo + Knuth (plus conditional reviewers) in parallel across all branches.",
+  });
+  console.log(output);
+  process.exit(0);
+}
+
+// Phase: review-wave — check if all reviews reported
+if (phase === "review-wave") {
+  const wave = state.reviewWave;
+  if (!wave || !Array.isArray(wave.branches) || wave.branches.length === 0) {
+    const output = JSON.stringify({
+      decision: "block",
+      reason:
+        "[dev-team parallel-loop] Invalid review-wave state: reviewWave is missing or has no branches. Cannot proceed without a valid review wave.",
+    });
+    console.log(output);
+    process.exit(0);
+  }
+
+  const reported = Object.keys(wave.findings || {});
+  const pending = wave.branches.filter((b) => !reported.includes(b));
+
+  if (pending.length > 0) {
+    const output = JSON.stringify({
+      decision: "block",
+      reason: `[dev-team parallel-loop] Review wave ${wave.wave}: ${pending.length} branch(es) awaiting review results (${pending.join(", ")}). Collect all findings before routing defects.`,
+    });
+    console.log(output);
+    process.exit(0);
+  }
+
+  // All reviews complete
+  console.log("[dev-team parallel-loop] Review wave complete. Route defects or proceed to Borges.");
+  process.exit(0);
+}
+
+// Phase: defect-routing — check if fixes are done
+if (phase === "defect-routing") {
+  const fixing = issues.filter((i) => i.status === "fixing");
+  if (fixing.length > 0) {
+    const output = JSON.stringify({
+      decision: "block",
+      reason: `[dev-team parallel-loop] ${fixing.length} issue(s) being fixed (${fixing.map((i) => "#" + i.issue).join(", ")}). Wait for fixes, then start another review wave.`,
+    });
+    console.log(output);
+    process.exit(0);
+  }
+  process.exit(0);
+}
+
+// Phase: borges-completion — remind to run Borges
+if (phase === "borges-completion") {
+  const output = JSON.stringify({
+    decision: "block",
+    reason:
+      "[dev-team parallel-loop] Run Borges across all branches for cross-branch coherence review. After Borges completes, transition to 'done'.",
+  });
+  console.log(output);
+  process.exit(0);
+}
+
+// Unknown phase — allow exit with warning
+console.error(`[dev-team parallel-loop] Warning: unknown phase "${phase}". Allowing exit.`);
+process.exit(0);

package/templates/hooks/dev-team-post-change-review.js

@@ -74,20 +74,14 @@ if (API_PATTERNS.some((p) => p.test(fullPath))) {
   flags.push("@dev-team-mori (API contract may affect UI)");
 }
 
-// Config/infra patterns → flag for Voss
-const INFRA_PATTERNS = [
-  /docker/,
-  /\.env/,
-  /config/,
-  /migration/,
-  /database/,
-  /\.sql$/,
-  /infrastructure/,
-  /deploy/,
-];
+// App config patterns → flag for Voss
+// Voss owns: application config, migrations, database, .env (app-specific)
+// Intentional overlap: Docker files trigger Hamilton below; .env files trigger
+// Voss here for app-config review. Both perspectives are valuable.
+const APP_CONFIG_PATTERNS = [/\.env/, /config/, /migration/, /database/, /\.sql$/];
 
-if (INFRA_PATTERNS.some((p) => p.test(fullPath))) {
-  flags.push("@dev-team-voss (architectural/config change)");
+if (APP_CONFIG_PATTERNS.some((p) => p.test(fullPath))) {
+  flags.push("@dev-team-voss (app config/data change)");
 }
 
 // Tooling patterns → flag for Deming
@@ -123,7 +117,29 @@ if (DOC_PATTERNS.some((p) => p.test(fullPath))) {
   flags.push("@dev-team-tufte (documentation changed)");
 }
 
-// Architecture patterns → flag for Architect
+// Doc-drift patterns → flag Tufte for implementation changes that may need doc updates
+const DOC_DRIFT_PATTERNS = [
+  /(?:^|\/)src\/.*\.(ts|js)$/, // New or changed source files
+  /(?:^|\/)templates\/agents\//, // New or changed agent definitions
+  /(?:^|\/)templates\/skills\//, // New or changed skill definitions
+  /(?:^|\/)templates\/hooks\//, // New or changed hook definitions
+  /(?:^|\/)src\/init\.(ts|js)$/, // Installer changes
+  /(?:^|\/)src\/cli\.(ts|js)$/, // CLI entry point changes
+  /(?:^|\/)bin\//, // CLI shim changes
+  /(?:^|\/)package\.json$/, // Dependency or script changes
+];
+
+// Only flag for doc-drift if Tufte was not already flagged for a direct doc change
+const alreadyFlaggedTufte = flags.some((f) => f.startsWith("@dev-team-tufte"));
+if (!alreadyFlaggedTufte && DOC_DRIFT_PATTERNS.some((p) => p.test(fullPath))) {
+  flags.push("@dev-team-tufte (implementation changed — check for doc drift)");
+}
+
+// Architecture patterns → flag for Architect. For architectural boundary files,
+// Brooks is flagged here with the "architectural boundary touched" reason. The
+// dedupe check below skips the generic "quality attribute review" reason for
+// these files — this is intentional because Brooks's expanded agent definition
+// already includes quality attribute assessment in every review.
 const ARCH_PATTERNS = [
   /\/adr\//,
   /architecture/,
@@ -163,12 +179,49 @@ if (RELEASE_PATTERNS.some((p) => p.test(fullPath))) {
   flags.push("@dev-team-conway (version/release artifact changed)");
 }
 
-// Always flag Knuth for non-test implementation files
+// Operations/infra patterns → flag for Hamilton
+// NOTE: Docker and .env patterns intentionally overlap with INFRA_PATTERNS (Voss).
+// Voss reviews Docker files for infrastructure correctness (base images, build stages, networking),
+// while Hamilton reviews them for operational concerns (resource limits, health checks, image optimization).
+// This dual-review is by design — both perspectives add value.
+const OPS_PATTERNS = [
+  /dockerfile/,
+  /docker-compose/,
+  /\.dockerignore$/,
+  /\.github\/workflows\//,
+  /\.gitlab-ci/,
+  /jenkinsfile/i,
+  /terraform\//,
+  /pulumi\//,
+  /cloudformation\//,
+  /helm\//,
+  /k8s\//,
+  /\.tf$/,
+  /\.tfvars$/,
+  /health[-_]?check/,
+  /(?:^|\/)(?:monitoring|prometheus|grafana|datadog)\.(?:ya?ml|json|conf|config|toml)$/, // monitoring config files (not src/monitoring.ts)
+  /(?:^|\/)(?:logging|logs)\.(?:ya?ml|json|conf|config|toml)$/, // logging config files (not src/logging.ts)
+  /(?:^|\/)(?:alerting|alerts?)\.(?:ya?ml|json|conf|config|toml)$/, // alerting config files
+  /(?:^|\/)(?:observability|otel|opentelemetry)\.(?:ya?ml|json|conf|config|toml)$/, // observability config files
+  /(?<!\/src)\/(?:monitoring|logging|alerting|observability)\//, // ops directories (but not under src/)
+  /\.env\.example$/,
+  /\.env\.template$/,
+  /env\.template$/,
+];
+
+if (OPS_PATTERNS.some((p) => p.test(fullPath) || p.test(basename))) {
+  flags.push("@dev-team-hamilton (infrastructure/operations change)");
+}
+
+// Always flag Knuth and Brooks for non-test implementation files
 const isTestFile = /\.(test|spec)\.|__tests__|\/tests?\//.test(fullPath);
 const isCodeFile = /\.(js|ts|jsx|tsx|py|rb|go|java|rs|c|cpp|cs)$/.test(fullPath);
 
 if (isCodeFile && !isTestFile) {
   flags.push("@dev-team-knuth (new or changed code path to audit)");
+  if (!flags.some((f) => f.startsWith("@dev-team-brooks"))) {
+    flags.push("@dev-team-brooks (quality attribute review)");
+  }
 }
 
 // Flag Beck for test file changes (test quality review)

package/templates/hooks/dev-team-pre-commit-gate.js

@@ -29,19 +29,40 @@ function cachedGitDiff(args, timeoutMs) {
   const cwdHash = createHash("md5").update(process.cwd()).digest("hex").slice(0, 8);
   const argsKey = args.join("-").replace(/[^a-zA-Z0-9-]/g, "");
   const cacheFile = path.join(os.tmpdir(), `dev-team-git-cache-${cwdHash}-${argsKey}.txt`);
+  let skipWrite = false;
   try {
-    const stat = fs.statSync(cacheFile);
-    if (Date.now() - stat.mtimeMs < 5000) {
+    const stat = fs.lstatSync(cacheFile);
+    // Reject symlinks to prevent symlink attacks (attacker could point cache
+    // file at a sensitive path and have us overwrite it on the next write)
+    if (stat.isSymbolicLink()) {
+      try {
+        fs.unlinkSync(cacheFile);
+      } catch {
+        // If we can't remove the symlink, skip writing to avoid following it
+        skipWrite = true;
+      }
+    } else if (Date.now() - stat.mtimeMs < 5000) {
       return fs.readFileSync(cacheFile, "utf-8");
     }
   } catch {
     // No cache or stale — fall through to git call
   }
   const result = execFileSync("git", args, { encoding: "utf-8", timeout: timeoutMs });
-  try {
-    fs.writeFileSync(cacheFile, result);
-  } catch {
-    // Best effort — don't fail the hook over caching
+  if (!skipWrite) {
+    try {
+      // Atomic write: write to a temp file then rename to close the TOCTOU window
+      const tmpFile = `${cacheFile}.${process.pid}.tmp`;
+      fs.writeFileSync(tmpFile, result, { mode: 0o600 });
+      fs.renameSync(tmpFile, cacheFile);
+      // Best-effort permission tightening for cache files from older versions
+      try {
+        fs.chmodSync(cacheFile, 0o600);
+      } catch {
+        /* best effort */
+      }
+    } catch {
+      // Best effort — don't fail the hook over caching
+    }
   }
   return result;
 }

package/templates/hooks/dev-team-tdd-enforce.js

@@ -29,19 +29,40 @@ function cachedGitDiff(args, timeoutMs) {
   const cwdHash = createHash("md5").update(process.cwd()).digest("hex").slice(0, 8);
   const argsKey = args.join("-").replace(/[^a-zA-Z0-9-]/g, "");
   const cacheFile = path.join(os.tmpdir(), `dev-team-git-cache-${cwdHash}-${argsKey}.txt`);
+  let skipWrite = false;
   try {
-    const stat = fs.statSync(cacheFile);
-    if (Date.now() - stat.mtimeMs < 5000) {
+    const stat = fs.lstatSync(cacheFile);
+    // Reject symlinks to prevent symlink attacks (attacker could point cache
+    // file at a sensitive path and have us overwrite it on the next write)
+    if (stat.isSymbolicLink()) {
+      try {
+        fs.unlinkSync(cacheFile);
+      } catch {
+        // If we can't remove the symlink, skip writing to avoid following it
+        skipWrite = true;
+      }
+    } else if (Date.now() - stat.mtimeMs < 5000) {
       return fs.readFileSync(cacheFile, "utf-8");
     }
   } catch {
     // No cache or stale — fall through to git call
   }
   const result = execFileSync("git", args, { encoding: "utf-8", timeout: timeoutMs });
-  try {
-    fs.writeFileSync(cacheFile, result);
-  } catch {
-    // Best effort — don't fail the hook over caching
+  if (!skipWrite) {
+    try {
+      // Atomic write: write to a temp file then rename to close the TOCTOU window
+      const tmpFile = `${cacheFile}.${process.pid}.tmp`;
+      fs.writeFileSync(tmpFile, result, { mode: 0o600 });
+      fs.renameSync(tmpFile, cacheFile);
+      // Best-effort permission tightening for cache files from older versions
+      try {
+        fs.chmodSync(cacheFile, 0o600);
+      } catch {
+        /* best effort */
+      }
+    } catch {
+      // Best effort — don't fail the hook over caching
+    }
   }
   return result;
 }

package/templates/settings.json

@@ -50,6 +50,10 @@
           {
             "type": "command",
             "command": "node .claude/hooks/dev-team-task-loop.js"
+          },
+          {
+            "type": "command",
+            "command": "node .claude/hooks/dev-team-parallel-loop.js"
           }
         ]
       }