diff --git a/.agents/skills/update-galaxy-with-latest-warp/SKILL.md b/.agents/skills/update-galaxy-with-latest-warp/SKILL.md new file mode 100644 index 00000000..787781b3 --- /dev/null +++ b/.agents/skills/update-galaxy-with-latest-warp/SKILL.md @@ -0,0 +1,387 @@ +--- +name: update-galaxy-with-latest-warp +description: Merge the latest changes from upstream Warp into Galaxy, preserving Galaxy's identity, branding, and AI provider architecture (Bedrock / OpenAI-LiteLLM only). This skill fetches the latest Warp master, merges it in, resolves conflicts in favor of Galaxy's customizations, strips any Warp API/AI/cloud code, and then iteratively repairs the build until `cargo build` succeeds cleanly. +--- + +# Update Galaxy with Latest Warp + +This skill merges the latest upstream Warp changes into Galaxy while preserving everything that makes Galaxy what it is. Galaxy is a fork of Warp that: + +- Uses **Amazon Bedrock** and/or **OpenAI/LiteLLM** as its AI providers — NEVER Warp's proprietary AI API +- Has its own branding (Galaxy, not Warp) in user-facing surfaces +- Does NOT use Warp's cloud authentication, telemetry, or billing +- Maintains its own deployment pipeline (Hermes) +- Keeps all Galaxy-specific features, settings, and customizations intact + +--- + +## Phase 1: Fetch Latest Warp + +The `warp` remote is already configured in this repository pointing to `git@github.com:warpdotdev/warp.git`. + +```bash +git fetch warp master +``` + +Verify the fetch succeeded and note the latest commit: + +```bash +git log --oneline -1 warp/master +``` + +--- + +## Phase 2: Create a Working Branch + +Create a dedicated branch for the merge work: + +```bash +git checkout -b update-from-warp-$(date +%Y%m%d) master +``` + +This ensures master stays clean until we have a working build. + +--- + +## Phase 3: Merge Warp into Galaxy + +Perform the merge, expecting conflicts: + +```bash +git merge warp/master --no-commit --no-ff +``` + +Using `--no-commit` so we can inspect and fix everything before committing. + +--- + +## Phase 4: Resolve Conflicts — Galaxy Always Wins on Identity + +When resolving merge conflicts, follow these **non-negotiable rules**: + +### 4a. Files Where Galaxy ALWAYS Wins (keep ours) + +For these files/patterns, always take Galaxy's version (`--ours`): + +- `app/Cargo.toml` — Galaxy's version, package name, binary targets +- `Cargo.lock` — Will be regenerated anyway +- `AGENTS.md` / `CLAUDE.md` — Galaxy's agent instructions +- `.agents/` — Galaxy's skill definitions +- `script/build-and-deploy-hermes*` — Galaxy's deploy pipeline +- `script/install-galaxy.sh` — Galaxy's installer +- `app/channels/` — Galaxy's channel configurations and icons +- Any file under `app/src/ai/bedrock/` — Galaxy's Bedrock provider (keep ours) +- Any file under `app/src/ai/openai/` — Galaxy's OpenAI/LiteLLM provider (keep ours) +- Any file under `app/src/ai/provider/` — Galaxy's provider dispatch (keep ours) +- `app/src/ai/llms.rs` — Galaxy's model registry (keep ours) +- `app/src/settings/ai.rs` — Galaxy's AI settings (keep ours) +- `app/src/ai/blocklist/controller/response_stream.rs` — Galaxy's provider resolution (keep ours) +- Files with Samsung/Galaxy branding customizations + +To resolve these in bulk: +```bash +git checkout --ours +git add +``` + +### 4b. Files Where Warp Wins (take theirs) + +For pure infrastructure/terminal/UI improvements that don't touch AI or branding: + +- `crates/galaxyui/` (formerly `warpui`) — Take Warp's UI improvements, then rename +- `crates/galaxyui_core/` — Same +- `app/src/terminal/` — Terminal emulation improvements (EXCEPT `app/src/terminal/input/agent.rs`) +- `crates/editor/` — Editor improvements +- `crates/sum_tree/` — Data structure improvements +- Pure algorithm / utility crates + +For these: +```bash +git checkout --theirs +git add +``` + +### 4c. Files That Need Manual Merge + +These require reading both versions and combining: + +- `app/src/ai/agent/` — Take Warp's agent logic improvements BUT ensure they route through Galaxy's provider dispatch, not Warp's API +- `app/src/ai/blocklist/` — Similar: take improvements but keep Galaxy's provider architecture +- `app/src/workspace/` — Take improvements but keep Galaxy branding +- `app/src/settings_view/` — Take UI improvements but keep Galaxy's AI settings pages +- Root `Cargo.toml` — Merge new dependencies from Warp but keep Galaxy's workspace metadata + +### 4d. Files/Directories to DELETE if Warp Adds Them + +If the merge introduces any of these, remove them: + +- Any Warp-proprietary AI client (e.g. `app/src/ai/warp_api/`, `app/src/ai/warp_server/`) +- Warp authentication modules that phone home to `api.warp.dev` +- Warp telemetry/analytics senders +- Warp billing/subscription code +- Any new GraphQL queries targeting Warp's server for AI (model listing from Warp's API, etc.) + +```bash +git rm -r +``` + +### 4e. Naming Fixups After Merge + +After resolving conflicts, some Warp naming may have leaked in from theirs-wins files. Do a sweep: + +```bash +# Check for Warp API endpoints that should not exist +grep -rn "api\.warp\.dev" app/ crates/ --include="*.rs" +grep -rn "warp\.dev/api" app/ crates/ --include="*.rs" + +# Check for Warp AI service calls +grep -rn "WarpAIService\|warp_ai_service\|WarpAiClient" app/ crates/ --include="*.rs" +``` + +Fix any hits — either remove the code or replace with Galaxy equivalents. + +--- + +## Phase 5: Regenerate Cargo.lock + +After all conflict resolution: + +```bash +cargo generate-lockfile +``` + +Or if that fails due to errors, just delete and let the build recreate it: + +```bash +rm Cargo.lock +cargo metadata --format-version 1 > /dev/null 2>&1 || true +``` + +--- + +## Phase 6: Build Repair Loop + +This is the critical phase. **Keep iterating until `cargo build` succeeds.** + +### Strategy + +Run the build and fix errors one category at a time: + +```bash +cargo build 2>&1 | head -100 +``` + +### Common Error Categories and Fixes + +**1. Missing modules / unresolved imports:** +- Warp may have added new modules. Check if they're AI/cloud related → delete them. +- If they're legitimate (terminal, UI, utilities) → keep them but ensure they compile. +- If they reference renamed crates (`warpui` vs `galaxyui`) → fix the import paths. + +**2. Type mismatches in AI code:** +- Warp may have changed AI types/traits. Galaxy's AI architecture takes priority. +- If Warp added new fields to shared types used by both AI and non-AI code, add the fields but make them optional or provide Galaxy-appropriate defaults. + +**3. Missing crate features:** +- New Warp code may need features not enabled in Galaxy's `Cargo.toml`. +- Add the features if they're for legitimate crates. Do NOT add features that enable Warp-proprietary functionality. + +**4. Renamed/moved items:** +- Warp may have refactored. Follow their refactoring for non-AI code. +- For AI code, keep Galaxy's structure. + +**5. New dependencies:** +- If Warp added a new crate to `[workspace.dependencies]`, add it to Galaxy's too (unless it's a Warp-internal crate). + +**6. Compilation errors in files we took from Warp:** +- These files may reference things that exist in Warp but not Galaxy. +- Stub out or adapt as needed. + +### The Loop + +Repeat this cycle until clean: + +``` +1. cargo build 2>&1 | head -80 +2. Identify the FIRST error +3. Fix it +4. Go to 1 +``` + +When individual crate errors are isolated, use targeted checks to speed up: + +```bash +cargo check -p 2>&1 | head -50 +``` + +**IMPORTANT**: If you encounter more than 50 errors in a single file that all stem from Warp's AI API being absent, the correct fix is usually to **revert that file to Galaxy's version**: + +```bash +git checkout HEAD~1 -- +``` + +Or if the file is new from Warp and entirely AI-API-dependent, just delete it. + +--- + +## Phase 7: Post-Build Verification + +Once `cargo build` succeeds: + +### 7a. Run clippy + +```bash +cargo clippy --workspace --all-targets --all-features --tests -- -D warnings 2>&1 | head -100 +``` + +Fix any warnings. Repeat until clean. + +### 7b. Run formatter + +```bash +./script/format +``` + +### 7c. Verify no Warp API leaks + +```bash +grep -rn "api\.warp\.dev" app/src/ crates/ --include="*.rs" | grep -v "// ported from" +grep -rn "warp\.dev/v1" app/src/ crates/ --include="*.rs" +grep -rn "WARP_API_KEY\|WARP_AUTH_TOKEN" app/src/ crates/ --include="*.rs" +``` + +Any hits must be removed. + +### 7d. Verify Galaxy's AI providers still work + +Ensure these files are intact and functional: +- `app/src/ai/bedrock/translator.rs` — Bedrock orchestrator +- `app/src/ai/bedrock/client.rs` — AWS SDK client +- `app/src/ai/bedrock/request_translator.rs` — Request builder +- `app/src/ai/bedrock/response_translator.rs` — Response parser +- `app/src/ai/openai/translator.rs` — OpenAI/LiteLLM orchestrator +- `app/src/ai/openai/client.rs` — HTTP client +- `app/src/ai/openai/convert.rs` — Message conversion +- `app/src/ai/openai/response_translator.rs` — SSE parser +- `app/src/ai/provider/mod.rs` — Provider dispatch +- `app/src/ai/provider/types.rs` — Shared types +- `app/src/ai/blocklist/controller/response_stream.rs` — `resolve_provider_config()` + +### 7e. Quick smoke test + +```bash +cargo build --release 2>&1 | tail -5 +``` + +If release build also passes, we're good. + +--- + +## Phase 8: Commit and Report + +Once everything is clean: + +```bash +git add -A +git commit -m "Merge latest Warp upstream into Galaxy + +Merged warp/master ($(git log --oneline -1 warp/master | cut -d' ' -f1)) into Galaxy. + +Kept Galaxy's: +- AI provider architecture (Bedrock + OpenAI/LiteLLM) +- Branding and deployment pipeline +- Settings and model configuration + +Took from Warp: +- Terminal emulation improvements +- UI framework updates +- Editor and utility improvements +- Bug fixes + +Stripped: +- Any Warp API/cloud/auth/telemetry additions" +``` + +Then inform the user of: +- What was merged +- What conflicts were resolved and how +- What Warp additions were rejected/stripped +- Whether any manual follow-up is needed + +Ask the user if they want to merge this branch into master: + +```bash +git checkout master +git merge update-from-warp-$(date +%Y%m%d) +git push +``` + +--- + +## Critical Invariants — NEVER Violate These + +1. **Galaxy's AI MUST only use Bedrock or OpenAI/LiteLLM** — defined in `app/src/ai/bedrock/` and `app/src/ai/openai/`. Warp's AI API/server calls are NEVER acceptable. + +2. **Galaxy's version and package name stay as-is** — `app/Cargo.toml` keeps `name = "galaxy"` and Galaxy's version number. + +3. **Galaxy's binary targets stay as-is** — `galaxy-oss`, `galaxy-dev`, `galaxy-preview`, `galaxy-stable`. + +4. **No Warp telemetry** — Any analytics/tracking code from Warp gets deleted, not commented out. + +5. **No Warp authentication flows** — Galaxy does not phone home to Warp's servers. + +6. **Galaxy's deploy pipeline is untouched** — `script/build-and-deploy-hermes*` and `script/install-galaxy.sh` are always kept. + +7. **The build MUST succeed before this skill is considered complete** — If the build is broken, keep fixing. Do not stop. + +--- + +## Failure Recovery + +If the merge becomes unrecoverable (e.g., Warp has done a massive architectural change that breaks everything): + +1. Abort the merge: + ```bash + git merge --abort + ``` + +2. Or reset the branch: + ```bash + git checkout master + git branch -D update-from-warp-$(date +%Y%m%d) + ``` + +3. Inform the user that a manual, selective port is needed instead of a full merge. + +4. Suggest using the `bring-warp-feature-over` skill to cherry-pick specific improvements instead. + +--- + +## Reference: Galaxy ↔ Warp Name Mapping + +- `warp` (package) → `galaxy` +- `warp_core` → `galaxy_core` +- `warpui` → `galaxyui` +- `warpui_core` → `galaxyui_core` +- `warp_features` → `galaxy_features` +- `warp_completer` → `galaxy_completer` +- `warp_graphql_schema` → `galaxy_graphql_schema` +- `WARP_` env var prefix → `GALAXY_` +- `~/.warp/` → `~/.galaxy-ai/` +- `warp.sqlite` → `galaxy.sqlite` +- Binary names: `warp` → `galaxy-oss` (main), `galaxy-dev`, `galaxy-preview`, `galaxy-stable` + +## Reference: Galaxy's AI Architecture + +``` +Provider dispatch: response_stream.rs → resolve_provider_config() → ProviderConfig enum + ↓ Bedrock ↓ OpenAI + bedrock/translator.rs openai/translator.rs +``` + +- Settings: `ai.bedrock.enabled` (default true), `ai.openai.enabled` (takes priority if true) +- Multi-provider: `ai.providers[]` array with per-provider `base_url`, `api_key`, `models[]` +- Model discovery: OpenAI providers probe `/models` endpoint + `[1m]` variant detection +- Bedrock: Direct AWS SDK calls via `aws-sdk-bedrockruntime`, uses cross-region inference + +This architecture is SACRED. Warp's AI changes must never replace or bypass it. diff --git a/.warp/skills/pull_warp_feature/SKILL.md b/.warp/skills/pull_warp_feature/SKILL.md deleted file mode 100644 index d7c8320e..00000000 --- a/.warp/skills/pull_warp_feature/SKILL.md +++ /dev/null @@ -1,360 +0,0 @@ ---- -name: pull_warp_feature -description: Pull a feature from the upstream Warp codebase into the Galaxy fork. Use this skill whenever the user wants to port, backport, or bring over a feature from Warp into Galaxy. This skill handles cloning the Warp source, analyzing the feature for Warp-specific dependencies, planning safe replacements, and implementing the port. ---- - -# Pull Warp Feature into Galaxy - -This skill orchestrates porting a feature from the upstream Warp terminal (github.com/warpdotdev/warp) into the Galaxy fork. It is intentionally cautious — Galaxy MUST NOT contain any Warp-proprietary service dependencies, Warp API calls, or Warp cloud infrastructure ties. - ---- - -## Phase 1: Acquire Warp Source - -Before anything else, ensure a clean copy of the Warp source exists locally for reference. - -### Steps - -1. Check if `.galaxy/warp-upstream/` already exists in the project root: - -```bash -ls -d .galaxy/warp-upstream/.git 2>/dev/null -``` - -2. **If it does NOT exist**, clone the Warp repo: - -```bash -mkdir -p .galaxy -git clone --depth 1 https://github.com/warpdotdev/warp.git .galaxy/warp-upstream -``` - - Use `--depth 1` to keep it lightweight. If deeper history is needed for a specific feature, deepen later with `git fetch --unshallow`. - -3. **If it DOES exist**, pull latest: - -```bash -git -C .galaxy/warp-upstream pull --ff-only -``` - -4. **Ensure `.galaxy/` is gitignored.** Check `.gitignore` for a `.galaxy/` entry. If missing, append it: - -```bash -echo ".galaxy/" >> .gitignore -``` - - IMPORTANT: Verify the line doesn't already exist before appending. Use `grep -q "^\.galaxy/" .gitignore` first. - -5. **NEVER commit the `.galaxy/` directory or its contents.** It is a local-only reference checkout. - ---- - -## Phase 2: Identify the Feature - -Once the Warp source is available, ask the user: - -> **What feature are you looking at bringing over?** - -Wait for the user's response. Do NOT proceed until you have a clear answer. - -### Interpreting the response - -- The user may describe the feature by name (e.g. "tab drag and drop", "AI suggestions", "voice input"). -- The user may reference a specific file, module, or PR number. -- The user may describe behavior they saw in Warp and want in Galaxy. - -Accept any of these as valid starting points. - ---- - -## Phase 3: Deep Feature Analysis - -Once you know the target feature, perform a thorough investigation. You need to build a complete dependency map before making any promises. - -### 3a. Locate the feature in Warp source - -Search the Warp source at `.galaxy/warp-upstream/` for the feature: - -- Use `grep`, `codebase_semantic_search`, and `file_glob` against `.galaxy/warp-upstream/` -- Read the relevant source files in full -- Identify the entry points, data models, UI components, and backend calls -- Map out every file the feature touches - -### 3b. Locate the corresponding code in Galaxy - -Search the Galaxy codebase to understand: - -- Does Galaxy already have a partial implementation of this feature? -- What Galaxy modules correspond to the Warp modules this feature touches? -- Are there naming differences? (e.g. `warp_core` → `galaxy_core`, `WarpUI` → `GalaxyUI`) - -### 3c. Build the dependency inventory - -For EVERY dependency the feature has, categorize it into one of these buckets: - -**✅ SAFE — No changes needed:** -- Pure UI logic (elements, views, event handlers) -- Local computation (parsers, formatters, algorithms) -- Terminal emulation logic -- Platform-native APIs (macOS, Windows, Linux) -- Local filesystem operations -- Open-source crate dependencies already in Galaxy's `Cargo.toml` - -**⚠️ REQUIRES REPLACEMENT — Can be ported with modification:** -- Warp AI / LLM calls → Must be replaced with Amazon Bedrock via `BedrockClient` -- Warp API HTTP endpoints → Must be removed or replaced with local storage -- Warp Drive cloud sync → Must be replaced with local `.galaxy/` storage or removed -- Warp authentication/identity → Must be removed or replaced with Galaxy auth -- Warp telemetry/analytics → Must be removed entirely -- Warp-specific feature flags → Must be converted to Galaxy `FeatureFlag` enum variants -- GraphQL queries to Warp server → Must be removed or rerouted - -**🚫 BLOCKED — Cannot be ported:** -- Features that fundamentally require Warp's proprietary backend to function -- Features that require Warp's authentication tokens with no Bedrock/local alternative -- Features requiring real-time sync with Warp's cloud that cannot be made local -- Warp billing/subscription gating logic - -### 3d. Ask follow-up questions - -Based on your analysis, ask the user clarifying questions. These might include: - -- "This feature uses Warp's X service — do you want me to replace it with Y, or skip that part?" -- "There are two sub-features here: A and B. A is clean to port, B requires major rework. Want both?" -- "The Warp version uses cloud storage for Z. Should I store this in `~/.galaxy-ai/` or `.galaxy/`?" -- "This depends on crate X which isn't in Galaxy yet. OK to add it?" - -Do NOT proceed until the user has answered your follow-up questions and you are confident you understand the scope. - ---- - -## Phase 4: Compatibility Assessment - -This is the most critical phase. You must produce a detailed assessment. Go through EVERY dependency from Phase 3c and make a concrete determination. - -### 4a. AI/LLM Dependencies - -If the feature uses Warp AI in any way: - -1. **Identify every AI call site** — What prompts are sent? What models are used? What's the expected response format? -2. **Determine if Bedrock can handle it** — Galaxy uses `BedrockClient::converse_stream` (see `app/src/ai/bedrock/client.rs`). The feature's AI usage MUST be expressible as Bedrock Converse API calls. -3. **Check for Warp-specific prompt engineering** — System prompts in Warp may reference Warp-specific context. These must be rewritten for Galaxy. -4. **Check for Warp-specific tool use** — If the feature defines custom AI tools, verify they don't call Warp APIs internally. -5. **Verdict**: Can it be "Bedrockified"? If NO → the feature CANNOT be ported. Stop and inform the user. - -Key files for Bedrock integration reference: -- `app/src/ai/bedrock/client.rs` — Client implementation -- `app/src/ai/bedrock/convert_request.rs` — Request construction and system prompts -- `app/src/ai/bedrock/convert.rs` — Wire format conversion -- `app/src/ai/bedrock/tool_docs.rs` — Tool documentation -- `app/src/ai/bedrock/stream.rs` — Response stream processing - -### 4b. Cloud Storage / Warp API Dependencies - -If the feature calls Warp API endpoints or uses Warp Drive: - -1. **List every HTTP/GraphQL call** the feature makes to Warp servers -2. **For each call, determine:** - - Can it be removed entirely without breaking the feature? - - Can it be replaced with local file storage in `~/.galaxy-ai/` or project-local `.galaxy/`? - - Can it be replaced with a different API (e.g. direct AWS call)? -3. **If it requires Warp server and there's no local alternative** → that specific sub-feature CANNOT be ported -4. **Local storage patterns to use:** - - User-scoped data: `~/.galaxy-ai//` - - Project-scoped data: `.galaxy//` (ensure gitignored) - - SQLite via Diesel: `app/src/persistence/` (for data that fits Galaxy's existing DB) - -### 4c. Authentication Dependencies - -If the feature requires Warp authentication: - -1. Does Galaxy have its own auth that can substitute? -2. If the feature gates on "is the user logged in" — can this gate be removed? -3. If the feature requires user identity — can it use a local config value instead? - -### 4d. Telemetry / Analytics - -Any Warp telemetry, analytics, or tracking code MUST be stripped entirely. Do not replace it — remove it. - -### 4e. Naming and Branding - -All references to "Warp" in user-facing strings, comments, and identifiers must be changed to "Galaxy": -- `warp` → `galaxy` -- `Warp` → `Galaxy` -- `WARP` → `GALAXY` -- `warp_core` → `galaxy_core` -- `WarpUI` → `GalaxyUI` -- etc. - -This includes: -- Rust module names and paths -- Struct/enum/function names -- String literals shown to users -- Comments and documentation -- Environment variable prefixes (`WARP_` → `GALAXY_`) -- Config file paths (`~/.warp/` → `~/.galaxy-ai/`) - ---- - -## Phase 5: Present Findings and Plan - -Present the user with a structured summary using the `create_plan` tool. The plan MUST include: - -1. **Feature summary**: What the feature does in Warp, in 2-3 sentences -2. **Files to port**: Exact list of files from `.galaxy/warp-upstream/` and where they map in Galaxy -3. **Dependency assessment table** (as a list, not a markdown table): - - For each dependency: what it is, its category (SAFE / REQUIRES REPLACEMENT / BLOCKED), and the replacement strategy -4. **AI assessment**: Does it need AI? Can it be Bedrockified? What changes are needed? -5. **Cloud/API assessment**: Does it call Warp servers? What's the local replacement? -6. **Storage assessment**: Where will data live? What gets gitignored? -7. **Risk areas**: What might break? What needs extra testing? -8. **Estimated scope**: How many files are touched? Is this a 1-hour or 1-week port? - -**CRITICAL**: Do NOT proceed to implementation until the user explicitly approves the plan. - -If any part of the feature is BLOCKED, clearly state: -> "The following parts of this feature CANNOT be ported because they fundamentally require Warp's proprietary infrastructure: [list]. I recommend porting only the parts that are SAFE or REQUIRES REPLACEMENT." - ---- - -## Phase 6: Implementation - -Only after the user approves the plan, begin implementation. - -### Implementation Rules - -These rules are NON-NEGOTIABLE: - -1. **NEVER copy Warp API URLs, tokens, or endpoint paths into Galaxy code.** -2. **NEVER leave Warp telemetry/analytics calls in the code, even commented out.** -3. **NEVER leave `warp` branding in user-facing strings.** Internal code comments referencing the upstream origin (e.g. "Ported from Warp's X module") are acceptable. -4. **ALL AI calls MUST go through `BedrockClient`** — no direct OpenAI, Anthropic, or other provider calls. -5. **ALL cloud storage MUST be local** — `~/.galaxy-ai/` for user data, `.galaxy/` for project data, or Diesel/SQLite for persistent structured data. -6. **ALL feature flags MUST use Galaxy's `FeatureFlag` enum** in `galaxy_features/src/lib.rs`. -7. **ALL environment variables MUST use the `GALAXY_` prefix.** -8. **ALL config paths MUST use `~/.galaxy-ai/`** not `~/.warp/`. - -### Implementation Procedure - -1. **Create a TODO list** with discrete steps for the port. - -2. **Port files one module at a time**, in dependency order (deepest dependencies first, UI last): - - Copy the file from `.galaxy/warp-upstream/` to the correct Galaxy location - - Rename all Warp references to Galaxy equivalents - - Replace all REQUIRES REPLACEMENT dependencies with Galaxy alternatives - - Remove all BLOCKED dependencies and any code paths that depend on them - - Ensure all `use` / `mod` statements point to Galaxy crate names - -3. **After each module**, verify it compiles: - ```bash - cargo check -p - ``` - -4. **After all modules are ported**, run full workspace checks: - ```bash - cargo fmt - cargo clippy --workspace --all-targets --all-features --tests -- -D warnings - ``` - -5. **If the feature has tests in Warp**, port the tests too: - - Place tests in `${filename}_tests.rs` per Galaxy convention - - Update test assertions to reflect Galaxy behavior (no Warp API mocking) - - Run tests: - ```bash - cargo nextest run --no-fail-fast -p - ``` - -6. **Update documentation**: - - Update `GALAXY.md` if the feature changes architecture or adds commands - - Update `WARP.md` if it exists and needs corresponding changes - - Update `CLAUDE.md` if it exists in the project - -7. **Final validation**: - ```bash - cargo build - cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2 - ``` - -### Post-Implementation Audit - -After implementation, perform a final audit. Search the entire diff for: - -```bash -# In the changed files, search for any Warp leaks -grep -rn "warp\.dev" -grep -rn "api\.warp" -grep -rn "warpdotdev" -grep -rn "warp-server" -grep -rn "WARP_API" -grep -rn "warp_api" -``` - -Any hits (other than comments documenting the port origin) are bugs that must be fixed before completion. - -Also verify no `.galaxy/` files were staged: - -```bash -git status --porcelain | grep "^A.*\.galaxy/" -``` - ---- - -## Reference: Galaxy ↔ Warp Name Mapping - -Common renames when porting: - -- `warp` → `galaxy` (crate names, binary names) -- `warp_core` → `galaxy_core` -- `warpui` → `galaxyui` -- `warpui_core` → `galaxyui_core` -- `warpui_extras` → `galaxyui_extras` -- `warp_terminal` → `galaxy_terminal` -- `warp_util` → `galaxy_util` -- `warp_features` → `galaxy_features` -- `warp_completer` → `galaxy_completer` -- `warp_graphql_schema` → `galaxy_graphql_schema` -- `warp_cli` → `galaxy_cli` -- `WARP_` prefix env vars → `GALAXY_` -- `~/.warp/` → `~/.galaxy-ai/` -- Warp AI server endpoints → `BedrockClient::converse_stream` -- Warp Drive → local storage in `~/.galaxy-ai/` or `.galaxy/` -- `WarpAI` / `warp_ai` → `GalaxyAI` / `galaxy_ai` - -## Reference: Bedrock Integration Points - -When replacing Warp AI calls with Bedrock: - -- Client: `app/src/ai/bedrock/client.rs` — `BedrockClient::converse_stream` -- Request building: `app/src/ai/bedrock/convert_request.rs` -- Response parsing: `app/src/ai/bedrock/stream.rs` -- Tool definitions: `app/src/ai/bedrock/tool_docs.rs` -- AWS credentials: `app/src/ai/aws_credentials.rs` -- Model selection: `app/src/ai/llms.rs` - -All AI features MUST flow through these modules. Direct HTTP calls to any LLM provider are forbidden. - -## Reference: Local Storage Patterns - -When replacing Warp cloud storage: - -- **User preferences / global state**: `~/.galaxy-ai//` -- **Project-scoped state**: `/.galaxy//` (must be gitignored) -- **Structured persistent data**: Use Diesel ORM + SQLite via `app/src/persistence/` -- **Cached/temporary data**: `$TMPDIR/galaxy_/` - ---- - -## Failure Modes — When to STOP - -STOP the port and inform the user if: - -1. The feature's core functionality requires real-time communication with Warp's servers and there is no local alternative. -2. The feature's AI usage cannot be expressed as Bedrock Converse API calls (e.g. it requires fine-tuned Warp-specific models with no public equivalent). -3. The feature depends on Warp-proprietary data formats or protocols that are not documented in the open-source repo. -4. Porting the feature would require modifying more than 30% of Galaxy's existing codebase — this suggests architectural incompatibility. -5. The feature's tests all depend on Warp server mocks that have no Galaxy equivalent, making it untestable. - -In these cases, present the user with: -- WHY the port is blocked -- WHICH specific dependency is the blocker -- WHETHER a partial port (subset of functionality) is viable -- WHAT alternative approaches might achieve similar UX without the blocked dependency