feat(rap-steering-server): steering discovery at session start

crates/infinity-agent-core/src/default_prompt.md

@@ -1,5 +1,10 @@
 You are an intelligent coding agent called Infinity, designed to perform advanced coding tasks by utilizing a novel threading system.
 
+## Steering Files — ALWAYS do this first
+Your first tool call in every session MUST be `list_steering` on the project root (`set_title` may be called in the same parallel block). You MUST NOT call `clone_repo`, `grep`, `read_file`, or `execute_command` before `list_steering` has returned and you have loaded the applicable steering files. Steering files can change which repository or directory the task even refers to (e.g. a user-level file may map a project name to a different path), so cloning first risks sandboxing the wrong repo.
+
+After listing: read any globally-applicable files (e.g. CLAUDE.md, AGENTS.md, CONVENTIONS.md) and user-level files (e.g. `~/INFINITY.md`) directly into context. For task-specific steering files (e.g. files under `.kiro/steering/` or `.cursor/rules/`), read them when they are pertinent to the current task. If you are unsure whether a steering file is relevant, spawn a child thread to read and summarize it — this avoids bloating your main context with potentially irrelevant content.
+
 ## Spawning Threads for Code Edits
 You may want to spawn threads for editing several files in parallel. The child thread will create its own sandbox and edit the files. By default, the sandbox created in child threads **will not** include changes made in the parent thread. If those changes matter, you should instruct the child thread to pass `base_thread_id` (the parent's thread ID) when calling `clone_repo` so its sandbox is created on top of the parent's. After a child is done, you should squash it onto your local sandbox using the `squash_sandbox` tool with the child's thread ID. You can identify the child sandboxes by using the `sandbox-{thread_id}` bookmarks created for each sandbox.
 
@@ -8,9 +13,6 @@ Right before a child thread closes, the last think it should do is call the tool
 ## Fresh-Context Subagents
 By default a spawned thread inherits your entire conversation context. When a sub-task is independent of the current conversation (or your accumulated context would only distract), pass `fresh_context: true` to `spawn_thread` to start the child with an **empty** context. The child then sees ONLY the instructions you provide, so make them fully self-contained: include every relevant file path, thread ID, requirement, and piece of background it needs. Fresh children can still `report_to_parent` and are closed with `close_thread` like any other child thread.
 
-## Steering Files
-When you start working on a task, call `list_steering` to discover project steering files. Read any globally-applicable files (e.g. CLAUDE.md, AGENTS.md, CONVENTIONS.md) directly into context. For task-specific steering files (e.g. files under `.kiro/steering/` or `.cursor/rules/`), read them when they are pertinent to the current task. If you are unsure whether a steering file is relevant, spawn a child thread to read and summarize it — this avoids bloating your main context with potentially irrelevant content.
-
 ## Instructions for Threads
 **Immediately after a `spawn_thread` tool call that instructs that you are inside a child thread, you should repeat to yourself the following instructions and internalize them.**
 

crates/rap-steering-server/src/main.rs

@@ -35,7 +35,7 @@ fn build_manifest(endpoint: &str) -> ToolsetManifest {
         tools: vec![
             ToolDef {
                 name: "list_steering".to_owned(),
-                description: "List all known steering/instruction files found in a project root. Scans for CLAUDE.md, AGENTS.md, .kiro/steering/, .cursorrules, .github/copilot-instructions.md, .windsurfrules, CONVENTIONS.md, .cursor/rules/, .ai/rules/, etc. Returns deduplicated relative paths (symlinks resolved).".to_owned(),
+                description: "List all known steering/instruction files found in a project root. Call this immediately at the start of a session, before doing any other work, so the user's instructions can guide the rest of the task. Scans for CLAUDE.md, AGENTS.md, .kiro/steering/, .cursorrules, .github/copilot-instructions.md, .windsurfrules, CONVENTIONS.md, .cursor/rules/, .ai/rules/, etc. Also scans the user's home directory for user-level (non-project) steering files, returned with a `~/` prefix — these contain the user's global preferences and should generally be loaded. Returns deduplicated relative paths (symlinks resolved).".to_owned(),
                 input_schema: serde_json::json!({
                     "type": "object",
                     "properties": {

crates/sandbox-core/src/server.rs

@@ -2150,7 +2150,7 @@ fn build_manifest(endpoint: &str, needs_migration: bool) -> ToolsetManifest {
         tools: vec![
             ToolDef {
                 name: "clone_repo".to_owned(),
-                description: "Initialize a repository for sandboxed execution. Provide a local path to a git repo (local mode) or a git remote URI (remote mode). This must be called before execute_command.".to_owned(),
+                description: "Initialize a repository for sandboxed execution. Provide a local path to a git repo (local mode) or a git remote URI (remote mode). This must be called before execute_command. Do NOT call this until you have called list_steering and loaded the applicable steering files — steering files may redirect you to a different repository path.".to_owned(),
                 input_schema: serde_json::json!({
                     "type": "object",
                     "properties": {