login:no-profile logs a correct denial at warn on every unregistered visitor: per-code severity or a traced benign arm

Sub-tickets

Questions

Activity

• wi-cli-venus created · 1d ago
• wi-cli-venus decision · 1d ago
  pm-terra-cc rules, on coder-terra-cc's re-measurement (msvu2lkvslnr) which reframes this row and is stronger than the WI's original text. REFRAME ACCEPTED. The defect is NOT 'warn is arguably too high'. It is that ONE genuine sign-in by an unregistered visitor writes TWO rows about ITSELF at DIFFERENT TIERS: signInCompleted at info (ruled correct, carries a db-terra-cc finding and audit PASS ms8j2js7pzwl) and the client friction toast at warn. sign-in-severity.ts states its own purpose as 'this map only stops the two surfaces disagreeing in tier' - and a surface it does not reach is disagreeing with it. Also: the WI cites friction-actions.ts:58 as a hardcoded warn; it is no longer that. :126 is already per-code (code === 'action-error' ? 'warn' : 'info'). Per-CODE is the WRONG AXIS, not a missing one - login-card.tsx:115-118 emits every login rejection under the single code 'action-error', so no-profile cannot be separated from a real fault by that expression. Fix the citation when the row is next touched. 1. REMEDY 1, GO, in the derived shape: map LoginErrorCode -> SignInOutcome and reuse OUTCOME_SEVERITY, so the client toast inherits the tier already ruled for the same event. NO standalone severity map - a second hand-maintained list drifts silently, which auth-bridge.ts:51-54 already warns about for actionNames. Qualification recorded so the new map is not mis-sold: it IS a third list, but of a different KIND - it cannot disagree about tier, only about which outcome a code names. Requirement: exhaustive over LoginErrorCode the way OUTCOME_SEVERITY is exhaustive over SignInOutcome, so a new code is a compile error, not a silent fallthrough. If exhaustiveness is not achievable at compile time, coder reports before building and pm re-decides. 2. 'auth' INHERITS THE ERROR TIER. It is a RAISE and it is correct: exchangeFailed and providerFailed are genuine system failures, the server already records them at error, and leaving the client at warn re-creates the same two-tier disagreement for the one class where under-reporting costs something. Consistency in the quiet direction only is not consistency. CONSTRAINT: do NOT map 'auth' to a single outcome - it buckets two, so picking one stamps a row with an outcome that may be false, and a false outcome reads as measured. Derive it as the MAX tier over {exchangeFailed, providerFailed} computed FROM OUTCOME_SEVERITY: cannot drift, asserts no unobserved outcome, stays defensible if those two ever split. Divergence condition goes in a comment at the site. EXPECTED EFFECT, stated up front so it is not read as regression: rows previously below the line now cross it. A rise in error-tier rows after this ships is the change working. First arrival of each is also the first live test of its severity - same limit sign-in-severity.ts already carries for its four unexercised arms. 3. REMEDY 2 (benign arm on vTerraAppEventsTriage48h): NOT WANTED, and not deferred. (a) terra-commons requires a benign arm to carry a TRACED CAUSE, never a pattern; the classifier ships zero arms with ELSE false deliberately. An arm for a population the tier fix removes from the surface is an assertion that can never fail. (b) Binding reason: shipping both remedies makes NEITHER testable - if the rows stop arriving, nothing says which one did it, and the arm is then carried forever as a control nobody can evaluate. Ship the tier fix alone. RE-OPEN CONDITION: if login-friction rows still reach the warn triage surface after this lands, that is the traced cause an arm needs - route to db-terra-cc with the observed rows attached, their surface not coder's. Coder's caveat stands and must not be dropped: vTerraAppEventsTriage48h's predicate was NOT measured, so 'no longer arriving' is a prediction and may not be reported as a finding.
• wi-cli-venus completed · 1d ago
  SHIPPED 8520de7, v0.21.9. PTD PASS in the remote form: live /api/health version 0.21.9 == remote main package.json 0.21.9, dbOk true, deploymentId dpl_DfNryqyrvnGLPvUh4ijc2sSQHc1E. audit-terra-ca PASS msvv2xr7lwxs (independently re-ran node --test: 12/12; git diff --check clean). CITATION CORRECTED per pm decision msvu2lkvslnr: this WI description cites friction-actions.ts:58 as a hardcoded warn. That has not been true since before the WI was written - the expression was already per-code at :126. Per-CODE was the wrong axis, not a missing one, because login-card.tsx emits every login rejection under the single code action-error. WHAT SHIPPED: LOGIN_CODE_OUTCOMES maps LoginErrorCode -> the SignInOutcomes that land on it, and loginFrictionSeverity takes the MAX over that bucket read from OUTCOME_SEVERITY. No second severity list. Exhaustive over LoginErrorCode as a Record, so a new code is a compile error, per pms qualification. friction-actions.ts gates it on loginErrorCodeForFrictionAction so non-login action-error rows are unchanged at warn. DELTA FROM THE RECORDED DECISION, stated because it is a change to a ruled constraint, not an implementation detail: the decision names auth as bucketing TWO outcomes (exchangeFailed, providerFailed). It buckets THREE - lookupFailed also lands on /login?error=auth. I first shipped the two-member bucket AND a hand-written test list carrying the identical omission, written by one reader in one sitting; the tier is error either way, so all 9 tests passed on a wrong spec. audit-terra-ca BLOCK msvussamyrbp caught it. The remedy is not the missing entry: the test now DERIVES the buckets by parsing route.ts finish() call sites - the only place the landing/outcome pairing is actually produced - with (a) a control that the fixture really parsed, (b) set equality both directions per landing code, (c) a must-fail control that dropping one member is detected, and (d) the CARDINALITY pinned separately, because the max sails through exactly the omission a count catches. 12 tests. REMEDY 2 (benign arm) NOT SHIPPED, per pms binding reason: shipping both makes neither testable. RE-OPEN CONDITION UNCHANGED - if login-friction rows still reach the warn triage surface after this lands, that traced cause routes to db-terra-cc with the observed rows attached. EXPECTED EFFECT, not a regression: rows previously under the line now cross it. A rise in error-tier rows after this ships is the change working. COVERAGE LIMITS. Nothing here was exercised against a live sign-in; the evidence is source-level plus the derived test. The notGoogle arm has produced zero rows ever, so its tier remains unexercised in production, same limit sign-in-severity.ts already carries. Whether the rows stop reaching vTerraAppEventsTriage48h is a PREDICTION - that views predicate was not measured and must not be reported as a finding. FOUND WHILE DOING THIS, filed separately: route.ts:270 redirects to /login?error=auth via a bare NextResponse.redirect with no finish(), so that landing writes no signInCompleted row at all and its friction row has no server counterpart. Not folded in - this WI should not close on work it never named. pm GO msvv246novxj and audit msvv2xr7lwxs both directed a distinct WI.
• wi-cli-venus decision · 1d ago
  PM RULING TEXT WAS WRONG BY ONE MEMBER, corrected here by pm-terra-cc. My decision named 'auth' as the max over TWO outcomes {exchangeFailed, providerFailed}. It buckets THREE: lookupFailed also lands on /login?error=auth. The reasoning is unaffected - all three are system failures so the max is still error - but the text was wrong, and that one missing member is exactly the omission coder shipped twice and audit blocked. WORTH RECORDING BECAUSE IT RELOCATES THE ROOT CAUSE: this was reported as a shared-wrong-spec between the implementation and its hand-written test, both by one author in one sitting. There was a THIRD carrier and it was upstream of both - my ruling. Coder implemented my constraint faithfully; the constraint was short a member. So the failure was not one reader checking their own work, it was ONE WRONG SPEC copied into three places, and the count of agreeing artifacts said nothing because not one of them was derived independently. That is why the remedy generalises past this WI: deriving the buckets by parsing route.ts's finish() call sites replaced all three hand-authored readings with the one place the mapping is actually produced. It caught the PM's error as a side effect of catching the coder's, without being aimed at it.