Separate routing-label consumption from label carry-over

[ineedjet]

Summary

The current route workflow passes create_labels_if_missing directly to GitHub's transferIssue.createLabelsIfMissing. This couples two policies that have different semantics:

• carrying ordinary issue metadata labels into the destination;
• consuming the triggering routing label as a one-time command.

This follows up on the unresolved routing-label design question in #14.

Current behavior

With create_labels_if_missing: false, a label that has no same-named counterpart in the destination is dropped during transfer. This is useful for routing labels, but it also drops ordinary labels that a consumer may eventually want to preserve.

With create_labels_if_missing: true, GitHub may create the triggering routing label in the destination along with other missing labels. The transferred issue can then carry a route back to its own current repository. Removing that label from the issue after transfer does not solve the whole problem because the unnecessary label definition remains in the destination repository.

Removing the routing label before transfer avoids creating it in the destination, but weakens recoverability: if the transfer fails, the source issue loses the visible routing intent and no new labeled event is available for an automatic retry.

Consumer evidence

A current consumer routes issues by exact labels and deliberately uses create_labels_if_missing: false. Its destination repositories do not define the corresponding routing labels, so GitHub currently drops them as desired.

There is no immediate blocker. The ambiguity appears when a consumer has a concrete need to create or preserve other missing labels during transfer.

Desired outcome

Define routing-label consumption independently from ordinary label carry-over. The contract should allow a routing label to be consumed without creating a persistent label definition in the destination, while preserving a recoverable source issue when transfer fails.

One possible future approach is:

1. Capture source label metadata before transfer.
2. Transfer with createLabelsIfMissing: false.
3. After a successful transfer, selectively create and apply approved non-routing labels in the destination.
4. Never create or reapply the triggering routing label.

This is a candidate, not a prescribed implementation. The design should wait for a real consumer case that needs missing-label carry-over.

Acceptance criteria

• The triggering routing label can be consumed independently of other labels.
• Enabling ordinary missing-label carry-over does not create the routing label in the destination.
• A failed transfer leaves routing intent visible and recoverable.
• Successful transfers and retries remain idempotent.
• Behavior is documented for missing labels, existing same-named destination labels, and transfer failures.
• Tests cover both routing-label cleanup and ordinary-label carry-over.