0.6.1

The adversarial review brief now attacks the form of the code: the reviewer writes the changed block the way the strongest engineer in that language would, in the repository's idioms, and a smaller or clearer version is a finding fixed before filing.

housebroken 0.6.0

• A project's AI policy is read from its own tree listing, templates and agent instruction files included, and ends with a reading: BAN, DISCLOSE, MENTION or CLEAN. A ban is never filed into; a disclosure ask is answered in the body. housebroken policy owner/repo --out saves the printout the filing gate requires.
• A branch adds no comment to someone else's code, test files included. housebroken comments refuses one; a reworded comment, a new file's opening header and a maintainer's request (--asked URL) pass. housebroken branch runs it and stamps the head it passes.
• housebroken file stands behind five gates: prior art, policy, prose, the branch stamp for the exact head, and a POST AS IS review bound to that head and body. It forwards only the gh pr create arguments it parses, and review check reads only the report's header.
• The README and the skill state the rules; the ledger keeps the history.

v0.5.1

The shellcheck badge is true again. An unused variable in inbox.sh and two findings in the claim-check test had made it false since at least 0.4.0; all three are fixed, and every script and test passes shellcheck.

The README now lists inbox.sh in step 10 and in the script table, and no longer says the package is waiting for PyPI.

v0.5.0

A new gate at step 9: housebroken review.

Every gate before this one reads code or counts prose. None of them asks whether the idea of a patch is complete, or whether a sentence in its body is true, and those are the defects that got furthest. A reply saying five new static_asserts fail on main when four did. A new test file committed 100755 among 100644 siblings. A patch that removed behaviour the repository documents and never touched the documentation. A second session reviewing the work caught each of them.

review.sh brief names the reviewer and prints its brief. The reviewer is never the model that wrote the change. It is one tier down by default, Fable to Opus and Opus to Sonnet, which costs less and still brings different blind spots, and never below Sonnet, because a review has to be able to check a standard citation or a CI matrix, so Sonnet's own work goes up to Opus. The brief sets hard read-only limits, opens its attack list with every claim housebroken claims finds in the text, and asks for evidence the reviewer produced itself behind every finding.

The report is bound to what it read. Its header records the head it attacked and the sha256 of every text, and housebroken file now refuses unless there is a POST AS IS review of the exact head and body being filed. A fix the reviewer asks for is a new head, and a new head is reviewed again. An inline --body is refused, because a review cannot be bound to text that was never a file. The skill sends a reply that concedes, disagrees or rides on a code change through the same review, checked with housebroken review check before it is posted.

A passed review is not a proof. The day this was written, a review passed a reply packet whose author then found, re-reading, that two functions it cited as precedent compile only under MSVC. The author still re-reads every claim the reviewer did not re-derive.

housebroken branch now also refuses a commit carrying a tool trailer or a session link, and a sign-off that names a username. Its ignore check applies only to files the branch adds: a repository that ignores dl for a built binary also matches its own pkg/dl source directory, and forcing the check called two upstream source files build output. install.sh writes the version beside the dispatcher, so a script install can answer housebroken version.

v0.4.0

A new gate at step 6 and step 10: housebroken claims.

Every gate in this repository read code. File modes, working trees, diffs, comment density, red-then-green, the project's own CI. Nothing read the prose, and the prose is what a maintainer reads first.

On microsoft/GSL #1272 a reply draft said "The five new static_asserts fail on main." An adversarial review falsified it in one pass. Reverting only the rework fails four of the five, because for dyn_array_iterator<const T> the old const_reference and reference are the same type, so the defect never reached the const iterator. Against upstream, five fail beside twenty-one other errors, since that state predates the pull request's own first commit. The number came from a red arm that grepped for static assertion failed and so counted its own filter.

claim-check.sh lists every counted or absolute claim in a body or a reply, so each is re-measured against the exact revision its sentence names. It deliberately does not judge. The sentence that caused it named its revision and read perfectly; a text check cannot tell you it was wrong about it. Listing is the gate, and the re-derivation belongs to whoever is sending the text.

Its own first draft could not catch the sentence it was written for. The pattern wanted the noun beside the number, and "five new static_asserts" has a word in between, so the sentence passed clean in isolation. It had only appeared to work because in the real draft it shared a line with "15/15". Test a new check against the verbatim artefact that motivated it, alone in a file, before believing it.

v0.3.0

A new gate at step 9: housebroken branch.

Three defects on one pull request were facts about the branch rather than about the patch, and git could have printed all three before anything left the machine. A test file committed 100755 among 100644 siblings, which GitHub renders in the diff. A corrected sentence that never left the working tree, because git reset --soft leaves the index at the previous commit, so the rebuilt commits carried the exact wording a reviewer had just rejected. And a documentation sentence claiming the command removes "only the files the plugin generated", which the code falsifies for two file names.

branch-check.sh refuses a dirty working tree, a file mode that disagrees with the file's own siblings, a committed file the repository's own .gitignore excludes, a working artifact, and a branch that is not on top of its base. It prints every absolute claim the added prose makes, and asks for each to be falsified against the code. Those it warns about rather than refuses, because some absolutes are true.

Its ignore check shipped inert in the first draft, because git check-ignore skips tracked files without --no-index. The sabotage proof in its test caught it before the gate ever ran, which is the argument for writing those proofs.

Step 4 gains the two rules a script cannot hold. Swap a file's content from git show <base>:<path> rather than switching branches: a checkout refused because the tree is dirty leaves the patched file in place, and the arm then reports success under the label RED. And after rebuilding commits, grep the committed blob for the change, never the file on disk.

Step 5 gains one more: a project whose own lint aborts on its own configuration is a fact to state, not permission to skip linting the files you changed.

v0.2.8

Step 4 of the door becomes prove it red first, and prove the proof.

A day of upstream work produced six separate failures with one shape: a check whose success condition could be satisfied by nothing happening. A revert that silently did nothing, so both arms of a red-then-green agreed exactly. A CI watcher that exited before any check existed. A census that read a throttled search as a clean sweep. A toolchain that never ran and printed empty results under labels saying RED and GREEN.

Step 4 now asks the question that catches all of them: what would this step print if it did nothing? It requires reverting by content and comparing hashes rather than trusting an exit code, checking a clone's line endings before the first edit, exporting PATH in detached scripts, and hashing the changed file against the blob in the commit before filing, because a branch can carry the test and not the fix.

v0.2.7

The pull request census now reports what it could not read.

Each pull request was read with a call that, on failure, skipped it silently. Under GitHub API throttling that made a pull request disappear from the census, and an unreadable pull request looked exactly like a clean one. natsort #196 sat with two failing checks and was never flagged.

The census now counts the pull requests it could not read and prints CENSUS UNREADABLE with their names, so unknown state can never pass for healthy state. A test stubs gh so every lookup fails; it fails against the previous code and passes against this one.

This is the same defect family as the truncated-search guard in 0.2.6, one layer further down: a check whose success condition can be satisfied by nothing happening.

v0.2.6

The pull request census now says when it could not see everything.

GitHub's search endpoint returns a short page when it is throttled, and a census of half the pull requests reads exactly like a clean one: fewer rows enumerated, fewer flagged, no error. Observed on 9 September, when a tick enumerated 68 of 83 open pull requests and said nothing about the other 15.

The count the search API reports is now compared against the rows returned. A mismatch prints CENSUS INCOMPLETE with both numbers, so an incomplete sweep can no longer pass for a quiet one.

v0.2.5

Step 3 of the door changes: a fix that narrows what a project accepts or publishes is now filed as a pull request whose body names exactly what breaks for existing users and offers to narrow or close it, rather than withheld as an issue.

Withholding the patch did not protect the maintainer's judgement, it only removed the author's name from the fix. cisco/libsrtp #822 was diagnosed and filed as an issue under the old rule; another contributor implemented that diagnosis seven hours later and the maintainer merged theirs.

The issue route survives for a policy that requires discussion first and for a runtime behaviour change that breaks a stable major's compatibility promise, and even then the patch is pushed to a branch and linked so the work stays attributable.