scriptoriumadmin/fabro
1
0
Fork 0
mirror of https://github.com/fabro-sh/fabro.git synced 2026-10-01 02:04:24 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
fabro/lib/components/fabro-workflow
History
Bryan Helmkamp 45d94ce711
Use pebble's sandbox-driver adapter and delete fabro-pebble-sandbox 
`lib/components/fabro-pebble-sandbox` moved into pebble as
`pebble_coding_agent::sandbox_driver` (lithoscomputer/pebble#27): the
`Environment` over a driver handle (`SandboxEnvironment`, was
`PebbleSandbox`), the `SandboxExec` policy, the port routes, and
`display_for_log`. The pebble pin moves to that branch head, 6d03b3b,
with the `sandbox-driver` feature on (`sandbox-driver-test-util` for the
server's tests, which take `MockSandbox` from pebble now). Nothing in the
crate was Fabro's by design; what was Fabro's stays: `SecretRedactor`
moves to `fabro-redact` as pebble's `Redactor` over `redact_string`, and
the log renderer takes it where a driver failure is rendered.

`fabro-petri` hands pebble types to Petri's crates, so Petri must pin the
same pebble revision: the petri pins move to lithoscomputer/petri#36
(9ee3f85), which pins pebble at the same head. Both re-pin to the pebble
merge commit together once #27 merges.

The 14 pebble commits between the pins fold the session projection's
lifetime tallies into `SessionProjection::totals` (and `PromptDelta`'s
into a flattened `totals`, which renames the prompt's `subagents` key to
`subagent_counts`, as the projection's already was). The stage progress
fold, the runs handler, the OpenAPI schema, the generated client model,
and the round-trip test follow.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-21 17:42:15 -04:00
..
src Use pebble's sandbox-driver adapter and delete fabro-pebble-sandbox 2026-09-21 17:42:15 -04:00
Cargo.toml Use pebble's sandbox-driver adapter and delete fabro-pebble-sandbox 2026-09-21 17:42:15 -04:00
README.md Read workflow graphs through Petri's DOT parser 2026-09-19 12:23:57 -04:00

README.md

fabro-workflow

Fabro's platform half of a workflow run: what Fabro does around the engine.

Petri compiles and executes every run. fabro-petri is the crate that talks to the engine (fabro-dot reads a graph's shape and file references through Petri's parser), and this crate keeps what Fabro itself owns:

  • operations — creating a run around Petri's admission (materialize_admitted_run, persist_create_run), and the other run operations: fork, rewind, retry, and the timeline they resolve targets on. The run's display graph (fabro_types::RunGraph) is read off the graph Petri admitted; the DOT the workflow was written in is persisted beside it as graph_source.
  • workflow_bundle — the bundle a run is created from: every workflow of the version closure with its settings file and its files, and the RunDefinition the run records.
  • git, sandbox_git — the Git helpers a run's platform effects use, on the host and inside a sandbox.
  • pull_request — pull request creation for a finished run.
  • run_tools, services — the run tools an agent session calls.
  • web_search — the built-in web search backend.
  • run_lookup — resolving a run selector to a run.

The run records and status vocabulary are fabro_types'. Workflow diagnostics are Petri's: fabro validate, fabro preflight and the create handler report Petri's codes (attractor.*, unsupported.*, deprecated.*, info.*), plus Fabro's fabro.model.no_ready_provider when a model node has no provider ready to run it.