fraim-framework 2.0.67 → 2.0.69

package/dist/registry/rules/communication.md

@@ -1,122 +0,0 @@
-# Communication
-
-## INTENT
-To establish clear communication patterns and progress reporting standards that enable effective coordination between agents and stakeholders, ensuring transparent progress tracking and proper status updates throughout the development process.
-
-## PRINCIPLES
-- **Clear Communication**: Provide transparent progress updates
-- **Evidence-Based**: Show concrete progress with specific details
-- **Consistent Format**: Use standardized reporting templates
-- **Stakeholder Focus**: Communicate what matters to reviewers and users
-- **Actionable Updates**: Provide clear next steps and blocking issues
-- **Ask for help**: When blocked and out of options, ask user for help
-- **ABSOLUTE ACCOUNTABILITY**: Agent is 100% responsible for fixing their own work and mistakes
-
-## COMMUNICATION REQUIREMENTS
-
-### Progress Updates
-Always provide clear progress updates with:
-1. **Actions executed** (imperative, past tense)
-2. **Local progress** (files modified, tests run)
-3. **Remote artifacts** (branch, PR status)
-4. **Next steps** for this issue
-5. **Blocking issues** (if any)
-
-### Status Reporting
-- **Be specific**: "Fixed calendar sync timeout" not "Made changes"
-- **Include evidence**: "Tests run: npm test test-calendar-sync.ts ✅ PASSED"
-- **Show concrete progress**: "Files modified: src/calendar-api.ts, test-calendar-sync.ts"
-- **Indicate readiness**: "Ready for code review" vs "Still working on implementation"
-
-### Communication Channel
-- **GitHub**: The PR is the best way to communicate with your stakeholders. Update the PR with standard templates as covered below
-
-
-## COMMUNICATION TEMPLATES
-1. When you need feedback on a completed spec - Retrieve via `get_fraim_file({ path: "templates/evidence/Spec-Evidence.md" })`
-2. When you need feedback on a completed design - Retrieve via `get_fraim_file({ path: "templates/evidence/Design-Evidence.md" })`
-3. When you need feedback on a completed bug fix implementation - Retrieve via `get_fraim_file({ path: "templates/evidence/Implementation-BugEvidence.md" })`
-4. When you need feedback on a completed feature implementation - Retrieve via `get_fraim_file({ path: "templates/evidence/Implementation-FeatureEvidence.md" })`
-5. When you are stuck and need help - Retrieve via `get_fraim_file({ path: "templates/help/HelpNeeded.md" })`
-
-## EXAMPLES
-
-### Good: Clear Progress Update
-```
-Summary:
-  - Local progress: Fixed calendar sync timeout, added retry logic, ran tests
-  - Files modified: src/calendar-api.ts, test-calendar-sync.ts
-  - Tests run: npm test test-calendar-sync.ts ✅ PASSED
-  - Remote status: Branch feature/84-fix-sync pushed, Draft PR created
-  - Next steps: Wait for code review
-  - Blocking issues: None
-```
-
-### Bad: Vague Progress Update
-```
-Summary:
-  - Local progress: Made some changes
-  - Remote status: Something happened
-  - Next steps: Not sure
-```
-
-### Good: Specific Status Update
-```
-Issue #84: "Fix calendar sync timeout"
-- ✅ Identified root cause: Missing retry logic in calendar API
-- ✅ Implemented exponential backoff with jitter
-- ✅ Added comprehensive test coverage (5 new test cases)
-- ✅ All tests passing locally
-- ✅ Pushed to feature/84-fix-sync
-- ✅ Draft PR created and ready for review
-- Next: Waiting for code review feedback
-```
-
-### Bad: Generic Status Update
-```
-Issue #84: "Fix calendar sync timeout"
-- Working on it
-- Made some changes
-- Need to test more
-```
-
-## ACCOUNTABILITY AND RESPONSIBILITY RULES
-
-### ABSOLUTE ACCOUNTABILITY PRINCIPLE
-**The agent is 100% responsible for fixing their own work and mistakes. No exceptions.**
-
-### PROHIBITED ACCOUNTABILITY DEFLECTION
-**NEVER suggest the user should handle the agent's responsibilities:**
-
-❌ **PROHIBITED LANGUAGE:**
-- "Would you like me to work with you to fix this, or would you prefer to handle it yourself?"
-- "Should I do X or would you prefer to do Y?"
-- "Do you want to fix this yourself?"
-- "Can you handle this part for me?"
-- "Would you like to take over this task?"
-
-✅ **REQUIRED LANGUAGE:**
-- "I will fix this myself"
-- "I am working to resolve this issue"
-- "I will complete the proper validation"
-- "I take full responsibility for this mistake"
-
-### HELP vs RESPONSIBILITY DISTINCTION
-
-**APPROPRIATE Help Requests (when genuinely blocked):**
-- "I'm blocked on X technical issue, can you provide guidance?"
-- "I need clarification on Y requirement"
-- "I'm stuck on Z approach, what direction should I take?"
-
-**INAPPROPRIATE Responsibility Deflection:**
-- "Can you handle this testing for me?"
-- "Would you prefer to do this validation yourself?"
-- "Should I continue or do you want to take over?"
-
-### OWNERSHIP PROTOCOL
-- **Agent breaks it** → **Agent fixes it**
-- **Agent makes mistake** → **Agent corrects it**  
-- **Agent claims false success** → **Agent provides real validation**
-- **Agent creates problems** → **Agent solves them**
-
-**No exceptions. No deflection. No user responsibility for agent mistakes.**

package/dist/registry/rules/continuous-learning.md

@@ -1,55 +0,0 @@
-# Continuous Learning
-
-## INTENT
-To prevent repeating past mistakes and build upon existing solutions by systematically learning from retrospectives, RFCs, and historical issue patterns, ensuring continuous improvement and knowledge accumulation across all agents.
-
-## PRINCIPLES
-- **Learn from History**: Always review past work before starting new tasks
-- **Build on Success**: Apply proven solutions rather than reinventing
-- **Avoid Known Pitfalls**: Use retrospectives to prevent recurring issues
-- **Share Knowledge**: Document learnings for future agents
-- **Pattern Recognition**: Identify recurring problems and solutions
-
-## MANDATORY LEARNING WORKFLOW
-
-### Before Starting Any Work
-1. **Search retrospectives** for related issues or similar problems
-2. **Read relevant RFCs** to understand the design context
-3. **Review test cases** to see expected behavior
-4. **Check issue comments** for previous attempts and solutions
-
-### Knowledge Sources
-- **Retrospectives**: `/retrospectives/` folder for past problem analysis
-- **RFCs**: `/docs/rfcs/` for design decisions and architectural context
-- **Test Cases**: Existing tests show expected behavior patterns
-- **Issue History**: Comments and PRs reveal previous attempts and solutions
-
-## EXAMPLES
-
-### Good: Learning from History
-```
-Issue: "Fix calendar sync timeout"
-Before Starting: 
-- ✅ Read retrospective on issue-45 (similar timeout problem)
-- ✅ Found root cause: missing retry logic
-- ✅ Applied proven solution: exponential backoff
-- ✅ Avoided known pitfall: infinite retry loops
-Result: Fixed in 1 iteration using proven approach
-```
-
-### Bad: Ignoring History
-```
-Issue: "Fix calendar sync timeout"
-Approach: 
-- ❌ Started coding immediately without research
-- ❌ Implemented naive retry logic
-- ❌ Hit same infinite loop issue from issue-45
-- ❌ Wasted 3 iterations on known problem
-Result: Eventually found retrospective, but too late
-```
-
-## RETROSPECTIVE CREATION
-- **Use template**: Retrieve via `get_fraim_file({ path: "templates/retrospective/RETROSPECTIVE-TEMPLATE.md" })` for consistent structure
-- **Follow process**: Use the `get_fraim_file({ path: "workflows/product-building/retrospect.md" })` workflow for retrospective creation workflow
-
-Remember: The best code is often written by those who learn from history rather than repeat it.

package/dist/registry/rules/debugging-multitenancy-issues.md

@@ -1,85 +0,0 @@
-# Systematic Debugging Approach for Multi-Tenancy issues
-
-## INTENT
-To prevent inefficient debugging practices that waste time and frustrate users by running tests repeatedly without fixing root causes.
-
-## PRINCIPLES
-- Analyze test failures before re-running tests
-- Focus on broken functionality, not working tests
-- Follow user instructions immediately
-- Fix root causes, not symptoms
-- Use systematic approach for multi-tenancy debugging
-
-## MANDATORY DEBUGGING WORKFLOW
-
-### 1. **Before Re-running Any Test**
-- [ ] Read the test output carefully to understand WHY it failed
-- [ ] Identify the specific error messages or assertions that failed
-- [ ] Determine if it's a configuration issue, missing data, or broken functionality
-- [ ] Plan the specific fix needed
-
-### 2. **Multi-Tenancy Debugging Checklist**
-- [ ] Verify executive context is being passed correctly (headers + query params)
-- [ ] Check that API calls include `x-executive-id` header
-- [ ] Ensure test navigation includes `executive_id` query parameter
-- [ ] Verify middleware is extracting executive context properly
-- [ ] Check that database operations use correct executive ID
-
-### 3. **Test Analysis Template**
-When a test fails, answer these questions:
-- What specific assertion failed?
-- What data was expected vs. what was received?
-- Is the issue in the test setup, API call, or UI logic?
-- Are all required headers/parameters being sent?
-- Is the executive context being set correctly?
-
-### 4. **Prohibited Actions**
-- ❌ Running the same failing test multiple times without analysis
-- ❌ Adding debug logging without fixing the underlying issue
-- ❌ Running tests that are already working
-- ❌ Ignoring specific user instructions
-- ❌ Making assumptions about what's broken
-
-### 5. **Required Actions**
-- ✅ Analyze test output to identify root cause
-- ✅ Fix the specific issue identified
-- ✅ Verify the fix works before moving on
-- ✅ Follow user instructions exactly as given
-- ✅ Focus on broken functionality only
-
-## COMMON MULTI-TENANCY ISSUES
-
-### Executive Context Problems
-- **Symptom**: "No executive_id found in request" or "Invalid executive context"
-- **Root Cause**: Missing `x-executive-id` header in API calls
-- **Fix**: Add `'x-executive-id': getExecutiveId()` to all API call headers
-
-### Test Navigation Issues
-- **Symptom**: Test can't find records or gets wrong data
-- **Root Cause**: Missing `executive_id` query parameter in navigation URLs
-- **Fix**: Include `&executive_id=${this.testExecutiveId}` in all test navigation
-
-### Middleware Context Issues
-- **Symptom**: API returns 401 or wrong data
-- **Root Cause**: Middleware not setting executive context properly
-- **Fix**: Ensure middleware extracts from headers first, query params as fallback
-
-## SUCCESS METRICS
-- Tests pass on first re-run after fixes
-- No more than 2 iterations per test case
-- User satisfaction with debugging efficiency
-- Clear identification of root causes before fixes
-
-## ANTI-PATTERNS TO AVOID
-
-1. **Debug Loop Anti-Pattern**: Running same test repeatedly without analysis
-2. **Symptom Fixing Anti-Pattern**: Adding logging instead of fixing functionality
-3. **Working Test Anti-Pattern**: Running tests that already pass
-4. **Instruction Ignoring Anti-Pattern**: Not following specific user guidance
-5. **Assumption Anti-Pattern**: Guessing what's wrong instead of analyzing
-
-## ENFORCEMENT
-- Every test failure must be analyzed before re-running
-- User instructions take priority over agent assumptions
-- Focus on broken functionality only
-- Document root cause analysis in comments

package/dist/registry/rules/ephemeral-execution.md

@@ -1,54 +0,0 @@
-# Rule: Direct Script Execution
-
-FRAIM scripts are pre-synchronized to the user's local directory and executed directly from there.
-
-## Policy
-
-1. **Pre-Synchronized Scripts**: All FRAIM scripts are automatically synced to `~/.fraim/scripts/` during `fraim init` and `fraim sync`.
-2. **Direct Execution**: Execute scripts directly from the user scripts directory using standard shell commands.
-3. **No Fetching Required**: Scripts are already available locally - no need to fetch from MCP server.
-
-## Script Location
-
-Scripts are located in the user's home directory at `~/.fraim/scripts/`
-
-**Note for Windows users**: Always use Git Bash terminal to ensure `~` path expansion works correctly.
-
-## Implementation Pattern
-
-When a script is needed:
-
-1. **Verify Sync**: Ensure scripts are up to date with `fraim sync` if needed
-2. **Execute Directly**: Run the script from its synced location
-3. **Working Directory**: Scripts operate on the current working directory
-
-## Example (Bash)
-
-```bash
-# Execute script directly from synced location
-~/.fraim/scripts/prep-issue.sh 123
-
-# TypeScript scripts
-npx tsx ~/.fraim/scripts/generate-engagement-emails.ts
-```
-
-## Example (Node.js/JavaScript)
-
-```javascript
-// Execute script using child_process
-const { execSync } = require('child_process');
-const os = require('os');
-const path = require('path');
-
-const scriptsDir = path.join(os.homedir(), '.fraim', 'scripts');
-const scriptPath = path.join(scriptsDir, 'prep-issue.sh');
-
-// Execute script
-execSync(`"${scriptPath}" 123`, { 
-    cwd: process.cwd(),  // Current working directory
-    stdio: 'inherit' 
-});
-```
-
-> [!IMPORTANT]
-> This rule replaces the previous ephemeral execution pattern. Scripts are now treated as pre-installed tools rather than dynamic content.

package/dist/registry/rules/git-safe-commands.md

@@ -1,34 +0,0 @@
-# Git Safe Commands Rule
-
-## Problem
-Some Git commands (`git log`, `git diff`, `git branch`, `git commit`) open an interactive pager or editor, which causes Windsurf agents to hang.
-
-## Rule
-Agents **must not** run Git commands that may open interactive prompts or pagers **without non-interactive flags**.
-
-### Disallowed (will hang)
-- `git log`
-- `git diff`
-- `git branch`
-- `git commit`
-
-### Allowed (safe variants)
-- `git log --oneline --no-pager`
-- `git diff --no-pager`
-- `git branch --no-color`
-- `git commit -m "message"`
-
-## Enforcement
-If an agent attempts to run one of the disallowed forms, **reject the command** and suggest the safe variant instead.
-
-## Examples
-❌ `git log` → hangs  
-✅ `git log --oneline --no-pager` → safe  
-
-❌ `git diff` → hangs  
-✅ `git diff --no-pager` → safe  
-
-❌ `git commit` → opens editor  
-✅ `git commit -m "Fix issue #123"` → safe  
-
----

package/dist/registry/rules/hitl-ppe-record-analysis.md

@@ -1,302 +0,0 @@
-# HITL PPE Record Analysis & Debugging Patterns
-
-## INTENT
-To provide agents with systematic patterns for analyzing HITL (Human-In-The-Loop) records from PPE database, categorizing issues, and implementing appropriate fixes. This rule ensures consistent analysis and prevents overfitting or missing root causes.
-
-## PRINCIPLES
-- **Systematic Analysis**: Always follow a structured approach (query → analyze → categorize → fix)
-- **Categorize Before Fixing**: Distinguish systemic issues from executive preferences before implementing
-- **Leverage Existing Infrastructure**: Check if existing features can handle needs before adding new fields
-- **Minimal Fixes**: Focus on smallest changes that solve the problem
-- **Avoid Overfitting**: Use generic examples, never specific person names or scenarios
-
-## CORE WORKFLOW PATTERN
-
-### The "Query → Filter → Analyze → Categorize → Fix → Document" Pattern
-
-```
-1. QUERY: Connect to PPE database and query HITL records
-2. FILTER: Exclude test/synthetic data (e.g., ChatGPT records)
-3. ANALYZE: Extract reviewer feedback patterns and identify issues
-4. CATEGORIZE: Divide into systemic (BAML/code) vs preferences (configurable)
-5. FIX: Implement minimal fixes for systemic issues
-6. DOCUMENT: Create GitHub issues for preference gaps
-```
-
-## RULE 1: Data Collection & Filtering
-
-### When Querying HITL Records
-
-**Always filter by source:**
-- Exclude test/synthetic records: `Inputs.source != 'chatgpt'`
-- Handle missing source fields: Use `$or` with `$exists: false`
-- Filter for non-empty reviewer feedback: `ReviewerFeeback: { $exists: true, $regex: /\S/ }`
-
-**Query Pattern:**
-```typescript
-const query = {
-  ReviewerFeeback: {
-    $exists: true,
-    $regex: /\S/  // At least one non-whitespace character
-  },
-  $or: [
-    { 'Inputs.source': { $exists: false } },
-    { 'Inputs.source': { $ne: 'chatgpt' } }
-  ]
-};
-```
-
-**Verification:**
-- [ ] Verify record count makes sense (not too many/too few)
-- [ ] Check that filtered results exclude test data
-- [ ] Confirm reviewer feedback exists and is non-empty
-
-## RULE 2: Issue Categorization
-
-### Before Implementing Fixes, Categorize All Issues
-
-**Systemic Issues (BAML/Code Fixes):**
-- ✅ Affect all executives universally
-- ✅ Examples: Fake conference links, date logic errors, missing calendar data extraction, accountability violations
-- **Action**: Fix in BAML prompts or code logic
-
-**Executive Preferences (Configurable):**
-- ✅ Differ per executive
-- ✅ Examples: Time preferences (avoid 6-7pm), location defaults (virtual vs in-person), verbosity level
-- **Action**: Add to ExecutivePreferences schema OR use existing infrastructure (focus blocks)
-
-**Hybrid Issues:**
-- ✅ Core logic is systemic, but thresholds/preferences differ
-- **Action**: Implement systemic fix with configurable parameters
-
-**Categorization Checklist:**
-- [ ] Identify which category each issue belongs to
-- [ ] Verify categorization makes sense (would this affect all executives?)
-- [ ] Check if existing infrastructure can handle preference needs
-- [ ] Only add new fields after confirming no existing solution
-
-## RULE 3: Leverage Existing Infrastructure
-
-### Before Adding New Preference Fields
-
-**Check if focus blocks can handle it:**
-- Time-based preferences (avoided windows, thresholds) → Use HIGH protection focus blocks
-- Example: "Avoid 6-7pm meetings" → Create focus block with HIGH protection for 6-7pm
-
-**Check if rules can handle it:**
-- Natural language rules may cover edge cases
-- Example: "Prefer in-person for direct reports" → Could use rule with condition
-
-**Only add new fields if:**
-- ❌ No existing infrastructure can handle the use case
-- ✅ The preference is structural (location type, duration defaults)
-- ✅ It needs explicit configuration (not inferable from behavior)
-
-**Infrastructure Check:**
-- [ ] Check `ExecutivePreferences` schema for existing fields
-- [ ] Check if `focus_blocks` can handle time-based preferences
-- [ ] Check if `rules` can handle natural language preferences
-- [ ] Only add new fields after confirming no existing solution
-
-## RULE 4: BAML Prompt Updates
-
-### When Fixing Systemic Issues in BAML
-
-**Add explicit instructions:**
-- Don't rely on implicit understanding
-- Use phrases like "NEVER", "CRITICAL", "MUST NOT"
-- Example: "NEVER generate conference links" not "Don't generate conference links"
-
-**Use multiple locations:**
-- Add rules in all relevant sections
-- Example: Conference link prohibition → LocationGuidelines, EmailResponseGuidelines, CalendarInviteDetails
-
-**Provide examples:**
-- Include both correct ✅ and incorrect ❌ examples
-- Show what NOT to do, not just what to do
-
-**List banned phrases explicitly:**
-- When fixing verbosity/accountability, list specific phrases to avoid
-- Example: "DO NOT say: 'I'll note it for the team', 'I can take responsibility', etc."
-
-**Avoid overfitting:**
-- ❌ Never use specific person names ("Lindy", "Sarah")
-- ✅ Use generic examples ("a person", "someone coordinating")
-- ✅ Use placeholder variables when possible
-
-**BAML Update Checklist:**
-- [ ] No specific person names (generic examples only)
-- [ ] Explicit instructions (NEVER, CRITICAL, MUST NOT)
-- [ ] Multiple relevant sections updated if needed
-- [ ] Banned phrases listed explicitly
-- [ ] Examples provided (correct and incorrect)
-- [ ] Regenerated BAML client (`npm run generate`)
-
-## RULE 5: Iterative Refinement
-
-### For Complex Rule Updates
-
-**Start with core rule:**
-- Add basic rule first
-- Test to see if it works
-
-**Test edge cases:**
-- Identify problematic phrases/behaviors
-- Look for variations of the issue
-
-**Iterate:**
-- Add specific exceptions and banned phrases
-- Refine based on user feedback
-
-**Regenerate and verify:**
-- Always run `npm run generate` after changes
-- Check for lint errors (note pre-existing vs new)
-
-**Refinement Checklist:**
-- [ ] Core rule added
-- [ ] Edge cases identified
-- [ ] Specific exceptions added
-- [ ] BAML client regenerated
-- [ ] Lint errors checked
-
-## RULE 6: Minimal Fixes Strategy
-
-### When Implementing Fixes
-
-**Focus on root cause:**
-- Don't fix symptoms, fix the underlying issue
-- Example: Don't add workarounds, fix the prompt logic
-
-**Smallest change:**
-- Make the minimal change that solves the problem
-- Avoid over-engineering
-
-**Multiple locations if needed:**
-- If issue appears in multiple places, fix all instances
-- Don't partially fix
-
-**Don't over-engineer:**
-- Avoid adding complex logic when simple rule updates work
-- Example: Adding validation code when prompt instruction works
-
-**Minimal Fix Checklist:**
-- [ ] Root cause identified (not just symptom)
-- [ ] Smallest possible change made
-- [ ] All instances fixed if issue appears multiple times
-- [ ] No unnecessary complexity added
-
-## RULE 7: Documentation
-
-### After Analysis
-
-**Create analysis document:**
-- Document findings, patterns, and recommendations
-- Include specific examples from records
-- Link to source data
-
-**Create GitHub issues:**
-- For gaps that can't be fixed immediately (preferences)
-- Include clear recommendations and implementation points
-- Label appropriately (enhancement, area:preferences, etc.)
-
-**Link to analysis:**
-- Reference source documents in issues and code comments
-- Include record IDs for traceability
-
-**Record patterns:**
-- Document patterns for future reference
-- Note what worked and what didn't
-
-**Documentation Checklist:**
-- [ ] Analysis document created with findings
-- [ ] GitHub issues created for preference gaps
-- [ ] Source documents linked
-- [ ] Patterns documented for future reference
-
-## RULE 8: Testing & Validation
-
-### Before Considering Fixes Complete
-
-**Regenerate BAML client:**
-- Always run `npm run generate` after BAML changes
-- Verify generation succeeds
-
-**Check lint errors:**
-- Verify no new errors introduced
-- Note any pre-existing errors (don't fix unrelated issues)
-
-**Verify changes:**
-- Confirm changes are in correct locations
-- Check that all relevant sections updated
-
-**Don't commit prematurely:**
-- User may request multiple iterations
-- Wait for explicit commit instruction
-
-**Testing Checklist:**
-- [ ] BAML client regenerated (`npm run generate`)
-- [ ] Lint errors checked (no new errors)
-- [ ] Changes verified in correct locations
-- [ ] Not committed (wait for user instruction)
-
-## COMMON PATTERNS
-
-### Pattern 1: Time Window Preferences
-**Issue**: "Executive prefers not to have 6-7pm meetings"  
-**Solution**: Use focus blocks with HIGH protection (don't add new field)  
-**Implementation**: Create focus block for 6-7pm with `protection_level: HIGH`
-
-### Pattern 2: Location Defaults
-**Issue**: "Location incorrectly defaulted to virtual when should be in-person"  
-**Solution**: Add `default_meeting_location_type` to ExecutivePreferences  
-**Implementation**: New field in schema, use in BAML when location not specified
-
-### Pattern 3: Accountability Violations
-**Issue**: "Ashley took over coordination when someone else was coordinating"  
-**Solution**: Add explicit rules to respect existing accountability  
-**Implementation**: Update AccountabilityRules template, add banned phrases list
-
-### Pattern 4: Date Interpretation Errors
-**Issue**: "This week included past dates"  
-**Solution**: Add validation rules to never include past dates  
-**Implementation**: Update date interpretation rules in calendar_intent.baml
-
-## ANTI-PATTERNS TO AVOID
-
-1. **❌ Adding new fields when focus blocks work**: Use existing infrastructure first
-2. **❌ Using specific names in prompts**: Always use generic examples
-3. **❌ Fixing symptoms not root causes**: Dig deeper to find underlying issue
-4. **❌ Over-engineering solutions**: Simple prompt updates often work better than complex logic
-5. **❌ Skipping categorization**: Always categorize before fixing
-
-## RELATED RULES
-
-- `get_fraim_file({ path: "rules/successful-debugging-patterns.md" })` - General debugging patterns
-- `get_fraim_file({ path: "rules/code-quality-and-debugging-patterns.md" })` - Code quality standards
-- Read local architecture document (path from `.fraim/config.json` `customizations.architectureDoc`) - Project-specific architecture guidelines
-
-## EXAMPLES
-
-### Good: Systematic Analysis
-```
-1. Query PPE database with proper filters
-2. Identify 18 records with reviewer feedback
-3. Categorize: 7 systemic, 3 preferences
-4. Fix systemic issues in BAML
-5. Create GitHub issue for preferences
-6. Document in retrospective
-```
-
-### Bad: Ad-hoc Fixes
-```
-1. See one issue
-2. Fix it immediately
-3. Don't check for patterns
-4. Don't categorize
-5. Don't document
-```
-
----
-
-**Source**: Derived from retrospective `retrospectives/ppe-hitl-feedback-analysis-debugging-patterns.mdc`  
-**Last Updated**: 2025-11-05