These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
Traced the origin of the-custodian issues #1-5 (opened 2026-07-08, all
reviewed and closed 2026-07-20): this ActivityDefinition's matched rule
always produces a TaskSpec (rules/actions.py::_task_spec_for_rule), and
RunActivityWorkflow unconditionally routes TaskSpecs through emit_tasks
-> the deployment-wide IssueSink (ISSUE_SINK_TYPE=rest -> issue-core ->
Forgejo). It is the fleet's only consumer of the task_template rule
action -- confirmed via grep across activity-definitions/.
Per current policy (Forgejo issue tracking is not the fleet coordination
mechanism), paused rather than left to recreate the same sidetrack daily:
enabled: false, status: paused, re-enable path documented in the file
(needs a new activity-core report-sink authoring a kind: intake work
record instead of an IssueSink task spec). Added as item 6 to
CUST-WP-0060's stage-3 successor seed, including the reminder to grep the
fleet for any other task_template consumer before stage 3 ships.
This is the ADR-001 file-level fix; the live activity-core DB row and
Temporal schedule pick it up on the next Railiance-deployed
'make sync-activity-definitions' run -- not something I have credentials
or standing to trigger directly from this session.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
