Restore ring3

.claude/agents.disabled/kernel-validator.json

@@ -0,0 +1,12 @@
+{
+    "permissions": {
+        "allow": [
+            "mcp.*",
+            "Read(**/*)",
+            "Write(**/*)",
+            "Shell(**)",
+            "WebFetch"
+        ],
+        "deny": []
+    }
+}

.claude/agents/kernel-validator.md → .claude/agents.disabled/kernel-validator.md

@@ -2,13 +2,39 @@
 name: kernel-validator
 description: Validates kernel implementation outputs and test results. Acts as quality gatekeeper - work cannot proceed without this agent's acceptance. Analyzes logs, verifies test passes, confirms feature requirements are met, and provides ACCEPT/REJECT decisions with specific failure reasons.
 tools:
-  - cursor-cli
+  - mcp__cursor-cli__cursor_agent_execute
 ---
 
 # Kernel Output Validation Agent
 
 You are the quality gatekeeper for Breenix OS development. No feature implementation or bug fix can be considered complete without your validation. You analyze kernel outputs, test results, and log files to provide definitive ACCEPT or REJECT decisions.
 
+## Your Role
+
+When invoked, you MUST:
+
+1. Call the MCP tool `cursor-cli:cursor_agent_execute` with OS-specific testing criteria
+2. Return Cursor Agent's analysis verbatim
+3. Add synthesis focusing on OS-critical validation aspects: correctness, OS-dev best practices
+
+## Tool Usage
+
+Always call the tool with these parameters:
+
+```json
+{
+  "metaprompt": "You are reviewing an OS kernel implementation plan. Evaluate against production OS standards (Linux/FreeBSD). Check for: 1) Architectural correctness for x86_64, 2) Security boundary violations, 3) Race conditions and concurrency issues, 4) Hardware compatibility (UEFI, interrupts, paging), 5) POSIX compliance where applicable, 6) Performance implications. Flag ANY shortcuts or toy OS patterns. Current date: {CURRENT_DATE}",
+  "content": "<the evidence to review>",
+  "model": "gpt-5",
+  "workingDir": "/Users/wrb/fun/code/breenix"
+}
+```
+
+## Guardrails:
+- You MUST call mcp__cursor-cli__cursor_agent_execute at least once.
+- If you cannot call it, output exactly NO_TOOL_USED and stop.
+
+
 ## Your Authority
 
 You have **ABSOLUTE VETO POWER** over feature completion. When invoked:
@@ -168,7 +194,7 @@ Call cursor-cli for complex validation analysis:
 ```json
 {
   "metaprompt": "You are validating a Breenix OS kernel feature implementation. Analyze the provided logs and test outputs. Check for: 1) Functional correctness, 2) No regressions, 3) Proper error handling, 4) Security boundaries maintained, 5) Performance acceptable. Provide ACCEPT or REJECT decision with specific evidence-based reasoning. Be strict - production quality only.",
-  "plan": "<logs, test outputs, and requirements>",
+  "content": "<logs, test outputs, and requirements>",
   "model": "gpt-5",
   "workingDir": "/Users/wrb/fun/code/breenix"
 }

.claude/agents/local-tester.md → .claude/agents.disabled/local-tester.md

@@ -7,6 +7,27 @@ tools:
   - kernel-validator
 ---
 
+## Your Role
+
+When invoked, you must:
+
+1. Call the MCP tool `cursor-cli:cursor_agent_execute` with OS-specific testing criteria
+2. Return Cursor Agent's analysis verbatim
+3. Add synthesis focusing on OS-critical testing aspects: coverage, success rates, errors to focus on
+
+## Tool Usage
+
+Always call the tool with these parameters:
+
+```json
+{
+  "metaprompt": "You are reviewing an OS kernel implementation plan. Evaluate against production OS standards (Linux/FreeBSD). Check for: 1) Architectural correctness for x86_64, 2) Security boundary violations, 3) Race conditions and concurrency issues, 4) Hardware compatibility (UEFI, interrupts, paging), 5) POSIX compliance where applicable, 6) Performance implications. Flag ANY shortcuts or toy OS patterns. Current date: {CURRENT_DATE}",
+  "content": "<the test plan to run>",
+  "model": "gpt-5",
+  "workingDir": "/Users/wrb/fun/code/breenix"
+}
+```
+
 # Local Testing and Regression Prevention Agent
 
 You are responsible for comprehensive local testing after every code change to ensure no regression in achieved capabilities. You work closely with the kernel-validator agent to confirm all functionality remains intact.

.claude/agents/planner-os.md → .claude/agents.disabled/planner-os.md

@@ -13,7 +13,7 @@ You are a rigorous OS kernel plan reviewer that leverages Cursor Agent (GPT-5) t
 
 When invoked, you must:
 
-1. Call the MCP tool `cursor-cli:cursor_agent.review` with OS-specific review criteria
+1. Call the MCP tool `cursor-cli:cursor_agent_execute` with OS-specific review criteria
 2. Return Cursor Agent's analysis verbatim
 3. Add synthesis focusing on OS-critical aspects: correctness, security, performance
 
@@ -24,7 +24,7 @@ Always call the tool with these parameters:
 ```json
 {
   "metaprompt": "You are reviewing an OS kernel implementation plan. Evaluate against production OS standards (Linux/FreeBSD). Check for: 1) Architectural correctness for x86_64, 2) Security boundary violations, 3) Race conditions and concurrency issues, 4) Hardware compatibility (UEFI, interrupts, paging), 5) POSIX compliance where applicable, 6) Performance implications. Flag ANY shortcuts or toy OS patterns. Current date: {CURRENT_DATE}",
-  "plan": "<the implementation plan to review>",
+  "content": "<the implementation plan to review>",
   "model": "gpt-5",
   "workingDir": "/Users/wrb/fun/code/breenix"
 }
@@ -89,7 +89,7 @@ CRITICAL REQUIREMENTS:
 ## Output Format
 
 1. **Cursor Agent Review**: Complete analysis from GPT-5
-2. **Critical Issues**: 
+2. **Critical Issues**:
    - 🔴 Blocking problems that MUST be fixed
    - 🟡 Concerns that should be addressed
    - 🟢 Good practices observed

.claude/agents/researcher-kernel.md → .claude/agents.disabled/researcher-kernel.md

@@ -28,12 +28,12 @@ When you need to research:
 
 ## Tool Invocation Pattern
 
-Always call the MCP tool `cursor-cli:cursor_agent.review` with these parameters:
+Always call the MCP tool `cursor-cli:cursor_agent_execute` with these parameters:
 
 ```json
 {
   "metaprompt": "You are an OS kernel research specialist. Research the following topic with focus on production-quality operating system implementation. Prioritize information from: 1) Linux kernel documentation and source, 2) FreeBSD documentation, 3) Intel/AMD manuals, 4) Academic OS textbooks (Tanenbaum, Silberschatz), 5) OSDev wiki. Current date: {CURRENT_DATE}",
-  "plan": "<the specific research query with context>",
+  "content": "<the specific research query with context>",
   "model": "gpt-5",
   "workingDir": "/Users/wrb/fun/code/breenix"
 }

.claude/hooks/inject_claude_md.sh

@@ -0,0 +1,11 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+proj="${CLAUDE_PROJECT_DIR:-$PWD}"
+file="$proj/CLAUDE.md"
+
+[ -f "$file" ] || exit 0
+
+printf "\n### INSTRUCTIONS (from %s)\n\n" "$file"
+cat "$file"
+printf "\n"

.cursor/rules/breenix.md

@@ -0,0 +1,170 @@
+## Breenix Cursor Rules
+
+These rules govern how the assistant works in this repository. Follow them strictly. Quality and correctness outweigh speed.
+
+### Project Overview
+- **Breenix** is a production-quality x86_64 OS kernel written in Rust. Not a toy.
+- Kernel is `#![no_std]`, runs on bare metal with a custom target.
+- Repo structure highlights:
+  - `kernel/` core kernel implementation
+  - `libs/` supporting libraries
+  - `tests/` integration tests
+  - `docs/planning/` roadmap and design docs
+
+### Critical Command Line Policy
+- **Never** generate unique ad-hoc shell commands that require user approval.
+- **Always** use the provided reusable scripts/utilities; add a new script first if needed.
+- **Log searching**: Use `./scripts/find-in-logs` configured via `/tmp/log-query.txt`.
+- Prefer non-interactive, deterministic commands. Avoid prompts and background long-lived processes.
+
+Examples for log searches:
+```bash
+echo '-A50 "Creating user process"' > /tmp/log-query.txt
+./scripts/find-in-logs
+
+echo '-E "Fork succeeded|exec succeeded"' > /tmp/log-query.txt
+./scripts/find-in-logs
+```
+
+### Critical Mindset: No Time Constraints
+- **There are no time constraints — only quality matters.**
+- Iterate until changes are accepted. Address all feedback thoroughly.
+- Do not take shortcuts due to complexity; build production-grade solutions.
+
+### Critical Design Principle: Follow OS-Standard Practices
+- Use Linux/FreeBSD patterns as the standard.
+- No quick hacks; implement correct mechanisms that scale.
+- Required patterns include (non-exhaustive):
+  - Proper page table switching for `exec()` ELF loading (no double-mapping)
+  - Correct copy-on-write `fork()`
+  - Standard syscall interfaces/semantics
+  - Real virtual memory isolation
+  - Proper interrupt/exception handling
+
+### Running Breenix
+- Preferred wrappers (these auto-manage logs):
+  - `./scripts/run_breenix.sh`
+  - `./scripts/run_test.sh`
+
+Direct commands (console-only logs):
+```bash
+cargo run --release --bin qemu-uefi -- -serial stdio -display none
+cargo run --release --bin qemu-bios -- -serial stdio -display none
+cargo run --release --features testing --bin qemu-uefi -- -serial stdio
+```
+
+### Logs
+- All kernel runs produce timestamped logs in `logs/` (e.g., `breenix_YYYYMMDD_HHMMSS.log`).
+- Use `./scripts/find-in-logs` for all searches (configure via `/tmp/log-query.txt`).
+
+Typical patterns to search for:
+- **Success**: words like "succeeded" or `✓`
+- **Failures**: "failed", "ERROR", "DOUBLE FAULT"
+- **Userspace execution proof**: explicit logs showing usermode instructions and syscalls
+
+### Development Workflow
+1. Make code changes in `kernel/src/` and related components.
+2. Run via scripts or tests; logs go to `logs/`.
+3. Analyze with `./scripts/find-in-logs`.
+4. Compare against known-good patterns; investigate any regressions.
+
+Automated testing (preferred during development):
+```bash
+./scripts/breenix_runner.py > /dev/null 2>&1 &
+sleep 15  # wait for boot + tests
+```
+
+### Testing and Test Infrastructure
+- Most tests use a shared QEMU instance for speed (~45s total).
+- Standard test entry point:
+```bash
+cargo test
+```
+
+Test categories include (non-exhaustive):
+- `boot_post_test.rs`, `interrupt_tests.rs`, `memory_tests.rs`, `logging_tests.rs`, `timer_tests.rs`, `simple_kernel_test.rs`, `kernel_build_test.rs`, `system_tests.rs`
+
+Special tests (ignored by default):
+```bash
+cargo test test_bios_boot -- --ignored
+cargo test test_runtime_testing_feature -- --ignored
+cargo run --features testing --bin qemu-uefi -- -serial stdio
+```
+
+Visual testing:
+```bash
+BREENIX_VISUAL_TEST=1 cargo test
+BREENIX_VISUAL_TEST=1 cargo test memory
+```
+
+Interactive manual testing utility:
+```bash
+./scripts/test_kernel.sh
+```
+
+### Coding Practices
+- Rust nightly; custom target `x86_64-breenix.json`; panic strategy: abort; red zone disabled.
+- Clear module organization; const-correct hardware constants; explicit error handling.
+- Code style: descriptive names, early returns, minimal nesting, meaningful comments only where needed.
+
+#### Build Quality Requirements
+- Treat all warnings as errors; code must compile cleanly with `cargo build`.
+- Fix all clippy warnings when available.
+- Use `#[allow(dead_code)]` only for legitimate soon-to-be-used APIs.
+
+### Pull Request Workflow
+- Never push directly to `main`.
+- Always branch from latest `main` and use feature branches.
+- Create PRs with GitHub CLI; include summary, implementation details, testing results, legacy parity improvements, and co-authorship credit.
+
+Example flow:
+```bash
+git checkout main && git pull origin main
+git checkout -b feature-name
+# ... changes ...
+git push -u origin feature-name
+gh pr create --title "Brief description" --body "Detailed description with testing results"
+```
+
+### Critical Debugging Requirement: Proof via Logs
+- Never declare success without definitive log evidence.
+- Proof of userspace execution requires logs like:
+```text
+[INFO] Userspace instruction executed at 0x10000000
+[INFO] Syscall 0x80 received from userspace
+[INFO] Returning to userspace at 0x10000005
+```
+- A crash (e.g., DOUBLE FAULT) is not proof of execution.
+- Critical baseline: ensure "Hello from userspace!" output in direct test before deeper debugging.
+
+### Validation Requirement
+- Always present implementation details and log evidence for validation.
+- Request review/verification and iterate until acceptance.
+- This file intentionally avoids MCP-specific agent invocation details.
+
+### Documentation and Roadmap
+- Master roadmap: `docs/planning/PROJECT_ROADMAP.md`
+  - Update after each PR merge (Recently Completed)
+  - Update when starting new work (Currently Working On)
+  - Weekly review (Immediate Next Steps)
+- Additional docs:
+  - `docs/planning/legacy-migration/FEATURE_COMPARISON.md`
+  - `docs/planning/06-userspace-execution/USERSPACE_SUMMARY.md`
+  - `docs/planning/posix-compliance/POSIX_COMPLIANCE.md`
+
+### Legacy Code Removal Policy
+- Remove legacy code from `src.legacy/` once the new implementation reaches parity or better and is verified.
+- Update `FEATURE_COMPARISON.md` accordingly and do removal in the same commit when practical.
+
+### Cleanup Utilities
+```bash
+pkill -f qemu-system-x86_64
+ls -t logs/*.log | tail -n +11 | xargs rm -f
+```
+
+### Context Compression Reminder
+- If conversation context is compressed, immediately re-read this `.cursor/rules` file to refresh critical project instructions.
+
+### Development Notes
+- Commits should be co-developed by Ryan Breen and the assistant when appropriate.
+