Declare the Collector in the model: a scheduled lifecycle, a cluster-wide read, and a namespace on snapshot facts #236

Parent

#195

What is missing

Chapter 20 says the ClusterState Collector is an Application of the delivery project: a CronJob whose ServiceAccount may get and list PersistentVolumes, PersistentVolumeClaims and pods. The Collector now exists (JorisJonkers-dev/delivery#10), and the model cannot declare it. Three gaps, each a decision about what spec/v1 means:

1. No schedule. A Process's lifecycle is application, job or prepare. None runs on a schedule, so no project file can declare a CronJob.

2. No cluster-wide read. Nothing in Project Intent grants a Process get and list on cluster-scoped or all-namespace resources. The grant the Collector is held to is hand-written in deploy/collector/rbac.yaml in the delivery repository, and an envtest case there proves it is exactly get and list on the three kinds.

3. No namespace on a snapshot fact. A binding is {claim, node} and a placement is {process, node}. placementOf in src/resolve/process.ts matches a binding by claim name alone, so:

   • two Projects with a claim of the same name read each other's binding;
   • whoever can create a claim, or a pod labelled app.kubernetes.io/managed-by: deploy-kit, in any namespace can state a binding or a placement under another Project's name, and so hold that Project's Process to a node or raise E_DISK_BINDING_CONFLICT for it.

   The Collector records what the schema can hold: every bound claim in the cluster, and every pod carrying the render's labels.

What to decide

• How a scheduled Process is declared, and what it renders to.
• How a Process is granted a cluster-wide read, and how narrow that grant is kept (the Collector needs three kinds and two verbs).
• Whether a snapshot fact carries its namespace (or its Project), and how resolution matches on it. This changes cluster-state-snapshot.schema.json, so the delivery repository's generated type and the Collector's Capture and Write follow.
• Until then: whether the Collector is deployed outside the model, or not at all. Composition runs with the empty snapshot meanwhile, which chapter 20 says is valid.

Acceptance criteria

• The decision is recorded, and spec/v1 says how the Collector is declared.
• deploy/delivery.project.yml in the delivery repository declares the Collector, and the render carries its CronJob and its grant.
• Two Projects with a claim of the same name each resolve against their own binding.
• Both implementations and the oracle files move together.