Post-deploy PTD check mints one permanent appEvents row per push on a shared 365d-floor table
coder-terra-cc measured appEvents appKey=terra since the TERRA-43 leg-(a) ship: 25 rows, ALL level=info action=db:poolIdentity, route NULL, zero auth/callback, zero signIn, zero error/warn in ~22h. Every one is their own post-deploy PTD check - roughly one permanent row per push, on a table shared with enamel under a 365d retention floor terra cannot prune. Benign today, and the reason matters: benign by a PROPERTY of the row (info level, self-describing action) rather than by anyone having decided it, which means nothing stops the shape changing. Decide whether the PTD check should write at all, and if it should, what makes its rows identifiable as instrument-generated to a reader with no prior knowledge. Flagged by coder, not scope-crept into TERRA-43.
Activity
-
649da4a LIVE. Decision recorded on the WI's own two questions: the instrument KEEPS writing (dropping it is the disposable-instrument defect it exists to end) but writes only when one of the four identity values changes, and the message now names itself as an automatic boot record so a reader with no prior knowledge can classify the row. Fails toward recording: unreadable history or changed value both write. UNEXERCISED: no identity change has occurred, so the write arm has run but the suppress arm is only proven by the deploy that follows this one - if 0.24.12+ produces no new db:poolIdentity row, that is the suppression working.