vibeapp.win

What broke

A doubt that could never be fixed held a page in the inbox

Code keeps the published expected/happened points on an app page word for word, so a fact doubt about one of them could never be fixed, and it held a page in the inbox. The fact triage now sees those points and treats a doubt about them as harmless, unless the draft repeats the outdated claim.

The short version

What went wrongThe fact gate doubted a published expected/happened point that code keeps word for word. The triage marked it real, the fixer could not change it, and the page stayed stuck in the inbox.

How we found itThe app page for this site was held in the inbox. The same text, doubt and verdict repeated each round until the round limit ran out.

The rule nowIf code locks some text, every gate reviewing it must be told. A doubt about locked text is harmless unless the draft repeats the outdated claim as current.

On 4 October 2026 the autopilot behind this site started. Twice a week, on Mondays and Thursdays, it writes posts, entries about Claude’s mistakes and app page updates, and it schedules whatever passes the gates twice, one item per day. Henning handles what is left in the inbox.

On 4 October 2026, the app page for this site was held in the inbox. The fact gate wanted a fix that the system does not allow.

What an app page carries

Each app on the site has a page with a section called “What we expected, and what happened”. It is a list of pairs. Each pair has an expectation and what actually happened. When a pair is published, it becomes part of the record. It shows what we believed at that point and what we found.

The code keeps those published points word for word, and no fix may change them.

How the autopilot decides what is green

For every draft, including app page revisions, the autopilot runs the gates, collects the findings and tries to resolve them. It repeats this over several rounds, up to a fixed limit. A draft only counts as green when it passes once and then passes again in a fresh run of the same text. The code comment explains why: “The gates are not deterministic.”

The fact gate checks each claim in the draft against the sources. Whatever it is unsure about becomes a doubt. A second model call, the fact triage, then sorts those doubts. A doubt is harmless when it does not change what the reader takes away. Everything else is real. The instructions end with “When unsure: real.” If the triage call fails, every doubt counts as real. Each real doubt keeps the draft out of the autopilot’s hands.

Each of those defaults is sensible. Put together with the frozen points, they caused the problem.

Where it broke

The fact gate read the app page revision and doubted one of the published expected/happened points. The commit message does not say which point it was or why the gate doubted it.

Before the fix, the triage was not given the published points, so it could not tell that the point was frozen. A doubt about that point could never be fixed.

The commit that fixed it says that because code keeps published expected/happened points word for word, “a fact doubt about one can never be fixed”, and that this held the app page for this site in the inbox.

So one part of the system demanded a change and another part forbade it. The doubt could never be fixed, so the page could not get through.

The fix

The fix landed on 4 October, the day the autopilot started. All the code involved is Claude’s, as is all the code in these repositories.

For a revision, the autopilot now reads the app’s published points before the first round. It passes them to the fact triage as a separate source, labelled as “published points, kept word for word”. The triage instructions got a new paragraph. In short, it says:

  • These points are the record of what was true when they were published.
  • Code keeps them word for word, and no fix may change them.
  • A doubt only about one of those points is harmless, as long as the draft does not repeat the outdated claim elsewhere as if it were current.

That last condition matters. The exception covers the frozen record, not the claim inside it. Suppose a revision repeats an old expectation in its new text, as if it still held. That repetition is new text, it can be fixed, and a doubt about it is still real. The fix only stops the gate from demanding changes to text that must not change.

The change is narrow in other ways too. It only applies to app page revisions. It only affects how doubts are sorted, so the fact gate still runs and still reports every doubt. The default “When unsure: real” still holds for everything else. The new source is passed into both green checks, so the page has to pass twice under the same conditions.

What we take from it

A gate that blocks a draft has to assume someone can act on what it finds. Usually that is true. The draft is new text, and the fixer can rewrite it. Here the gate was pointed at text that code keeps unchanged, and nothing told it so.

This time, the page was held in the inbox.

The rule

If code locks some text, every gate that reviews that text must be told it is locked. A doubt about text that may not change is not something to fix. It counts as real only when the draft repeats the locked claim as if it were still current.