chore: remove route-issue-shared.yml, no longer used

.github/workflows/proposal-shared.yml

@@ -71,8 +71,8 @@ permissions:
   contents: write
   pull-requests: write
 # actions/proposal is pinned to @main below, not a version tag, while v0.9.0
-# is still unreleased -- switch back to @v0.9 (matching route-issue-shared.yml's
-# own pinned-tag pattern for its sibling action) once that tag exists.
+# is still unreleased -- switch back to @v0.9 (matching this repo's other
+# reusable workflows' pinned-tag pattern) once that tag exists.
 jobs:
   validate:
     runs-on: ubuntu-latest

AGENTS.md

@@ -27,8 +27,6 @@ commit SHA. Do not recommend `@main` for stable consumers.
 
 ## Workflow behavior
 
-- `route-issue-shared.yml` transfers an issue according to an explicit label
-  routing map.
 - `collect-issues-shared.yml` expands configured organizations to repositories,
   combines them with explicit repositories, and processes each unique
   repository independently. It paginates open issues directly and does not use

CHANGELOG.md

@@ -71,6 +71,15 @@
   `issue_number`/`comment_id` to `type: string`, whose unset default is
   genuinely empty.
 
+### Removed
+
+- `route-issue-shared.yml` reusable workflow and its `actions/route-issue`
+  composite action: label-based issue transfer had no proposal or review
+  step, so it never fit the human-agent loop this repo builds for, and its
+  only consumer (`dupmachine/ground-control`) vendored the logic locally
+  instead of depending on it. Breaking for any other consumer still pinned
+  to it (#110).
+
 ## [v0.8.0] - 2026-08-05
 
 ### Added

README.md

@@ -44,7 +44,7 @@ editorial pipeline implementation has been removed and is not supported. Its
 history remains available in Git.
 
 The current reusable workflows cover centralized Project intake for issues and
-pull requests, plus explicit label-based issue routing. The proposal-as-issue
+pull requests. The proposal-as-issue
 lifecycle described above (`Propose`/`Apply`/`Reject`/`Distill`/`Rework`) has a
 working contract, `proposal-shared.yml`: `Apply`/`Reject` are fully
 implemented, `Propose` dequeues and creates a proposal with mocked field
@@ -53,46 +53,6 @@ placeholders (tracked in #11).
 
 ## Reusable workflows
 
-### `route-issue-shared.yml`
-
-Transfers an issue to another repository when a configured label is
-applied, idempotently.
-
-```yaml
-jobs:
-  route:
-    uses: rubykatzen/starcast/.github/workflows/route-issue-shared.yml@v0.9
-    with:
-      routes: >-
-        {
-          "Household": "some-org/some-repo",
-          "Meds": "another-org/another-repo"
-        }
-      label_name: ${{ github.event.label.name }}
-      issue_number: ${{ github.event.issue.number }}
-      create_labels_if_missing: false
-    secrets:
-      token: ${{ secrets.ROUTE_TOKEN }}
-```
-
-Caller triggers on `issues: labeled`.
-
-- **Exact match only**: `routes` maps exact label names to `owner/repo`.
-  A label with no configured route is a clean no-op, not an error —
-  StarCast never derives a destination from untrusted label text.
-- **Idempotent, verified against real transfers**: after a transfer, the
-  issue's old id and its `owner/repo#number` address both stop resolving
-  on the source side. A retry that can't find the issue there anymore is
-  treated as an already-completed transfer, not an error.
-- **Source equal to destination** is a clean no-op.
-- **Label carry-over** is off by default (`create_labels_if_missing:
-  false`) — GitHub's own transfer behavior otherwise silently drops a
-  label with no same-named counterpart at the destination, which is
-  usually what you want for a routing label. Set it to `true` to have
-  GitHub create the label at the destination instead.
-- `token` needs write access to both the source and destination
-  repositories; StarCast stores no consumer secrets.
-
 ### `collect-issues-shared.yml`
 
 Collects open issues from a configured set of organizations and/or individual