967 commits

Author	SHA1	Message	Date
Bryan Helmkamp	96fff07a84	fix(agent): retry retryable mid-stream LLM failures ... Replay retryable stream failures from the last committed turn state, clear partial visible output before retry or terminal failure, and map Anthropic stream error events into structured provider errors.	2026-05-22 21:00:50 -04:00
fabro-sh-0530[bot]	0754f1ca4a	Add fabro_run_get read-only run inspection tool (#358) ... ## Summary Adds a new `fabro_run_get` MCP tool that returns a run's summary, resolved ID, projection, and pending questions without any mutation capability. This separates read-only inspection from operational control, allowing Ask Fabro sessions to inspect runs safely without access to write operations. ## What changed and why **New tool (`fabro-tool/src/get.rs`):** `FabroRunGetParams` / `ValidatedRunGet` / `RunGetResult` follow the same validation-and-dispatch pattern as other run tools. The implementation resolves a selector, then fans out to three read-only API calls (retrieve run, get state, list questions) and assembles them into a single structured result. **Tool registry and dispatch:** `FABRO_RUN_GET_TOOL_NAME` is exported from `common.rs` and `lib.rs`, added to `TOOL_DEFINITIONS`, wired into the MCP stdio server (`fabro-mcp-server/src/server.rs`), and dispatched in the LLM agent executor (`fabro-workflow/src/handler/llm/api.rs`). **Ask Fabro access policy (`fabro-server/.../sessions.rs`):** The session now registers and allows only `fabro_run_events` + `fabro_run_get` via the new `ASK_FABRO_RUN_TOOL_NAMES` constant. `fabro_run_interact` is explicitly moved to the denied set, closing off mutation from that session type. The policy match arm is refactored from a hardcoded `|`-chain to a slice `contains` check so the constant is the single source of truth. **Docs:** `mcp.mdx` now lists `fabro_run_get` as the inspection tool and redescribes `fabro_run_interact` as control-oriented. **Backward compatibility:** `fabro_run_interact` (including `get` and `get_questions` actions) is unchanged and still fully operational for contexts that allow it. ### Plan Summary - New `get.rs` module in `fabro-tool` with validation, async fetch, and unit tests - Constants + schema registration in `common.rs` / `lib.rs` - MCP server and LLM dispatch branches added for `FABRO_RUN_GET_TOOL_NAME` - Ask Fabro session swaps `FABRO_RUN_INTERACT_TOOL_NAME` → `FABRO_RUN_GET_TOOL_NAME` in registry and policy - MCP integration tests: tool count constant, schema assertions, two new end-to-end tests (`mcp_get_resolves_selector_and_returns_summary_projection_and_questions`, `mcp_get_rejects_blank_run_id_before_auth_or_network`) - Public MCP docs updated ### Fabro Details <details> <summary>Ran 9 stages in 43m 30s for $13.42</summary> | Stage | Duration | Cost | Retries | |---|---|---|---| | start | 0s | – | 0 | | toolchain | 1s | – | 0 | | preflight_compile | 2m 2s | – | 0 | | preflight_lint | 2m 14s | – | 0 | | implement | 19m 43s | $8.85 | 0 | | simplify_opus | 5m 52s | $1.45 | 0 | | simplify_gpt | 10m 16s | $3.12 | 0 | | verify | 2m 53s | – | 0 | | fmt | 3s | – | 0 | | **Total** | **43m 30s** | **$13.42** | **0** | </details> <details> <summary>Ran <code>ImplementPlan.fabro</code> (12 nodes and 15 edges)</summary> ```dot digraph ImplementPlan { graph [ goal="Implement and simplify", model_stylesheet=" * { model: claude-opus-4-7; } " ] rankdir=LR start [shape=Mdiamond, label="Start"] exit [shape=Msquare, label="Exit"] toolchain [label="Toolchain", shape=parallelogram, script="command -v cargo >/dev/null || { curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && sudo ln -sf $HOME/.cargo/bin/* /usr/local/bin/; }; cargo --version 2>&1", max_retries=0] preflight_compile [label="Preflight Compile", shape=parallelogram, script="cargo check -q --workspace 2>&1", max_retries=0] preflight_lint [label="Preflight Lint", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1", max_retries=0] fix_lints [label="Fix Lints", prompt="The preflight lint step failed. Read the build output from context and fix all clippy lint warnings.", max_visits=3] implement [label="Implement", prompt="Read the plan file referenced in the goal and implement every step. Make all the code changes described in the plan. Use red/green TDD."] simplify_opus [label="Simplify (Opus)", prompt="@prompts/simplify.md"] simplify_gpt [label="Simplify (GPT-55)", prompt="@prompts/simplify.md", model="gpt-55"] verify [label="Verify", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1 && cargo nextest run --cargo-quiet --workspace --status-level fail 2>&1 && cargo dev docs refresh 2>&1 && cargo dev docs check 2>&1", goal_gate=true, retry_target="fixup"] fixup [label="Fixup", prompt="The verify step failed. Read the build output from context and fix all clippy lint warnings, test failures, and generated docs errors.", max_visits=3] fmt [label="Format", shape=parallelogram, script="cargo +nightly-2026-04-14 fmt --all 2>&1", max_retries=0] start -> toolchain toolchain -> preflight_compile [condition="outcome=succeeded"] toolchain -> exit preflight_compile -> preflight_lint [condition="outcome=succeeded"] preflight_compile -> exit preflight_lint -> implement [condition="outcome=succeeded"] preflight_lint -> fix_lints fix_lints -> preflight_lint implement -> simplify_opus -> simplify_gpt -> verify verify -> fmt [condition="outcome=succeeded"] verify -> fixup fixup -> verify fmt -> exit } ``` </details> ⚒️ Generated with [Fabro](https://fabro.sh) --------- Co-authored-by: Fabro <noreply@fabro.sh>	2026-05-22 19:03:56 -04:00
fabro-sh-0530[bot]	94c657b92e	feat: add run.checkpoint.skip_git_hooks to bypass Git commit hooks (#355) ... ## Summary Adds an opt-in `skip_git_hooks` boolean to `[run.checkpoint]` that causes Fabro-managed run-branch checkpoint commits to pass `--no-verify` to `git commit`, bypassing local hooks such as `pre-commit` and `commit-msg`. Defaults to `false`. Metadata-branch snapshots and Fabro `[[run.hooks]]` are unaffected. ```toml [run.checkpoint] skip_git_hooks = true ``` ### Plan Summary - `RunCheckpointSettings` (dense, in `fabro-types`) gains `skip_git_hooks: bool` with `#[serde(default)]`. - `RunCheckpointLayer` (sparse, in `fabro-config`) gains `skip_git_hooks: Option<bool>` so layered config can distinguish unset from explicit `false`. - `RunCheckpointLayer::combine` is refactored from a wholesale-replace to field-level merging: `exclude_globs` keeps its existing replace-wins semantics; `skip_git_hooks` uses `.or()` (highest-priority layer that sets it wins). - `resolve_checkpoint` resolves `None → false`. - `git_checkpoint` / `checked_git_checkpoint` in `sandbox_git.rs` accept a new `skip_git_hooks: bool` and append `--no-verify` when true. - `parallel_branch_commit_cmd` (new helper in `handler/parallel.rs`) replaces the inline format string and accepts the same flag. - `GitState` carries `checkpoint_skip_git_hooks`; `RunOptions::checkpoint_skip_git_hooks()` exposes it; `execute.rs` and `git.rs` thread it through. - OpenAPI schema, TypeScript API client, and docs are updated. ### Key design decisions **Field-level merging in `combine`**: the previous `RunCheckpointLayer::combine` replaced the whole struct when `self.exclude_globs` was non-empty. The refactor keeps that same replace rule for `exclude_globs` while adding independent `Option::or` merging for `skip_git_hooks`, so the two fields don't interfere. **`--no-verify` only on run-branch commits**: the flag is injected only in the two Git commit paths Fabro controls for run-branch checkpoints. Metadata-branch snapshots use `git2` and never fire local hooks regardless of this setting. ### Fabro Details <details> <summary>Ran 9 stages in 48m 3s for $13.91</summary> | Stage | Duration | Cost | Retries | |---|---|---|---| | start | 0s | – | 0 | | toolchain | 3s | – | 0 | | preflight_compile | 2m 4s | – | 0 | | preflight_lint | 2m 15s | – | 0 | | implement | 24m 13s | $10.38 | 0 | | simplify_opus | 10m 31s | $1.59 | 0 | | simplify_gpt | 5m 8s | $1.93 | 0 | | verify | 3m 4s | – | 0 | | fmt | 3s | – | 0 | | **Total** | **48m 3s** | **$13.91** | **0** | </details> <details> <summary>Ran <code>ImplementPlan.fabro</code> (12 nodes and 15 edges)</summary> ```dot digraph ImplementPlan { graph [ goal="Implement and simplify", model_stylesheet=" * { model: claude-opus-4-7; } " ] rankdir=LR start [shape=Mdiamond, label="Start"] exit [shape=Msquare, label="Exit"] toolchain [label="Toolchain", shape=parallelogram, script="command -v cargo >/dev/null || { curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && sudo ln -sf $HOME/.cargo/bin/* /usr/local/bin/; }; cargo --version 2>&1", max_retries=0] preflight_compile [label="Preflight Compile", shape=parallelogram, script="cargo check -q --workspace 2>&1", max_retries=0] preflight_lint [label="Preflight Lint", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1", max_retries=0] fix_lints [label="Fix Lints", prompt="The preflight lint step failed. Read the build output from context and fix all clippy lint warnings.", max_visits=3] implement [label="Implement", prompt="Read the plan file referenced in the goal and implement every step. Make all the code changes described in the plan. Use red/green TDD."] simplify_opus [label="Simplify (Opus)", prompt="@prompts/simplify.md"] simplify_gpt [label="Simplify (GPT-55)", prompt="@prompts/simplify.md", model="gpt-55"] verify [label="Verify", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1 && cargo nextest run --cargo-quiet --workspace --status-level fail 2>&1 && cargo dev docs refresh 2>&1 && cargo dev docs check 2>&1", goal_gate=true, retry_target="fixup"] fixup [label="Fixup", prompt="The verify step failed. Read the build output from context and fix all clippy lint warnings, test failures, and generated docs errors.", max_visits=3] fmt [label="Format", shape=parallelogram, script="cargo +nightly-2026-04-14 fmt --all 2>&1", max_retries=0] start -> toolchain toolchain -> preflight_compile [condition="outcome=succeeded"] toolchain -> exit preflight_compile -> preflight_lint [condition="outcome=succeeded"] preflight_compile -> exit preflight_lint -> implement [condition="outcome=succeeded"] preflight_lint -> fix_lints fix_lints -> preflight_lint implement -> simplify_opus -> simplify_gpt -> verify verify -> fmt [condition="outcome=succeeded"] verify -> fixup fixup -> verify fmt -> exit } ``` </details> ⚒️ Generated with [Fabro](https://fabro.sh) --------- Co-authored-by: Fabro <noreply@fabro.sh>	2026-05-22 17:26:06 -04:00
Bryan Helmkamp	511371bd9a	feat(mcp): support goal files in run create ... Allow fabro_run_create object specs to pass goal_file, reject goal and goal_file together, and preserve file-sourced goal semantics when building run manifests.	2026-05-22 14:27:42 -04:00
fabro-sh-0530[bot]	a42634cc54	Add event-sourced todo tools for OpenAI and Anthropic profiles (#353) ... ## Summary Adds a shared todo/task engine behind two model-native tool surfaces, with all mutations persisted as individual run events and replayed into `RunProjection`. ### Plan Summary - **New domain types** in `fabro-types`: `TodoStatus`, `TodoListKind`, `TodoProjection`, `TodoListProjection`, and `todos_by_list` on `RunProjection`. - **New run events**: `todo.created`, `todo.updated`, `todo.deleted` — mapped through Fabro's typed event pipeline and replayed by `RunProjectionReducer`. - **`TodoRuntime`** (`fabro-agent`): thread-safe in-memory projection shared across tool closures within a profile instance; each mutation emits the corresponding agent event. - **`update_plan`** registered only in `OpenAiProfile`: reconciles incoming steps by exact `step` text (sha256-derived ID), emitting create/update/delete events to match the submitted plan. - **`TaskCreate` / `TaskUpdate` / `TaskList`** registered only in `AnthropicProfile`: numeric task IDs per list, metadata merge with `null`-key deletion, `status: "deleted"` routes to `todo.deleted`. - **Session identity threading**: `ToolContext` gains `session_id`, `root_session_id`, `tool_call_id`, and `agent_event_emitter`; `execute_tool_calls` threads these through to `execute_one_tool`; `Session` tracks `root_session_id` and `spawn_agent` inherits it for subagents. - **Scoping**: OpenAI todos scope to `openai_plan:<session_id>` (per-session); Anthropic todos scope to `anthropic_tasks:<root_session_id>` (shared across subagents). - **Web invalidation**: `todo.*` events invalidate `getRunState` and the run events list; tested in `run-events.test.tsx`. ```mermaid graph TB subgraph OpenAI UP[update_plan] -->|diff by step text| TR[TodoRuntime] end subgraph Anthropic TC[TaskCreate] --> TR TU[TaskUpdate] --> TR TL[TaskList] -->|read-only snapshot| TR end TR -->|emit todo.created/updated/deleted| SE[SessionBoundEmitter] SE --> EV[AgentEvent stream] EV --> RP[RunProjection\ntodos_by_list] ``` ### Key design decisions - **Step identity by text, not position** (`update_plan`): a sha256-derived ID from `list_id + step` means reordering without renaming emits an update rather than a delete+create. Duplicate step strings are rejected with a model-visible error because text is the identity. - **No plan-replace event**: the engine emits only individual mutation events; bulk replacement is expressed as a set of create/update/delete events produced by diffing the incoming plan against the projection snapshot. - **`TodoRuntime` per profile instance**: tools inside a single profile share one runtime. OpenAI subagents each have their own `session_id` so their plans are isolated; Anthropic subagents inherit `root_session_id` so tasks are shared — matching upstream Codex/Claude behavior. - **`AgentEventEmitter` trait on `ToolContext`**: a narrow interface that lets tools publish typed events without taking a dependency on the full `Emitter`. `SessionBoundEmitter` wraps `Emitter` and stamps `session_id` + `tool_call_id` on each event. ### Fabro Details <details> <summary>Ran 9 stages in 93m 23s for $56.46</summary> | Stage | Duration | Cost | Retries | |---|---|---|---| | start | 0s | – | 0 | | toolchain | 1s | – | 0 | | preflight_compile | 2m 6s | – | 0 | | preflight_lint | 2m 20s | – | 0 | | implement | 41m 30s | $38.21 | 0 | | simplify_opus | 29m 2s | $11.78 | 0 | | simplify_gpt | 14m 24s | $6.46 | 0 | | verify | 3m 2s | – | 0 | | fmt | 3s | – | 0 | | **Total** | **93m 23s** | **$56.46** | **0** | </details> <details> <summary>Ran <code>ImplementPlan.fabro</code> (12 nodes and 15 edges)</summary> ```dot digraph ImplementPlan { graph [ goal="Implement and simplify", model_stylesheet=" * { model: claude-opus-4-7; } " ] rankdir=LR start [shape=Mdiamond, label="Start"] exit [shape=Msquare, label="Exit"] toolchain [label="Toolchain", shape=parallelogram, script="command -v cargo >/dev/null || { curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && sudo ln -sf $HOME/.cargo/bin/* /usr/local/bin/; }; cargo --version 2>&1", max_retries=0] preflight_compile [label="Preflight Compile", shape=parallelogram, script="cargo check -q --workspace 2>&1", max_retries=0] preflight_lint [label="Preflight Lint", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1", max_retries=0] fix_lints [label="Fix Lints", prompt="The preflight lint step failed. Read the build output from context and fix all clippy lint warnings.", max_visits=3] implement [label="Implement", prompt="Read the plan file referenced in the goal and implement every step. Make all the code changes described in the plan. Use red/green TDD."] simplify_opus [label="Simplify (Opus)", prompt="@prompts/simplify.md"] simplify_gpt [label="Simplify (GPT-55)", prompt="@prompts/simplify.md", model="gpt-55"] verify [label="Verify", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1 && cargo nextest run --cargo-quiet --workspace --status-level fail 2>&1 && cargo dev docs refresh 2>&1 && cargo dev docs check 2>&1", goal_gate=true, retry_target="fixup"] fixup [label="Fixup", prompt="The verify step failed. Read the build output from context and fix all clippy lint warnings, test failures, and generated docs errors.", max_visits=3] fmt [label="Format", shape=parallelogram, script="cargo +nightly-2026-04-14 fmt --all 2>&1", max_retries=0] start -> toolchain toolchain -> preflight_compile [condition="outcome=succeeded"] toolchain -> exit preflight_compile -> preflight_lint [condition="outcome=succeeded"] preflight_compile -> exit preflight_lint -> implement [condition="outcome=succeeded"] preflight_lint -> fix_lints fix_lints -> preflight_lint implement -> simplify_opus -> simplify_gpt -> verify verify -> fmt [condition="outcome=succeeded"] verify -> fixup fixup -> verify fmt -> exit } ``` </details> ⚒️ Generated with [Fabro](https://fabro.sh) --------- Co-authored-by: Fabro <noreply@fabro.sh> Co-authored-by: Bryan Helmkamp <bryan@brynary.com>	2026-05-22 13:44:42 -04:00
Bryan Helmkamp	4190e13a20	Collapsible run stage sidebar (#352) ... ## What Makes the run-detail stage sidebar (shown on the Overview and Stages tabs) collapsible with a slide animation. - A toggle button slides the panel between full width (`w-56`) and an icon-only rail (`w-12`), animating `width` over 300ms with the same easing as the Ask Fabro panel. - When collapsed, **stage status icons stay visible** — green check / red X / spinning teal for running — so run progress is still scannable at a glance. Workflow links (Graph Source, Run Logs, etc.) collapse to icons too so they remain reachable. - Labels and durations become `sr-only` with `title` tooltips for hover. - The open/closed choice persists to `localStorage` (`fabro:stage-sidebar-collapsed`), carrying across the Overview and Stages tabs and reloads. ## Layout - The collapse toggle is inline with the `STAGES` heading row (or `WORKFLOW` when a run has no stages yet), so it doesn't push the stage list down. - The stage sidebar's top padding on the Stages tab was reduced (`pt-6` → `pt-3`) so the heading aligns with the adjacent content column and sits closer to the tab nav. ## Notes Self-contained in `StageSidebar` — `run-overview.tsx` and `run-stages.tsx` render it inside flex layouts that already track its width, so the slide works in both with no parent changes (aside from the padding tweak). Verified: `tsc` typecheck passes; `stage-sidebar` lib tests pass (10/10). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: fabro-sh-0530[bot] <281434857+fabro-sh-0530[bot]@users.noreply.github.com> Co-authored-by: Fabro <noreply@fabro.sh>	2026-05-22 12:20:29 -04:00
fabro-sh-0530[bot]	199cf0822e	feat: gate Fabro run tools by worker JWT scope (#351) ... Fabro run tools are now gated behind an explicit per-run opt-in so workflow agents only receive those capabilities when the run requests them. ## What changed - **`fabro_tools` setting** (`run.agent.fabro_tools`, default `false`) is resolved through the existing TOML config layer stack. - **Worker JWT scope** adds `agent:run_tools` only when the resolved setting is `true`; default worker tokens carry only `run:worker`. - **Worker tool registration** derives from the worker JWT scope claim. The CLI worker locally decodes the token payload and registers `FabroRunToolServices` only when the scope includes both `run:worker` and `agent:run_tools`. - **Server-side authorization remains authoritative**. The worker-side decode is only a local tool-registration gate; the server still validates token signature and scopes before accepting run-tool API calls. > **Behavior change:** existing runs that relied on Fabro run tools being always available must add `[run.agent] fabro_tools = true` to their workflow config. ## Verification ```sh cargo +nightly-2026-04-14 fmt --all cargo test -p fabro-cli fabro_run_tools_enabled_token_requires_run_tools_scope cargo test -p fabro-server worker_command_ cargo test -p fabro-static cargo +nightly-2026-04-14 clippy -p fabro-cli -p fabro-server -p fabro-static --all-targets -- -D warnings git diff --check ``` --------- Co-authored-by: Fabro <noreply@fabro.sh> Co-authored-by: Bryan Helmkamp <bryan@brynary.com>	2026-05-22 12:12:17 -04:00
fabro-sh-0530[bot]	f5f921aa3c	feat: add [run.agent] fabro_tools opt-in for worker run tools (#348) ... ## Summary Workflow agents previously always received the `agent:run_tools` JWT scope and had Fabro run tools registered unconditionally. This PR makes Fabro run tool access an explicit per-run opt-in via `[run.agent] fabro_tools = true`, defaulting to `false`. ## What changed **Config layer** (`fabro-types`, `fabro-config`): `RunAgentSettings` gains a `fabro_tools: bool` field (serialized with `#[serde(default)]` for backward compatibility). The corresponding `RunAgentLayer` gets an optional `fabro_tools: Option<bool>` that resolves to `false` when absent. Layer merging follows the existing `Combine` macro semantics, so a workflow-level `false` overrides a user-level `true`. **Server** (`fabro-server`): `worker_command` gains an `agent_fabro_tools_enabled: bool` parameter. The server reads `run_state.spec.settings.run.agent.fabro_tools` from the stored run before spawning `__run-worker`, then issues the worker JWT with either `["run:worker"]` or `["run:worker", "agent:run_tools"]` accordingly. `WorkerScopeSet::run_worker()` loses its `#[cfg(test)]` gate so it's available in production paths. **CLI worker** (`fabro-cli`): `FabroRunToolServices` construction is now gated on `run_spec.settings.run.agent.fabro_tools` rather than being unconditional. The resolved run spec already carries the setting, so no env-var parsing is needed in the runner. **Tests**: The single monolithic `worker_command_always_sets_worker_token_env` test is replaced by two focused tests — one confirming the default scope is `["run:worker"]` only, and one confirming the opt-in scope includes `agent:run_tools`. Shared assertion logic is extracted into `assert_worker_command_passes_token_only_by_env` and `worker_token_claims` helpers. Config resolver tests cover default, explicit true/false, and layer-override behavior. **Docs**: `[run.agent]` description and reference tables are updated; a new `run-configuration.mdx` section explains the opt-in semantics before the existing `[run.agent.mcps]` section. ### Plan Summary - 1. Add `fabro_tools` to resolved and layered run config, with resolver tests. - 2. Gate worker JWT scope and pass setting from stored run state into `worker_command`. - 3. Gate CLI `FabroRunToolServices` construction on the resolved setting. - 4. Update docs generator sample and public reference/execution docs. - 5. Full verification pass (nextest, fmt, clippy). ### Fabro Details <details> <summary>Ran 9 stages in 54m 4s for $15.21</summary> | Stage | Duration | Cost | Retries | |---|---|---|---| | start | 0s | – | 0 | | toolchain | 1s | – | 0 | | preflight_compile | 2m 4s | – | 0 | | preflight_lint | 2m 18s | – | 0 | | implement | 28m 5s | $10.58 | 0 | | simplify_opus | 12m 4s | $2.86 | 0 | | simplify_gpt | 5m 19s | $1.77 | 0 | | verify | 3m 37s | – | 0 | | fmt | 3s | – | 0 | | **Total** | **54m 4s** | **$15.21** | **0** | </details> <details> <summary>Ran <code>ImplementPlan.fabro</code> (12 nodes and 15 edges)</summary> ```dot digraph ImplementPlan { graph [ goal="Implement and simplify", model_stylesheet=" * { model: claude-opus-4-7; } " ] rankdir=LR start [shape=Mdiamond, label="Start"] exit [shape=Msquare, label="Exit"] toolchain [label="Toolchain", shape=parallelogram, script="command -v cargo >/dev/null || { curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && sudo ln -sf $HOME/.cargo/bin/* /usr/local/bin/; }; cargo --version 2>&1", max_retries=0] preflight_compile [label="Preflight Compile", shape=parallelogram, script="cargo check -q --workspace 2>&1", max_retries=0] preflight_lint [label="Preflight Lint", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1", max_retries=0] fix_lints [label="Fix Lints", prompt="The preflight lint step failed. Read the build output from context and fix all clippy lint warnings.", max_visits=3] implement [label="Implement", prompt="Read the plan file referenced in the goal and implement every step. Make all the code changes described in the plan. Use red/green TDD."] simplify_opus [label="Simplify (Opus)", prompt="@prompts/simplify.md"] simplify_gpt [label="Simplify (GPT-55)", prompt="@prompts/simplify.md", model="gpt-55"] verify [label="Verify", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1 && cargo nextest run --cargo-quiet --workspace --status-level fail 2>&1 && cargo dev docs refresh 2>&1 && cargo dev docs check 2>&1", goal_gate=true, retry_target="fixup"] fixup [label="Fixup", prompt="The verify step failed. Read the build output from context and fix all clippy lint warnings, test failures, and generated docs errors.", max_visits=3] fmt [label="Format", shape=parallelogram, script="cargo +nightly-2026-04-14 fmt --all 2>&1", max_retries=0] start -> toolchain toolchain -> preflight_compile [condition="outcome=succeeded"] toolchain -> exit preflight_compile -> preflight_lint [condition="outcome=succeeded"] preflight_compile -> exit preflight_lint -> implement [condition="outcome=succeeded"] preflight_lint -> fix_lints fix_lints -> preflight_lint implement -> simplify_opus -> simplify_gpt -> verify verify -> fmt [condition="outcome=succeeded"] verify -> fixup fixup -> verify fmt -> exit } ``` </details> ⚒️ Generated with [Fabro](https://fabro.sh) --------- Co-authored-by: Fabro <noreply@fabro.sh> Co-authored-by: fabro-agent <agent@fabro.local>	2026-05-22 09:41:27 -04:00
Bryan Helmkamp	c6356cbd77	feat: improve run board, thread, and MCP create flows (#347) ... ## Summary This branch improves several run-management surfaces that agents and users rely on: archived runs now stay visible and ordered correctly in the board view, pair-session messages appear in the stage Thread tab, and the `fabro_run_create` MCP tool accepts the workflow-string shorthand it advertises. ## Changes - Updates the web board cache invalidation and archived-column handling so archive/unarchive actions refresh both active and archived board queries and keep archived runs in a predictable column position. - Adds pair user/system message events to stage activity parsing, Thread rendering, search, details, and DNA timeline items. - Aligns `fabro_run_create` MCP runtime deserialization and `tools/list` schema so each run entry may be either a workflow string or a full create spec object. ## Test Plan - `cargo nextest run -p fabro-tool -p fabro-mcp-server` - `cargo nextest run -p fabro-cli stdio_server_initializes_and_lists_run_tools mcp_create_string_shorthand_deserializes_before_auth mcp_create_validation_errors_happen_before_auth_or_network mcp_create_and_search_manage_real_runs_with_cli_auth` - `cargo +nightly-2026-04-14 fmt --check --all` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 09:39:20 -04:00
fabro-sh-0530[bot]	f5ec711a2c	Stage-based pairing API and fabro_run_pair MCP tool (#344) ... ## Summary Run pairing previously required callers to supply an opaque `agent_session_id` alongside a `stage_id` to start or target a pair session. This leaked an internal runtime identifier across the public HTTP API, generated TypeScript client, and would have bled into any MCP tooling. This PR removes that coupling: the public pair API now identifies targets by `StageId` alone, the server resolves the live session internally, and a new `fabro_run_pair` MCP tool exposes the full pair lifecycle without ever seeing session identifiers. ### What changed **Public contract simplification** (`fabro-types`, OpenAPI, generated TS client) - `PairTarget` is now `{ stage_id, node_label }` — `node_id`, `visit`, `agent_session_id`, `provider`, and `model` are removed. - `PairStartRequest` accepts `{ stage_id }` instead of `{ target: PairTargetSelector }`. - `PairTargetSelector` and `PairTranscriptModel` types are deleted entirely. - `PairMessageRecord.target` (selector) replaced by `PairMessageRecord.stage_id`. - `PairTranscriptAssistantMessage.model` field removed. - `MAX_PAIR_MESSAGE_BYTES` extracted as a public constant shared between the server handler and the MCP tool. **Internal session binding** (`SteeringHub`, server projection) - `ActivePair` now carries `session_id: String` separately from the public `PairRecord`. This preserves the stale-session protection that previously relied on `target.agent_session_id`. - Transcript matching changed from `(session_id AND stage_id)` to `stage_id` within the already-scoped pair window sequence range — simpler and sufficient. - `active_api_targets` deactivation no longer does a per-target `agent_session_id` check; it relies on the `active_steerable_stages` lease already doing that guard. **New `fabro_run_pair` MCP tool** (`fabro-mcp-server`) - Actions: `status`, `start`, `get`, `message`, `end`, `transcript`. - Validation happens before any network call; missing `run_id`, missing `stage_id` for `start`, missing/invalid `pair_id` for other actions, and overlong message text all return clean tool-level errors. - `strum::IntoStaticStr` on `RunPairAction` enables the `parse_pair_id_for_action` helper to embed the action name in error messages without a `match`. - MCP result schema and serialized results are covered by leakage assertions confirming none of the removed fields surface. **Tests** - Negative leakage assertions added to pair DTO tests, event round-trip tests, control-protocol tests, server handler tests, MCP validation tests, and MCP schema test. - Tool count updated from 5 → 6 in all CLI MCP integration tests. - Steering hub test renamed: `pair_start_rejects_non_selected_or_missing_target` → `pair_start_rejects_missing_target` (session-mismatch rejection is now an internal concern). ### Fabro Details <details> <summary>Ran 9 stages in 60m 29s for $31.78</summary> | Stage | Duration | Cost | Retries | |---|---|---|---| | start | 0s | – | 0 | | toolchain | 1s | – | 0 | | preflight_compile | 2m 9s | – | 0 | | preflight_lint | 2m 26s | – | 0 | | implement | 33m 14s | $25.51 | 0 | | simplify_opus | 15m 7s | $4.18 | 0 | | simplify_gpt | 3m 46s | $2.08 | 0 | | verify | 3m 9s | – | 0 | | fmt | 3s | – | 0 | | **Total** | **60m 29s** | **$31.78** | **0** | </details> <details> <summary>Ran <code>ImplementPlan.fabro</code> (12 nodes and 15 edges)</summary> ```dot digraph ImplementPlan { graph [ goal="Implement and simplify", model_stylesheet=" * { model: claude-opus-4-7; } " ] rankdir=LR start [shape=Mdiamond, label="Start"] exit [shape=Msquare, label="Exit"] toolchain [label="Toolchain", shape=parallelogram, script="command -v cargo >/dev/null || { curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && sudo ln -sf $HOME/.cargo/bin/* /usr/local/bin/; }; cargo --version 2>&1", max_retries=0] preflight_compile [label="Preflight Compile", shape=parallelogram, script="cargo check -q --workspace 2>&1", max_retries=0] preflight_lint [label="Preflight Lint", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1", max_retries=0] fix_lints [label="Fix Lints", prompt="The preflight lint step failed. Read the build output from context and fix all clippy lint warnings.", max_visits=3] implement [label="Implement", prompt="Read the plan file referenced in the goal and implement every step. Make all the code changes described in the plan. Use red/green TDD."] simplify_opus [label="Simplify (Opus)", prompt="@prompts/simplify.md"] simplify_gpt [label="Simplify (GPT-55)", prompt="@prompts/simplify.md", model="gpt-55"] verify [label="Verify", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1 && cargo nextest run --cargo-quiet --workspace --status-level fail 2>&1 && cargo dev docs refresh 2>&1 && cargo dev docs check 2>&1", goal_gate=true, retry_target="fixup"] fixup [label="Fixup", prompt="The verify step failed. Read the build output from context and fix all clippy lint warnings, test failures, and generated docs errors.", max_visits=3] fmt [label="Format", shape=parallelogram, script="cargo +nightly-2026-04-14 fmt --all 2>&1", max_retries=0] start -> toolchain toolchain -> preflight_compile [condition="outcome=succeeded"] toolchain -> exit preflight_compile -> preflight_lint [condition="outcome=succeeded"] preflight_compile -> exit preflight_lint -> implement [condition="outcome=succeeded"] preflight_lint -> fix_lints fix_lints -> preflight_lint implement -> simplify_opus -> simplify_gpt -> verify verify -> fmt [condition="outcome=succeeded"] verify -> fixup fixup -> verify fmt -> exit } ``` </details> ⚒️ Generated with [Fabro](https://fabro.sh) --------- Co-authored-by: Fabro <noreply@fabro.sh> Co-authored-by: Bryan Helmkamp <bryan@brynary.com>	2026-05-21 21:57:55 -04:00
fabro-sh-0530[bot]	54bc67017e	feat: Replace duration/elapsed fields with wall_time_ms and StageTiming (#343) ... ## Summary Replaces the ambiguous `runtime_secs`, `elapsed_secs`, and `duration_ms` timing fields on run/stage public API surfaces with explicit `wall_time_ms` (elapsed clock time) and a `StageTiming` value object that also carries `inference_time_ms`, `tool_time_ms`, and `active_time_ms`. This is a greenfield breaking change — no compatibility shims are preserved. ### What changed **API shape** - `RunBillingStage.runtime_secs` → `RunBillingStage.timing: StageTiming` - `RunBillingTotals.runtime_secs` → `RunBillingTotals.timing: StageTiming` - `RunSummary.timestamps.duration_ms` / `elapsed_secs` removed; a top-level `timing: StageTiming | null` field added - Stage list item `duration_secs` → `wall_time_ms` **Web app (`apps/fabro-web`)** - `run-billing.tsx`: `liveRuntimeSecs` → `liveWallTimeMs`; live ticking now returns milliseconds and the footer total sums `wallTimeMs` across rows - `stage-sidebar.ts`: `duration_secs` → `wall_time_ms` for the per-stage duration display - `runs.ts`: `elapsed_secs` lookup replaced with `timing.wall_time_ms` - `formatElapsedSecs` / `formatDurationSecs` call sites replaced with `formatDurationMs` **Lockfile / tooling** - `@openapitools/openapi-generator-cli@2.20.2` added as a dev dependency to `@qltysh/fabro-api-client` to support regenerating the TypeScript client after schema edits; several transitive deps pulled in alongside it. ### Design notes - **Units are now consistent**: every timing value on run/stage surfaces is in milliseconds; the old API mixed seconds (`runtime_secs`, `elapsed_secs`) with milliseconds (`duration_ms`). - **Live ticking** still works correctly: the in-flight billing row computes `now - startedAt` in ms and sums across rows for the footer, avoiding a server round-trip during a running stage. - **`StageTiming.active_time_ms = inference_time_ms + tool_time_ms`** — parallel work is summed, so run active time can exceed wall time. - Subsystem-internal `duration_ms` fields (sandbox setup, devcontainer lifecycle, hooks) are intentionally left unchanged; only public run/stage timing surfaces are affected. ### Fabro Details <details> <summary>Ran 9 stages in 115m 53s for $108.50</summary> | Stage | Duration | Cost | Retries | |---|---|---|---| | start | 0s | – | 0 | | toolchain | 1s | – | 0 | | preflight_compile | 2m 6s | – | 0 | | preflight_lint | 2m 18s | – | 0 | | implement | 80m 53s | $101.97 | 0 | | simplify_opus | 21m 35s | $4.09 | 0 | | simplify_gpt | 5m 1s | $2.44 | 0 | | verify | 3m 11s | – | 0 | | fmt | 3s | – | 0 | | **Total** | **115m 53s** | **$108.50** | **0** | </details> <details> <summary>Ran <code>ImplementPlan.fabro</code> (12 nodes and 15 edges)</summary> ```dot digraph ImplementPlan { graph [ goal="Implement and simplify", model_stylesheet=" * { model: claude-opus-4-7; } " ] rankdir=LR start [shape=Mdiamond, label="Start"] exit [shape=Msquare, label="Exit"] toolchain [label="Toolchain", shape=parallelogram, script="command -v cargo >/dev/null || { curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y && sudo ln -sf $HOME/.cargo/bin/* /usr/local/bin/; }; cargo --version 2>&1", max_retries=0] preflight_compile [label="Preflight Compile", shape=parallelogram, script="cargo check -q --workspace 2>&1", max_retries=0] preflight_lint [label="Preflight Lint", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1", max_retries=0] fix_lints [label="Fix Lints", prompt="The preflight lint step failed. Read the build output from context and fix all clippy lint warnings.", max_visits=3] implement [label="Implement", prompt="Read the plan file referenced in the goal and implement every step. Make all the code changes described in the plan. Use red/green TDD."] simplify_opus [label="Simplify (Opus)", prompt="@prompts/simplify.md"] simplify_gpt [label="Simplify (GPT-55)", prompt="@prompts/simplify.md", model="gpt-55"] verify [label="Verify", shape=parallelogram, script="cargo +nightly-2026-04-14 clippy -q --workspace --all-targets -- -D warnings 2>&1 && cargo nextest run --cargo-quiet --workspace --status-level fail 2>&1 && cargo dev docs refresh 2>&1 && cargo dev docs check 2>&1", goal_gate=true, retry_target="fixup"] fixup [label="Fixup", prompt="The verify step failed. Read the build output from context and fix all clippy lint warnings, test failures, and generated docs errors.", max_visits=3] fmt [label="Format", shape=parallelogram, script="cargo +nightly-2026-04-14 fmt --all 2>&1", max_retries=0] start -> toolchain toolchain -> preflight_compile [condition="outcome=succeeded"] toolchain -> exit preflight_compile -> preflight_lint [condition="outcome=succeeded"] preflight_compile -> exit preflight_lint -> implement [condition="outcome=succeeded"] preflight_lint -> fix_lints fix_lints -> preflight_lint implement -> simplify_opus -> simplify_gpt -> verify verify -> fmt [condition="outcome=succeeded"] verify -> fixup fixup -> verify fmt -> exit } ``` </details> ⚒️ Generated with [Fabro](https://fabro.sh) --------- Co-authored-by: Fabro <noreply@fabro.sh> Co-authored-by: Bryan Helmkamp <bryan@brynary.com>	2026-05-21 21:06:40 -04:00
Bryan Helmkamp	fb2174c7d0	feat(agent): expose Fabro run tools in sessions (#339) ... ## Summary API-backed Fabro agent sessions can now use the same five run-control tools that were previously MCP-only, while the server uses a single scoped `FABRO_WORKER_TOKEN` path for worker authorization. This lets server-dispatched API agents create, gather, inspect, and interact with runs without reintroducing a separate delegated run-agent token or leaking credentials into sandboxed child environments. ## Changes - Moved the reusable run-tool implementation into the new `fabro-tool` crate so MCP and API agent backends share the same tool schemas and client behavior. - Registered the five `fabro_run_*` tools for API-mode agents, with ACP sessions continuing to omit those tools. - Replaced `FABRO_RUN_AGENT_TOKEN` with scoped worker-token auth: base worker tokens keep same-run access, and `run:worker agent:run_tools` tokens can call the run-control API across runs. - Added server auth guards for run-tool actors and run-scoped-or-run-tools routes, then applied them only to the routes used by the run-tool client backend. - Kept `FABRO_WORKER_TOKEN` scrubbed from sandbox commands, hooks, ACP subprocesses, MCP env providers, and other child tool environments. ## Testing - `cargo nextest run -p fabro-server worker_token principal_middleware spawn_env --no-fail-fast` - `cargo nextest run -p fabro-cli runner --no-fail-fast` - `cargo nextest run -p fabro-workflow agent_run --no-fail-fast` - `cargo nextest run -p fabro-static --no-fail-fast` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy -p fabro-server -p fabro-cli -p fabro-static --all-targets -- -D warnings` - `git diff --check` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-21 19:48:54 -04:00
Bryan Helmkamp	37d6b3dbcd	fix(server): count whole storage tree in Fabro-managed bytes ... build_disk_usage_response only summed scratch/ run dirs and logs/*.log, omitting objects/ (SlateDB + artifacts), sessions/, and vaults/ — a ~30x undercount of "Fabro managed" storage on the resources page. Measure the whole storage_dir tree for total_size_bytes so it can't drift as new subdirectories are added. Reclaimable stays a curated estimate that matches what `fabro system prune` actually frees. A residual "other" summary row keeps `fabro system df` totals consistent and surfaces as a "Database & artifacts" table row. Also add a KiB tier to formatBytesAsMemory so small storage values render human-readably instead of raw byte counts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-21 11:28:39 -04:00
Bryan Helmkamp	86b1fbef7f	feat(api): bind sessions to runs (#336) ... ## Summary Ask Fabro sessions are now run-bound instead of standalone. Sessions are created under their owning run, then accessed by flat session ID routes, with durable state projected from the run event stream rather than a separate session store. ## Changes - Move session creation/listing to `POST/GET /api/v1/runs/{id}/sessions` while keeping flat session reads, turns, interrupts, and event streams under `/api/v1/sessions/{id}/...`. - Add typed `run.session.*` events, ULID-backed session/turn IDs, read-only default permissions, and a rebuildable SlateDB `session_id -> run_id` index. - Remove the old file-backed session store and wire the server, runtime, Rust client, generated API crates, and TypeScript client around run event projections. - Replace the old top-level CLI session command with `fabro run ask` for chatting with a run. - Regenerate the TypeScript API client; this also catches up existing generated models for Pair/run event detail schemas already present in the OpenAPI spec. ## Validation - `cargo build -p fabro-api -p fabro-client -p fabro-server -p fabro-cli` - `cargo nextest run -p fabro-server --features test-support -E 'test(run_bound_session_is_created_as_run_event_and_resolves_by_flat_id) | test(sessions_are_listed_only_under_their_owning_run)'` - `cargo nextest run -p fabro-store projection_rebuilds_runtime_context_from_run_events` - `cargo +nightly-2026-04-14 clippy -p fabro-api -p fabro-client -p fabro-store -p fabro-server -p fabro-cli --all-targets -- -D warnings` - `cargo +nightly-2026-04-14 fmt --check --all` - `cd lib/packages/fabro-api-client && bun run typecheck && cd ../../../apps/fabro-web && bun run typecheck` - `git diff --check` --- [](https://github.com/EveryInc/compound-engineering-plugin) Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-21 10:53:41 -04:00
Bryan Helmkamp	02fabb7b47	fix(workflow): capture configured artifacts once (#337) ... ## Summary Fixes artifact promotion for configured `[run.artifacts].include` globs by collecting matching files after each stage regardless of mtime and surfacing failed discovery commands as collection failures. The workflow lifecycle now keeps a per-run ledger keyed by `(path, content_sha256)`, rebuilt from existing `artifact.captured` events, so unchanged files are persisted and emitted once while changed content at the same path can still be captured again. Fixes fabro-sh/fabro#335. ## Tests - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo nextest run -p fabro-workflow artifact_snapshot` - `cargo nextest run -p fabro-cli unchanged_matching_artifact_is_captured_once_across_stages` - `cargo nextest run -p fabro-cli acp_artifacts_are_listed_when_touched_file_mtime_precedes_attempt_start` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Jess Martin <27258+jessmartin@users.noreply.github.com>	2026-05-21 10:52:22 -04:00
Bryan Helmkamp	9837a08929	refactor(install): share persistence pipeline (#332) ... ## Summary Unifies installer persistence so CLI and web install paths share the same file/env/vault primitives, while preserving the CLI's server-API secret persistence and auth bootstrap behavior. ## What Changed - Added shared `fabro-install` config writers for installer-owned tagged enum tables, replacing `server.listen` and `cli.target` atomically so stale variant fields cannot survive. - Added `InstallPersistencePlan` for disk-backed settings, server env, and vault writes/removals with the existing rollback semantics for settings and vault failures. - Refactored `fabro install`, `fabro install github`, and `/install/finish` to use the shared persistence plan where their disk behavior overlaps. - Preserved full-install ordering: settings/env first, workflow-visible secrets through the server API second, and CLI `auth.json` only after API secret persistence succeeds. - Preserved web installer failure response fields for leftover and removed env keys, plus the post-success finish hook/shutdown behavior. ## Test Plan - `cargo nextest run -p fabro-install` - `cargo nextest run -p fabro-cli commands::install::tests` - `cargo nextest run -p fabro-cli --test it cmd::install` - `cargo nextest run -p fabro-server --features test-support --test it api::install` - `cargo +nightly-2026-04-14 fmt --check --all` - `git diff --check` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-21 08:04:04 -04:00
Bryan Helmkamp	15ff38fa53	feat(template): resolve template error locations (#333) ... ## Summary Fixes `fabro-sh/fabro#330` by making template partials that reference missing inputs validate structurally with a warning instead of failing the validate command. The template crate now owns MiniJinja semantic error classification and source-location mapping, so workflow diagnostics can consume already-resolved template locations instead of remapping fragment spans itself. ## What Changed - Added `TemplateErrorLocation` and `TemplateSourceOrigin` APIs to report source name, line, column, and span from `fabro-template`. - Classified wrapped MiniJinja errors by their deepest semantic cause, preserving the original source chain for renderer context. - Added fragment-origin rendering paths so attribute fragments embedded in full workflow source report locations in the original source text. - Removed workflow-side source span remapping from template diagnostics; workflow now only adds owner, node/edge, severity, rule, and fix context. - Added regression coverage for include/import/from/extends undefined variables and the CLI `fabro validate` partial fixture. ## Test Plan - `cargo nextest run -p fabro-template` - `cargo nextest run -p fabro-workflow transforms::variable_expansion transforms::file_inlining` - `cargo nextest run -p fabro-cli --test it cmd::validate` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy -p fabro-template -p fabro-workflow -p fabro-cli --all-targets -- -D warnings` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 (context not reported, reasoning not reported) via [Codex](https://openai.com/codex)	2026-05-20 20:15:04 -04:00
Bryan Helmkamp	bf96baa9f0	feat(server): add run pairing API (#312) ... ## Summary Adds the server-side run pairing surface for joining one active API-mode agent session, sending pair messages, reading a compact transcript, and ending pairing explicitly before workflow release continues. This PR wires the feature end to end: - adds OpenAPI paths and shared `fabro-types` DTOs for pair lifecycle, messages, transcript entries, and run event details - adds typed `RunEvent` variants for pair lifecycle and pair-scoped user/system messages - extends the workflow steering hub and agent session drain path with typed pair control items, single-target validation, pair parking, and pair end/resume behavior - extends worker JSONL control and server transports for pair start/message/end while preserving existing steer/interrupt/answer/cancel behavior - adds Axum handlers for `/api/v1/runs/{id}/pair`, pair messages, pair transcript, and `/api/v1/runs/{id}/events/{seq}` - adds `fabro-client` helpers for the new endpoints ## Notes The subprocess path does not add a bidirectional worker ack channel in this PR. Instead, the HTTP pair handlers only return lifecycle/message success after the corresponding durable runtime event is observed, so mpsc enqueue success alone is not treated as API success. The plan checklist in `docs/superpowers/plans/2026-05-18-server-side-run-pairing-api-events.md` is included with that distinction left visible. ## Verification - `cargo build -p fabro-api` - `cargo check -p fabro-api -p fabro-client -p fabro-agent -p fabro-workflow -p fabro-interview -p fabro-server` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo nextest run -p fabro-api pair run_event_round_trips_pair_lifecycle_events run_event_round_trips_agent_pair_messages` - `cargo nextest run -p fabro-workflow pair` - `cargo nextest run -p fabro-interview pair` - `cargo nextest run -p fabro-server pair subprocess_answer_transport_pair_commands_enqueue_control_messages steer interrupt`	2026-05-20 18:58:38 -04:00
Bryan Helmkamp	32015b2226	fix(graph): support dotted Fabro graph attributes (#324) ... ## Summary Graph rendering now accepts documented Fabro dotted DOT attributes end to end while keeping raw Graphviz calls behind `fabro-graphviz`. The new `RenderableDot` boundary applies Fabro render styling and normalization before raw SVG rendering, and both the CLI subprocess and server path now route through that typed boundary instead of calling `graphviz_sys` directly outside the graphviz crate. The branch also adds a small curated DOT compatibility corpus covering ACP agent attributes, human default choices, and subworkflow manager attributes. Those fixtures are exercised by both render and validation tests, and the run overview now shows graph render errors directly instead of falling through to the empty graph state. ## Verification - `cargo nextest run -p fabro-graphviz` - `cargo nextest run -p fabro-validate` - `cargo nextest run -p fabro-cli render_graph` - `cargo nextest run -p fabro-server render_graph_from_manifest_accepts_fabro_dotted_attributes` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy -p fabro-graphviz -p fabro-cli -p fabro-server -p fabro-validate --all-targets -- -D warnings` - `rg -n "graphviz_sys" lib/crates/fabro-cli lib/crates/fabro-server` - `cd apps/fabro-web && bun test` - `cd apps/fabro-web && bun run typecheck` --- [](https://github.com/EveryInc/compound-engineering-plugin) Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Jess Martin <27258+jessmartin@users.noreply.github.com>	2026-05-20 09:31:08 -04:00
Bryan Helmkamp	21c408d647	fix(workflow): allow workflow-root template partials (#322) ... ## Summary - Add a CLI validation regression for workflow-root prompt partials included from nested prompt files. - Allow bundled prompt templates to resolve sibling partials from the workflow root instead of jailing each prompt file to its own directory. - Refactor include handling so manifest discovery and runtime rendering share rooted template sources, include normalization, root containment checks, and FileResolver-backed TemplateStore loading. ## Testing - `cargo nextest run -p fabro-template` - `cargo nextest run -p fabro-manifest` - `cargo nextest run -p fabro-workflow` - `cargo nextest run -p fabro-cli cmd::validate` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy -p fabro-template -p fabro-manifest -p fabro-workflow -p fabro-cli --all-targets -- -D warnings` --------- Co-authored-by: Aleksi Asikainen <1086393+salieri@users.noreply.github.com>	2026-05-20 09:22:28 -04:00
David Bock	ef70dbc5be	fix(cli): print full run id on rm (#315) ... When `fabro rm` succeeds, the confirmation output should identify exactly which run was removed. Today the human-readable path prints a shortened run ID, which is less precise than the JSON output and less useful for copy/paste confirmation. ## Summary - print the full run ID after successful `fabro rm` removal - keep `--json` behavior unchanged - update CLI snapshots to expect full IDs on success paths ## Testing - cargo test -p fabro-cli rm_ -- --nocapture - cargo +nightly-2026-04-14 fmt --check --all	2026-05-20 08:24:31 -04:00
Bryan Helmkamp	29b7cc0de0	feat(workflow): enforce strict api/acp backends (#307) ... ## Summary This PR makes agent execution a strict two-backend contract: API-backed stages use Fabro-owned model/provider auth, while ACP-backed stages launch a user-supplied stdio process that owns its own auth and tools. That removes the legacy CLI backend and prevents ACP execution from accidentally resolving or forwarding provider credentials. ## Changes - Replaces the old `api`/`cli`/`acp` backend model with `AgentBackend { api, acp }`, with `backend=\"cli\"` rejected and migrated toward explicit ACP process configuration. - Splits ACP process configuration into `acp.command` for shell command strings and `acp.config` for JSON stdio configs, while rejecting legacy `acp_command`. - Restricts ACP to `agent` nodes and rejects API-only attributes such as `model`, `provider`, `reasoning_effort`, `max_tokens`, and `speed` on ACP nodes. - Deletes the workflow CLI runtime, CLI credential resolver surface, CLI live smoke tests, and `agent.cli.*` event handling. - Updates ACP events and projections to report process identity (`command`, optional `config_name`) rather than provider/model metadata. - Updates import/stylesheet propagation, CLI workflow smoke coverage, server steering tests, and web model extraction for the new event/backend contract. ## Validation - `cargo check -p fabro-auth -p fabro-acp -p fabro-workflow -p fabro-cli --all-targets` - `cargo nextest run -p fabro-auth -p fabro-acp -p fabro-validate -p fabro-store -p fabro-workflow --lib` - `cargo nextest run -p fabro-acp` - `cargo nextest run -p fabro-cli --test it workflow::acp::acp_backend_workflow` - `cargo nextest run -p fabro-workflow --test it codergen_without_backend_simulated` - `cargo nextest run -p fabro-workflow --test it import_e2e_through_engine` - `cargo nextest run -p fabro-workflow --test it stylesheet_application` - `cargo nextest run -p fabro-server steer_with_active_acp_stage_returns_non_steerable_conflict` - `cargo nextest run -p fabro-server active_acp_stage_marker_clears_on_terminal_paths` - `cargo nextest run -p fabro-types agent_backend_accepts_only_api_and_acp` - `cd apps/fabro-web && bun test app/routes/run-stages.test.ts` - `cd apps/fabro-web && bun run typecheck` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Peter Bell <4843+PeterBell@users.noreply.github.com>	2026-05-18 13:20:56 -04:00
Bryan Helmkamp	cd74013d06	refactor(auth): split credential sources and vault schemas (#306) ... ## Summary Compared with `origin/main`, this PR splits credential storage and credential references into explicit types. Vault secrets now distinguish `token`, `oauth`, and `file` payloads, while runtime/model configuration points to credentials through explicit `env:<NAME>` and `vault:<NAME>` source refs. ## Changes - Replaces the old `environment`/`credential` secret schema vocabulary with `token`/`oauth`/`file` across OpenAPI, Rust API tests, generated TypeScript models, CLI/docs references, and the changelog. - Updates auth resolution, refresh, provider strategies, workflow LLM handling, server diagnostics, install flows, run manifests, and secret handlers to consume typed vault entries and explicit credential sources. - Updates provider catalog TOMLs and config parsing so provider auth and extra headers use `vault` refs instead of ambiguous `credential` refs. - Updates CLI install/login/run/secret paths and integration tests to write and read the new credential shapes. - Removes the temporary legacy vault migration and empty-vault fallback, then centralizes provider vault secret-name lookup and Codex API credential shaping. ## Verification - `cargo +nightly-2026-04-14 fmt --all` - `cargo +nightly-2026-04-14 clippy -p fabro-auth -p fabro-model -p fabro-config -p fabro-vault -p fabro-server -p fabro-cli --all-targets -- -D warnings` - `ulimit -n 4096 && cargo nextest run -p fabro-auth -p fabro-model -p fabro-config -p fabro-vault -p fabro-server -p fabro-cli` (`1938` passed, `35` skipped)	2026-05-18 11:07:42 -04:00
David Bock	6a86ced77c	fix(server): persist manifest metadata names (#302) ... When Fabro creates a detached run through the server, the resulting run metadata should still read like something a human can trust at a glance. Before this change, those runs could persist with `settings.project.name` and `settings.workflow.name` left `null` even though Fabro already had enough local context to infer them. That made `inspect` output look half-populated and made it harder to tell whether the saved run state was complete. This fixes that trust gap in the server-backed manifest flow. ## Summary - backfill missing manifest-backed project and workflow names during server run preparation - prefer explicit `[workflow].name` from bundled `workflow.toml`, then fall back to graph name or workflow slug - cover both manifest preparation and persisted run-state behavior with server tests ## Testing - cargo test -p fabro-server prepare_manifest_backfills_missing_project_and_workflow_names -- --nocapture - cargo test -p fabro-server prepare_manifest_preserves_explicit_project_and_workflow_names -- --nocapture - cargo test -p fabro-server create_run_persists_backfilled_project_and_workflow_names -- --nocapture --------- Co-authored-by: Bryan Helmkamp <bryan@brynary.com>	2026-05-18 08:31:23 -04:00
Aleksi Asikainen	492aba7fff	fix: MiniJinja can't find partials (#301) ... Fixes an issue where use of MiniJinja [`include`](https://jinja.palletsprojects.com/en/stable/templates/#include) control structure (`{% include "filename.ext" %}`) causes a render error `template not found: tried to include non-existing template "filename.ext"` ### Example broken diagram ``` dot digraph ValidatePlan { start [shape=Mdiamond, label="Start"] exit [shape=Msquare, label="Exit"] test_inline_prompt [label="moo" prompt="{% include 'test.tpl.md' %}"] // ^^^^^^^^^^^^^^^^^^^^^^^^^ start -> test_inline_prompt -> exit } ``` ### Fix The core issue was that template rendering knew the source name for diagnostics, but did not have a loader rooted at the prompt/goal file location. Includes therefore failed even when the included file existed next to the rendered file. The fix adds optional loader support to `fabro-template`, then wires workflow rendering to the existing `FileResolver` so includes resolve relative to the file currently being rendered. For `fabro validate`, there was a second manifest-specific problem: validation runs through a bundled manifest, and the manifest builder only bundled explicit `prompt.md` / `goal.md` files, not static MiniJinja `include` dependencies inside those files. The manifest builder now scans prompt/goal template text for literal `{% include "file" %}` / `{% include 'file' %}` references and bundles those files too. Missing or unsafe include names are left for MiniJinja/runtime validation rather than expanding scope. (For clarity: The fix does not support variables or arrays in `include`.)	2026-05-17 22:15:45 -04:00
Bryan Helmkamp	302e2445b4	refactor(model): move provider facts into catalog (#298) ... ## Summary Moves provider-specific facts out of `AdapterKind` metadata and into provider catalog data, leaving adapters responsible for runtime protocol behavior. This makes providers that share an adapter mostly TOML-driven while still surfacing adapter construction failures during readiness checks. ## What Changed - Provider TOML now owns auth mode, API-key/header policy, billing policy, agent profile, base URLs/env overrides, extra headers, and probe markers. - Auth, install, config, diagnostics, and server flows resolve provider credentials from catalog auth config, including API-key, header-only, and no-auth providers. - LLM client registration now reports adapter construction failures, validates final adapter requests before HTTP dispatch, and preserves custom primary auth headers. - Billing and docs now use provider-owned billing policy instead of adapter metadata, and the old adapter metadata surface is removed. ## Reviewer Notes OpenAI-compatible `base_url` validation now happens during adapter/client registration rather than catalog build. That keeps catalog parsing adapter-agnostic while still letting readiness and model listing reflect providers that cannot register. ## Verification - `cargo check -p fabro-model -p fabro-auth -p fabro-llm -p fabro-server -p fabro-cli` - `cargo nextest run -p fabro-llm -- adapter_registry` - `cargo nextest run -p fabro-model -- catalog` - `cargo nextest run -p fabro-auth -- api_key` - `cargo nextest run -p fabro-server -- install` - `cargo +nightly-2026-04-14 fmt --check --all` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 20:59:08 -04:00
Bryan Helmkamp	93452001a1	feat(api): require typed PermissionLevel on session create (#300) ... ## Summary - `POST /api/v1/sessions` now requires `permissions` as a typed enum (`read-only` | `read-write` | `full`) instead of accepting an optional plain string. - Removes the silent fallback at `sessions.rs:906-911` where unknown values (e.g. `"readonly"`) were coerced to `read-write` — a real security footgun: a client trying to lock the agent down would get write access instead. - Invalid or missing values are now rejected by axum's `Json` extractor with `422 Unprocessable Entity`. ## Approach - New `PermissionLevel` OpenAPI schema (`type: string, enum: [...]`). - Moves `PermissionLevel` from `fabro_agent::cli` to `fabro_types::session` so `fabro-api` can `with_replacement` it without a circular dep. `fabro_agent::cli::PermissionLevel` remains as a `pub use` re-export so existing call sites keep working. - `SessionRecord.permissions` becomes required and non-nullable for coherence — every created session has a concrete level. - `build_tool_approval` in the server takes `PermissionLevel` directly; the string-match fallback is deleted. - CLI's `session_permissions` returns a concrete `PermissionLevel` (defaults to `read-write` when neither flag nor settings provide one) and is sent explicitly on every request. ## Scope notes Confirmed out of scope and not addressed here: - Mid-session model/permission switching - Interactive tool approval / HITL ## Breaking change The `permissions` field is now required on `CreateSessionRequest` and non-nullable on `SessionRecord`. Existing on-disk session records persisted with `"permissions": null` will fail to deserialize. Acceptable per project policy (no migration); local dev users may need to clear `~/.fabro/storage/sessions/` once. ## Test plan - [x] `cargo build --workspace` - [x] `cargo nextest run -p fabro-api` — 125/125 (includes new `permission_level_round_trip` parity tests) - [x] `cargo nextest run -p fabro-server` — 554/554 (includes new 422 tests for missing + invalid permissions) - [x] `cargo nextest run -p fabro-cli` — 892/892 - [x] `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - [x] `cargo +nightly-2026-04-14 fmt --check --all` - [x] `bun run generate` on `fabro-api-client` — emits typed `PermissionLevel` union and required field on `CreateSessionRequest` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 17:15:20 -04:00
Bryan Helmkamp	73ebb7d28b	feat(mcp): support run parent relationships (#295) ... ## Summary - Add parent metadata (`parent_id`, `children_count`) to Fabro MCP run summaries, search summaries, and created-run results. - Allow MCP clients to create child runs, search direct children, and link or unlink an existing run's parent through the existing run tools. - Update MCP docs and tool descriptions for the parent-aware create/search/interact behavior. ## Test Plan - [x] `cargo +nightly-2026-04-14 fmt --check --all` - [x] `cargo nextest run -p fabro-mcp-server` - [x] `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 12:26:18 -04:00
Bryan Helmkamp	8d1b5f6c23	feat(mcp): add interrupt action to fabro_run_interact (#296) ... ## Summary - Adds a standalone `interrupt` action to the `fabro_run_interact` MCP tool, closing a parity gap with the HTTP API (`POST /api/v1/runs/{id}/interrupt`). - Lets MCP callers cancel an API-mode agent's current LLM round and park it in `SteeringHub`'s `waiting_for_steer` state without committing to follow-up text in the same call. - Dispatches through the existing `Client::interrupt_run`; no client or server-side changes. ## Why not just use `message` with `interrupt: true`? Combined interrupt+steer remains the right choice when you want to redirect the agent. Bare interrupt is for "pause the agent while I decide what to say next." The variant's doc comment steers callers toward `message` or `cancel` as the usual options, since a bare interrupt with no follow-up leaves the run idle indefinitely. ## Test plan - [x] `cargo nextest run -p fabro-mcp-server` — 13/13 pass, including new `interrupt_action_requires_only_run_id` unit test - [x] `cargo nextest run -p fabro-cli -E 'test(/mcp_/)'` — 27/27 pass, including extended `mcp_interact_actions_resolve_selector_and_call_expected_endpoints` E2E (mocks `POST /runs/{id}/interrupt`, asserts the tool hits it) - [x] `cargo +nightly-2026-04-14 clippy -p fabro-mcp-server -p fabro-cli --all-targets -- -D warnings` — clean - [x] `cargo +nightly-2026-04-14 fmt --check` on touched crates — clean 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 12:12:32 -04:00
Bryan Helmkamp	2ba04be181	feat(template): add source-aware diagnostics (#292) ... ## Summary Template failures from `fabro run` and structural warnings from `fabro validate` now preserve source provenance through rendering, workflow transforms, API serialization, and CLI display. Diagnostics can point at the actual workflow, import, or prompt file with node/attribute context instead of surfacing MiniJinja's generic `<string>` source. ## What Changed - Added named MiniJinja render APIs plus miette-aware `TemplateError` metadata for source names, source text, spans, and labels. - Reworked workflow template expansion so inline attributes, imported workflows, and `@prompt` files render with file and owner context. - Split strict run behavior from structural validate behavior: run-start still hard-fails on missing inputs, while validate emits source-aware warnings and continues linting. - Extended validation diagnostics through Rust structs, OpenAPI, server DTO mapping, and CLI rendering with optional source path, line, column, span, and related metadata. - Added regression coverage across template rendering, workflow transforms, CLI output, and the server validate endpoint. ## Verification - `cargo nextest run -p fabro-template` - `ulimit -n 4096 && cargo nextest run -p fabro-workflow --no-fail-fast` - `cargo nextest run -p fabro-cli bare_fabro_with_unbound_inputs_validates_structurally_with_warning run_rejects_unbound_template_inputs_before_creating_remote_run` - `cargo nextest run -p fabro-server validate_endpoint_returns_template_source_coordinates` - `cargo build -p fabro-api` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Aleksi Asikainen <1086393+salieri@users.noreply.github.com>	2026-05-16 18:47:37 -04:00
Bryan Helmkamp	2b53917759	fix(validate): treat undefined template vars in @file prompts as warnings (#290) ... ## Summary `fabro validate` had inconsistent behavior for undefined template variables depending on whether the prompt was inline or loaded via an `@file` reference. Inline `{{ inputs.foo }}` produced a warning and validation passed; the same expression inside a `@file`-imported prompt produced a hard validation error. Fixes #286. ## Root cause Two template-rendering passes with different strictness, applied to disjoint inputs: 1. **DOT-source pass** (`lib/crates/fabro-workflow/src/operations/create.rs`) honored `RenderMode::Structural` for `fabro validate` — undefined variables downgraded to a `Severity::Warning` diagnostic, then lenient render finished the job. 2. **Per-attribute pass** (`lib/crates/fabro-workflow/src/transforms/variable_expansion.rs`) inside `TemplateTransform` was always strict and had no `RenderMode` awareness. Because `FileInliningTransform` runs *before* `TemplateTransform`, expressions inside `@file` content only ever encountered the strict pass. ## Fix - Plumb `RenderMode` through `TransformOptions` into `TemplateTransform`. - In `RenderMode::Structural`, the transform catches `TemplateError::UndefinedVariable` per attribute, emits a warning diagnostic, and falls back to `render_lenient`. - Diagnostics flow through a new `Transformed.diagnostics` field into `Validated` alongside lint output. - Diagnostics now include `node_id` when the undefined variable was found inside a node attribute, which is more useful than the previous "at line 1" location. - `RenderMode` and the shared `template_undefined_variable_diagnostic` helper moved to `pipeline/types.rs` so the transform layer can reach them without a circular dep. Strict mode (`fabro run`, preflight) is unchanged — undefined inputs still hard-fail before a run is created. ## Behavior Illustrative output shapes (variable names and line numbers depend on the fixture): Inline prompt (unchanged): ``` warning: undefined template variable `inputs.<name>` at line <n> (template_undefined_variable) Validation: OK ``` `@file`-imported prompt (previously a hard error, now matches inline — node-attributed instead of line-attributed): ``` warning [node: <id>]: undefined template variable `inputs.<name>` in node `<id>` (template_undefined_variable) Validation: OK ``` ## Test plan - [x] `cargo nextest run --workspace` — 5773/5773 passing - [x] `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` clean - [x] `cargo +nightly-2026-04-14 fmt --check --all` clean - [x] New regression test `bare_fabro_with_unbound_inputs_in_imported_prompt_validates_structurally_with_warning` in `lib/crates/fabro-cli/tests/it/cmd/validate.rs` against new fixture `test/templated_unbound_imported/` - [x] Existing `bare_fabro_with_unbound_inputs_validates_structurally_with_warning` and `strict_render_hard_fails_on_unbound_inputs` still pass — verifies inline structural and run-start strict behavior are both preserved - [x] Manual reproduction of the exact inputs from the issue now succeeds with a warning 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Aleksi Asikainen <1086393+salieri@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 17:31:22 -04:00
Bryan Helmkamp	56c7f627c4	feat(session): add server-backed agent sessions (#278) ... ## Summary Adds the first server-backed Fabro agent session slice: persistent session records, durable turn/event storage, HTTP session APIs, SSE turn streaming, generated clients, and a new `fabro session -p <prompt>` CLI path. ## What Changed - Adds shared session IDs, records, statuses, event envelopes, and message DTOs in `fabro-types`, with OpenAPI replacements in `fabro-api`. - Renames the agent runtime transcript item from `Turn` to `Message` and adds conversion between runtime history and persisted `SessionMessage` records. - Introduces a file-backed `SessionStore` for session metadata, turns, full transcripts, and append-only events under local storage. - Wires server session routes for create/list/read/update/delete, turn submission, event replay, interrupt requests, and session-scoped tools. - Implements streamed turn execution with durable events persisted before SSE broadcast, active-turn conflict handling, local same-machine `working_dir` validation, and noninteractive permission denials. - Adds `fabro-client` helpers and the `fabro session -p` command, plus regenerated TypeScript API client files. ## Notes V1 intentionally keeps session execution local to same-machine server targets. Remote clone-backed session sandboxes, interactive REPL/TUI behavior, warm session pooling, and real tool discovery for `/sessions/{id}/tools` remain follow-up work. ## Verification - `cargo build --workspace` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo test -p fabro-store session_store_contract_tests --lib` - `cargo test -p fabro-agent history::tests::session_message_roundtrip_preserves_runtime_history --lib` - `cargo test -p fabro-server 'session_' --lib` - `cargo test -p fabro-server --features test-support --test it openapi_conformance -- --nocapture` - `cargo test -p fabro-cli --test it cmd::session:: -- --nocapture` - `cd lib/packages/fabro-api-client && bun run typecheck` - `git diff --check` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-16 17:25:05 -04:00
Bryan Helmkamp	4f5e3b78f8	refactor: remove compatibility shims (#281) ... ## Summary Simplifies the greenfield PR/run schema surface by collapsing alias-only type shims and removing legacy compatibility paths that kept old wire shapes and workflow names alive. ## Changes - Use canonical `Run`, `PullRequestLink`, `PullRequestResponse`, `BoardColumn`, `WorkflowSettings`, SWR `Key`, and `SteerRunRequest` names directly across Rust and web code. - Remove legacy PR/event deserialization compatibility for old PR records and command output fields, with tests updated to reject stale wire shapes. - Drop obsolete workflow aliases for `agent_loop`, `one_shot`, `codergen_mode`, and `stack.child_dotfile`, then update docs and tests to the current names. ## Verification - `git diff --check` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo nextest run -p fabro-types -p fabro-api -p fabro-client -p fabro-store -p fabro-server -p fabro-workflow -p fabro-cli` - `cd apps/fabro-web && bun run typecheck` - `cd apps/fabro-web && bun test` --- [](https://github.com/EveryInc/compound-engineering-plugin) Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 15:29:25 -04:00
Bryan Helmkamp	0f1cf4da5c	feat(cli): wire run parent commands (#288) ... ## Summary Add CLI support for run parent relationships now that the server API can store them. This lets users create child runs, filter children, inspect parent metadata, and link or unlink parents without dropping to raw API calls. ## What Changed - Added top-level `fabro parent link` and `fabro parent unlink` commands with selector resolution, text output, and JSON summaries. - Added `--parent` to `fabro run`, `fabro create`, and `fabro ps`; create/run send `parent_id` in manifests and `ps` uses server-side parent filtering. - Surfaced `parent_id` in `ps --json` and `inspect`, with a conditional `PARENT` column for unfiltered tables. - Extended `fabro-client` parent-link APIs and `list_store_runs(parent_id)`. ## Test Plan - `cargo nextest run -p fabro-cli` - `cargo nextest run -p fabro-client` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy -p fabro-cli -p fabro-client --all-targets -- -D warnings` - `cargo insta pending-snapshots` - `git diff --check` --- [](https://github.com/EveryInc/compound-engineering-plugin) Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-16 15:15:28 -04:00
Bryan Helmkamp	66519ee12a	feat(errors): add structured failure diagnostics (#277) ... ## Summary - Make `FailureDetail` the canonical rich diagnostic shape for stage and terminal failures, with terminal `RunFailure` carrying `{ reason, detail }`. - Preserve cause chains and move process stdout/stderr diagnostics into sanitized `exec_output_tail` instead of embedding them in messages or causes. - Update ACP error plumbing, CLI/server/store rendering, OpenAPI, and the generated TypeScript API client for the nested failure contract. Closes #273 ## Test Plan - `cargo nextest run -p fabro-types -p fabro-core -p fabro-acp -p fabro-api -p fabro-store -p fabro-server -p fabro-workflow -p fabro-cli --no-fail-fast -E 'not test(/returns_svg/)' --status-level fail --final-status-level fail` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `bun run typecheck` in `lib/packages/fabro-api-client` - `bun run typecheck` in `apps/fabro-web`	2026-05-16 13:25:07 -04:00
Bryan Helmkamp	87950295bd	refactor(llm): split provider identity from adapters (#280) ... ## Summary This PR separates provider identity from adapter behavior across the LLM stack. Provider IDs now represent catalog rows and provider metadata, while adapter/profile routing owns protocol behavior for Anthropic, OpenAI, Gemini, and OpenAI-compatible providers. ## Changes - Replace the shared `fabro_model::Provider` enum with open-ended `ProviderId` catalog identity and typed `AdapterKind` metadata. - Route auth, CLI, ACP, workflow, memory selection, profile construction, and LLM client registration through catalog provider rows instead of provider-ID fallbacks. - Move API-key URL/header/env metadata into provider catalog/auth flows and require configured provider rows for credential-backed clients. - Simplify billing to `algorithm`-tagged OpenAI, Anthropic, and Gemini shapes; OpenAI-compatible adapters bill through the OpenAI algorithm. - Remove greenfield compatibility paths for old provider aliases, legacy provider-tagged billing JSON, and the `openai_compatible` pseudo-provider env fallback. - Update fixtures and tests to exercise catalog-driven Kimi/Zai/Minimax/Inception/custom OpenAI-compatible routing. ## Validation - `cargo test --no-run -p fabro-model -p fabro-auth -p fabro-agent -p fabro-workflow -p fabro-server -p fabro-llm -p fabro-api -p fabro-cli -p fabro-store -p fabro-static` - `cargo nextest run -p fabro-model -p fabro-auth -p fabro-agent -p fabro-workflow -p fabro-server --no-fail-fast` - `cargo nextest run -p fabro-llm -p fabro-api -p fabro-cli -p fabro-store -p fabro-static --no-fail-fast` - `cargo +nightly-2026-04-14 fmt --check --all` - `git diff --check` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-16 13:13:41 -04:00
Bryan Helmkamp	d09e6cde33	feat(pr): support GitHub pull request associations (#270) ... ## Summary Adds event-sourced pull request association management for runs while preserving Fabro-created PR creation. A run can now store a current GitHub PR association, replace it by linking another GitHub PR URL, and remove it through an unlink event. ## What Changed - Added `pull_request.linked` and `pull_request.unlinked` events, projection replay support, and optional PR metadata fields in shared pull request records. - Added API, server, and client support for `PUT /runs/{id}/pull_request` and `DELETE /runs/{id}/pull_request`; linking accepts GitHub PR URLs, infers owner/repo/number, and captures live GitHub title and branch metadata when available. - Added `fabro pr link` and `fabro pr unlink`, updated `fabro pr view`, and kept create/merge/close behavior guarded to GitHub PRs with usable coordinates. - Updated web UI rendering and internal event docs so stored PR links display cleanly when live GitHub details are unavailable. ## Testing - `cargo +nightly-2026-04-14 fmt --check --all` - `git diff --check` - `cargo build -p fabro-api` - `cargo nextest run -p fabro-types -p fabro-store -p fabro-server -p fabro-cli` - `bun run typecheck` in `lib/packages/fabro-api-client` - `bun run typecheck` in `apps/fabro-web` - `bun test` in `apps/fabro-web` Refs https://github.com/fabro-sh/fabro/issues/235 --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Haroldo Olivieri <6575718+haroldolivieri@users.noreply.github.com>	2026-05-16 12:47:27 -04:00
David Bock	b0847180b6	Fix custom provider resolution in exec and model list (#276) ... ## Summary - allow `fabro exec` to use configured custom provider IDs from the resolved LLM catalog - route direct exec sessions through the same catalog-aware provider/profile resolution used by workflow runs - stop `fabro-client::list_models` from rejecting non-built-in provider filters client-side - update CLI snapshots and add regression tests for custom-provider exec and model listing ## Repro With a configured provider like: ```toml [llm.providers.bedrock] adapter = "openai_compatible" base_url = "https://.../v1" [cli.exec.model] provider = "bedrock" name = "bedrock-claude-sonnet-4-6" ``` these paths diverged: - `fabro run ... --model bedrock-claude-sonnet-4-6` worked - `fabro model list` showed `bedrock-*` models - `fabro exec "..."` failed with `unknown provider: bedrock` - `fabro model test --provider bedrock` failed with the same client-side error ## Root cause There were two separate built-in-only assumptions: 1. `fabro-agent` direct CLI paths parsed provider strings into the built-in `Provider` enum and built a default catalog, so configured provider IDs from `settings.toml` were invisible. 2. `fabro-client::list_models()` parsed the optional provider filter into the same built-in enum before calling the server, so custom provider filters never reached the API. ## Validation - `cargo check -p fabro-cli -p fabro-agent -p fabro-client` - `cargo test -p fabro-agent resolve_provider_accepts_custom_catalog_provider -- --nocapture` - `cargo test -p fabro-client list_models_allows_custom_provider_filters -- --nocapture` - `cargo test -p fabro-cli exec_accepts_configured_custom_provider_from_settings -- --nocapture` - `cargo test -p fabro-cli list_invalid_provider_errors -- --nocapture` - `cargo test -p fabro-cli help -- --nocapture` --------- Co-authored-by: Bryan Helmkamp <bryan@brynary.com>	2026-05-16 10:49:14 -04:00
Bryan Helmkamp	9768651b52	feat(model): add opt-in Ollama catalog provider (#268) ... ## Summary Adds Ollama as a disabled-by-default built-in catalog provider backed entirely by provider TOML. Enabling `[llm.providers.ollama] enabled = true` exposes the bundled `qwen3-coder` sample model through the existing OpenAI-compatible adapter, while other local Ollama models still require explicit model blocks until fabro-sh/fabro#267 adds discovery. The docs now show the opt-in setting and note that local users can set `OLLAMA_API_KEY=ollama` for Ollama's OpenAI-compatible endpoint. ## Verification - `cargo nextest run -p fabro-model` - `cargo nextest run -p fabro-cli cmd::model` - `cargo +nightly-2026-04-14 fmt --check --all` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: roALAB1 <233429779+roALAB1@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 08:18:21 -04:00
Bryan Helmkamp	32f100cbe7	feat(install): make LLM setup optional in web installer and CLI (#265) ... ## Summary Makes LLM setup explicitly skippable in both the web installer and `fabro install`, without making omission accidental. A skipped LLM step lets install complete with zero LLM credentials; later LLM-dependent workflows keep using the existing provider-not-configured behavior. `fabro doctor` is intentionally unchanged. Plan: `docs/superpowers/plans/2026-05-14-optional-llm-install.md` ## Key changes **Server + API** - `PUT /install/llm` now accepts `{"providers":[]}` as "LLM step completed, skipped" — the empty-list rejection is removed; per-provider validation for non-empty lists is retained. - OpenAPI: dropped `minItems: 1` from `InstallLlmProvidersInput.providers`, updated schema descriptions so empty = skipped and `llm: null` = incomplete. TypeScript client regenerated. - `/install/finish` still requires the LLM step to be present, but tolerates zero credentials — it writes settings, runtime auth secrets, and GitHub secrets normally and writes no LLM vault entries. **Web installer** - New "Skip LLM setup" secondary action on the LLM step (via a `secondaryAction` prop on `StepPanel`) that records an empty provider list and advances to GitHub. - Review screen shows `LLM providers: Skipped` (step completed, empty) vs `Not configured` (step never completed), via a new `describeLlmSummary` helper. - Continue with no API keys still shows the existing validation error — skipping is only reachable through the explicit skip action. **CLI** - Interactive `fabro install` asks "Configure LLM providers now?" (default yes) before provider selection; declining returns an empty selection and continues to GitHub. - Hidden non-interactive `--skip-llm` flag, mutually exclusive with `--llm-provider` / `--llm-api-key-stdin` / `--llm-api-key-env` via clap `conflicts_with_all`. Missing LLM flags are still validation errors unless `--skip-llm` is present. Non-interactive usage text updated with a skip example. ## Code review Ran a 12-reviewer `ce:review` pass (correctness, testing, maintainability, project-standards, agent-native, learnings, security, api-contract, reliability, adversarial, cli-readiness, kieran-typescript). No P0/P1 findings; agent-native parity PASS. Applied fixes in `40a29c591`: - Re-entrancy guard on `runStepSubmit` so a fast double-click on "Skip LLM setup" can't fire two requests. - `validate()` only suggests `--skip-llm` in the missing-provider error when no credential flag is set (it conflicts with those flags). - Added tests: all three `--skip-llm` conflict arms, the review screen's "Not configured" branch, and the skip-button failure path. One advisory finding left as report-only: an empty `PUT /install/llm` overwrites previously-saved credentials if a user navigates Back and clicks Skip — judged acceptable since the button is explicitly labeled and clicking it is deliberate. ## Testing - `cargo nextest run -p fabro-server -p fabro-cli -p fabro-install` — 1521 passed - `cargo build -p fabro-api`, `cargo fmt --check`, `cargo clippy` (changed crates) — clean - `bun test` (install-app) — 14 passed; `bun run typecheck` — clean - New coverage: server accepts empty providers + session shows `llm` complete with `providers:[]`; finish with skipped LLM persists no LLM vault credentials but keeps GitHub secrets; web skip button PUTs `providers:[]` and navigates to GitHub; review renders Skipped / Not configured; CLI `--skip-llm` requires `--non-interactive`, conflicts with all credential flags, `validate()` succeeds with `--skip-llm`, usage text documents `--skip-llm`. Not added (out of plan scope): an automated test for the interactive `InstallInputSource` skip branch — `InteractiveInstallInputSource` is TTY-coupled and has no existing tests; the non-interactive `--skip-llm` path is fully covered. ## Post-Deploy Monitoring & Validation This change is install-time only; there is no continuous runtime impact. Validate during the next install/release smoke: - **Web installer:** run a fresh browser install, click "Skip LLM setup" on the LLM step, confirm it advances to GitHub and the review screen reads `LLM providers: Skipped`. Finish the install and confirm the server restarts into normal mode with no LLM credentials in the vault (`secrets.json` has no credential entries) and GitHub/server/object-store/sandbox settings written normally. - **CLI:** run `fabro install --non-interactive --skip-llm --github-strategy token --github-username <user>` and confirm it completes; run interactive `fabro install` and confirm declining "Configure LLM providers now?" continues to GitHub. - **Healthy signals:** install completes (web `/install/finish` → 202; CLI exits 0), server boots in normal mode, `fabro doctor` runs and reports no LLM providers configured (expected, unchanged behavior). - **Failure signals / rollback trigger:** install fails to finish, server fails to boot after a skipped install, or `/install/finish` rejects a completed-but-empty LLM step. Rollback = revert this PR; install behavior returns to requiring at least one LLM provider. - **Validation window/owner:** next install smoke / release verification, owned by whoever runs the release. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-14 22:34:39 -04:00
Bryan Helmkamp	78941a2b84	test(model): prepare catalog-only providers (#264) ... ## Summary Prepares the model catalog tests for catalog-only built-in providers so a future provider can be added with just its catalog TOML. ## Changes - Replaces the closed-enum round-trip guardrail with a catalog metadata guardrail, allowing built-in TOML providers that do not have `Provider` enum variants. - Makes the all-model `fabro model` CLI tests assert stable table structure instead of snapshotting every built-in catalog row. - Renames synthetic custom-provider and missing-provider fixtures away from provider names that can become real catalog entries. ## Verification - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo nextest run -p fabro-model -p fabro-auth -p fabro-llm -p fabro-server -p fabro-workflow -p fabro-config` - `cargo nextest run -p fabro-cli cmd::model` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 (unknown context, medium reasoning) via [Codex](https://openai.com/codex) --------- Co-authored-by: Jesse <606+jesseproudman@users.noreply.github.com>	2026-05-14 21:51:18 -04:00
Bryan Helmkamp	c0fe29390a	feat(sandbox): prepare clone layout for multi-repo runs (#250) ... ## Summary - Clone primary GitHub repos into provider-owned `/repos/{owner}/{repo}` paths for Docker and Daytona sandboxes. - Keep user/agent execution rooted at the workspace symlink, e.g. `/workspace/{repo}` or `/home/daytona/workspace/{repo}`. - Persist optional runtime layout metadata (`workspace_root`, `repos_root`, `primary_repo_path`, `primary_repo_link`) through events, projections, OpenAPI, Rust API tests, and the TS client. - Preserve empty workspace behavior and reconnect from stored `working_directory` for existing run records. ## Verification - `cargo nextest run -p fabro-sandbox --features docker,daytona` - `cargo nextest run -p fabro-workflow` - `cargo nextest run -p fabro-server` - `cargo build -p fabro-api` - `cargo nextest run -p fabro-api run_sandbox_json_matches_openapi_shape sandbox_details_json_matches_openapi_shape` - `cd lib/packages/fabro-api-client && bun run typecheck` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `git diff --check` ## Notes - Added ignored live smoke tests for Docker and Daytona layout validation; they require real provider credentials/runtime.	2026-05-14 09:38:20 -04:00
Bryan Helmkamp	1cfe9419f5	refactor(llm): simplify catalog cleanup paths (#261) ... ## Summary This is a cleanup pass over the configurable LLM provider/catalog work from issue #210. It addresses reuse, quality, and efficiency findings from the phase 0-9 review without changing the public provider settings contract. Notable changes: - skip LLM client initialization during run preflight when the workflow has no LLM nodes - make preflight provider checks use alias-aware `Client::has_provider` - resolve `run.model.fallbacks` through the catalog instead of the old empty-key bridge - paginate `/models` before cloning returned rows - share label parsing, provider default-adapter lookup, enum expected-value formatting, and billing token formatting helpers - use catalog provider display names for OpenAI-compatible agent profiles - align process-env configured-provider discovery with `EnvCredentialSource` ## Verification - `cargo check -p fabro-config -p fabro-model -p fabro-auth -p fabro-agent -p fabro-workflow -p fabro-server -p fabro-cli` - `cargo nextest run -p fabro-config parse_labels_keeps_key_value_pairs` - `cargo nextest run -p fabro-workflow resolve_fallback_chain_resolves` - `cargo nextest run -p fabro-auth configured_providers` - `cargo nextest run -p fabro-server list_models` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy -p fabro-model -p fabro-auth -p fabro-workflow -p fabro-server -p fabro-agent -p fabro-config -p fabro-cli --all-targets -- -D warnings` - `cd apps/fabro-web && bun test app/routes/run-billing.test.tsx` - `cd apps/fabro-web && bun run typecheck` - `git diff --check` --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-14 09:35:42 -04:00
Bryan Helmkamp	1b6189ee32	docs(llm): finish configurable provider cleanup (#260) ... ## Summary Finish phase 9 of the configurable LLM provider/model work by aligning public docs, release notes, and guardrails with the implementation already landed in phases 0-8. - documents settings-driven providers/models, OpenAI-compatible gateway examples, typed `extra_headers`, model `api_id`, controls, and per-speed costs - adds the 2026-05-13 changelog entry and provider string migration note - updates the internal phase plan ledger to reflect current implementation status - adds a workspace policy test blocking direct production `Catalog::builtin()` usage outside catalog owner/test code - clarifies `Provider` as a built-in compatibility enum while open-ended identity is `ProviderId` ## Verification - `cargo nextest run -p fabro-dev --features dev --test it policy` - `cargo dev docs check` - `cargo nextest run -p fabro-model -p fabro-config -p fabro-auth -p fabro-llm` - `cargo build --workspace` - `cargo nextest run --workspace` (5717 passed, 182 skipped, nextest reported 1 leaky test) - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `git diff --check`	2026-05-13 17:17:54 -04:00
Bryan Helmkamp	a81eb09e78	feat(llm): add catalog controls and speed billing (#249) ... ## Summary This PR advances the catalog-driven LLM work from fabro-sh/fabro#210 by making the resolved model catalog the source of truth for provider registration, request control validation, and billing identity. Runs now preserve canonical provider/model/speed identity through pricing and API responses instead of collapsing billing around provider API aliases or model IDs alone. ## What Changed - Register LLM provider adapters from the resolved catalog, including custom OpenAI-compatible providers and their credential resolution paths. - Validate effective model request controls, including run-level defaults and node overrides, before dispatching LLM requests. - Add catalog-aware billing lookup that prices canonical `ModelRef` values, uses base model costs for standard speed, applies per-speed cost overrides, and returns an unknown estimate instead of silently billing zero for unsupported combinations. - Move Anthropic Opus fast-mode pricing into the built-in catalog for `claude-opus-4-6` and `claude-opus-4-7`. - Thread the injected catalog and effective speed controls through workflow billing, including API-mode and CLI-mode handlers. - Update billing APIs, server aggregation, generated clients, and the web billing view to expose provider/model/speed billing identity and keep standard and fast usage in separate rows. ## Notes for Review Billing lookup intentionally uses canonical catalog model IDs. Provider `api_id` substitution remains limited to provider request construction, so aliases can be used on the wire without changing billing identity. Event conversion paths that do not have catalog access now preserve token counts with a null dollar estimate rather than falling back to the bootstrap catalog. ## Verification - `cargo build -p fabro-api` - `cd lib/packages/fabro-api-client && bun run generate` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `ulimit -n 4096 && cargo nextest run -p fabro-model -p fabro-workflow -p fabro-server -p fabro-api -p fabro-cli --no-fail-fast` - `ulimit -n 4096 && cargo nextest run --workspace --no-fail-fast` - `cd apps/fabro-web && bun run typecheck` - `cd apps/fabro-web && bun test` - `git diff --check` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-13 14:12:16 -04:00
Bryan Helmkamp	6297b200f7	refactor(run): add rich failure contract (#256) ... ## Summary Terminal run failures now use a first-class `RunFailure` contract so downstream consumers receive structured diagnostics instead of flat `error` / `causes` / `reason` fields. The wire shape keeps concise public messages, source-chain causes, classification, optional actor/signature data, and redacted exec output tail in one nested value. Refs fabro-sh/fabro#198 ## What Changed - Added `fabro_types::RunFailure` and changed `run.failed` to emit `properties.failure` with `final_git_commit_sha` for failed-run commit state. - Replaced `Conclusion.failure_reason` with `Conclusion.failure` while leaving stage-level `StageCompletion.failure_reason` untouched. - Updated workflow internals to preserve owned error source chains until terminal event projection, then convert them into `RunFailure.causes`. - Updated store, server, CLI, OpenAPI, and generated TypeScript client consumers to use the nested failure object. - Added serialization, OpenAPI replacement, projection, and lifecycle coverage for the new contract. ## Validation - `cargo nextest run -p fabro-api -p fabro-types -p fabro-workflow -p fabro-store -p fabro-server -p fabro-cli` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo +nightly-2026-04-14 fmt --check --all` - `cd apps/fabro-web && bun run typecheck` - `cd apps/fabro-web && bun test` - `git diff --check` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-13 12:32:28 -04:00
Bryan Helmkamp	34d83db801	feat(model): support open provider catalog data (#245) ... ## Summary This PR moves Fabro’s provider/model catalog toward settings-driven provider identity by replacing the closed provider schema at the API/auth/model boundary with `ProviderId`, then loading built-in provider and model metadata from embedded per-provider TOML files. The immediate result is that built-ins now use the same settings-shaped catalog data that custom providers will use later, while request-serving paths still keep the existing bootstrap/default catalog behavior until the resolved-catalog plumbing lands. ## Changes - Replaces API-facing provider enum usage with string-backed `ProviderId`, including OpenAPI/progenitor replacements and regenerated TypeScript client models. - Routes model, auth, billing, CLI, server, and workflow call sites through provider IDs where they cross product identity boundaries. - Builds `Catalog` from settings-shaped provider/model data with validation for adapter keys, OpenAI-compatible `base_url`, duplicate aliases, provider defaults, disabled entries, model controls, and per-speed cost rows. - Replaces `catalog.json` with embedded provider TOML files under `lib/crates/fabro-model/src/catalog/providers/`. - Adds an explicit `fabro_model::bootstrap_catalog` hatch for setup/install paths and extends the dev policy test to keep bootstrap access contained. - Preserves public training and knowledge-cutoff labels in LLM model settings while still accepting bare TOML dates. ## Verification - `cargo nextest run -p fabro-model -p fabro-config -p fabro-api` — 416 passed - `cargo nextest run -p fabro-dev --features dev bootstrap_catalog_references_stay_in_allowlist` — 1 passed - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo build --workspace` - `git diff --check` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-12 15:42:49 -04:00
Bryan Helmkamp	087c9233f3	fix(validate): pick up sibling workflow.toml inputs for bare .fabro path (#242) ... ## Summary - `fabro validate path/to/workflow.fabro` now auto-discovers a sibling `workflow.toml` and loads its `[run.inputs]`, so templated graphs validate the same way they do when invoked by name or by toml path. - The discovery is opt-in to the user's specific graph: we only pick up the sibling toml if its `[workflow].graph` resolves back to the `.fabro` the user passed. Unrelated tomls in the same directory are ignored. ## Why `fabro validate` is the natural fast-feedback tool for CI/pre-commit hooks that iterate on changed `.fabro` files. Previously, a graph using `{{ inputs.* }}` would fail with a generic MiniJinja "undefined value" error when validated by path, even when a sibling `workflow.toml` defined those inputs. The other two invocation forms (by name, by toml) worked, which made the path form a usability cliff. Fixes #195. ## Test plan - [x] New integration test: `bare_fabro_picks_up_sibling_workflow_toml_inputs` validates `test/templated_inputs/workflow.fabro` (uses `{{ inputs.app_dir }}`) and expects `Validation: OK`. - [x] New unit tests in `fabro-config::project`: - `resolve_workflow_path_picks_up_sibling_workflow_toml` — happy path. - `resolve_workflow_path_ignores_sibling_toml_pointing_elsewhere` — guard: don't apply an unrelated sibling toml. - [x] `cargo nextest run --workspace` — 5585 tests pass. - [x] `cargo +nightly-2026-04-14 fmt --check --all`, `clippy --workspace --all-targets -- -D warnings` clean. - [x] Manual: `fabro validate /tmp/fabro-issue-195/workflow.fabro` (templated graph + sibling toml with `[run.inputs]`) prints `Validation: OK`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Nate Aune <118984+natea@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 12:05:21 -04:00
Bryan Helmkamp	a33d17c88d	feat(run): add managed branch controls (#243) ... ## Summary Adds run-level controls for clone behavior, managed run branch setup/pushes, and metadata branch writes/pushes so workflows can opt out of Fabro-managed Git behavior without relying on provider-specific `skip_clone` settings. This closes fabro-sh/fabro#240. ## What Changed - Introduced `[run.clone]`, `[run.run_branch]`, and `[run.meta_branch]` settings with defaults that preserve current behavior. - Removed user-facing `skip_clone` from Docker/Daytona config while mapping the new run-level clone setting into the internal sandbox runtime options. - Gated run branch setup/push, metadata branch writer creation/push, and PR branch output on the new settings. - Enforced invalid combinations: pull requests require an enabled pushed run branch, and disabling the run branch also disables metadata branch behavior. - Updated OpenAPI, the generated TypeScript API client, frontend fixture data, and docs for the new configuration shape. ## Testing - `cargo nextest run -p fabro-config -p fabro-types -p fabro-workflow -p fabro-server` - `cargo build -p fabro-api` - `cd lib/packages/fabro-api-client && bun run generate` - `cd lib/packages/fabro-api-client && bun run typecheck` - `cd apps/fabro-web && bun run typecheck` - `cd apps/fabro-web && bun test` - `cargo build --workspace` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo insta pending-snapshots` - `git diff --check` ## Post-Deploy Monitoring & Validation - Validation window: first 24 hours after release; owner: release owner/on-call engineer. - Log queries/search terms: `run_branch`, `meta_branch`, `clone.enabled`, `skip_clone`, `pull request requires an enabled pushed run branch`, `metadata branch`. - Healthy signals: runs without custom branch config continue creating and pushing run/meta branches; runs with `[run.clone] enabled = false` start provider sandboxes without cloning; runs with branch pushes disabled complete without Git push errors. - Failure signals: increased run startup failures for Docker/Daytona, unexpected PR creation conflicts, missing metadata for default-config runs, or validation errors for configurations that previously used default settings. - Mitigation trigger: if default-config runs stop producing expected branch/metadata artifacts or sandbox startup failures increase, roll back the release or temporarily restore previous defaults while investigating the run-level setting resolution path. --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) Co-authored-by: Haroldo Olivieri <6575718+haroldolivieri@users.noreply.github.com>	2026-05-12 12:00:30 -04:00
fabro-sh-0530[bot]	10de9fd16c	Add foundation for settings-driven LLM catalog (#207) ... ## Summary This lays the groundwork for settings-driven LLM providers and models without switching production routing yet. The new schemas and shared vocabulary let later catalog construction treat provider/model identity as data while keeping adapter behavior and control values Rust-owned. ## What changed - Added `[llm.providers]` and `[llm.models]` settings layers with sparse per-entry merging, whole-array replacement for credential/alias/control lists, TOML date support for `knowledge_cutoff`, and typed `credential:` / `env:` references that reject literal secrets. - Added `ProviderId`, `ModelId`, and a shared `ReasoningEffort` enum in `fabro-model`, plus adapter metadata for `anthropic`, `openai`, `gemini`, and `openai_compatible`. - Added a matching `fabro-llm` adapter factory registry with parity tests to keep metadata keys and factory keys in sync. - Added `[run.model.controls]` defaults through config resolution and runtime settings types. - Added a workspace policy test to prevent future `bootstrap_catalog` use outside install/test-support paths. ### Plan Summary - This is the foundation slice of the settings-driven catalog plan. - Production still uses the existing `Provider` enum and `Catalog::builtin()` call paths. - ProviderId routing, OpenAPI regeneration, auth resolver changes, resolved `Arc<Catalog>` injection, typed request speed, and per-speed billing are deferred follow-ups. ⚒️ Generated with [Fabro](https://fabro.sh) --------- Co-authored-by: Fabro <noreply@fabro.sh> Co-authored-by: fabro-bot <fabro-bot@fabro.sh> Co-authored-by: Bryan Helmkamp <bryan@brynary.com>	2026-05-12 10:01:57 -04:00