Rename pull_warp_feature skill to update-galaxy-with-latest-warp
Rewrote the skill from a single-feature porting tool into a full upstream merge workflow that: - Fetches and merges latest warp/master - Resolves conflicts preserving Galaxy's AI providers (Bedrock/OpenAI-LiteLLM) - Strips any Warp API/auth/telemetry additions - Iteratively repairs the build until cargo build succeeds - Runs clippy/format/leak checks before committing
This commit is contained in:
Ryan Ward
@@ -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 <file_path>
|
||||||
|
git add <file_path>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 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 <file_path>
|
||||||
|
git add <file_path>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 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 <unwanted_path>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 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 <crate_name> 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 -- <file_path>
|
||||||
|
```
|
||||||
|
|
||||||
|
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.
|
||||||
@@ -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/<feature>/`
|
|
||||||
- Project-scoped data: `.galaxy/<feature>/` (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 <crate_name>
|
|
||||||
```
|
|
||||||
|
|
||||||
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 <crate_name>
|
|
||||||
```
|
|
||||||
|
|
||||||
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" <changed_files>
|
|
||||||
grep -rn "api\.warp" <changed_files>
|
|
||||||
grep -rn "warpdotdev" <changed_files>
|
|
||||||
grep -rn "warp-server" <changed_files>
|
|
||||||
grep -rn "WARP_API" <changed_files>
|
|
||||||
grep -rn "warp_api" <changed_files>
|
|
||||||
```
|
|
||||||
|
|
||||||
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/<feature_name>/`
|
|
||||||
- **Project-scoped state**: `<project_root>/.galaxy/<feature_name>/` (must be gitignored)
|
|
||||||
- **Structured persistent data**: Use Diesel ORM + SQLite via `app/src/persistence/`
|
|
||||||
- **Cached/temporary data**: `$TMPDIR/galaxy_<feature_name>/`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 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
|
|
||||||
Reference in New Issue
Block a user