The screen that started it
The screen I like best in my Control Plane is the one for a client meeting. It has a phase switch (prepare, meet, process), a numbered column of steps with sub-steps indented, and tabs underneath for the summary, files, questions and actions.
On 11 September I wrote down what I had been missing: that is not a meeting screen. It is a sequence with a lifecycle, and a trip fits it, and so does an epic or an incident.
The decision I wrote down was one cockpit, with the type as a parameter. A type says which phases it has, which tabs, and where its records live. The cockpit draws whatever the type says. A type is one entry in a configuration file, and a screen is that entry drawn by the same code.
What a type costs
On 11 September there were 13 types. Two days later 33. By 16 September 64. Today 66.
A runbook and an epic are worked through rather than presented, so their entry says phases: [] and the phase bar disappears.
This week two more arrived. Instructions came as one entry with seven kinds under it, each kind overriding only what differs: a handover has the statuses open, picked-up and done and no file tab. Templates came with their own entry and a list of rules for what counts as one. Neither needed a new renderer.
Where it still bites
One thing is not a parameter, and it showed. The back button. Each type needs a line in a small table that says where "back" goes, and a type without a line falls back to the Use Cases cockpit. In one round of new screens on 13 September, twelve of them opened with a back button to Use Cases, a list their user had never been on. There was no error and no test failed, because the fallback was valid code.
The comment I left in the code says a new type must get a line there. A rule that lives in a comment is a rule nobody checks, and I have not yet found how to turn it into a check.