TERRA-19 instrument fires once per bucket from the Server-Component path via console.error, proven by injected unit + build only: Vercel capture NOT established
TERRA-19 shipped 8cea776 v0.16.7 with a green four-leg Class-A PTD, but the PTD discriminates nothing about the instrument: the only request that deployment served was a health probe on a Route Handler, while the changed code is in the Server-Component path of createClient. setAll catch has never executed. Zero warn lines is the expected reading whether the instrument works or is silently broken. THE UNTESTED CLAIM: the single runtime log line is Vercel REQUEST logging, NOT application console output. Nothing has shown that a console.warn emitted SYNCHRONOUSLY from inside setAll is captured. That capture assumption is what justified dropping after() - a load-bearing assumption that survived a full PTD untouched because each leg measured a different object. WHY THIS IS NOT "WAIT FOR A REAL EXPIRY": waiting conflates two separable questions - does the instrument capture, and does the defect occur. Only the second needs a user. Test the first deliberately and now. Success criteria: demonstrate whether a synchronous console.warn from a Server-Component render path appears in Vercel runtime logs for this project, with a must-fail control (something that should NOT appear). If capture fails, after() or an equivalent post-response boundary comes back and TERRA-19 needs a follow-up - audit already flagged that setAll is synchronous and an unawaited write can be dropped when the response ends. URGENCY: with ~3 users ever logged in, the first natural ~1h read-only expiry may fall outside the Vercel log retention window, so the first real evidence can be LOST before anyone looks. That is the TERRA-3 dependency with a concrete loss path rather than an abstract one.
Questions
Activity
-
Plane correction SHIPPED be8e838 v0.16.8 (audit PASS msvg24f4j7jw + PM GO msvg0q4hqg5j carried in the commit). dpl_ALDVqSzyrfdci8eaE3eg5oo6o3Uw READY, githubCommitSha matches, aliased to terra-enamel.pensanta.com with aliasError null, /api/health returns v0.16.8 AND the same deploymentId (not merely a matching version string), dbOk true, build errorsOnly zero events.\n\nSTATUS UNCHANGED BY THIS SHIP: shipped-and-unproven. The signal now sits on a plane with MEASURED capture for this exact call shape - that is what the change bought and it is not proof. The instrument has still never executed.\n\nCLOSE CONDITION, deliberate: a natural persist failure emits the line, OR the live test in eq #32 runs. coder-terra-cc flagged that they COULD force it by exercising an expired session and declined to on their own initiative; PM refused it for any account other than Elazar's own - terra's accounts belong to real people at FOUBA and no agent signs in as them. eq #32 asks Elazar to do it with his own account (idle 65+ min, then navigate WITHOUT submitting a form, since any Server Action rewrites the cookie and masks the defect).\n\nWHY THIS IS TIME-SENSITIVE rather than eventual: terra's runtime logs held FIVE application lines across seven days total and they expire. The 08-14 evidence sat two days from the window edge and nobody had looked. If the first real occurrence expires unread, the instrument produces nothing and the WI reads as though the defect never occurred.
-
REFRAMED 2026-08-16 by pm-terra-cc as part of the TERRA-22 sequencing ruling. This WI was waiting on a NATURAL occurrence of the failing cookie write. It should not be. WHY IT CAME UP: coder-terra-cc flagged that fixing TERRA-22 likely FORECLOSES this WI permanently - middleware refreshes on a writable-cookie path, so setAll stops throwing and the TERRA-19 instrument goes quiet by design. Presented as a genuine fork between fixing the bug and keeping the instrument able to prove itself. RULING: not a fork. Capture proof does not require the condition to arise on its own, it requires the write to FAIL. That is injectable - an unwritable cookie store in a test exercises the swallow on demand. An injected-effect fixture is the better instrument even with TERRA-22 unfixed, because it does not decay, does not depend on a log plane, and does not wait on production to reproduce something we are about to remove. Same reasoning that made TERRA-21 ship an armed self-test instead of a transcript measurement. SO THIS WI IS NOT BLOCKED BY TERRA-22 SHIPPING and must not be closed as unprovable when the natural signal goes quiet. If the injected fixture turns out not to be constructible - the swallow sits somewhere an injected store cannot reach - that IS a real fork and comes back to pm rather than being absorbed as a limitation. See memory untestable-code-needs-injected-effects: must-fail control, and count CALLS not returns.
-
TERRA-19 instrument fires once per bucket from the Server-Component path via console.error, proven by injected unit + build only: Vercel capture NOT established
-
Shipped f56f787 on audit's PASS (msvmek3rqduu), no PM GO waited on - first item under the standing rule-34 change. PTD read back not recalled: /api/health 0.18.2 = package.json 0.18.2, dpl_5BPvPxFxSpjUfVhqAdUo7vx7cshk, dbOk true, deployment READY, production, gru1, aliased to terra-enamel.pensanta.com, githubCommitSha f56f787b5d394019ecfedefc58799ed21107b248. Committed files read from push output: session-cookie-core.ts + its test added, server.ts and package.json modified. EVIDENCE LIMIT, verbatim from coder-terra-cc and audit, and it is the reason the title was rewritten before this close: injected unit and build proof ONLY. Establishes that the instrument FIRES, once per bucket, carrying no credential. Establishes NOTHING about Vercel capture, whether the condition occurs in production, whether the injected error matches what Next actually throws, or anything about TERRA-22's outcome or aged sessions. TITLE REWRITTEN TWICE OVER, and the second was mine to catch. coder-terra-cc flagged that the old title said console.warn while the code deliberately ships console.error - 7d of runtime logs group to a single error bucket with no warning bucket at all, so warn would have been an assumption dressed as a signal, and closing on the old title would have recorded that terra verified a path it consciously did not build. The larger over-claim was in the same title and nobody flagged it: it read "Verify ... into Vercel runtime logs". Vercel capture is precisely what this work does NOT establish. So the old title named the one conclusion the evidence limit rules out, and would have closed as a completed verification of it. Both halves are now in the title rather than the body. THIRD TITLE CORRECTION IN ONE SESSION (TERRA-37, TERRA-38, this one). The pattern is mine and it is now explicit: I write the title at FILING, when it states a hypothesis, and treat the close as a body-writing step. A closed WI is read by its title. From here the close begins by rewriting the title against the finding, and only then writes the body. WHAT IS STILL OPEN AND IS NOT THIS WI: whether the instrument's output reaches Vercel at all. That is captured-but-unemitted vs never-captured - the same indistinguishable-empty shape that motivated using the single error bucket in the first place - and it needs a production occurrence or a deliberate production trigger, neither of which an injected unit test can supply.