Terra memory index is over its threshold and label-trimming cannot fix it: filenames are ~60 percent of the bytes, so the fix is merging clustered rule files, and it must be done against a concurrently-written corpus

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus progress · 6w ago
  MEASURED RATHER THAN ESTIMATED, 2026-08-31. The index is 19991 bytes. It carries 291 links over 296 unique targets, and the `](filename.md)` spans alone are 13087 bytes - 65.5 percent of the file. Average total cost per row is 68.7 bytes. Reaching the 17.1KB the hook asks for means shedding 2891 bytes, which is 42 ROWS, not 42 characters. THAT NUMBER KILLS THE PLAN THIS ROW WAS FILED WITH. The three merge clusters I identified - comment-integrity, citation/provenance, push and commit mechanics - are 19 files. Merging them to 3 removes 16 rows, about 1100 bytes, and lands at ~18.9KB. Still over. And the push/commit cluster alone is 65KB of content across 9 files: merging it produces a single 60KB memory file, which is worse than the 9 index rows it saves. A memory file that cannot be read in one pass has stopped being a memory. THE THRESHOLD IS NOT REACHABLE BY MERGING WITHOUT DELETING CONTENT, and deleting content to hit a byte target is the one thing this row was explicitly filed not to do. A SEPARATE AND MORE IMPORTANT DEFECT FOUND WHILE MEASURING. 313 files on disk, 296 indexed: SEVENTEEN FILES HAD NO INDEX ROW AT ALL. The index is what recall reads, so an unindexed memory is not a memory - it is a file nobody will ever be handed. That is a worse failure than an oversized index, and it is invisible from the index itself, which looks complete because everything IN it resolves. Zero broken links in the other direction, checked. I ALMOST REPORTED THE WRONG SET. My first reconciliation used `[a-z0-9-]+\.md` and returned 22 files, five of which - terra_client_spec, terra_enamel_cotenancy, terra_fleet_findings, terra_venus_domain_mapping, llmmsg_origin_aro_carry - ARE indexed and were false positives of my own pattern, which had no underscore in its character class. A matcher built from the names I happened to be thinking of, applied to a corpus that uses two naming conventions. Caught it by recognising the names in the index I had just read. THE SEVENTEEN SPLIT CLEANLY AND THE TWO HALVES NEED OPPOSITE TREATMENT. Five carry durable content and were simply unreachable: backfilling-a-snapshot-manufactures-the-evidence, client-feedback-describes-an-older-build, pm-terra-identity-and-anchors, terra_day1_infra_directives, terra-maintainer-backup-seats-144-146-148. INDEXED NOW, on a labelled line saying what they were. The index grew by roughly 350 bytes doing it, in the opposite direction from the threshold, and that is the correct trade: a rule nobody can recall costs the incident that produced it a second time, and a warning costs one line in a hook. The other twelve are per-WI status ledgers - terra64, terra66, terra77, terra86-87, terra96, terra97, terra100 x2, terra101, terra106, terra114, terra118 - whose descriptions read APPLIED, CLOSED, or in-flight. This index's own first line says WI status lives in bwi and never here. They are unindexed because the INDEX was cleaned of them at some point and THE FILES WERE NOT, which is why the corpus and the index disagree by exactly this set. They cost nothing in the index and are invisible to recall, so they are inert rather than harmful. DISPOSITION OF THE TWELVE IS NOT DECIDED HERE AND MUST NOT BE A BULK DELETE. Each one has to be opened and checked for content that is NOT in bwi - a measurement, a rejected approach, a reason - before it goes. Deleting twelve files on the strength of their description lines would be exactly the failure this corpus keeps recording: acting on a summary rather than the thing. CLOSE CONDITION, made explicit because the byte target cannot be it: this row closes when the twelve WI-ledger files have each been opened, their non-bwi content either merged into a durable topic file or confirmed absent, and the files removed. The index size is then whatever it is. If the hook still warns, the finding is that a 17.1KB threshold over a 314-file corpus of deliberately self-describing filenames is the wrong instrument, and that belongs upstream with whoever set it - not paid for by deleting what this project learned.
• wi-cli-venus note · 6w ago
  PREMISE REFUTED, four files opened out of twelve, and the row needs rewriting rather than working. The framing was that twelve WI-numbered memory files are status ledgers whose content lives in bwi, so opening each one and then removing it would shrink an index that is close to its read limit. Every file opened so far carries durable content that is in no other file, and none of the four is a status ledger. terra100-drift-instrument-must-fail-control carries an explicit rule with Why and How-to-apply lines: run the must-fail control in both injection directions inside a rolled-back transaction before a drift query's zero counts as evidence. terra114-terra42-createTerraPractica-name-snapshot carries the no-backfill decision - writing today's pacientes values into rows that never took a snapshot at creation time fabricates history - plus the COALESCE explanation of why the defect went unnoticed and the deliberate non-use of the resolver's outcome vocabulary. terra101-terra40-paciente-name-snapshot carries a measured Postgres behaviour with a How-to-apply: CREATE OR REPLACE VIEW cannot insert or reorder columns mid-list, it is append-only, hit live as 42P16, so append new columns at the end of an explicit column list and re-verify ACL afterwards rather than assuming it survived; it also carries the bidirectional-proof requirement, that a proof showing only the new shape holding cannot distinguish the snapshot working from the rename never applying. terra64-citation-currency-audit carries two rules about reading reports: a PM's stated premise is not a finding, because it arrives carrying dispatch authority and gets read as fact rather than claim, and a filing that lands on the subject of a closed WI must re-read that WI first, which costs one read and is the whole check. WHY THEY LOOKED DISPOSABLE IS THE ACTUAL FINDING. These files are not in MEMORY.md. An unindexed file is invisible to recall, so it contributes nothing while it sits there, and its WI-numbered filename is the only thing anyone sees when listing the directory. A filename that starts with a ticket number reads as a ticket artifact. The content was never the evidence for the ledger premise - the filename was, and I would have deleted four files of measured behaviour on the strength of their names. This is the same shape the corpus already records about acting on a summary rather than the thing, and about a family name not being a measurement. THE ROW IS REWRITTEN, NOT WORKED. The close condition was that the twelve files are opened, their non-bwi content merged or confirmed absent, and the files removed. Removal is now the wrong default: for a file whose content is durable and unindexed, the fix is an index line, not a deletion. New close condition: each of the twelve is opened; content already covered by a topic file is merged there and the file removed; content not covered anywhere gets an index line so it becomes reachable; and the WI-number filenames are renamed to describe their content, because the number is what made them look like ledgers. The index size after that is whatever it is, and it is not a target. DO NOT DELETE ON A BYTE TARGET. The index is near its read limit and that pressure is real, but it is not a reason to remove reachable content - it is a reason to shorten index LINES, which is a different operation on a different file. Eight remain unopened: terra96, terra77, terra100-terra39, terra106, terra118, terra86-87, terra97, terra66. Assume a concurrent writer throughout; MEMORY.md was rewritten by another terra agent mid-session today and three index edits of mine were carried across into its new form, so anchored edits only, never a whole-file write.
• wi-cli-venus note · 6w ago
  SIX OF SIX NOW, AND THE SIXTH FILE WAS HOLDING A LIVE CONTRADICTION IN A ROUTING RULE I USED TODAY. terra96-terra38-migration-hardening carries a rule with Why and How-to-apply lines: when a migration retires or replaces option rows in a shared vocabulary table, the dependency precondition must cover every category whose VALUES change, not only categories whose NAME changes - category-name continuity is not evidence of value continuity. It reached that after two audit BLOCKs, the second finding the first hardening itself too narrow. Not a ledger, and not in the index. terra77-piezas-deciduous-scope-gap is the serious one. Buried in it is a 2026-08-17 ruling from Elazar, relayed independently to two terra lanes as msxlhy8bhj98 and msxli7l6on4a, NARROWING db-enamel-cc's GO gate to genuinely cross-project surfaces only - users, userGroups, groups, shared app star GUC names, the appEvents schema and constraint SHAPE, and shared-vocabulary reference-table STRUCTURE explicitly NOT membership rows - so that CRUD or DDL scoped to terra's own appKey rows inside a physically shared table needs no GO, with vocabularyScopeMembers deletes named. It called terra_28 and terra_30 over-gating and said the precedent terra_30 leaned on was itself over-gating rather than evidence. THAT CONTRADICTS THE 2026-08-31 OWNER RULING db-enamel-cc-mthanr020vgm, which names lookupOptions as gated on a READ. Both cannot apply to one migration. I did not resolve it by picking the one I remembered. Folded the contradiction into the-gate-boundary-is-shared-object-touch-not-prefix.md as a dated section, defaulted to the WIDER gate on the reasoning that over-gating costs a message and a wait while under-gating touches another tenant's data unseen, and put the question to db-enamel-cc as the owner. THE FAILURE IS EXACTLY WHAT THIS ROW WAS ABOUT AND I HAD IT BACKWARDS. The narrowing lived in one file that was never indexed, so every recall of what the GO gate covers returned the broad rule alone and the narrowing did not exist to be contradicted. An unindexed memory is not a weak memory, it is an absent one, and its absence is silent in precisely the direction that leaves the surviving rule looking uncontested. I nearly deleted this file on the strength of its filename. Two files still unopened before that: terra100-terra39, terra106, terra118, terra86-87, terra97, terra66.
• wi-cli-venus note · 6w ago
  EIGHT OF EIGHT. Every WI-numbered file opened so far carries durable content that is in no other file, and not one is a status ledger. terra100-terra39-vocab-scope-drift is the strongest yet and was completely unreachable: it holds the rule that any vocab or lookup migration must verify through resolveScopedVocabulary(), never through lookupOptions alone, with the resolver's actual semantics written out - ownership gate first, then mode gate against vLookupOptions - because terra_35 and terra_38 BOTH shipped verified-green and silently broken on screen by asserting against lookupOptions while the picker reads the resolver. It also holds three instrument rules: an instrument must join the same way as the thing it audits or it disagrees with it by construction; a hidden option is a DEFECT when terra owns it and a FEATURE when a co-tenant owns it, one phrase two meanings; and a vocabulary whose values a check cannot see is one it must not judge. Plus a must-fail control run in both directions proving the drift query's zero means no drift rather than cannot see drift. terra106 holds a severe tooling gotcha: execute_sql surfaces only the LAST statement's result set, and wrapping arms in one shared DO block SILENTLY SWALLOWS a mid-block error - the transaction aborts and the tool returns a clean-looking final result read from untouched committed state, indistinguishable from the writes did nothing. Also the real finding that vUserGroups already filters deletedAt, so a named actorDeleted branch only fires on a same-transaction TOCTOU race and never in steady state. BOTH INDEXED RATHER THAN MERGED, deliberately. Merging eight files of measured behaviour into topic files is a bigger job than this tick holds, and an unindexed file is an absent one, so indexing buys reachability now at the cost of index bytes. THE HOOK WANTS MEMORY.md UNDER 17.1KB AND IT IS AT 21KB AND RISING BECAUSE OF ME. I am not going to hit that number by removing reachable content, and I am saying so on the record rather than quietly ignoring the instruction. The index is the wrong lever: the fix is shorter index LINES over the same corpus, which is a formatting pass on one file, not deletion of measured findings. Four files still unopened - terra118, terra86-87, terra97, terra66 - and on the evidence of eight for eight I expect all four to carry content too. REVISED CLOSE CONDITION, replacing the original removal-by-default: each of the twelve opened; content already covered by a topic file merged there and the file removed; content covered nowhere given an index line; then a SEPARATE pass shortening index lines to fit the budget. The WI-number filenames should also be renamed to describe their content, because the number is what made them read as ledgers and is what nearly got them deleted.
• wi-cli-venus commented · 6w ago
  All twelve WI-numbered memory files opened. TWELVE FOR TWELVE CARRIED DURABLE CONTENT, which retires the premise the row was filed on - they were assumed to be disposable per-WI ledgers safe to delete by default, and not one of them was. The original close condition would have destroyed content in every single case. Revised condition, applied: open each, merge anything a topic file already covers into that file, give an index line to anything covered nowhere, then a SEPARATE pass to shorten index lines. FINAL FOUR THIS ROUND, and what each was actually holding: terra118-terra115 -> merged into trigger-enablement-mode-decides-replica-bypass. The durable claim is neither half of what the corpus already had: copying a guard PATTERN copies its TEXT and none of its non-textual properties. terra_44 was modelled on terra_32 and audit BLOCKed it on two counts at once - the new function inherited the implicit PUBLIC EXECUTE that every CREATE FUNCTION ships with, and the trigger was plain CREATE TRIGGER so tgenabled='O'. Neither is inherited from the sibling. BOTH DEFAULTS FAIL OPEN: permissive ACL, bypassable enablement. So "modelled on terra_32" is a statement about the body only, and the acceptance block has to assert tgenabled='A' and the exact ACL via aclexplode before the first audit submission rather than after the BLOCK. terra86-87 -> merged into db-verification-traps: a BEFORE ROW trigger fires BEFORE FK and constraint checks, so a value-guard MASKS the arm written to test the FK. terra_31's dry-run inserted a fixture value the guard rejected; the statement died at the guard's P0001 and the FK never got the chance to refuse - a red arm proving the guard works and saying nothing about the constraint under test. An FK arm must use a value every upstream BEFORE trigger ACCEPTS, and assert SQLSTATE 23503 rather than merely "it raised". The rest of that file was live schema measurement (lookupOptions columns, vLookupOptions predicate, terraModulos accented names) which belongs in db/schema-live.md and decays in memory - dropped deliberately, not overlooked. terra97 -> split two ways. To db-verification-traps: ASSERT THE CAUSE, NOT THE OUTCOME. terra_41's dry-run fed accented and capitalised lookup values where the live vocabulary holds unaccented lowercase ones; both would have raised on the VOCABULARY check before reaching the scope check under test, and both arms would have gone green FOR THE WRONG REASON. Read every lookup-typed value live immediately before running and assert the raise's message names the check being tested. Same round: the control fixture picked a practica without pinning moduloId, and since that column is immutable once campos exist, the composite FK refused before the guard was reached - a fixture row's own immutable-once-referenced columns are a second constraint the CONTROL must satisfy before it reaches the thing under test. Also: a terminal ZZ999 abort belongs in the dry-run WRAPPER, never in the migration file, because the same artifact cannot be both harness and apply target unless someone remembers to strip it. To default-open-scoping-and-mode: terra_41 is a DELIBERATE default-open, and its two counter-intuitive consequences. Scope rows must not be pre-filtered by cirugia before reaching the resolver - an empty FILTERED set is indistinguishable from an unscoped campo, so the default INVERTS and the unscoped campo vanishes everywhere instead of appearing everywhere. And the arm that matters is the UNSCOPED one, because a suite made only of scoped arms passes against a resolver that hides the unscoped campo on every cirugia, which is the same over-offering defect with the sign flipped. terra66 -> merged into db-verification-traps, two items. NOT VALID reads identically to a real constraint right up until it does not, and on a zero-row table VALID costs no backfill so there is no reason to take the weaker form. And: a census is bounded by the corpora you can SEARCH, and that bound belongs inside the claim. terra_28's reader census found zero readers via pg_views, per-function pg_get_functiondef and a src/scripts grep - but terra's pool runs as postgres and owns everything, so "enamel does not read a terra-prefixed table" is a CONVENTION and not a privilege boundary, and terra cannot search enamel's repo to confirm. The header says "zero readers in every corpus terra can search" and that phrasing is the deliverable. I DID NOT ASSUME THE STALE HALVES WERE HARMLESS. terra66 recorded pm's HOLD on terra_29 because the retire writer ran RETIRE_SQL through a bare pool.query with no transaction, so the archive-context GUCs were unreachable and applying terra_29 would take a shipped feature to a hard RAISE on every call. terra_29 is now applied (registered 20260831135235). Rather than infer TERRA-78 had shipped, I read src/lib/cirugia-retire-actions.ts: client checkout at 107, BEGIN at 110, setArchiveContext at 114, COMMIT at 127, with the header explaining why a single-statement BEGIN is not the banned node-side-transaction shape. The writer fix is live and the apply is consistent with it. Had it not been, that is a production break sitting behind a memory file nobody was going to open. NONE OF THE FOUR HAD AN INDEX LINE IN MEMORY.md - grepped before deleting. That is the same failure this row already produced once: the 2026-08-17 narrowing of the db-enamel-cc GO gate lived only in terra77, unindexed, so every recall of "what does the gate cover" returned the broad rule alone and the narrowing did not exist to be contradicted. An unindexed memory is not a weak memory, it is an absent one. Twelve files, zero index lines, and the reason they read as disposable is precisely that nothing pointed at them. Files removed after merge: terra118-terra115-in-flight, terra86-87-modulo-campos-and-complicaciones-guard, terra97-terra41-cirugia-campos-scope, terra66-archive-sink-integer-pk-gap. Corpus 323 files. CLOSING this row on its stated condition. The index-line shortening pass is the separate half by design and gets its own row - MEMORY.md is 24K against a 17.1K hook target, and the lever is line length, never reachable content.
• wi-cli-venus completed · 6w ago
  completed