backlog: amend #1212 (built, refuted, reverted) and #122 (visibility is not enforcement) - #323
Merged
Merged
Conversation
…it in) Both items STAY OPEN; neither status glyph is touched. #1212 -- the record must not read as merely unbuilt, because the obvious implementation is now known to be WRONG. It was built, refuted by another session, verified by execution, and reverted at ed8a09d. The defect is the inversion of the item's intent. serve's posture gate is wrapped in 'if not settings.retention.allow_unbounded_phi:', so when the AUDITED keep-forever opt-out is TRUE the auto-bound block is SKIPPED and the field keeps its model default. Measured: RetentionSettings(allow_unbounded_phi=True).messages_days -> 60. The runner then purges PHI bodies after 60 days on exactly the instances whose operator consciously chose to keep them forever. And it was a no-op where aimed: the auto-bound keys on model_fields_set, so an operator who says nothing still resolves to 30 and always did. The amendment also retires a STALE PREMISE IN THE ITEM'S OWN TRAP 5. PR #71 already inverted the prod gate -- a production PHI instance with an unset window no longer refuses, it auto-bounds at 30 and starts, and tests/test_cli.py:1619 flipped with it. So the 'less explicit by default' trade was already made and was never this item's to weigh. PHI.md section 8 still described the old refusal, which is exactly how that stale premise reached the filing: the doc-vs-code gap recorded under ASVS 14.2.4 ground (5), misleading a second engineer in practice. Recorded for whoever picks it up: if the 60 is still wanted the value to change is auto_bound_days in retention_classification.py, NOT the field default -- and 30 -> 60 LOOSENS the shipped PHI bound rather than tightening it. That module carries nine windows behind MIN_PHI_RETENTION_WINDOWS = 9 with a two-way drift test against PHI.md section 2, so the tuple and the doc must move together. #122 -- the owner ruled it IN, and that ruling POST-DATES the DEMAND-GATE and the 2/10 above: 'we never want to process stuff if the processing cannot be logged.' That coupling IS the count-and-log invariant, so the gate is discharged and the trigger is moot. The 2/10 came from conflating VISIBILITY with ENFORCEMENT. stdout, NSSM rotation, the TLS syslog forwarder and #50's disk metering make the log visible; none makes processing STOP when it cannot be written. A guard that logs a warning and continues does not satisfy this item -- that is the specific thing to check at review. Work exists on w3-log-write-failure (d26d66a, five commits, pushed and anchored) and is UNVERIFIED -- the lane died mid-flight on a usage limit. ADR 0162's number is confirmed sound (real alloc record, main's highest is 0161), but the index row should be re-checked before landing. The claim most worth executing is the partial halt: a halt that stops intake while routed and outbound rows keep draining still violates the invariant. Gates: 484 items each declaring exactly one status (248 live / 236 archived); ledger_check clean; citation check 272 in scope, same 4 pre-existing advisory warnings. Open 183 on main -- unchanged by this commit; the 188 I quoted earlier was before the C train (PR #319) landed its five closures.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Amends
#1212and#122. Ledger only. Both items stay OPEN; neither glyph is touched.#1212 -- recorded as BUILT, REFUTED, REVERTED
Not as unbuilt. The obvious implementation is now known to be wrong -- it would have deleted PHI on
instances whose operator explicitly opted into keep-forever -- and the next person to pick this up
would otherwise rebuild the same defect.
It also retires a stale premise inside the item's own trap list: an earlier change already inverted
the production gate, so a production-PHI instance with an unset window no longer refuses -- it
auto-bounds and starts. The PHI documentation still described the old refusal, which is exactly how the
stale premise reached the original filing. A security document describing a refusal the engine no
longer performs is the misleading-a-live-engineer case, and that argues for raising the item's
priority rather than lowering it.
#122 -- the owner's ruling post-dates both the demand-gate and the score
The original 2/10 came from conflating visibility with enforcement. Console output, service
rotation, the TLS forwarder and metering all make the log visible; none makes processing stop when
it cannot be written.
Flagged for whoever builds it: a guard that logs a warning and continues does not satisfy this item.
Verification
Ledger re-derived with
parse_items: live 248, open 183, archive 236 -- namespace 484 conserved. Noduplicates, no item declaring more than one status.
#1212and#122both confirmed still OPEN.Merges cleanly onto
main.