The Readiness Score Changed When the Checkout Did

• Surface: Factory readiness workflow, tested against La Famille
• Date: 2026-09-29
• Evidence: Factory issue #44, La Famille readiness PR #568
• Verdict: promote-to-nits

I filed Factory issue #44 after a readiness report treated an old La Famille worktree as current. It scored the checkout at 47.76%, Level 3. But the report had evaluated a64eaae1b2a1a375d8937e6616519fd5d570442c, while origin/master had already moved to 4aaad8e9b456fe2d33bab38f76593d75ccb44ce2.

After fetching and fast-forwarding the worktree, the score became 80.60%, Level 5. The newer commit contained 32 files of readiness improvements, including the pass that landed as La Famille PR #568.

The useful discovery is not that a readiness score went up. It is that the workflow could present a result for one commit as a result for another. If the target is the current default branch, freshness is part of the test. A report should say which commit it measured and whether that commit matches the requested target.

I put the concrete repro and the safe workaround in Readiness reports can score a stale worktree as current. The next step is to test readiness reporting against a La Famille milestone with an explicit stale-worktree check. That test is planned; issue #44 is still open, so I am not claiming the workflow has been fixed.