fraim-framework 1.0.11 → 2.0.1

package/test-utils.ts

@@ -0,0 +1,118 @@
+import dotenv from 'dotenv';
+dotenv.config({override:true});
+
+import { test } from 'node:test';
+
+
+// Base test case interface that all test cases should extend
+export interface BaseTestCase {
+  name: string;
+  description?: string;
+  tags?: string[];
+  testFn?: () => Promise<boolean>;
+}
+
+// Global tracker for failed tests across all suites
+const globalFailedTests: string[] = [];
+
+// Generic test runner function that can run any type of test
+
+export async function runTests<T extends BaseTestCase>(
+  testCases: T[],
+  runTestFn: (testCase: T) => Promise<boolean>,
+  testTitle: string
+): Promise<void> {
+  console.log(`🧪 Testing ${testTitle}...\n`);
+  
+  // Check if we need to filter by tags
+  let tagsFilter: string[] = [];
+  
+  console.log(`Command line arguments: ${process.argv.join(', ')}`);
+  
+  // First try command line arguments
+  const tagsArg = process.argv.find(arg => arg && typeof arg === 'string' && arg.startsWith('--tags='));
+  if (tagsArg) {
+    const tagValue = tagsArg.split('=')[1];
+    if (tagValue) {
+      tagsFilter = tagValue.split(',');
+      console.log(`Filtering tests by tags (from CLI): ${tagsFilter.join(', ')}`);
+    }
+  }
+  
+  // Then try environment variable (for npm scripts)
+  if (tagsFilter.length === 0 && process.env.TAGS) {
+    tagsFilter = process.env.TAGS.split(',');
+    console.log(`Filtering tests by tags (from ENV): ${tagsFilter.join(', ')}`);
+  }
+  
+  // Check for exclusion tags
+  let excludeTags: string[] = [];
+  if (process.env.EXCLUDE_TAGS) {
+    excludeTags = process.env.EXCLUDE_TAGS.split(',');
+    console.log(`Excluding tests with tags (from ENV): ${excludeTags.join(', ')}`);
+  }
+  
+  // Filter test cases by tags if specified
+  const testsToRun = testCases.filter(test => {
+    // First check inclusion filter
+    if (tagsFilter.length > 0) {
+      // Ensure test.tags exists before calling .some() on it
+      if (!test.tags || !test.tags.some(tag => tagsFilter.includes(tag))) {
+        return false;
+      }
+    }
+    
+    // Then check exclusion filter
+    if (excludeTags.length > 0) {
+      // Exclude tests with specified tags
+      if (test.tags && test.tags.some(tag => excludeTags.includes(tag))) {
+        return false;
+      }
+    }
+    
+    return true;
+  });
+  
+  if (testsToRun.length === 0) {
+    console.log('No tests to run for suite: ' + testTitle);
+    return;
+  }
+
+  console.log(`Running ${testsToRun.length} tests${tagsFilter.length > 0 ? ` with tags: ${tagsFilter.join(', ')}` : ''}\n`);
+  
+  // Use Node.js built-in test() function for each test case
+  // This allows the TAP reporter to properly aggregate results across all test files
+  for (const testCase of testsToRun) {
+    await test(testCase.name, async () => {
+      try {
+        const success = await runTestFn(testCase);
+        if (!success) {
+          const failedTestName = `${testTitle}: ${testCase.name}`;
+          if (!globalFailedTests.includes(failedTestName)) {
+            globalFailedTests.push(failedTestName);
+          }
+          throw new Error(`Test failed: ${testCase.name}`);
+        }
+      } catch (error) {
+        const failedTestName = `${testTitle}: ${testCase.name}`;
+        if (!globalFailedTests.includes(failedTestName)) {
+          globalFailedTests.push(failedTestName);
+        }
+        throw error;
+      }
+    });
+  }
+
+  // Display comprehensive final summary
+  console.log(`\n🚨 FINAL TEST SUMMARY:`);
+  console.log(`   ❌ Total Failed Tests: ${globalFailedTests.length}`);
+  
+  if (globalFailedTests.length > 0) {
+    console.log(`   📋 Failed Test Names:`);
+    globalFailedTests.forEach(testName => {
+      console.log(`   - ${testName}`);
+    });
+  }
+
+  process.exit(globalFailedTests.length > 0 ? 1 : 0);
+}

package/tsconfig.json

@@ -0,0 +1,22 @@
+{
+  "compilerOptions": {
+    "target": "es2021",
+    "module": "commonjs",
+    "lib": ["es2021"],
+    "outDir": "./dist",
+    "rootDir": "./",
+    "strict": true,
+    "esModuleInterop": true,
+    "skipLibCheck": true,
+    "forceConsistentCasingInFileNames": true
+  },
+  "include": [
+    "src/**/*.ts",
+    "test/**/*.ts",
+    "test-runner.ts",
+    "test-utils.ts"
+  ],
+  "exclude": [
+    "node_modules"
+  ]
+}

package/agents/claude/CLAUDE.md

@@ -1,42 +0,0 @@
-# Claude Code Configuration for Ashley Calendar AI
-
-## Always-On Rules
-The following rules from `.cursor/rules/` should ALWAYS be followed by Claude Code instances:
-
-- **architecture.mdc** - Core architecture principles (BAML for LLM tasks, TypeScript for deterministic logic)
-- **continuous-learning.mdc** - Always review retrospectives and RFCs before starting work
-- **cursor-workflow.mdc** - Standard Claude Code development workflow
-- **local-development.mdc** - Local development guidelines and tool usage
-- **resolve.mdc** - Issue resolution process
-- **software-development-lifecycle.mdc** - Complete SDLC process
-
-## Phase-Specific Rules (Manual Trigger Only)
-These rules should only be applied when explicitly requested:
-
-- **prep.md** - Apply when user says "prep issue" or similar
-- **design.md** - Apply when user says "design phase" or similar
-- **implement.md** - Apply when user says "implementation phase" or similar  
-- **test.md** - Apply when user says "test phase" or similar
-
-## Key Behavioral Requirements
-1. **Never commit** unless explicitly asked
-2. **Use TodoWrite** tool for all multi-step tasks
-3. **Review retrospectives** before starting similar work
-4. **Follow architecture principles** - BAML for natural language, TypeScript for deterministic logic
-5. **Verify working directory** before file operations
-6. **Promise to follow these rules** when asked
-
-## Project Structure Awareness
-- BAML sources: `/baml_src/**/*.baml`
-- Generated client: `/baml_client/**`
-- Deterministic logic: `/src/**`
-- Design docs: `/docs/rfcs/*.md`
-- Retrospectives: `/retrospectives/`
-- Scripts: `/scripts/`
-
-## Tool Usage Guidelines
-- Use Read, Edit, Write tools for file operations
-- Use Grep, Glob for searching
-- Use Bash for commands and tests
-- Use TodoWrite for progress tracking
-- Always verify working directory before file operations

package/agents/cursor/rules/architecture.mdc

@@ -1,49 +0,0 @@
----
-description: Architecture principles and guidelines
-alwaysApply: true
----
-
-# Architecture
-
-## Intent
-Keep the architecture clean: use BAML (LLM) for any natural-language understanding, fuzzy matching, or semantic comparison. Use deterministic TypeScript only for side-effectful or strictly rule-based work (APIs, DB, validation, formatting, scheduling, retries).
-
-## Principles (follow in this order)
-1. Parse (LLM/BAML) → 2. Normalize (deterministic) → 3. Validate (deterministic) → 4. Decide (LLM if subjective; code if rules) → 5. Act (deterministic side effects)
-
-## LLM/BAML Usage
-- Entity/intent extraction, timezone/place inference, date/time range interpretation
-- Participant role classification, preference inference, text similarity
-- De-dupe by meaning, natural language understanding
-
-## Deterministic TypeScript Usage
-- ISO date math, schema validation, authZ/authN, idempotency keys
-- OpenAPI I/O, DB writes, calendar invites, retries/timeouts
-- Metrics/telemetry, side effects
-
-## Do / Don't
-
-### Do (LLM/BAML)
-- NLP; Anything that needs understanding from user unstructured input
-
-### Do (Deterministic TS)
-- Ensure structure through interfaces, folder management, test cases
-
-### Don't
-- Don't hand-roll regex/heuristics for dates/locations/intent
-- Don't duplicate LLM functionality
-- Don't call BAML for pure formatting (e.g., toISOString, trimming)
-
-## Project Structure
-- **BAML sources**: `/baml_src/**/*.baml`
-- **Generated client**: `/baml_client/**` (run `baml-cli generate`)
-- **Deterministic logic**: `/src/**`
-- **Design docs + Test plans**: `/docs/rfcs/*.md`
-- **Random utility scripts**: `/scripts` 
-- **Test cases**: `/` (at root level, these are the most important artifacts)
-
-## Local Development Notes
-- Test deterministic logic with unit tests before integrating with LLM components
-- Write test cases for each change. Tag representative ones with 'smoke'
-- Keep architecture boundaries clear between LLM and deterministic code
-- Document any architectural decisions in your RFC or implementation notes

package/agents/cursor/rules/continuous-learning.mdc

@@ -1,48 +0,0 @@
----
-description: Continuous learning from retrospectives and past work
-alwaysApply: true
----
-
-# Continuous Learning
-
-## Retrospectives Review
-- **Always review** the `/retrospectives/` folder before starting work on similar issues
-- **Learn from past problems** - understand root cause analysis and lessons learned
-- **Apply previous solutions** - don't repeat mistakes that have already been solved
-
-## Knowledge Integration
-- **Read related RFCs** in `/docs/rfcs/` to understand design decisions
-- **Review test cases** to see how similar problems were approached
-- **Check issue history** for patterns in failures and solutions
-
-## Local Development Benefits
-- **Avoid known pitfalls** by learning from retrospectives
-- **Build on existing solutions** rather than starting from scratch
-- **Understand system constraints** from past architectural decisions
-
-## Before Starting 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
-
-## Document Your Learning
-- **Update retrospectives** if you discover new insights
-- **Add to RFCs** if you find better approaches
-- **Share solutions** with other agents through issue comments
-
-## Retrospective Triggers
-
-### **Automatic Retrospective Requirements**
-- **Complex Issues (>3 iterations)**: Must create retrospective before issue closure
-- **Process Violations**: Any workflow rule violations require retrospectives
-- **Work Loss Incidents**: Any incidents where work is lost require detailed retrospectives
-
-### **Retrospective Creation Process**
-1. **Stop Current Work**: Pause issue resolution if retrospective is required
-2. **Create Retrospective**: Use standard template in retrospectives folder
-3. **Root Cause Analysis**: Identify underlying causes, not just symptoms
-4. **Prevention Measures**: Document specific actions to prevent recurrence
-5. **Process Updates**: Update rules and workflows based on learnings
-
-Remember: The best code is often written by those who learn from history rather than repeat it.

package/agents/cursor/rules/cursor-workflow.mdc

@@ -1,29 +0,0 @@
----
-description: Cursor development workflow and output guidelines
-alwaysApply: true
----
-
-# Cursor Development Workflow
-
-## Goal
-Work efficiently in local environment while maintaining coordination with remote repository and other agents.
-
-## Behavior
-- Use local file system for development work
-- ***NEVER*** commit unless asked to do so
-- Produce 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)
-
-## Stop Criteria
-- When the assigned work is complete
-- When tests pass and PR is ready for review
-- When waiting for reviewer feedback
-
-## Output Template
-- Summary:
-  - Local progress: [what you accomplished locally]
-  - Remote status: [branch/PR status]

package/agents/cursor/rules/design.mdc

@@ -1,25 +0,0 @@
----
-description: Start designing the solution
-alwaysApply: false
----
-Step 1: Ask for {issue_number} (and optional {slug})
-
-Step 2: Label the issue 'phase:design' (GitHub Action will automatically create a branch, label the issue `status:wip`, create a draft PR)
-
-Step 3: Using GitHub MCP, wait for the branch to get created, then do a checkout to start your work.
-
-*** IMPORTANT IF YOU ARE WORKING LOCALLY **** switch into your branch and ensure you work in your own folder. 
-
-Step 4: Do your work either remotely or locally as defined by the user. If unsure, ask the user. Once sure, let the user know.
-
-Step 5: Your work entails the following
-
- - Create docs/rfcs/{issue_number}-{slug}.md.  
-
- - If the issue requires a small fix or bug fix, use this template - docs/rfcs/BUG-TEMPLATE.md 
-
- - If the issue requires major changes, use this template - docs/rfcs/RFC-TEMPLATE.md 
-
- - When ready for review, flip issue to 'status:needs-review' and remove 'status:wip'
-
-Step 6: If workflow actions or reviewer feedback indicates more work is needed, ensure the issue is set back to `status:wip` and continue working as above.

package/agents/cursor/rules/implement.mdc

@@ -1,26 +0,0 @@
----
-description: Start implementing the solution
-alwaysApply: false
----
-Step 1: Ask for {issue_number} (and optional {slug}); confirm target branch feature/{issue_number}-{slug}.
-
-Step 2: Ensure the branch exists (your GitHub Action will usually auto-create it) and checkout it. 
-
-Step 3: Label the issue 'phase:impl'. (GitHub Action will automatically label the issue `status:wip`, create a draft PR)
-
-Step 4: Do your work either remotely or locally as defined by the user. If unsure, ask the user. Once sure, let the user know.
-
-Step 5: Your work entails the following
-
- - Review the RFC associated with this issue.
-
- - Determine whether changes need to be made to existing code, or brand new code needs to be written.
-
- - Write the minimal set of code and test cases needed for this issue.
-
- - **Test cases must inherit from test-utils and follow the structure of the rest of the test suite**
- - Ensure test cases pass.
-
- - When ready for review, flip issue to 'status:needs-review' and remove 'status:wip'
-
-Step 6: If workflow actions or reviewer feedback indicates more work is needed, ensure the issue is set back to `status:wip` and continue working as above.

package/agents/cursor/rules/local-development.mdc

@@ -1,104 +0,0 @@
----
-description: Local development with remote coordination guidelines
-alwaysApply: true
----
-
-# Local Development with Remote Coordination
-
-- Use local file system for development work in your own cloned repository folder
-- Push to feature branches only; never push to master
-- Do NOT open PRs; push and let Actions open/update Draft PRs
-- Always work in your own cloned repository folder: `git clone <repo> "<repo> - Issue {issue_number}"`
-- After you create the clone, do not forget to change into that working directory. All your work **MUST** be in your working directory.
-- Coordinate with other agents through GitHub issues and PRs
-- Each agent works independently in their own folder to enable true parallel development
-
-## CRITICAL RULE: Absolute Workspace Separation
-
-### Local Clone: WORK-ONLY  
-- **Directory**: `<repo> - Issue <issue number>`
-- **Purpose**: All development work happens here exclusively
-- **Rule**: ALL file operations must be within this directory
-
-## Mandatory Pre-File-Operation Checklist
-
-**Before ANY file operation (edit_file, delete_file, etc.), verify:**
-
-1. ✅ **Directory Check**: `pwd` shows local clone with issue number in path
-2. ✅ **Path Verification**: File path is relative (no "../" or main workspace name)  
-3. ✅ **Branch Check**: `git branch` shows correct feature branch
-4. ❌ **If ANY check fails**: STOP immediately and fix location
-
-**This checklist is MANDATORY, not optional.**
-
-
-## Enhanced Stop Conditions
-
-**Stop ALL work immediately if:**
-- You create a file and it appears in main workspace
-- You use edit_file with "../" paths
-- You work in directory without issue number in name  
-- `pwd` shows main workspace path
-- Any file operation targets main workspace
-
-**Take corrective action before continuing.**
-
-## Workspace Validation Commands
-
-**Before starting work, run:**
-```bash
-echo "Working in: $(pwd)"
-echo "Should contain issue number in path"
-git branch
-echo "Should show feature branch"
-```
-
-**If output doesn't match expectations, fix before proceeding.**
-
-## Tool Usage Restrictions
-
-### File Operations - Local Only
-- `edit_file()` - ONLY with relative paths in local repo
-- `delete_file()` - ONLY within local repo
-- `search_replace()` - ONLY on local repo files
-
-### Reference Operations - Main Workspace OK  
-- `read_file()` - OK to read from main workspace for reference
-- `list_dir()` - OK to explore main workspace structure
-- `grep()` - OK to search main workspace for patterns
-
-## Violation Recovery Process
-
-**If you violate workspace boundaries:**
-
-1. **Stop immediately** - Do not continue file operations
-2. **Assess damage** - Check what was created in wrong location  
-3. **Clean up** - Delete files created in main workspace
-4. **Recreate correctly** - Recreate files in local repo only
-5. **Document violation** - Update post-mortem with details
-
-
-## Enhanced Output Template
-
-```
-Summary:
-  - Work completed in local repository: [path]
-  - Files created/modified: [list with relative paths]
-  - Workspace violations: [none/details if any occurred]
-
-Artifacts:
-  - Branch: [URL]
-  - Local directory: [full path to local clone]
-```
-
-## Emergency Safeguards
-
-**If assistant shows signs of workspace confusion:**
-- User should immediately clarify working directory
-- Assistant should run `pwd` and verify location
-- All file operations should pause until location confirmed
-- Assistant should explicitly state file paths being used
-
----
-
-**Bottom Line**: The local development workflow requires absolute discipline about workspace boundaries. 

package/agents/cursor/rules/prep.mdc

@@ -1,15 +0,0 @@
-Step 1: Ask for {issue_number}
-
-Step 2: Clone the repo to "<repo> - Issue {issue_number}" 
-- **CRITICAL**: Clone ONE LEVEL ABOVE the current workspace directory
-- **DO NOT** clone inside the current workspace folder
-- **VERIFY LOCATION**: Use `pwd` to confirm you're in the parent directory before cloning
-
-Step 3: Confirm items in the checklist and say "Huzzah!"
-
-
-## Safety Checklist
-- [ ] Confirmed current workspace path with `pwd`
-- [ ] Changed to parent directory (`cd ..`) before cloning
-- [ ] Verified clone location is outside current workspace
-- [ ] Successfully changed into cloned repository

package/agents/cursor/rules/resolve.mdc

@@ -1,46 +0,0 @@
----
-description: Start resolution workflow
-alwaysApply: false
----
-Ensure branch: feature/{issue}-{slug} is checked out (create if needed).
-
-Commit & push any pending changes.
-
-Sync from origin/master into this branch (merge or rebase), resolve conflicts, push again.
-
-Check the results of GitHub Action that runs the full tests in the cloud.
-
-If they pass: open/update the Implementation PR, label it, and enable auto-merge.
-
-If they fail: no PR is opened/updated; fix, push again, repeat.
-
-Once PR is approved and related actions succeed, do the following: 
-- **MANDATORY**: Verify PR is actually merged to master before proceeding
-- **MANDATORY**: Run merge verification checks (see below)
-- Close the issue ONLY after merge verification passes
-- Delete the branch remotely.
-- If operating locally, delete the local branch and the local codebase.
-- Say Hoorah !
-
-## Mandatory Merge Verification
-
-**Before closing ANY issue, verify the following:**
-
-1. ✅ **PR Status**: PR shows "merged" status, not just "closed"
-2. ✅ **Merge Commit**: Verify merge commit exists in master
-3. ✅ **Files in Master**: Confirm expected files are present in master
-
-### **Verification Commands**
-```bash
-# Check PR is merged, not just closed
-gh pr view <PR_NUMBER> --json merged
-
-# Verify merge commit in master
-git fetch origin master
-git log origin/master --oneline | grep "PR #<PR_NUMBER>"
-
-# Verify files in master
-git show origin/master:path/to/expected/file
-```
-
-**CRITICAL**: Do not close the issue until merge verification passes. This prevents work loss incidents.

package/agents/cursor/rules/simplicity.mdc

@@ -1,18 +0,0 @@
----
-description:
-globs:
-alwaysApply: true
----
-
-****Keep it simple. Don't over-engineer. *****
-Don't over-think it. 
-While fixing an issue, focus on that issue only. Don't fix other issues. Don't make unrelated changes. Instead, file a Git issue if you find other issues that aren't already tracked by an existing Git issue.
-
-
-Always verify the action you have taken. Do not expect the user to verify it for you. 
-If you kicked off a Git workflow, verify it completed successfully (e.g., gh checks: list or PR status).
-If you wrote a test and expect it to pass, run it yourself and verify it passes; if you expect it to fail, verify it fails.
-Always link work to the issue (use “Closes #<n>” in the Implementation PR).
-Open Draft PRs early; review happens in the PR, not in chat.
-
-Agents must not run gh pr create. Push to the feature branch and let Actions open Draft PRs.

package/agents/cursor/rules/software-development-lifecycle.mdc

@@ -1,41 +0,0 @@
----
-description: Issue resolution process for local development with branch/clone approach
-alwaysApply: true
----
-
-# Issue Resolution Process
-
-Always work on the feature branch for the current issue: `feature/<issue#>-<kebab-title>`. Never push to master.
-
-## Development Workflow
-1. **Clone Setup**: Work in your own cloned repository folder.
-2. **Branch Management**: Create/checkout feature branch for your issue
-3. **Local Development**: Make changes, run tests locally
-4. **Check before commit**: Only commit after approval from the user.
-5. **Remote Coordination**: Use GitHub MCP for issue labels
-
-## Phases
-- **Design**: Set ISSUE to `phase:design` → create RFC
-- **Implementation**: Set ISSUE to `phase:impl` → implement solution
-
-## Status Management
-- **WIP**: Automatically set when entering new phase
-- **Needs Review**: Set this when work is ready for review
-- **Complete**: Automatically set when PR is approved
-
-## PR Requirements
-- Implementation PR body MUST include `Closes #<n>`
-- Let Actions handle PR creation and updates
-- Address all reviewer feedback before completion
-
-## Cleanup
-When user confirms code is correctly merged into master, confirm with the user, then 
-- delete remote branch
-- delete local branch
-- remove your local clone folder:
-```
-cd ..
-Remove-Item -Recurse -Force "<repo> - Issue {issue_number}"
-```
-
-Respect CODEOWNERS; don't modify auth/CI without approval.

package/agents/cursor/rules/test.mdc

@@ -1,25 +0,0 @@
----
-description: Start testing workflow
-alwaysApply: false
----
-Step 1: Ask for {issue_number} (and optional {slug}); confirm target branch feature/{issue_number}-{slug}.
-
-Step 2: Using GitHub MCP, ensure the branch exists (your GitHub Action will usually auto-create it) and checkout it.
-
-Step 3: Label the issue 'phase:tests'. (GitHub Action will automatically label the issue `status:wip`, create a draft PR)
-
-Step 4: Do your work either remotely or locally as defined by the user. If unsure, ask the user. Once sure, let the user know. 
-
-Step 5: Your work entails the following
-
- - Review the RFC associated with this issue.
-
- - Determine whether tests need to be added to an existing test suite, or a new one needs to be created.
-
- - Write the minimal set of test cases that accurately reproduce the issue
-
- - Run the test cases to ensure they fail
-
- - Flip issue to 'status:needs-review' and remove 'status:wip'
-
-Step 6: If workflow actions or reviewer feedback indicates more work is needed, ensure the issue is set back to `status:wip` and continue working as above.

package/agents/windsurf/rules/architecture.md

@@ -1,49 +0,0 @@
----
-trigger: always_on
----
-
-
-# Architecture
-
-## Intent
-Keep the architecture clean: use BAML (LLM) for any natural-language understanding, fuzzy matching, or semantic comparison. Use deterministic TypeScript only for side-effectful or strictly rule-based work (APIs, DB, validation, formatting, scheduling, retries).
-
-## Principles (follow in this order)
-1. Parse (LLM/BAML) → 2. Normalize (deterministic) → 3. Validate (deterministic) → 4. Decide (LLM if subjective; code if rules) → 5. Act (deterministic side effects)
-
-## LLM/BAML Usage
-- Entity/intent extraction, timezone/place inference, date/time range interpretation
-- Participant role classification, preference inference, text similarity
-- De-dupe by meaning, natural language understanding
-
-## Deterministic TypeScript Usage
-- ISO date math, schema validation, authZ/authN, idempotency keys
-- OpenAPI I/O, DB writes, calendar invites, retries/timeouts
-- Metrics/telemetry, side effects
-
-## Do / Don't
-
-### Do (LLM/BAML)
-- NLP; Anything that needs understanding from user unstructured input
-
-### Do (Deterministic TS)
-- Ensure structure through interfaces, folder management, test cases
-
-### Don't
-- Don't hand-roll regex/heuristics for dates/locations/intent
-- Don't duplicate LLM functionality
-- Don't call BAML for pure formatting (e.g., toISOString, trimming)
-
-## Project Structure
-- **BAML sources**: `/baml_src/**/*.baml`
-- **Generated client**: `/baml_client/**` (run `baml-cli generate`)
-- **Deterministic logic**: `/src/**`
-- **Design docs + Test plans**: `/docs/rfcs/*.md`
-- **Random utility scripts**: `/scripts` 
-- **Test cases**: `/` (at root level, these are the most important artifacts)
-
-## Local Development Notes
-- Test deterministic logic with unit tests before integrating with LLM components
-- Write test cases for each change. Tag representative ones with 'smoke'
-- Keep architecture boundaries clear between LLM and deterministic code
-- Document any architectural decisions in your RFC or implementation notes