Before a PR merges, TeamX computes which features, owners, and customer-visible surfaces it touches — and posts that list straight onto the PR. Regressions get caught at code-review time, not after the deploy.
Your features.depends_on declarations plus the linked-epic history on every feature_version — so a change that touches 'auth' surfaces every feature that depends on auth, back through every shipped version.
Docs you attached to tasks and epics (from the Context Engine) carry a feature_ref. A change on a task with an attached Billing doc surfaces Billing in the radius.
Every complete_task captures the files the agent actually edited. Those roll up into the parent epic and feed the 'wide surface' risk flag automatically.
public_surfaceChange affects a feature flagged share_public=true. Customers see this feature. Extra care warranted.
owner_review_requiredAn affected feature opted into 'require owner review'. The PR gets the owner auto-requested if auto-reviewer mode is 'request'.
wide_surfaceMore than 15 files touched across the epic. Consider splitting, or reviewing with extra eyes.
recent_breaking_changeAn affected feature shipped a breaking change recently. Touch carefully — regressions here are costly.
Off
TeamX never touches the PR on GitHub. You still see the panel in-app; just no side-effects on the PR itself.
Comment (default)
Post a bot comment with the Affects block. Safe: never edits what the author wrote. Comment is patched in place on every PR update, so it never stacks.
Edit description
Prepend the Affects block to the PR body itself. Idempotent — the block is wrapped in marker tags and replaced cleanly on sync.
Off
No reviewer suggestions or requests. Radius is still computed and visible in-app.
Suggest (default)
Mention the owners of affected features in the bot comment so the PR author can @-ping them manually.
Request
POST to GitHub and put affected-feature owners on the reviewers list automatically. Requires the GitHub App install to have repo write perms.
Blast Radius picks up the task by matching a TMX-N (or your team prefix) pattern in the PR title OR head branch name. If neither has a match, the radius side-effects are silently skipped — no harm done. Use TMX-N in the PR title going forward to get it working.
No. Today Blast Radius is observational — surface + suggest + request. If you need a hard gate, wire a GitHub branch-protection rule to require the owner_review_required reviewer. Auto Testing is the sibling module that actually blocks completion on failing tests; they compose well.
The union of: docs attached to this task or its parent epic with a feature_ref; features whose shipped versions listed this epic (via feature_versions.linked_epic_ids); features whose depends_on graph reaches a touched feature. Explicit links always win — attach the right docs and Blast Radius gets sharper automatically.
Yes. The three switches (pr_tagging_mode, auto_reviewer_mode, per-feature require_owner_review) are all team-scoped via team_settings. One team can be strict, another fully opt-out. No cross-team coupling.
Tight. Auto Docs writes per-feature tech + user docs on every version ship. Context Engine attaches those docs to tasks. Blast Radius reads the attachment graph to compute affected features. All three modules use the same underlying data — work_item_docs, feature_versions, touched_files — so Blast Radius gets better automatically as your docs and links fill in.
Each team's own PRs get its own radius. We key off the payload's installation_id → team_id mapping via github_installations. A PR from team A's webhook install will never trigger radius on team B's data, even if it touches the same files.
Open Settings → Blast Radius in TeamX, pick your PR tagging and auto-reviewer modes, and every subsequent PR gets the Affects block.