Signed resume-link 404s under malformed /n/ base path (solicitar-acceso/completar)
9 admitted 404 hits, level=warn/category=navigation/action=page_not_found, route=/n/solicitar-acceso/completar?rid=6e5644ba-eed7-4c30-b75f-81172cbd98a0&exp=1781383056361&sig=... -- single rid, last 2026-06-07. A real person clicked a real signed resume link 9 times and got a 404 every time; HMAC+exp intact, only the path prefix is wrong (/n/ instead of /solicitar-acceso). 7-day TTL means this specific link is dead -- value is preventing recurrence, not recovering this user. This is the ONLY completion path for a no-profile user (§Auth: no auto-provisioning) so a silently-404ing resume link is a user who cannot get an account and has no way to report it except a support ticket. Surfaced inside the applog noise bucket that VENUS-325/PLUTO-653's now-withdrawn suppression predicate would have muted -- 3rd instance in that thread of a filter hiding the thing it was built to sort. Generator verified CORRECT at HEAD: src/lib/resume-link.ts:18 builds via resolveSiteOrigin() (Site-Origin-compliant), no /n/ literal anywhere in src/. Hypothesis (NOT measured): the bare 'n' segment where a newline would sit points at the EMAIL TEMPLATE -- a \n being literalised into the URL during plain-text templating/wrapping rather than breaking the line. One file read (the plain-text body that carries createResumeLink()'s output) would size it; not yet done. CLASS-A (live outbound-email path, §Push-to-Done pre-implementation trigger) -- needs a design ping/diagnosis before any fix, not a coder guessing at a template. Two adjacent lower-priority findings from the same measurement (log only, no separate WI): seed-shaped-UUID comisiones broken links (/administrar/comisiones/c0000000-...-0001/0005/0006, 4/3/3 hits, real prod rows, last 2026-07-17) and route='' 29 admitted page_not_found hits collapsing into dedupAllow's __no_route__ key.
Questions
Activity
-
DIAGNOSTIC COMPLETE (coder-pluto-cc, 2026-07-30): hypothesis REFUTED, no pluto code defect. Path read end-to-end: admin-actions.ts:2550 createResumeLink -> sendNeedsInfoEmail -> email.ts:519-551. Template is HTML-ONLY (no text: field), URL appears once as a single unwrapped <a href> (email.ts:542) -- no plain-text body, no manual line wrap, no interpolation adjacent to a newline. resume-link.ts:18 (resolveSiteOrigin(), Site-Origin-compliant) cannot emit /n/ and neither can the template. Row detail: ONE user, ONE link, 9 taps in 6 minutes (2026-06-07 17:17:06-17:23:04), userAgent NULL all 9, referer=android-app://com.google.android.gm/ on 5 of 9 (Gmail Android app), remainder no-referer retries from same session. /n/ has never appeared on any other route in the table's history -- single-occurrence, no recurrence in 8 weeks. Malformation happened between our SMTP handoff and the tap, on a surface we cannot read (mail-client/link-rewriter mangling the href, or an Android intent/App-Link artifact) -- genuinely unfalsifiable, not merely unmeasured, since delivered message source is not retained. Link's 7-day TTL expired 2026-06-15 -- nothing to recover for this user.
-
DOWNGRADED + REDIRECTED: this is NOT an outbound-link-origin / Site-Origin-class defect (original framing withdrawn by coder-pluto-cc -- resolveSiteOrigin() verified doing its job, email well-formed at our boundary). No fix to make in pluto code. Adopted recommendation: pin the signed-completion route (/solicitar-acceso/completar and any malformed-prefix variant) as an outcome-2 (app-shaped, pageable) hold-out in the VENUS-327/PLUTO-653 classifier fixtures, so a recurrence pages on first tap instead of sitting invisible in alert-noise for weeks -- this is what actually failed here (a signed-link 404 indistinguishable from scanner noise), not the email path. No audit design-ping needed for an email fix since there is no fix; if pinged at all, ping the classifier hold-out addition, which is already inside PLUTO-653's scoped work. Closing this WI -- folding the one actionable item into PLUTO-653 rather than tracking it twice.
-
Root cause unfalsifiable (client-side/mail-app artifact between SMTP handoff and tap, single occurrence, no recurrence in 8wk) -- no pluto code defect, resolveSiteOrigin()/email template verified correct. Actionable remainder (pin signed-completion route as outcome-2 classifier hold-out) folded into PLUTO-653/VENUS-327.
-
CORRECTION: already fixed, not merely unfalsifiable. PLUTO-13 (6868bb9, 2026-06-09, two days after the 9 404 rows) added next.config.ts:80-81 redirect '/n/:path* -> /:path*' with an explicit comment: Gmail Android wraps notification links as /n/<original-path>, strip the prefix. Live-verified: /n/solicitar-acceso/completar -> 307 -> correct path. The diagnosis (Gmail-Android-referer wrapping) was correct; the 'unfalsifiable' framing was wrong -- the mechanism was already documented in a fix outside src/ (next.config.ts), which the original src/-only grep could not surface. No classifier hold-out needed -- the redirect resolves it before the route ever reaches the 404 classifier. Retracting the hold-out item logged against PLUTO-653. Residual: that one user's link had already expired (7-day TTL) by the time PLUTO-13 shipped -- worth a one-off data check on whether their access request was ever separately completed, no code action.