Document process monitoring handoff
Add ACP discovery and configuration support
This commit is contained in:
Ryan Ward
@@ -1,232 +1,264 @@
|
||||
---
|
||||
name: bring-warp-feature-over
|
||||
description: Identify recent features merged into upstream Warp, assess eligibility for the Galaxy fork, and migrate selected features with Bedrock API adaptations. Use when syncing new Warp functionality into Galaxy.
|
||||
description: Find and selectively port explicitly requested upstream Warp pull requests into Galaxy. Accepts PR/MR numbers or a user-provided feature description, confirms the selected PRs before editing, filters out Warp-only service code, preserves Galaxy's Bedrock/OpenAI/ACP provider architecture and branding, and adapts eligible local changes.
|
||||
---
|
||||
|
||||
# bring-warp-feature-over
|
||||
# Bring a Specific Warp Feature into Galaxy
|
||||
|
||||
Fetches recent upstream Warp changes, filters for eligible features, lets the user pick which to migrate, plans the work, and spawns agents to implement each migration.
|
||||
Use this skill to identify and port selected upstream Warp functionality into Galaxy without performing a broad upstream synchronization.
|
||||
|
||||
## Overview
|
||||
## Required scope
|
||||
|
||||
Galaxy is a fork of Warp that uses AWS Bedrock instead of Warp's proprietary AI APIs. When upstream Warp ships new features, this skill identifies which ones can be brought over, adapts API calls to Bedrock, and replaces Warp-specific branding where needed.
|
||||
The user must provide either:
|
||||
|
||||
## Workflow
|
||||
1. One or more upstream Warp pull request numbers, or
|
||||
2. A description of the feature they want to find upstream.
|
||||
|
||||
### 1. Fetch recent upstream changes
|
||||
Examples:
|
||||
|
||||
Use the GitHub API to pull merged commits from `warpdotdev/warp` on the default branch. Group by PR (commits reference `#<number>`).
|
||||
- `Bring over Warp PR #12345`
|
||||
- `Port PRs 12345 and 12389`
|
||||
- `Find the Warp PR that added terminal search highlighting`
|
||||
- `Bring over the recent worktree picker improvements`
|
||||
|
||||
If the user provides a description, search for candidate PRs and ask the user to confirm the matching PR number(s) before making code changes. Do not scan and port arbitrary recent history.
|
||||
|
||||
## Non-negotiable Galaxy boundaries
|
||||
|
||||
Galaxy-specific architecture always wins. Never replace or bypass:
|
||||
|
||||
- Bedrock provider code in `app/src/ai/bedrock/`
|
||||
- OpenAI/LiteLLM provider code in `app/src/ai/openai/`
|
||||
- ACP provider/runtime code in `app/src/ai/acp/` and the related ACP crate(s)
|
||||
- Provider dispatch and response streaming in `app/src/ai/provider/` and `app/src/ai/blocklist/controller/response_stream.rs`
|
||||
- Galaxy branding, package names, channels, settings, deployment, and installer behavior
|
||||
|
||||
Do not import or preserve new upstream code that depends on:
|
||||
|
||||
- Warp's proprietary AI API or hosted agent backend
|
||||
- Warp authentication, billing, subscriptions, teams, or cloud-only flows
|
||||
- Warp telemetry/analytics that phone home to Warp
|
||||
- Warp server GraphQL/API endpoints unless explicitly adapted to an existing Galaxy service
|
||||
- Warp-specific deployment or branding
|
||||
- Oz/hosted orchestration that Galaxy cannot run locally
|
||||
|
||||
## Phase 0: Inspect the working tree
|
||||
|
||||
Before making changes:
|
||||
|
||||
```bash
|
||||
# Fetch commits from the last N days (default 14)
|
||||
curl -s "https://api.github.com/repos/warpdotdev/warp/commits?per_page=100&since=$(date -u -v-14d +%Y-%m-%dT00:00:00Z)" \
|
||||
| python3 -c "
|
||||
import json, sys
|
||||
data = json.load(sys.stdin)
|
||||
for c in data:
|
||||
sha = c['sha'][:8]
|
||||
msg = c['commit']['message'].split('\n')[0]
|
||||
date = c['commit']['author']['date'][:10]
|
||||
print(f'{date} {sha} {msg}')
|
||||
"
|
||||
git --no-optional-locks status --short --branch
|
||||
```
|
||||
|
||||
If the user specifies a date range or number of days, adjust the `since` parameter. For longer lookups, paginate with `&page=2`, etc.
|
||||
Do not overwrite unrelated user work. If the working tree is dirty, keep existing changes intact and use a separate branch where possible.
|
||||
|
||||
## Phase 1: Resolve the requested scope
|
||||
|
||||
### If PR/MR numbers were provided
|
||||
|
||||
Use the supplied numbers directly. Do not search unrelated upstream history.
|
||||
|
||||
### If a feature description was provided
|
||||
|
||||
Search upstream GitHub for matching Warp PRs. Prefer the GitHub search API, using a concise query derived from the user’s description:
|
||||
|
||||
To get more detail on a specific PR:
|
||||
```bash
|
||||
curl -s "https://api.github.com/repos/warpdotdev/warp/pulls/<PR_NUMBER>" | python3 -c "
|
||||
import json, sys
|
||||
pr = json.load(sys.stdin)
|
||||
print(pr.get('title'))
|
||||
print(pr.get('body','')[:2000])
|
||||
"
|
||||
curl -sS --get 'https://api.github.com/search/issues' \
|
||||
--data-urlencode 'q=<keywords> repo:warpdotdev/warp is:pr' \
|
||||
--data-urlencode 'per_page=10'
|
||||
```
|
||||
|
||||
To see the files changed in a PR:
|
||||
If authentication or API rate limits prevent the search, use the public GitHub web search URL or fetch recent commit/PR metadata as a fallback. Keep the search bounded by the user’s description; do not enumerate the entire repository history.
|
||||
|
||||
For each candidate, collect:
|
||||
|
||||
- PR number and title
|
||||
- State and merge status
|
||||
- Updated/merged date
|
||||
- Body excerpt
|
||||
- Labels, when available
|
||||
- Changed-file summary
|
||||
|
||||
Inspect candidate files before presenting them:
|
||||
|
||||
```bash
|
||||
curl -s "https://api.github.com/repos/warpdotdev/warp/pulls/<PR_NUMBER>/files" | python3 -c "
|
||||
import json, sys
|
||||
files = json.load(sys.stdin)
|
||||
for f in files:
|
||||
print(f['status'], f['filename'])
|
||||
"
|
||||
curl -sS "https://api.github.com/repos/warpdotdev/warp/pulls/<PR>"
|
||||
curl -sS "https://api.github.com/repos/warpdotdev/warp/pulls/<PR>/files?per_page=100"
|
||||
```
|
||||
|
||||
### 2. Assess eligibility
|
||||
Present a short ranked list with the reason each candidate matches and its likely adaptation cost. Then ask for confirmation, for example:
|
||||
|
||||
For each feature/PR, determine eligibility. A feature is **ineligible** if:
|
||||
```text
|
||||
I found these likely matches:
|
||||
|
||||
- It depends on Warp's server APIs that we don't have access to (e.g. `warp-server` endpoints, GraphQL mutations for Warp Cloud services)
|
||||
- It's specific to "Warp Drive" syncing infrastructure (unless it can be adapted to "Galaxy Drive")
|
||||
- It references "Oz" orchestration that relies on Warp's hosted agent backend
|
||||
- It requires Warp's proprietary AI proxy and cannot be redirected to Bedrock
|
||||
- It's purely a Warp billing, subscription, or team management feature
|
||||
- It touches WASM-only paths that Galaxy doesn't ship
|
||||
1. #12345 — Improve terminal search highlighting
|
||||
Matches the requested behavior; mostly local terminal/UI code. Low adaptation cost.
|
||||
|
||||
A feature **is eligible** if:
|
||||
2. #12389 — Add cloud search synchronization
|
||||
Related wording, but depends on Warp cloud APIs. Likely ineligible.
|
||||
|
||||
- It's a client-side UX improvement (terminal, editor, completions, themes, settings)
|
||||
- It's an AI feature that calls a model API we can route through Bedrock (Claude, etc.)
|
||||
- It's a local-only feature (git integration, file system, SSH, etc.)
|
||||
- It's a bug fix applicable to shared code paths
|
||||
- It touches "Warp Drive" but can be rebranded to "Galaxy Drive"
|
||||
|
||||
When assessing, also note the **adaptation cost**:
|
||||
- **Low**: Drop-in (UI fix, terminal behavior, keybindings)
|
||||
- **Medium**: Needs Bedrock API mapping or minor branding changes
|
||||
- **High**: Significant refactoring of server-dependent code to work with Bedrock
|
||||
|
||||
### 3. Present feature checklist to user
|
||||
|
||||
After assessment, present the eligible features to the user using `AskUserQuestion` with `multiSelect: true`. Group by adaptation cost. Include the PR title and a one-line summary of what it does.
|
||||
|
||||
Example:
|
||||
```
|
||||
Which features would you like to bring over?
|
||||
|
||||
Low effort:
|
||||
- [ ] #10958 - Make worktree menu paths readable for long entries
|
||||
- [ ] #11099 - Clip terminal view column to prevent split-pane footer overflow
|
||||
|
||||
Medium effort:
|
||||
- [ ] #11049 - Add sleep auto handoff to cloud (needs Bedrock adaptation)
|
||||
|
||||
High effort:
|
||||
- [ ] #10857 - Add orchestration create environment modal (heavy server dependency)
|
||||
Which PR(s) should I port? Reply with the number(s), or say “none”.
|
||||
```
|
||||
|
||||
### 4. Research selected features
|
||||
Do not create a branch, apply patches, or edit source files until the user confirms the selected PR number(s). Research and recommendation are allowed before confirmation.
|
||||
|
||||
For each selected feature, perform detailed research:
|
||||
If the search returns no confident match, say so and ask for a PR link, more keywords, or clarification. Do not guess.
|
||||
|
||||
1. **Read the PR diff** — use the GitHub API to understand what changed:
|
||||
## Phase 2: Fetch and inspect only the confirmed PRs
|
||||
|
||||
After the user confirms PR numbers, fetch upstream refs if needed:
|
||||
|
||||
```bash
|
||||
git fetch warp master
|
||||
```
|
||||
|
||||
For each confirmed PR, inspect:
|
||||
|
||||
- PR title, state, merge commit, and description
|
||||
- Files changed and additions/deletions
|
||||
- New dependencies, feature flags, migrations, or generated files
|
||||
- Whether the change is local-only or depends on Warp services
|
||||
- Whether Galaxy has renamed or diverged from the affected paths
|
||||
|
||||
For local context:
|
||||
|
||||
```bash
|
||||
git log --oneline --all -- <path>
|
||||
git diff HEAD...warp/master -- <path>
|
||||
```
|
||||
|
||||
## Phase 3: Eligibility decision
|
||||
|
||||
Classify each confirmed PR as one of:
|
||||
|
||||
### Eligible: direct port
|
||||
|
||||
Usually local terminal, editor, UI, completion, parser, filesystem, SSH, theme, or platform bug fixes with limited dependencies.
|
||||
|
||||
### Eligible: adapted port
|
||||
|
||||
Useful functionality that touches Galaxy provider or branding boundaries but can be redirected safely to Bedrock, OpenAI/LiteLLM, or ACP. Document the adaptation before editing.
|
||||
|
||||
### Ineligible
|
||||
|
||||
Reject the PR, or only extract isolated local hunks, when it fundamentally depends on Warp-only services such as hosted AI, Warp auth, billing, telemetry, server GraphQL, Warp Drive infrastructure, or Oz orchestration.
|
||||
|
||||
When a PR mixes eligible and ineligible changes, do not cherry-pick the whole PR. Port only the eligible files or hunks manually.
|
||||
|
||||
Summarize the decision before implementation. If the user asked to implement and the PR is clearly eligible, proceed after the PR confirmation. If the PR has meaningful adaptation risk, explain the risk and ask before making substantial changes.
|
||||
|
||||
## Phase 4: Create a focused working branch
|
||||
|
||||
Before source changes:
|
||||
|
||||
```bash
|
||||
git switch -c port-warp-pr-<PR>
|
||||
```
|
||||
|
||||
For multiple PRs, use a descriptive branch containing all numbers, or apply them sequentially on one focused branch.
|
||||
|
||||
Do not commit unless the user explicitly requests it.
|
||||
|
||||
## Phase 5: Apply the smallest safe change
|
||||
|
||||
Prefer these strategies in order:
|
||||
|
||||
1. Cherry-pick without committing only when the PR is narrowly scoped and service-free:
|
||||
```bash
|
||||
curl -s "https://api.github.com/repos/warpdotdev/warp/pulls/<PR>/files?per_page=100"
|
||||
git cherry-pick -n <merge-commit-or-commit>
|
||||
```
|
||||
2. Apply only eligible paths:
|
||||
```bash
|
||||
git diff <base> <commit> -- <eligible-paths> | git apply --3way
|
||||
```
|
||||
3. Manually port the relevant hunks when Galaxy renamed paths, has diverged, or the PR mixes service and local changes.
|
||||
|
||||
2. **Map to local files** — identify corresponding files in our Galaxy fork. Check if the files exist and what state they're in.
|
||||
Do not use a blanket `git merge warp/master` for this skill.
|
||||
|
||||
3. **Identify Bedrock adaptations** — if the feature makes AI/model calls, document:
|
||||
- What model is being called and how
|
||||
- What the equivalent Bedrock invocation looks like
|
||||
- What request/response transformations are needed
|
||||
Preserve Galaxy naming and adapt upstream imports where necessary:
|
||||
|
||||
4. **Identify branding changes** — flag any references to:
|
||||
- "Warp Drive" → "Galaxy Drive"
|
||||
- "Oz" → remove or replace
|
||||
- Warp-specific UI copy that needs updating
|
||||
- `warpui` → `galaxyui`
|
||||
- `warpui_core` → `galaxyui_core`
|
||||
- `warp_core` → `galaxy_core`
|
||||
- `warp_terminal` → `galaxy_terminal`
|
||||
- `warp_editor` → `galaxy_editor`
|
||||
|
||||
5. **Document dependencies** — note any new crates, feature flags, or config changes needed.
|
||||
Do not perform repository-wide renames as part of a feature port.
|
||||
|
||||
### 5. Write migration plans
|
||||
## Provider-specific adaptation rules
|
||||
|
||||
For each selected feature, create a plan file at:
|
||||
```
|
||||
plans/warp-migrations/<PR_NUMBER>-<short-slug>.md
|
||||
```
|
||||
### Bedrock and OpenAI/LiteLLM
|
||||
|
||||
Each plan should contain:
|
||||
A PR that adds AI behavior must use Galaxy’s provider dispatch. Adapt request/response types to the existing provider interfaces rather than importing Warp’s AI client or endpoint.
|
||||
|
||||
```markdown
|
||||
# Migration: <PR Title>
|
||||
### ACP
|
||||
|
||||
**Source PR**: warpdotdev/warp#<number>
|
||||
**Adaptation Cost**: Low | Medium | High
|
||||
**Date Assessed**: <today>
|
||||
ACP changes are allowed only when they preserve Galaxy’s ACP runtime, transport, launch, and model-selection architecture. Do not replace ACP with Warp’s hosted agent service or introduce a Warp-specific backend. Inspect relevant files under `app/src/ai/acp/` and the ACP crate before applying upstream changes.
|
||||
|
||||
## Summary
|
||||
<What the feature does, 2-3 sentences>
|
||||
### Shared agent/blocklist code
|
||||
|
||||
## Files Changed (upstream)
|
||||
<List of files from the PR>
|
||||
Treat `app/src/ai/agent/` and `app/src/ai/blocklist/` as manual-merge areas. Keep Galaxy’s provider selection, tool handling, persistence, and ACP integration intact even when adopting local UX or controller improvements.
|
||||
|
||||
## Local File Mapping
|
||||
<Corresponding Galaxy files, noting any that don't exist yet>
|
||||
## API and service leak checks
|
||||
|
||||
## Required Adaptations
|
||||
- <Bedrock changes if any>
|
||||
- <Branding changes if any>
|
||||
- <New dependencies if any>
|
||||
|
||||
## Implementation Steps
|
||||
1. <Step 1>
|
||||
2. <Step 2>
|
||||
...
|
||||
|
||||
## Testing Notes
|
||||
<How to verify this works in Galaxy>
|
||||
```
|
||||
|
||||
### 6. Spawn implementation agents
|
||||
|
||||
For each migration plan, spawn an agent using the `Agent` tool to make the code changes. Key rules for spawning:
|
||||
|
||||
- **Agents only write code** — they do NOT run `cargo check`, `cargo build`, or `cargo clippy`
|
||||
- **Spawn agents in parallel** for independent features (no shared file conflicts)
|
||||
- **Spawn sequentially** if two features touch the same files
|
||||
- Each agent's prompt must include:
|
||||
- The full migration plan content
|
||||
- The specific files to modify and what changes to make
|
||||
- Instructions to NOT run cargo commands
|
||||
- Instructions to report back what files were changed
|
||||
|
||||
Example agent prompt structure:
|
||||
```
|
||||
You are implementing a Warp feature migration into the Galaxy fork.
|
||||
|
||||
Migration plan:
|
||||
<paste plan content>
|
||||
|
||||
Instructions:
|
||||
- Make ONLY the code changes described in the plan
|
||||
- Do NOT run cargo check, cargo build, cargo clippy, or any compilation commands
|
||||
- Adapt any Warp API calls to use Bedrock (see plan for specifics)
|
||||
- Replace "Warp Drive" with "Galaxy Drive" where applicable
|
||||
- Remove or skip any "Oz" references
|
||||
- Report back: list all files you modified and a brief summary of changes
|
||||
```
|
||||
|
||||
### 7. Verify builds (parent agent only)
|
||||
|
||||
After all implementation agents complete, the parent agent (you) runs:
|
||||
Review new code before accepting it:
|
||||
|
||||
```bash
|
||||
cargo fmt
|
||||
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings
|
||||
grep -RInE 'api\.warp\.dev|warp\.dev/v1|WarpAIService|WarpAiClient|WARP_API_KEY|WARP_AUTH_TOKEN' app/src crates --include='*.rs'
|
||||
```
|
||||
|
||||
If there are errors, fix them directly or re-delegate targeted fixes to agents.
|
||||
New hits introduced by the port must be removed or adapted. Do not mechanically remove existing compatibility names without checking their purpose.
|
||||
|
||||
### 8. Instruct user to test
|
||||
## Dependencies and generated files
|
||||
|
||||
After a clean build, present the user with testing instructions:
|
||||
For each new dependency:
|
||||
|
||||
- List each migrated feature and how to exercise it
|
||||
- Note any features that need specific configuration or feature flags enabled
|
||||
- Ask the user to report back any issues they find
|
||||
- Remind them to test with `cargo run` and verify the features work end-to-end
|
||||
1. Check whether Galaxy already has an equivalent.
|
||||
2. Add the smallest local/client-side dependency needed.
|
||||
3. Reject dependencies that exist only for Warp services, hosted AI, auth, telemetry, or billing.
|
||||
4. Regenerate code only when the PR genuinely changes a Galaxy-supported schema or generated source.
|
||||
|
||||
## Branding Reference
|
||||
## Validation
|
||||
|
||||
| Upstream (Warp) | Galaxy equivalent |
|
||||
|-----------------------|-----------------------|
|
||||
| Warp Drive | Galaxy Drive |
|
||||
| Oz / Orchestrator | Remove or skip |
|
||||
| Warp AI / Warp Agent | Galaxy AI / Agent |
|
||||
| warp-server endpoints | Skip (ineligible) |
|
||||
Run focused checks based on changed files:
|
||||
|
||||
## Bedrock Adaptation Patterns
|
||||
```bash
|
||||
git diff --check
|
||||
cargo fmt --all -- --check
|
||||
```
|
||||
|
||||
When adapting AI features from Warp's proxy to Bedrock:
|
||||
Typical targeted checks include:
|
||||
|
||||
- Warp's AI calls typically go through their proxy server — Galaxy calls Bedrock directly
|
||||
- Look for the existing Bedrock integration patterns in `app/src/ai/` for how Galaxy makes model calls
|
||||
- Ensure streaming responses are handled correctly (Bedrock uses different event formats)
|
||||
- Check `WARP.md` "Bedrock Diagnostics" section for debugging tools
|
||||
```bash
|
||||
cargo check -p galaxy_terminal
|
||||
cargo check -p galaxyui
|
||||
cargo check -p galaxy_editor
|
||||
cargo check -p galaxy
|
||||
```
|
||||
|
||||
## Related Skills
|
||||
Also check the ACP crate or affected package when ACP files change. Use the actual package names from the relevant `Cargo.toml` files.
|
||||
|
||||
- `fix-errors` — for resolving build failures after migration
|
||||
- `add-feature-flag` — if the migrated feature needs gating
|
||||
- `implement-specs` — for larger features that need full specs
|
||||
For a release-ready port, run:
|
||||
|
||||
```bash
|
||||
./script/format
|
||||
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings
|
||||
cargo build
|
||||
```
|
||||
|
||||
Fix errors caused by the port, but do not pull in excluded Warp service code to make the build pass.
|
||||
|
||||
## Output report
|
||||
|
||||
Report:
|
||||
|
||||
- Search description, candidate PRs, and the user’s confirmed selection
|
||||
- Eligibility decision for each selected PR
|
||||
- Files and hunks ported
|
||||
- Bedrock/OpenAI/ACP adaptations made, if any
|
||||
- Warp-only changes intentionally skipped
|
||||
- Dependencies or generated files changed
|
||||
- Validation commands and results
|
||||
- Any follow-up work or manual testing needed
|
||||
|
||||
If a requested PR is too intertwined with Warp's service architecture, recommend a smaller follow-up port or explain which local hunks can be extracted safely.
|
||||
|
||||
@@ -1,387 +1,216 @@
|
||||
---
|
||||
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.
|
||||
description: Selectively synchronize Galaxy with upstream Warp by updating Rust dependencies and porting eligible terminal, UI, editor, and local core improvements. Do not perform a blanket merge or import Warp API, proprietary AI, cloud auth, telemetry, or billing code.
|
||||
---
|
||||
|
||||
# Update Galaxy with Latest Warp
|
||||
# Selectively Update Galaxy from 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:
|
||||
Galaxy is a fork of Warp, but it intentionally does not use Warp's proprietary service architecture. The default update strategy is therefore **not** `git merge warp/master`. It is a controlled, selective synchronization focused on code that can run locally in Galaxy.
|
||||
|
||||
- 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
|
||||
## Non-negotiable exclusions
|
||||
|
||||
---
|
||||
Never import or reintroduce upstream code that depends on:
|
||||
|
||||
## Phase 1: Fetch Latest Warp
|
||||
- Warp's proprietary AI API, agent backend, or hosted orchestration
|
||||
- Warp authentication, subscriptions, billing, teams, or cloud-only flows
|
||||
- Warp telemetry or analytics that phone home to Warp
|
||||
- Warp server GraphQL/API endpoints, unless the change is explicitly adapted to an existing Galaxy service
|
||||
- Warp-specific deployment, channel, branding, or package identity
|
||||
- Any change that would replace or bypass Galaxy's Bedrock/OpenAI provider dispatch
|
||||
|
||||
The `warp` remote is already configured in this repository pointing to `git@github.com:warpdotdev/warp.git`.
|
||||
Galaxy's AI provider implementation remains authoritative in:
|
||||
|
||||
- `app/src/ai/bedrock/`
|
||||
- `app/src/ai/openai/`
|
||||
- `app/src/ai/provider/`
|
||||
- `app/src/ai/blocklist/controller/response_stream.rs`
|
||||
|
||||
## Phase 0: Inspect the working tree
|
||||
|
||||
Before changing anything:
|
||||
|
||||
```bash
|
||||
git --no-optional-locks status --short --branch
|
||||
```
|
||||
|
||||
Do not overwrite or reset user changes. If the worktree contains unrelated modifications, keep them intact and make the update in a separate branch or ask the user before proceeding.
|
||||
|
||||
## Phase 1: Update Rust dependencies separately
|
||||
|
||||
A dependency update is independent from synchronizing upstream source code. Run it from the Galaxy repository root:
|
||||
|
||||
```bash
|
||||
cargo update
|
||||
```
|
||||
|
||||
Then inspect the dependency diff:
|
||||
|
||||
```bash
|
||||
git diff -- Cargo.lock
|
||||
cargo check --workspace
|
||||
```
|
||||
|
||||
If `cargo update` causes unrelated or excessive churn, do not blindly keep it. Prefer targeted updates for a specific dependency:
|
||||
|
||||
```bash
|
||||
cargo update -p <package>
|
||||
```
|
||||
|
||||
If the lockfile update is useful but a package causes breakage, revert only that package's update or restore the lockfile and update dependencies incrementally. Never use a lockfile regeneration as a substitute for source synchronization.
|
||||
|
||||
`cargo update` updates crates.io/git dependency resolution; it does **not** bring terminal or UI source changes from Warp. Those require the selective workflow below.
|
||||
|
||||
## Phase 2: Fetch and inventory upstream changes
|
||||
|
||||
The `warp` remote may be configured, but fetching is read-only with respect to Galaxy's branches:
|
||||
|
||||
```bash
|
||||
git fetch warp master
|
||||
git log --oneline -30 warp/master
|
||||
```
|
||||
|
||||
Verify the fetch succeeded and note the latest commit:
|
||||
Compare upstream with the Galaxy base without merging:
|
||||
|
||||
```bash
|
||||
git log --oneline -1 warp/master
|
||||
git diff --stat HEAD...warp/master
|
||||
git diff --name-status HEAD...warp/master
|
||||
```
|
||||
|
||||
---
|
||||
Classify candidate changes by path and commit. Good candidates generally include:
|
||||
|
||||
## Phase 2: Create a Working Branch
|
||||
- `app/src/terminal/` and terminal model/emulation code, excluding agent/provider integrations
|
||||
- `crates/galaxy_terminal/` or the corresponding upstream terminal crate
|
||||
- `crates/galaxyui/`, `crates/galaxyui_core/`, and UI components
|
||||
- `crates/editor/`, `crates/sum_tree/`, completers, parsers, and local utilities
|
||||
- Local-only bug fixes and platform behavior fixes
|
||||
|
||||
Create a dedicated branch for the merge work:
|
||||
Reject candidates that touch or depend on:
|
||||
|
||||
- Warp AI/server/auth/telemetry/billing modules
|
||||
- Warp-specific GraphQL/API schema or cloud synchronization
|
||||
- Galaxy identity, channels, settings, deployment, or Bedrock/OpenAI files
|
||||
- Broad refactors whose dependency surface cannot be isolated safely
|
||||
|
||||
For a candidate commit, inspect before applying it:
|
||||
|
||||
```bash
|
||||
git checkout -b update-from-warp-$(date +%Y%m%d) master
|
||||
git show --stat --summary <commit>
|
||||
git show --format=fuller --find-renames <commit> -- <path>
|
||||
```
|
||||
|
||||
This ensures master stays clean until we have a working build.
|
||||
## Phase 3: Apply only selected changes
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Merge Warp into Galaxy
|
||||
|
||||
Perform the merge, expecting conflicts:
|
||||
Create a working branch before porting source changes:
|
||||
|
||||
```bash
|
||||
git merge warp/master --no-commit --no-ff
|
||||
git switch -c update-from-warp-$(date +%Y%m%d)
|
||||
```
|
||||
|
||||
Using `--no-commit` so we can inspect and fix everything before committing.
|
||||
Prefer, in order:
|
||||
|
||||
---
|
||||
1. A focused upstream commit with a small, eligible file set:
|
||||
```bash
|
||||
git cherry-pick -n <commit>
|
||||
```
|
||||
2. A file- or hunk-level patch:
|
||||
```bash
|
||||
git diff <base> <commit> -- <eligible-paths> | git apply --3way
|
||||
```
|
||||
3. A manual port when Galaxy renamed paths or diverged substantially.
|
||||
|
||||
## Phase 4: Resolve Conflicts — Galaxy Always Wins on Identity
|
||||
Do **not** cherry-pick a commit merely because it includes one useful terminal fix. If a commit mixes terminal code with Warp API/AI/cloud changes, extract only the eligible hunks or manually port the local change.
|
||||
|
||||
When resolving merge conflicts, follow these **non-negotiable rules**:
|
||||
After each selected change:
|
||||
|
||||
### 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>
|
||||
git diff --check
|
||||
cargo check -p galaxy_terminal
|
||||
cargo check -p galaxyui
|
||||
cargo check -p galaxy_editor
|
||||
```
|
||||
|
||||
### 4b. Files Where Warp Wins (take theirs)
|
||||
Use the actual package name from the relevant `Cargo.toml` if it differs. For changes affecting the application, also run:
|
||||
|
||||
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>
|
||||
cargo check -p galaxy
|
||||
```
|
||||
|
||||
### 4c. Files That Need Manual Merge
|
||||
## Path and naming adaptation
|
||||
|
||||
These require reading both versions and combining:
|
||||
Upstream may still use Warp names while Galaxy has renamed crates and paths. Adapt imports to Galaxy's existing names rather than introducing new aliases or reverting Galaxy's naming:
|
||||
|
||||
- `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
|
||||
- `warpui` → `galaxyui`
|
||||
- `warpui_core` → `galaxyui_core`
|
||||
- `warp_core` → `galaxy_core`
|
||||
- `warp_terminal` → `galaxy_terminal`
|
||||
- `warp_editor` → `galaxy_editor`
|
||||
|
||||
### 4d. Files/Directories to DELETE if Warp Adds Them
|
||||
Preserve existing Galaxy aliases only where the codebase already requires them. Do not perform a repository-wide rename as part of an update.
|
||||
|
||||
If the merge introduces any of these, remove them:
|
||||
## Dependency policy
|
||||
|
||||
- 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`
|
||||
When a selected upstream change needs a new dependency:
|
||||
|
||||
1. Check whether an equivalent dependency already exists in the Galaxy workspace.
|
||||
2. Add only the smallest required dependency or feature.
|
||||
3. Confirm it is local/client-side and not a Warp service crate.
|
||||
4. Run the narrowest affected `cargo check`.
|
||||
|
||||
Do not add dependencies for Warp's proprietary APIs, cloud auth, telemetry, billing, or hosted AI.
|
||||
|
||||
## AI and service boundary review
|
||||
|
||||
Before accepting a patch that touches shared app or agent code, inspect all new imports and calls. It must route AI requests through Galaxy's provider dispatch. Reject or adapt code containing concepts such as:
|
||||
|
||||
- `api.warp.dev`, `warp.dev/v1`, Warp AI clients, hosted agent endpoints
|
||||
- Warp auth tokens or Warp account/session APIs
|
||||
- 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.)
|
||||
- Warp billing/subscription/team APIs
|
||||
- Hosted orchestration/Oz dependencies
|
||||
|
||||
Useful checks:
|
||||
|
||||
```bash
|
||||
git rm -r <unwanted_path>
|
||||
grep -RInE 'api\.warp\.dev|warp\.dev/v1|WarpAIService|WarpAiClient|WARP_API_KEY|WARP_AUTH_TOKEN' app/src crates --include='*.rs'
|
||||
```
|
||||
|
||||
### 4e. Naming Fixups After Merge
|
||||
Existing intentional compatibility names or comments should be reviewed rather than mechanically deleted. New hits introduced by the update must be removed or adapted.
|
||||
|
||||
After resolving conflicts, some Warp naming may have leaked in from theirs-wins files. Do a sweep:
|
||||
## Phase 4: Validation
|
||||
|
||||
Run focused checks first, then broader validation as appropriate:
|
||||
|
||||
```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"
|
||||
cargo fmt --all -- --check
|
||||
git diff --check
|
||||
cargo check -p galaxy
|
||||
cargo check -p galaxy_terminal
|
||||
cargo check -p galaxyui
|
||||
cargo check -p galaxy_editor
|
||||
```
|
||||
|
||||
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
|
||||
For a release-ready update, run the repository-required checks:
|
||||
|
||||
```bash
|
||||
./script/format
|
||||
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings
|
||||
cargo build
|
||||
```
|
||||
|
||||
### 7c. Verify no Warp API leaks
|
||||
If the build fails, fix only errors caused by the selected update. Do not solve incompatibilities by importing excluded Warp service code or weakening Galaxy's provider boundaries.
|
||||
|
||||
```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"
|
||||
```
|
||||
## Reporting
|
||||
|
||||
Any hits must be removed.
|
||||
Report separately:
|
||||
|
||||
### 7d. Verify Galaxy's AI providers still work
|
||||
- Dependencies updated by `cargo update`, including notable lockfile changes
|
||||
- Upstream commits or patches selectively ported
|
||||
- Files and functionality intentionally skipped because they were Warp-specific
|
||||
- Validation commands run and their results
|
||||
- Any candidate changes that need a future manual port
|
||||
|
||||
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()`
|
||||
Do not commit, push, or merge into `master` unless the user explicitly requests it.
|
||||
|
||||
### 7e. Quick smoke test
|
||||
## Recommended fallback
|
||||
|
||||
```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.
|
||||
If upstream has accumulated a large architectural delta, stop doing a broad synchronization. Use the `bring-warp-feature-over` skill to identify and migrate individual eligible features. That workflow is safer for Galaxy than attempting to reconcile all of Warp's unrelated service and AI changes at once.
|
||||
|
||||
Reference in New Issue
Block a user