Skip to content

Codify: Let the Real Operation Be the Check, and Close a Defect Class Through One Primitive #2431

Closed

Description

@ptr727

Lesson

Two patterns came out of hardening the host-safety installer for #2423. The work ran from #2424 through #2429, and the record is in each PR body. Both belong in governance prose, likely CODESTYLE.md General or GOVERNANCE.md "Verification Discipline".

  1. Let the real operation be the check, not a prediction of it.
    • Render CLAUDE.md First and Let the Real Write Be the Check #2427 first added a probe that predicted whether CLAUDE.md could be read and written, using exists(), is_file() and os.access.
    • Successive local-review rounds found 5, then 5, then 4 cases the probe got wrong: a dangling link, a link loop, a read-only file that was already current, a Windows ACL, and a backup directory that couldn't be written.
    • The fix that converged moved the file step ahead of every other write. It attempted the real read, backup and write, skipped the write when nothing would change, and turned any OSError into a clean refusal.
    • A prediction can drift from the operation it predicts. The operation itself can't.
  2. Close a defect class through one primitive, not with a check at each site.

Done means

Activity

  1. ptr727 commented on Oct 6, 2026

    @ptr727
    OwnerAuthor

    A third principle of the same family, measured on #2455.

    A failure message states the error, the path, and the remedy, and claims nothing about the state the failure left. The installer's write-failure messages first described the file afterwards: "nothing was installed", "this file is unchanged, so the hook is not registered", "new sessions load that partial file", "a re-run refuses it". Two local review rounds each found a state that reaches the message and makes its description false. Examples are a settings.json written in full but reported as unregistered, and a close error on a complete file reported as a partial one. Each rewording added another state claim, and the next round found another false case. A deletion-only round that kept just the error, the path, and "fix what it names, then re-run" was the first round with no introduced finding.

    It is the message-side form of "let the real operation be the check". The error the operation raised is the one fact the code knows. A description of the aftermath is a prediction, and predictions about filesystem state did not converge here any more than the writability checks in #2427 did.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions