What runs while nobody is looking
A flow that fires on an event gets noticed when it breaks: something does not happen when it should. A flow that runs on a calendar and was never registered has no such moment. It simply never had one, and nobody finds out. These seven are registered, and a test fails when one of them loses its clock.
Expiry, reminders and the sweep
- Compliance expiring in 30 daysThe first warning, while there is still time to renew without stopping anything.
- Expiring in 15 daysThe second pass, to whoever holds the document and to whoever depends on it.
- Expiring in 7 daysThe last one before it stops being a warning and becomes a hold.
- Expired todayThe billing hold goes on. An expired certificate does not release a payment.
- Scheduled-phase sweepThe seventh trigger. Without this clock the scheduled date is a field nobody ever reads.
- Visit reminder, 24 hours outTo the inspector, with the address and the checklist attached.
- Visit reminder, 2 hours outThe one that catches the visit that was going to be missed.
A flow with no clock never had a first run
All of them declared a schedule and none was being registered at startup. That is not a bug you find by using the product: nothing errors, nothing is red, and the screens all look right. What was missing was the run that never happened.
So the check is not that the flow exists. It is that the flow was registered with its clock, by name, one by one. A global count of a global count reads as reasonable and hides exactly the ones that the wrong schedule format left out.
What the check asserts
| Assertion | Result |
|---|---|
| Flows registered with a clock | 7 / 7 |
| Named one by one, not counted | Yes |
| Schedule format the engine reads | Yes |
| No schedule that is all wildcards | Yes |
| The sweep flow has its clock | Yes |
Three more are written, and none of them runs
A cash-timing watcher, a blocked-value watcher and a waiver-gap watcher exist as declarations in the repository. None of the three is loaded, and this page listed all three as if they were.
The cause is the same shape this whole page is about. The loader reads files named exactly one thing, those three are named something else, and a declaration that never loads does not fail — it produces nothing. No error, no red, no missing run to notice, because there was never a run scheduled to miss.
Two of the three query only tables that exist here. One of them reaches for four that belong to the product this came from. So it is not one fix, it is three, and until each is measured they stay off this list.
One action in the whole product can record money as received
Every action declares two things before it can be installed: how much damage it can do, and whether it touches money. The second one is not a label somebody remembered to add — the manifest validator refuses to install a money-touching action that has not asked for a dangerous permission, and refuses it again if the skill is not a verified one.
| Level | Actions |
|---|---|
| Safe — reads, and cannot change anything | 3 |
| Caution — writes, and is reversible | 1 |
| Dangerous — moves money or releases work | 1 |
The one that is dangerous
Recording a phase as paid. It is the step that unlocks the next stretch of work, so it is the one worth guarding: it only runs against a payment already verified with the bank, and it is the only action in the catalogue marked as touching money.
The value of a short list is that it can be read. A catalogue where forty actions are all marked dangerous tells you nothing, because nobody reads forty warnings before approving one.