Run a FULL end-to-end test of the ENTIRE software-mansion/argent repository — all of it — in the local checkout. Dispatch a massive swarm of agents (dozens) and divide the whole codebase and all of its functionality between them: every entry point, every module, every command / flow / feature, the build, the test suites, the installers, and the seams between components. The goal is to surface every real defect that exists anywhere in the repo.

NON-NEGOTIABLE BAR — the bar from my CLAUDE.md, at maximum strength. TRIAGE EACH SUSPECTED FINDING'S LIKELY SEVERITY FIRST, because the proof scales to it and the expensive part has to land where it pays. A HIGH or MEDIUM finding only counts once it is HARD-REPRODUCED with a concrete, runnable reproduction that proves it exists with 100% CERTAINTY. No hypotheses, no "this could fail", no second-hand swarm claims. Every one of them must carry an exact reproduction (precise inputs / steps -> observed wrong behaviour) that I can re-run myself. And "reproduced" has a strict meaning here: you must DRIVE THE BUG IN A REAL APP RUNNING ON A REAL SIMULATOR / EMULATOR and watch the failure happen first-hand — boot the simulator/emulator, run the actual app, and trigger the fault for real. A code-reading argument, a mock, a stub, or an isolated unit test does NOT count as proof at this level. A suspected HIGH / MEDIUM you cannot reproduce beyond all doubt is NOT a finding — discard it silently. A LOW is the one level that bar does NOT apply to: it gets ONE short adversarial check and nothing more — read the exact code, confirm the trigger can really occur, and move on. Never boot a simulator / emulator and never dispatch a swarm to confirm a LOW, and drop it if that quick check cannot confirm it. A NITPICK — style preference, phrasing, or a defect with no reachable consequence — is dropped ON SIGHT, unverified: do not spend a single step establishing whether one is real. Keep dispatching fresh swarms until ONE full pass over the whole repo turns up nothing new; that single clean pass ends the loop, and a pass whose findings are all LOW counts as clean.

Classify EVERY confirmed finding by severity — HIGH, MEDIUM, or LOW — by how much it actually hurts: whether it causes significant disruption (crashes, data loss, broken core flows), how often it bites (a common / hot path or frequent trigger vs. a rare, obscure edge case), and how visible the damage is. HIGH = serious and/or frequently hit; MEDIUM = real but limited impact or moderate frequency; LOW = minor, cosmetic, or only reachable in obscure edge cases. Below LOW sits the NITPICK — style preference, phrasing, or a defect with no reachable consequence — which is not a finding at all and never reaches this report: it is dropped on sight. Tag every finding with its level and carry that label through to the report.

Deliver every confirmed finding (and every open bug-issue you reproduced and fixed) as a focused pull request, opened as a DRAFT (`gh pr create --draft`) — ALWAYS draft, never a ready-for-review PR, and never mark one ready yourself. Gate which findings actually get a PR by their severity: HIGH and MEDIUM findings always get one; a LOW finding earns a PR ONLY when its fix is small — strictly under 20 lines of diff — otherwise do NOT open a PR for it, just report it in the summary. Nitpicks never reach this gate at all: they were dropped on sight, so they get neither a PR nor a report line. RIGHT BEFORE you open each PR, verify it is NOT a DUPLICATE of an existing open PR: enumerate the repo's open PRs and compare their ACTUAL CODE, not their titles or descriptions (those routinely mislead) — read each plausible candidate's real diff with `gh pr diff <n>` and judge whether it already lands the same fix or changes the same lines to equivalent effect. If one does, do NOT open a duplicate: skip it and tell me which existing PR already covers it. Each PR gets a clear title and description that names the defect(s) and quotes the evidence that confirmed each — the hard reproduction for a HIGH / MEDIUM, the short check for a LOW — plus a closing reference to any issue it resolves. You MAY bundle closely-related fixes into one PR when they genuinely belong together (same root cause, same file/area) — that's encouraged over splitting hairs — but keep each PR coherent and reviewable: never a single mega-PR lumping unrelated fixes together, and never a PR for anything you could not confirm to its severity's bar. SELF-REVIEW GATE — before you open ANY PR, put the change you just wrote through the same review lenses a human reviewer will, and clear all four; a fix whose reproduction now comes back clean can still be sent back for any of these, and routinely is. (1) A REGRESSION TEST THAT DISTINGUISHES FIXED FROM BROKEN: ship an automated test that pins the exact behaviour the fix corrected. You already established the broken behaviour when you confirmed the bug, so you know both the wrong value and the right one — assert the right one in a way the wrong one would VIOLATE (an exact value, count, order, type, or status code — never an incidental property like `>= 1`, `contains something`, or `not-equal-to some unrelated state`, all of which the unfixed code already satisfied). The test must be one the original unfixed code would FAIL; if it would also pass against the old behaviour it guards nothing, so tighten the assertion until it targets the one thing the fix changed. This is a requirement about how strong the assertion is, argued purely from the reproduction you already captured — do NOT undo, weaken, re-break, or otherwise modify the fix to check it, and never leave the branch in an unfixed state. (2) FIX THE CLASS, NOT THE INSTANCE: treat the defect as one instance of a pattern, never a one-off. Search the WHOLE repo for every other call site, sibling backend / platform, or adjacent path that reaches the same sink or repeats the same shape (grep the shared helper, the error class, the transport, the guard / redaction) and fix every sibling that carries the same defect in this same PR — or, when one is genuinely out of scope, name it explicitly in the PR description as a known-unfixed instance with the reason. A fix for one line while an identical bug sits one call over is the single most common rejection there is. (3) DOC / COMMENT / RATIONALE RIPPLE: bring every piece of prose the change touches into agreement with the new behaviour — tool and command descriptions, JSDoc, class-level and inline code comments, README / docs, and the PR description's own rationale. Two hard rules: no comment, description or doc may still describe the OLD behaviour after your change; and every rationale you write or leave standing must be TRUE — verify each claim against the source (real case-sensitivity, which callers actually exist, a value's real units) instead of asserting a plausible-sounding reason. A stale description or a fabricated rationale is itself a defect in this PR. (4) NO DEAD CODE THE FIX INTRODUCED: re-read your own diff for anything the change made unnecessary — a branch or early-return that can never run given the guards above it, a general-form splice / loop / spread handling a case that cannot occur on this path, defensiveness duplicating a check already guaranteed upstream, or a now-unreferenced export / import / helper — and delete it. A guard whose case is currently unreachable is a smell: prefer removing it, and keep it only with a one-line comment stating why it must stay. Every line you add must be reachable and load-bearing.

No AI attribution anywhere in git/GitHub — commits and PRs authored as me, no Co-Authored-By, no "Generated with" taglines.

Diplomat attribution tag — a REQUIRED exception to the no-attribution rule, for GitHub commentary only. Do NOT tag PR titles — leave every pull-request title exactly as you would write it. End every pull-request DESCRIPTION with a footer: after the body, a blank line, a horizontal rule on its own line (`---`), a blank line, then this exact last line — `<sub>Made by Diplomat. Like what you're seeing? [Give it a try](https://github.com/latekvo/Diplomat).</sub>`. In that footer the word Diplomat is PLAIN TEXT (not a link); ONLY "Give it a try" is a Markdown link, pointing to https://github.com/latekvo/Diplomat. For every standalone comment you post instead (an issue comment, or a review / reply comment), BEGIN it with the exact prefix `\[[Diplomat](https://github.com/latekvo/Diplomat)\]: `, copied character for character — the `\[` and `\]` are literal brackets, only the word Diplomat is a Markdown link (to https://github.com/latekvo/Diplomat), anything after that link is plain text, and a colon and a space close it — followed by the text you would otherwise have written, so it renders as "[Diplomat]: <your text>". This is the ONE sanctioned attribution; it applies to posted PR-description / comment text ONLY and never changes PR titles, commit messages, commit authorship, or the no-Co-Authored-By / no-"Generated with" git rules, which remain in force.

At the very end, give me one consolidated report: every confirmed defect with its severity (HIGH / MEDIUM / LOW) and the evidence that confirmed it — the exact reproduction for a HIGH / MEDIUM, the short check for a LOW; which open bug-issues you reproduced and fixed; which PRs (if any) you opened; and anything you could not reproduce, listed explicitly as NOT confirmed so it is never mistaken for a real finding.