fraim-framework 2.0.27 → 2.0.30

package/registry/workflows/improve-fraim/contribute.md

@@ -0,0 +1,32 @@
+# Workflow: Contribute to FRAIM
+
+**Path:** `workflows/improve-fraim/contribute.md`
+
+---
+
+# Contribute Workflow
+
+## INTENT
+Allows users to contribute new workflow ideas back to the FRAIM project. The agent collects necessary information and files a GitHub issue with the contribution details.
+
+## STEPS
+
+### Step 1: Gather Information
+1. Ask the user for the **Workflow Name**.
+   - Example: "What is the name of the workflow you would like to contribute?"
+2. Ask the user for the **Recommended Prompt** / Description.
+   - Example: "Please provide the recommended prompt or a detailed description of what this workflow should do."
+
+### Step 2: Confirmation
+Confirm the details with the user before proceeding.
+- "I am about to file a contribution for workflow '{workflow_name}' with the following prompt: '{workflow_prompt}'. Is this correct?"
+
+### Step 3: Execute Contribution
+Call the `file_issue` tool with the details gathered.
+
+- `title`: `"[CONTRIBUTION]: {workflow_name}"`
+- `body`: `"{workflow_prompt}"`
+- `labels`: `["enhancement", "workflow"]`
+
+### Step 4: Completion
+Notify the user that the issue has been filed successfully. Summarize the information (title and body) that was filed. Do not provide the issue number or URL.

package/registry/workflows/improve-fraim/file-issue.md

@@ -0,0 +1,32 @@
+# Workflow: File Issue for FRAIM
+
+**Path:** `workflows/improve-fraim/file-issue.md`
+
+---
+
+# File Issue Workflow
+
+## INTENT
+Allows users to easily file bugs or feature requests for the FRAIM framework directly from their working environment.
+
+## STEPS
+
+### Step 1: Gather Information
+1. Ask the user to describe the **Issue** (Bug or Feature Request).
+   - Example: "Please describe the bug you encountered or the feature you would like to request."
+
+### Step 2: Categorization (Optional)
+Ask if this is a **Bug** or a **Feature**.
+- If Bug: Use label `bug`.
+- If Feature: Use label `enhancement`.
+- Default: `triage`.
+
+### Step 3: Execute Issue Filing
+Call the `file_issue` tool with the details gathered.
+
+- `title`: `"[ISSUE]: <Short Summary>"`
+- `body`: `"<Full Description>"`
+- `labels`: `["<bug/enhancement>"]`
+
+### Step 4: Completion
+Notify the user that the issue has been filed successfully. Summarize the information (title and body) that was filed. Do not provide the issue number or URL.

package/registry/workflows/marketing/hbr-article.md

@@ -0,0 +1,73 @@
+# Workflow: hbr-article
+
+**Path:** `workflows/marketing/hbr-article.md`
+
+---
+
+# Harvard Business Review Article Phase
+
+## INTENT
+Design a repeatable reviewable process for researching, drafting, and submitting an HBR or similar thought-leadership article that follows the Harvard Business Review author guidelines and documents each review before publication.
+
+## PRINCIPLES
+- **Strategy First** – Explain why the piece matters to HBR readers and how it advances the product roadmap.
+- **Evidence-Led Storytelling** – Back every claim with customer insights, data, or experiments and include proper citations.
+- **Executive Clarity** – Keep the tone structured, concise, and professional while still being compelling.
+- **Review Discipline** – Require sign-offs during every milestone so the article progresses with confidence.
+
+## HARVARD BUSINESS REVIEW GUIDELINES SUMMARY
+- **Audience & Outcome**: HBR serves ambitious senior leaders with rigorous, evidence-backed insights they can apply today.
+- **Topic Scope**: Strategy, leadership, culture, operations, technology change, innovation, communication, decision-making, talent, and transitions.
+- **Five Quality Criteria**: Expertise, evidence, originality (or a counterintuitive twist), practical usefulness, and excellent writing.
+- **Responsible Storytelling**: Represent diverse organizations, avoid bias/stereotypes, disclose conflicts, and explain any generative AI usage.
+- **Pitch Checklist** (covered during Step 2 and in the template): central message, importance/counterintuition, novelty, leader application, authority/backing, supporting research/examples, and relevant experiences.
+
+## HBR ARTICLE WORKFLOW
+
+### Step 1: Confirm the story belongs with HBR
+- Articulate the insight, the proposed HBR section (Strategy, Leadership, Technology, etc.), and why the timing is right.
+- Cite the HBR guidelines (https://hbr.org/guidelines-for-authors) for exclusivity, word count, bylines, and conflict-of-interest disclosures.
+- Document how the story ties to the product roadmap, clarify the customer problem, and capture any embargo or exclusivity constraints with marketing and executive reviewers.
+
+### Step 2: Research & angle sharpening
+- Gather customer data, experiments, interviews, or telemetry that demonstrate the thesis.
+- Review two recent HBR pieces in the target section to understand structure, tone, and citation style.
+- Identify outstanding sourcing needs (people, metrics, visuals) and schedule them before drafting.
+- Use the HBR prompts to refine the story:
+  - What is the central message of the article?
+  - Why is it important, useful, or counterintuitive?
+  - What is new about the idea?
+  - Why do senior leaders need to know about it today, and how can they apply it?
+  - What is the source of the team’s authority (prior work, credentials, experience)?
+  - What research or examples will back the idea?
+  - What academic, professional, or personal experience will you draw on?
+
+### Step 3: Outline and structure guardrails
+- Draft an outline covering:
+  - Hook and problem framing
+  - Diagnostic/evidence blocks (data, quotes, frameworks)
+  - Practice-ready recommendation and product-specific next steps
+- Annotate each section with required references and attachments.
+- Share the outline with product and marketing reviewers, collect feedback, and incorporate it prior to drafting.
+
+### Step 4: Draft, iterate, and polish
+- Adhere to HBR word limits and formatting expectations; note disclosures, partnerships, or competing interests directly in the draft.
+- Run two review passes: one focused on clarity (peer reviewer) and one on strategic voice (executive reviewer).
+- Track edits through versioned drafts, doc comments, or PR history and finalize the headline/angle with the marketing lead.
+- Capture approvals for accuracy, voice, and compliance before locking the draft.
+
+### Step 5: Finalize submission + collateral
+- Verify the draft satisfies the HBR checklist (tone, length, references, conflicts) and secure the final sign-off.
+- Draft the submission email (subject line, synopsis, attachments) and log it in `docs/marketing/hbr/submission-log.md` or an equivalent tracking document.
+- Plan accompanying collateral (blog post, newsletter snippet, executive update) that repurposes the article's insight and assign owners.
+- Note follow-up steps for publication tracking and audience engagement.
+
+## OUTPUT
+- Thesis/angle memo that explains the fit for HBR.
+- Approved outline and draft with reviewer notes and version history.
+- Submission package (email, attachments, compliance checklist).
+- Launch collateral plan with asset owners and delivery status.
+
+## DOCUMENT TEMPLATE STRUCTURE
+
+Use `get_fraim_file({ path: "templates/marketing/HBR-ARTICLE-TEMPLATE.md" })` to capture the thesis, outline, draft, review log, submission log, and launch collateral plan for each HBR article. 

package/registry/workflows/performance/analyze-performance.md

@@ -1,59 +1,63 @@
-# Performance Analysis Phase
-
-## INTENT
-To diagnose production performance issues (CPU, Memory, Swap) and provide actionable recommendations for stabilization without performing direct application or infrastructure modifications.
-
-## PRINCIPLES
-- **Observational Only**: Do not modify code or infrastructure during this phase.
-- **Data-Driven**: Base all recommendations on metrics collected from the environment.
-- **Non-Invasive**: Use non-destructive commands that do not impact server stability.
-- **Actionable**: Provide clear, prioritized recommendations for remediation.
-
-## ANALYSIS WORKFLOW
-
-### Step 1: Run the Performance Profiler
-Execute the profiling script against the production environment to collect plan-level and process-level metrics.
-// turbo
-```bash
-npx tsx .ai-agents/scripts/performance/profile-server.ts --prod
-```
-
-### Step 2: Inspect Automated Diagnosis
-Review the "Step 4: Automated Diagnosis" section of the output. 
-It will specifically check for:
-- **Swap Death**: If >95% swap is used, the server is thrashing.
-- **Absent Application**: If `server.js` is missing, the infrastructure is healthy but the app is crashed/not starting.
-- **Infrastructure Hogs**: If Azure agents (Kudu/dotnet) are consuming excessive RAM.
-
-### Step 3: Deep Dive Log Analysis
-If a crash loop or high operation frequency is suspected, collect and analyze application logs.
-```bash
-npx tsx .ai-agents/scripts/performance/profile-server.ts --prod --logs
-```
-Look for:
-- Frequency of initialization logs (e.g., "Ensured unique index").
-- Patterns indicative of OOM events or unhandled exceptions.
-- High volume of specific operations (e.g., decryptions) suggesting an infinite loop.
-
-### Step 4: Formulate Recommendations
-Based on the diagnosis, provide specific recommendations in your response or an implementation plan (if a fix is needed in a subsequent phase).
-Examples:
-- **Restart**: If swap usage is high or rogue processes are detected.
-- **Upgrade Plan**: If physical memory is chronically saturated (B1 to P1v3).
-- **Code Optimization**: If log analysis reveals initialization loops or leaks.
-
-## EXAMPLES
-
-### Good Analysis
-> "The profiler shows 98% CPU usage and 'Swap Death'. The logs show 'Ensured unique index' occurring 100 times per minute. I recommend implementing an initialization guard in `PrismaDatabaseService` to break this loop."
-
-### Bad Analysis (Do not do)
-> "I found a loop, so I've updated `server.ts` to fix it." 
-> *Correction: Propose the fix first, do not implement it within the analysis workflow.*
-
-## COMPLETION CHECKLIST
-- [ ] Profiler run successfully on production.
-- [ ] Resource bottlenecks (CPU/Mem/Swap) identified.
-- [ ] Application process stability verified.
-- [ ] Root cause hypothesis formulated based on metrics and logs.
-- [ ] Prioritized recommendations delivered to the user.
+# Performance Analysis Phase
+
+## INTENT
+To diagnose production performance issues (CPU, Memory, Swap) and provide actionable recommendations for stabilization without performing direct application or infrastructure modifications.
+
+## PRINCIPLES
+- **Observational Only**: Do not modify code or infrastructure during this phase.
+- **Data-Driven**: Base all recommendations on metrics collected from the environment.
+- **Non-Invasive**: Use non-destructive commands that do not impact server stability.
+- **Actionable**: Provide clear, prioritized recommendations for remediation.
+
+## ANALYSIS WORKFLOW
+
+### Step 1: Run the Performance Profiler
+Execute the profiling script against the production environment to collect plan-level and process-level metrics.
+// turbo
+```bash
+# 1. Fetch profile-server.ts using get_fraim_file and save to machine temp
+# (Agent implementation detail: use os.tmpdir())
+
+# 2. Run from temp
+npx tsx /path/to/temp/profile-server.ts --prod
+```
+
+### Step 2: Inspect Automated Diagnosis
+Review the "Step 4: Automated Diagnosis" section of the output. 
+It will specifically check for:
+- **Swap Death**: If >95% swap is used, the server is thrashing.
+- **Absent Application**: If `server.js` is missing, the infrastructure is healthy but the app is crashed/not starting.
+- **Infrastructure Hogs**: If Azure agents (Kudu/dotnet) are consuming excessive RAM.
+
+### Step 3: Deep Dive Log Analysis
+If a crash loop or high operation frequency is suspected, collect and analyze application logs.
+```bash
+npx tsx tmp/profile-server.ts --prod --logs
+```
+Look for:
+- Frequency of initialization logs (e.g., "Ensured unique index").
+- Patterns indicative of OOM events or unhandled exceptions.
+- High volume of specific operations (e.g., decryptions) suggesting an infinite loop.
+
+### Step 4: Formulate Recommendations
+Based on the diagnosis, provide specific recommendations in your response or an implementation plan (if a fix is needed in a subsequent phase).
+Examples:
+- **Restart**: If swap usage is high or rogue processes are detected.
+- **Upgrade Plan**: If physical memory is chronically saturated (B1 to P1v3).
+- **Code Optimization**: If log analysis reveals initialization loops or leaks.
+
+## EXAMPLES
+
+### Good Analysis
+> "The profiler shows 98% CPU usage and 'Swap Death'. The logs show 'Ensured unique index' occurring 100 times per minute. I recommend implementing an initialization guard in `PrismaDatabaseService` to break this loop."
+
+### Bad Analysis (Do not do)
+> "I found a loop, so I've updated `server.ts` to fix it." 
+> *Correction: Propose the fix first, do not implement it within the analysis workflow.*
+
+## COMPLETION CHECKLIST
+- [ ] Profiler run successfully on production.
+- [ ] Resource bottlenecks (CPU/Mem/Swap) identified.
+- [ ] Application process stability verified.
+- [ ] Root cause hypothesis formulated based on metrics and logs.
+- [ ] Prioritized recommendations delivered to the user.

package/registry/workflows/product-building/design.md

@@ -10,13 +10,14 @@
 To create comprehensive, detailed technical design documents that plan solutions before implementation, ensuring proper architecture, clear requirements, and stakeholder alignment through structured RFCs and bug fix templates.
  
 ## PRINCIPLES
+- **Success Criteria**: Optimize for Integrity, Correctness, Completeness, Independence, and Speed - see `rules/agent-success-criteria.md` (fetch via `get_fraim_file`).
 - **Design First**: Plan before implementing to avoid rework
 - **Template Consistency**: Use established templates for different types of changes
 - **Stakeholder Alignment**: Get review and approval before implementation
 - **Clear Documentation**: Create detailed, actionable design documents
 - **Iterative Refinement**: Incorporate feedback and iterate on designs
-- **Spike-First Development**: Follow "Spike-First Development" rule (retrieve via `get_fraim_file({ path: "rules/spike-first-development.md" })`) to validate technology compatibility before building complex solutions
-- **Simplicity**: Follow "Simplicity" principle (retrieve via `get_fraim_file({ path: "rules/simplicity.md" })`)
+- **Spike-First Development**: Follow "Spike-First Development" rule (read `rules/spike-first-development.md` using `get_fraim_file`) to validate technology compatibility before building complex solutions
+- **Simplicity**: Follow "Simplicity" principle (read `rules/simplicity.md` using `get_fraim_file`)
 - **Architecture**: Follow existing architecture - see `.fraim/config.json` for the path (`customizations.architectureDoc`)
  
 ## DESIGN WORKFLOW

package/registry/workflows/product-building/implement.md

@@ -11,14 +11,15 @@ To implement solutions based on approved design documents, ensuring minimal, tes
 Consult the architecture document for coding standards. 
 
 ## PRINCIPLES
+- **Success Criteria**: Optimize for Integrity (100pts), Correctness (50pts), Completeness (30pts), Independence (20pts), and Speed (10pts) - see `rules/agent-success-criteria.md` (fetch via `get_fraim_file`).
 - **Design-Driven**: Follow approved RFCs and design documents
 - **Minimal Implementation**: Write only the code needed for the issue
 - **Test-First**: Ensure comprehensive test coverage
 - **Quality Focus**: Maintain code quality and follow patterns
 - **Complete**: All aspects of technical spec are implemented, tested, validated
-- **Spike-First Development**: Follow "Spike-First Development" rule (retrieve via `get_fraim_file({ path: "rules/spike-first-development.md" })`) to validate technology compatibility before building complex solutions
-- **Debugging**: Use "Successful Debugging Patterns" (retrieve via `get_fraim_file({ path: "rules/successful-debugging-patterns.md" })`) when stuck
-- **Git Safety**: Follow "Git Safe Commands" (retrieve via `get_fraim_file({ path: "rules/git-safe-commands.md" })`)
+- **Spike-First Development**: Follow "Spike-First Development" rule (read `rules/spike-first-development.md` via `get_fraim_file`) to validate technology compatibility before building complex solutions
+- **Debugging**: Use "Successful Debugging Patterns" (read `rules/successful-debugging-patterns.md` via `get_fraim_file`) when stuck
+- **Git Safety**: Follow "Git Safe Commands" (read `rules/git-safe-commands.md` via `get_fraim_file`)
 - **Architecture**: Follow existing architecture - see `.fraim/config.json` for the path (`customizations.architectureDoc`)
  
 ## IMPLEMENTATION WORKFLOW

package/registry/workflows/product-building/prep-issue.md

@@ -9,36 +9,47 @@ This workflow prepares the local development environment for working on a specif
 
 ## Action Items
 
-1.  **Fetch the Preparation Script**:
-    `ACTION: Call get_fraim_file({ path: "scripts/prep-issue.sh" })`
+1.  **Execute Preparation Script**:
+    Fetch and run cleanup/setup scripts ephemerally.
+
+    ```javascript
+    // 1. Fetch script
+    const script = await get_fraim_file({ path: "scripts/prep-issue.sh" });
+    
+    // 2. Save to machine temp
+    const os = require('os');
+    const path = require('path');
+    const fs = require('fs');
+    const fraimTmp = path.join(os.homedir(), '.fraim', 'tmp');
+    if (!fs.existsSync(fraimTmp)) fs.mkdirSync(fraimTmp, { recursive: true });
+    const tempPath = path.join(fraimTmp, 'prep-issue.sh');
+    fs.writeFileSync(tempPath, script);
+    
+    // 3. Make executable (if needed) and run
+    await run_command({ command: `bash ${tempPath} ${issueNumber}` });
+    ```
 
-2.  **Execute Ephemerally**:
-    You MUST execute the script according to the "Ephemeral Execution" rule (retrieve via `get_fraim_file({ path: "rules/ephemeral-execution.md" })`).
-
-    > [!IMPORTANT]
-    > Do NOT save this script to the project repository. Save it to your system's temp folder.
 
 3.  **Verify Setup**:
     - **Clean Context**: Start fresh to avoid pollution
-    - **Environment**: Follow "Local Development" guidelines (retrieve via `get_fraim_file({ path: "rules/local-development.md" })`).
+    - **Environment**: Follow "Local Development" guidelines (read `rules/local-development.md` using `get_fraim_file`).
     - [ ] Feature branch created and pushed to origin.
     - [ ] `npm install` completed.
     - [ ] Serena indexing completed (if applicable).
 
 ## Implementation Detail (Agent Guidance)
 
-When you receive the script content from `get_fraim_file`:
-
+Execute:
 ```javascript
-// 1. Save to temp file
-const tempPath = path.join(os.tmpdir(), "prep-issue.sh");
+const scriptContent = await get_fraim_file({ path: "scripts/prep-issue.sh" });
+const os = require('os');
+const path = require('path');
+const fs = require('fs');
+const fraimTmp = path.join(os.homedir(), '.fraim', 'tmp');
+if (!fs.existsSync(fraimTmp)) fs.mkdirSync(fraimTmp, { recursive: true });
+const tempPath = path.join(fraimTmp, 'prep-issue.sh');
 fs.writeFileSync(tempPath, scriptContent);
-
-// 2. Execute
 await run_command({ command: `bash ${tempPath} ${issueNumber}` });
-
-// 3. Cleanup
-fs.unlinkSync(tempPath);
 ```
 
 > [!NOTE]

package/registry/workflows/product-building/resolve.md

@@ -10,15 +10,16 @@
 To provide a systematic approach to resolving issues from development through merge verification and cleanup, ensuring no work is lost and all changes are properly integrated into the main codebase.
  
 ## PRINCIPLES
+- **Success Criteria**: Optimize for Integrity (Verify truthfully) and Completeness (Clean up fully) - see `rules/agent-success-criteria.md` (fetch via `get_fraim_file`).
 - **Verification First**: Always verify merges before closing issues
 - **Complete Cleanup**: Remove all traces of feature branches
 - **No Work Loss**: Prevent incidents like Issue #112 through proper verification
 - **Systematic Process**: Follow established steps in order
 - **Evidence-Based**: Provide concrete verification of completion
-- **Git Safety**: Follow "Git Safe Commands" (retrieve via `get_fraim_file({ path: "rules/git-safe-commands.md" })`)
+- **Git Safety**: Follow "Git Safe Commands" (read `rules/git-safe-commands.md` using `get_fraim_file`)
 
 ## CRITICAL DEPENDENCY
-**This workflow MUST be used in conjunction with "Merge Requirements" rule** (retrieve via `get_fraim_file({ path: "rules/merge-requirements.md" })`) which contains:
+**This workflow MUST be used in conjunction with "Merge Requirements" rule** (read `rules/merge-requirements.md` via `get_fraim_file`) which contains:
 - **Pre-Push Workflow** (for feature branches during development)
 - **PR Description Template** (for PR creation)
 - **Final Merge Process** (for merging to master - used in this workflow)

package/registry/workflows/product-building/retrospect.md

@@ -4,12 +4,13 @@
 To capture learnings and insights from completed issues, enabling continuous improvement and preventing future similar problems through systematic analysis and documentation.
 
 ## PRINCIPLES
+- **Success Criteria**: Focus on Integrity (Self-reflection) and Independence (Learning from mistakes) - see `rules/agent-success-criteria.md` (fetch via `get_fraim_file`).
 - Every completed issue requires a retrospective
 - Focus on root causes, not just symptoms
 - Document both successes and failures
 - Create actionable prevention measures
 - Share learnings with other agents
-- Continuous Learning: Follow "Continuous Learning" principles (retrieve via `get_fraim_file({ path: "rules/continuous-learning.md" })`)
+- Continuous Learning: Follow "Continuous Learning" principles (read `rules/continuous-learning.md` via `get_fraim_file`)
 
 ## WORKFLOW
 
@@ -30,7 +31,7 @@ To capture learnings and insights from completed issues, enabling continuous imp
 
 ### 1. Create Retrospective File
 - **File path**: `retrospectives/issue-{issue-number}-{kebab-title}-postmortem.md`
-- **Template**: Use Retrospective template (retrieve via `get_fraim_file({ path: "templates/retrospective/RETROSPECTIVE-TEMPLATE.md" })`) as the base
+- **Template**: Use Retrospective template: `get_fraim_file({ path: "templates/retrospective/RETROSPECTIVE-TEMPLATE.md" })`
 - **Copy template**: Copy the template file and fill in the placeholders
 
 ### 2. Root Cause Analysis

package/registry/workflows/product-building/spec.md

@@ -10,10 +10,11 @@
 To create comprehensive, detailed product specifications that clarify the Why, What and User Experiences for new features.
 
 ## PRINCIPLES
+- **Success Criteria**: Optimize for Integrity, Correctness, Completeness, Independence, and Speed - see `rules/agent-success-criteria.md` (fetch via `get_fraim_file`).
 - **Start with the User**: Understand the user's needs and experiences before implementing
 - **User Experience Matters**: Focus on creating a great user experience right from the beginning
 - **Validation Criteria**: Define clear validation criteria to ensure the feature meets user needs
-- **Simplicity**: Maintain simplicity in feature definition (retrieve via `get_fraim_file({ path: "rules/simplicity.md" })`)
+- **Simplicity**: Maintain simplicity in feature definition (read `rules/simplicity.md` via `get_fraim_file`)
 
 ## SPECIFICATION WORKFLOW
 
@@ -40,7 +41,7 @@ You are already in the correct workspace prepared by the user. Confirm you're on
 Before creating any specification document, agents MUST:
 
 1. **Verify Template Selection**:
-   - Use Feature Spec template (retrieve via `get_fraim_file({ path: "templates/specs/FEATURESPEC-TEMPLATE.md" })`)
+   - Use Feature Spec template: `get_fraim_file({ path: "templates/specs/FEATURESPEC-TEMPLATE.md" })`
    
 2. **Validate Naming Convention**:
    - Format: `docs/feature specs/{issue_number}-{kebab-title}.md`
@@ -79,8 +80,8 @@ Before committing your work, verify:
 ### Step 8: Submit for Review
 - Commit and sync your work
 - Label the issue 'status:needs-review' and remove 'status:wip'
-- Update the PR with a comment to include evidence - Use Spec Evidence template (retrieve via `get_fraim_file({ path: "templates/evidence/Spec-Evidence.md" })`)
-- **Next Step**: Switch to "Iterate on PR Comments" workflow (retrieve via `get_fraim_file({ path: "workflows/product-building/iterate-on-pr-comments.md" })`) to monitor actions and handle feedback.
+- Update the PR with a comment to include evidence - Use Spec Evidence template: `get_fraim_file({ path: "templates/evidence/Spec-Evidence.md" })`
+- **Next Step**: Switch to "Iterate on PR Comments" workflow: `get_fraim_file({ path: "workflows/product-building/iterate-on-pr-comments.md" })`
 
 ### Step 9: Iteration
 If workflow actions or reviewer feedback indicates more work is needed:

package/registry/workflows/product-building/test.md

@@ -10,13 +10,14 @@
 To create comprehensive test coverage that accurately reproduces issues and validates solutions, ensuring robust testing through proper test structure, failure verification, and systematic test execution.
  
 ## PRINCIPLES
+- **Success Criteria**: Optimize for Integrity (Honest reporting), Correctness (Coverage), Completeness, Independence, and Speed - see `rules/agent-success-criteria.md` (fetch via `get_fraim_file`).
 - **Test-Driven**: Write tests that reproduce the issue before fixing
 - **Comprehensive Coverage**: Ensure all scenarios are tested
 - **Failure Verification**: Confirm tests fail before implementation
 - **Proper Structure**: Use established test patterns and frameworks
 - **Systematic Execution**: Follow consistent testing procedures
-- **Testing Guidelines**: Follow "Agent Testing Guidelines" (retrieve via `get_fraim_file({ path: "rules/agent-testing-guidelines.md" })`)
-- **Integrity**: Adhere to "Integrity and Test Ethics" (retrieve via `get_fraim_file({ path: "rules/integrity-and-test-ethics.md" })`)
+- **Testing Guidelines**: Follow "Agent Testing Guidelines" (read `rules/agent-testing-guidelines.md` via `get_fraim_file`)
+- **Integrity**: Adhere to "Integrity and Test Ethics" (read `rules/integrity-and-test-ethics.md` via `get_fraim_file`)
 - **Architecture**: Follow existing architecture - see `.fraim/config.json` for the path (`customizations.architectureDoc`)
 
 ## TESTING WORKFLOW