Session dies mid-session on read-only navigation ~1h after login

Sub-tickets — 0/1 done

Activity

• wi-cli-venus created · 2026-08-16
• wi-cli-venus note · 2026-08-16
  OBSERVED IN PRODUCTION 2026-08-14 07:12Z, one user - no longer latent. coder-terra-cc correlated Vercel runtime logs to appEvents to the second: 07:12:14 GET / 307 with AuthApiError refresh_token_not_found (cookie ALREADY held a dead refresh token on arrival), same error across four renders through 07:12:19; then three sign-in attempts - 07:12:20 signInInitiated / 07:12:25 signInCompleted exchangeFailed, 07:12:30 / 07:12:44 noProfile, 07:12:53 / 07:12:57 authorized actorUserId 6ebaffae. User arrived logged out without being told and needed THREE attempts to return. ATTRIBUTION HELD, do not upgrade this: refresh_token_not_found proves only that the cookie held a token GoTrue rejects. An aged cookie or a sign-out elsewhere produce the IDENTICAL error, and TERRA-20's second front door was still open on 08-14 (closed 08-16), which is a live confound. This is the observation TERRA-19's instrument exists to attribute, not a confirmation of the rotate-then-failed-persist mechanism.
• wi-cli-venus statusChanged · 2026-08-16
  status=backlog
• wi-cli-venus priorityChanged · 2026-08-16
  1
• wi-cli-venus note · 2026-08-16
  Instrument plane corrected be8e838 v0.16.8 - see TERRA-24. Attribution for the 2026-08-14 07:12Z occurrence remains UNRESOLVED and is what TERRA-19/24's instrument exists to supply.
• wi-cli-venus note · 2026-08-16
  SEQUENCING RULED 2026-08-16 by pm-terra-cc, on coder-terra-cc raising it as a project call (tag coder-terra-cc-msvhw519sxn0). SHIP THIS NOW. Reasons in order, and the second is the load-bearing one. (1) A P1 that logs real users out outranks an observability exercise. You do not hold a live defect open to keep an instrument able to prove itself. (2) THE CHOICE WAS FALSE. The stated fork was "fix TERRA-22 and TERRA-24 loses the natural occurrence it is waiting for". TERRA-24 does not need a natural occurrence - it needs the cookie write to FAIL. That is injectable: an unwritable cookie store in a test exercises the swallow on demand. An injected-effect fixture does not decay and does not depend on production reproducing a condition we are about to remove, so it is the better instrument even setting TERRA-22 aside. TERRA-24 is reframed accordingly. If it turns out not to be constructible, that is a real fork and comes back. FIX SHAPE APPROVED: (a) middleware, running where cookies are writable so the rotation persists. Shape (c) - dropping dependence on the GoTrue cookie - was WITHDRAWN BY THE CODER and the withdrawal is the record: terra resolves roles and identity from pg by authId and never trusts JWT claims, but getUser() is a live GoTrue call that VALIDATES the token, and that validation is the authentication. Remove the refresh and the token simply expires at 1h. CONSTRAINTS, both from the coder and both accepted: matcher excludes _next/static and assets so a GoTrue round-trip is not added to every file; and it fails OPEN on its own errors, because terra has never carried an always-on request-path component and one that throws is an every-route 500. FAIL-OPEN NEEDS ITS REASON IN THE DIFF so review does not read it as a relaxed auth gate. Middleware REFRESHES, it does not authorize. resolveAccess runs downstream and still denies. Middleware that throws breaks every route; middleware that declines yields a request that meets the real gate unchanged. That is why fail-open is correct HERE and is not a precedent for failing open in a component that decides access. MECHANISM, re-read from installed auth-js 2.110.8 rather than memory: getUser to _getUser to _useSession to __loadSession, which refreshes past EXPIRY_MARGIN and persists - so every Server-Component render past ~1h triggers rotate-then-fail-to-persist. GoTrueClient.js:2622-2666. New detail: on AuthSessionMissingError, _getUser calls _removeSession - another cookie WRITE on the same unwritable path - and returns {user:null} rather than throwing, which is why the symptom is a silent logged-out render and not an error. CLASS-A: pre-implementation audit ping, diff review before push, full PTD. NO BEFORE/AFTER READING EXISTS. TERRA-23 closed with the verdict that it cannot detect this defect at this population - the interval it measures is time-to-logout plus time-until-next-visit, and nobody in this cohort browses across the boundary. Verify by the mechanism, never by that screen.
• wi-cli-venus audit-finding · 2026-08-16
  Class-A pre-push diff review dispatched to audit-terra-ca (pm-terra-cc-msvlfuzyt430). Built by coder-terra-cc, uncommitted, 4 new files, nothing modified: src/proxy.ts, src/lib/proxy-session.ts, src/lib/proxy-matcher.ts, src/lib/proxy-session.test.ts. 8 tests green, tsc --noEmit clean. DELIBERATE FORK from the pm plan that changed the file set: next/server is not loadable under bare node --test (measured ERR_MODULE_NOT_FOUND), so the untestable boundary was drawn AT the Next import - proxy-session.ts takes structural RequestLike/ResponseLike plus injected passThrough, proxy.ts supplies NextResponse.next, and the matcher moved to its own module so the test asserts the SHIPPED string rather than a retyped copy. Coder's stated coverage bound, carried forward rather than dropped: client and response factory are both injected, so the tests cover terra's half of the contract with @supabase/ssr and NOT @supabase/ssr, auth-js, GoTrue, or Next's matcher compilation - and there is NO evidence the ~1h logout is gone. Test (e) anchors the raw matcher string with ^...$, testing the pattern's intent, not routing. Audit asked to judge whether that boundary leaves anything load-bearing untested and whether the coverage bound is drawn wider than the tests support. Push waits on the verdict.
• wi-cli-venus audit-finding · 2026-08-16
  BLOCK from audit-terra-ca (msvlgn5o6q52). The uncommitted diff is NOT BUILDABLE: pnpm build fails in Next 16.2.10/Turbopack at src/proxy.ts:65:14 - 'Next.js can't recognize the exported config field... matcher[0] need to be static strings or static objects'. config.matcher cannot consume the imported PROXY_MATCHER, so the matcher-module split moved a load-bearing Next static-analysis requirement onto the untested side. THE REUSABLE FINDING, worth more than the fix: 97/97 tests passed and pnpm typecheck passed, both before and after. Neither checker can see this class of defect. Turbopack's static analysis of an exported config field is a THIRD checker, and it is the one that reads the shape a module split changes. A green tsc --noEmit plus green tests is not a green build. This is the second time in one day on terra that a stack of independent green checks missed the actual defect (TERRA-35: four green checks over source and units while the OnFailure= trigger path was broken) - and both times the finding came from exercising the real mechanism rather than from adding another static check. The Class-A pre-push gate is what caught it. Had TERRA-22 been tiered Class-S on 'coder self-verifies', an unbuildable diff reaches the push lane and the failure surfaces as a Vercel build failure on production's deploy queue. Audit accepted the rest: the injected-seam design is justified, and the coder's stated coverage bound is correct as written - the tests prove request-first write-through, options preservation, the rebuilt response, getUser invocation, and structural matcher intent, and they prove NOTHING about @supabase/ssr, auth-js, GoTrue, Next routing, or whether the ~1h logout is gone. FIX DISPATCHED (pm-terra-cc-msvlh8yk6e1e): matcher returns to a literal in src/proxy.ts; anti-drift preserved by extracting the source literal in the test or asserting source equality, NOT by retyping the string into the test - that reintroduces the drift the split existed to prevent. Re-run test, typecheck AND build before re-submitting.
• wi-cli-venus statusChanged · 2026-08-16
  BLOCK on build; rework dispatched to coder-terra-cc
• wi-cli-venus commit · 2026-08-16
  IMPLEMENTATION SHIPPED, BUG NOT VERIFIED FIXED. c33f37a..9e9911b, v0.18.0. Committed files read from push output, not predicted: src/proxy.ts, src/lib/proxy-session.ts, src/lib/proxy-session.test.ts (new) + package.json. 468 insertions. TERRA-24's two files listed as stray-outside---only and did not go. CLASS-A PTD, four planes: - /api/health cache-busted: 0.18.0, dpl_B4VPd2fTbTkupdx4iurE4HpZPTJq, dbOk true, 09:29:34Z, matching package.json at origin/main. - Deployment: READY, target production, aliased to terra-enamel.pensanta.com, gru1, turbopack. - SHA read from the deployment record regardless of the version match: githubCommitSha 9e9911b9790cac443f4a11a273e9d7a8d9b32053. - Build log: 'f Proxy (Middleware)' in the route table at 09:28:20, Next.js 16.2.10 Turbopack, compiled 7.0s, TypeScript clean. The proxy is in the DEPLOYED OUTPUT, not merely in the repo. RUNTIME PLANE IS UNREAD, NOT CLEAN - coder stated the limit rather than the result, correctly. / /login /mi-cursada exercised (307/200/307, the expected unauthenticated shape); the runtime log for that window shows only serverless entries and NO edge-middleware entries at all. That is not evidence the proxy did or did not execute. Vercel's runtime plane is not surfacing proxy invocations for this project. No errors in the window. THE BOUND, CARRIED UNSOFTENED AND WRITTEN INTO THE COMMIT MESSAGE IN THESE WORDS: this closes the implementation, not the bug. audit's PASS is unit and build proof. Nothing exercises an aged live session, a GoTrue rotation, or browser cookie acceptance, and NOTHING SHOWS THE ~1h LOGOUT HAS STOPPED. The WI stays open for that reason - closing it here would close it on work it never named. A FAILED PUSH BURNS A VERSION, found by reading back: the first attempt printed 0.17.0, the pre-push hook rejected it, but sitebump runs BEFORE the hook so 0.17.0 stayed on disk and the successful re-run bumped to 0.18.0. The number printed by a failed run is not the number that ships. Coder would have reported 0.17.0 from memory. UNCOMMITTED WORK IN A SHARED TREE IS NOT ISOLATED FROM ANOTHER PUSH'S GATE: typecheck is tree-wide, so TERRA-24's unsubmitted file BLOCKED this push on noUncheckedIndexedAccess until fixed. It cannot dirty the commit; it can stop it.
• wi-cli-venus blocked · 2026-08-16
  Implementation shipped at 9e9911b v0.18.0 and verified present in the deployed build output. The BUG is unverified: no aged live session has been exercised. Blocked on eq 32 (live session-expiry test) with Elazar - a real browser session must age past an hour. Until then the fix is shipped and unvalidated.
• wi-cli-venus commented · 7w ago
  Unchanged and still unreproducible on demand 2026-08-22: needs a real session left idle ~1h on read-only navigation. NOT stale though - the mechanism is recorded and narrow. src/proxy.ts excludes api/ by PREFIX from session refresh, which is correct today because /api/health is the only route and consumes no session, but the exclusion is what will silently re-create this for the first AUTHENTICATED /api route somebody adds. That warning is still in the file. Nothing to do until Puia and the alumnos generate real sessions.
• wi-cli-venus commented · 7w ago
  RUNTIME PLANE NOW SURFACES THE PROXY, which it did not at v0.18.0 - and the one auth error in production is GATE-CORRECT, not this defect. Read 2026-08-22 by coder-terra-cc from the Vercel runtime logs, 7d window, project prj_HTTOJEAeVtjuJ3BJMYvyck2xmYaq. THREE ERROR GROUPS IN 7 DAYS, ALL ALREADY TRACKED, none new: AuthApiError refresh_token_not_found (2, this WI), poolIdentityFailed (2, TERRA-98), PKCE exchangeFailed (2, TERRA-51). Nothing unfiled. THE PROXY IS EXECUTING AND IS NOW VISIBLE. The v0.18.0 close recorded "the runtime log shows only serverless entries and NO edge-middleware entries at all - that is not evidence the proxy did or did not execute". It is visible today: log lines carry source `serverless-middleware` on /login, /mi-cursada, /cirugias, /administrar, /administrar/usuarios, /alumnos, /practicas/nueva, /mi-perfil. That closes the "did it run" half of the verification gap by observation rather than by build output. THE 12:38:39Z OCCURRENCE IS A CLEAN RECOVERY, and the full request sequence is why I am not filing it as a defect: 12:38:39 GET / 307 [error] AuthApiError refresh_token_not_found 12:38:41 GET /login 200 12:38:44 POST /login 200 12:38:51 GET /auth/callback 307 12:38:51+ /administrar, /alumnos, /mi-cursada, /panel, /practicas ... all 200 A dead refresh token arrived, the request REDIRECTED to /login rather than 500ing, the person signed in and browsed normally. Per the auth-gate rule that is gate-correct behaviour and the fix is a statement of evidence, NOT a code change. The error line is auth-js reporting its own failed refresh; it is logged, not fatal. THIS STILL DOES NOT EXERCISE THE BUG, and the distinction is the whole reason this WI stays open. `refresh_token_not_found` after an 8-day gap (first seen 2026-08-14, next 2026-08-22, same single user) is REFRESH-TOKEN EXPIRY. TERRA-22 is about the ~1h JWT rotation persisting into an unwritable cookie store. Different clock, different mechanism, and a recovery that works here says nothing about the one that failed there. eq 32 is unchanged: a real browser session must age past an hour on read-only navigation. ONE OBSERVATION RECORDED, NOT ACTED ON: the AuthApiError is logged TWICE for that single request, so the failing refresh runs twice in one pass. Consistent with the proxy attempting it and a Server Component attempting it again - which is expected when the token is dead, since the proxy cannot persist a rotation that GoTrue has no record of. Costs one extra GoTrue round-trip per request carrying a dead cookie, and only until the redirect. Not worth a change; recorded so the duplicate is not mistaken for two separate failures later. Deployment carrying the occurrence: dpl_FE6qyLx1V3DkxRvfuCqm9W82RS23, githubCommitSha 360b9e6, 2026-08-22 10:58 - POST-fix, so the proxy was present.
• wi-cli-venus commented · 7w ago
  SE AGREGO UN INSTRUMENTO, NO SE CIERRA NADA. v0.30.1 (273afbe). El logout silencioso a la ~1h sigue necesitando una sesion real de navegador envejecida mas de una hora en navegacion de solo lectura (eq 32), y ningun codigo de este repo puede producirla. Esta WI sigue bloqueada por lo mismo.\n\nLO QUE SI SE CERRO es la SEGUNDA via, latente, de reintroducir el mismo defecto. La exclusion 'api/' del matcher es correcta UNICAMENTE POR UNA MEDICION: proxy.ts la justifica en su propio comentario con 'la unica ruta es /api/health, que no consume sesion', y eso es cierto hoy y se degrada SIN NINGUNA SENAL. El archivo incluso nombra la falla - 'THIS IS THE ONE THAT ROTS... presentara como la API me desloguea sin nada que apunte a esta linea' - y ese aviso esta en el fuente desde v0.18.0.\n\nUN AVISO NO ES UN INSTRUMENTO: lo lee quien edita proxy.ts, y quien rompe esto esta agregando una ruta bajo src/app/api y no tiene ningun motivo para abrirlo.\n\nUNA EXCLUSION POR PREFIJO NO SE PUEDE PROBAR LISTANDO PATHS, porque cubrir paths que todavia no existen es justamente su proposito. El arm nuevo lee el FILESYSTEM y falla cuando cambia la poblacion - mismo instrumento que route-access.test.ts contra src/app y que el censo de writers de appEvents en probe-marker.test.ts. La falla ES la notificacion, y su mensaje enuncia la decision real (angostar el matcher a /api/health, o refrescar con cookies escribibles dentro de la ruta) en vez de pedir que actualicen una lista.\n\nEL NOMBRE NO ES LA PROPIEDAD: un censo de nombres seguiria pasando si /api/health empezara a leer sesion, que es el mismo defecto entrando por la puerta que nadie mira. La segunda mitad lee el fuente de health/route.ts y exige que no mencione requireAppUserPage, requireAppUserAction, getSessionUser ni createServerClient.\n\nNO ASUMI QUE DISPARA: cree src/app/api/__censusprobe/route.ts, corri la suite, vi el arm 10 en rojo nombrando '/__censusprobe', borre el directorio y confirme 10/10 verde con src/app/api conteniendo solo health. 307/307 unit, tsc limpio.
• wi-cli-venus assigned · 7w ago
  coder-terra-ca
• wi-cli-venus note · 6w ago
  THIS ROW IS BLOCKED ON A QUESTION THAT WAS ANSWERED THIRTEEN DAYS AGO, AND THE ANSWER DID NOT RESOLVE IT. blockedReason cites eq 32 as the pending item. I read eq 32 rather than its status line: status answered, answered_at 2026-08-18, answered by Elazar. He did NOT run the aged-session test. He redirected: "terra is part of the evolutiva family apps. There is a standard for logging telemetry using host venus with its own app, no vercel.com and no supabase, look into WEBUSAGE-1 for telemetry.pensanta.com, maintainer coder-enamel-cc". ANSWERED IS A STATUS, NOT A RESOLUTION, and that is the whole defect here. The question left the open queue without the need being met, so nothing surfaces it any more: a reader who checks the cited blocker sees "answered", infers movement, and stops looking. The row has therefore been blocked on NOTHING ANYONE WILL EVER ACT ON since 2026-08-18. Found by db02-terra-cc in the blocked-row audit; I re-read eq 32 myself rather than take the summary. RE-FILING THE SAME ASK WOULD BE IGNORING HIS ANSWER, so I did not. Instead I checked whether the path he named actually exists for terra: grep across src/ and shared/ for telemetry.pensanta, webusage and WEBUSAGE returns ZERO hits. Terra is not wired to telemetry.pensanta.com at all. SO THE REAL BLOCKER IS NOT A DECISION AND NOT A HUMAN FAVOUR - IT IS AN UNBUILT INTEGRATION WITH A NAMED OWNER. Elazar's answer is a routing instruction that nobody executed: terra must report to telemetry.pensanta.com (maintainer coder-enamel-cc, tracked as WEBUSAGE-1), and until it does there is no instrument that could observe an aged session expiring on read-only navigation. Restating the block in those terms is what makes it actionable, because "waiting for Elazar to leave a tab open for 65 minutes" is a request he already declined in favour of a different mechanism. WHAT DID NOT CHANGE: the underlying defect is untouched and unreproduced. A real user was silently logged out about an hour after login on 2026-08-14 while only browsing, and had to sign in three times with no message. The instrument shipped for it has never fired, because nobody has been logged in that long under observation. Terra's runtime logs held five application lines across seven days and they expire, so a first natural occurrence with nobody watching loses the evidence and leaves the row reading as though the defect never happened. NEXT, and it is a cross-repo dependency rather than terra work: confirm with coder-enamel-cc whether terra is in scope for WEBUSAGE-1 and what wiring terra owes. Do NOT re-file eq 32's ask. Do not close this row on the reframing - the reframing only makes the block honest.
• wi-cli-venus blocked · 6w ago
  El arreglo salio en 9e9911b v0.18.0 y esta verificado presente en el build desplegado. El BUG sigue sin confirmarse: ninguna sesion viva envejecida fue ejercitada. LO QUE ESPERA NO ES UN FAVOR DE ELAZAR - eq 32 YA FUE RESPONDIDA el 2026-08-18 y la respuesta ruteo el asunto a telemetria en venus via WEBUSAGE-1 (mantenedor coder-enamel-cc) en vez de una prueba manual. Hasta que esa integracion exista no hay INSTRUMENTO capaz de observar una sesion envejecida expirando en navegacion de solo lectura. O sea: trabajo sin construir con dueno nombrado, no una pregunta pendiente. La linea anterior de este campo decia 'blocked on eq 32 with Elazar - a real browser session must age past an hour' y era ESTALE contra los propios eventos del row, que ya registraban la respuesta; yo mismo le pedi a Elazar esa prueba manual el 2026-09-01 confiando en esta linea en vez de leer los eventos, y la retire. Encontrado por coder-terra-ca en una auditoria backlog-contra-fuente; verificado por mi en el row antes de editar.
• wi-cli-venus assigned · 5w ago
  coder-terra-cc
• wi-cli-venus assigned · 5w ago
  coder02-terra-ca
• wi-cli-venus assigned · 5w ago
  coder-terra-cc
• wi-cli-venus note · 4w ago
  MEASURED BY coder-terra-cc 2026-09-12, read from the row's EVENTS not the blockedReason, and it CONTRADICTS the blockedReason line. That line says no instrument can observe an aged session expiring on read-only navigation. That is TRUE for catching it in the wild, which is what WEBUSAGE-1 is for, and FALSE for a controlled run: the mechanism is already fully specified in this row - sign in, wait past jwt_exp=3600 touching NO Server Action (any action rewrites the cookie and mitigates the bug), then navigate a read-only Server Component route. A stored cookie jar makes that scriptable with no telemetry at all. So a dedicated test user with a stored session DOES reproduce this row. THE CATCH IS WORSE THAN THE INSTRUMENT AND THIS ROW MUST NOT BE SOLD AS RETIRED WITHOUT IT: the fix already shipped in 9e9911b v0.18.0 and is verified present in the deployed build, so a PASSING aged-session run proves nothing - a control that has never been seen to fail is a green line, not a control. The only surface the proxy excludes is /api/, and /api/health consumes no session, so the failing path cannot be forced on the deployed build. Verifying this honestly means running the aged-session script against a build with the proxy DISABLED first, observing the silent logout, and then running the identical script against production. That is a deliberate extra step, not a side effect of having a test user. PREREQUISITE ONLY ELAZAR CAN SUPPLY: sign-in is Google OAuth, so a dedicated test user needs a real Google account able to complete consent plus a terra membership row. No agent can create that. The resulting stored session is a CREDENTIAL - it lives in the git-ignored .llmmsg-env overlay, never a tracked file.
• coder-terra-cc note · 2w ago
  MARKER-t22-4h-muldx A ~4h-old session on the DEPLOYED build survives read-only Server Component navigation. proxy-general-cc signed in ~10:51 ART for the TERRA-252 uploads and at ~11:53 ART (about 4h later, past jwt_exp=3600 by a factor of four) navigated to /practicas: the full Practicas de la catedra list rendered, no bounce to /login, still elazar.pimentel@pensanta.com. It submitted nothing - I asked explicitly for read-only, because any Server Action rewrites the cookie and mitigates the very bug in question, which would have destroyed the answer. WHAT THIS IS NOT. It is not verification and this row does not move to done on it. The fix shipped in 9e9911b v0.18.0 and is present in the deployed build, so a PASSING aged-session run is exactly the green line this row's 2026-09-12 note already refused: a control that has never been seen to fail. Forcing the failure still needs a build with the fix disabled plus a dedicated test identity, and that prerequisite is unchanged and still Elazar's. WHAT IT IS, and it is worth having three days out: a BOUND on the demo-day risk. The 1/10 jornada is 30 minutes. The failure mode this row describes triggers past one hour. A session four times that age held on the exact navigation pattern a docente in the room would produce. So TERRA-22 is not a live risk to 1/10, which is a different claim from the bug being fixed, and only the first one is evidenced.
• db-enamel-ca verified · 1w ago
  Standing SELECT-only read 2026-10-06 since v0.18.0 cutoff 2026-08-16T09:28Z: 1233 Terra appEvents, 0 with nonblank sessionId, including 100 signInCompleted. Therefore session count and same-session >60m survival are NOT measurable on this rail. Proxy only: 51 distinct signed-in actorUserIds; 6 have any later event >60m after first recorded signInCompleted (27 later rows), but only 3 have a later non-signin event (12 rows), none within 24h. These could be separate sign-ins and do not verify an aged session. 0 Terra level error/warn with httpStatus=401; 0 rows with a session-expired failureCode since cutoff. No data write.
• coder-terra-cc note · 1w ago
  MK22Q. Coverage statement, 2026-10-06 (db-enamel-ca read). Window: since 2026-08-16T09:28Z (v0.18.0). 1233 terra appEvents, 0 warn/error with httpStatus 401, 0 session-expired failureCodes. A session-level claim is NOT possible: every row has a blank sessionId. As a proxy, 6 of 51 signed-in actors have any event more than 60m after their first sign-in, and none of those is a non-sign-in event within 24h, so a long-lived session cannot be told apart from a later new one. Not 'fixed'. The instrument is TERRA-270, which has 0 accepted events so far.
• coder-terra-cc note · 1w ago
  MK22PROD. Producer bug, not a coverage limit. The only appEvents writer, logEvent in src/lib/logger.ts:138, never inserts sessionId, requestId, ip, userAgent or traceId. The column list ends at actorUserId and appVersion. command grep -rn sessionId src/ finds zero producers. So '0 session-expired failures' is a statement about an empty column. Fix (coder lane): take request headers already in scope (headers() at logger.ts:74) for requestId (x-vercel-id) and userAgent, and the GoTrue session_id claim from the session JWT, labelled as claimed. Class-A design ping to audit before implementing, because it reads the auth cookie.
• coder-terra-cc decision · 1w ago
  MK22FORK pmmaster muwbi2bd7a02: before building the producer fix, decide populate vs drop. venus resolved the identical appEvents.path defect by DROPPING the column. appEvents is a shared enamel object, so a drop is db-enamel-cc's GO. Next: ask db-enamel-cc whether any enamel reader needs sessionId/requestId/ip/userAgent/traceId before wiring the logger. No code until that answer.
• db-enamel-ca decision · 1w ago
  Enamel shared-object read 2026-10-06 (DM db-enamel-ca-muwc8bv0lait): live resolveScopedAppEventsSecurity projects requestId, sessionId, traceId, ip, userAgent; resolveScopedAppEventsErrors24h projects traceId; live fn_scanAppEventsForPii reads ip/userAgent and timer/alarm uses the scan. No Enamel app/alert consumer found for requestId/sessionId/traceId values. All five NULL in 87 Enamel and 1297 Terra rows. Shared-object decision: populate sessionId only for TERRA-22 future signed-in survival measurement, using a new non-secret synthetic per-session correlator, never a GoTrue token/cookie or personal identifier. Leave requestId/traceId NULL without a named consumer; keep ip/userAgent NULL under standing shared-appEvents personal-data ban. No GO to drop any column: shared function contracts, traceId index, and live PII detector dependencies exist. This is a design decision, not implementation or observed aged-session coverage.
• coder-terra-cc decision · 1w ago
  MK22SESSREF db-enamel-ca shared-object answer (db-enamel-ca-muwc8bv0lait): populate sessionId ONLY with a generated non-secret synthetic correlator; requestId/traceId stay NULL (no consumer); ip/userAgent stay NULL (PII ban, live detector inputs); drop BLOCKED (shared function output contracts, traceId indexed). Design ping sent to audit-terra-ca: callback mints an httpOnly random terraSessionRef cookie; logEvent writes it fail-soft to sessionId; sign-out clears it; it outlives the GoTrue session so post-expiry rows correlate. Class-A, no code until audit replies.
• coder-terra-cc unblocked · 1w ago
  cleared: El arreglo salio en 9e9911b v0.18.0 y esta verificado presente en el build desplegado. El BUG sigue sin confirmarse: ninguna sesion viva envejecida fue ejercitada. LO QUE ESPERA NO ES UN FAVOR DE ELAZAR - eq 32 YA FUE RESPONDIDA el 2026-08-18 y la respuesta ruteo el asunto a telemetria en venus via WEBUSAGE-1 (mantenedor coder-enamel-cc) en vez de una prueba manual. Hasta que esa integracion exista no hay INSTRUMENTO capaz de observar una sesion envejecida expirando en navegacion de solo lectura. O sea: trabajo sin construir con dueno nombrado, no una pregunta pendiente. La linea anterior de este campo decia 'blocked on eq 32 with Elazar - a real browser session must age past an hour' y era ESTALE contra los propios eventos del row, que ya registraban la respuesta; yo mismo le pedi a Elazar esa prueba manual el 2026-09-01 confiando en esta linea en vez de leer los eventos, y la retire. Encontrado por coder-terra-ca en una auditoria backlog-contra-fuente; verificado por mi en el row antes de editar.
• coder-terra-cc completed · 1w ago
  SHA 4f2dd6d526d8, version 0.31.99. PTD: live /api/health version 0.31.99 == REMOTE package.json on main (gh api, read at check time), commitSha 4f2dd6d, deploymentId dpl_CN3ELpAdFGhFjJWyGkPqdht3P3Qb, Vercel inspect status Ready, target production, served on the prod origin; runtime log stream scanned ~40s with zero error/warn/500 lines. Audit SOURCE PASS audit-terra-ca-muwcu98ea908; push GO pmmaster muwcv24i3tre. COVERAGE (pmmaster muwd23eoyuyy): STANDING QUERY - key on an organic authorized signInCompleted row and check that a normalized sessionId is present on THAT row only; presence/aggregate checks only, no actor IDs, no tokens. PER-WRITER STATUS: logger path, cirugia create, confirm and retire are each UNEXERCISED INDIVIDUALLY until an organic action occurs; absence of such an action is not a defect. STAYS UNEXERCISED until directly observed: full OAuth callback header behaviour, the literal Set-Cookie coexistence with GoTrue's cookie on a live response, and the Server Action (signOut) cookie deletion. A later request carrying the same sessionId is an INFERENCE of same browser session, not proof. Exercised: unit tests incl. real NextResponse Set-Cookie serialisation and a whole-tree appEvents writer census (forced red).