pluto
PLUTO-535
PLUTO-529 client friction-telemetry leg: un-stub notifyFriction + wire checkRequired (post-Jul-10, server-action transport)
Done low
cpcoder-pluto-cc
Deferred client leg of PLUTO-529 (server leg shipped 70df514/v2.5.0). notifyFriction currently a visual-only stub (toast.warning, NO /api POST) — decoupled by design. Post-Jul-10 (token reset), un-stub it to WRITE friction telemetry (validation-fails + user-facing feedback) at info/warn tier via a SERVER-ACTION write path (adblock-immune, posts to page URL), NOT /api. Wire the checkRequired/form-submit hook so required-field fails log. NO success logging, NO PII. This is the shared friction write path PLUTO-534 (native HTML5 invalid capture) depends on — land this first, then 534 mounts on it. HELD until after Fri Jul-10 per Elazar transport+timing decision.
Activity
-
Closed as delivered-by-another-route, with the gap it left now pinned. Shipped v2.23.45 (b3eac79). WHAT THE WI ASKED FOR vs WHAT IS TRUE NOW. Filed 2026-07-07 to un-stub notifyFriction onto a server-action transport and wire checkRequired so required-field fails log, explicitly as the shared write path PLUTO-534 would then mount on. 534 did not mount on it - it shipped the durable transport (lib/friction-reporter.ts -> recordFriction server action) wired DIRECTLY into lib/toast.ts, so every CODED toast reports on its own. There is no transport left to swap in behind this stub. MEASURED TODAY, three facts: - useActionForm, and therefore notifyFriction and the vendored checkRequired, have ZERO call sites in src/. - That stub line is the ONLY uncoded toast.warning/info in the whole app; every other friction site carries a registered code and reports. - The required-field friction the WI wanted captured IS captured - the practica.validate.*.required / solicitud.validate.*.required / *.fields.required codes are all in the closed registry and all emit through the 534 path. So the deliverable exists; it is just reached by a different door than the one this WI held open. WHAT I SHIPPED INSTEAD. Un-stubbing would have meant inventing a code for an unreached call site, which the design forbids - the registry is a closed trust boundary and a code no digest can group is worse than no code. The real residual risk was different and unguarded: toast.error requires a code at the TYPE level, but warning/info take an OPTIONAL one, so a future uncoded warning would nag the user, write nothing, and no build step would say so - a coverage hole that only shows up as a digest quietly undercounting. src/lib/friction-toast-coverage.test.ts closes it: no uncoded warning/info outside a one-entry documented allowlist; the allowlist must STAY uncoded (a stale entry fails, so the exemption cannot outlive its reason); every literal toast code resolves in the registry (an unregistered one would be dead-lettered in prod, silently); and a scanner self-guard so a broken walker cannot make the other three pass vacuously. Balanced-paren call slicing rather than a line regex - a line regex reads only the first line and calls every wrapped call site uncoded. All three mutations verified red. The stub stays, with the reason in the file: it is the Pluto EDGE of the MARS-408 vendored pair (hooks/action-form-core.ts is byte-for-byte upstream), so deleting it is a fleet-vendoring decision, not a Pluto one. COVERAGE STATEMENT. This is a static source-invariant verdict over src/**/*.ts(x): it proves every user-visible toast call site carries a registered code. NOT exercised: that the reported events actually arrive in appEvents (534 owns that leg and has its own canary), the native-validation and inline-hint mechanisms (no toast call site to scan), and any dynamically-composed code - there are none today, and the WS-F lint is what guards against one appearing. FOLLOW-ON: whether to delete the dead useActionForm/notifyFriction/checkRequired trio is a fleet-vendoring call for pm; not filed as a WI because it is a one-line decision, not work.
-
Follow-up shipped after close, pm ruling "535: cut. Zero call sites, dead. Cut Pluto edge, flag the vendored core to whoever owns MARS-408." v2.23.46: src/hooks/use-action-form.ts DELETED. Consequence worth recording - the coverage test allowlist drops to EMPTY, so the assertion is now the stronger one: every friction toast in src carries a registered code, no exemptions. Kept the staleness assertion even though it is vacuous today, so the first exemption anyone adds is enforced to be real and cannot outlive the site that justified it. src/hooks/action-form-core.ts is now orphaned in Pluto but left byte-for-byte with a header status note - it is the MARS-408 vendored core, and editing a vendored copy forks it and silently un-fixes its upstream history. Flagged to coder-mars-cc + coder-venus-cc as a fleet call, including the suggestion that the same dead-edge drift may exist on their side and the coded-toast coverage invariant if they want the shape. Suite 52 files / 739 tests green.
task
2026-07-07 by wi-cli-venus
7w ago
2026-08-22 13:31