mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-08-28 05:27:41 +00:00
docs: refresh changelog and setup docs
Add dated changelog entries for recent user-facing changes and update server setup docs for the object-store installer flow.
This commit is contained in:
Bryan Helmkamp
parent
8aeaef5f33
commit
68214575e3
13 changed files with 354 additions and 35 deletions
|
|
@ -1 +1 @@
|
|||
fae575c1935fd8d507f29a41941d0b440335728c
|
||||
6d97de0d9948f26d544e7a2bc35a99f53c55cbf8
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
1945dc8e53ecba40f8f758f943bf2a7041f2124b
|
||||
533785cd4c107cee673825847b1f8fe3d8d14dfe
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ If `~/.fabro/settings.toml` does not yet exist, `fabro server start` enters **in
|
|||
|
||||
The `Object store` step offers two wizard-managed modes:
|
||||
|
||||
- `Local disk` for the default host-local SlateDB + artifact storage path
|
||||
- `Local disk` for a host-local object-store root, detected by default and editable before continuing
|
||||
- `AWS S3` for one shared bucket with fixed `slatedb/` and `artifacts/` prefixes
|
||||
|
||||
The wizard's manual-credential path stores only `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` in `server.env`. It does not collect STS/session tokens or S3-compatible endpoint settings. If you need MinIO, Cloudflare R2, path-style options, or custom endpoints, finish install with local defaults and then edit `[server.slatedb]` / `[server.artifacts]` in `settings.toml` manually.
|
||||
|
|
|
|||
|
|
@ -196,6 +196,22 @@ The browser install wizard's `Object store` step manages both `[server.slatedb]`
|
|||
to `<storage_root>/objects`, with fixed prefixes `slatedb` and `artifacts`. `AWS S3` writes one
|
||||
shared bucket with the same fixed prefixes.
|
||||
|
||||
```toml title="Local disk object store"
|
||||
[server.artifacts]
|
||||
provider = "local"
|
||||
prefix = "artifacts"
|
||||
|
||||
[server.artifacts.local]
|
||||
root = "/var/lib/fabro/objects"
|
||||
|
||||
[server.slatedb]
|
||||
provider = "local"
|
||||
prefix = "slatedb"
|
||||
|
||||
[server.slatedb.local]
|
||||
root = "/var/lib/fabro/objects"
|
||||
```
|
||||
|
||||
The wizard only covers AWS S3 bucket/region plus one of:
|
||||
|
||||
- runtime credentials already supplied by the deployment environment
|
||||
|
|
|
|||
|
|
@ -1,37 +1,57 @@
|
|||
---
|
||||
title: "Deploy to Railway, Alpine and musl support"
|
||||
title: "Homebrew install, deployment guides, and hardened hosting"
|
||||
date: "2026-04-18"
|
||||
---
|
||||
|
||||
## One-click deploy to Railway
|
||||
<Warning>
|
||||
**GitHub webhook exposure is now explicit.** Fabro no longer starts Tailscale Funnel or rewrites the GitHub App webhook URL just because `[server.integrations.github.webhooks]` exists.
|
||||
|
||||
Self-hosting Fabro on Railway no longer requires bespoke Dockerfile work. A new `railway.toml` and Railway deploy button ship with the project, along with a full guide covering volume setup at `/storage`, required environment variables, dev-token retrieval, and pointing your CLI at the deployed server.
|
||||
To migrate:
|
||||
1. Set `strategy = "server_url"` for deployments with a stable HTTPS URL.
|
||||
2. Set `strategy = "tailscale_funnel"` if you intentionally want Fabro to run Tailscale Funnel on startup.
|
||||
</Warning>
|
||||
|
||||
The runtime container now binds `0.0.0.0:${PORT:-32276}`, so Railway, Fly, Render, and Cloud Run can route traffic without manual port configuration. Default behavior on local `docker run` and `docker-compose` is unchanged.
|
||||
## More ways to install and deploy Fabro
|
||||
|
||||
Homebrew is now a first-class install path, so macOS and Linux users can let Brew manage updates instead of downloading release archives manually.
|
||||
|
||||
```bash
|
||||
brew install fabro-sh/tap/fabro-nightly
|
||||
```
|
||||
|
||||
Self-hosting also has more direct paths: Railway uses the prebuilt GHCR image, Render has a blueprint and deploy button, Fly.io ships with a `fly.toml`, and DigitalOcean now has a Droplet plus Compose guide. The deployment docs cover persistent storage, required environment variables, server URLs, and how to point the CLI at the hosted server.
|
||||
|
||||
## Alpine and musl Linux support
|
||||
|
||||
The release pipeline now builds `x86_64-unknown-linux-musl` and `aarch64-unknown-linux-musl` tarballs alongside the glibc Linux targets. The `install.sh` script detects musl-based distributions via `ldd --version` and downloads the right archive automatically, so installs on Alpine and other musl hosts work out of the box.
|
||||
Fabro now publishes `x86_64-unknown-linux-musl` and `aarch64-unknown-linux-musl` tarballs alongside the glibc Linux builds. The installer detects musl-based distributions through `ldd --version` and downloads the matching archive automatically, so Alpine and other musl hosts work without a custom build.
|
||||
|
||||
The published Docker image switched to [Docker Hardened Images](https://www.docker.com/products/hardened-images/) (Alpine 3.23 via our nightly mirror at `ghcr.io/fabro-sh/dhi-alpine-base`), dropping from ~287 MB to ~96 MB (66% smaller) with a CVE-minimized, hardened base. The image and the `install.sh` tarball now ship the same binary.
|
||||
The Docker image also moved to an Alpine-based Docker Hardened Image. That keeps the release binary layout shared between the image and tarballs while reducing image size and trimming the default runtime surface.
|
||||
|
||||
## Production Docker compose with Caddy
|
||||
## Server hardening by default
|
||||
|
||||
A new `docker-compose.prod.yaml` stands up a Caddy 2 sidecar that handles auto-HTTPS on ports 80/443 and proxies to the Fabro service. Set `FABRO_DOMAIN` to your domain and Caddy provisions and renews the certificate; certs persist in a named volume. The base `docker-compose.yaml` has moved to the repo root.
|
||||
Fabro now emits baseline HTTP security headers on every server response and adds a report-only Content Security Policy for the web app. Operators get stronger defaults without having to place every deployment behind custom proxy header rules first.
|
||||
|
||||
## GitHub webhook exposure is now explicit
|
||||
|
||||
GitHub App webhook exposure no longer auto-enables just because `[server.integrations.github.webhooks]` exists. The webhook handler now lives on the main API router at `POST /api/v1/webhooks/github`, and operators must choose an explicit strategy if they want Fabro to mutate any external state on startup.
|
||||
|
||||
- Breaking: if you previously relied on Fabro silently starting `tailscale funnel` and rewriting the GitHub App webhook URL, add `strategy = "tailscale_funnel"` under `[server.integrations.github.webhooks]` to restore that behavior.
|
||||
- New: `strategy = "server_url"` tells Fabro to use `server.api.url` and set the GitHub App webhook URL to `<server.api.url>/api/v1/webhooks/github` on startup. This is the recommended choice for stable production deployments behind HTTPS.
|
||||
- Unset `strategy`: Fabro still verifies and serves signed GitHub webhooks when `GITHUB_APP_WEBHOOK_SECRET` is present, but it will not run `tailscale funnel` and it will not rewrite the GitHub App webhook URL.
|
||||
The GitHub webhook handler now lives on the main API router at `POST /api/v1/webhooks/github`. When `GITHUB_APP_WEBHOOK_SECRET` is configured, Fabro verifies signed webhook deliveries whether or not it is configured to update the GitHub App webhook URL.
|
||||
|
||||
## More
|
||||
|
||||
<Accordion title="Fixes">
|
||||
- Fixed Gemini API keys being sent as URL query parameters; they now go through the `x-goog-api-key` header so they don't leak into access logs, proxies, or request traces
|
||||
- Hardened the `fabro-demo` cookie with `HttpOnly` unconditionally and `Secure` when the web URL is HTTPS
|
||||
- Fixed a path-traversal issue where authenticated users could send percent-encoded `..` segments in the GitHub repo lookup endpoint and redirect the server's privileged token to an unintended GitHub API path; owner and repo now require `[A-Za-z0-9._-]` with length caps
|
||||
- Fixed SIGSEGV at startup on the `aarch64-unknown-linux-musl` target (Apple Silicon, Graviton, Ampere) caused by a glibc-vs-musl `.init_array` calling-convention mismatch; the release pipeline now uses `cargo-zigbuild` for musl targets, producing binaries that start cleanly on arm64 Alpine, Debian, and DHI runtimes
|
||||
<Accordion title="CLI">
|
||||
- Added the Homebrew install path to the quick start and public install page
|
||||
- `fabro version` now warns when the CLI and server versions differ
|
||||
- `fabro version` now surfaces when the binary was built from a debug profile
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Improvements">
|
||||
- Added Render, Fly.io, and DigitalOcean deployment guides alongside the existing Railway path
|
||||
- Added a production Docker Compose setup with Caddy handling automatic HTTPS in front of Fabro
|
||||
- Added `/health` to the container deployment path so platform health checks can target the server directly
|
||||
- Published the runtime image from the Docker Hardened Images Alpine base
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Fixes">
|
||||
- Fixed startup crashes on `aarch64-unknown-linux-musl` by building musl targets through `cargo-zigbuild`
|
||||
- Fixed the SPA fallback so `/api/*` paths no longer resolve to the frontend shell
|
||||
- Fixed Gemini API keys being sent as URL query parameters; they now use the `x-goog-api-key` header
|
||||
- Hardened the `fabro-demo` cookie with `HttpOnly` and conditional `Secure`
|
||||
- Fixed GitHub repo lookup path validation so encoded `..` segments cannot redirect server-side GitHub API requests
|
||||
</Accordion>
|
||||
|
|
|
|||
|
|
@ -1,24 +1,80 @@
|
|||
---
|
||||
title: "Archive terminal runs"
|
||||
title: "Run files, archived runs, and browser setup"
|
||||
date: "2026-04-19"
|
||||
---
|
||||
|
||||
<Warning>
|
||||
**Fabro no longer terminates inbound TLS or mTLS itself.** Keep the Fabro listener on plain HTTP or a Unix socket, then terminate HTTPS or mTLS at a reverse proxy, load balancer, or platform ingress.
|
||||
|
||||
To migrate:
|
||||
1. Remove direct TLS listener settings from Fabro.
|
||||
2. Put the TLS-terminating proxy in front of Fabro.
|
||||
3. Set `server.api.url` and `server.web.url` to the external HTTPS origin.
|
||||
</Warning>
|
||||
|
||||
## Browse changed files from a run
|
||||
|
||||
Run detail pages now include a Files view backed by server-side file metadata and diffs. Instead of leaving the web app to infer output from terminal logs or downloaded artifacts, Fabro can show the changed files, empty states, loading states, errors, and refresh behavior directly in the run UI.
|
||||
|
||||
The same data is available through the API:
|
||||
|
||||
```bash
|
||||
GET /api/v1/runs/{id}/files
|
||||
```
|
||||
|
||||
The server reads the run's sandbox path when available and can fall back to final patch data for failed runs, so file review still works across more failure modes.
|
||||
|
||||
## Archive terminal runs
|
||||
|
||||
Terminal runs — `succeeded`, `failed`, and `dead` — can now be explicitly archived to signal "reviewed, no further action needed." Archived runs are hidden from default listings (`fabro ps`, `GET /api/v1/runs`) and are read-only: any mutation on an archived run returns an actionable error asking you to unarchive first.
|
||||
Terminal runs - `succeeded`, `failed`, and `dead` - can now be archived after review. Archived runs are hidden from default listings and are read-only; if you try to mutate one, Fabro returns an actionable error asking you to unarchive it first.
|
||||
|
||||
Two new CLI commands mirror `fabro rm`'s bulk-by-ID shape:
|
||||
|
||||
```
|
||||
```bash
|
||||
fabro archive <run-id> [<run-id> ...]
|
||||
fabro unarchive <run-id> [<run-id> ...]
|
||||
```
|
||||
|
||||
Both are idempotent in their respective directions — archiving an already-archived run is a no-op, and unarchiving a non-archived terminal run is a no-op — so retries and mixed-id batches are safe. Unarchive restores the run's exact prior terminal status.
|
||||
Both commands are idempotent in their respective directions, which makes retries and mixed batches safe. `fabro ps -a` shows active, terminal, and archived runs together, while the default `fabro ps` view stays focused on active work.
|
||||
|
||||
On the HTTP surface, two new endpoints sit alongside the existing control family:
|
||||
## Browser-based server setup
|
||||
|
||||
- `POST /api/v1/runs/{id}/archive`
|
||||
- `POST /api/v1/runs/{id}/unarchive`
|
||||
Starting a server without an existing settings file now enters install mode and opens a browser wizard. The wizard walks through server URL, object storage defaults, LLM credentials, and GitHub integration instead of requiring a long manual `settings.toml` edit before first use.
|
||||
|
||||
`GET /api/v1/runs` gained an `include_archived=true` query parameter for opting in. `fabro ps` continues to show active runs only by default; `fabro ps -a` now shows active, terminal, and archived runs together.
|
||||
```bash
|
||||
fabro server start
|
||||
```
|
||||
|
||||
The install flow is also available in the embedded web app, so Docker and hosted deployments can complete setup from the same server process they will keep running.
|
||||
|
||||
## More
|
||||
|
||||
<Accordion title="API">
|
||||
- New `GET /api/v1/runs/{id}/files` endpoint returns paginated run file data and diff metadata
|
||||
- New `POST /api/v1/runs/{id}/archive` and `POST /api/v1/runs/{id}/unarchive` endpoints manage archived terminal runs
|
||||
- `GET /api/v1/runs` accepts `include_archived=true` for listing archived runs
|
||||
- GitHub webhook handling now supports explicit source IP allowlisting with GitHub webhook range refresh
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="CLI">
|
||||
- Added `fabro archive` and `fabro unarchive` for bulk archiving terminal runs
|
||||
- `fabro ps -a` now includes archived runs alongside active and terminal runs
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Workflows">
|
||||
- Added `run.archived` and `run.unarchived` events for archive state changes
|
||||
- Captured `final_patch` on failed runs so Run Files can still show changed files when finalization degrades
|
||||
- Added machine-readable sandbox git helpers for Run Files extraction
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Improvements">
|
||||
- Promoted Settings to the top-level web navigation and added page headers for settings pages
|
||||
- Tightened run detail layout, graph toolbar behavior, billing presentation, and stage sidebar ergonomics
|
||||
- Added a shared empty, loading, and error state primitive for web run views
|
||||
- Canonicalized paginated run list responses across real and demo mode
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Fixes">
|
||||
- Fixed Run Files path normalization for Unicode paths and tightened denylist handling for sandbox, artifact, and blob paths
|
||||
- Fixed archive and unarchive bulk failure grammar in CLI output
|
||||
- Fixed archived run mutation handling so archived runs return the correct actionable error
|
||||
- Fixed install wizard edge cases around GitHub App setup, unsupported providers, and demo status parsing
|
||||
</Accordion>
|
||||
|
|
|
|||
42
docs/changelog/2026-04-20.mdx
Normal file
42
docs/changelog/2026-04-20.mdx
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
title: "GitHub CLI auth and web run controls"
|
||||
date: "2026-04-20"
|
||||
---
|
||||
|
||||
## GitHub login for the CLI
|
||||
|
||||
The CLI can now authenticate to GitHub-backed Fabro servers through a browser login flow. Instead of copying bearer tokens around, run `fabro auth login`, approve the flow in your browser, and let the CLI store and refresh the session for future commands.
|
||||
|
||||
```bash
|
||||
fabro auth login
|
||||
fabro auth status
|
||||
fabro auth logout
|
||||
```
|
||||
|
||||
Token refresh is wired through the shared client path used by commands such as `fabro doctor`, `fabro model`, `fabro repo init`, `fabro secret`, `fabro system`, and `fabro version`, so authenticated server commands can recover from expired access tokens without a manual retry.
|
||||
|
||||
## Run controls in the web app
|
||||
|
||||
Run detail pages now expose lifecycle actions directly in the browser. You can start, pause, unpause, cancel, archive, and unarchive runs from the run UI, with toasts and server-sent event updates keeping the page state in sync after the action completes.
|
||||
|
||||
Blocked runs also get a clearer notice in the stage sidebar. The web app now treats lifecycle actions as first-class run operations instead of burying them in CLI-only workflows.
|
||||
|
||||
## More
|
||||
|
||||
<Accordion title="API">
|
||||
- Corrected the GitHub webhook OpenAPI contract so generated clients match the server route
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="CLI">
|
||||
- Added `fabro auth login`, `fabro auth status`, and `fabro auth logout`
|
||||
- Restored configured socket autostart behavior for local server targets
|
||||
- `fabro system df` now checks server stores in parallel
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Fixes">
|
||||
- Fixed CLI login so the browser must confirm the auth request before the CLI receives a token
|
||||
- Removed explicit remote same-host auth fallbacks from the CLI client
|
||||
- Fixed server stop polling so zombie processes do not keep a server marked as running
|
||||
- Rejected obfuscated IPv4 host forms when parsing CLI server targets
|
||||
- Deduplicated archive, unarchive, cancel, and lifecycle toasts in the web app
|
||||
</Accordion>
|
||||
50
docs/changelog/2026-04-21.mdx
Normal file
50
docs/changelog/2026-04-21.mdx
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
---
|
||||
title: "Install-first server startup and safer auth boundaries"
|
||||
date: "2026-04-21"
|
||||
---
|
||||
|
||||
<Warning>
|
||||
**Fabro now expects one public API and web origin for browser auth.** Deployments should route API and web traffic through the same external origin, then set `server.api.url` and `server.web.url` to that origin.
|
||||
|
||||
To migrate:
|
||||
1. Put API and web traffic behind the same public origin.
|
||||
2. Update `settings.toml` so both URLs point at that origin.
|
||||
3. Re-run `fabro auth login` from clients that still have old target metadata.
|
||||
</Warning>
|
||||
|
||||
## `fabro server start` is the setup path
|
||||
|
||||
The happy path for a fresh machine now starts with the server itself. If settings do not exist yet, `fabro server start` enters install mode, opens the browser wizard, and guides you through configuring the deployment before normal server traffic begins.
|
||||
|
||||
```bash
|
||||
fabro server start
|
||||
```
|
||||
|
||||
The install flow no longer enables dev-token material when GitHub App auth is selected, keeps loading states visible until the install session resolves, and carries GitHub App manifest state as form data instead of URL query data.
|
||||
|
||||
## Auth failures are easier to recover from
|
||||
|
||||
CLI commands now return exit code `4` for authentication-required failures, giving scripts a stable signal that the user needs to log in. When a GitHub-authenticated server has no runs yet, the blank-slate quick start in the web app starts with `fabro auth login` so the first command users copy is the one they actually need.
|
||||
|
||||
The OAuth callback and CLI resume pages were restyled to match the Fabro app, making browser auth feel like part of the product instead of a detached server page.
|
||||
|
||||
## More
|
||||
|
||||
<Accordion title="CLI">
|
||||
- Added exit code `4` for authentication-required command failures
|
||||
- `fabro exec` now classifies auth-required responses consistently with other server commands
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Improvements">
|
||||
- Browser auth and CLI resume pages now use the Fabro auth theme
|
||||
- API status types now reuse the domain run status shape in generated Rust API types
|
||||
- GitHub auth translation now converts non-JWT auth into bearer tokens before request handling
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Fixes">
|
||||
- Fixed markdown links in run stage output so unsafe links are sanitized before rendering
|
||||
- Fixed detached MCP launch commands by shell-quoting interpolated command values
|
||||
- Fixed event replay so unknown stage statuses do not stop run event streaming
|
||||
- Fixed Linux process checks so zombie-only process groups are treated as stopped
|
||||
- Restricted CLI start session reuse to GitHub-authenticated sessions
|
||||
</Accordion>
|
||||
41
docs/changelog/2026-04-22.mdx
Normal file
41
docs/changelog/2026-04-22.mdx
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
---
|
||||
title: "Object-store setup in the installer"
|
||||
date: "2026-04-22"
|
||||
---
|
||||
|
||||
## Configure storage from the browser wizard
|
||||
|
||||
The install wizard now includes an Object store step, so hosted deployments can choose local disk or AWS S3 before the server starts serving normal traffic. The wizard manages SlateDB and artifact storage together, which prevents the common setup mistake of putting run events in one backend and artifacts somewhere else.
|
||||
|
||||
```toml
|
||||
[server.slatedb]
|
||||
provider = "s3"
|
||||
disk_cache = true
|
||||
|
||||
[server.slatedb.s3]
|
||||
bucket = "{{ env.SLATEDB_BUCKET }}"
|
||||
region = "us-east-1"
|
||||
```
|
||||
|
||||
For AWS S3, the wizard supports runtime credentials from the deployment environment or manually entered `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`. Advanced S3-compatible backends such as MinIO, R2, custom endpoints, and path-style settings remain available through manual `settings.toml` configuration.
|
||||
|
||||
## More
|
||||
|
||||
<Accordion title="CLI">
|
||||
- `fabro settings --local` now reads and writes local settings without contacting a server
|
||||
- Authentication-required errors now suggest `fabro auth login`
|
||||
- Run dump artifact paths now use the displayed stage ID in export paths
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Improvements">
|
||||
- Dev-token handling is now gated on explicit `dev-token` auth configuration
|
||||
- `fabro server start` no longer mints dev-token material when dev-token auth is disabled
|
||||
- Added a Discord badge to the README
|
||||
- Run status handling now uses one tagged lifecycle state representation across API and UI surfaces
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Fixes">
|
||||
- Fixed archive outcome alignment so status transitions report consistently
|
||||
- Fixed server-side settings authority so unit tests and dry paths do not accidentally reach live object stores
|
||||
- Fixed install runtime refresh behavior after settings updates
|
||||
</Accordion>
|
||||
52
docs/changelog/2026-04-23.mdx
Normal file
52
docs/changelog/2026-04-23.mdx
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
---
|
||||
title: "Server secrets, fabro dump, and faster workflow finalization"
|
||||
date: "2026-04-23"
|
||||
---
|
||||
|
||||
<Warning>
|
||||
**`fabro store dump` has been renamed to `fabro dump`.** Update scripts and docs that still call the nested command.
|
||||
|
||||
To migrate:
|
||||
1. Replace `fabro store dump ...` with `fabro dump ...`.
|
||||
2. Re-check any automation that depends on dump output paths.
|
||||
</Warning>
|
||||
|
||||
## Tighter server secret boundaries
|
||||
|
||||
Server startup now validates authority-bearing secrets at the server boundary instead of letting every subprocess inherit whatever happened to be in the parent environment. Worker subprocesses receive a scoped worker token when they need one, then scrub it from their process environment before launching hooks, sandbox commands, devcontainer setup, MCP stdio, or other descendants.
|
||||
|
||||
That change reduces the chance of leaking server-level credentials into user-controlled command paths while preserving authenticated run operations. It also makes install-time and startup-time secret handling easier to reason about for self-hosted deployments.
|
||||
|
||||
## Faster workflow finishing and devcontainer setup
|
||||
|
||||
Several workflow phases now do less serialized work. Retros load the event log once, devcontainer `Command::Parallel` entries actually run concurrently, and final patch creation can overlap with finalize commit work.
|
||||
|
||||
Users should notice this most on longer workflows with large event logs, devcontainer initialization, or expensive final patch generation. The behavior is the same, but the slow tail of a run has fewer avoidable waits.
|
||||
|
||||
## More
|
||||
|
||||
<Accordion title="CLI">
|
||||
- Renamed `fabro store dump` to `fabro dump`
|
||||
- `fabro run --json` no longer opens a preview browser window
|
||||
- Manifest git detection now respects the workflow `working_directory`
|
||||
- Added `CommandContext::json_output()` and `CommandContext::verbose()` accessors for more consistent CLI behavior
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Workflows">
|
||||
- Sub-workflows now reuse the parent credential source
|
||||
- Terminal run events now emit from FINALIZE and include the real terminal error when finalization fails
|
||||
- Stage and billing summaries are deduplicated before terminal events are written
|
||||
- Auto-PR creation now reuses the resolved LLM client instead of resolving credentials again
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Improvements">
|
||||
- Dense settings resolution is now cached across manifest, server, workflow, and CLI loaders
|
||||
- Server secrets are scrubbed from worker environments before descendant commands can inherit them
|
||||
- Pull request creation now runs through server-side plumbing with shared validation
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Fixes">
|
||||
- Fixed the Get Started button to point to the docs introduction
|
||||
- Fixed LLM source resolution gaps in settings-driven runs
|
||||
- Fixed PR refactor review feedback around conflict and auth error handling
|
||||
</Accordion>
|
||||
|
|
@ -3,11 +3,23 @@ title: "Server-backed rewind and fork"
|
|||
date: "2026-04-24"
|
||||
---
|
||||
|
||||
<Warning>
|
||||
**`fabro rewind` now creates a replacement run instead of mutating the source run.** The source run is archived after rewind succeeds, and the new run ID is the one you should resume.
|
||||
|
||||
To migrate:
|
||||
1. Read the new run ID printed by `fabro rewind`.
|
||||
2. Resume or inspect that replacement run instead of assuming the original run ID changed in place.
|
||||
</Warning>
|
||||
|
||||
<Warning>
|
||||
**`fabro pr list` has been removed.** Remove scripts that still call it and use the run detail surfaces that own pull request creation state.
|
||||
</Warning>
|
||||
|
||||
## Server-backed rewind and fork
|
||||
|
||||
`fabro rewind` now creates a replacement run at the target checkpoint and archives the source run instead of mutating the source run in place. The command prints the new run ID:
|
||||
|
||||
```
|
||||
```bash
|
||||
fabro rewind <run-id> plan@2
|
||||
fabro resume <new-run-id>
|
||||
```
|
||||
|
|
@ -15,3 +27,28 @@ fabro resume <new-run-id>
|
|||
The source run records which run superseded it, so archived run history keeps a clear audit trail. Rewind requires the source to be terminal (`succeeded`, `failed`, or `dead`).
|
||||
|
||||
`fabro fork`, `fabro rewind`, and their `--list` modes now use the server API. The server must be able to read the run's recorded working directory. Timeline listing no longer rebuilds a missing metadata branch; if the metadata branch is gone, the timeline is empty until metadata is restored.
|
||||
|
||||
## More
|
||||
|
||||
<Accordion title="API">
|
||||
- New `POST /api/v1/runs/{id}/rewind` endpoint creates the replacement run and archives the source run
|
||||
- New `POST /api/v1/runs/{id}/fork` endpoint forks a run from the server-side run record
|
||||
- New `GET /api/v1/runs/{id}/timeline` endpoint returns checkpoint timeline entries from run metadata
|
||||
- Run summaries now include `superseded_by` data for rewound source runs
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="CLI">
|
||||
- Removed the obsolete `fabro pr list` command
|
||||
- `fabro fork`, `fabro rewind`, and timeline listing now call the server API
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Improvements">
|
||||
- Updated the quick start with supported platform details
|
||||
- Fixed Mintlify MDX parsing in planning docs
|
||||
- Simplified server-side pull request creation plumbing around run and GitHub context loading
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Fixes">
|
||||
- Changed the install wizard token field to a single-line input
|
||||
- Refreshed the embedded web assets for the rewind and install UI changes
|
||||
</Accordion>
|
||||
|
|
|
|||
|
|
@ -252,6 +252,11 @@
|
|||
"group": "April 2026",
|
||||
"icon": "clock-rotate-left",
|
||||
"pages": [
|
||||
"changelog/2026-04-24",
|
||||
"changelog/2026-04-23",
|
||||
"changelog/2026-04-22",
|
||||
"changelog/2026-04-21",
|
||||
"changelog/2026-04-20",
|
||||
"changelog/2026-04-19",
|
||||
"changelog/2026-04-18",
|
||||
"changelog/2026-04-17",
|
||||
|
|
|
|||
|
|
@ -378,7 +378,7 @@ When `--no-web` is set, the server still exposes the machine API under `/api/v1`
|
|||
|
||||
### Install mode
|
||||
|
||||
If `~/.fabro/settings.toml` does not exist yet, `fabro server start` enters install mode: it prints an install URL, attempts to open it in your default browser, and serves a web wizard for configuring LLM providers, the server URL, and GitHub integration. The server exits cleanly when the wizard finishes; start it again (or let a supervisor restart it) to boot in configured mode. See [Running the Fabro Server](/administration/deploy-server) for the full flow, and `fabro install` for the headless CLI-only equivalent.
|
||||
If `~/.fabro/settings.toml` does not exist yet, `fabro server start` enters install mode: it prints an install URL, attempts to open it in your default browser, and serves a web wizard for configuring the server URL, shared object store, LLM providers, and GitHub integration. The server exits cleanly when the wizard finishes; start it again (or let a supervisor restart it) to boot in configured mode. See [Running the Fabro Server](/administration/deploy-server) for the full flow, and `fabro install` for the headless CLI-only equivalent.
|
||||
|
||||
## `fabro server stop`
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue