scriptoriumadmin/fabro
1
0
Fork 0
mirror of https://github.com/fabro-sh/fabro.git synced 2026-09-09 22:33:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
fabro/docs/internal/product/technical-requirements.md
Bryan Helmkamp 5fc9157017
refactor(workflow): remove retro stage (#230) 
## 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.

---

[![Compound
Engineering](https://img.shields.io/badge/Compound_Engineering-6366f1)](https://github.com/EveryInc/compound-engineering-plugin)
🤖 Generated with GPT-5 (unknown context, reasoning unspecified) via
[Codex](https://openai.com/codex)
2026-05-09 10:18:20 -04:00

1.3 KiB
Raw Permalink Blame History

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.