Primary finding
Classification logic: STALE branch is unreachable; UNREADABLE fallback is dead code
highbughigh
- skills/fork-cohort/SKILL.md:108-122
The classification cascade conflicts with the cohort definitions table. (1) The first branch sends ANY fork with `404_on_runs` to COLD, but only after also testing `days_since_run > 365`. For 404 responses there is no last_run timestamp — days_since_run is defined as ∞ when last_run is empty, which makes the COLD branch swallow every fork whose runs lookup 404'd or returned empty (∞ > 365). That is mostly fine for the 404 case, but it also means a fork with empty workflow_runs (200 OK, no runs ever) is classified COLD via the `days_since_run > 365` path — never via an explicit "no runs ever" predicate as the spec describes. (2) More importantly, the STALE definition in the table says `Last run ≥7 days ago and ≤365 days ago`, but the code path is `elif days_since_run >= 7` with no upper bound — yet that branch is only reached if the first branch (`> 365`) was false, so it's actually correct. (3) The final `else: UNREADABLE` is unreachable: every real-valued days_since_run is covered by the prior three elif clauses (<7 twice, >=7 once), and ∞ is captured by the first branch. UNREADABLE is documented as the bucket for API errors after retry exhaustion (per step 3), but the classifier never assigns it — it must be assigned out-of-band in step 3 and the else-branch in step 5 is dead. This is a documentation/code mismatch: an operator reading step 5 will believe UNREADABLE is set here, but it isn't.
Recommendation
Make UNREADABLE assignment explicit and short-circuit the classifier: at the top of step 5, `if unreadable_flag: bucket = UNREADABLE; continue`. Also replace `404_on_runs OR days_since_run > 365` with two explicit predicates so the "no runs ever" case is distinguishable from the ">365d ago" case in the state file, which downstream WENT_COLD transitions depend on.