795 commits

Author	SHA1	Message	Date
Bryan Helmkamp	eb4891b1b0	refactor(agent): simplify reviewed changes ... Use raw sandbox reads for memory and skills, keep line-numbered reads focused on display, and share retry-delay handling across agent and LLM code. Trim task tool descriptions, bound multi-file read concurrency, restore Docker's text read path, and add the reviewed implementation plan docs.	2026-05-22 21:51:45 -04:00
fabro-sh-0530[bot]	a2e2cbc7ed	Add agent context observability events (memory, skills, MCP tools) (#356) ... ## Summary Adds three new durable run events — `agent.memory.loaded`, `agent.skills.discovered`, and `agent.skill.activated` — and enriches `agent.mcp.ready` with names-only tool summaries. Consumers can now reconstruct what memory, skills, and MCP tools were active for any agent run by reading the event stream, without needing to inspect session state. ### Plan Summary - **`fabro-types`**: New prop structs (`AgentMemoryLoadedProps`, `AgentSkillsDiscoveredProps`, `AgentSkillActivatedProps`, `AgentMcpToolSummary`) and three new `EventBody` variants with canonical dot-name serialization. `AgentMcpReadyProps.tools` uses `#[serde(default, skip_serializing_if = "Vec::is_empty")]` for backwards compatibility. - **`fabro-agent/memory.rs`**: `discover_memory` now returns `Vec<MemoryDocument>` carrying path, byte counts, and truncation flag alongside content. The content itself is never put in any event payload. - **`fabro-agent/types.rs`**: Adds `MemoryLoaded`, `SkillsDiscovered`, `SkillActivated`, and enriched `McpServerReady` internal variants. Removes `SkillExpanded` (replaced by `SkillActivated { source: Slash }`). New variants are **not** classified as streaming noise, so they persist. - **`fabro-agent/session.rs`**: Emits `MemoryLoaded` before skills init, `SkillsDiscovered` after skill discovery, and enriches `McpServerReady` with summaries from `McpConnectionManager::tool_summaries_for_server`. Slash expansion now emits `SkillActivated { source: Slash }` instead of `SkillExpanded`. - **`fabro-agent/skills.rs`**: `make_use_skill_tool` emits `SkillActivated { source: Tool }` on successful lookup only. - **`fabro-mcp/connection_manager.rs`**: New `tool_summaries_for_server` returns sorted `(qualified_name, original_name)` pairs without leaking descriptions or schemas. - **`fabro-workflow/event/convert.rs` + `names.rs`**: Converts all new agent events to their typed `fabro-types` props, including `visit` injection. Removes dead `SkillExpanded` arm. - **`docs/internal/events.md`**: Documents all new event shapes with full property tables; notes that `agent.skill.expanded` is replaced. ### Key design decisions - Both `MemoryLoaded` and `SkillsDiscovered` are emitted even when the result is empty. This lets consumers distinguish "no memory/skills found" from "event not yet reported." - Memory file **contents are never included** in any event payload — only `path`, `byte_count`, `loaded_bytes`, and `truncated`. - `agent.mcp.ready` `tools` field is omitted from JSON when empty (`skip_serializing_if`), preserving wire compatibility with existing stored events. - `SkillActivated` is persisted (not filtered as streaming noise), unlike the former internal-only `SkillExpanded`. ### Fabro Details <details> <summary>Ran 9 stages in 57m 15s for $27.15</summary> | Stage | Duration | Cost | Retries | |---|---|---|---| | start | 0s | – | 0 | | toolchain | 1s | – | 0 | | preflight_compile | 2m 17s | – | 0 | | preflight_lint | 2m 30s | – | 0 | | implement | 21m 18s | $16.27 | 0 | | simplify_opus | 15m 21s | $6.52 | 0 | | simplify_gpt | 10m 33s | $4.35 | 0 | | verify | 4m 24s | – | 0 | | fmt | 3s | – | 0 | | **Total** | **57m 15s** | **$27.15** | **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:06:00 -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	203ed5d029	docs: document agent pair and todo tools	2026-05-22 15:15:30 -04:00
Bryan Helmkamp	8811054f99	docs(changelog): refresh recent product changes	2026-05-22 15:15:30 -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]	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
Bryan Helmkamp	296fbddec9	feat(api): add ask fabro session endpoints (#342) ... ## Summary Adds the run-backed API surface needed for a real Ask Fabro sidebar: run readiness metadata, detailed session projections, session-scoped event listing/attach streaming, and turn control that exposes durable turn IDs and machine-readable failures. ## What Changed - Extended the OpenAPI contract and regenerated Rust/TypeScript clients for `Run.ask_fabro`, `SessionDetail`, `SessionTurn`, paginated run sessions, session event APIs, and optional client-supplied `turn_id` values. - Updated `fabro-types` and `fabro-store` so durable `run.session.*` events project active turn state, transcript messages, and the latest owning run event sequence. - Implemented server routing for session details, `/events`, `/attach`, turn conflict headers, typed turn failure codes, and cheap run readiness decoration across run responses. - Added browser helpers for POST turn streaming and session attach SSE parsing, plus an exported generated `sessionsApi`. ## Verification - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo build --workspace` - `cargo test -p fabro-types run_session_turn_failed_defaults_code_for_old_events` - `cargo test -p fabro-store run_sessions::tests` - `cargo test -p fabro-api` - `cargo test -p fabro-server --features test-support --test it api::sessions` - `cargo test -p fabro-server --features test-support --test it api::runs` - `cd apps/fabro-web && bun test app/lib/session-stream.test.ts` - `cd apps/fabro-web && bun run typecheck` --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 Codex (context unknown, medium reasoning) via [Codex](https://openai.com/codex/)	2026-05-21 21:26:15 -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	5095873ddd	feat(web): add detail popovers to the run header ... Hovering the run header items now reveals a popover with extra context: - Run status: failure reason and error message for failed runs; archived timestamp for archived runs (no popover otherwise) - Repository: full owner/repo name and the cloned branch - Workflow: node and edge counts plus run labels - PR: live GitHub details fetched lazily on hover — title, an open/draft/merged/closed badge, and the head -> base branch arrow Workflow node/edge counts are new: WorkflowRef now carries node_count/edge_count, computed in build_summary from the parsed graph that is already in hand there. Adds a HoverCard primitive alongside Tooltip (shared useHoverAnchor hook) for rich, viewport-aware popovers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-21 14:10: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	9201ef9fe6	feat(web): add Ask Fabro assistant page (#334) ... ## Summary Adds `/ask-fabro`, a prototype route that brings the right-docked "Ask Fabro" assistant into the real web app. It graduates the sidebar design from the `docs/superpowers/prototypes/2026-05-16-chats-new` prototype: a placeholder workspace page with an "Ask Fabro" trigger that toggles an animated 420px docked panel. The panel streams scripted, **fake** AI replies through assistant-ui — no real model calls — matching the behavior of the existing `/chats` prototype. ## What changed - **`routes/ask-fabro.tsx`** — the route. A placeholder "Runs" workspace (stat cards + recent-runs list) whose only job is to host the trigger button, plus the docked sidebar. Uses `handle = { hideHeader, fullHeight, wide }` and the edge-bleed wrapper copied from the shipping `chats-layout`. - **`components/chats/ask-fabro-sidebar.tsx`** — animated-width 420px assistant panel rendering assistant-ui's `<Thread>`. - **`components/chats/sidebar-composer.tsx`** — compact single-line composer pill for the narrow column. - **`app.css`** — the `.ask-fabro-sidebar` CSS block (narrow-column overrides, layered into `assistant-ui` to beat its unlayered defaults), ported verbatim from the prototype. - **`router.tsx`** — registers the route under the AppShell. The components and CSS are faithful, near-verbatim ports of the prototype, which was carefully constructed. The runtime is fully reused — `chats-runtime`, `chats-script`, `chats-types`, and `tool-fallback` already graduated with `/chats`, so this PR adds no new chat plumbing. ## Decisions - **Route-local state, not context.** The prototype used an app-level `AskFabroContext` so the sidebar could mount above the top nav. This route is self-contained, so a plain `useState` passed as props is simpler and equivalent. - **Sidebar sits below the top nav** (within the route), rather than spanning the full window like the prototype. Intentional — keeps the route self-contained. - **Not added to the nav.** Reachable directly at `/ask-fabro`; it is not `demoOnly`, so it renders regardless of demo mode. ## Verification - `bun run typecheck`, `bun test` (403 pass), and `bun run build` all clean. - Rendered side-by-side against the prototype's `/sample`: empty state and active thread (user bubble + streamed markdown assistant reply) match. --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with Claude Opus 4.7 (1M context, extended thinking) via [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 21:11:54 -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	40ed64c1c2	Add system resources settings page (#328) ... ## Summary Adds server-visible resource reporting and a compact Resources settings tab for CPU, memory, and the filesystem that contains Fabro storage. ## Changes - Adds `GET /api/v1/system/resources` backed by `sysinfo`, including CPU sampling, cgroup-aware memory reporting, storage filesystem matching, and Fabro-managed disk byte totals. - Extends the OpenAPI contract and regenerates the Rust and TypeScript API clients. - Adds a deterministic demo-mode resources route. - Adds `/settings/resources` with 5 second polling and panels for overview, CPU, memory, disk, and notes. - Adds server integration/unit coverage and web route/render coverage. ## Screenshot  ## Verification - `cargo build -p fabro-api` - `cd lib/packages/fabro-api-client && bun run generate` - `cargo nextest run -p fabro-server --features test-support --test it api::system` - `cargo test -p fabro-server resource_sampler::tests` - `cd apps/fabro-web && bun test` - `cd apps/fabro-web && bun run typecheck` - `cd apps/fabro-web && bun run build` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` --- [](https://github.com/compound-engineering) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 17:22:53 -04:00
Bryan Helmkamp	5eb874b55c	feat(sandbox): label Daytona sandboxes as managed (#326) ... ## Summary Fabro-created Daytona sandboxes now carry the same managed-resource labels Docker containers already use: `sh.fabro.managed=true` and `sh.fabro.run_id=<run-id>` when a run id is available. This moves the Docker label constants into a shared sandbox helper, keeps Docker behavior unchanged, and applies the helper when Daytona create params are built. User-provided Daytona labels are preserved, but Fabro's reserved keys are authoritative on collisions. Daytona snapshot behavior is unchanged because the snapshot API does not expose labels. ## Testing - `cargo test -p fabro-sandbox managed_labels --no-default-features --features docker,daytona` - `cargo test -p fabro-sandbox docker::tests::real_run_container_gets_name_and_labels --no-default-features --features docker` - `cargo test -p fabro-sandbox daytona::tests::base_params --no-default-features --features daytona` - `cargo test -p fabro-sandbox daytona_managed_labels_live_smoke --no-default-features --features daytona` - `cargo test -p fabro-sandbox --no-default-features --features docker,daytona` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo +nightly-2026-04-14 clippy -p fabro-sandbox --all-targets --no-default-features --features docker,daytona -- -D warnings` The live Daytona smoke test remains ignored; it compiles under the Daytona feature but was not run against live credentials. ## Post-Deploy Monitoring & Validation - Log queries/search terms: `Failed to create Daytona sandbox`, `Daytona`, `labels`, `sh.fabro.managed`, `sh.fabro.run_id`, and sandbox initialization errors for `provider=daytona`. - Metrics or dashboards: Daytona sandbox creation success/error rate, Fabro run initialization failures for Daytona runs, and Daytona resource inventory filtered by `sh.fabro.managed=true`. - Expected healthy signals: new Fabro-created Daytona sandboxes include `sh.fabro.managed=true`, run-owned sandboxes include the matching `sh.fabro.run_id`, user labels remain visible, and Daytona sandbox creation failure rates stay at baseline. - Failure signals and rollback trigger: any sustained increase in Daytona sandbox creation failures, API validation errors around labels, or missing managed labels on newly created sandboxes. Roll back this PR or hotfix the label merge to omit Daytona labels if Daytona rejects the keys in production. - Validation window and owner: release owner watches the first 24 hours after deploy, with an immediate manual Daytona dashboard/API spot-check after the first managed Daytona run. --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 (context unknown, reasoning enabled) via [Codex](https://openai.com/codex)	2026-05-20 17:22:12 -04:00
Jess Martin	5bfd115339	[codex] Add ACP steering support (#329) ... ## Summary - Adds a backend-neutral live control abstraction so steering, interrupt, and interrupt+steer no longer depend on API-only session handles. - Reworks ACP sessions into a live protocol loop that uses ACP `session/prompt` for follow-up steers and ACP `session/cancel` for interrupts without restarting the process. - Registers ACP sessions as steerable, removes the stale non-steerable server/UI/API path, preserves ACP projection metadata, and keeps unsupported backends out of the steerability gate. ## Validation - `LC_ALL=C cargo nextest run --workspace --no-fail-fast` (5,833 passed, 178 skipped) - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cargo +nightly-2026-04-14 fmt --check --all` - `git diff --check` - `cd apps/fabro-web && LC_ALL=C ASDF_NODEJS_VERSION=20.13.1 ASDF_BUN_VERSION=1.3.11 bun test` (396 passed) - `cd apps/fabro-web && LC_ALL=C ASDF_NODEJS_VERSION=20.13.1 ASDF_BUN_VERSION=1.3.11 bun run typecheck` - `cargo build -p fabro-api` - `cd lib/packages/fabro-api-client && LC_ALL=C ASDF_BUN_VERSION=1.3.11 bun run typecheck` --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: Bryan Helmkamp <bryan@brynary.com>	2026-05-20 17:21:56 -04:00
Bryan Helmkamp	d17599898e	feat(web): show creator avatar on run "Created by" cell (#319) ... ## Summary The run Overview tab's "Created by" cell rendered every user as a colored circle with the first letter of their login. Reviewers and run owners expected the same GitHub avatar shown on `/profile` and in the top-right nav. The cell only had `login` to work with — the `PrincipalUser` schema carried no avatar URL. This threads an optional `avatar_url` through `UserPrincipal` end-to-end: schema, server auth, and frontend. The avatar is captured at action time from the request's auth context and persisted with the run's `created_by` principal — a point-in-time snapshot, the same pattern as audit logs and chat apps. ## What changed - **`fabro-types`** — `UserPrincipal` gains `avatar_url: Option<String>` with `#[serde(default, skip_serializing_if)]`, plus a `Principal::user_with_avatar` constructor. The existing `Principal::user` constructor is unchanged (sets `None`), so test fixtures and CLI/replay call sites need no edits. - **OpenAPI** — `PrincipalUser` gains an optional nullable `avatar_url`; Rust (progenitor) and TypeScript clients regenerated. - **`fabro-server`** — `auth_context_from_session` (cookie auth) and `classify_user_token` (JWT auth) populate the principal's avatar from the session/JWT, treating an empty string as `None`. - **`fabro-web`** — the `run-summary-panel` "Created by" cell renders an `<img>` when `avatar_url` is present, falling back to the initial circle otherwise. ## Compatibility The field is optional with serde defaults, so old persisted runs and `RunEvent.actor` payloads deserialize unchanged — they show the initial-circle fallback. No migration or backfill. ## Known gap CLI-initiated runs (`fabro run ...`) still show the initial circle: the CLI auth flow hardcodes an empty `avatar_url` in the JWT subject (`cli_flow.rs:508`). Wiring the avatar through CLI login (`~/.fabro/auth.json`, JWT claims, refresh-token chain) is a deliberate follow-up. Web-initiated runs get the avatar today. ## Test plan - `cargo nextest run --workspace` — 5,832 tests pass, including new `principal.rs` and `principal_round_trip.rs` cases covering avatar serialization and legacy-JSON (no-field) deserialization. - `cd apps/fabro-web && bun test run-summary-panel` — 13 tests pass, including a new case asserting the `<img>` renders with the avatar src. - `bun run typecheck`, `cargo +nightly-2026-04-14 fmt --check --all`, and `clippy --workspace --all-targets -- -D warnings` all clean. - Manual: restart `fabro server`, create a run from the web UI, confirm the real avatar renders on the Overview tab; confirm an older run falls back to the initial circle. --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with Claude Opus 4.7 (1M context, extended thinking) via [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 09:11:57 -04:00
Bryan Helmkamp	fbe8b50a16	feat(server): add GET /api/v1/providers and /settings/models page (#321) ... ## Summary Operators had no UI surface to see which LLM providers their Fabro server has configured — provider state was only inferable indirectly via the per-model `configured` flag on `GET /api/v1/models`. This adds a dedicated **Models** settings tab backed by a new providers endpoint. - **`fabro_model::Provider`** — a public projection of the internal `CatalogProvider` that *structurally* excludes credential-bearing fields (`auth`, `extra_headers`, `billing_policy`, `agent_profile`). Reused by the generated API client via progenitor `with_replacement`, mirroring the existing `Model` pattern — no parallel API DTO. - **`GET /api/v1/providers`** — lists catalog providers with effective config and a `configured` status stamped per request from `ready_llm_provider_ids()`. Sorted by the catalog's existing `provider_order`. No write endpoints. - **`/settings/models` web page** — new route + nav entry (`CpuChipIcon`, between Integrations and Security) rendering each provider with model count, default model, configured status, and a "Get API key" link for unconfigured providers. ## Key decisions - Provider sort: reuse catalog `provider_order` (priority desc, id asc) — zero extra code. - `adapter` is hidden in the UI row (noisy for first-party providers); the OpenAPI `adapter` field is pinned to an enum matching the closed `AdapterKind` type. - `configured` reflects credential resolution **at the time of the response**, not a frozen startup snapshot — doc/spec wording corrected to match. ## Testing - `fabro-model`: `From<&CatalogProvider>` + serde `skip_serializing_if` unit tests. - `fabro-api`: `Provider` type-identity + JSON-parity tests, including the required/optional field split. - `fabro-server`: handler tests for configured vs unconfigured providers, exact `model_count`/`default_model` against catalog truth, and credential-omission (asserts internal field names *and* the injected credential value never reach the wire). - OpenAPI route conformance test covers `GET /api/v1/providers`. - `cargo build --workspace`, `fmt --check`, `clippy -D warnings` clean; 935 Rust tests pass; web `tsc` typecheck passes. - Reviewed via a 10-persona `ce:review` (autofix) — no P0/P1 in shipped code; 8 safe fixes applied. Not done: manual UI screenshots — the `apps/fabro-web` build is blocked in this environment by an unrelated missing `@assistant-ui/react` dependency. Run `bun install` in `apps/fabro-web` to verify `/settings/models` manually. ## Post-Deploy Monitoring & Validation - **What to watch:** request logs for `GET /api/v1/providers` — expect `200`s for authenticated users, `401` for unauthenticated. The handler resolves LLM credentials per request via `ready_llm_provider_ids()` (the same path the existing `list_models` handler already uses). - **Healthy signals:** `/settings/models` renders the provider list; `configured` matches each provider's actual credential state; no credential strings appear in any response body or log line. - **Failure signals / rollback trigger:** any provider object in the response containing `auth`, `extra_headers`, or a raw key/token value → roll back immediately (the projection type makes this structurally impossible, but treat any occurrence as P0). 5xx spikes on the new route. - **Validation window / owner:** first 24h after deploy, owned by the deploying engineer. Pre-existing note (not introduced here): credential resolution can refresh OAuth tokens and write the vault as a side effect of this read — shared with `list_models`; flagged for a future caching pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 09:05:00 -04:00
Bryan Helmkamp	c28a102af8	docs: sync public docs to recent changes ... Document Daytona Dockerfile path refs, static template includes, Slack review context, skipped LLM setup, and template validation behavior.	2026-05-18 14:42:54 -04:00
Bryan Helmkamp	7f81beb63c	docs(changelog): refresh recent product changes ... Add dated changelog entries for the recent user-facing changes and advance the changelog watermark.	2026-05-18 14:42:54 -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
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	ac32963538	feat(web): add Children tab to Run detail page (#294) ... ## Summary - Surfaces parent/child run relationships in the web UI as a new **Children** tab between Files Changed and Sandbox on `/runs/:id`. - Backend exposes a new `children_count` field on the `Run` summary, computed on read from the existing `RunProjectionCacheState.children_by_parent` index — accurate without an extra query. - Frontend reuses the compact-table `RunRow` from `/runs` (now exported) so the children list matches the existing list-view at a glance. - Tab always shows, with a zero state when there are no children. Refresh button (icon-only, matching the Files Changed pattern) re-fetches both the list and the parent detail so the count badge updates with the list. ## Screenshots Captured live from the running fabro server. **Populated — `Children · 2` tab active, two succeeded child rows:**  **Zero state — visiting a run that has no children:**  ## API verification ```sh # parent $ curl -s -H "Authorization: Bearer $TOKEN" \ http://127.0.0.1:32276/api/v1/runs/01KRTKP5DJJ4EV6T7QSB081Z1N \ | jq '{id, parent_id, children_count}' { "id": "01KRTKP5DJJ4EV6T7QSB081Z1N", "parent_id": null, "children_count": 2 } # child $ curl -s -H "Authorization: Bearer $TOKEN" \ http://127.0.0.1:32276/api/v1/runs/01KRTKP7VAS2J2AG73GQSAKF4G \ | jq '{id, parent_id, children_count}' { "id": "01KRTKP7VAS2J2AG73GQSAKF4G", "parent_id": "01KRTKP5DJJ4EV6T7QSB081Z1N", "children_count": 0 } # list-by-parent $ curl -s -H "Authorization: Bearer $TOKEN" \ "http://127.0.0.1:32276/api/v1/runs?parent_id=01KRTKP5DJJ4EV6T7QSB081Z1N" \ | jq '{count: (.data | length), has_more: .meta.has_more}' { "count": 2, "has_more": false } ``` ## What's in each commit | Commit | What | | --- | --- | | `2f5f4296` | `chore(api-client)`: regenerate TS client from current OpenAPI spec — catches up drift from #292's source-aware diagnostics and the session/turn shape updates that hadn't been re-run yet. Pure generator output. | | `ba16d2b3` | `feat(web)`: the actual Children tab feature. Backend `children_count` field + cache wiring, new `useChildRuns` SWR hook, exported `RunRow`/`RUNS_LIST_GRID_TEMPLATE` from `runs.tsx`, new `run-children.tsx` route, `Run.children_count` on the generated TS type. | | `de0c32c9` | `docs`: live UI screenshots for this PR. Safe to revert before merge if reviewers prefer a screenshot-free repo. | ## Reproducing the screenshots 1. `cargo build -p fabro-cli && ./target/debug/fabro server start` 2. `cd apps/fabro-web && bun run build` 3. ```sh PARENT=$(./target/debug/fabro run hello --dry-run --detach --sandbox local --json | jq -r .run_id) ./target/debug/fabro run hello --dry-run --detach --sandbox local --parent "$PARENT" ./target/debug/fabro run hello --dry-run --detach --sandbox local --parent "$PARENT" ``` 4. Open `http://127.0.0.1:<port>/runs/$PARENT/children` (populated) and a child's children tab (zero state). ## Test plan - [x] `cargo nextest run -p fabro-store -p fabro-types -p fabro-api -p fabro-server -p fabro-mcp-server` — 900+ tests pass, including new `run_summary_includes_children_count` in `fabro-store` - [x] `cd apps/fabro-web && bun run typecheck` — clean - [x] `cd apps/fabro-web && bun test` — 383/383 pass - [x] OpenAPI ↔ Rust parity (the `fabro-api` `run_summary_round_trip` test covers the new field both directions) - [x] Manual API verification via curl (above) - [x] Live UI verification (screenshots above) ## Out of scope (v1) - Real-time SSE updates of the children list (refresh button covers this). - Multi-page pagination UI (shows first page with a "more exist" footer when `has_more`). - Parent breadcrumb on the child run page (separate small change). - Tree/nesting view (flat list only). - Empty-state CTA. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 10:21:40 -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	b9497517a5	feat(llm): support agent profile overrides (#291) ... ## Summary Adds catalog-level `agent_profile` overrides so custom providers and individual models can choose Anthropic, OpenAI, or Gemini agent behavior independently from their adapter default. The effective precedence is model override, then provider override, then adapter metadata. ## What Changed - Added typed provider/model `agent_profile` settings in `fabro-config` and `fabro-model`, with serde/strum support for `anthropic`, `openai`, and `gemini`. - Centralized effective profile resolution in the catalog, including provider alias canonicalization and a guard against unrelated model overrides leaking across providers. - Updated run startup, API sessions, CLI/ACP backends, prompt project-memory discovery, and standalone agent startup to use the resolved catalog profile. - Documented provider-level and model-level `agent_profile` configuration in the public model and user configuration docs. No OpenAPI or model-list response shape changes are included. ## Validation - `cargo nextest run -p fabro-model -p fabro-config -p fabro-workflow -p fabro-agent` passed: 1826 passed, 125 skipped. - `cargo +nightly-2026-04-14 fmt --check --all` passed. - `cargo +nightly-2026-04-14 clippy -p fabro-model -p fabro-config -p fabro-workflow -p fabro-agent --all-targets -- -D warnings` passed. - `git diff --check` passed. - `cargo nextest list -p fabro-dev` confirmed there is no docs-options reference test target to run. ## Post-Deploy Monitoring & Validation Watch workflow and agent-session logs for provider/model resolution errors, unexpected project-memory file selection, or CLI/ACP launch command mismatches on custom catalog providers. Healthy signal: custom provider/model runs start normally and use the intended profile-specific behavior. Failure trigger: repeated `Provider ... is not configured` errors, missing expected project memory, or profile-specific agent startup failures after configuring `agent_profile`. Mitigation is to remove the override from config or revert this PR. Validation window: first deploy cycle after merge; owner: release/on-call engineer. --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 via [Codex](https://openai.com/codex)	2026-05-16 17:40:59 -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	7ac15b28f0	feat(fabro-web): port /chats/new + /chats/:id from prototype (#289) ... ## Summary Ports the validated `/chats/new` and `/chats/:id` chat surface from `docs/superpowers/prototypes/2026-05-16-chats-new/` into `apps/fabro-web`. Client-side scripted prototype mounted inside the existing `AppShell`; replaces `/start` as the planned new "kick off agent work" entry point (but does not delete `/start` in this phase). - New routes: `/chats/new` (empty-state composer) and `/chats/:chatId` (active conversation with assistant-ui's `<Thread>`, scripted streaming replies, markdown + tool-call rendering). - Drives `@assistant-ui/react` + `@assistant-ui/react-ui` via `useLocalRuntime` and a custom `ChatModelAdapter` that cycles a 6-entry scripted reply bank. - Tailwind v4 cascade fix: assistant-ui CSS is now imported via `@layer assistant-ui` so v4 utilities cascade above the package's unlayered scoped preflight. Includes a discovered Bun-specific tweak — see Notable Deviations below. - StrictMode-safe first-message handoff: store seeds the user message into `seedMessages` with a `pendingResponse: true` flag, and `chats-detail` triggers a single `runtime.thread.startRun({ parentId: null })` then consumes the flag. Avoids the prototype's autorespond-lost-stream race under React 19 StrictMode. The Ask-Fabro right sidebar (also in the prototype) is **out of scope** for this PR. Companion spec: [`docs/superpowers/specs/2026-05-16-chats-new-prototype-design.md`](../tree/chats-new-port/docs/superpowers/specs/2026-05-16-chats-new-prototype-design.md) Implementation plan: [`docs/superpowers/plans/2026-05-16-chats-new-fabro-web-port.md`](../tree/chats-new-port/docs/superpowers/plans/2026-05-16-chats-new-fabro-web-port.md) ## Screenshots Captured from a local debug `fabro server` running this branch's binary, signed in via GitHub. ### `/chats/new` (empty state)  ### `/chats/:chatId` (active conversation)  ## Files **New** (under `apps/fabro-web/`): - `app/lib/chats-types.ts` — `Chat` wrapper + `ChatContentPart` discriminated union over the API client's `CompletionContentPart` - `app/lib/chats-script.ts` — 6-entry scripted reply bank (`CompletionMessage[]`) - `app/lib/chats-store.tsx` — Context + `useReducer` for chat metadata, `pendingResponse` flag, scriptIndex - `app/lib/chats-runtime.ts` — `createScriptedAdapter` + `toThreadMessages` boundary converter - `app/lib/test-utils.tsx` — minimal `renderHook` shim (lifts the duplicated `IS_REACT_ACT_ENVIRONMENT` + dep-warning silencing pattern out of `install-app.test.tsx`) - `app/components/chats/{tool-fallback,composer-chips,custom-composer}.tsx` - `app/routes/{chats-layout,chats-new,chats-detail}.tsx` - Tests: `chats-store.test.tsx` (5), `chats-runtime.test.ts` (4), `chats-router.test.tsx` (3) **Modified:** - `package.json` — adds `@assistant-ui/{react,react-ui,react-markdown}` (pinned exactly to versions verified in the prototype) - `app/app.css` — `@layer` declaration + assistant-ui CSS imports into `layer(assistant-ui)` + `.fabro-chat` `--aui-*` variable overrides mapping to the Fabro palette - `app/root.tsx` — removed `import "./app.css"` (see Notable Deviations) - `app/router.tsx` — wires the chats routes under the AppShell tree ## Notable deviations from the plan Two intentional deviations, both explained in their commit bodies: 1. **`apps/fabro-web/app/root.tsx` no longer imports `./app.css`.** Bun's CSS bundler (used by `Bun.build` on `entry.tsx`) rejects spec-valid `@layer name, name;` ordering between `@import` rules, even though Tailwind's CLI accepts it. The CSS is built standalone by the Tailwind CLI step in `scripts/build.ts` and linked from `index.template.html`, so dropping the JS-side import bypasses Bun's parser without any runtime change. A safety-net comment at the top of `app.css` warns future engineers against re-adding the import. Commit: `c37690be9`. 2. **`!` non-null assertions removed** in two places where the verbatim prototype copy violated the global CLAUDE.md rule banning `!` in production code: `chats-script.ts` now uses a typed `FALLBACK_REPLY` and `??` coalescing; `composer-chips.tsx` lifts the first option of each chip into a `DEFAULT_*` constant. `chats-runtime.test.ts`'s `for await` drain loops were also replaced with `Array.fromAsync(...)` per the no-loops-in-tests rule. Commits: `ace6ac6d4`, `652ad97af`. ## Test plan - [x] `cd apps/fabro-web && bun run typecheck` — clean - [x] `bun test` — 383 pass / 0 fail (12 new tests for chats) - [x] `cd apps/fabro-web && bun run build` — succeeds; assistant-ui CSS bundled into `dist/assets/app.css` - [x] **Manual browser smoke test** — debug `fabro` binary running this branch served `/chats/new` and `/chats/seed_email` correctly inside the real AppShell with GitHub-OAuth auth (screenshots above). --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 17:10:16 -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	2296ba6ea8	feat(runs): add parent run links (#271) ... ## Summary Adds orchestration-only parent links between runs without merging them into fork or rewind lineage. Runs can now be created under a parent, linked to a different parent, or unlinked through event-sourced mutations that rebuild summaries and projections from the run event stream. ## Changes - Adds optional `parent_id` to run manifests, public run summaries, run projections, `run.created`, OpenAPI, and the generated TypeScript API client. - Adds `PUT /api/v1/runs/{id}/parent` and `DELETE /api/v1/runs/{id}/parent` for mutable parent links across any run state, including terminal or archived runs. - Records `run.parent.linked` and `run.parent.unlinked` events with actor metadata and previous/current parent IDs. - Validates parent changes in the API path: parent must exist for new links, self-parenting is rejected, cycles are rejected, and same-parent or already-root operations are idempotent no-ops. - Adds `parent_id` filtering to run listing while preserving dangling historical parent references after parent deletion. ## Validation - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo build -p fabro-api` - `cargo check -p fabro-workflow -p fabro-store -p fabro-server` - `cargo nextest run -p fabro-types -p fabro-store` - `cargo nextest run -p fabro-server --features test-support create_run_can_set_parent_and_list_children link_relink_and_unlink_parent_are_idempotent parent_link_validation_rejects_missing_self_and_cycles deleting_parent_leaves_child_parent_id_as_historical_reference` - `cargo nextest run -p fabro-api run_summary_json_matches_openapi_shape` - `cd lib/packages/fabro-api-client && bun run typecheck` Known unrelated broad-suite blocker: `cargo nextest run -p fabro-server --features test-support get_graph_returns_svg` currently returns 500 because the render subprocess emits test-harness output instead of SVG. --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 Generated with GPT-5 (unknown context, medium reasoning) via [Codex](https://openai.com/codex)	2026-05-16 13:57:33 -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
Bryan Helmkamp	f790a47da4	feat(sandbox): surface provider links and network policy (#275) ... ## Summary - Add provider dashboard URL reporting to `SandboxDetails`, including Daytona dashboard links and a Sandbox tab provider link. - Extend `SandboxDetails` with required provider-neutral public network policy for egress and ingress allow/block rules. - Populate local, Docker, and Daytona network policies from provider details when Fabro can assert them, otherwise default to explicit `unknown` policy. - Update OpenAPI, Rust API replacements, generated TypeScript client models, server/API tests, and the Sandbox tab `Network` panel. ## Notes - This reports policy only; it does not probe live connectivity. - The network model intentionally excludes ports, previews, IP addresses, DNS, routes, Docker network IDs, and service discovery. - Older persisted/API JSON still deserializes through the Rust serde default for `network`. ## Verification - `cargo build -p fabro-api` - `cargo nextest run -p fabro-types -p fabro-api -p fabro-sandbox -p fabro-server sandbox_details` - `cargo test -p fabro-sandbox details --features docker,daytona` - `cargo +nightly-2026-04-14 fmt --check --all` - `cargo +nightly-2026-04-14 clippy --workspace --all-targets -- -D warnings` - `cd apps/fabro-web && bun test app/routes/run-sandbox.test.tsx` - `cd apps/fabro-web && bun run typecheck` - `cd apps/fabro-web && bun run build` - `cd lib/packages/fabro-api-client && bun run typecheck` - `git diff --check` ## Post-Deploy Monitoring & Validation - Log queries/search terms: `Failed to inspect Docker container`, `Daytona sandbox is not initialized`, `missing runtime metadata`, `GET /api/v1/runs/*/sandbox`, `Sandbox unavailable`. - Metrics/dashboards to watch: API 5xx/error rate for `GET /api/v1/runs/{id}/sandbox`, frontend error reporting for the Sandbox tab, and provider reconnect/inspect failures. - Expected healthy signals: Sandbox tab loads with Overview, Resources, Network, Labels, and Timestamps; Daytona sandboxes show provider links; local/ambiguous network policy shows `Unknown`; Docker `network_mode = none` shows `Blocked`. - Failure signals and rollback trigger: sandbox details deserialization errors, missing `network` crashes, sustained sandbox endpoint 5xx increase, or blank Sandbox tab after deploy. Roll back this PR or hide the Network panel if API/client shape issues appear. - Validation window and owner: first 24 hours after deploy, release owner/on-call. ## Compound Engineering - Implemented with OpenAI Codex CLI on GPT-5.	2026-05-16 10:16:18 -04:00
Bryan Helmkamp	be993cb608	feat(server): expose health check at /api/v1/health (#279) ... ## Summary - Mount the existing `/health` handler at `/api/v1/health` so callers using a uniform `/api/v1` base no longer have to special-case the root path. The root `/health` route is unchanged and remains the canonical probe target. - Add the new path to the OpenAPI spec (`operationId: getApiHealth`, `Discovery` tag, reusing `HealthResponse`), and regenerate the TypeScript client so `DiscoveryApi.getApiHealth()` is exposed alongside `getHealth()`. - Split the old `moved_routes_not_at_root_of_api_prefix` test into a focused `api_v1_root_is_not_routed` and a new `health_responds_at_versioned_path` that asserts `200` + `{"status":"ok"}` under the versioned prefix. ## Test plan - [x] `cargo build --workspace` (verifies the OpenAPI spec regenerates cleanly via `fabro-api` build.rs) - [x] `cargo nextest run -p fabro-server` (545 tests pass, including OpenAPI conformance and the new routing assertions) - [x] `cd lib/packages/fabro-api-client && bun run generate` (regenerated client exposes `getApiHealth`) - [ ] Manual: `fabro server start` then `curl -s http://localhost:<port>/api/v1/health` and `curl -s http://localhost:<port>/health` both return `{"status":"ok"}` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 08:37:00 -04:00
Bryan Helmkamp	d52a2ccbe2	feat: add opt-in LiteLLM TOML provider (#269) ... ## Summary - Add a disabled built-in `litellm` provider fragment backed by the OpenAI-compatible adapter and local proxy defaults. - Document how to enable LiteLLM in `settings.toml`, configure credentials, and declare explicit LiteLLM-routed models. - Register the LiteLLM integration page and cross-link it from the model and settings docs. ## Validation - `cargo test -p fabro-model` - `cargo test -p fabro-config` - `jq empty docs/public/docs.json` - `rg -n 'aliases = \["openai_compatible", "openai-compatible"\]|llm\.discovery|FABRO_LITELLM|litellm_api_key_env|x-litellm-' lib/crates/fabro-model/src/catalog/providers/litellm.toml docs/public/integrations/litellm.mdx docs/public/core-concepts/models.mdx docs/public/reference/user-configuration.mdx` returned no matches --------- Co-authored-by: Mark Ferraz <mferraz@netwoven.com>	2026-05-16 08:36:31 -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	9027f1cc67	docs(tutorials): clarify what sub-workflows share with the parent run ... The sub-workflow tutorial implied a child workflow was an "entirely separate" engine with isolated logs, but the child reuses the parent's run ID and emits into the same event stream. Reframe the section as "What's shared and what's isolated" and correct the encapsulation bullet to scope the isolation to checkpoints and artifacts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 10:03:53 -04:00
Bryan Helmkamp	ba27bcdd57	docs(github): note GITHUB_TOKEN enables gh CLI in sandbox ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 08:14:22 -04:00