terraModulos has the same zero archive coverage and the same integer-PK wall as terraCirugias, and is the second half of the population TERRA-66 measured

Filed so it does not ride along invisibly inside TERRA-66. The sink widening in TERRA-66 SERVES this table; the trigger does not. MEASURED by db-terra-cc 2026-08-17 in the TERRA-66 PK census: terraModulos.id is INTEGER, the same wall as terraCirugias against terraPracticasArchive.rowId uuid. Row count 6. The two integer-PK tables are exactly the two static vocabulary tables - the pattern tracks vocabulary-vs-clinical, not chance, which is what made TERRA-66 fix the sink assumption rather than one table. NOT MEASURED, and this WI must start by measuring it rather than assuming symmetry with terraCirugias: terraModulos trigger set is UNREAD. TERRA-66 measured terraCirugias only, and one table trigger set is not the population - that bound is stated in TERRA-66 for exactly this reason. Read pg_trigger before designing anything. ALSO NOT SETTLED: whether terraModulos NEEDS archive-on-UPDATE at all. terraCirugias earned it by ceasing to be vocabulary in TERRA-52 - it gained a client-decision writer (isConfirmedByClient) and then a staff retire path (TERRA-56). TERRA-57 explicitly ruled terraModulos does NOT move with it: no client-writable column, stays vocabulary. So the honest question here is whether a table with no app-side write path needs UPDATE capture, and NO is a legitimate outcome - but it must be RULED with a close condition and a mechanical detector, the way terra_25 was. That is the shape that just worked: terra_25 re-open condition 1 fired on its own grep detector when TERRA-56 added a second writer, and it is the first close condition on terra to fire. DEPENDS ON: TERRA-66 sink widening applying first if coverage is taken. Do not schedule ahead of it.