ln-640-pattern-evolution-auditor

What it does

Coordinated analysis of implemented architectural patterns against best practices, maintaining a central catalog of patterns and a health timeline. It computes four scores per pattern, detects drift against SLA thresholds, and can auto-create defect stories for architecture degradation. It coordinates multiple workers to inspect layer boundaries, API contracts, dependency graphs, and project structure, and aggregates results to identify cross-domain systemic issues. Output is written to docs/project/patterns_catalog.md and health logs, with an emphasis on documenting discovered patterns, violations, and recommended actions.

How it works

• Loads and validates the patterns catalog from docs/project/patterns_catalog.md, ensuring required sections exist and templates align.
• Uses a multi-phase workflow to discover, verify, and score patterns:
  • Phase 1a Baseline Detection: load catalog, append missing sections from templates, and auto-detect baseline patterns by scanning the codebase.
  • Phase 1b Adaptive Discovery: load references/pattern_library.md to seed discovery heuristics; identify additional project-specific patterns and add them as Discovered Patterns (Adaptive).
  • Phase 1d Applicability Verification: for each detected pattern, verify required components via scoring_rules.md, then apply semantic checks via MCP Ref and WebSearch to exclude language idioms or built-in features.
  • Phase 2 Best Practices Research: fetch best practices via MCP Ref, Context7, and WebSearch for patterns lacking current guidance.
  • Phase 3 Domain Discovery + Output Setup: detect project domains and prepare an output directory under docs/project/.audit/ln-640/ with date stamping.
  • Phase 4 Layer + API + Dependency Graph Audit: run domain-aware or global tasks ln-642, ln-643, ln-644, ln-645, ln-646 to collect structural and contractual data.
  • Phase 5 Pattern Analysis Loop: run ln-641-pattern-analyzer on VERIFIED patterns to compute final scores.
• Worker outputs are written to per-pattern and per-domain files; Phase 6 cross-domain aggregation ingests these outputs to assess systemic issues across domains.
• The system enforces an anti-pattern: avoid direct Skill tool invocations without the Task wrapper, ensuring proper subagent context isolation.

When to use it

Use when the user asks to:

• Check architecture health
• Audit patterns before refactoring
• Find undocumented patterns in codebase

What it can touch

• Writes to: docs/project/patterns_catalog.md, docs/project/architecture_health.md, and per-domain audit reports under docs/project/.audit/ln-640/{YYYY-MM-DD}/
• Invokes workers ln-641, ln-642, ln-643, ln-644, ln-645, ln-646, and uses the Task wrapper format documented in the skill.

Caveats

• SLA-driven actions rely on Linear availability for auto-remediation; if Linear is unavailable, health details are appended to architecture_health.md with ACTION_REQUIRED marker.
• Excludes patterns that are determined to be language idioms or built-in features after semantic checks; such patterns are added to Excluded Patterns.
• Pattern status can be EXCLUDED or VERIFIED; only VERIFIED patterns proceed to cross-domain analysis.