fraim-framework 2.0.66 → 2.0.67

package/dist/registry/rules/mandatory-pre-completion-reflection.md

@@ -0,0 +1,193 @@
+# Rule: mandatory-pre-completion-reflection
+
+**Path:** `rules/mandatory-pre-completion-reflection.md`
+
+---
+
+# Mandatory Pre-Completion Reflection
+
+## INTENT
+To prevent agents from claiming success without thorough self-validation, ensuring high-quality deliverables through systematic reflection and honest self-assessment.
+
+## PRINCIPLES
+- **Honesty First**: Be brutally honest about what works and what doesn't
+- **Evidence-Based**: Claims must be backed by concrete evidence
+- **User Perspective**: Think from the end user's point of view
+- **Production Ready**: Would you ship this to customers right now?
+
+## THE 4-PHASE REFLECTION PROCESS
+
+### Phase 1: Claim Verification
+**Purpose**: Verify every claim you're making is backed by evidence
+
+**Questions to Answer**:
+- 🎯 **What exactly am I claiming works?** (Be specific)
+- 📸 **Do I have screenshots/logs proving it works?** (Visual evidence)
+- 🧪 **Did I test every acceptance criteria manually?** (Not just automated tests)
+- 📊 **Are ALL tests passing?** (100%, not 91% or 99%)
+- 🔍 **Have I investigated every error in the logs?** (No assumptions)
+
+**Red Flags**:
+- ❌ Claiming "tests pass" without running them
+- ❌ Saying "it works" without manual validation
+- ❌ Ignoring errors because they "seem expected"
+- ❌ Accepting partial test success (91% pass rate)
+
+### Phase 2: Risk Analysis 
+**Purpose**: Identify what could go wrong in production
+
+**Questions to Answer**:
+- ⚠️ **What could go wrong if a user tries this right now?**
+- 🔍 **What didn't I test that I should have?** (Edge cases, error scenarios)
+- 🚫 **Are there any errors I'm ignoring or assuming are OK?**
+- 🎭 **What would a real user experience if they used this feature?**
+- 🌐 **Have I tested this in the actual environment (browser/API/CLI)?**
+
+**Red Flags**:
+- ❌ Haven't tested error scenarios
+- ❌ Haven't tested edge cases
+- ❌ Haven't done end-to-end user flow testing
+- ❌ Assuming errors are "probably fine"
+
+### Phase 3: Validation Plan Check 
+**Purpose**: Ensure comprehensive validation was performed
+
+**Questions to Answer**:
+- ✅ **Would I ship this to customers right now?** (Honest answer)
+- 💰 **Would I bet money this works end-to-end?** (Confidence check)
+- 🔄 **Can I reproduce the success consistently?** (Not just once)
+- 📋 **Have I followed every step of the workflow?** (No shortcuts)
+- 🎯 **Does this actually solve the user's problem?** (Requirements met)
+
+**Red Flags**:
+- ❌ Wouldn't ship to customers but claiming it's done
+- ❌ Can't reproduce success consistently
+- ❌ Skipped workflow steps
+- ❌ Doesn't actually solve the stated problem
+
+### Phase 4: Self-Audit 
+**Purpose**: Final honesty check and integrity validation
+
+**Questions to Answer**:
+- 🤔 **Am I being completely honest about the status?** (Integrity check)
+- 📝 **Is my evidence complete and accurate?** (Documentation quality)
+- ⏰ **Am I rushing to claim completion?** (Pressure check)
+- 🎯 **Am I solving the assigned issue or something else?** (Scope check)
+- 🔍 **Did I follow all the rules and guidelines?** (Compliance check)
+
+**Red Flags**:
+- ❌ Feeling pressure to claim completion
+- ❌ Evidence is incomplete or misleading
+- ❌ Solving different problem than assigned
+- ❌ Cutting corners on quality
+
+## REFLECTION DOCUMENTATION
+
+After completing the reflection, document your analysis:
+
+```markdown
+## Pre-Completion Reflection
+
+### Phase 1: Claim Verification 
+- **Claims**: [List what you're claiming works]
+- **Evidence**: [List evidence for each claim]
+- **Manual Testing**: [Describe manual validation performed]
+- **Test Results**: [All tests passing? Include output]
+
+### Phase 2: Risk Analysis 
+- **Potential Issues**: [What could go wrong?]
+- **Untested Areas**: [What didn't you test?]
+- **Error Analysis**: [Any errors in logs? Why are they OK?]
+- **User Experience**: [What would user experience?]
+
+### Phase 3: Validation Plan Check 
+- **Ship to Customers**: YES/NO [Would you ship this right now?]
+- **Bet Money**: YES/NO [Would you bet money this works?]
+- **Reproducible**: YES/NO [Can you reproduce success?]
+- **Workflow Complete**: YES/NO [Followed all steps?]
+
+### Phase 4: Self-Audit 
+- **Honesty Check**: YES/NO [Being completely honest?]
+- **Evidence Quality**: YES/NO [Evidence complete and accurate?]
+- **No Rushing**: YES/NO [Not rushing to completion?]
+- **Correct Problem**: YES/NO [Solving the right problem?]
+
+### Reflection Summary
+[Brief summary of reflection analysis and any blockers identified]
+```
+
+**IMPORTANT**: After completing reflection, append your insights to the retrospective document:
+- **File**: `retrospectives/issue-{issue-number}-{kebab-title}-postmortem.md`
+- **If file exists**: Append new section with timestamp
+- **If file doesn't exist**: Create it using the retrospective template
+- **Section format**: `## Pre-Completion Reflection Insights ({date} - {current-phase})`
+
+## ENFORCEMENT
+
+### Mandatory Completion
+- **REQUIRED**: All 4 phases must be completed before claiming work is done
+- **MINIMUM TIME**: 10 minutes total reflection time
+- **DOCUMENTATION**: Reflection analysis must be included in evidence
+
+### Blocker Identification
+If reflection identifies any blockers:
+- **STOP**: Do not claim completion
+- **FIX**: Address all identified issues
+- **RE-REFLECT**: Complete reflection again after fixes
+
+### Quality Gates
+- ❌ **BLOCKER**: Any "NO" answers in Phase 3 or 4
+- ❌ **BLOCKER**: Incomplete reflection documentation
+- ❌ **BLOCKER**: Evidence doesn't support claims
+- ❌ **BLOCKER**: Identified risks not addressed
+
+## EXAMPLES
+
+### Good Reflection Example
+```markdown
+### Phase 1: Claim Verification
+- **Claims**: OAuth login flow works end-to-end
+- **Evidence**: Screenshots of login → redirect → dashboard flow
+- **Manual Testing**: Tested in Chrome, Firefox, Safari - all work
+- **Test Results**: 15/15 tests passing, full output attached
+
+### Phase 3: Validation Plan Check
+- **Ship to Customers**: YES - Confident this works in production
+- **Bet Money**: YES - Tested thoroughly, no concerns
+- **Reproducible**: YES - Works consistently across browsers
+- **Workflow Complete**: YES - Followed all implementation steps
+```
+
+### Bad Reflection Example
+```markdown
+### Phase 1: Claim Verification
+- **Claims**: Login works
+- **Evidence**: Tests pass
+- **Manual Testing**: Didn't test manually, tests should be enough
+- **Test Results**: 14/15 tests passing (93% is good enough)
+
+### Phase 3: Validation Plan Check
+- **Ship to Customers**: NO - Haven't tested manually
+- **Bet Money**: NO - Not sure if it actually works
+- **Reproducible**: UNKNOWN - Only ran tests once
+- **Workflow Complete**: NO - Skipped manual validation
+```
+
+## BENEFITS
+
+1. **Prevents False Success**: Catches claims not backed by evidence
+2. **Improves Quality**: Forces thorough validation before completion
+3. **Builds Confidence**: Systematic validation increases confidence
+4. **Reduces Rework**: Catches issues before they reach human review
+5. **Develops Discipline**: Builds habit of thorough self-validation
+
+## SUMMARY
+
+The mandatory pre-completion reflection ensures agents:
+- Validate every claim with concrete evidence
+- Think from user perspective about potential issues
+- Perform comprehensive testing before claiming completion
+- Maintain integrity and honesty in status reporting
+- Deliver production-ready work that actually solves the problem
+
+**Remember**: 10 minutes of reflection can save hours of rework.

package/dist/registry/rules/merge-requirements.md

@@ -0,0 +1,238 @@
+# Merge Requirements
+
+## INTENT
+To ensure the stability of the `master` branch and prevent accidental overwrites by requiring all agents to apply their local changes *on top of* the latest `master` branch changes, ensuring `master`'s history is never overwritten.
+
+## PRINCIPLES
+- **Rebase, Don't Merge:** Always rebase your feature branch on top of the latest `master` to maintain a clean, linear history and ensure changes from `master` are applied first.
+- **Verify After Rebase:** Run all tests and builds *after* a successful rebase to ensure stability before pushing.
+- **Document Conflict Resolution:** Clearly document how any rebase conflicts were resolved, emphasizing how `master`'s changes were preserved.
+- **Force-with-Lease:** When pushing a rebased branch, use `git push --force-with-lease` to avoid overwriting work from other contributors.
+
+## WORKFLOW
+
+## MANDATORY PRE-PUSH WORKFLOW
+
+### Before ANY push to your feature branch:
+```bash
+# 1. Sync with latest master
+git fetch origin
+git rebase origin/master
+
+# 2. If conflicts occur, resolve them using conflict resolution guide
+# (Git will pause and show you conflict markers)
+git rebase --continue
+
+# 3. Verify everything works
+# Use project-specific smoke test command from .fraim/config.json if available
+# Check: cat .fraim/config.json | grep "smokeTestCommand"
+# Use configured command or default to:
+npm run build
+
+npm run test-smoke test*.ts
+
+# 4. Only then push
+git push origin <your-feature-branch> --force-with-lease
+```
+
+### This workflow is MANDATORY because:
+- Prevents creating stale PRs
+- Ensures your changes work with latest master
+- Reduces merge conflicts
+- Required by GitHub branch protection rules
+
+## DETAILED REBASE PROCESS
+1.  **Sync with `master`:** Before pushing your changes, rebase your feature branch on top of the latest `master` branch. This applies `master`'s changes first, then your local changes on top.
+
+    ```bash
+    git checkout <your-feature-branch>
+    git fetch origin
+    git rebase origin/master
+    ```
+
+2.  **Resolve Rebase Conflicts:** If there are any conflicts during the rebase, you must resolve them intelligently. The rebase process will pause to allow you to fix the files. Your goal is to preserve the changes from `master` while reapplying your feature's changes.
+
+    ## CONFLICT RESOLUTION DURING REBASE
+
+    ### When Git Pauses for Conflicts:
+    1. **Read the conflict markers carefully:**
+       - `<<<<<<< HEAD` = Your changes
+       - `=======` = Separator  
+       - `>>>>>>> origin/master` = Master's changes
+
+    2. **Understand what each version does:**
+       - Master's version = What's already in production
+       - Your version = What you're trying to add
+
+    3. **Resolution Strategy:**
+       - **Keep master's base** (it's already tested/deployed)
+       - **Add your enhancements** on top
+       - **Never overwrite master's working code**
+       - **Never lose your new functionality**
+
+    4. **Common Conflict Scenarios:**
+
+       **Scenario 1: Same function, different implementations**
+       ```typescript
+       <<<<<<< HEAD (your changes)
+       async function processMessage(message: string) {
+         // Your new implementation
+         return await this.messageService.process(message);
+       }
+       =======
+       async function processMessage(message: string) {
+         // Master's updated implementation  
+         return await this.messageService.processWithValidation(message);
+       }
+       >>>>>>> origin/master
+       ```
+       
+       **Resolution:** Keep master's version + add your enhancements
+       ```typescript
+       async function processMessage(message: string) {
+         // Master's base implementation
+         const result = await this.messageService.processWithValidation(message);
+         // Your additional logic
+         return await this.enhanceResult(result);
+       }
+       ```
+
+       **Scenario 2: Different functions, no overlap**
+       ```typescript
+       <<<<<<< HEAD (your changes)
+       // Your new function
+       async function newFeature() {
+         return "new stuff";
+       }
+       =======
+       // Master's new function  
+       async function masterFeature() {
+         return "master stuff";
+       }
+       >>>>>>> origin/master
+       ```
+       
+       **Resolution:** Keep both (no conflict, just different functions)
+       ```typescript
+       // Master's function
+       async function masterFeature() {
+         return "master stuff";
+       }
+
+       // Your function
+       async function newFeature() {
+         return "new stuff";
+       }
+       ```
+
+    5. **After resolving conflicts:**
+       ```bash
+       # After resolving conflicts in your IDE
+       git add <resolved-file-1> <resolved-file-2>
+       git rebase --continue
+       ```
+
+    ### NEVER DO THIS:
+    ❌ "Accept Current Change" (your version) - overwrites master
+    ❌ "Accept Incoming Change" (master's version) - loses your work
+    ❌ "Accept Both Changes" - creates duplicate code
+
+    ### ALWAYS DO THIS:
+    ✅ Read both versions carefully
+    ✅ Understand what each change does
+    ✅ Merge intelligently or choose the better implementation
+    ✅ Test the resolution with: npm run build && [use smokeTestCommand from .fraim/config.json or default smoke test]
+    ✅ Document your resolution in the PR description
+
+3.  **Run Verification Checks:** After the rebase is complete, you must run all local verification checks to ensure the codebase is stable.
+    *   **Build the project:** Run the build command to ensure there are no compilation errors.
+    *   **Run tests:** Execute the full test suite to confirm that your changes have not introduced any regressions.
+
+4.  **Push Your Changes:** Once all checks have passed, push your rebased branch. You must use `--force-with-lease` because the rebase has rewritten your branch's commit history.
+
+    ```bash
+    git push origin <your-feature-branch> --force-with-lease
+    ```
+
+5.  **Pull Request:** When creating a pull request, the description must include a confirmation that this rebase process was followed and a detailed summary of how any conflicts were resolved.
+
+    ## PR Description Template
+    ```markdown
+    ## Merge Process Confirmation
+    - [ ] Rebased on latest master
+    - [ ] Resolved X conflicts in files: [list files]
+    - [ ] Resolution strategy: [explain what you did]
+    - [ ] Verified with: npm run build && [used smokeTestCommand from .fraim/config.json]
+    - [ ] All tests passing: ✅
+
+    ## Conflict Resolution Summary
+    ### Files with conflicts:
+    - `src/file1.ts`: [Brief description of how conflict was resolved]
+    - `src/file2.ts`: [Brief description of how conflict was resolved]
+
+    ### Resolution approach:
+    [Explain your overall strategy - e.g., "Kept master's base implementation and added my enhancements on top"]
+    ```
+
+## FINAL MERGE PROCESS (After PR Approval)
+
+### 6. **Execute the Merge:** Once your PR is approved and ready, perform the final merge:
+
+    ```bash
+    # 1. Navigate to your PR on GitHub
+    # 2. Click "Merge pull request" button
+    # 3. GitHub will automatically:
+    #    - Rebase your branch on latest master
+    #    - Apply your changes on top
+    #    - Create a clean, linear history
+    #    - Merge into master
+    ```
+
+### 7. **Post-Merge Cleanup:** After successful merge:
+
+    ```bash
+    # 1. Switch to master and pull latest changes
+    git checkout master
+    git pull origin master
+
+    # 2. Delete your feature branch (local)
+    git branch -d <your-feature-branch>
+
+    # 3. Delete your feature branch (remote)
+    git push origin --delete <your-feature-branch>
+
+    # 4. Verify the merge was successful
+    git log --oneline -5
+    ```
+
+### 8. **Final Verification:** Ensure everything is working:
+
+    ```bash
+    # Run final tests to confirm merge didn't break anything
+    npm run build
+    # Use project-specific smoke test command from .fraim/config.json if available
+    # Check: cat .fraim/config.json | grep "smokeTestCommand"
+    # Use configured command or default to:
+    npm run test-smoke test*.ts
+    ```
+
+## MERGE WORKFLOW SUMMARY
+
+### Complete Process:
+1. **Development** → Work on feature branch
+2. **Pre-Push** → Rebase on master, resolve conflicts, test
+3. **Push** → Push to GitHub
+4. **PR Creation** → Create PR with detailed description
+5. **Review** → Wait for approval
+6. **Merge** → Click "Merge pull request" on GitHub
+7. **Cleanup** → Delete branches, verify merge
+8. **Verification** → Run final tests
+
+### Key Points:
+- ✅ **GitHub handles the final rebase** automatically during merge
+- ✅ **No manual rebasing** needed before merge
+- ✅ **Linear history** maintained automatically
+- ✅ **All conflicts resolved** during the merge process
+- ✅ **Clean, up-to-date master** branch
+
+By following this process, we ensure that the `master` branch always remains in a stable and deployable state. Failure to follow these rules will result in the rejection of your pull request.

package/dist/registry/rules/simplicity.md

@@ -0,0 +1,118 @@
+# Rule: simplicity
+ 
+**Path:** `rules/simplicity.md`
+ 
+---
+ 
+# Simplicity
+ 
+## INTENT
+To maintain code quality and development velocity by preventing over-engineering, ensuring agents focus on solving the specific problem at hand rather than building unnecessary complexity.
+ 
+## PRINCIPLES
+- Keep it simple. Don't over-engineer.
+- Don't over-think it.
+- Focus on the assigned issue only.
+- Don't fix other issues or make unrelated changes.
+
+## REQUIREMENTS
+- While fixing an issue, focus on that issue only
+- Don't fix other issues or make unrelated changes
+- If you find other issues that must be fixed, include them in your final report as a suggested Git issue
+- Don't over-engineer solutions
+- Choose the simplest approach that solves the problem
+- **NEVER use placeholder comments** like "For now", "TODO", "FIXME", or "This is a placeholder"
+- **ALWAYS implement complete solutions** - if something needs to be customized later, implement it properly with clear configuration
+
+## PROTOTYPE-FIRST DEVELOPMENT PATTERN
+
+### Core Principle
+**Always prototype the end-to-end solution manually before engineering it correctly.**
+
+### Development Flow
+1. **Prototype**: Build simplest possible solution that works end-to-end
+2. **Manual Validation**: Test each step manually using browser/API calls
+3. **Verify**: Confirm everything works before creating automated tests
+4. **Engineer**: Refactor to production quality once proven to work
+5. **Automate**: Create Playwright tests only after manual validation
+
+### Anti-Patterns to Avoid
+- ❌ **"Assume It Works"**: Creating tests before manual validation
+- ❌ **"Over-Engineer First"**: Building complex architecture before proving simple solution works
+- ❌ **"Test-Driven Over-Engineering"**: Writing comprehensive test suites for unproven solutions
+- ❌ **"Band-Aid Fixes"**: Adding delays, retries, workarounds instead of fixing root cause
+- ❌ **"Resource Waste"**: Running expensive operations repeatedly without analyzing failures
+
+### Validation Requirements
+- **Manual Testing**: Use browser/curl to test each step manually
+- **End-to-End Flow**: Verify complete user journey works
+- **No Assumptions**: Don't assume anything works until manually verified
+- **Simple First**: Start with simplest possible implementation
+- **Prove Then Improve**: Only add complexity after proving simple version works
+
+## RESOURCE WASTE PREVENTION
+- Maximum 2 retries for expensive operations (Playwright, API calls, database)
+- After 2 failures: STOP, analyze, propose different approach
+- **STOP** if tests are consuming significant resources repeatedly
+- **Manual validation required** before creating automated tests
+
+## EXAMPLES
+
+### Good: Prototype-First Development
+```
+Issue: "Add OAuth login"
+Action: 
+1. Built simple OAuth callback → JWT → redirect
+2. Manually tested with browser (login → redirect → dashboard works)
+3. Verified end-to-end flow works
+4. Then created Playwright tests
+Result: Working solution, no overengineering
+```
+
+### Bad: Over-Engineering First
+```
+Issue: "Add OAuth login"
+Action: 
+1. Built complex session management system
+2. Created comprehensive test suite
+3. Added session validation endpoints
+4. Created infinite redirect loops
+5. Added delays/retries to fix timing issues
+Result: Over-engineered, resource waste, doesn't work
+```
+
+### Good: Manual Validation First
+```
+Issue: "Fix API endpoint"
+Action: 
+1. Fixed the code
+2. Tested with curl to verify it works
+3. Tested in browser to verify UI works
+4. Then created automated tests
+Result: Confident solution works before automation
+```
+
+### Bad: Assume It Works
+```
+Issue: "Fix API endpoint"
+Action: 
+1. Fixed the code
+2. Created Playwright tests immediately
+3. Tests fail because solution doesn't actually work
+4. Keep retrying tests instead of fixing code
+Result: Wasted resources, false confidence
+```
+
+### Good: Simple Solution
+```
+Issue: "Add error message for invalid input"
+Action: Added single validation check with clear error message
+Result: Clean, focused solution
+```
+
+### Bad: Complex Solution
+```
+Issue: "Add error message for invalid input"
+Action: Built comprehensive validation framework with multiple error types, internationalization, and complex state management
+Result: Over-engineered for simple requirement
+```

package/dist/registry/rules/software-development-lifecycle.md

@@ -0,0 +1,105 @@
+# Software Development Lifecycle
+
+## INTENT
+To provide a structured, phase-based approach to issue resolution that ensures proper planning, implementation, testing, and cleanup while maintaining coordination with other agents and respecting project governance.
+
+## PRINCIPLES
+- **Phase-Based Development**: Clear phases with specific deliverables
+- **Branch Safety**: Never work on master, always use feature branches
+- **Local Development**: Work in isolated clones to prevent conflicts
+- **Coordination**: Use GitHub for agent coordination and status management
+- **Governance**: Respect CODEOWNERS and project policies
+
+## CORE WORKFLOW
+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. Folder name should be `Ashley Calendar AI - Issue {issue_number}`
+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
+
+## MANDATORY PRE-COMMIT VALIDATION
+Before ANY commit, run: `git branch` and verify NOT on master
+
+## PHASES
+
+### Design Phase
+- **Trigger**: Set ISSUE to `phase:design`
+- **Deliverable**: Create RFC document
+- **Status**: Automatically set to `status:wip`
+
+### Implementation Phase
+- **Trigger**: Set ISSUE to `phase:impl`
+- **Deliverable**: Working code with tests
+- **Status**: Set to `status:needs-review` when ready
+
+## 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
+
+## EXAMPLES
+
+### Good: Proper Phase Management
+```
+Issue #84: "Fix calendar sync timeout"
+1. Set phase:design → Create RFC for retry logic
+2. Set phase:impl → Implement exponential backoff
+3. Set status:needs-review → Ready for code review
+4. PR approved → Set status:complete
+Result: Clear progression through phases
+```
+
+### Bad: Skipping Phases
+```
+Issue #84: "Fix calendar sync timeout"
+1. Jump straight to coding without design
+2. No RFC created
+3. Implementation lacks proper planning
+Result: Incomplete solution, potential rework
+```
+
+## PRE-PHASE VALIDATION
+
+### Before Starting Any Phase
+Agents MUST complete validation checklist:
+
+1. **Read Relevant Rules**:
+   - [ ] Read `get_fraim_file({ path: "rules/software-development-lifecycle.md" })`
+   - [ ] Read phase-specific workflow via `get_fraim_file` (e.g. `workflows/product-building/design.md`)
+   - [ ] Read retrospectives folder thoroughly and understand past learnings
+
+2. **Verify Environment**:
+   - [ ] Confirm working directory is correct
+   - [ ] Verify branch exists and is checked out
+   - [ ] Check issue labels are correct
+
+3. **Template Validation**:
+   - [ ] Locate correct template file
+   - [ ] Verify template exists and is readable
+   - [ ] Confirm naming convention understanding
+
+4. **Technical Understanding**:
+   - [ ] Understand relevant technical patterns for the issue
+   - [ ] Plan test strategy for core functionality
+
+### Validation Failure Response
+If any validation step fails:
+1. Stop work immediately
+2. Read missing documentation
+3. Ask clarifying questions if needed
+4. Resume only after validation complete
+
+## 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 "Ashley Calendar AI - Issue {issue_number}"
+```
+
+Respect CODEOWNERS; don't modify auth/CI without approval.