MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-2203

(motir-ai) Re-point `MOTIR_META_BUG_PARENT_KEY` to the `@planner-bug-home` marker — MOTIR-1466's unfinished consumer half

Done
Description

Repo: motir-ai · ONE PR. The consumer half of MOTIR-1466, which was never done. Found 2026-08-05 while verifying MOTIR-2201 against the running deployment.

The gap

MOTIR-1466 replaced the volatile numeric key with the drift-proof @planner-bug-home marker and taught motir-core to resolve it. motir-ai was never re-pointed to send it. Read off the platform, not the repo:

fly machines list -a motir-ai   →   MOTIR_META_BUG_PARENT_KEY = 'MOTIR-1465'
fly secrets list -a motir-ai    →   no MOTIR_META_BUG_PARENT_KEY (nothing overrides it)

fly.toml:29-31 even records the handoff that stalled:

# ⚠ This key is MCP-created + drifts on a db:seed rebuild — MOTIR-1466 makes the home seed-durable + stably resolvable, after which this is re-pointed.

So lessonService sends the literal MOTIR-1465, isPlannerBugHomeMarker() is false, and aiWorkItemsService.fileBug takes the getWorkItemByIdentifier branch. That works — filing is not broken — but it leaves the exact fragility the marker exists to remove: the numeric key dangles the moment the tenant is rebuilt (keys are allocated sequentially, so a reseed renumbers everything), and then auto-filed bugs go to whatever item inherits MOTIR-1465, or nowhere.

What to change

One value, in fly.toml's [env]:

MOTIR_META_BUG_PARENT_KEY = "@planner-bug-home"

…and rewrite the stale ⚠ comment above it to say what the marker is and that motir-core owns its resolution (lib/ai/plannerBugHome.ts). Nothing else in motir-ai changes: metaBugParentKey() (src/services/lessonService.ts:300) already passes the value straight through, and @planner-bug-home is a legal parentKey string.

The three tests that hardcode 'MOTIR-1465' as the configured parent (tests/lessonCapture.test.ts:260,353, tests/analyzeBugHandler.test.ts) assert pass-through, not the literal's meaning — update them to the marker so the suite exercises the value production will actually send.

⚠️ Ordering — this is blocked_by MOTIR-2201, and the edge is load-bearing

The marker path in motir-core is broken until MOTIR-2201 merges (it resolves through the home epic's first story child, which a re-parent voided). Deploying this re-point first would switch the filer from a working numeric key onto a broken marker and silently stop the self-learning loop — the failure is swallowed on the filing path. Merge MOTIR-2201 to motir-core main and confirm it is live before this PR is merged.

Acceptance criteria

  • fly.toml's MOTIR_META_BUG_PARENT_KEY is @planner-bug-home, matching PLANNER_BUG_HOME_MARKER in motir-core's lib/ai/plannerBugHome.ts character for character.
  • The stale ⚠ comment above it is replaced: it names the marker, points at motir-core as the owner of resolution, and no longer describes the re-point as pending.
  • No other motir-ai source changes — metaBugParentKey() and every caller stay as they are (pass-through is the existing contract).
  • Every test that sets MOTIR_META_BUG_PARENT_KEY uses the marker literal, and the suites that assert the unset case (parentKey undefined → project-root) still pass unchanged.
  • grep -rn "MOTIR-1465" . over the repo returns nothing outside comments/history — no numeric key survives as configuration.

Verification — AFTER the deploy lands (this is the card's completion evidence, not a pre-merge check)

CI's deploy: Deploy to Fly job ships main automatically, so no manual fly deploy is needed. Once it is green:

  1. fly machines list -a motir-ai --json → the running machine's env shows MOTIR_META_BUG_PARENT_KEY = '@planner-bug-home'. Read the PLATFORM, never fly.toml — a config file is a claim about the deployment, not a reading of it.
  2. File one bug through the marker path and confirm it lands under MOTIR-1465: curl -X POST "$MOTIR_CORE_URL/api/internal/ai/work-items" -H "Authorization: Bearer $CORE_CALLBACK_SECRET" -H 'content-type: application/json' -d '{"projectKey":"MOTIR","kind":"bug","title":"marker smoke","parentKey":"@planner-bug-home"}' → 201, the bug appears under MOTIR-1465. Archive the smoke bug afterwards.
  3. If step 2 returns 500 planner_bug_home_not_provisioned, MOTIR-2201 is not live — revert the value rather than leaving the loop deaf.

Context refs

  • fly.toml:29-31 — the [env] value and its stale comment.
  • src/services/lessonService.ts:300 — metaBugParentKey(), the pass-through; unchanged.
  • tests/lessonCapture.test.ts:260,353 · tests/analyzeBugHandler.test.ts:146 — the tests carrying the numeric literal.
  • motir-core lib/ai/plannerBugHome.ts — PLANNER_BUG_HOME_MARKER, the literal to match, and the cross-repo config contract it documents.
  • MOTIR-1466 — the card that introduced the marker and owed this half · MOTIR-2201 — the resolver fix this depends on.