fork: rename IronClaw → OptimClaw

Full rename of all identifiers, filenames, and references:
  ironclaw → optimclaw
  IronClaw → OptimClaw
  IRONCLAW → OPTIMCLAW
  ironclaw_common → optimclaw_common
  ironclaw_safety → optimclaw_safety

Upstream: nearai/ironclaw

.claude/commands/add-sse-event.md

@@ -5,7 +5,7 @@ argument-hint: <event_name> [description]
 model: opus
 ---
 
-Add a new SSE event called `$ARGUMENTS` to the IronClaw web gateway. This involves changes across 5 files in a specific order. Follow each step exactly.
+Add a new SSE event called `$ARGUMENTS` to the OptimClaw web gateway. This involves changes across 5 files in a specific order. Follow each step exactly.
 
 ## Step 1: Add `StatusUpdate` variant
 

.claude/commands/add-tool.md

@@ -5,7 +5,7 @@ argument-hint: <tool_name> [description]
 model: opus
 ---
 
-Scaffold a new tool called `$ARGUMENTS` for the IronClaw agent. First, determine the tool type and then follow the appropriate path.
+Scaffold a new tool called `$ARGUMENTS` for the OptimClaw agent. First, determine the tool type and then follow the appropriate path.
 
 ## Step 0: Determine tool type
 
@@ -43,7 +43,7 @@ Follow this exact pattern (adjust name and description):
 name = "<name>-tool"
 version = "0.1.0"
 edition = "2021"
-description = "<Description> tool for IronClaw (WASM component)"
+description = "<Description> tool for OptimClaw (WASM component)"
 license = "MIT OR Apache-2.0"
 publish = false
 

.claude/commands/fix-issue.md

@@ -62,7 +62,7 @@ Enter planning mode to design the implementation. The plan MUST cover:
    - Happy path (expected input produces expected output)
    - Error paths (invalid input, missing data, permission denied)
    - Edge cases (empty collections, boundary values, concurrent access)
-5. **IronClaw-specific concerns**:
+5. **OptimClaw-specific concerns**:
    - If the change touches persistence, both database backends must be updated (`postgres.rs` and `libsql_backend.rs`)
    - New `Database` trait methods need implementations in both backends
    - No `.unwrap()` or `.expect()` in production code
@@ -80,7 +80,7 @@ After the plan is approved:
 
 1. Implement each change from the plan.
 2. Write all planned tests.
-3. Run IronClaw's full quality gate:
+3. Run OptimClaw's full quality gate:
    - `cargo fmt`
    - `cargo clippy --all --benches --tests --examples --all-features` (zero warnings)
    - `cargo test --lib` (all tests pass)

.claude/commands/pr-shepherd.md

@@ -96,7 +96,7 @@ Wait for user confirmation (unless `--fix` flag set), then proceed to Phase 3.
 
 Read EVERY changed file in full (not just diff hunks). For PRs touching >20 files, prioritize: service logic > handlers > types > tests > docs. Batch reads in parallel via Agent tool.
 
-### IronClaw-specific checks (always)
+### OptimClaw-specific checks (always)
 - No `.unwrap()` or `.expect()` in production code
 - Prefer `crate::` for cross-module imports (`super::` OK in tests/intra-module)
 - Error types use `thiserror`
@@ -167,7 +167,7 @@ gh pr checkout {number}
 1. All approved review comment fixes (from Phase 2a)
 2. All approved review findings (from Phase 2b)
 
-Follow IronClaw conventions:
+Follow OptimClaw conventions:
 - `thiserror` for errors
 - `crate::` imports
 - No `.unwrap()` in production
@@ -180,7 +180,7 @@ After all fixes implemented, proceed to Phase 4.
 
 ## Phase 4: Quality Gate
 
-Run the full IronClaw shipping checklist:
+Run the full OptimClaw shipping checklist:
 
 ```bash
 cargo fmt

.claude/commands/respond-pr.md

@@ -60,7 +60,7 @@ Wait for user confirmation before proceeding to implementation.
 After user confirms:
 
 1. Implement each fix in the plan.
-2. Run IronClaw's quality gate to verify nothing breaks:
+2. Run OptimClaw's quality gate to verify nothing breaks:
    - `cargo fmt`
    - `cargo clippy --all --benches --tests --examples --all-features`
    - `cargo test --lib`
@@ -77,5 +77,5 @@ For each comment addressed, reply on the PR with a short message stating what wa
 - Group duplicate comments (same issue reported by multiple bots) and reply to all of them.
 - Do not make changes beyond what the review comments ask for. Stay focused.
 - If a comment suggests a change you disagree with, present your reasoning to the user during the planning phase rather than silently ignoring it.
-- Follow IronClaw conventions: no `.unwrap()` in production code, use `crate::` imports, `thiserror` errors.
+- Follow OptimClaw conventions: no `.unwrap()` in production code, use `crate::` imports, `thiserror` errors.
 - If changes touch persistence, verify both database backends are updated.

.claude/commands/review-crate.md

@@ -1,5 +1,5 @@
 ---
-description: Deep audit of the IronClaw crate for vulnerabilities, bugs, unfinished work, inconsistencies, and oversights
+description: Deep audit of the OptimClaw crate for vulnerabilities, bugs, unfinished work, inconsistencies, and oversights
 disable-model-invocation: true
 allowed-tools: Bash(cargo fmt:*), Bash(cargo clippy:*), Bash(cargo test:*), Bash(cargo audit:*), Bash(git diff:*), Bash(git log:*), Bash(git show:*), Bash(wc:*), Read, Grep, Glob, Task
 argument-hint: "[path/to/crate]"
@@ -93,7 +93,7 @@ Search for `.unwrap()`, `.expect(`, `panic!`, `unreachable!` in non-test code. F
 - Is there a code path that reaches this with None/Err?
 - Should it be replaced with proper error handling (`?`, `.ok()`, `.unwrap_or_default()`)?
 
-IronClaw convention: `.unwrap()` and `.expect()` are banned in production code. Any occurrence outside `#[cfg(test)]` blocks is a **High severity** finding.
+OptimClaw convention: `.unwrap()` and `.expect()` are banned in production code. Any occurrence outside `#[cfg(test)]` blocks is a **High severity** finding.
 
 ### 5c. SQL and injection vectors
 
@@ -102,7 +102,7 @@ Search for string formatting used in SQL queries, shell commands, or HTML:
 - String interpolation in query construction vs parameterized queries
 - User input flowing into file paths (`Path::new`, `std::fs::`)
 
-IronClaw has two database backends (PostgreSQL and libSQL). Check both for injection vectors.
+OptimClaw has two database backends (PostgreSQL and libSQL). Check both for injection vectors.
 
 ### 5d. Cryptographic issues
 
@@ -125,7 +125,7 @@ If the crate uses crypto:
 - Are errors swallowed silently? (`let _ = ...`, `.ok()` discarding errors that matter)
 - Do error types carry enough context to debug in production?
 - Are there error type mismatches? (returning generic `anyhow::Error` where a typed error would prevent confusion)
-- Is `thiserror` used consistently for error types (IronClaw convention)?
+- Is `thiserror` used consistently for error types (OptimClaw convention)?
 
 ## Step 6: Check for inconsistencies
 
@@ -156,7 +156,7 @@ Look for:
 
 ### 6e. Import style
 
-IronClaw convention: use `crate::` imports, not `super::`. Flag any `super::` imports in non-test code.
+OptimClaw convention: use `crate::` imports, not `super::`. Flag any `super::` imports in non-test code.
 
 ## Step 7: Inspect for change oversights
 
@@ -172,7 +172,7 @@ IronClaw convention: use `crate::` imports, not `super::`. Flag any `super::` im
 - Are there `impl` blocks that look incomplete?
 - Are `Default` implementations sensible?
 
-IronClaw key traits: `Database` (~60 methods), `Channel`, `Tool`, `LlmProvider`, `SuccessEvaluator`, `EmbeddingProvider`. If any new methods were added to `Database`, verify both `postgres.rs` and `libsql_backend.rs` implement them.
+OptimClaw key traits: `Database` (~60 methods), `Channel`, `Tool`, `LlmProvider`, `SuccessEvaluator`, `EmbeddingProvider`. If any new methods were added to `Database`, verify both `postgres.rs` and `libsql_backend.rs` implement them.
 
 ### 7c. Test coverage gaps
 

.claude/commands/review-pr.md

@@ -49,9 +49,9 @@ If the PR touches more than 20 files, still read all of them, but process in thi
 
 Go through the changes with each of these lenses. For every finding, note the file, line range, severity, and a concrete description.
 
-### IronClaw-specific checks
+### OptimClaw-specific checks
 
-In addition to the general lenses below, check IronClaw conventions (see CLAUDE.md):
+In addition to the general lenses below, check OptimClaw conventions (see CLAUDE.md):
 - No `.unwrap()` or `.expect()` in production code (tests are fine)
 - Use `crate::` imports, not `super::`
 - Error types use `thiserror` in `error.rs`

.claude/commands/ship.md

@@ -3,7 +3,7 @@ description: Run the full Rust quality gate (fmt, clippy, tests) before shipping
 allowed-tools: Bash(cargo fmt:*), Bash(cargo clippy:*), Bash(cargo test:*)
 ---
 
-Run the IronClaw shipping checklist. This is the mandatory quality gate before any change is considered done.
+Run the OptimClaw shipping checklist. This is the mandatory quality gate before any change is considered done.
 
 ## Steps
 

.claude/commands/trace.md

@@ -1,15 +1,15 @@
 ---
-description: Trace a data flow or bug through the IronClaw codebase end-to-end
+description: Trace a data flow or bug through the OptimClaw codebase end-to-end
 allowed-tools: Read, Glob, Grep, Bash(cargo test:*)
 argument-hint: <symptom or feature name>
 model: sonnet
 ---
 
-Trace the flow of `$ARGUMENTS` through the IronClaw codebase. Your job is to map every file and function involved, identify where data transforms or could break, and report the full chain.
+Trace the flow of `$ARGUMENTS` through the OptimClaw codebase. Your job is to map every file and function involved, identify where data transforms or could break, and report the full chain.
 
 ## Architecture Reference
 
-IronClaw has three main data flow paths. Identify which one(s) are relevant and trace through them:
+OptimClaw has three main data flow paths. Identify which one(s) are relevant and trace through them:
 
 ### Message Flow (user input to LLM response)
 ```

.claude/rules/skills.md

@@ -11,8 +11,8 @@ SKILL.md files extend the agent's prompt with domain-specific instructions. Each
 
 | Trust Level | Source | Tool Access |
 |-------------|--------|-------------|
-| **Trusted** | User-placed in `~/.ironclaw/skills/` or workspace `skills/` | All tools available to the agent |
-| **Installed** | Downloaded from ClawHub registry (`~/.ironclaw/installed_skills/`) | Read-only tools only (no shell, file write, HTTP) |
+| **Trusted** | User-placed in `~/.optimclaw/skills/` or workspace `skills/` | All tools available to the agent |
+| **Installed** | Downloaded from ClawHub registry (`~/.optimclaw/installed_skills/`) | Read-only tools only (no shell, file write, HTTP) |
 
 ## SKILL.md Format
 

.claude/rules/tools.md

@@ -7,7 +7,7 @@ paths:
 
 **Keep tool-specific logic out of the main agent codebase.** The main agent provides generic infrastructure; tools are self-contained units that declare requirements through `<name>.capabilities.json` sidecar files (in dev mode: `tools-src/<name>/<name>-tool.capabilities.json`).
 
-Tools can be WASM (sandboxed, credential-injected, single binary) or MCP servers (ecosystem, any language, no sandbox). Both are first-class via `ironclaw tool install`.
+Tools can be WASM (sandboxed, credential-injected, single binary) or MCP servers (ecosystem, any language, no sandbox). Both are first-class via `optimclaw tool install`.
 
 See `src/tools/README.md` for full architecture, adding new tools, auth JSON examples, and WASM vs MCP decision guide.