/mcp endpoint, which arrived in v1.1.0: the knowledge-graph skills, which query the graph it serves, and bd-system-questions, which calls its diagnostic tools.
Which pages you are reading. These document the current release — what you get by deploying a released version.
The latest entry in the version selector documents the development line instead: changes that have landed there but have not been cut into a release. What it describes can still change before it ships.
Admin sign-in, project memory your team can query, and an orchestrator that releases itself.Before you upgradeIf your runs execute on Fly Machines or local Docker and fetch a private sibling repository while installing dependencies, this release breaks them until you act. The token those runners receive is now scoped to the target repository alone, matching what GitHub Actions mode always did. Turn on Dependency Token Scope on the project mapping to restore that access through a separate read-only token. Runs on GitHub Actions are unaffected.Admin sign-in
- The admin interface supports Google and Microsoft sign-in, with the shared access code kept as a deprecated fallback. See Admin sign-in.
- Access is an allowlist matched against the verified email address or its domain, and it fails closed — an unverified or missing address is refused before the allowlist is consulted.
/mcp endpoint- An orchestrator can serve a project knowledge graph — shared memory of past issues, pull requests and decisions — over an authenticated endpoint that Claude clients and the BuildDown skills connect to. See Knowledge graph.
- Connecting uses the same identity providers as admin sign-in, and a client in regular use stays signed in rather than re-authenticating on a schedule. See The
/mcpendpoint. - The same endpoint answers questions about the orchestrator itself — why an issue isn’t running, what is in flight, how a project is configured — through read-only diagnostic tools.
- An orchestrator can build and release its own next version, which is also the only way to change the knowledge graph it serves. See Self-deployment.
- Releasing pauses new dispatches and waits for running work to finish first, so nothing is dispatched into a version about to be replaced.
- A Deployments panel reports what is running, what is available to deploy, and how the last release went.
- A Reports panel summarizes activity by repository, run outcomes, planned-versus-actual comparisons, and runaway runs over a window you choose. See Admin interface.
- A Parked issues card lists issues the orchestrator has stopped picking up, each with an Unpark button.
- The runner-mode switch moved to the Runners panel, alongside the rest of the runner controls.
- Report cards are readable per issue and across the fleet from a connected client, covering every dispatch, its cost, and whether the work was approved, merged, and later edited.
- A child pull request that conflicts with its grouping branch is recovered automatically, within a bounded number of attempts, before it is left for a person. See Feature-branch grouping.
- A grouping parent is held while its roll-up pull request awaits your review, rather than being dispatched again underneath it.
- An issue whose declared files overlap a sibling’s on the same grouping branch waits for that sibling to merge.
- An issue whose dispatches keep failing is parked rather than retried indefinitely, and stops being picked up until someone unparks it. See Troubleshooting.
- A GitHub Actions run that never reports back is now canceled and re-dispatched against a bounded attempt budget, and the issue gets a comment asking for a person once that budget is spent. See Run statuses and failures.
- The planning phase now posts an Implementation Map, an Acceptance Bar, and Risks & Open Questions, replacing the four comments it used to write. See AI planning phase.
- Two of those are read by the run and not only by you: the review pass checks the diff against the Acceptance Bar, and the Implementation Map’s file list holds back a sibling issue whose declared work would overlap.
- Planning context can be read from Jira comments, fetched newest-first and across pages, so a late re-plan on a busy issue is not missed.
- The post-push review matches your external review check by name, and which names it matches is configurable per repository. See Customize pipeline behavior.
- That reviewer’s blocking findings are folded into the step’s own passes, so a pull request is not approved while any of them stand.
- Only a check concluding
success,failure, orstalecounts as a review at all. Every other conclusion fails closed rather than approving, including any GitHub adds in future. - Reviews run against pushed commits rather than only against the pull request as it was opened, so a fix pass is no longer merged unreviewed.
- The pipeline can be run against a checkout on your own machine from a task file, with no ticketing system, no orchestrator and no pull request. See Run the pipeline on your machine.
- Fifteen environment variables are new, and none were removed or renamed.
.env.examplecarries every one with grouped comments, and Environment variables documents the ones you set. - The default runner image is rebuilt from this release, so a target repo that has not pinned its own image picks the new one up on its next run.
gap_analysis_modelis no longer read fromWORKFLOW.mdfront matter. Setmodels.implementandmodels.reviewin.ai-implement/config.ymlto run implementation and review on different models.
The first stable release. It consolidates roughly a hundred changes that had been accumulating on the development line, so an operator moving from a pre-release deployment gets all of the following at once.Ticketing
- The orchestrator now authenticates to Linear as an application rather than with a personal API key.
LINEAR_API_KEYis retired in favor ofLINEAR_CLIENT_IDandLINEAR_CLIENT_SECRET, and Linear activity is attributed to the app rather than to a person. See Create a Linear app. - Jira supports Basic authentication with a long-lived API token, which needs no refresh. The OAuth path remains available. See Environment variables.
- Issues are marked done when their pull request merges, driven by a poll that runs regardless of webhook configuration.
- Runners no longer hold ticketing credentials at all — the orchestrator applies every tracker update itself.
- A parent issue and its children can now be worked as one unit: children open pull requests into a shared grouping branch, and the tree arrives as a single reviewable pull request rather than several unrelated ones. See Feature-branch grouping.
- An optional per-project setting merges child pull requests into their grouping branch once checks pass. It never merges into your default branch — that final pull request always waits for a human.
- Runner image resolution is unified across execution modes, so the same
.ai-implement/image.ymlapplies whether a run executes on GitHub Actions or a Fly Machine. - The implementation job’s runner is configurable, so CPU-bound test suites can be pointed at a larger machine.
- Session runners receive a GitHub token minted by the orchestrator rather than carrying their own credentials.
- Runs emit structured telemetry and per-step timings, with verbosity controlled per repository.
- Notifications distinguish planning from implementation, so the two phases of one issue are no longer indistinguishable.
- A failed run now reports why in actionable terms — timed out, review flagged the pull request, or failed outright — posted to the issue whether or not a webhook is configured. See Troubleshooting.
- Widened clock-skew tolerance when minting GitHub App tokens, which was rejecting valid requests on hosts whose clocks ran ahead.
- Newly created files are included in the review diff rather than being reviewed as if absent.
- An oversized review diff no longer discards otherwise working implementation output.
- Planning runs are tracked against the correct workflow instead of being stranded in an unknown state.