Motir

Type: manual · Executor: human · Repo: none. The fix is a GitHub App installation change in a console, not a code change in any repository, so targetRepo is deliberately unpinned.

Parent: MOTIR-653 (Epic 8) — the EDGE TEST returns NO. No card in 8.3 is genuinely held out of the ready set by this: MOTIR-1144 was built, pushed and pull-requested against motir-marketing today with the repository unconnected, and every sibling can be run the same way. What is lost is automation, not buildability, so the defect belongs in the epic container rather than under a deliverable it does not block.

Discovered in: MOTIR-1144 (8.3.4), while opening its pull request — moooon-B-V/motir-marketing#1.

Root cause / fix

MOTIR-1455 (8.3.10) is done and did what its title says: it provisioned the repository, the Fly app, the CI pipeline and the motir.co records. It did not add the repository to Motir's GitHub App installation, which is the step four sibling cards assume when they say "Pin it once MOTIR-1455 provisions and connects the repo." Nothing in 8.3 owns that step, and no card names it.

Measured on the live tenant, 2026-08-28 — two refusals, not an inference:

update_work_item MOTIR-1144 targetRepo="motir-marketing"
→ UNKNOWN_TARGET_REPO: Unknown target repo "motir-marketing".
  Connected repositories: moooon-B-V/motir-ai, moooon-B-V/motir-core,
  moooon-B-V/motir-gateway, moooon-B-V/motir-meta,
  moooon-B-V/nextjs-prisma-vercel-starter, motir-projects/motir.

link_pull_request MOTIR-1144 url=…/motir-marketing/pull/1
→ GITHUB_REPO_NOT_FOUND: GitHub repository not connected in this workspace:
  moooon-B-V/motir-marketing.

get_project_state MOTIR agrees: five indexed repositories, motir-marketing absent, project repoSet: [] (so the domain is the workspace's connected set, per lib/workItems/dispatchRepo.ts).

Three consequences, all silent:

1. targetRepo cannot be pinned on MOTIR-1143, MOTIR-1144, MOTIR-1152, MOTIR-1154 or MOTIR-1168, so per-card gate 1 is un-dischargeable on every card in this story and the CLI cannot route a dispatch to the right checkout.
2. link_pull_request is refused, so a merge on motir-marketing moves NO card. And the fallback cannot save it either: resolveChangeRequestWorkItem — the branch/title parse — is still present on origin/main (git grep resolveChangeRequestWorkItem origin/main -- lib returns seven files; MOTIR-3674 retires it and is implemented, NOT merged), but it never runs here, because an unconnected repository delivers no webhook at all. There is nothing for either mechanism to act on. So every one of these cards needs a hand transition to done — and the failure mode is a card silently stranded at implemented on work that has actually shipped.
3. The Motir / work item link check never runs on that repository, so the one signal that would have surfaced (1) and (2) is itself absent. This is why the gap survived MOTIR-1455's close-out: nothing anywhere goes red.

Fix direction: add moooon-B-V/motir-marketing to the Motir GitHub App installation on the moooon-B-V org and bind it to the MOTIR project, the same way motir-core / motir-ai / motir-gateway / motir-meta are. Then pin targetRepo: motir-marketing on the five cards above, and back-link any pull request already merged on that repository.

⚠️ Read target-repo-registry-mismatch before diagnosing further if the pin still fails after connecting. UNKNOWN_TARGET_REPO reports the PIN DOMAIN, not the connected set — the stray motir-projects/motir row in the message above is the known artefact of that, and a single project_repository row can switch the domain off every connected repository. repoSet: [] says that rung is not active today, but it is the wrong-answer this symptom invites.

Acceptance criteria

• moooon-B-V/motir-marketing appears in get_project_state MOTIR → code.index.repos, and the repository is bound to the MOTIR project.
• update_work_item MOTIR-1144 targetRepo="motir-marketing" succeeds (the pin is tested, not inferred), and the same pin is then set on MOTIR-1143, MOTIR-1152, MOTIR-1154 and MOTIR-1168.
• link_pull_request succeeds for moooon-B-V/motir-marketing#1, and any other pull request already merged on that repository is linked to the card it delivered.
• The Motir / work item link check is observed running on a pull request in that repository.

Ordering. Every criterion above reads on state that exists only AFTER the installation change; none can be verified from a branch. This card is finished when the four hold against the live tenant, not when a config file says they should.

Context refs

• MOTIR-1455 — the provisioning card whose dependents assume this step · MOTIR-1144 — where it was found, and the first pull request affected
• motir-core lib/workItems/dispatchRepo.ts — the two-rung pin domain · lib/mcp/tools/linkPullRequest.ts — the connected-repository check that refuses the link