/tech.md`. See [`specs/GH408/`](specs/GH408/), [`specs/GH1063/`](specs/GH1063/), and [`specs/GH1066/`](specs/GH1066/) for examples of well-structured specs, and browse the rest of [`specs/`](specs/) for more. After common skills are installed, the `/write-product-spec` and `/write-tech-spec` skills are available to scaffold these for you.
-2. Use the PR as the home for product and technical discussion.
-3. Once the specs are approved, implementation generally continues on the same PR. In rarer cases — for example, if a large spec is merged on its own so the implementation can be broken up — it can move to a linked follow-up PR.
-
-## Opening a Code PR
-
-For issues labeled `ready-to-implement`:
-
-1. Branch from `master`.
-2. Implement the change and add tests (see [Testing](#testing)).
-3. Run `./script/presubmit` and fix any failures before pushing.
-4. Open a PR using the [pull request template](.github/pull_request_template.md) and add a changelog entry (`CHANGELOG-NEW-FEATURE`, `CHANGELOG-IMPROVEMENT`, or `CHANGELOG-BUG-FIX`); omit only for docs-only or refactoring-only changes.
-5. Keep the PR focused on a single logical change and merge `master` in before the PR enters review.
-
-You **do not need to manually request reviewers**. Oz is auto-assigned to PRs that target a ready issue and produces an initial review. After Oz approves, it automatically requests a follow-up review from the appropriate Warp team subject-matter expert.
-
-After you push changes that address Oz's feedback, comment `/oz-review` on the PR to request a re-review — you can do this up to **three times** per PR. If something looks stuck or you need more reviews than that, mention **@oss-maintainers** on the PR to escalate to the team.
-
-**You must include proof of [manual testing](#manual-testing)**. For small, isolated, and visual changes, you should include **before and after screenshots**. For larger, broad, or interactive changes, you should also include a **narrated screen recording**.
-
-If a maintainer requests changes to your PR, you will need to request `/oz-review` again and pass it before a re-review can be requested. Oz will request the re-review for you automatically once you pass its reviews.
-
-### PRs opened without a linked issue
-
-We require PRs to be linked to an associated issue. This is where problems get scoped, [readiness labels](#readiness-labels) get applied, and some features go through a [spec phase](#opening-a-spec-pr) before any code is written. See the [Contribution Flow](#contribution-flow) for the full picture.
-
-That said, if you open a PR ahead of the standard issue workflow, here's what we recommend:
-
-First, **search for a related issue.** Due to the volume of issues we receive, there's often an existing issue for a given feature or bug fix. If you find one, link it in your PR description. Ideally, this issue will have been reviewed by a maintainer with a [readiness label](#readiness-labels) applied. If you do not find a related issue, file an issue describing what your PR resolves. Once a maintainer has reviewed the issue and associated PR, we can apply a readiness label to unblock final checks.
-
-Then, **ensure your PR passes code review and includes relevant tests** per our [Opening a Code PR guide.](#opening-a-code-pr) If code review passes and relevant tests are present, that's high signal for us to review your work sooner.
-
-## Using a Coding Agent
-
-You can use **any coding agent** to implement a contribution — for example, Warp's built-in agent, Claude Code, Codex, Gemini CLI, or others — or no agent at all. This repository ships agent-readable context (skills under [`.agents/skills/`](.agents/skills/), specs under [`specs/`](specs/), and [`AGENTS.md`](AGENTS.md)) that any harness supporting these formats can pick up.
-
-If you'd rather have an **Oz cloud agent** implement a ready issue for you, mention **@oss-maintainers** on the issue to request it. Approved requests run **for free** on complimentary Oz credits — you don't need to set up your own Oz account or pay for compute.
-
-While you can use coding agents for implementation, we expect contributors to **collaborate with us personally**. This means that you should not be using agents like OpenClaw to engage in conversation with our team. Our maintainers will always talk to you as a human, so please talk to us as a human as well.
-
-## Code Review
-
-All pull requests go through a two-stage review process:
-
-1. **Oz review** — When you open a PR, [Oz](https://warp.dev/oz) is automatically assigned and produces the first review. Oz checks for correctness, style, test coverage, and alignment with the linked issue and any associated specs.
-2. **Warp team review** — Only after Oz has **approved** the PR is it routed to a Warp team subject-matter expert for a final human review. PRs that have not yet been approved by Oz will not be assigned to a team member.
-
-You do not need to manually request reviewers at any stage. After pushing changes that address Oz's feedback, comment `/oz-review` on the PR to request a re-review — you can do this up to **three times** per PR. If something looks stuck or you need additional reviews, mention **@oss-maintainers** on the PR to escalate to the team.
-
-### Stale PRs with requested changes
-
-If a review (from Oz or a maintainer) leaves your PR with **changes requested** and it then goes quiet, automation follows up and eventually closes it so the review queue stays current. This applies only to external-contributor PRs with an active requested-changes review.
-
-- **Reminders** are posted at **7** and **10** days of inactivity, with the **day-10 reminder serving as the final warning**.
-- The PR is **automatically closed at ~14 days** of inactivity — but only after that final warning, so you always get a heads-up first.
-- Only **your** activity resets the timer: pushing to your branch (including a force-push) or commenting on the PR. Maintainer comments don't reset it, since the PR is waiting on you.
-- To keep a PR open, just push updates or reply. A closed PR can be reopened when you're ready to continue (reopen it and push, or ask a maintainer to reopen).
-- Maintainers can apply the **`no-autoclose`** label to exempt a PR that should stay open (for example, when it's blocked on us).
-
-## Development Setup
-
-See [README.md](README.md) and [AGENTS.md](AGENTS.md) for the full engineering guide. Quick start:
+## Development setup
```bash
-./script/bootstrap # platform-specific setup
-cargo run # build and run Warp
-./script/presubmit # fmt, clippy, and tests
+./script/bootstrap
+cargo run
```
-## Testing
+The project is a Rust workspace with the main client in `app/`, GalaxyUI in `crates/galaxyui/`,
+and shared libraries under `crates/`. The default build must work without a Galaxy account or a
+remote service.
-Tests are required for most code changes:
+## Making changes
-### Manual Testing
-Manual testing is required for changes that can be manually tested, and almost all changes can be manually tested. For small, isolated, and visual changes, you should include **before and after screenshots**. For larger, broad, or interactive changes, you should also include a **narrated screen recording**.
+Keep changes focused and preserve the local-first boundaries:
-You can run the app locally using `./script/run` - see [AGENTS.md](AGENTS.md) for more details on how to get set up.
+- Model traffic may use only a provider explicitly configured by the user.
+- Galaxy owns permission prompts and execution for shell, file, and MCP actions.
+- Local content should use the local repository instead of cloud identity or sync services.
+- New UI should reuse existing GalaxyUI components, theme tokens, and button themes.
+- Never log credentials, prompts, command output, or provider responses unless a diagnostic mode
+ explicitly documents that behavior.
-### Automated Tests
-- **Bug fixes** should include a regression test that would have caught the bug.
-- **Algorithmic or non-trivial logic** needs unit tests.
-- **User-facing flows** should have end-to-end coverage under [`crates/integration/`](crates/integration/) whenever the behavior can be exercised that way. The bar is high-quality coverage of the changes you ship — with agent-driven development the expectation is more integration tests, not just coverage of P0 paths. If a flow is worth shipping, it's usually worth an integration test.
+For user-facing changes, verify the complete flow manually. Include screenshots for small visual
+changes and a short recording for larger interactive flows when practical. For persistence,
+provider, or agent-runtime changes, add restart, failure, cancellation, or boundary coverage as
+appropriate.
-Run unit tests with `cargo nextest run`.
+## Checks
-## Code Style
+Run the focused checks for the code you touched, then run the required formatting and lint checks:
-- `./script/format --check` and `cargo clippy --workspace --all-targets --all-features --tests -- -D warnings` must pass.
-- Prefer imports over path qualifiers, inline format args (`println!("{x}")`), and exhaustive `match` over `_` wildcards.
-- See [AGENTS.md](AGENTS.md) for the full style guide, including WarpUI patterns and terminal model locking rules.
+```bash
+./script/format
+cargo clippy --workspace --all-targets --all-features --tests -- -D warnings
+cargo test
+```
-## Commit and Branch Conventions
+Useful narrower commands include:
-- Branch names should be prefixed with your handle (e.g. `alice/fix-parser`).
-- Commit messages should explain *what* and *why*, not just *what*.
+```bash
+cargo check -p galaxy
+cargo test -p galaxy --lib
+cargo test -p galaxy_agent_core
+cargo test -p galaxy_agent_rig
+```
-## Code of Conduct
+If a check cannot run locally, explain why in the change description and include the closest
+available validation.
-This project adopts the [Contributor Covenant](https://www.contributor-covenant.org/) (v2.1) as its code of conduct. All contributors and maintainers are expected to follow it in every project space. See [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md) for the full text, or report violations to warp-coc at warp.dev.
+## Pull requests
-## Reporting Security Issues
+Use a branch named for the change, keep commits focused, and include:
-See [`SECURITY.md`](SECURITY.md) for our security disclosure policy and private reporting channels. **Do not open public issues for security vulnerabilities.**
+1. A concise summary of the user-visible behavior.
+2. The design or architectural boundary affected.
+3. Automated checks and manual verification performed.
+4. Screenshots or recordings for visual and interactive changes.
+5. Any follow-up work added to the relevant plan or noticed-bugs list.
-## Getting Help
+Reviewers should be able to build the branch from a clean checkout and understand why the change
+belongs in Galaxy. Do not include unrelated formatting or generated-file churn.
-- Chat with other contributors and the Warp team in [`#oss-contributors`](https://warpcommunity.slack.com/archives/C0B0LM8N4DB) on the [Warp Slack community](https://go.warp.dev/join-preview) (join the workspace first if you're new).
-- Browse the [Warp docs](https://docs.warp.dev/).
-- Open a [GitHub issue](https://github.com/warpdotdev/warp/issues) for bugs or feature requests.
+## Code of conduct
+
+Galaxy follows the [Contributor Covenant](CODE_OF_CONDUCT.md). Please keep issue, review, and
+community discussions respectful, constructive, and focused on the work.
+
+## License
+
+The Galaxy application and most workspace crates are licensed under
+[AGPL-3.0-only](LICENSE-AGPL). The GalaxyUI crates are licensed under the
+[MIT License](LICENSE-MIT). Contributions are accepted under the license applicable to the code
+they modify. Review the existing file headers and third-party notices before copying code into a
+different crate.
diff --git a/README.md b/README.md
index 228ec9d8..781f8ab0 100644
--- a/README.md
+++ b/README.md
@@ -1,112 +1,65 @@
-
- 
-
-
-
- 
-
- 
-
+# Galaxy
-
- Website
- ·
- Code
- ·
- Agents
- ·
- Terminal
- ·
- Drive
- ·
- Docs
- ·
- How Warp Works
-
+Galaxy is a local-first developer terminal with an agent that works alongside your shell. It is
+designed to keep your conversations, settings, and personal workspace data on your machine while
+letting you explicitly connect the model providers and local agents you choose.
-> [!NOTE]
-> OpenAI is the founding sponsor of the new, open-source Warp repository, and the new agentic management workflows are powered by GPT models.
+## What Galaxy provides
-
+- A fast terminal, editor, and local workspace for development.
+- Agent conversations with Galaxy-owned permissions for shell, file, and MCP actions.
+- Provider connections for ChatGPT subscriptions, OpenAI-compatible APIs, Anthropic, Gemini,
+ Vertex AI, AWS Bedrock, and ACP agent runtimes.
+- Local Galaxy Drive content, including rules, profiles, notebooks, workflows, and MCP settings.
+- Explicit network boundaries: model traffic goes only to configured providers, and network tools
+ remain opt-in.
-## About
+## Building from source
-[Warp](https://www.warp.dev) is an agentic development environment, born out of the terminal. Use Warp's built-in coding agent, or bring your own CLI agent (Claude Code, Codex, Gemini CLI, and others).
+Galaxy is a Rust workspace. Platform setup and the common development tools are installed with:
-## Installation
+```bash
+./script/bootstrap
+```
-You can [download Warp](https://www.warp.dev/download) and [read our docs](https://docs.warp.dev/) for platform-specific instructions.
+Then build or run the client with:
-## Warp Contributions Overview Dashboard
+```bash
+cargo run
+```
-Explore [build.warp.dev](https://build.warp.dev) to:
-- Watch thousands of Oz agents triage issues, write specs, implement changes, and review PRs
-- View top contributors and in-flight features
-- Track your own issues with GitHub sign-in
-- Click into active agent sessions in a web-compiled Warp terminal
+Before submitting changes, run the repository checks:
-## Oz for OSS
+```bash
+./script/format
+cargo clippy --workspace --all-targets --all-features --tests -- -D warnings
+cargo test
+```
-Maintaining a popular open-source project? [Apply for Oz credits](https://tally.so/r/LZWxqG) to explore [Oz for OSS](https://github.com/warpdotdev/oz-for-oss).
+See [AGENTS.md](AGENTS.md) for architecture notes, platform setup, coding conventions, and the
+focused commands used by the project.
-Oz for OSS is our partner program for bringing the same agentic open-source management workflows used in this repository to select partner repositories. We work directly with maintainers to implement workflows for issue triage, PR review, community management, and contributor coordination in a way that fits each project.
+## Contributing
+
+Please read [CONTRIBUTING.md](CONTRIBUTING.md) before opening a change. Bug reports should include
+reproduction steps, expected and actual behavior, platform details, and relevant logs or
+screenshots that do not contain secrets. Security issues must be reported privately according to
+[SECURITY.md](SECURITY.md).
+
+UI changes should include manual verification, and visual changes should include before-and-after
+screenshots when practical. Changes to local persistence, provider boundaries, or agent execution
+should include focused automated coverage.
## Licensing
-Warp's UI framework (the `warpui_core` and `warpui` crates) are licensed under the [MIT license](LICENSE-MIT).
+The Galaxy application and most workspace crates are licensed under
+[AGPL-3.0-only](LICENSE-AGPL). The GalaxyUI crates are licensed under the
+[MIT License](LICENSE-MIT). Individual third-party components retain the licenses required by
+their respective notices and source files.
-The rest of the code in this repository is licensed under the [AGPL v3](LICENSE-AGPL).
+## Project direction
-## Open Source & Contributing
-
-Warp's client codebase is open source and lives in this repository. We welcome community contributions and have designed a lightweight workflow to help new contributors get started. For the full contribution flow, read our [CONTRIBUTING.md](CONTRIBUTING.md) guide.
-
-> [!TIP]
-> **Chat with contributors and the Warp team** in the [`#oss-contributors`](https://warpcommunity.slack.com/archives/C0B0LM8N4DB) Slack channel — a good place for ad-hoc questions, design discussion, and pairing with maintainers. New here? [Join the Warp Slack community](https://go.warp.dev/join-preview) first, then jump into `#oss-contributors`.
-
-### Issue to PR
-
-Before filing, [search existing issues](https://github.com/warpdotdev/warp/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) for your bug or feature request. If nothing exists, [file an issue](https://github.com/warpdotdev/warp/issues/new/choose) using our templates. Security vulnerabilities should be reported privately as described in [CONTRIBUTING.md](CONTRIBUTING.md#reporting-security-issues).
-
-Once filed, a Warp maintainer reviews the issue and may apply a readiness label: [`ready-to-spec`](https://github.com/warpdotdev/warp/issues?q=is%3Aissue+is%3Aopen+label%3Aready-to-spec) signals the design is open for contributors to spec out, and [`ready-to-implement`](https://github.com/warpdotdev/warp/issues?q=is%3Aissue+is%3Aopen+label%3Aready-to-implement) signals the design is settled and code PRs are welcome. Anyone can pick up a labeled issue — mention **@oss-maintainers** on an issue if you'd like it considered for a readiness label.
-
-### Building the Repo Locally
-
-To build and run Warp from source:
-
-```bash
-./script/bootstrap # platform-specific setup
-./script/run # build and run Warp
-./script/presubmit # fmt, clippy, and tests
-```
-
-See [AGENTS.md](AGENTS.md) for the full engineering guide, including coding style, testing, and platform-specific notes.
-
-## Joining the Team
-
-Interested in joining the team? See our [open roles](https://www.warp.dev/careers).
-
-## Support and Questions
-
-1. See our [docs](https://docs.warp.dev/) for a comprehensive guide to Warp's features.
-2. Join our [Slack Community](https://go.warp.dev/join-preview) to connect with other users and get help from the Warp team — contributors hang out in [`#oss-contributors`](https://warpcommunity.slack.com/archives/C0B0LM8N4DB).
-3. Try our [Preview build](https://www.warp.dev/download-preview) to test the latest experimental features.
-4. Mention **@oss-maintainers** on any issue to escalate to the team — for example, if you encounter problems with the automated agents.
-
-## Code of Conduct
-
-We ask everyone to be respectful and empathetic. Warp follows the [Code of Conduct](CODE_OF_CONDUCT.md). To report violations, email warp-coc at warp.dev.
-
-## Open Source Dependencies
-
-We'd like to call out a few of the [open source dependencies](https://docs.warp.dev/help/licenses) that have helped Warp to get off the ground:
-
-- [Tokio](https://github.com/tokio-rs/tokio)
-- [NuShell](https://github.com/nushell/nushell)
-- [Fig Completion Specs](https://github.com/withfig/autocomplete)
-- [Warp Server Framework](https://github.com/seanmonstar/warp)
-- [Alacritty](https://github.com/alacritty/alacritty)
-- [Hyper HTTP library](https://github.com/hyperium/hyper)
-- [FontKit](https://github.com/servo/font-kit)
-- [Core-foundation](https://github.com/servo/core-foundation-rs)
-- [Smol](https://github.com/smol-rs/smol)
+The migration plan in [plans/galaxy-local-first-rig.md](plans/galaxy-local-first-rig.md) records the
+local-first architecture, provider boundary, and remaining work. Contributions should preserve
+those boundaries: no inherited Warp service is required for a fresh install, and no provider or
+agent may bypass Galaxy's permission and egress policy.
diff --git a/app/src/settings_view/about_page.rs b/app/src/settings_view/about_page.rs
index 8a53976c..5e4a1815 100644
--- a/app/src/settings_view/about_page.rs
+++ b/app/src/settings_view/about_page.rs
@@ -59,12 +59,12 @@ impl SettingsWidget for AboutPageWidget {
&self,
_view: &AboutPageView,
appearance: &Appearance,
- _app: &AppContext,
+ app: &AppContext,
) -> Box {
let ui_builder = appearance.ui_builder();
let icon_file =
- AppIconSettings::get_base_icon_file_name(*AppIconSettings::as_ref(_app).app_icon);
+ AppIconSettings::get_base_icon_file_name(*AppIconSettings::as_ref(app).app_icon);
let image_path = match icon_file {
"galaxy" => "bundled/png/galaxy.png",
"galaxy_dotmatrix" => "bundled/png/galaxy_dotmatrix.png",
@@ -121,14 +121,23 @@ impl SettingsWidget for AboutPageWidget {
.with_child(version_row.finish())
.with_child(
ui_builder
- .span("Open source software released under the MIT License.")
+ .span("Galaxy is a local-first, open-source developer terminal built around your workflow, your data, and the model providers you choose.")
.build()
.with_margin_top(16.)
.finish(),
)
.with_child(
ui_builder
- .span("Source code and license details are available in the project repository.")
+ .span("Conversations, settings, and Galaxy Drive content are stored locally by default. Network access is limited to providers and tools that you explicitly configure.")
+ .with_soft_wrap()
+ .build()
+ .with_margin_top(8.)
+ .finish(),
+ )
+ .with_child(
+ ui_builder
+ .span("The application and most workspace crates are licensed under AGPL-3.0-only. GalaxyUI crates are licensed under the MIT License. See LICENSE-AGPL and LICENSE-MIT in the source repository for the full terms.")
+ .with_soft_wrap()
.build()
.with_margin_top(8.)
.finish(),
diff --git a/plans/galaxy-local-first-rig.md b/plans/galaxy-local-first-rig.md
index 3e173ffc..a6f479c1 100644
--- a/plans/galaxy-local-first-rig.md
+++ b/plans/galaxy-local-first-rig.md
@@ -428,10 +428,10 @@ assigned to the phase that owns the affected flow before the related work is con
monitor.
- [x] Monitor teardown now clears orphaned in-memory state when completion metadata is missing.
- [x] Refresh requests ignore completed or no-longer-long-running blocks.
-- [ ] Open-source project presentation: structure the About page around Galaxy’s local-first
+- [x] Open-source project presentation: structure the About page around Galaxy’s local-first
identity, audit the repository’s license and third-party notices, and make the root metadata,
- contribution guidance, and license files agree on the final permissive license (currently the
- repository contains both MIT and AGPL materials and needs an explicit policy).
+ contribution guidance, and license files agree on an explicit license split (the repository
+ contains AGPL-3.0-only application code and MIT-licensed GalaxyUI crates).
### Phase 7 — UI untangling