sinapse-ai 7.1.0 → 7.3.0

package/squads/claude-code-mastery/checklists/agent-team-readiness-checklist.md

@@ -0,0 +1,88 @@
+# Agent Team Readiness Checklist
+
+**Checklist ID:** CCM-CL-003
+**Referenced by:** swarm-orqx
+**Purpose:** Pre-spawn validation before launching parallel or sequential agent teams. Ensures task decomposition is sound, agents are configured, isolation is planned, and failure recovery is defined.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - AGENT TEAM READINESS
+
+This checklist validates that a multi-agent execution plan is safe
+to launch. It prevents wasted compute, merge conflicts, and orphaned
+work by catching configuration issues before any agent spawns.
+
+EXECUTION APPROACH:
+1. Review the task decomposition plan
+2. Validate each agent's configuration and tool access
+3. Confirm isolation strategy prevents conflicts
+4. Verify resource limits and cost estimates
+5. Ensure communication and merge strategies are defined
+6. All CRITICAL items must pass before any agent spawns
+
+Spawning agents without validation creates expensive cleanup work.]]
+
+---
+
+## 1. Task Decomposition
+
+- [ ] All subtasks are identified with clear scope boundaries (CRITICAL)
+- [ ] Dependencies between subtasks are mapped (which must finish before others start)
+- [ ] No circular dependencies exist between subtasks (CRITICAL)
+- [ ] Each subtask has a single responsible agent assigned
+- [ ] Subtask outputs are well-defined (files, artifacts, status reports)
+- [ ] Estimated complexity per subtask is documented (small/medium/large)
+- [ ] Parallel-safe subtasks are identified (no shared file modifications)
+
+## 2. Agent Configuration
+
+- [ ] Agent definition files (.md) exist for every assigned agent (CRITICAL)
+- [ ] Model selection is appropriate for each agent's task complexity
+- [ ] Tool restrictions match each agent's needs (no unnecessary tool access)
+- [ ] Agent personas do not conflict with subtask requirements
+- [ ] System prompts or CLAUDE.md content is compatible with agent roles
+- [ ] Each agent has access to the specific files it needs to read/modify
+
+## 3. Isolation Strategy
+
+- [ ] Worktree vs shared workspace decision is made and documented (CRITICAL)
+- [ ] Branch naming convention defined (e.g., agent/{agent-id}/{subtask-id})
+- [ ] If shared workspace: file-level locking strategy defined to prevent conflicts
+- [ ] If worktree isolation: base branch for each worktree identified
+- [ ] Agents working on the same codebase have non-overlapping file scopes
+- [ ] Temporary files and build artifacts have agent-specific paths
+
+## 4. Resource Planning
+
+- [ ] max_turns is set for each agent to prevent runaway execution (CRITICAL)
+- [ ] Background vs foreground execution decided per agent
+- [ ] Total estimated cost calculated across all agents
+- [ ] Cost ceiling defined (max spend before halting)
+- [ ] Timeout limits set for each agent spawn
+- [ ] Memory/context budget per agent assessed (large codebases may hit limits)
+
+## 5. Communication Plan
+
+- [ ] How agents share intermediate results is defined (files, status files, stdout)
+- [ ] Merge strategy for combining agent outputs is documented (CRITICAL)
+- [ ] Conflict resolution procedure exists for overlapping changes
+- [ ] Status reporting mechanism defined (polling, completion files, events)
+- [ ] Final integration point identified (which agent or process merges everything)
+- [ ] Handoff artifacts between sequential agents are specified
+
+## 6. Rollback Plan
+
+- [ ] What happens if an individual agent fails is defined (CRITICAL)
+- [ ] Cleanup procedure for failed agent's partial work is documented
+- [ ] Other agents can continue independently if one fails (graceful degradation)
+- [ ] Worktree cleanup command is prepared for post-execution
+- [ ] Git state can be restored to pre-spawn baseline if entire team fails
+- [ ] Orphaned branch detection and cleanup is planned
+
+---
+
+## PASS/FAIL Criteria
+
+**PASS:** All items marked (CRITICAL) are checked. All agents have valid definitions. Task decomposition has no circular dependencies. Merge strategy is documented.
+
+**FAIL:** Any (CRITICAL) item unchecked. Missing agent definition file. Circular dependency detected. No merge strategy defined.
+
+**Action on FAIL:** Fix all critical gaps before spawning any agent. If task decomposition has circular dependencies, restructure the plan. If agent definitions are missing, create them first.

package/squads/claude-code-mastery/checklists/brownfield-readiness-checklist.md

@@ -0,0 +1,91 @@
+# Brownfield Readiness Checklist
+
+**Checklist ID:** CCM-CL-006
+**Referenced by:** project-integrator
+**Purpose:** Readiness check before integrating Claude Code into an existing (brownfield) project. Ensures the repository is analyzed, conventions are discovered, sensitive files are mapped, and risks are mitigated.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - BROWNFIELD READINESS
+
+This checklist is used BEFORE adding Claude Code configuration to an
+existing project. It ensures we understand the codebase, protect
+sensitive files, and integrate without disrupting existing workflows.
+
+EXECUTION APPROACH:
+1. Analyze the repository structure and existing tooling
+2. Discover conventions and patterns already in use
+3. Map ALL sensitive files and secrets
+4. Assess team considerations for configuration choices
+5. Document risks and prepare rollback plan
+6. All CRITICAL items must pass before starting integration
+
+Brownfield integration done carelessly exposes secrets and breaks workflows.
+Take the time to understand before modifying.]]
+
+---
+
+## 1. Repository Analysis
+
+- [ ] Git repository is initialized and has commit history
+- [ ] `.gitignore` exists and covers common patterns (node_modules, build output, OS files)
+- [ ] CI/CD pipeline is present (GitHub Actions, GitLab CI, Jenkins, etc.)
+- [ ] Repository has a defined branching strategy (main/develop, trunk-based, etc.)
+- [ ] Package manager is identified (npm, yarn, pnpm, bun) with lockfile present
+- [ ] Build system is identified and functional (`npm run build` or equivalent works)
+- [ ] Project language and framework are documented or identifiable
+
+## 2. Existing Tooling
+
+- [ ] Linter is configured (ESLint, Prettier, etc.) with existing rules
+- [ ] Test framework is present (Jest, Vitest, Mocha, pytest, etc.)
+- [ ] Code formatting rules are defined and enforced
+- [ ] Pre-commit hooks exist (husky, lint-staged, etc.)
+- [ ] IDE configuration files are present (.vscode/, .idea/, etc.)
+- [ ] Other AI coding tools are configured (Copilot, Cursor rules, etc.)
+
+## 3. Convention Discovery
+
+- [ ] Naming patterns identified (camelCase, PascalCase, kebab-case for files)
+- [ ] Directory structure mapped (src/, lib/, app/, components/, etc.)
+- [ ] Import style identified (absolute vs relative, path aliases)
+- [ ] Error handling patterns documented (try/catch, Result types, error boundaries)
+- [ ] State management approach identified (if frontend project)
+- [ ] API patterns documented (REST, GraphQL, tRPC, etc.)
+- [ ] Test file naming convention identified (*.test.ts, *.spec.ts, __tests__/)
+
+## 4. Sensitive Files
+
+- [ ] All `.env` files located and cataloged (CRITICAL)
+- [ ] Credentials files identified (service accounts, API keys, certificates) (CRITICAL)
+- [ ] Secret management approach documented (vault, env vars, config files)
+- [ ] `.gitignore` already excludes secret files (verify, do not assume)
+- [ ] No committed secrets found in git history (run secret scanner if available)
+- [ ] Private key files (*.key, *.pem, *.p12) located and mapped
+- [ ] Database connection strings identified and their storage method documented
+
+## 5. Team Considerations
+
+- [ ] Team size documented (solo, small team, large team)
+- [ ] Permission mode preference decided (explore for solo, ask for teams, auto for trusted CI)
+- [ ] Shared vs local settings strategy decided (settings.json vs settings.local.json)
+- [ ] Existing code review process documented (PR reviews, pair programming)
+- [ ] Team familiarity with AI coding tools assessed
+- [ ] Communication plan for introducing Claude Code to team members defined
+
+## 6. Risk Assessment
+
+- [ ] Critical paths identified (auth, payments, data processing) that need extra deny rules
+- [ ] Rollback plan exists (can remove .claude/ directory cleanly) (CRITICAL)
+- [ ] No existing .claude/ directory that would be overwritten
+- [ ] Integration will not modify existing CI/CD without explicit approval
+- [ ] First integration scope is limited (start with CLAUDE.md + settings, add rules incrementally)
+- [ ] Test environment available for validating integration before team-wide rollout
+
+---
+
+## PASS/FAIL Criteria
+
+**PASS:** All items marked (CRITICAL) are checked. Sensitive files are fully mapped. Rollback plan documented. Risk assessment complete with mitigations for each identified risk.
+
+**FAIL:** Any (CRITICAL) item unchecked. Sensitive files not fully identified. No rollback plan. Risk assessment incomplete.
+
+**Action on FAIL:** Complete sensitive file mapping before any integration work. Document rollback plan. If secrets are found in git history, address that security issue before proceeding with Claude Code integration.

package/squads/claude-code-mastery/checklists/change-checklist.md

@@ -0,0 +1,75 @@
+# Change Impact Assessment Checklist
+
+**Checklist ID:** CCM-CL-002
+**Referenced by:** config-engineer, roadmap-sentinel
+**Purpose:** Systematically assess the impact of Claude Code configuration modifications before applying them. Ensures backward compatibility, security integrity, and context budget discipline.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - CHANGE IMPACT ASSESSMENT
+
+This checklist is used BEFORE applying configuration changes to Claude Code
+artifacts (.claude/ directory, settings, rules, hooks, MCP config).
+
+EXECUTION APPROACH:
+1. Identify all files that will change
+2. For each category, assess impact and document findings
+3. Security impacts must be explicitly assessed -- never skip
+4. A rollback plan is mandatory for any change touching deny rules or hooks
+5. Present the completed assessment to the user for approval
+
+Changes to Claude Code configuration affect ALL agents and sessions.
+Treat configuration changes with the same rigor as production deployments.]]
+
+---
+
+## 1. Scope Assessment
+
+- [ ] List all settings files affected by this change (settings.json, settings.local.json, CLAUDE.md, rules/)
+- [ ] Identify which agents are impacted (check agent definitions for dependencies on changed files)
+- [ ] Determine if the change affects only the current project or all projects (global vs local scope)
+- [ ] Verify the change does not touch framework-protected paths (L1/L2 boundary)
+- [ ] Document the motivation for the change (bug fix, optimization, new capability, security hardening)
+
+## 2. Backward Compatibility
+
+- [ ] Existing agent activation workflows still function after the change
+- [ ] No permission regressions (agents that could previously access files still can)
+- [ ] Custom commands defined in agent files still resolve to valid task paths
+- [ ] Workflows referencing changed rules or settings still execute correctly
+- [ ] Hook integrations (PreToolUse, PostToolUse) remain functional
+- [ ] If removing a rule or setting, confirm no agent or workflow depends on it
+
+## 3. Security Impact
+
+- [ ] Deny rules are not weakened or removed without explicit security justification (CRITICAL)
+- [ ] No new sensitive file patterns exposed by allow rule additions (CRITICAL)
+- [ ] Permission mode changes are intentional (explore/ask/auto transitions documented)
+- [ ] Secret file patterns (.env, credentials.json, *.key, *.pem) remain in deny rules
+- [ ] MCP server access is not broadened beyond intended scope
+- [ ] Hook scripts do not introduce new file system write access to protected areas
+
+## 4. Context Impact
+
+- [ ] Calculate CLAUDE.md line count delta (before vs after change)
+- [ ] Count rules files delta (added, removed, modified)
+- [ ] Assess MCP context budget delta (new servers add context overhead)
+- [ ] Verify total always-loaded context stays within performance budget
+- [ ] If adding new always-loaded content, identify what can be moved to path-scoped rules
+- [ ] No unnecessary duplication introduced between CLAUDE.md, rules, and agent definitions
+
+## 5. Rollback Plan
+
+- [ ] Changes can be reverted with a single git checkout or documented manual steps
+- [ ] Backup of current configuration exists before applying changes (CRITICAL)
+- [ ] Rollback procedure is documented in change notes
+- [ ] If the change involves hook modifications, the previous hook version is preserved
+- [ ] Database or persistent state changes (if any) have a reversal path
+
+---
+
+## PASS/FAIL Criteria
+
+**PASS:** All impacts assessed and mitigated. Security section has zero unchecked items. Rollback plan exists.
+
+**FAIL:** Any item in Security Impact is unchecked without justification, OR no rollback plan documented, OR scope assessment incomplete.
+
+**Action on FAIL:** Address all security gaps and document rollback plan before proceeding. Escalate to config-engineer if unsure about security implications.

package/squads/claude-code-mastery/checklists/context-rot-checklist.md

@@ -0,0 +1,114 @@
+# Context Rot Checklist
+
+**Checklist ID:** CCM-CL-007
+**Referenced by:** project-integrator
+**Purpose:** Detect staleness, bloat, and outdated references in CLAUDE.md and rules files. Produces a Rot Score (0-100, lower = more rot) to quantify context health and prioritize cleanup.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - CONTEXT ROT DETECTION
+
+Context rot occurs when CLAUDE.md, rules, and memory files accumulate
+stale references, outdated instructions, and redundant content over time.
+This degrades agent accuracy and wastes context budget.
+
+EXECUTION APPROACH:
+1. Measure CLAUDE.md size against budget limits
+2. Validate every file path and reference mentioned in context files
+3. Check instructions against current codebase reality
+4. Verify rules match current directory structure
+5. Audit memory files for relevance
+6. Check for redundancy across all context sources
+7. Calculate Rot Score from findings
+
+Context rot is gradual and invisible until agent behavior degrades.
+Regular audits prevent accumulation.]]
+
+---
+
+## 1. Size Check
+
+- [ ] CLAUDE.md is under 200 lines (for auto-memory projects)
+- [ ] CLAUDE.md is under 500 lines total (absolute maximum)
+- [ ] No single rule file exceeds 200 lines
+- [ ] Total always-loaded rules content is under 1000 lines combined
+- [ ] No unnecessary code blocks or verbose examples (could be in rules instead)
+- [ ] Managed sections are concise (tables preferred over prose)
+
+## 2. Reference Validity
+
+- [ ] All file paths mentioned in CLAUDE.md resolve to existing files (CRITICAL)
+- [ ] All directory paths mentioned in CLAUDE.md resolve to existing directories
+- [ ] All command examples reference valid scripts or binaries
+- [ ] All agent names referenced in CLAUDE.md match actual agent definitions
+- [ ] All checklist references resolve to existing checklist files
+- [ ] All task references resolve to existing task files
+- [ ] URLs and links (if any) are accessible and current
+
+## 3. Instruction Currency
+
+- [ ] No references to deprecated APIs or libraries (CRITICAL)
+- [ ] No references to removed or renamed files
+- [ ] Command syntax matches current tool versions (e.g., CLI flags still valid)
+- [ ] Framework version references are current
+- [ ] Workflow descriptions match actual implemented behavior
+- [ ] Testing instructions use current test runner and patterns
+- [ ] Build commands match current package.json scripts
+
+## 4. Rule Health
+
+- [ ] Rule `paths:` frontmatter matches current directory structure (CRITICAL)
+- [ ] No rules reference file patterns that no longer exist in the project
+- [ ] Rule content aligns with current coding standards
+- [ ] Path-scoped rules correctly scope to their intended files
+- [ ] No rule has been untouched for more than 90 days in an active project
+- [ ] Rules do not reference removed agents or deprecated workflows
+
+## 5. Memory Hygiene
+
+- [ ] Auto-memory files (MEMORY.md, agent memory) contain relevant content
+- [ ] No stale entries referencing completed or abandoned work
+- [ ] Memory entries are organized by topic (not chronological dumps)
+- [ ] No memory entries contradict current CLAUDE.md instructions
+- [ ] Memory file sizes are within limits (MEMORY.md under 200 lines)
+- [ ] Temporary notes (session-specific) have been cleaned up
+
+## 6. Redundancy Check
+
+- [ ] No duplicate instructions between CLAUDE.md and rules files (CRITICAL)
+- [ ] No duplicate instructions between CLAUDE.md and agent definitions
+- [ ] No duplicate instructions between different rule files
+- [ ] Common patterns are defined once and referenced (not copied)
+- [ ] If the same instruction appears in multiple places, consolidate to one source
+- [ ] Settings in settings.json are not re-stated as prose in CLAUDE.md
+
+---
+
+## Rot Score Calculation
+
+For each category, count failed items (excluding N/A). Apply weights:
+
+| Category | Weight | Max Deduction |
+|----------|--------|---------------|
+| Size Check | 1x per fail | 10 points |
+| Reference Validity | 3x per fail | 21 points |
+| Instruction Currency | 2x per fail | 14 points |
+| Rule Health | 2x per fail | 12 points |
+| Memory Hygiene | 1x per fail | 6 points |
+| Redundancy Check | 2x per fail | 12 points |
+
+**Rot Score** = 100 - (total deductions, capped at 100)
+
+| Score Range | Health Status | Action Required |
+|-------------|--------------|-----------------|
+| 80-100 | Healthy | Routine maintenance only |
+| 60-79 | Aging | Schedule cleanup within 1-2 sprints |
+| 40-59 | Rotting | Immediate cleanup sprint needed |
+| 0-39 | Critical | Full context rebuild recommended |
+
+## Priority Fix Order
+
+1. **Reference Validity** failures -- broken paths cause agent errors
+2. **Instruction Currency** failures -- outdated instructions cause wrong behavior
+3. **Redundancy** failures -- duplicates waste context budget and cause conflicts
+4. **Rule Health** failures -- stale rules load unnecessary content
+5. **Size Check** failures -- bloat degrades all operations
+6. **Memory Hygiene** failures -- stale memory misleads agents

package/squads/claude-code-mastery/checklists/integration-audit-checklist.md

@@ -0,0 +1,104 @@
+# Integration Audit Checklist
+
+**Checklist ID:** CCM-CL-005
+**Referenced by:** project-integrator
+**Purpose:** Audit the quality of an existing Claude Code integration in a project. Produces a scored grade (A-F) to identify gaps and prioritize improvements.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - INTEGRATION AUDIT
+
+This checklist evaluates how well Claude Code is integrated into a project.
+Use it to audit existing setups and identify improvement opportunities.
+
+EXECUTION APPROACH:
+1. Check each item against the actual project state
+2. Mark [x] for present and correct, [ ] for missing or incorrect, [N/A] for not applicable
+3. Count checked items vs total applicable items
+4. Calculate score and grade
+5. Prioritize gaps by category (security first, then structure, then optimization)
+
+This audit is non-destructive -- it only reads and reports.]]
+
+---
+
+## 1. Directory Structure
+
+- [ ] `.claude/` directory exists at project root
+- [ ] `.claude/settings.json` is present and valid JSON
+- [ ] `.claude/rules/` directory exists with at least one rule file
+- [ ] `.claude/CLAUDE.md` exists
+- [ ] `.claude/agents/` directory exists (if project uses custom agents)
+- [ ] `.claude/skills/` directory exists (if project uses custom skills)
+
+## 2. Configuration Quality
+
+- [ ] Deny rules exist for `.env` and common secret file patterns (CRITICAL)
+- [ ] Deny rules exist for `node_modules/`, `.git/objects`, and large binary directories
+- [ ] Permission mode is set to an appropriate level (not `auto` for untrusted repos)
+- [ ] Allow rules are scoped narrowly (not blanket `*` patterns)
+- [ ] Settings follow the principle of least privilege
+- [ ] Local overrides (`settings.local.json`) are gitignored
+
+## 3. CLAUDE.md Health
+
+- [ ] CLAUDE.md exists and is not empty (CRITICAL)
+- [ ] CLAUDE.md is under 500 lines (under 200 preferred)
+- [ ] No stale file path references (all mentioned paths resolve to existing files)
+- [ ] Instructions are specific to this project (not generic boilerplate)
+- [ ] Managed sections (if present) have matching start/end markers
+- [ ] No contradictory instructions within the document
+- [ ] Code examples are syntactically valid and use current project patterns
+
+## 4. Hook Coverage
+
+- [ ] At least one damage-control hook exists (PreToolUse for destructive commands)
+- [ ] Hooks have been tested (not just written and never validated)
+- [ ] Hook scripts handle errors gracefully (no unhandled exceptions)
+- [ ] Hooks have explicit timeouts to prevent blocking
+- [ ] PostToolUse hooks do not silently swallow errors
+
+## 5. MCP Integration
+
+- [ ] MCP servers are configured in `.claude/mcp.json` or equivalent (if MCP is used)
+- [ ] Configured servers are reachable and authenticated
+- [ ] Context budget for MCP tools is documented or within reasonable limits
+- [ ] MCP tool selection priority is documented (native tools preferred)
+- [ ] No redundant MCP servers (each serves a distinct purpose)
+
+## 6. Rules Coverage
+
+- [ ] Path-based rules exist for major source directories (src/, lib/, tests/)
+- [ ] No orphaned rules (rules that reference non-existent file patterns)
+- [ ] Rules use frontmatter `paths:` for path-scoped loading (not always-loaded)
+- [ ] Total always-loaded rule content stays under 1000 lines combined
+- [ ] Rules do not duplicate content already in CLAUDE.md
+- [ ] Rule file naming follows kebab-case convention
+
+## 7. Agent Definitions
+
+- [ ] If `.claude/agents/` exists, each agent file has valid structure
+- [ ] Agent definitions include clear role and scope descriptions
+- [ ] Agent tool access is restricted to what each agent needs
+- [ ] Agent command lists reference valid task files
+- [ ] No conflicting instructions between agent definitions
+
+---
+
+## Scoring
+
+**Calculation:** (Checked items) / (Total items - N/A items) x 100
+
+| Grade | Score Range | Interpretation |
+|-------|------------|----------------|
+| A | 90-100% | Excellent integration, production-ready |
+| B | 80-89% | Good integration, minor improvements needed |
+| C | 70-79% | Adequate integration, several gaps to address |
+| D | 60-69% | Below average, significant gaps present |
+| F | Below 60% | Poor integration, major rework needed |
+
+## Priority Fix Order
+
+1. **CRITICAL items** (security deny rules, CLAUDE.md existence) -- fix immediately
+2. **Hook coverage** -- prevents accidental damage
+3. **Rules coverage** -- improves agent accuracy
+4. **Configuration quality** -- optimizes performance
+5. **Agent definitions** -- enhances team workflow

package/squads/claude-code-mastery/checklists/multi-agent-review-checklist.md

@@ -0,0 +1,77 @@
+# Multi-Agent Review Checklist
+
+**Checklist ID:** CCM-CL-004
+**Referenced by:** swarm-orqx
+**Purpose:** Post-completion validation after an agent team finishes work. Ensures all outputs are present, merged without conflict, meet quality standards, and all temporary resources are cleaned up.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - MULTI-AGENT REVIEW
+
+This checklist validates the combined output of a multi-agent execution.
+Run this AFTER all agents have completed or timed out.
+
+EXECUTION APPROACH:
+1. Verify every agent returned a result (or document why it did not)
+2. Check for merge conflicts between agent outputs
+3. Validate each output against its acceptance criteria
+4. Clean up all worktrees, branches, and temporary artifacts
+5. Run integration tests on the combined result
+6. All CRITICAL items must pass for the team execution to be considered successful
+
+Skipping post-execution review leads to orphaned resources and hidden failures.]]
+
+---
+
+## 1. Output Completeness
+
+- [ ] All spawned agents returned results (no silent failures) (CRITICAL)
+- [ ] Agents that timed out have their partial work documented
+- [ ] Each agent's output matches its assigned subtask scope
+- [ ] No agent produced empty or placeholder output
+- [ ] Status reports from each agent are collected and reviewed
+- [ ] Agents that encountered errors logged their failure reason
+
+## 2. Merge Validation
+
+- [ ] No file-level conflicts between agent outputs (CRITICAL)
+- [ ] If conflicts exist, they are resolved with documented rationale
+- [ ] Consistent code formatting across all agent outputs (same lint config applied)
+- [ ] No duplicate function/variable/component names introduced by different agents
+- [ ] Import statements are consistent (no conflicting dependency versions)
+- [ ] Shared configuration files (package.json, tsconfig, etc.) are merged correctly
+
+## 3. Quality Check
+
+- [ ] Each agent's output meets its subtask acceptance criteria (CRITICAL)
+- [ ] `npm run lint` passes on the combined codebase
+- [ ] `npm run typecheck` passes on the combined codebase (if TypeScript)
+- [ ] Unit tests from each agent's work pass individually
+- [ ] No regressions introduced (existing tests still pass)
+- [ ] Code follows project coding standards and patterns
+
+## 4. Worktree Cleanup
+
+- [ ] All worktrees created for this execution are merged or removed (CRITICAL)
+- [ ] No orphaned branches remain from agent work
+- [ ] Temporary files created by agents are cleaned up
+- [ ] Agent-specific build artifacts are removed
+- [ ] `.git/worktrees/` directory has no stale entries
+- [ ] Branch protection rules are restored if temporarily modified
+
+## 5. Integration Test
+
+- [ ] Combined output compiles/builds successfully (CRITICAL)
+- [ ] `npm test` passes on the full integrated codebase
+- [ ] End-to-end workflows affected by the changes still function
+- [ ] API contracts between components written by different agents are compatible
+- [ ] No circular dependencies introduced between new modules
+- [ ] Performance benchmarks are within acceptable range (no significant degradation)
+
+---
+
+## PASS/FAIL Criteria
+
+**PASS:** All agents returned results. No unresolved merge conflicts. Combined codebase passes lint, typecheck, and tests. All worktrees cleaned up.
+
+**FAIL:** Any agent produced no output without documented reason. Unresolved merge conflicts exist. Combined tests fail. Orphaned worktrees or branches remain.
+
+**Action on FAIL:** For missing outputs, determine root cause and re-run individual agent if needed. For merge conflicts, resolve manually and document. For test failures, identify which agent's output causes the failure and fix. For orphaned resources, run cleanup commands.

package/squads/claude-code-mastery/checklists/pre-push-checklist.md

@@ -0,0 +1,79 @@
+# Pre-Push Quality Gate Checklist
+
+**Checklist ID:** CCM-CL-001
+**Referenced by:** config-engineer, roadmap-sentinel
+**Purpose:** Validate Claude Code configuration changes before pushing to remote. Ensures settings integrity, CLAUDE.md quality, rule correctness, hook safety, and MCP sanity.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - PRE-PUSH VALIDATION
+
+This checklist validates Claude Code configuration changes specifically.
+It complements the SINAPSE framework pre-push-checklist but focuses on
+.claude/ directory artifacts, settings.json, rules, hooks, and MCP config.
+
+EXECUTION APPROACH:
+1. For each category, verify every item against the current file state
+2. Mark items as [x] Pass, [ ] Fail, or [N/A] Not Applicable
+3. Any CRITICAL item failure blocks the push
+4. Non-critical failures should be documented with justification
+
+CRITICAL items are marked with (CRITICAL) suffix.]]
+
+---
+
+## 1. Settings Validation
+
+- [ ] `settings.json` is valid JSON with no syntax errors (CRITICAL)
+- [ ] `settings.json` contains `deny` rules for `.env`, credentials, and secrets (CRITICAL)
+- [ ] `settings.json` contains `deny` rules for framework-protected paths (L1/L2 boundary)
+- [ ] No API keys, tokens, or secrets hardcoded in `settings.json`
+- [ ] `settings.local.json` is listed in `.gitignore` if it contains user-specific overrides
+- [ ] Permission defaults (`allow`/`deny`) are intentional and match project security posture
+- [ ] All `allow` rules have corresponding deny rules that they override (no open holes)
+
+## 2. CLAUDE.md Quality
+
+- [ ] CLAUDE.md exists at `.claude/CLAUDE.md` (CRITICAL)
+- [ ] CLAUDE.md is under 500 lines total (recommended under 200 for auto-memory projects)
+- [ ] All `SINAPSE-MANAGED-START` sections have matching `SINAPSE-MANAGED-END` markers (CRITICAL)
+- [ ] No stale file path references (all mentioned paths exist in the repository)
+- [ ] No duplicate instructions between CLAUDE.md and `.claude/rules/` files
+- [ ] Code examples in CLAUDE.md are syntactically valid
+- [ ] No TODO or FIXME comments left in CLAUDE.md content
+
+## 3. Rules Validation
+
+- [ ] All `.claude/rules/*.md` files have valid YAML frontmatter (if path-scoped)
+- [ ] Frontmatter `paths:` values match existing directories or file patterns
+- [ ] No always-loaded rules exceed 200 lines (context budget discipline)
+- [ ] Path-scoped rules only load for their intended file types
+- [ ] No conflicting instructions between different rule files
+- [ ] Rule file names follow kebab-case convention
+- [ ] No orphaned rules (rule references files/patterns that no longer exist)
+
+## 4. Hook Safety
+
+- [ ] All registered hooks have explicit timeout configuration (CRITICAL)
+- [ ] No hook contains infinite loops or unbounded recursion (CRITICAL)
+- [ ] Hook exit codes follow convention (0 = success, non-zero = failure)
+- [ ] Hooks that modify files use atomic write patterns (temp + rename)
+- [ ] PreToolUse hooks do not block essential tool operations
+- [ ] PostToolUse hooks handle errors gracefully (no silent swallowing)
+- [ ] Hook file paths in settings.json resolve to existing scripts
+
+## 5. MCP Configuration
+
+- [ ] All configured MCP servers respond to health checks (if enabled)
+- [ ] MCP context budget stays within project limits (check core-config.yaml)
+- [ ] No duplicate MCP server entries in configuration
+- [ ] MCP servers requiring authentication have valid credentials configured
+- [ ] Docker-based MCPs have container running and accessible
+
+---
+
+## PASS/FAIL Criteria
+
+**PASS:** All items marked (CRITICAL) are checked. Non-critical items have fewer than 3 failures, each with documented justification.
+
+**FAIL:** Any item marked (CRITICAL) is unchecked, OR more than 3 non-critical items fail without justification.
+
+**Action on FAIL:** Fix all critical issues before push. Document non-critical issues as tech debt if deferring.