upgrade-readiness-brief

upgrade-readiness-brief — The Week's Decisions, On Request

The Saturday job upgrade-readiness-weekly-review grades every cluster and registers each blocker and risk on the findings queue; the job upgrade-readiness-weekly-brief composes the week's brief from both under /opt/data/profiles/platform/governance/upgrade_readiness_brief_sop.md. This skill is that SOP's "On request" route: a user asks for the brief, or for what needs their decision, or for this week's report, and gets the same shape in chat. Read only. Register nothing, decide nothing, upgrade nothing.

Steps

1. Read the review's copy:
   • cat /opt/data/upgrade-readiness/weekly/latest.json — the summary: generated_at, projects, clusters (reviewed, blocked, ready, unknown, unread), counts, findings (rows with id, severity, check, entry, project, cluster, namespace, object, title, action, outcome), new_ids, suppressed_ids, no_longer_reported_ids, project_failures, registration_errors, report_path.
   • cat /opt/data/upgrade-readiness/weekly/latest.md when a line needs more than the row says.
   • If the asked-for thing is the report, print latest.md as it is and stop; when the file is missing, say the review's copy is not there (the weekly review has not run, or its copy did not land; the review's own chat line, if any, says which) and offer the on-request readiness report (fleet-upgrade-verification, --readiness) instead of composing anything.
   • If generated_at is older than 48 hours, compose from the summary anyway and say its date and age in the headline: a stale brief with its date beats none.
   • If the file is missing, read the queue first (step 2). When it holds upgrade- rows, the review ran and its copy did not land: compose from the queue alone, with a headline that says the summary is unavailable, and leave out the counts only the summary gives. Only when the queue holds no upgrade- rows either compose a live brief: run the fleet-upgrade-verification skill with --readiness once over every project in scope, treat its blockers and risks as the findings (a budget over a single replica, a pool past the skew ceiling and a webhook in the upgrade's path are critical; a budget over several replicas, a webhook refusing only what it matches today and a pool at the ceiling are major; a covering exclusion is minor; a readiness rule's blocker is critical, and its risk is minor for catalogue entries 9, 10, 11, 13 and 16 and major for every other entry), name objects where the queue would give ids, say "live brief, composed now; the weekly review has not run" in the headline, and close with the live form of the last line: there is no report file and no id to reply with until the Saturday review registers them.
2. Read the queue, with the platform_control tools:
   • get_ranked_findings: the open backlog. Keep the rows whose check starts with upgrade-. A row in state queued or surfaced is undecided: nobody has decided on it, whether or not the hourly nudge has named it yet. accepted is decided (being worked on).
   • get_findings with state=snoozed, then state=dismissed: the other decided rows; the backlog never carries them. Keep the upgrade- rows of these too. Pass limit=1000 and project=<id> for each project in the summary's projects (the default page is 200 rows across every source); a page of exactly 1000 rows is cut, so say "at least" before that count.
3. Compose the brief in exactly this shape, at most twenty-five lines, ids verbatim in backticks: