Four TERRA-152 arms I recorded as PERMANENTLY unbuildable are buildable through changeTerraMembership itself - the rule is not shared table therefore forbidden but no sanctioned boundary function reaches this state, and holder 3 had already written through shared users the same way

I RECORDED A PERMANENT BOUND THAT IS NOT ONE, AND THE EVIDENCE AGAINST IT WAS IN THE SAME TASK. TERRA-152's close states that the unarmed refuse arms needing a synthetic bedel, a synthetic second admin, or a revoked member are "permanently unbuildable" because they require writing userGroups, which is enamel-owned and terra never writes - "nothing in this lane will ever do them". That reasoning is wrong for every arm that goes through userGroups, and the counterexample is holder 3 of the very same task. THE ARGUMENT I MISSED. Terra does not write shared state DIRECTLY; it writes shared state THROUGH ITS BOUNDARY FUNCTIONS. That is the entire design, recorded across this project. setTerraUserTelefono's satisfied arm performed a real UPDATE on the shared users table, inside a rolled-back transaction, and I accepted it correctly and explicitly as "the sanctioned boundary-function call, not a direct write to the shared users table bypassing it". changeTerraMembership is the boundary function FOR userGroups. Granting or revoking a Terra membership through it, inside a transaction that rolls back, is the same sanctioned shape - not the forbidden one. SO THESE BECOME BUILDABLE, and each was previously recorded as permanently out of reach: - adminOnly (census row 5): needs a bedel. Grant bedel to a live user via changeTerraMembership, then attempt the admin-group operation as that actor. - lastAdmin (census row 7, TERRA-161): needs a second admin. The live admin grants admin to a second user via changeTerraMembership, then a revoke is attempted. This also DECIDES TERRA-161 - whether lastAdmin can fire at all, which is currently an untested structural hypothesis. - selfDemotion's did-not-fire half (row 6): same second admin. - createTerraPractica's revoked-member refuse arm (row 1): the current arm uses a random UUID and therefore proves refusal of a NON-USER rather than of a REVOKED MEMBER, which is the case the guard exists for. Revoke a live member's terra membership through changeTerraMembership, then call createTerraPractica as that actor. WHAT REMAINS GENUINELY UNBUILDABLE, AND THE DISTINCTION IS THE POINT. actorDeleted (row 9) needs users.deletedAt set. NO terra boundary function sets it - the applied set is createTerraPractica, changeTerraMembership, resolveTerraSessionUser and setTerraUserTelefono, and none of them soft-deletes a user. So that arm would require a direct write to enamel-owned state and the bound holds. TERRA-162 also established it is race-only regardless. 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 one permits. WHY THE WRONG BOUND WAS THE DANGEROUS KIND. It was recorded as PERMANENT and as an instruction not to file the work - "recorded as a ceiling because filing it as a to-do would be a lie about what this lane can ever do". A bound stated that confidently stops the next reader from testing it, and it was written into a closed row and a pushed census amendment where it reads as settled. The census text at pm/2026-08-31-sql-authorization-predicate-census.md carries the same claim and needs the same correction. ORDER OF WORK, because one arm unlocks the others: build the second-admin grant first and confirm changeTerraMembership's own grant path returns a committed-shaped outcome inside the rollback, exactly as row 8 did. Everything else depends on that working. CONSTRAINT UNCHANGED: every write goes through the boundary function, never a direct INSERT or UPDATE against users, userGroups or groups, and the whole script rolls back. If any arm cannot be built without a direct write, it is not built and the reason is recorded in the transcript.