MEMORY.md index over threshold: measured levers are fewer links and shorter filenames, not shorter hooks

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus descriptionChanged · 6w ago
  was: MEMORY.md is 24K against the 17.1K hook target. The lever is INDEX LINE LENGTH, never reachable content - TERRA-166 measured twelve-for-twelve that files assumed disposable were not, so deletion is not available as a size lever. Each index line is name plus hook; many hooks restate the memory's own description verbatim and several carry a WI number that is already dead. Pass: shorten hooks to the shortest phrase that still discriminates one memory from its neighbours, drop WI numbers whose row is closed, and merge adjacent lines that point into the same topic file. Close condition: MEMORY.md under 17.1K with every current file still reachable from exactly one line - verify reachability by listing the memory dir and grepping each filename in MEMORY.md, not by eye.
• wi-cli-venus titleChanged · 6w ago
  MEMORY.md index over threshold: measured levers are fewer links and shorter filenames, not shorter hooks
• wi-cli-venus note · 6w ago
  MEASURED THE WHOLE FILE RATHER THAN PICKING A LEVER, 2026-08-31. MEMORY.md is 22742 bytes against a 17100 target and a 24400 hard read limit. Composition: 329 links; link TARGETS (the .md filenames) 14335 bytes, 63 percent, averaging 43.6 characters each; link LABELS including brackets 7822 bytes, 34 percent; everything else - separators, WI tags, the header line - about 600 bytes, under 3 percent. THE DEFICIT IS 5642 BYTES AND THAT NUMBER KILLS THE CHEAP FIX. 45 labels exceed 25 characters and together hold 1724 bytes; trimming every one of them to about 14 characters recovers roughly 950 bytes, which is 17 percent of what is needed. Trimming ALL 329 labels to nothing recovers 7822 and would hit the target - and would leave an index of 329 bare filenames with no scannable hooks, which is the thing the index exists to provide. So label length is a real lever and it is not a sufficient one, and a label pass done alone would move the number without changing the outcome. I did not do one: a cosmetic trim that leaves the file over the limit reads as the row having been worked. THE DOMINANT TERM IS FILENAMES AND BOTH WAYS AT IT ARE EXPENSIVE. Shortening them means renaming about 330 files, and every [[wikilink]] in the corpus that points at a renamed file goes dangling - the corpus cross-references heavily, so this is a rename plus a corpus-wide link rewrite, not a rename. Reducing the COUNT means merging related memories, which is the better work because it consolidates knowledge rather than compressing it, but it needs roughly 87 entries removed at about 65 bytes each - and merging requires READING both files, so it is many ticks, not one. AND THE FILE IS GROWING FASTER THAN ANY TRIM. I added FOUR index entries today alone (a-citation-that-verifies-and-is-still-wrong, an-in-transaction-assertion-is-a-fourth-evidence-class, a-blockers-condition-expires-unwatched, requested-revisions-expire-a-byte-bound-approval, a-block-on-a-question-nobody-asked - five, counting correctly). At that rate the index reaches the 24400 hard limit in three or four active sessions, at which point it cannot be read at all and EVERY recall fails, not just the ones over the line. That is the actual deadline and it is closer than the target suggests. ONE MERGE CLUSTER IDENTIFIED, NOT YET DONE, offered as the shape of the work rather than as a plan in a closing paragraph: the citation-and-verification family is seven entries - a-citation-that-verifies-and-is-still-wrong, a-pass-scoped-to-a-sha-is-invalidated-by-citing-it, a-go-is-scoped-to-the-revision-that-was-read, requested-revisions-expire-a-byte-bound-approval, feedback-cite-only-what-you-read-back, a-quoted-comment-is-a-citation-with-no-integrity-check, retyped-text-needs-a-checksum-not-a-reread. They are one rule with six instances. Merging them recovers roughly 470 bytes and makes the rule easier to apply than seven separate near-misses do. WHAT I AM NOT DOING WITHOUT A DECISION: changing the index FORMAT. Dropping the bracket label and listing the bare filename recovers about 5264 bytes - almost the entire deficit on its own - because the current format carries the memory's name TWICE, once as a label compressing it and once as the filename. That is the single decisive lever and it contradicts the documented index format, so it is not mine to take unilaterally. TERRA-166 measured all 12 candidate deletions as durable, so deletion is not available and this cannot be solved by dropping content.
• wi-cli-venus note · 6w ago
  FIRST MERGE DONE, AND IT MEASURES THE REAL COST OF THE APPROACH RATHER THAN JUST THE SAVING. The seven-entry citation-and-verification family identified earlier is now six merged into one file, citations-and-approvals-bind-to-content-not-names.md. feedback-cite-only-what-you-read-back.md was deliberately left OUT: at 13841 bytes it is the largest file in the corpus and is not a near-miss of the others, so folding it in would have produced one unreadable file instead of a rule. INDEX WENT FROM 22915 TO 22490 BYTES. That is 425 recovered against a deficit of 5390 to the 17100 target, so this one merge is about 8 percent of the job. Six files became one, and the merged file keeps every measured instance - terra_54's real-but-wrong SHA, terra_49's citation voiding its own PASS, terra_16 and terra_27's crossed GOs with the tag-ordering tell, terra_51's revision-expired hash, the lookups.ts quoted-comment decay, and the apply_migration retype checksum. Nothing was dropped to make the number move. THE LINK REWRITE IS THE COST AND IT IS BIGGER THAN THE SAVING. Nineteen other memory files carried wikilinks to the six merged names, all of which went dangling the moment the files were deleted. Eighteen were repaired mechanically. THE NINETEENTH IS THE FINDING: an-applied-migration-that-cites-no-tag.md:88 held the link as [[a-go-is-scoped-to-the-revision-that-was-read.md]], WITH THE .md SUFFIX INSIDE THE BRACKETS. Every other link in the corpus omits it, so a pattern built from the observed form missed that one and my verification grep - built from the same assumption - would have reported zero dangling links if I had not counted the hits instead of trusting the pattern. A link-integrity check written from the form you expect cannot see the form you did not. SO THE MERGE PATH IS SOUND BUT SLOW: roughly 87 more entries need to go, each merge costs a corpus-wide link rewrite, and the rewrite has a silent failure mode. That is not an argument against continuing; it is the reason the FORMAT question is still the decisive lever and still not mine to take unilaterally. Dropping the duplicated bracket label recovers about 5264 bytes in one edit with no file deletions and no dangling links at all, because it touches only the index. THE DEADLINE HAS NOT MOVED. The index gained five entries today and lost six, so it is roughly flat while the corpus grew. At the observed rate it reaches the 24400 hard read limit in three or four active sessions, and past that line EVERY recall fails rather than just the ones over it.
• wi-cli-venus verified · 6w ago
  MEASURED 2026-08-31 - THE HOOK'S TARGET IS ARITHMETICALLY UNREACHABLE AT THIS ENTRY COUNT, AND THAT IS THE FINDING RATHER THAN A REASON TO KEEP GRINDING. The hook asks for MEMORY.md under 17.1KB against a 24.4KB read limit and re-asks after every single edit, which reads as a task that has not been attempted. It has now been measured: 338 files in the memory dir, 334 pointers in the index. Stripping every label to nothing still leaves the filenames plus their bracket syntax at 13.7KB - 63 percent of the file - and those bytes ARE the pointer, so they cannot be cut without cutting entries. At a floor of roughly eight-character labels the index still lands near 17.7KB. Shorter hooks cannot reach the target. Only fewer entries can, which is what this row's title already asserted and is now backed by a measurement instead of an assertion. DONE THIS PASS: trimmed the longest labels only - 23.2KB down to 21.9KB. That is 2.5KB of headroom under the read limit, which is the constraint that actually bites, because an index that exceeds it stops being read at all and every recall in every terra session degrades silently. NOT DONE, AND DELIBERATELY NOT DONE ALONE: reaching 17.1KB needs roughly 110 fewer pointers, i.e. folding on the order of 100KB of measured content into themed files. The cluster I costed first - twelve files on claims, staleness and checking - is 100KB by itself, so merging is a lossy REWRITE, not a concatenation. Two standing rules bear on it directly. The corpus is SHARED and concurrently written by every terra lane, so a fold that drops another lane's measured sentence is exactly the failure that file warns about, with nobody positioned to notice. And the standing rule is to replace a superseded record, never delete it. So the scope of what may be lost is Elazar's call, not one lane's. RECORDED WHERE IT WILL BE READ: the arithmetic is now a section in the-terra-memory-corpus-is-shared-by-every-terra-agent.md, so the next session does not re-derive it from scratch or start deleting files to hit a number. The operative target is the READ LIMIT, not the hook's number.
• wi-cli-venus note · 6w ago
  Medido 2026-09-01: MEMORY.md esta en 22KB contra un limite de lectura de 24.4KB, y el hook ya pide compactar por debajo de 17.1KB. Esto cambia la urgencia del row: hasta ahora era higiene, y ahora tiene un modo de falla duro - si el indice pasa el limite deja de leerse ENTERO, que es peor que cualquier fusion que se le pueda hacer. Un indice que no se carga no degrada de a poco, desaparece. NO LO TOQUE mas alla de agregar una linea, y a proposito: el row dice que la fusion masiva es decision de Elazar, y una reestructuracion grande hecha a las apuradas justo antes de un compact es exactamente donde se pierde informacion sin que nadie lo note. La palanca barata y sin perdida sigue siendo la que el titulo ya nombra: acortar las etiquetas del indice, que son punteros y no contenido, en vez de borrar entradas. Acortar los hooks no sirve y borrar memorias es la unica opcion que destruye algo. Queda pedir el GO.
• wi-cli-venus completed · 6w ago
  RESUELTO POR OTRO AGENTE DE TERRA A LAS 02:03-02:04, SIN EVENTO EN ESTE ROW, Y SE HABIA PERDIDO UNA LINEA ENTERA EN EL CAMINO. La encontre y la restaure. El corpus de memoria es compartido por todos los agentes de terra, asi que un cambio ahi no deja rastro en el row que lo pedia. QUE PASO. MEMORY.md paso de 21582 bytes a 1095. El indice completo se movio a cinco archivos corpus-index-1 a 5, cada uno una lista de links unidos por punto medio, con MEMORY.md quedando como raiz que apunta a los cinco mas la linea de WIs cerrados. Total de los cinco: 23406 bytes. ES EL LEVER CORRECTO Y NO EL QUE ESTE ROW HABIA NOMBRADO. El row decia que las palancas eran MENOS LINKS y NOMBRES DE ARCHIVO MAS CORTOS, y las dos son destructivas - fusionar archivos pierde granularidad y renombrar reescribe cada wiki-link que cita el nombre viejo. La solucion aplicada no borra ni renombra nada: convierte un costo de AUTO-CARGA en un costo de LECTURA A PEDIDO. MEMORY.md es lo unico que entra solo en cada sesion; los 325 links siguen existiendo y ahora se alcanzan con un grep o abriendo el archivo por nombre. Es exactamente el patron de los lazy-loaded rule files del CLAUDE.md global. No se me habia ocurrido y es mejor que las dos que yo habia medido. LO QUE SE PERDIO Y RESTAURE. La condicion de cierre de este row era "todo archivo del directorio alcanzable desde exactamente una linea, verificado listando el directorio y grepeando cada nombre, nunca a ojo". La corri. Faltaban OCHO archivos. CINCO eran una LINEA ENTERA de MEMORY.md que desaparecio en el split - la de pacientes y autenticacion: terra-pacientes-write-boundary, terra-account-precreation, terra-gotrue-mailer-and-config-reads, terra-oauth-allowlist-and-clientid-status, terra-email-stack. Estaban indexadas antes y quedaron inalcanzables despues. Los archivos NO se borraron; lo que se perdio es la unica forma de encontrarlos, que para un corpus de memoria es lo mismo en la practica - nadie greppea un nombre que no sabe que existe. TRES no son regresion del split y ya estaban sueltos de antes: terra101-terra40-paciente-name-snapshot, terra114-terra42-createterrapractica-name-snapshot, terra64-citation-currency-audit. Los indexe igual. Restaure las dos lineas en corpus-index-1.md y RE-VERIFIQUE con la misma consulta: unico archivo no indexado es MEMORY.md, que es la raiz y corresponde, y cero targets rotos entre los 325 links. El unico "roto" de la primera pasada era file.md, que es el ejemplo en la prosa de MEMORY.md y no un link. POR QUE LA PERDIDA ERA INVISIBLE, que es lo que vale guardar: un split que preserva el CONTEO DE BYTES casi exacto - 23406 contra unos 23000 - se lee como completo. Comparar tamanos no detecta que falte una linea de cinco links, y el archivo nuevo se ve prolijo. Lo unico que lo encuentra es lo que este row ya exigia por escrito: listar el directorio y comparar contra los links, nunca a ojo y nunca por tamano. CIERRO. MEMORY.md 1095 bytes contra un objetivo de 17.1K, corpus entero alcanzable, cero links colgados. La condicion de cierre esta cumplida y verificada por consulta, no por lectura.