mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-10-07 03:00:29 +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)
25 lines
1.2 KiB
Markdown
25 lines
1.2 KiB
Markdown
# The Problem Fabro Solves
|
|
|
|
Fabro exists for teams that have outgrown the prompt-act-review loop used by most AI coding tools.
|
|
|
|
## Why that loop breaks
|
|
|
|
Interactive agent sessions work for small tasks, but they do not define a repeatable software process. In practice this creates four recurring problems:
|
|
|
|
- The engineer must supervise the agent instead of defining the process once and reusing it.
|
|
- There is no reliable gate between "the agent stopped" and "the work is ready."
|
|
- Model choice is hard to control per step, so cost and quality drift.
|
|
- Sessions are hard to resume, audit, and improve over time.
|
|
|
|
## What Fabro adds
|
|
|
|
Fabro treats the process itself as code:
|
|
|
|
- Workflow graphs define stages, branching, loops, parallelism, and human gates.
|
|
- Model stylesheets route different stages to different models and providers.
|
|
- Sandboxes and Git checkpoints make runs isolated, resumable, and inspectable.
|
|
- Event logs, verifications, and run state create a feedback loop after execution.
|
|
|
|
## Product direction
|
|
|
|
Fabro should optimize for trust in long-running workflows, not for chat UX. The product is most useful when expert engineers can design, run, inspect, and improve processes with minimal supervision.
|