Readiness reports can score a stale worktree as current

Filed from The Readiness Score Changed When the Checkout Did and Factory issue #44.

What I did

Asked the readiness workflow to assess the current default branch in a worktree. The issue record does not preserve the exact command or session, so I am not reconstructing either.

What happened

The report evaluated commit a64eaae1b2a1a375d8937e6616519fd5d570442c while origin/master had already advanced to 4aaad8e9b456fe2d33bab38f76593d75ccb44ce2. It presented the result as current and scored it 47.76%, Level 3.

After the worktree was fetched and fast-forwarded, the report scored the newer commit 80.60%, Level 5. That commit included 32 files of readiness improvements. The number had changed because the subject being measured had changed.

What I expected

Before scoring the default branch, the workflow should fetch its target and compare the worktree's HEAD to the resolved target commit. The report should identify both commits, the fetch time, and whether the worktree is stale. A dirty worktree must never be reset or overwritten to make the report current.

The workaround

Fetch the target branch, confirm the worktree is clean, fast-forward it, then run the report again. If the tree is dirty or cannot be updated safely, stop and report that instead.

Verdict

still-broken — Factory issue #44 remains open. The behavior was observed on 2026-09-28; a later recheck is still needed.

Filed here

↑↓ move enter open esc close