byre/TODO.md

Bugs

M1 — One agent end to end

M2 — Seeing the work

M3 — Second vendor and review

M4 — Merging and history

• Merge-resolution stage A stage triggered when merging the default branch into a task branch conflicts; its result goes to review.
• Git notes on squash merges Attach a note under refs/notes/byre to each squash commit, holding the plan, the handoff bundle, review summaries, eval results and resolved inbox decisions, with full transcripts referenced by task ID. Notes don't push or fetch by default, so the merge pushes the notes ref explicitly and project setup configures fetching it.
• Repeated merge cycles Let a task merge more than once. After the squash commit lands, reset the task branch to the new default-branch head, since squash commits leave the agent's commits as non-ancestors and later cycles would accumulate spurious conflicts (the per-turn history stays reachable through snapshot refs). Then tell the agent explicitly that its branch was squashed and reset, so it doesn't try to repair history, and resume it; files on disk don't change. Test this per vendor.
• Archive search Search closed tasks across transcripts, artifacts and decisions.
• GitHub Issues integration Issue tracking is pluggable, GitHub Issues first. Tasks link to issues at intake, and each merge posts or updates a summary comment on the linked issues.

M5 — Workflows

• Workflow definitions and storage A workflow is a sequence of stages, each with a role prompt template, a vendor and model, typed artifact inputs and outputs, an optional gate, and optional review profiles. Definitions, prompt templates and review profiles live on the server, not in repos, and export and import as files. A task freezes its workflow definition at intake, so later edits to the workflow don't change running tasks. No general DAG engine until a real workflow needs one.
• Stages, gates and bounded loops Gates are human approval through the inbox, a review pass or an eval pass. Loops are bounded, for example on_fail: { goto: build, max: 3, then: escalate }.
• Plan artifact A versioned artifact with goal, approach, steps, acceptance criteria, risks and open questions. Humans edit it through the inbox; agents propose edits, which go to the inbox for approval. Stored on the server and attached to merges with git notes, never committed. A plan-conformance review profile compares the diff with it.
• Eval stages Report pass or fail per acceptance criterion of the plan.
• Task intake Pick a workflow, fill its inputs (a brief, attachments, linked GitHub issues, handoff bundles from other tasks), and optionally override vendors, models, prompts or review profiles per stage.
• Mid-task swapping of stage vendors, models, prompts and review profiles At any point a human can swap a stage's vendor, model, prompt or review profiles, and add, remove or reorder the stages of the task's frozen workflow.

M6 — Fan-out

• export_context and handoff bundles An export_context(purpose) MCP tool producing a bundle with the goal, decisions made and why, current state, dead ends tried, open questions and relevant files. Used for cross-vendor forks, stage-to-stage handoff, and the durable record of a task. Compaction already writes the same contents.
• Same-vendor forks
• Cross-vendor handoffs Forking a snapshot into a different vendor: the new session starts from a handoff bundle from export_context instead of the vendor's native fork, and the UI labels it a handoff, not a true fork. Same-vendor forks from a snapshot exist (see "Forking" in docs/operations.md).
• Fork-and-compare A fan-out of N forks with different vendors or prompts from one snapshot, followed by a judge stage that produces a comparison with visuals.
• Just-in-time fan-out with limits spawn_stages(stages[]) and collect(stage_ids[]) MCP tools let agents build workflows on the fly, using the same stage definition format. Limits on maximum depth, concurrent spawned stages and per-task usage budget, all configurable; an optional per-workflow human gate on spawning. Spawned stages show in the task's UI tree marked as just-in-time, and a just-in-time structure can be saved as a reusable workflow.
• Decide the default limits for just-in-time fan-out Defaults for maximum depth, concurrent spawned stages and per-task usage budget.

M7 — Inbox triage

• Inbox triage agent An agent that answers questions resolvable from the repo or docs and escalates the rest with its reasoning attached. Tune it on real inbox data.

Known hazards

• Pre-push hook on the shared repo Agents share the repo's .git across worktrees and run fully permissive, so they can push, check out other branches, delete snapshot refs, or run git gc or git worktree prune. Session guidance already forbids this; add a pre-push hook on the shared repo that blocks pushes not made by byre, and periodically verify that snapshot refs survive.
• Consider moving large event payloads into blobs Stream-json is verbose and tool outputs are large, so the event log grows fast. SSE resume and scrubbing need efficient queries; storing large payloads as blobs is one option.