Client cannot confirm a cirugia: isConfirmedByClient has 3 readers and no writer, and it blocks every guard on the empty population
isConfirmedByClient has THREE read sites and ZERO writers - no server action, no UI control, nothing in src/lib or src/components. Measured 2026-08-09, re-read live 2026-08-16 by db-terra-cc, unchanged: 35 cirugias, 0 confirmadas. The client principal is logged in and has an account, and what the app shows them is a read-only banner asking them to confirm, with no control to do it with. That is not a missing feature request, it is a shipped instruction the user cannot follow, and it has sat unowned since 2026-08-09 because it was recorded as a gap rather than assigned. WHY IT IS P1 AND NOT COSMETIC: this writer is the ONLY thing that would ever seed terraPracticas. Every guard on terra's empty population - the whole of TERRA-46 population A, the archive-context guards, the delete guards - is untestable until a practica exists, so an unowned UI control is currently the blocker on a security suite nobody can exercise. Two findings, one cause. SCOPE: build the writer and the control the banner already promises. Do NOT invent a new role list for who may confirm - key the gate to the same admission that renders the banner, the constraint from TERRA-17. Puia's group value is still unsettled on eq 34 (client vs bedel), which does NOT block this: derive from the admission, not from a role name, and the eq answer changes nothing in the code. Confirmation writes to a shared-DB row under terra's appKey, so treat it as Class-A and take the pre-push audit diff review.
Questions
Activity
-
Class-A DESIGN sign-off PASS from audit-terra-ca (audit-terra-ca-msvsskrbb7lj, hub 2026-08-16T09:44Z). Design-only: pre-push diff review and the rollback-only SQL proof with no-residue assertion are still owed, and no applied-state or deploy conclusion follows. Shape signed off: one-statement UPDATE RETURNING feeding the appEvents INSERT; capability re-read as a literal DB-side membership EXISTS inside that UPDATE; no Node transaction, lock or new function; UX precheck retained with a comment stating the EXISTS is the actual defence; closed reason set with no companion free text; probe-free boundary. Audit INDEPENDENTLY read the role constants rather than accepting the design's word: CLIENT_ROLES = [client, admin, bedel] at src/lib/route-access.ts:57, and /cirugias stays the wider CATALOG_ROLES reader at :54/:95. That is the confirm gate being narrower than the banner's render admission, which is the departure coder-terra-cc raised against pm's original instruction and which pm accepted. CONSEQUENCE PM HAD ARGUED AND CAN NOW STATE AS MEASURED: eq 34 (Puia = client vs Elazar's 2026-07-30 bedel ruling) changes no TERRA-52 code, because CLIENT_ROLES admits BOTH values. Previously that was a design argument from deriving the gate from admission; it is now a property of the constant audit read.
-
CORRECTION to this row's audit-finding event of 12:45:54Z, made by the same author. I wrote that eq 34 changes no TERRA-52 code because CLIENT_ROLES admits both client and bedel. The code claim is true; the sentence was used as if it meant the eq is inert for this WI, and it is not. Puia holds the ONLY live client membership. eq 34 asks whether Puia is bedel or docente. bedel is admitted - and is the single admitted role with ZERO live carriers, so it is precisely the arm the pre-push DB proof cannot exercise without manufacturing its own fixture (ruled: report unexercised, do not manufacture). docente is NOT admitted at all. So the two candidate answers are: sole live user moves onto the one untested arm, or sole live user loses the capability and the feature ships with no live user. NO CODE CHANGES AND NO RISK CHANGE ARE DIFFERENT CLAIMS. Collapsing them is what made an open ruling look irrelevant to a shipping feature. Consequence recorded on eq 34 itself so the decision is made with it visible: exercising the bedel arm is a precondition on APPLYING eq 34, not on pushing TERRA-52.
-
Pre-push diff review PASS from audit-terra-ca (audit-terra-ca-msvtn02syyj0), issued against the 907-line final diff /resource/terra/reviews/2026-08-16-terra52-diff-final.txt and confirmed by me directly rather than taken from the coder's relay - the diff was superseded mid-review (817 -> 907 lines) and a GO is scoped to the revision that was read, so a PASS on the earlier one would not have covered what shipped. LIMITS CARRIED VERBATIM FROM THE PASS, not softened: bedel and jtp arms unexercised; inactive/deleted cases are fixture-made; evidence is rollback-only SQL, NOT deployed browser or runtime proof. TERRA-54 and TERRA-55 stay separate rows. Added by coder-terra-cc and due rather than declared: nothing in either push exercised the confirm flow through a browser. The first real confirmation is still unobserved, and it is also what starts TERRA-58's exposure clock. Re-measure query now lives in the terra_13 comment: SELECT count(*) FROM "terraCirugias" WHERE "isConfirmedByClient" - 0 of 35 at 13:08Z.
-
Class-A push-to-done complete. c6eecc7, v0.20.9 -> v0.21.0. Pre-push hook: 171/171 tests, eslint clean, tsc clean, next build compiled. 6 files, 863(+)/9(-). Committed set read out of the push output rather than predicted from the --only argument: ADDED src/lib/cirugia-confirm-core.ts, src/lib/cirugia-confirm-core.test.ts, src/lib/cirugia-confirm-actions.ts, src/components/cirugia-confirm-control.tsx; MODIFIED package.json, src/app/cirugias/page.tsx. Live read-back on terra-enamel.pensanta.com/api/app-version at 13:06:56Z: version 0.21.0, dpl_5GBw73pA2m1m5ctt9TwJebWZ9bFr, dbOk true.
-
Client confirm/unconfirm writer live: c6eecc7 v0.21.0, audit PASS on the final diff, live-version verified dbOk true