COMMENT (own PR — GitHub blocks self-approve). No confirmed blockers. Two Majors and two Minors below; recommend fixing before merge, none of them a ship-stopper on their own.

Findings:

1. 🔴 Major — CHANGELOG.md:10 claims RouterLink "previously dropped its class." Reproduced against the pre-PR component and that's not what happens — the real prior bug is worse (silent href override). Inline.
2. 🔴 Major — router.ts:87-101: no cycle guard on the new redirect-return loop. Body.
3. 🟡 Minor — router.ts:95-96: fire-and-forget redirect dispatch with no .catch(). Inline.
4. 🟡 Minor — types.ts:81-87: compat proof only covers the sync middleware shape. Body.

On the CHANGELOG claim (finding 1, detail): I mounted the exact pre-PR createRouterLink shape (defineComponent(fn, {props: ['to']}), no inheritAttrs) against Vue 3.5.39 — the version pinned in this repo's node_modules — on both the CSR (happy-dom + createApp) and SSR (renderToString) paths:

h(OldRouterLink, {class: 'nav-link active', 'aria-current': 'page', 'data-testid': 'x', href: '/consumer-supplied'}, ...)
→ <a href="/consumer-supplied" class="nav-link active" aria-current="page" data-testid="x">Users</a>

class, aria-current, data-testid were already forwarded — Vue 3's automatic fallthrough-attrs merges any non-props attribute onto a single-root component's rendered element with zero code on the component's part. Nothing was "dropped." What the repro does show is a real, worse bug: the consumer-supplied href silently overrode the computed navigation href (/consumer-supplied won over /computed-href), because Vue's automatic merge favors the external value for non-class/style attributes. That's what components.ts:50-52's inheritAttrs: false + attrs-spread-before-owned-props actually fixes — and the PR's own new test ("should keep the owned href authoritative over a fallthrough href attribute") proves the fix works. The code is right; the changelog names the wrong defect.

On the redirect-loop gap (finding 2, detail): a middleware returning a MiddlewareRedirect toward a route whose own middleware redirects back (a misconfigured auth guard bouncing login↔dashboard) loops forever — each redirect re-enters beforeEach and re-runs the full chain. This isn't a new exposure class (the old hand-rolled cancel+goToRoute idiom had it too), but promoting it to a declarative single-object-return API plausibly lowers the bar for a consumer to hit it without separately reasoning about cycles — the two-step at least forced them to write the goToRoute call by hand. Worth a documented caveat at minimum, ideally a same-target-twice or depth-capped guard in the loop itself.

On the compat proof (finding 4, detail): the package's own pre-PR docs example used async (to, from) => {...}, and that's very plausibly the dominant real-world shape — but LegacyBooleanMiddlewareStillSatisfies only type-checks the synchronous case. I independently verified with tsc --noEmit --strict that a Promise<boolean>-returning middleware does still satisfy the widened type, so there's no live break — but the delivered proof, which the deployment order frames as "demonstrated, not asserted," doesn't cover the shape most likely to matter.

What landed well: buildRouteLocation (router.ts:48-61) is a clean extraction — goToRoute/replaceRoute share the params/query resolution instead of risking drift between two copies. The redirect-return test suite is genuinely thorough: "should short-circuit later middleware when a redirect object is returned" asserts the blocked hop never reaches a follow-on middleware (exactly the failure mode a naive implementation gets wrong silently), and the push-vs-replace tests discriminate on history.pushState/replaceState spies rather than just the end route, which is the right level of proof.

Scope: consumer touch-ups (BIO registerAuthGuard, town-crier guard collapse/replace restoration) are correctly left out of this PR per the deployment order — separate follow-up dispatches, not folded in here.

CI: all three checks (check, Cloudflare Pages, town-crier/gate) green at review time.

Automated war-room agent review — posted because this PR carries the Agent Review Requested label.

Re-verifying at head 1e6d7451 (was c38fca8). Both open Majors are genuinely fixed; one open Minor from the cross-harness thread is not addressed by this commit and stays open, non-blocking.

Major 1 — CHANGELOG mischaracterization: fixed. The 0.2.0 entry now correctly names the RouterLink defect. I reproduced the claim against the actual component (components.ts:45-53): attrs is spread before the owned href, so a consumer-supplied href is silently overridden — the entry's new wording matches the code exactly. class/style were never the real gap (Vue's automatic single-root attr inheritance already forwards those); good catch rewriting it rather than just softening the language.

Major 2 — no redirect-loop cycle guard: fixed, and it covers the case that matters. router.ts:90-91,106-136 adds a redirectDepth counter capped at MAX_REDIRECT_DEPTH = 10, incremented on every middleware-initiated redirect dispatch and reset only when a chain terminates (proceed, or a plain-boolean cancel). Because the counter lives in the closure rather than being scoped to a single beforeEach invocation, it persists across the separate navigation dispatches that a redirect chain produces — which is exactly what's needed to bound an indirect cycle (A→B→C→A), not just a direct self-redirect. On trip it resets, logs, and returns false (fails safe, lands on the prior route) rather than hanging.

One gap in the test coverage: router.spec.ts:790-861 exercises a direct self-redirect (about → about) and the depth-reset-on-terminate/reset-across-independent-navigations cases, but there's no test with three or more distinct routes forming the cycle (A→B→C→A). The self-redirect test does exercise the same load-bearing mechanism (depth persisting across separate beforeEach re-entries), so I'm not flagging this as a correctness gap — the code review confirms the guard's reach — but a mutual-redirect test with named intermediate routes would make that indirect-cycle coverage explicit rather than inferred. 🟡 Minor, non-blocking.

Minor (folded in, fixed) — fire-and-forget redirect dispatch unhandled rejection: now carries a .catch() reporter (router.ts:118-121), tested at router.spec.ts:864-882. Matches what both reviews asked for.

Minor (dispatch's finding #24 open, still unaddressed) — compat-proof coverage: types.ts:78-87's LegacyBooleanMiddlewareStillSatisfies only asserts the sync (to, from) => boolean shape stays assignable, not the pre-existing Promise<boolean> async shape. This commit didn't touch types.ts, so that gap is unchanged. Non-blocking — compile-time coverage gap, not a runtime defect — but leaving it open rather than treating it as resolved by this push.

0.2.0 surface scan (replaceRoute, notFoundComponent, RouterLink fallthrough) — nothing egregious. replaceRoute mirrors goToRoute's param-resolution path exactly and delegates to router.replace; notFoundComponent wiring in components.ts is a one-line conditional render, no edge case visible; the fallthrough merge order (attrs first, owned props last) is the fix itself and is correct.

CI green (check job: lint, build, typecheck, test:coverage, test:mutation all passed on 1e6d7451).

No blockers. The two Majors this re-verify was scoped to are resolved — COMMENT (own PR).

Auto-approved — Town Crier verdict PASS @Head, CI green, no open MAJOR+ thread. Our approval is our independent vote (approve-alongside): a peer's review / CHANGES_REQUESTED never withholds it — we verify every blocker ourselves, and a real one drops our own verdict below PASS. Any open 🟡 MINOR threads alongside this approval are non-blocking (TC-0036 R4) — author's choice: fold here or follow-up; if folding into this PR, say so in-thread and disarm auto-merge. See the verdict comment + inline notes.