0627 — worker liveness is an alert, not a register-time check

Context. [0625] chunk 14 specified “the producer’s liveness warn”: a fourth evaluator in RegisterProducer’s register-time pass logging a declared Warn when a topic’s topic_janitor had no live instance, plus runs_manager on the client’s start line. Three things did not survive the build. alert.Evaluator returns an *alert.Alert logged under one generic line, so it cannot carry a code of its own; the condition is not janitor-specific; and the client has no start line, nor any way at construction to know whether the process will later run upkeep.

Decision. The condition becomes the third built-in alert, worker_liveness (pkg/alert/workerliveness), file for file the partitioncount pattern: a JobConfig on RegisterSystemConfig, an hourly exclusive schedule, a provisioner the system manager claims, an instance that evaluates every topic and publishes through AlertController.Record. The condition is the classification the fleet already computes — metrics.WorkerStatus == WorkerUnclaimed, meaning target_instances != 0 with no live worker_instance row — scoped to the worker rows the owner topic owns, its own and its groups’. The controller composes MetricsController.WorkerSnapshots, the read admin already composes; it owns no SQL. There is no threshold: the manager DELETEs expired instance rows on every tick, so UnclaimedFor is 0 for exactly the workers the alert is for, and LiveInstances < TargetInstances is wrong for the group consumers that declare NoInstanceTarget (-1). The cron cadence and the alert’s own repeat/resolve are the debounce. The register-time line alert condition holds is declared as VK0063 for all three built-ins, one code and one page; the alert’s own message clause moves from the message attribute to alert_message, at every site including AlertController’s. runs_manager is cut: manager instance starting already prints in every process that runs upkeep.

Consequences. A produce-only deployment learns at RegisterProducer that nothing runs its topic’s rows, and a deployment with a manager gets the durable half — a dark consumer group now surfaces in vulkan alert list, which no mechanism reported before. Accepted noise: a process that produces then consumes logs VK0063 once on a cold start, since Register runs before Consume claims anything and an instance row lingers only its 30s TTL. Costs: every deployment carries a third alert schedule, worker row, and consumer group, and the alert overlaps the worker gauges and the manager’s suspended-worker Error line — three surfaces for one fact, each for a different reader. examples/phase_1/workerlivenesslab covers both halves; guides/client.mdx’s manager section documents it.