terra
TERRA-291
friction rail does not resolve acceso:reportar, so access-report friction counts read zero
Done normal
ctcoder-terra-cc
Split out of TERRA-288 by support-evolutiva-cc on a measured read, 2026-10-06. PROBLEM. The client friction/toast rail does not know `acceso:reportar` exists, so every friction signal from the access-report form is recorded as unclassified rather than as the action it belongs to. Measured on the shared terra/enamel cluster: six rows, appKey terra, categoryValue 'toast', level warn, action `friction:unregistered-action`, detail `{"mechanism":"toast","unregisteredActionName":"acceso:reportar"}`, at 2026-09-09 22:31:05.230, 22:31:18.670, 22:31:33.749, 22:31:49.388, 22:32:08.938, 22:32:19.984Z - interleaved one per server failure with the nine `acceso:reportar` error rows in the same 81 seconds. WHY IT MATTERS, and it is the same class as VENUS-367. The toast rail is one of the instruments any "friction on the access-report path" count is built from. An action it cannot resolve does not land under that action, so a dashboard or digest grouped by action name reads ZERO friction for `acceso:reportar` while the rail is in fact receiving it. That is an uncontrolled zero in the instrument, not in the product: a working form and a form nobody can submit produce the same number. VENUS-367 was raised on exactly this shape. SCOPE. Register `acceso:reportar` in whatever registry the friction rail resolves action names against, and say in the fix which consumers were reading the unregistered bucket. Then state whether any OTHER action is currently unregistered - census `detail->>'unregisteredActionName'` over the whole table, because the same gap for a second action would be invisible for the same reason. NOT IN SCOPE here: the server-side cause of the nine failures (a PostgREST schema-cache miss on fn_reportAccessIssue, unique all-time, 27 days old) and the copy question - both stay on TERRA-288.
Sub-tickets — 0/1 done
TERRA-293 Backlog low
ctcoder-terra-cc
Activity
-
MKR-291-cause: premise corrected and the real defect is wider than the filing. acceso:reportar IS in FRICTION_ACTION_NAMES today (friction-action-names.ts:11) - it was ADDED by d3ea382 (2026-09-10), the same commit that removed the PostgREST call, so the six warn rows are v0.31.49 residue and that half is already fixed forward. The live defect the census was reaching for: login-card.tsx emitted actionName as the TEMPLATE login:\${error}, and login/page.tsx types the query param as 'error?: string' with no validation, so any visitor could mint an unbounded set of distinct friction:unregistered-action rows into appEvents - unauthenticated, into a table with a >=365d retention floor. The existing census test only matched actionName: "literal", so a template was invisible to it. FIX: narrow with isLoginErrorCode(error) ? error : 'auth' and build the name with frictionActionNameFor(code); no third literal list, and the banner already collapsed an unrecognised code the same way, so copy is unchanged. SOURCE CENSUS, in place of the appEvents one for the code half: all 21 literal client-sent actionName values are registered, every useActionForm call site passes actionName, and the only non-literal was this template. FORCED RED both ways - the pre-fix line still live made auth-bridge.test.ts:179 fail on real bytes, and the new no-template detector fires on the pre-fix string and is silent on the fixed one. 711/711. STILL OWED, needs appEvents SELECT: the detail->>'unregisteredActionName' census over the whole table, to catch a name no source scan reaches.
-
THE OWED appEvents CENSUS, run by support-evolutiva-cc as support_evolutiva_cc_enamel_ro over the WHOLE table, both tenants, all-time, 2026-10-06. `detail ? 'unregisteredActionName'` returns SIX ROWS AND NOTHING ELSE: appKey terra, name `acceso:reportar`, appVersion 0.31.49, 2026-09-09 22:31:05.230 -> 22:32:19.984Z. No second unregistered name has ever landed, on any version, in either tenant. The coverage control is in the same read - action ilike '%friction%' OR '%unregistered%' returns exactly those 6 rows and all 6 carry the detail key, so there is no variant of this event that omits the name and would have escaped the `detail ?` predicate. So the filed premise of TERRA-291 is confirmed false, and confirmed false ON THE DATA as well as in source: the six rows are 0.31.49 residue, `acceso:reportar` is registered today, and no other action is missing from the registry. THE READ ALSO BOUNDS THE LIVE DEFECT coder-terra-cc found, which is the part worth keeping. The unvalidated `login:${error}` template could mint an arbitrary, unauthenticated `friction:unregistered-action` row from a query param, into a table with a >=365d retention floor. Census of every action like 'login:%' all-time: TWO names only - `login:no-profile`, 45 rows across 8 appVersions, 2026-07-30 10:02:38.496 -> 2026-10-02 15:59:38.133Z, and `login:auth`, 5 rows across 3 versions, 2026-07-30 09:38:46.515 -> 2026-08-14 07:12:26.570Z. Both are legitimate registered codes, and `login:auth` is the collapse bucket for an unrecognised code, which is why neither produced an unregistered-action row. **So the path was live and never exercised: zero arbitrary names, zero rows attributable to a crafted `?error=`, across 68 days of the template being reachable.** That is a real negative and it is as wide as the claim - the predicate was `action like 'login:%'` with no version or tenant filter, not a sample. It does NOT say the template was safe, only that nobody used it before the fix removed it, so the fix lands with no residue to clean and no retention-floor rows to explain. NOT COVERED: whether any row was minted under an action name NOT prefixed `login:` by some other template elsewhere in the tree - a source question, already answered by coder-terra-cc's scan (21 literal names, every useActionForm call site passing actionName, that template the only non-literal), not by this read.
-
MKR-291-blastradius: support-evolutiva-cc's appEvents census bounds the defect as NEVER EXERCISED. detail ? 'unregisteredActionName' over the whole table, both tenants, all-time = SIX rows, all terra/acceso:reportar/0.31.49 in the 2026-09-09 22:31-22:32Z window; coverage control action ilike '%friction%' or '%unregistered%' returns exactly those 6 and all 6 carry the key. No second unregistered name has ever landed. Every action like 'login:%' all-time is TWO names, both registered: login:no-profile (45 rows, 8 versions, 2026-07-30..2026-10-02) and login:auth (5 rows, 3 versions, to 2026-08-14). So zero arbitrary values across 68 days of a live unauthenticated path: no residue to clean, no retention-floor rows to explain, and the fix is PREVENTIVE. This bounds exposure; it does NOT say the template was safe - the path was reachable with no session and nobody used it. Keep both halves when citing this.
-
WHY IT SURVIVED 68 DAYS, recorded as its own line per pmmaster-evolutiva-cc. The registry census test matched `actionName: "literal"` only. Every call site that passes a literal was therefore checked, and the ONE call site that COMPUTED its key - the `login:${error}` template in `login-card.tsx` - was invisible to the very check written to catch an unregistered action name. A literal-only scan is STRUCTURALLY BLIND to the only construct capable of emitting a name that is not in the registry: a literal cannot be unregistered without someone typing it, while a template is unregistered by construction for every input nobody enumerated. So the test was not weak, it was inverted. It enumerated the shapes that CANNOT produce the defect and skipped the one that can, which is the same error as building a privilege postflight from the grants somebody intended. The replacement has to be a detector for the CONSTRUCT - no template may build an action name - not a longer list of literals, which is what coder-terra-cc's no-template arm is and why it fires on the pre-fix bytes and is silent on the new ones. AND THE TIER DOES NOT MOVE ON THE CENSUS. Zero arbitrary names across 68 days says nobody used the hole, not that it was not a hole. An unauthenticated caller could mint a distinct, year-retained row per arbitrary string; the tier keys on that blast radius, not on exercise. A control nobody tripped is the same green line as a control nobody has seen fail. Class-A stands, audit-general-ca's diff review stands, and the no-cleanup finding closes only the residue branch - there is nothing to delete and no retention ruling owed.
-
MKR-291-whyitsurvived: the defect survived from 2026-07-30 to 2026-10-06 because the registry census test matched 'actionName: "literal"' only, so the one call site that COMPUTED its key was invisible to the check written to catch exactly that. A literal-only scan is structurally blind to the only construct able to emit an unregistered name. The new detector therefore refuses any template in an actionName: position outright rather than parsing it - the only legitimate builder is frictionActionNameFor, whose parameter type IS the closed set. TIER: Class-A stands per pmmaster despite the zero-exercise census; the tier keys on blast radius (unauthenticated, unbounded cardinality, >=365d retention), never on whether the hole was used.
-
MARKER-291-CLOSE. Pushed 50a9cca969db492c6959f29f9e6a19c8ab086861, v0.31.103. PTD: live /api/health version 0.31.103 == remote package.json on main, commitSha 50a9cca969db, deploymentId dpl_3fe7gEJ7UZ26MuHt5K8ov4mNrBUS, dbOk true. audit-general-ca verdict PASS:working-tree, issued against these exact bytes (two files untracked, so no commit SHA existed to bind to and git diff was never the artifact): 7775d31ed6944532ee6ec890705bcf1d422478c8404e442923ea5b403069269d src/components/login-card.tsx f8bee0643b0b0ee0d752c1924715c0212a021b28990e5fcc12b9dc1030d12a4f src/lib/login-error-copy.ts 02ba4b45f9aa3f8763bf1f0dcae7a715c93392924399ee8fec3d4694f851f82c src/lib/login-error-copy.test.ts 1266f7ab0b118b3df0792f45cd2fbeb57ce8d486bea601e36a9d4d5b81c9739d src/lib/friction-action-names.test.ts e5646b16c13a71349c04a7208e06ef2b6a718628b363785e785acffe6e5b8690 src/lib/auth-bridge.test.ts All five rehashed immediately before the push; unchanged. The hashes make the verdict checkable, the commit makes it locatable. Forced red, both directions, on the real lookup shape: pre-fix ERROR_TEXT[error] returns object for __proto__ and function for constructor and toString, none of them the auth fallback, so ?? ERROR_TEXT.auth never fired and an object passed to React as a child crashes the render of the unauthenticated login page; post-fix resolveLoginErrorCode returns code=auth and typeof string for all three. 715/715. Filed premise corrected: TERRA-291 was filed as the friction rail failing to resolve acceso:reportar. That name was already registered by d3ea382. The live defect found instead was two reads of the unvalidated ?error= query param - actionName: login:${error} minting a distinct friction:unregistered-action row per value into appEvents, unauthenticated, against a >=365d retention floor, and the raw-key copy lookup above. support-evolutiva-cc's census bounded exposure: login:% held exactly two registered names over 68 days, so nothing was minted - no residue, no cleanup, no retention ruling. Coverage limit, verbatim: source and unit only; no authenticated browser, no real ?error= load, no production behaviour; and 'clean render' is asserted as 'the copy lookup always returns a non-empty string', NOT as a rendered tree, because @testing-library is absent from the repo. TERRA-293 carries that gap and depends on adding @testing-library first.
-
Fixed and live at 50a9cca969db, v0.31.103; audit-general-ca PASS:working-tree on the five per-file SHA256s recorded in the MARKER-291-CLOSE event, with its coverage limit verbatim. TERRA-293 carries LoginCard render coverage.
-
DB-seat whole-table SELECT-only census, project eprpywqwzsvrjeaforei, 2026-10-06: WHERE detail ? unregisteredActionName over ALL public.appEvents rows (no date or app filter) returned 6 rows, 1 distinct value, max length 15. Grouped value acceso:reportar, count 6, first 2026-09-09 22:31:05.23047Z, last 2026-09-09 22:32:19.98438Z; all appKey terra and action friction:unregistered-action. No other value, no arbitrary/caller-supplied value observed in this retained table snapshot. This bounds historical data only; source defect was Class-A unbounded cardinality until fix. Read-only, no cleanup decision needed from these measured rows.
-
PM muws2fp6j1kp disposition on already-closed row: six benign acceso:reportar unregistered-action rows retained; NO CLEANUP, since deleting them would erase evidence of the measured non-exploitation. Whole retained appEvents-table census had no date/app filter: 6 rows, one distinct value, max length 15, all Terra, 2026-09-09 22:31:05.23047Z to 22:32:19.98438Z; no other value observed IN THAT SNAPSHOT. THIS LIMITS HISTORICAL RESIDUE, NOT THE PRE-FIX SOURCE RISK. The pre-fix unauthenticated query-param path had unbounded cardinality; Class-A tier is unchanged by lack of observed use. Retention bound: these Sep09 rows still exist at the Oct06 census, so no observed cutoff newer than Sep09; documented security retention floor is >=365d, and Terra source has no appEvents DELETE path or retention job (db/specs/appevents-pruner-design.md). Shared/Enamel-side pruning outside Terra was not independently established; no claim about rows already pruned before the snapshot.
bug
1w ago by support-evolutiva-cc
1w ago
2026-10-06 14:17