From 57c7c54d5da3a206469b1a66f36afe2c502075ab Mon Sep 17 00:00:00 2001 From: Ryan Ward Date: Thu, 6 Aug 2026 16:13:48 -0500 Subject: [PATCH] Make Galaxy project presentation explicit --- CONTRIBUTING.md | 259 +++++++--------------------- README.md | 143 ++++++--------- app/src/settings_view/about_page.rs | 17 +- plans/galaxy-local-first-rig.md | 6 +- 4 files changed, 131 insertions(+), 294 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 25da1648..fd7d7d43 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,215 +1,90 @@ -# Contributing to Warp +# Contributing to Galaxy -Thanks for helping improve Warp! This guide explains how to open issues, propose changes, and get your work reviewed. +Thanks for helping improve Galaxy. This guide describes the local-first workflow for reporting +issues, developing changes, and preparing a reviewable contribution. -> [!TIP] -> **Chat with us in Slack.** Connect with other contributors and the Warp team in the [`#oss-contributors`](https://warpcommunity.slack.com/archives/C0B0LM8N4DB) channel — a good place for ad-hoc questions, design discussion, and pairing with maintainers as you work through an issue or PR. New here? [Join the Warp Slack community](https://go.warp.dev/join-preview) first, then hop into `#oss-contributors`. +## Before you start -## TL;DR +- Read [AGENTS.md](AGENTS.md) for the architecture, development commands, and coding conventions. +- Search the repository issue tracker before opening a duplicate report. +- For a bug, include reproduction steps, expected and actual behavior, platform details, and logs + or screenshots that do not contain secrets. +- For a larger feature, describe the user problem and agree on the shape of the change before + implementing it. Keep product and technical plans under `plans/` or `specs/` as appropriate. +- Report security vulnerabilities privately using [SECURITY.md](SECURITY.md). Do not publish + exploitable details in an issue or pull request. -- Bug fixes are welcome once the report is actionable from the provided details or maintainer triage. -- Feature requests must be marked `ready-to-spec` or `ready-to-implement` before PRs are accepted. -- Issues marked `warp:reserved-internal` are being handled by the Warp team and are not open for contributor PRs. -- Specs are the place where technical and design discussion on larger issues happen. -- Oz automatically triages incoming issues and reviews open PRs. -- Implementation PRs must include proof of manual testing. - -## How Contributing to Warp Works - -Warp's contribution model is shaped by [Oz](https://oz.warp.dev), an agent that automates parts of triage, spec writing, implementation, and review. Compared with a typical open-source repository, a few things work differently here: - -- **Issues are the starting point for everything.** Discussion, scoping, and design happen on the issue before any PR is opened. -- **Feature requests differ from bug fixes:** - - Features are gated by readiness labels — `ready-to-spec`, then `ready-to-implement` once the design is settled — that signal when contributors can pick up the work. Discussion alone is not approval to begin work. - - Feature work needs a written spec first: feature requests go through a spec PR (a *product spec* + *tech spec* committed under [`specs/`](specs/)) before any code is written. - - Bug fixes can go straight to a code PR once the report is reproducible or otherwise actionable; they do not require spec PRs unless the scope or design is unclear. -- **Review is largely automated.** When you open a PR, Oz is auto-assigned and produces an initial review. Once Oz approves, it automatically requests a follow-up review from a Warp team subject-matter expert — you do not need to assign human reviewers yourself. - -### Readiness labels - -The Warp team applies one of the following labels when an issue is ready for contribution: - -- **`ready-to-spec`** — The problem is understood but the design is open. Open a spec PR with a *product spec* (`product.md`) and a *tech spec* (`tech.md`) under [`specs/`](specs/) — see [Opening a Spec PR](#opening-a-spec-pr) for what goes in each. This label is **reserved for feature requests**. -- **`ready-to-implement`** — The issue is ready for a code PR. For bugs, this means the report is sufficiently reproducible or actionable and the likely fix does not need a spec, mocks, or deeper investigation. -- **`needs-mocks`** — Design mocks are required before implementation can begin. Wait for the Warp team to land them. -- **`warp:reserved-internal`** — The Warp team is reserving this work for internal implementation or alignment. Do not open a spec or code PR for issues with this label; Oz will reject contributor PRs linked to them with an explanatory comment. - -Anyone can pick up a ready issue — readiness labels are not assignments, and the best implementation wins through normal review. If an issue has been sitting un-triaged or you'd like readiness re-evaluated, mention **@oss-maintainers** in a comment to flag it for the team. - -## Contribution Flow - -Steps owned by you (the contributor) are shown in yellow; steps owned by the Warp team or Oz are shown in blue. - -```mermaid -flowchart TD - A[File an issue] --> B{Warp team triages} - B -- ready-to-spec
(feature requests) --> C[Open spec PR
product.md + tech.md] - B -- needs-mocks --> D[Design mocks produced] - D --> E[Open code PR] - C -- specs approved --> E - B -- ready-to-implement
(actionable bugs or settled designs) --> E - E --> F[Oz review → SME review → CI → merge] - - classDef contributor fill:#fef3c7,stroke:#b45309,color:#78350f; - classDef warpTeam fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a; - class A,C,E contributor; - class B,D,F warpTeam; -``` - -## Filing a Good Issue - -Search [existing issues](https://github.com/warpdotdev/warp/issues) before filing to avoid duplicates. Use the issue templates when filing. - -If you're already running Warp, the fastest way to file is the `/feedback` command — it opens a public GitHub issue with relevant context (logs, environment details) automatically attached. - -### Bug reports - -A good bug report includes: - -- A clear title and a one-paragraph summary of the problem. -- Steps to reproduce (with a minimal example where possible). -- Expected vs. actual behavior. -- Warp version and OS (see `Settings → About`). -- Logs, screenshots, or screen recordings when relevant. - -Once an issue is triaged as an actionable bug (by Oz's triage agent or a maintainer), it may be labeled **`ready-to-implement`** so you can pick it up and open a code PR. - -### Feature requests - -A good feature request describes the user-facing problem before any proposed implementation. Include: - -- The user need or pain point, and who experiences it. -- The current behavior and why it falls short. -- A sketch of the desired behavior or workflow (a short example or mock is helpful but not required). -- Any relevant constraints (compatibility, related features, prior art, etc.). - -Feature requests are the path that goes through the spec flow: a maintainer applies **`ready-to-spec`** when the problem is understood and the design is open for contributors. From there, the next step is a spec PR — not a code PR. - -Automated triage may add informational labels (`area:*`, `repro:*`, etc.). Those do not affect readiness. - -## Opening a Spec PR - -Issues labeled `ready-to-spec` need a spec before code can begin. A spec consists of two short documents committed under [`specs/GH/`](specs/): - -- **`product.md`** (the *product spec*) — Defines the desired behavior from the consumer's perspective (the user, an API caller, a CLI user, etc.) and stays out of implementation detail. The core is a numbered list of **testable behavior invariants** covering the happy path, user-visible states, inputs and responses, and edge cases (empty / error / loading, cancellation, offline, permission denied, races, accessibility). Optional sections: problem statement, goals / non-goals, Figma link, open questions. -- **`tech.md`** (the *tech spec*) — The implementation plan, grounded in this codebase. Required sections: **Context** (the current system and relevant files with line references), **Proposed changes** (modules touched, new types / APIs / state, data flow, tradeoffs), and **Testing and validation** (how each invariant from the product spec will be verified). Optional: end-to-end flow, Mermaid diagrams, risks, parallelization, follow-ups. - -The spec-writing skills are sourced from [`warpdotdev/common-skills`](https://github.com/warpdotdev/common-skills), not authored directly in this repository. This checkout pins the expected versions in [`skills-lock.json`](skills-lock.json), and the bootstrap scripts can restore them for you: - -- `./script/bootstrap` installs or updates common skills by default and prompts for a project-local or global install target when needed. -- `./script/bootstrap --install-common-skills-in-repo` installs the pinned common skills into this checkout's `.agents/skills/`. -- `./script/bootstrap --install-common-skills-globally` installs the pinned common skills into `~/.agents/skills/`. -- `WARP_COMMON_SKILLS_INSTALL_TARGET=project ./script/bootstrap` and `WARP_COMMON_SKILLS_INSTALL_TARGET=global ./script/bootstrap` select the same targets non-interactively. -- `./script/bootstrap --skip-common-skills` leaves common skills untouched if you are managing them separately. - -To open a spec PR: - -1. Add `specs/GH/product.md` and `specs/GH/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 @@ - - Warp Agentic Development Environment product preview - -  -

- Built with Warp -   - Powered by Oz -

+# 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