mindforge-cc 10.0.2 → 10.7.0

package/.mindforge/engine/cross-model-eval.md

@@ -0,0 +1,74 @@
+# Cross-Model Eval — Multi-Model Comparison Protocol
+
+## Purpose
+Route the same task to two different models and compare outputs. Divergence
+between models is a quality signal; agreement is a confidence booster.
+
+## When to Trigger
+- Architecture decisions (high stakes, hard to reverse)
+- Security-critical code (auth, payment, PII handling)
+- Agent confidence < 0.7 on current approach
+- User explicitly requests second opinion (via /mindforge:consult)
+- Eval-harness model-grader needs calibration
+
+## Model Selection Logic
+
+| Primary Model | Comparison Model | Rationale |
+|--------------|-----------------|-----------|
+| claude-sonnet-4-6 | gemini-2.5-pro | Different training, different strengths |
+| claude-opus-4-7 | gpt-4o | Independent validation of complex reasoning |
+| gemini-2.5-pro | claude-sonnet-4-6 | Verify research findings independently |
+
+Selection follows the cost-routing tier: comparison model is always from a DIFFERENT provider than the primary.
+
+## Comparison Method
+
+### Step 1 — Sanitize Context
+Same sanitization as multi-llm-consult skill:
+- Remove internal file paths, variable names, proprietary logic
+- Keep abstract question and public references
+
+### Step 2 — Parallel Dispatch
+Send identical sanitized prompt to both models simultaneously.
+
+### Step 3 — Structural Comparison
+Compare responses structurally (not token-by-token):
+- Do they recommend the same approach/pattern?
+- Do they identify the same risks?
+- Do they agree on the key trade-offs?
+
+### Step 4 — Divergence Classification
+
+| Agreement Level | Meaning | Action |
+|----------------|---------|--------|
+| Full agreement | Both recommend same approach with same reasoning | High confidence — proceed |
+| Partial agreement | Same recommendation, different reasoning | Moderate confidence — note alternate reasoning |
+| Approach divergence | Different recommendations, shared concerns | Flag for human review with both perspectives |
+| Full divergence | Different recommendations, different concerns | STOP — present both to user, defer decision |
+
+### Step 5 — Output
+Log to AUDIT entry:
+```json
+{
+  "event": "cross_model_eval",
+  "primary_model": "claude-sonnet-4-6",
+  "comparison_model": "gemini-2.5-pro",
+  "agreement_level": "partial",
+  "primary_recommendation": "...",
+  "comparison_recommendation": "...",
+  "divergence_points": ["..."],
+  "action_taken": "proceed_with_note"
+}
+```
+
+## Budget Guard
+- Maximum 2 cross-model evals per session (expensive operation)
+- Each eval costs ~2x a normal model call
+- Only trigger automatically on high-stakes decisions (not routine tasks)
+- User can always override via /mindforge:consult (manual, no limit)
+
+## Integration Points
+- Cost-routing module determines which comparison model to use
+- Multi-LLM consult skill handles the actual external dispatch
+- Token-ledger records both model calls
+- Council framework may trigger cross-model eval when consensus < 0.5

package/.mindforge/engine/instincts/capture-engine.md

@@ -0,0 +1,63 @@
+# Instinct Engine — Auto-Capture Protocol
+
+## Purpose
+Defines how the instinct engine observes sessions and automatically creates
+instinct entries. This runs in AUTO-CAPTURE mode (always observing).
+
+## Observation Triggers
+
+The capture engine watches for these signals during every session:
+
+### 1. User Corrections
+When the user corrects agent behavior ("no, don't do that", "always do X instead"):
+- Extract the correction as a behavior rule
+- Create instinct with initial confidence 0.6 (user-stated is higher than observed)
+
+### 2. Repeated Patterns (3+ occurrences)
+When the agent performs the same action pattern 3+ times in a session:
+- Extract the pattern as a potential instinct
+- Create with initial confidence 0.4 (observed but not confirmed)
+
+### 3. Successful Outcomes After Specific Actions
+When a verify/test pass follows a specific non-obvious action:
+- Extract the action-outcome pair
+- Create with initial confidence 0.5
+
+### 4. Manual Capture
+When user invokes `/mindforge:learn-instinct`:
+- User provides observation + behavior directly
+- Create with user-specified confidence (default 0.7)
+
+## Deduplication
+
+Before creating a new instinct:
+1. Compare `observation` field against all active instincts (same project)
+2. Similarity threshold: >80% word overlap → treat as duplicate
+3. If duplicate found: increment `times_applied` on existing instinct instead
+4. If near-duplicate (60-80% overlap): create new but link via tags
+
+## Auto-Capture Rate Limits
+
+To prevent noise:
+- Maximum 5 new instincts per session
+- Maximum 100 active instincts per project
+- If at 100: prune lowest-confidence instinct before adding new one
+- Never auto-capture from autonomous mode sessions (too noisy)
+
+## Session-End Summary
+
+At the end of each session where instincts were captured:
+```
+📝 Instincts captured this session:
+  - [NEW] "observation text" (confidence: 0.5)
+  - [REINFORCED] "existing instinct" (confidence: 0.5 → 0.6)
+  
+Active instincts: 47/100 | Ready for promotion: 3
+```
+
+## Integration Points
+
+- Hooks into existing memory capture at `.mindforge/memory/engine/capture-protocol.md`
+- Instinct observations flow through the same memory pipeline
+- Instincts are SEPARATE from memories (memories are facts, instincts are behaviors)
+- Both share the project-scoping mechanism

package/.mindforge/engine/instincts/instinct-schema.md

@@ -0,0 +1,76 @@
+# Instinct Engine — Schema Definition
+
+## Purpose
+Defines the data schema for learned behavioral instincts. Instincts are lightweight
+patterns observed during sessions that may evolve into full skills over time.
+
+## Instinct Entry Schema
+
+Each instinct is a single JSON line in `instinct-store.jsonl`:
+
+```json
+{
+  "id": "inst-[uuid]",
+  "created_at": "2026-05-25T10:30:00Z",
+  "updated_at": "2026-05-25T14:20:00Z",
+  "observation": "When writing database queries, the team always adds an index comment explaining the chosen index strategy",
+  "behavior": "After writing any new database query, add a brief inline comment explaining which index will serve this query and why",
+  "confidence": 0.72,
+  "times_applied": 8,
+  "times_succeeded": 6,
+  "times_failed": 2,
+  "project": "mindforge",
+  "tags": ["database", "documentation", "patterns"],
+  "status": "active",
+  "promoted_to_skill": null,
+  "last_applied_at": "2026-05-25T14:20:00Z",
+  "source_sessions": ["session-abc123", "session-def456"]
+}
+```
+
+## Field Definitions
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| id | string | yes | Unique identifier, prefixed with `inst-` |
+| created_at | ISO-8601 | yes | When the instinct was first observed |
+| updated_at | ISO-8601 | yes | Last modification timestamp |
+| observation | string | yes | What pattern was observed (the trigger condition) |
+| behavior | string | yes | What the agent should do when this pattern is detected |
+| confidence | float | yes | 0.0-1.0, computed from success/failure ratio + application count |
+| times_applied | int | yes | Total times this instinct was applied |
+| times_succeeded | int | yes | Times application led to positive outcome |
+| times_failed | int | yes | Times application led to negative outcome or correction |
+| project | string | yes | Project scope (instincts never leak between projects) |
+| tags | string[] | yes | Classification tags for retrieval |
+| status | enum | yes | One of: active, promoted, deprecated, pruned |
+| promoted_to_skill | string|null | yes | Skill name if promoted, null otherwise |
+| last_applied_at | ISO-8601 | yes | When instinct was last used |
+| source_sessions | string[] | yes | Session IDs where this instinct was observed/reinforced |
+
+## Confidence Scoring
+
+```
+confidence = (times_succeeded / times_applied) * weight_factor
+
+where weight_factor = min(1.0, times_applied / 10)
+```
+
+- New instincts start at 0.5 confidence (neutral)
+- Each success: recalculate with updated counts
+- Each failure: recalculate with updated counts
+- Weight factor prevents high confidence from single observations
+- Minimum 5 applications before promotion is considered
+
+## Status Transitions
+
+```
+[new observation] → active (confidence: 0.5)
+                       ↓
+            confidence >= 0.85 AND times_applied >= 5
+                       ↓
+                   promoted → creates SKILL.md
+                       
+active → deprecated (manual user action)
+active → pruned (confidence < 0.2 after 10+ applications OR 30 days inactive)
+```

package/.mindforge/engine/instincts/promotion-engine.md

@@ -0,0 +1,77 @@
+# Instinct Engine — Promotion Protocol
+
+## Purpose
+Defines the rules and process for promoting mature instincts into full MindForge skills.
+
+## Promotion Criteria
+
+An instinct is eligible for promotion when ALL of these are true:
+1. `confidence >= 0.85`
+2. `times_applied >= 5`
+3. `times_succeeded >= 4` (at least 80% success rate with minimum volume)
+4. `status == "active"` (not already promoted or deprecated)
+5. No existing skill covers the same behavior (checked against MANIFEST.md triggers)
+
+## Promotion Process
+
+### Step 1 — Candidate Identification
+Run by `/mindforge:evolve-skills` command:
+1. Scan `instinct-store.jsonl` for entries meeting all 5 criteria
+2. Rank candidates by confidence * times_applied (impact score)
+3. Present top candidates to user for approval
+
+### Step 2 — Skill Draft Generation
+For each approved candidate:
+1. Generate a SKILL.md using this template:
+
+```yaml
+---
+name: [derived-from-instinct-tags]
+version: 1.0.0
+min_mindforge_version: 10.0.3
+status: stable
+triggers: [derived-from-instinct-observation-keywords]
+origin: instinct-promotion
+origin_instinct_id: [inst-uuid]
+---
+
+# Skill — [Title derived from behavior]
+
+## When this skill activates
+[Derived from instinct observation field]
+
+## Mandatory actions when this skill is active
+
+### During implementation
+[Derived from instinct behavior field, expanded into actionable steps]
+
+### After implementation
+Verify the behavior was applied correctly.
+```
+
+### Step 3 — Registration
+1. Place generated SKILL.md in `.mindforge/skills/[name]/SKILL.md`
+2. Add entry to MANIFEST.md under appropriate tier (default: Project tier)
+3. Mark instinct as `promoted` with `promoted_to_skill: "[skill-name]"`
+
+### Step 4 — Feedback Loop
+After promotion:
+- Continue tracking the instinct's success/failure THROUGH the skill
+- If the skill is later found unhelpful: revert to instinct, mark status as deprecated
+- This prevents premature promotion from creating persistent bad skills
+
+## Pruning Protocol
+
+Instincts are pruned (removed) when:
+- `confidence < 0.2` AND `times_applied >= 10` (repeatedly failed)
+- OR `last_applied_at` is more than 30 days ago (stale)
+- OR user explicitly deprecates via command
+
+Pruned instincts are moved to `.mindforge/engine/instincts/archive/` (not deleted) for audit purposes.
+
+## Metrics
+
+Track promotion health:
+- Promotion rate: instincts promoted / instincts created (target: 10-20%)
+- Reversion rate: promoted skills reverted / total promotions (target: < 5%)
+- Active instinct count trend (should not monotonically increase)

package/.mindforge/engine/proactive/signal-detector.md

@@ -0,0 +1,60 @@
+# Proactive Skill Suggestion — Signal Detector
+
+## Purpose
+Detect contextual signals that indicate a skill should be suggested to the agent,
+even if the user hasn't explicitly mentioned trigger keywords.
+
+## Signal Categories
+
+### 1. File Signals
+Detect skills based on files being opened, modified, or referenced:
+
+| File Pattern | Suggested Skill | Confidence |
+|-------------|----------------|-----------|
+| `*.test.*`, `*.spec.*`, `__tests__/` | testing-anti-patterns | 0.75 |
+| `ONBOARDING*`, new git clone detected | codebase-onboarding | 0.9 |
+| `CLEANUP-REPORT*`, post-merge diff | de-sloppify | 0.8 |
+| `.mindforge/evals/` | eval-harness | 0.85 |
+| `RFC-*.md`, `SPEC-*.md` | rfc-pipeline | 0.8 |
+| `auth*`, `login*`, `payment*` | defense-in-depth | 0.75 |
+| `THREAT-MODEL-*` | threat-modeling | 0.85 |
+| `COUNCIL-*` in decisions/ | council | 0.8 |
+
+### 2. Error Signals
+Detect skills based on error patterns in build/test output:
+
+| Error Pattern | Suggested Skill | Confidence |
+|--------------|----------------|-----------|
+| Mock-related test failures (3+) | testing-anti-patterns | 0.8 |
+| Type errors in test files | testing-anti-patterns | 0.7 |
+| Security scan findings (medium+) | defense-in-depth | 0.85 |
+| Build failures after merge | verification-loop | 0.9 |
+| Token budget warnings | cost-aware-routing | 0.8 |
+
+### 3. Task Signals
+Detect skills based on task description or conversation patterns:
+
+| Task Pattern | Suggested Skill | Confidence |
+|-------------|----------------|-----------|
+| "review", "check", "verify" + completed work | santa-method | 0.75 |
+| "score", "grade", "evaluate" | eval-harness | 0.8 |
+| "cleanup", "polish", "finalize" | de-sloppify | 0.85 |
+| "new project", "unfamiliar", "first time" | codebase-onboarding | 0.9 |
+| "plan", "decompose", "break down spec" | rfc-pipeline | 0.8 |
+| "quality", "how good", "assess" | quality-audit | 0.8 |
+
+## Signal Processing Rules
+
+1. **Single signal sufficiency** — One signal above threshold is enough to suggest
+2. **Signal stacking** — Multiple signals for the same skill boost confidence: `combined = 1 - ((1 - s1) * (1 - s2))`
+3. **No interruption** — Suggestions queue silently; presented only at natural breakpoints
+4. **Context freshness** — File signals expire after 5 minutes of inactivity on that file
+5. **Session memory** — Track which skills were already loaded this session; don't re-suggest
+
+## Integration with Loader
+
+The signal detector works ALONGSIDE the trigger-based loader, not replacing it:
+- **Loader** = reactive (matches on explicit trigger keywords in task description)
+- **Signal detector** = proactive (observes context and suggests before explicit mention)
+
+If the loader has already loaded a skill, the signal detector suppresses its suggestion for that skill.

package/.mindforge/engine/proactive/suggestion-engine.md

@@ -0,0 +1,100 @@
+# Proactive Skill Suggestion — Suggestion Engine
+
+## Purpose
+Manage the lifecycle of skill suggestions: confidence gating, cooldown enforcement,
+deduplication, debounce, and user feedback integration.
+
+## Configuration (from config.json)
+
+```json
+{
+  "proactive_suggestions": {
+    "enabled": true,
+    "confidence_threshold": 0.7,
+    "cooldown_seconds": 300,
+    "debounce_seconds": 30,
+    "max_recent": 50,
+    "store_path": ".mindforge/engine/proactive/recent-suggestions.json"
+  }
+}
+```
+
+## Suggestion Lifecycle
+
+### Step 1 — Signal Received
+Signal detector emits: `{ skill: string, confidence: number, reason: string, signal_type: string }`
+
+### Step 2 — Confidence Gate
+- If `confidence < threshold` (0.7): discard silently
+- If `confidence >= threshold`: proceed to Step 3
+
+### Step 3 — Cooldown Check
+- Read dismissals from `.mindforge/engine/proactive/dismissals.json`
+- If this `skill:signal_type` pair was dismissed within `cooldown_seconds` (300s): suppress
+- Cooldown format: `{ "skill:signal_type": timestamp_ms }`
+
+### Step 4 — Debounce
+- If ANY suggestion was presented within `debounce_seconds` (30s): queue, don't present
+- Queue is FIFO; oldest suggestion presented first after debounce expires
+
+### Step 5 — Deduplication
+- Check if skill is already loaded in current session (from loader)
+- Check if same suggestion was already presented this session
+- If either: discard
+
+### Step 6 — Present Suggestion
+Format for agent context:
+```
+💡 Proactive suggestion: Load **[skill-name]** skill
+   Reason: [reason from signal]
+   Confidence: [0.XX]
+   Action: Apply automatically? [yes/dismiss]
+```
+
+### Step 7 — User Response
+- **Accept**: Load the skill via standard loader pipeline
+- **Dismiss**: Record in `dismissals.json` with timestamp, start cooldown
+
+## Storage
+
+### recent-suggestions.json (circular buffer, max 50)
+```json
+[
+  {
+    "skill": "testing-anti-patterns",
+    "confidence": 0.8,
+    "signal_type": "error",
+    "reason": "3+ mock-related test failures detected",
+    "timestamp": "2026-05-26T10:30:00Z",
+    "outcome": "accepted"
+  }
+]
+```
+
+### dismissals.json
+```json
+{
+  "testing-anti-patterns:error": 1748262600000,
+  "de-sloppify:task": 1748262300000
+}
+```
+
+## Metrics
+
+Track suggestion effectiveness:
+- **Acceptance rate**: accepted / (accepted + dismissed) — target > 60%
+- **Relevance rate**: accepted suggestions that led to skill activation / total accepted
+- **False positive rate**: dismissed / total presented — target < 40%
+
+Report in `/mindforge:status` output:
+```
+Proactive suggestions: 12 presented | 8 accepted (67%) | 4 dismissed
+```
+
+## Disable Conditions
+
+Suggestions are automatically disabled when:
+- `config.json` has `proactive_suggestions.enabled: false`
+- Session is in autonomous mode (too noisy)
+- Agent is in a time-critical path (shipping, hotfix)
+- Budget is in economy mode (avoid context overhead)

package/.mindforge/engine/skills/composition.md

@@ -0,0 +1,83 @@
+# MindForge Skills Engine — Composition System
+
+## Purpose
+Enable skills to declaratively depend on and invoke other skills via a `compose:` 
+field in YAML frontmatter. This allows complex skills to build on simpler foundations
+without duplicating content.
+
+## Schema Addition
+
+Skills may include an optional `compose:` field in their YAML frontmatter:
+
+```yaml
+---
+name: verification-loop
+version: 1.0.0
+min_mindforge_version: 10.0.3
+status: stable
+triggers: verification, quality gate, build check
+compose:
+  - security-review
+---
+```
+
+## Composition Rules
+
+### Resolution
+1. When a skill with `compose:` is loaded, the loader resolves each referenced skill name against MANIFEST.md
+2. Referenced skills are loaded as **summarized content** (not full injection) — see loader.md Step 5 summarisation format
+3. The composing (parent) skill is always injected in full; composed (child) skills are summarized
+
+### Depth Limit
+- Maximum composition depth: **2 levels**
+- A composed skill's own `compose:` dependencies are NOT resolved (no transitive loading)
+- Rationale: prevents context explosion and keeps token budget predictable
+
+### Cycle Detection
+- Before resolving compositions, check for circular references
+- If skill A composes B and B composes A: log a WARNING, skip the circular reference, load only the directly-requested skill
+- Circular detection is checked at load time, not at registration time
+
+### Token Budget Impact
+- Each composed skill adds ~150 tokens (summary format only)
+- A skill composing 3 others adds ~450 tokens overhead
+- This counts against the standard context budget (see loader.md budget table)
+
+### Conflict Resolution
+- If a composed skill is ALSO matched by trigger (i.e., it would have been loaded independently):
+  load it in FULL (not summarized), since it matched on its own merit
+- The composing skill still counts it as satisfied
+
+### Validation at Registration
+When a skill is registered via MANIFEST.md:
+1. Check that all skills listed in `compose:` exist in the manifest
+2. If a referenced skill doesn't exist: log a WARNING (not an error) and register anyway
+3. Missing composed skills are simply not loaded at runtime (graceful degradation)
+
+## Audit Logging
+
+When composition is resolved, add to the task's AUDIT entry:
+```json
+{
+  "skills_composed": [
+    { "parent": "verification-loop", "child": "security-review", "mode": "summarized" }
+  ]
+}
+```
+
+## Examples
+
+### Skill that composes one dependency
+```yaml
+---
+name: threat-modeling
+compose:
+  - security-review
+---
+```
+Result: threat-modeling loaded in full + security-review loaded as summary.
+
+### Skill where composed dependency also triggers independently
+Task: "Review auth threat model for the payment API"
+- Triggers match: threat-modeling (via "threat model") AND security-review (via "auth", "payment")
+- Both load in FULL (security-review matched independently, composition is moot)

package/.mindforge/engine/skills/loader.md

@@ -81,6 +81,22 @@ For each matched skill (in tier priority order: Project → Org → Core):
 3. Inject the skill content into the agent's context package (per `context-injector.md`)
 4. Log which skills were loaded in the task's `task_started` AUDIT entry
 
+### Step 4.1 — Resolve composed dependencies
+
+After loading matched skills, resolve any composition dependencies:
+
+1. For each loaded skill, check its YAML frontmatter for a `compose:` field
+2. If `compose:` is present, resolve each referenced skill name against MANIFEST.md
+3. Inject composed (child) skills as **summarized content** (not full injection) —
+   use the summarisation format defined in Step 5 below
+4. Maximum composition depth: **2 levels** — a composed skill's own `compose:`
+   dependencies are NOT resolved (no transitive composition beyond that)
+5. **Cycle detection:** if skill A composes B and B composes A, log a WARNING
+   and skip the circular reference — load only the directly-requested skill
+   without its circular dependency
+
+For full composition semantics, see `composition.md`.
+
 ### Step 4.5 — Validate loaded skill content (injection guard)
 
 Before injecting any skill content into an agent context, validate it against

package/.mindforge/personas/agent-architect.md

@@ -0,0 +1,57 @@
+---
+name: mindforge-agent-architect
+description: Designs autonomous agent loops, planning systems, and tool orchestration for agentic AI systems.
+tools: Read, Write, Bash, Grep, Glob
+color: autonomous-violet
+---
+
+<role>
+You are the MindForge Agent Architect. You design autonomous AI agents that plan multi-step tasks, use tools intelligently, and adapt to failures. Your systems bridge the gap between language model capabilities and real-world task execution through robust planning, execution monitoring, and error recovery.
+</role>
+
+<why_this_matters>
+- Agents unlock AI capabilities beyond single-shot responses (complex tasks require planning, tool use, and iteration)
+- Poorly designed agents create runaway costs (infinite loops, redundant tool calls) and safety risks (uncontrolled actions)
+- You depend on `llm-orchestrator` for model selection across planning vs execution phases
+- The `ai-safety-engineer` must approve all production agent tool access to prevent harm
+- Your planning algorithms determine whether `ai-economist` sees controlled costs or exponential budget burn
+</why_this_matters>
+
+<philosophy>
+**Planning Is Cheap, Execution Is Expensive:**
+Spend 10 LLM calls on careful planning to save 100 tool executions. Front-load reasoning: decompose tasks into subtasks, validate approach feasibility, identify required tools, and estimate steps before executing anything. Bad plans cost more to fix than time spent upfront planning properly.
+
+**Agents Must Explain Themselves:**
+Every agent decision should be explainable and auditable. Log: planned approach (why these subtasks?), tool call reasoning (why this tool now?), execution observations (what happened?), and adaptation decisions (why change plan?). Enable humans to interrupt, steer, and learn from agents. Opacity breeds distrust.
+
+**Fail-Fast With Circuit Breakers:**
+Agents can spiral: stuck in loops, making redundant calls, ignoring failures. Implement hard limits: max steps (stop after 20 iterations), max cost ($5 per task), max identical tool calls (3 retries), and timeout (5 minutes). Better to admit failure early than waste resources on impossible tasks.
+</philosophy>
+
+<process>
+
+<step name="task_decomposition">
+Break complex tasks into manageable subtasks. Use LLM to generate plan: identify goal, decompose into sequential or parallel subtasks, determine required tools and data, estimate difficulty and time. Validate plan: check for circular dependencies, impossible steps, or missing prerequisites. Output structured plan (DAG of subtasks with dependencies).
+</step>
+
+<step name="tool_orchestration">
+Design tool selection and execution system. Maintain tool registry: each tool has name, description, input schema, output format, cost estimate, and safety rating. Implement tool selection logic: match subtask requirements to tool capabilities, prioritize safe/cheap tools, and fall back to alternative tools when primary fails. Execute with retries and error handling.
+</step>
+
+<step name="execution_monitoring">
+Monitor agent execution in real-time. Track: current subtask, tools called, tokens used, cost accrued, and time elapsed. Detect failure patterns: infinite loops (repeated identical tool calls), stuck states (no progress for N steps), and budget overruns. Trigger interventions: request human guidance, abort task, or simplify plan.
+</step>
+
+<step name="adaptive_planning">
+Enable agents to adapt plans dynamically. After each tool execution, agent observes: tool output, success/failure, and new information learned. Agent decides: continue with plan, revise remaining subtasks, backtrack and try alternative approach, or escalate to human. Log all plan changes with reasoning for post-hoc analysis.
+</step>
+
+</process>
+
+<critical_rules>
+- Never allow agents to use tools without explicit approval from ai-safety-engineer (prevents accidental damage)
+- Always implement step limits per task (prevents infinite loops from consuming unbounded resources)
+- Log complete agent traces (plan, tool calls, observations, adaptations) for debugging and improvement
+- Test agent behavior on adversarial tasks (impossible goals, ambiguous instructions, missing prerequisites)
+- Monitor agent success rates per task type (reveals which tasks are well-suited vs poorly-suited for agents)
+</critical_rules>