mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-10-06 02:48:25 +00:00
5fc9157017
## Summary Removes Fabro's automatic retro generation stage so workflow runs go directly from execution to finalization and optional PR creation. This drops the retro-specific crate, events, projection fields, config/API knobs, and user-facing docs in favor of the existing durable run observability surfaces. ## What Changed - Deleted the `fabro-retro` crate and the workflow `retro` pipeline phase, with finalization now consuming `Executed` state directly. - Removed retro configuration and API surface area, including `--no-retro`, `[run.execution].retros`, manifest `no_retro`, `features.retros`, and run projection `retro*` fields. - Retired typed `retro.*` events while keeping historical event logs readable by deserializing retired retro event names as `Unknown`. - Stopped appending retro sections to generated PR bodies and updated docs, marketing copy, screenshots, and navigation to point users toward observability/event-stream inspection. ## Testing Not run during PR creation; this branch already contained the implementation commit. --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 (unknown context, reasoning unspecified) via [Codex](https://openai.com/codex)
24 lines
1.3 KiB
Markdown
24 lines
1.3 KiB
Markdown
# Fabro Technical Requirements
|
|
|
|
This note captures stable constraints that product changes should respect.
|
|
|
|
## Core constraints
|
|
|
|
- Fabro ships primarily as a single Rust binary with CLI and server modes.
|
|
- Workflows are defined in Graphviz DOT and should remain reviewable as source files.
|
|
- The workflow engine must support loops, branching, parallel stages, commands, agent stages, and human gates.
|
|
- Model routing is per-stage and provider-agnostic through stylesheets and config.
|
|
- Execution happens through sandbox providers rather than assuming direct host access.
|
|
- Git checkpointing is central to resume, rewind, fork, and auditability.
|
|
- Runs produce structured artifacts such as `progress.jsonl`, `live.json`, `checkpoint.json`, and `conclusion.json`.
|
|
- The HTTP API is OpenAPI-based, and the web app depends on that contract.
|
|
|
|
## Operational constraints
|
|
|
|
- Documented targets are macOS arm64, Linux x86_64, and Linux arm64.
|
|
- Git is required for checkpointing-related workflows.
|
|
- Docker, Graphviz, and SSH are optional system dependencies depending on the features in use.
|
|
|
|
## Design bias
|
|
|
|
Prefer changes that improve determinism, observability, resumability, and safe unattended execution. Avoid features that only make sense as IDE autocomplete or a chat-first REPL.
|