# constraints.template.yml - CONSTRAINT SETS BY WORK MODE
# Reusable constraints that apply to different work scenarios
# Reference this file: {{import: constraints.template.yml}}

constraints_registry:
  template_mode:
    description: "Constraints when developing or updating templates"
    rules:
      - "✋ NEVER replace {{PLACEHOLDERS}}"
      - "✋ Use generic examples only (no project-specific values)"
      - "✋ Test with mock data, not real project data"
      - "✋ Changes affect ALL projects using these templates"
      - "✋ Document all {{VARIABLES}} in metadata"
    
    anti_patterns:
      - "Hardcoded file paths"
      - "Project-specific configuration examples"
      - "Internal references that won't work in other projects"
      - "Credentials or sensitive data in examples"
    
    validation:
      - "All {{VARIABLES}} preserved unchanged"
      - "Works with all {{VARIABLE}} combinations"
      - "Example values are generic and reusable"
      - "No hardcoded paths or credentials"
  
  feature_mode:
    description: "Constraints when building features or fixing bugs"
    rules:
      - "✅ Use real project values from context/"
      - "✅ Use /scope-release, /enrich-release, /analyze-repo"
      - "✅ Read memory-bank/activeContext.md (or legacy context/vision.md) for current phase"
      - "✅ Link epics ↔ specs in all work"
      - "✅ Follow TDD: Red → Green → Refactor"
      - "✅ Test in all 3 deployment modes"
    
    anti_patterns:
      - "Speculative feature implementation"
      - "Changes without spec linkage"
      - "Test skipping to meet deadline"
      - "Ignoring phase-specific constraints"
    
    validation:
      - "All tests pass (npm test)"
      - "Specs are linked"
      - "Code tested with edge cases"
      - "Error handling implemented"
      - "Config externalized (no hardcoded values)"
  
  support_mode:
    description: "Constraints when helping customers or answering questions"
    rules:
      - "Use public language only"
      - "Reference README.md and public docs"
      - "Don't expose internal strategies"
      - "Point to public repositories for more info"
      - "Keep tone professional and helpful"
    
    anti_patterns:
      - "Exposing internal roadmap"
      - "Mentioning internal team dynamics"
      - "Exposing enterprise-only features"
      - "Referencing private team workflows"
      - "Speculative answers about future direction"
    
    validation:
      - "Response uses only public information"
      - "No internal details exposed"
      - "Links point to public resources"
      - "Clear and helpful tone"