Blast radius, red team and 3 more prompts

i'm about to change [file/module]. don't write any code yet.
use codebase memory to map the repo into one graph, read my uncommitted diff, map every change to the functions it touches, and return: each function, its downstream blast radius, and a risk level.
once it's ranked by risk, act at three levels of authority:
L1 low risk, just do it: local, covered by tests.
L2 medium risk, isolate it: one revertible commit per change, with before/after.
L3 high risk, propose only: anything touching an interface, data, or a shared dependency, give me the plan, don't touch it.
then tell me where it's most likely to break before i merge.

i have a few independent tasks to push at once: [task A], [task B], [task C].
for these, set yourself an end-to-end goal: take the whole plan to done, until architecture, implementation, tests, review and the final result all clear the bar. split the goal into independent parts, spawn as many parallel agents as it takes to finish faster, and give each agent its own goal with its expected deliverable, verification and done criteria. schedule them in parallel, keep tracking progress, synthesize what comes back, resolve conflicts, keep implementing, verify live after every important step, review when it matters, commit when it's ready, and give a final summary. verification has to cover the real end-to-end path, including browser/computer use, clicks, keyboard, and whatever else it takes. don't stop after partial progress unless you're blocked by missing credentials, destructive ambiguity, or conflicting requirements.

before you write the first line of this plan, be my red team. your judgment is the primary weapon. treat my plan as a hypothesis to attack.
first play my plan back in full to confirm you got it right, then open fire.
assume it already failed six months from now and work backward to the three most likely reasons: which assumption i took as true without checking, which failure case i never considered, where i got optimistic to save effort, and whether there's a simpler way to the same goal.
for each, give the trigger, the cost, and one minimal experiment that could falsify it early.
end with a verdict: ship it / run which experiment first then ship / tear it down.

open [url] with browser/computer control and actually walk each of these real user paths end to end, no reading the code and guessing: [sign up], [checkout], [change settings].
at every step really click, type, wait, screenshot, and log anything that would trip up someone opening it for the first time: slow loads, errors, copy that makes no sense, buttons you can't find, unclear state, data lost on back.
output a report ranked by severity, each with repro steps + the root cause you judge + a suggested fix, then fix it yourself and walk it again to confirm no regression.
treat me as someone opening it for the first time who's never read the code.

don't rush to solve. first set the budget: is this a quick lookup, medium reasoning, or deep thinking that may need an experiment to verify, and say why you judged it that way.
before you start, lay it out: what information you're missing, where i wasn't clear, and the single most fragile hidden assumption here.
once i confirm, solve at the level you set; on the deep ones, give intermediate results step by step so i can stop you anytime.
don't paper over a two-hour problem with a two-second answer, and don't write an essay for a one-lookup question.