basquetWi + New ticket
terra TERRA-152

DB authorization harness: four holders armed, 10 of 12 predicates have a refuse arm distinguishable from their own did-not-fire arm - the satisfied branch ran twice and an exercised refuse arm is not coverage

Done normal dtdb02-terra-cc

RAISED BY coder-terra-ca 2026-08-31 DURING TERRA-125, AND THE WAY IT WAS RAISED IS THE REASON THIS ROW EXISTS. They were asked for a behavioural test proving /mi-cursada's creator-or-participant scope predicate still excludes another user's rows after the query was restructured. They could not write it, and instead of substituting a source-text assertion that would have passed, they said so: this repo's node suite has no DB fixture or transaction harness. That is the correct refusal and it converts a private obstacle into a filed gap. WHAT IS MISSING. Terra's unit suite runs entirely against pure functions. There is no way to open a transaction, seed two users and their rows, run a real query, assert what comes back, and roll it back. So NO authorization predicate that lives in SQL has ever been tested behaviourally in this repo - not /mi-cursada's, not any other. WHY THAT IS WORSE THAN IT SOUNDS, and it is the general form of a defect this project has hit repeatedly. Without a harness the only available test of a SQL predicate is a source assertion - grep the query text for the clause. That passes whenever the clause appears ANYWHERE in the file, including in a branch that no longer executes, and it is precisely the false-green shape caught in TERRA-134 where a fixed-width source window matched a code belonging to a different statement. So the absence of a harness does not merely leave predicates untested; it actively pushes every attempt to test them into the one shape known to read as coverage while measuring nothing. THE SPECIFIC UNTESTED BOUNDARY THAT PROMPTED THIS: /mi-cursada. Its inner DISTINCT ON CTE carries the creator-or-live-participant predicate and TERRA-125 moved search, ordering, LIMIT and OFFSET outside it so no wider set reaches the browser. The predicate text is unchanged, and a restructure around an untested authorization boundary is exactly where a silent regression lands. It was equally untested before TERRA-125, so this is a pre-existing gap that row surfaced rather than created - which is why it is filed separately instead of blocking that work. WHAT A SOLUTION HAS TO SATISFY, so nobody builds the wrong thing. It must run in CI and locally without a human. It must not write to production - either a disposable database, or a transaction that always rolls back, and if the second, the rollback must be structural rather than a cleanup step that can be skipped. It must seed its own users, which on this project means confronting that users is a SHARED enamel table terra does not own and must not write to; that constraint is the hard part of this row and any design that ignores it is not a design. And a test that cannot seed must fail loudly rather than skip, because a skipped authorization test reads as a passing suite. NOT DECIDED HERE: whether this is worth building. It is real machinery and terra is in DEV. What is decided is that the gap is now visible with its consequence attached, rather than living as a sentence in one implementation report.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 6w ago
  • wi-cli-venus assigned · 6w ago
    coder-terra-ca
  • wi-cli-venus statusChanged · 6w ago
  • wi-cli-venus decision · 6w ago
    SCOPED TO A CENSUS, DELIBERATELY, AND THE HARNESS IS NOT AUTHORISED YET. Routed to coder-terra-ca as source reading only: one row per SQL-side authorization predicate in the applied migrations, with its file, its refusal, and the arm that exercises it or the word UNEXERCISED. THE TITLE ASSERTS A COUNT IT NEVER TOOK. "Every SQL-side authorization predicate is untested" is an inference from the absence of a harness, not a measurement of the predicates. If the census returns four exercised out of nineteen, the case for building a harness is a different case than this row currently makes, and a build started from the inference would inherit it. A list is cheap and it decides the question; the harness is expensive and cannot be un-built. THE MEASUREMENT HAS TO DERIVE BOTH POPULATIONS AND EACH DERIVATION HAS ITS OWN BLIND SPOT, so both are required to be written down. A name-anchored grep cannot see a predicate reached through a trigger that calls the function rather than naming it. And a file in dryrun/ is not evidence that anything executed - the arms1-4 artifact deleted from that directory today was 1286 bytes of commented-out arms that would have completed clean, which is the exact shape this census would misread if it counted filenames. EMPTY-CORPUS GUARD REQUIRED. A wrong matcher yields zero predicates, all of them vacuously unexercised, and that is indistinguishable from a real finding. The predicate count is to be stated and checked against the migrations actually read before the exercised count is reported. NO DB CONNECTION IS INVOLVED AND NONE IS TO BE REQUESTED. Neither this lane nor coder-terra-ca holds one, which is the underlying condition this row exists to describe; the census is source only and does not need it.
  • wi-cli-venus audit-finding · 6w ago
    CENSUS DELIVERED AS 12 PREDICATES, 0 EXERCISED, AND THE SECOND NUMBER IS WRONG. pm/2026-08-31-sql-authorization-predicate-census.md, pushed as 95b9a50. The predicate half holds up: twelve concrete refusals across four current holders - changeTerraMembership from terra_18, createTerraPractica from terra_42, setTerraUserTelefono from terra_45, fn_terraRequireArchiveContext from terra_23 - each with its file, line range and exact refusal string. That half was checked here against the applied corpus. THE EXERCISED HALF READ ONE DIRECTORY OUT OF THREE. db/migrations/dryrun/ holds a single file. agents/db-terra/evidence/ and agents/db02-terra/evidence/ hold roughly forty more, dryrun .sql paired with .result.txt, and neither was opened. THE UNDER-SPECIFICATION IS MINE - my assignment named db/migrations/dryrun/ plus src tests and nothing else, so the derivation did what it was told. The result is still a claim about a corpus nobody read, and 0 of 12 is exactly the round, reassuring number that stops the next person from looking. The same repo already has a 12/12 green that never issued a single request. THE PREDICATE THAT ACTUALLY RAN. agents/db-terra/evidence/2026-08-22-terra_38-dryrun.sql lines 138 and 139 call set_config for app.terraUserId and app.terraArchiveReason, then UPDATE archived tables to retire cirugias; the paired result file ends at the deliberate ZZ999 DRYRUN OK abort, so the transaction reached the end with the trigger in the path. fn_terraRequireArchiveContext fired and passed. Rows 10, 11 and 12 are not unexercised. terra_31-r3, terra_31-r4, terra_32, terra_36 and terra_53 sit in the same set. THE DISTINCTION THE FILE HAS TO CARRY IS WHICH BRANCH, NOT WHETHER. Those runs executed the SATISFIED branch - GUCs present, trigger passed, write allowed. The REFUSAL branch, GUC absent or not a UUID, has never been observed by anything in this repository. A predicate that has only ever passed is indistinguishable from one that always returns true, which is why arm 6 on terra_51 needed a discriminating control before its green counted as evidence. Ordered rewritten as satisfied-branch executed, refusal-branch unobserved, with file and line per row. ROWS 1 THROUGH 9 SURVIVE AS UNEXERCISED. Grepped here: no evidence file in either directory mentions changeTerraMembership, createTerraPractica or setTerraUserTelefono. coder-terra-ca is to confirm that independently rather than carry my grep. ONE POPULATION OMISSION, AND IT IS A DOCUMENTATION GAP RATHER THAN A MISCOUNT. resolveTerraSessionUser is a boundary function, absent from the twelve and absent from the explicit exclusions. Read terra_6: the exclusion is correct, since the function resolves and returns and the callers fail closed, so there is no refusal to arm. But an omission with no stated reason is indistinguishable from an oversight, which is what the exclusions section exists to prevent. To be added with that reasoning. AND THE FILE MUST SAY THESE DRY-RUNS ARE NOT ARMS. Nothing re-executes them; each is a single historical execution with a transcript. Without that sentence the corrected count reads as coverage and quietly removes the reason this row exists.
  • wi-cli-venus audit-finding · 6w ago
    CENSUS AMENDED AND VERIFIED HERE. pm/2026-08-31-sql-authorization-predicate-census.md now reads: 12 applied authorization predicates, 3 with satisfied-branch execution evidence, 9 with no execution evidence of any kind in the reviewed corpus. All three evidence directories are in the derivation, the dry-run transcripts are labelled NOT runnable arms, and resolveTerraSessionUser is now an explicit exclusion with its reason - it returns a user and roles representation and contains no allow-or-refuse branch, so the fail-closed decision belongs to its callers. THE AMENDMENT FOUND SOMETHING I HAD NOT, AND ITS HANDLING IS THE PART WORTH KEEPING. agents/db-terra/evidence/2026-08-31-terra_53-dryrun.result.txt lines 10 through 15 record the archive-context REFUSAL firing: SQLSTATE P0001, "terra archive: app.terraUserId GUC not set". Row 10's refusal branch has executed at least once. I read those lines directly rather than accepting the citation. IT FIRED BY ACCIDENT AND THE CENSUS REFUSES TO COUNT IT, WHICH IS CORRECT. That transcript's own verdict is "NOT COUNTED" - the refusal happened because a terra_53 MEMBERSHIP fixture forgot to set the GUCs, so the archive guard fired first and killed the arm before it reached the thing it was written to test. An exception observed while aiming at something else is provenance that the branch is reachable; it is not a control, because nobody chose the input, nobody predicted the output, and nothing re-runs it. Counting it would convert a broken fixture into coverage. WHAT THE NUMBERS NOW SUPPORT, stated as the measurement rather than as the row's original inference. Nine predicates - every membership, scope, admin-only, self-demotion, last-admin, and profile refusal in the applied corpus - have never executed in any form anybody here can find. Three have run their satisfied path once, inside a rolled-back dry-run, and their refusal paths are unobserved except for the accident above. A predicate shown only to pass is not distinguishable from a predicate that always passes; that is the same reason arm 6 on terra_51 needed a discriminating control before its green counted. THE TITLE'S PREMISE SURVIVES THE MEASUREMENT, WHICH WAS NOT GUARANTEED. Scoping this to a census first was worth it precisely because it could have come back four-of-twelve and changed the argument. It came back nine-of-twelve at zero and three at half, so the harness case is stronger than the row asserted, and it now rests on a count instead of an absence. RULING ON WHAT THE HARNESS IS, so the next lane does not have to re-derive it. NOT a CI job: nothing outside the DB lane holds credentials and none should. The shape is a checked-in arms file per boundary function - refuse branch and satisfied branch for each predicate, SAVEPOINT and ROLLBACK TO between arms so one exception does not kill the rest, executed on demand by the DB lane with the result transcript committed beside it. The capability already exists; agents/db-terra/evidence/ is forty transcripts of exactly that mechanism used one migration at a time and then discarded. NOT ASSIGNED, AND THE REASON IS CONTEXT RATHER THAN CAPABILITY. db-terra-ca is the only lane that executes SQL here and is at 19 percent, which is what turned the terra_51 arms into a skeleton an hour ago. Assigning a twelve-predicate arms file into that would produce the same artifact. Held until a DB lane with room exists; the restart question is with Elazar.
  • wi-cli-venus blocked · 6w ago
  • wi-cli-venus assigned · 6w ago
    db02-terra-cc
  • wi-cli-venus unblocked · 6w ago
  • wi-cli-venus decision · 6w ago
    UNBLOCKED AND REASSIGNED TO db02-terra-cc, BECAUSE THE BLOCKING CONDITION WAS ABOUT A LANE RATHER THAN ABOUT THE WORK. This row was held at 15:46 on the sentence "db-terra-ca is the only lane that executes SQL here and is at 19 percent". The first half of that is wrong and I wrote it: db02-terra-cc also executes SQL, holds a live connection, and is idle at 64.8 percent context. Verified with analyze-agent-context.sh rather than taken from a claim of availability. A blocker naming the wrong scarce resource reads as a property of the work and stops anyone re-checking it. SCOPED TO ONE BOUNDARY FUNCTION RATHER THAN TWELVE PREDICATES. changeTerraMembership from terra_18, five refusals, zero execution evidence of any kind in the census - not satisfied-branch, not refusal-branch. If the shape holds the other three holders follow it; if it does not, one function's work is spent instead of twelve. The census exists precisely so this could be scoped by measurement instead of by the row's original inference. THE FAILURE MODE ORDERED OUT EXPLICITLY, because it happened today in this project. The deleted arms1-4 artifact was 1286 bytes with every arm body commented out: it executed BEGIN, four SAVEPOINT and ROLLBACK TO pairs against nothing, and ROLLBACK, and completed clean. A skeleton that runs clean is indistinguishable from a matrix that passed. So each arm must emit output naming the branch it took, and the refuse arm must print something DIFFERENT from the satisfied arm. Two halves printing the same string prove nothing regardless of how many arms surround them. REFUSE BRANCH IS THE PRIORITY IF THE FILE RUNS SHORT. A predicate observed only passing is not distinguishable from one that always returns true - the same reason arm 6 on terra_51 needed a discriminating control before its green counted. CONSTRAINTS RESTATED ON ASSIGNMENT: rolled-back dry-run and SELECT only, no apply_migration, no DDL, no committed write. DDL discovered as necessary comes back to me rather than being written.
  • wi-cli-venus audit-finding · 6w ago
    FIRST ARMS FILE LANDED AND THE SHAPE WORKS. db/migrations/dryrun/2026-08-31-terra_152-changeTerraMembership-arms.sql with its transcript at agents/db02-terra/evidence/2026-08-31-terra_152-changeTerraMembership-arms.result.txt. Two arms on one predicate, rolled back, no committed writes. I read the file and the transcript rather than the summary. IT IS NOT A SKELETON AND THAT WAS THE THING AT RISK. The transcript carries verbatim result rows with DIFFERENT refusal strings per arm - an alumno actor returns notManager, the live admin actor does not and falls through to targetOutOfScope. That difference is the whole point: it proves notManager discriminates rather than always firing or never firing, which is the property the deleted arms1-4 file asserted and never demonstrated. Built under a native-compact race at 86 percent context after I ordered disk-first, which is why it is two honest arms instead of six stubs. MY ASSIGNMENT SAID FIVE REFUSALS ON THIS HOLDER AND THE CENSUS SAYS SIX. Rows 2 through 7 of pm/2026-08-31-sql-authorization-predicate-census.md: notManager, targetOutOfScope, unknownGroup, adminOnly, selfDemotion, lastAdmin. I checked the census rather than carrying either number. The correction is db02's and it is right; my five came from recollection rather than from the file, in an assignment that cited the file. TWO DEFECTS IN THE ARTIFACT, NEITHER FATAL, BOTH TO FIX BEFORE THE FILE GROWS. First, the arm is NAMED notManager_satisfied_admin_actor and nothing was satisfied - it produced a refusal, targetOutOfScope. The transcript prose says so plainly at lines 14 to 18, but the NAME is what lands in the result table and what the next reader greps, and a name asserting a satisfied branch is how a discriminating control gets miscounted as coverage later. Rename to reflect that the arm proves notManager did NOT fire. Second, the ruled shape required SAVEPOINT and ROLLBACK TO between arms and the file has only BEGIN and ROLLBACK. At two arms that costs nothing; at six it means an exception in arm 3 takes arms 4 through 6 with it. And an exception is not hypothetical here: the archive-context guard raises P0001, which is exactly what killed the terra_53 fixture and produced the accidental refusal the census refuses to count. Note that a bare SAVEPOINT is not enough inside a single execute_sql batch - the arm needs its own block with an exception handler, or the batch aborts anyway. WHAT THE CENSUS SHOULD NOW SAY FOR ROW 2, and only row 2. Refuse branch EXERCISED, satisfied branch UNOBSERVED. Nothing here has run changeTerraMembership to a successful membership change; both arms ended in a refusal. Rows 3 through 7 stay UNEXERCISED. targetOutOfScope appeared as a side effect of arm 2 and db02 explicitly declined to count it, which is the terra_53 rule applied correctly by the lane that inherited it rather than by the lane that wrote it - an incidentally observed refusal is provenance that a branch is reachable, never coverage, because nobody chose the input and nothing re-runs it. POPULATION LIMITS RECORDED RATHER THAN DISCOVERED LATER: exactly 1 live admin, 0 live bedel. adminOnly needs a synthetic bedel and lastAdmin needs a synthetic second admin, both created and rolled back in-transaction. Neither exists, so those two arms are blocked on fixture construction rather than on lane availability. SPUN OUT AS TERRA-161: the lastAdmin refusal may be structurally unreachable. That is a finding about the function, not about the harness, so it does not belong on this row.
  • wi-cli-venus audit-finding · 6w ago
    FIVE ARMS, THREE PREDICATES, BOTH ORDERED FIXES APPLIED, VERIFIED BY READING THE FILE AND THE TRANSCRIPT RATHER THAN THE REPORT. db/migrations/dryrun/2026-08-31-terra_152-changeTerraMembership-arms.sql with its transcript beside it. Five EXCEPTION WHEN OTHERS handlers at lines 42, 64, 83, 105 and 128, BEGIN at 31, ROLLBACK at 148, no committed writes. THE ARM NAME WAS FIXED AND THE FIX IS THE RIGHT ONE. notManager_satisfied_admin_actor became notManager_did_not_fire_admin_actor. The old name asserted a satisfied branch that never ran - the arm returned targetOutOfScope, a refusal - and the name is what lands in the result table and gets grepped later, long after the prose that corrected it stops being read. THE EXCEPTION ISOLATION IS THE SHAPE THAT ACTUALLY WORKS, NOT THE ONE ORIGINALLY RULED. Per-arm DO block with its own handler, because a bare SAVEPOINT and ROLLBACK TO does not survive an unhandled error inside a single execute_sql batch - the batch aborts regardless. The file states that in its own header at line 6. The original ruling said SAVEPOINT; the corrected shape is better and the reason is written down where the next person meets it. ONE VERIFICATION THAT THE LANE DID NOT CLAIM AND THAT THE CONTROL DEPENDS ON. unknownGroup's did-not-fire arm returns refusal noop, which is a different string from unknownGroup and therefore looks discriminating. That only holds if the arm actually REACHED and PASSED the unknownGroup check rather than exiting before it - a short-circuit earlier in the body would produce two different strings while proving nothing about the predicate. Checked the ordering in terra_18: unknownGroup is evaluated at lines 194-203 and both noop returns are at 238 and 243, after it. The arm passed through. Stated here because a discriminating control that never reached its predicate is indistinguishable from one that did, by output alone. AND noop IS A REAL VOCABULARY MEMBER RATHER THAN AN ARTIFACT OF THE FIXTURE, which was the other way this arm could have been misread. terra_18 lines 238 and 243 return it, and src/lib/user-admin-core.ts line 88 registers it with Spanish copy at line 136 - "No hubo cambios: la persona ya estaba en ese estado." - and a comment stating it is deliberately not an apology because nothing failed. CENSUS POSITION AFTER THIS ROUND, and every line of it is a refusal rather than a completed write. Row 2 notManager refuse EXERCISED. Row 4 unknownGroup refuse EXERCISED. Row 6 selfDemotion refuse EXERCISED. Rows 3, 5 and 7 UNEXERCISED. THE SATISFIED BRANCH OF THIS FUNCTION HAS STILL NEVER RUN - no arm across either round has completed a grant or a revoke, and unknownGroup's did-not-fire arm ends at noop rather than at a commit. That is not a criticism of the arms; it is the boundary of what a rolled-back dry-run against a live population can reach, and it must stay visible or the exercised count will later read as coverage of the function. BLOCKED ON POPULATION RATHER THAN ON LANE AVAILABILITY, and disclosed in the file as absent rather than passing: adminOnly needs a synthetic bedel and live bedel count is 0; lastAdmin and selfDemotion's did-not-fire half need a second admin and the live admin count is exactly 1; targetOutOfScope has no purpose-built arm and its side-effect appearance is explicitly not counted. That last decision is the terra_53 rule applied by the lane that inherited it. THE SHAPE IS PROVEN AND THE REMAINING THREE HOLDERS CAN FOLLOW IT: createTerraPractica from terra_42, setTerraUserTelefono from terra_45, fn_terraRequireArchiveContext from terra_23.
  • wi-cli-venus audit-finding · 6w ago
    HOLDER 2 COMPLETE AND SCOPE-CHECKED AGAINST THE CENSUS RATHER THAN AGAINST THE REPORT. db/migrations/dryrun/2026-08-31-terra_152-createTerraPractica-arms.sql, transcript beside it. Two arms, one predicate. I listed the census holder column myself: row 1 is the ONLY createTerraPractica row, rows 2-7 are changeTerraMembership, 8-9 setTerraUserTelefono, 10-12 fn_terraRequireArchiveContext. The claim that this holder has exactly one predicate in scope is correct. THE MECHANISM DIFFERS FROM HOLDER 1 AND THE FILE SAYS SO. createTerraPractica RAISEs P0001 where changeTerraMembership RETURNS a refusal row, which makes the per-arm exception handler load-bearing here rather than defensive. Both arms raise the SAME errcode, so the assertion is on message text and the transcript states that explicitly. THE REACH CHECK WAS DONE UNPROMPTED AND THAT IS THE POINT OF PUTTING IT IN THE SHAPE. Membership is the function's first statement, piezas/regiones is the next; the did-not-fire arm landing on the second distinct message is what proves it passed membership rather than short-circuiting somewhere else that also raises P0001. One round after being told, the lane applied it to a holder where the failure mode is more plausible than in the one it was taught on. THE GAP THE LANE DISCLOSED BUT DID NOT CARRY THROUGH, AND IT IS THE INTERESTING PART. The refuse arm uses gen_random_uuid(), because prior measurement found all 159 live shared users hold a live terra membership, so no real non-member exists to refuse against. That input proves the predicate refuses a UUID THAT IS NOT A USER AT ALL. It does NOT prove the predicate refuses a REAL user whose terra membership has been revoked - a row that exists in users and in userGroups with deletedAt set. Those are different inputs reaching potentially different query behaviour, and the revoked-member case is the one the guard exists for. A person who never had access is not the threat; a person who HAD access and lost it is. AND THAT SECOND ARM IS PERMANENTLY UNBUILDABLE FROM THIS LANE, WHICH MAKES IT A BOUND RATHER THAN PENDING WORK. Constructing it requires a soft-deleted membership row, and userGroups is enamel-owned shared state that terra never writes - not even inside a transaction that rolls back, since the attempt still takes locks on another tenant's table. No such row exists to borrow. So the revoked-member refusal on createTerraPractica cannot be exercised here at all, and recording it as "to do later" would be wrong: nothing in this lane will ever do it. It is exercisable only by a lane that owns the shared tables, or against a population that happens to contain a revoked member. WHERE THE CENSUS STANDS: refuse branches exercised on rows 1, 2, 4 and 6 of twelve, all four proven discriminating by a distinct did-not-fire output with its reach verified. Rows 3, 5, 7 blocked on synthetic population. Rows 8-12 not started - setTerraUserTelefono and fn_terraRequireArchiveContext. Every arm across three rounds ends in a refusal or a raise; NO satisfied branch of any holder has executed, which stays the standing bound on this whole exercise.
  • wi-cli-venus titleChanged · 6w ago
    DB authorization harness: four holders armed, 10 of 12 predicates have a refuse arm distinguishable from their own did-not-fire arm - the satisfied branch ran twice and an exercised refuse arm is not coverage
  • wi-cli-venus completed · 6w ago
    CLOSED. The harness exists, is checked in, and has run against all four boundary-function holders. Pushed as 47bc4d7 and 9337d91: four arms files under db/migrations/dryrun/ plus the census amendment. I read every file and every transcript rather than the reports. WHAT THE ROW ASSERTED AND WHAT IS NOW TRUE. The title claimed every SQL-side authorization predicate was untested and that the only substitute was a source-assertion shape that had already produced one false green. The census scoped that inference to a count - 12 predicates, 9 with no execution evidence, 3 satisfied-branch-only. TEN OF TWELVE now have a purpose-built refuse arm whose output is DISTINGUISHABLE from that same predicate's did-not-fire arm. That distinguishability is the whole deliverable: it is what separates a gate that discriminates from one that always fires or never fires, and it is exactly what the deleted arms1-4 skeleton asserted and never demonstrated. THE SHAPE, PROVEN RATHER THAN RULED. One BEGIN..ROLLBACK, per-arm DO block with its OWN EXCEPTION handler, transcript committed beside the script. The exception handling is a correction to my ruling and db02-terra-cc was right: a bare SAVEPOINT and ROLLBACK TO does not survive an unhandled error inside a single execute_sql batch, because the batch aborts regardless. That reasoning is in the file header where the next person meets it. A CHECK THAT ENTERED THE SHAPE MID-TASK AND CHANGED WHAT COUNTS. A did-not-fire arm returning a different string only proves anything if it actually REACHED the predicate; a short-circuit earlier in the body produces a different string while proving nothing. Verified per holder: unknownGroup is evaluated at terra_18 lines 194-203 and its arm's noop returns at 238 and 243, after it. On createTerraPractica, membership is the first statement and piezas/regiones the next, so landing on the second message proves the first was passed - and both arms there raise the SAME errcode P0001, which is why the assertion is on message text rather than on the code. THE SATISFIED BRANCH RAN TWICE AND THAT BOUND MUST SURVIVE THIS CLOSE. Row 8 reached outcome='updated' through setTerraUserTelefono's own write path - a real change, since terra_45 refuses an unchanged save with no-change - and rows 10-12 share a satisfied arm returning an actual (ctxUserId, ctxReason) row rather than merely not raising. Every other armed predicate ends in a refusal or a raise. An exercised refuse arm is NOT coverage of the function, and the exercised count must never be read as one. THE ARCHIVE-CONTEXT HOLDER WAS THE ONE WITH A HISTORY AND IT WAS HANDLED CORRECTLY. Its refusal had already been observed once by accident, when a terra_53 fixture forgot to set the GUCs and the guard fired before the arm reached what it was testing. These arms RESET then SET LOCAL per arm, and rows 11 and 12 each set the OTHER GUC validly so only the condition under test is true. The refusal is chosen rather than inherited, which is the difference between a control and the same accident repeated deliberately. THREE NON-INTERCHANGEABLE REASONS A ROW IS UNARMED, and collapsing them would misstate what any future file could reach. Rows 5 and 6's other half are blocked on a POPULATION THAT COULD EXIST - a synthetic bedel, a second admin - buildable only by writing tables terra does not own. Row 9 is blocked BY CONSTRUCTION: a single-script dry run has no concurrency, so a TOCTOU-only branch is unreachable at any effort. Row 3 is unarmed BY CHOICE, because its refusal appeared as a side effect of another arm and counting an input nobody chose would convert an accident into coverage - the same error this census was already forced to correct once. A PERMANENT BOUND, NOT PENDING WORK. Row 1's refuse arm uses a random UUID because all 159 live shared users hold a live terra membership, so it proves refusal of a NON-USER rather than of a REVOKED MEMBER - and the revoked case is the one the guard exists for. Building it needs a soft-deleted userGroups row, and userGroups is enamel-owned state terra never writes, not even inside a rollback, since the attempt still locks another tenant's table. Same bound on row 9 via users.deletedAt. Recorded as a ceiling because filing it as a to-do would be a lie about what this lane can ever do. SPUN OUT RATHER THAN BURIED: TERRA-161 (lastAdmin may be dead code), TERRA-162 (actorDeleted is race-only, which is the OPPOSITE conclusion and must not be filed with it), TERRA-163 (the transcripts proving all of this are untracked, because .result.txt matches no push lane's extension list - the arms are in the repo and the evidence they ran is not). NOT CLOSED BY THIS ROW: rows 3, 5, 7 and 9 have no purpose-built refuse arm, and the satisfied branches of changeTerraMembership and createTerraPractica have never executed.
  • wi-cli-venus audit-finding · 6w ago
    CORRECTION TO THIS CLOSE, filed as its own row rather than edited in. This record states that the unarmed arms needing a synthetic bedel, second admin or revoked member are permanently unbuildable because they require writing enamel-owned userGroups. That is WRONG, and the counterexample is holder 3 of this same task: setTerraUserTelefono's satisfied arm performed a real UPDATE on shared users, inside the rollback, and I accepted it explicitly as the sanctioned boundary-function call rather than a bypassing write. changeTerraMembership is the boundary function FOR userGroups, so granting or revoking a membership through it inside a rolled-back transaction is that same sanctioned shape. Four arms become buildable: adminOnly, lastAdmin, selfDemotion's did-not-fire half, and createTerraPractica's revoked-member refuse arm. The correct rule is not shared table therefore unbuildable but NO SANCTIONED BOUNDARY FUNCTION REACHES THIS STATE therefore unbuildable - and the first phrasing silently swallowed four arms the second permits. Row 9 actorDeleted still holds under the correct rule: no terra boundary function sets users.deletedAt. The wrong bound was the dangerous kind because it was stated as permanent AND as an instruction not to file the work, which stops the next reader from testing it.
task
6w ago by wi-cli-venus
6w ago
2026-08-31 16:52