Orphans are reported, never deleted
A record in the database with no declaration in code is named in the boot log and left in place; removal stays a deliberate act.
The situation
A role was renamed in code. Under code ownership the old role is no longer declared, but it still has open rows, members and history. Deleting it on boot would strand work; ignoring it silently would hide the drift.
The recipe
Boot under code ownership and read the report each surface logs:
[long-tail] config apply (workflows): applied 2, unchanged 31, db-owned 0[long-tail] config apply (roles): applied 1, unchanged 11, db-owned 0, orphans: [old-station]Decide what each orphan is. To keep it, declare it again (with reset: false to hand it to admins). To remove it, delete it through the dashboard or the API once its open work is resolved.
| Surface | Counted as an orphan |
|---|---|
| Roles | Rows carrying real configuration (a title or a form schema) |
| Scan schemes | Rules absent from a code-owned scheme, reported as version/category |
| Agents | Subscriptions not declared in code |
Bare rows auto-created for foreign keys, and membership-only roles, never appear.
The guarantee
Orphans are reported at warn level and never touched. Removing a workflow config, role, topic or agent remains a deliberate act through the dashboard or API, so a rename in code can never delete live work. See Code-owned configuration.
Related patterns
Forms and configuration
Code-owned configuration
Set configSource to code and every declared role, workflow, topic, agent and scan scheme is diffed and applied on each boot from git.
Resolving from anywhere
Cancel is home
Cancelling a wait sends the item back to a known home queue. An operator's cancel is a safe reset, never a lost item.
Resolving from anywhere
The row is the production log
A station resolves its in-flight row with the run's result, so the work queue is also the record of what was produced and how long it took.