Skip to content
Motir
Start free

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped
Follow  — continues on app.motir.co
Request a featureAtom feed

← Motir · Work items

MOTIR-60Done

1.6.1 Runtime validation: Inngest local dev + Vercel deploy + CI test harness (end-to-end smoke, no production wiring)

Estimate: 24m

Validate that Inngest's three load-bearing surfaces actually work against motir-core's stack BEFORE the SDK lands in main. The Story's runtime decision (Inngest) is durable but unverified — this Subtask is the gate that lets us back out cleanly if the local-dev story or the Vercel deploy story breaks. Three specific things to prove:

  • Local dev: npx inngest-cli dev runs alongside pnpm dev, discovers a registered function via the /api/inngest serve route, and a triggered event invokes the function locally with the function's logs visible in the Inngest dev UI. Smoke test: a no-op example.ping function that returns { ok: true }.
  • Vercel deploy: deploy the throwaway branch to a Vercel preview; confirm Inngest's prod control plane discovers the function via the preview URL's /api/inngest endpoint (registration). Trigger an event from the Inngest dashboard; confirm the preview deployment receives the invocation. This proves the INNGEST_SIGNING_KEY + INNGEST_EVENT_KEY env-var flow works with Vercel's preview-env model + the Vercel-Neon Marketplace preview-branch DB pattern.
  • CI test harness: Inngest's @inngest/test in-process harness invokes a function synchronously inside Vitest with no external dev server. Smoke test: same no-op function, asserted via the harness API.

Why a research Subtask, not just "do it in 1.6.2": If the Vercel preview-env registration model has a gap (e.g., Inngest can't probe ephemeral preview URLs reliably; signing-key rotation isn't compatible with Vercel's environment scopes), we want to discover it on a throwaway branch with a 2-file diff, NOT after the lib/jobs/ wrapper and the email.send migration are already woven through main. This Subtask is cheap insurance against a 1.6.2 rollback. Output is a finding in PRODECT_FINDINGS.md documenting any sharp edges encountered.

Throwaway branch policy: this Subtask's PR is for human review only, not merge. The artifacts (the validated patterns) feed 1.6.2's prompt; the Subtask branch is deleted after the finding is logged. The status flips to done when the finding lands; no production code from this branch ever reaches main.

If validation fails: log the failure mode in PRODECT_FINDINGS.md, re-open the runtime decision (this is the ONE escape hatch from the durable Inngest choice). The replan would be a fresh motir plan 1.6 with the finding as input.

Acceptance criteria

  • A throwaway branch (subtask/PROD-1.6.1-inngest-spike) demonstrates the no-op example.ping function invoked successfully via: (a) the local inngest-cli dev server, (b) a deployed Vercel preview, (c) the in-process @inngest/test harness in Vitest.
  • Screenshots / logs of each of the three invocations are attached to the PR body.
  • Env-var requirements documented in the PR body: which Inngest keys are needed in CI, in Vercel preview, in Vercel production; how preview-branch DB isolation interacts with Inngest's prod control plane discovering preview URLs.
  • A finding entry exists in motir-meta/prodect_plan/PRODECT_FINDINGS.md capturing any sharp edges (e.g., preview-URL registration quirks, dev-server port conflicts with the existing pnpm dev port), even if the entry is "no sharp edges discovered."
  • The PR is NOT merged; the throwaway branch is deleted after the finding is logged. The next Subtask (1.6.2) reads the finding before starting.
  • If validation fails on any of the three surfaces, the finding entry includes the failure mode and recommends an explicit replan; 1.6.2's status stays planned until a replan resolves the issue.

Context refs

  • motir-core/CLAUDE.md — 4-layer rule (auto-loaded)
  • lib/env.ts — the requiredEnv pattern any new env vars must register against
  • .github/workflows/ci.yml — where placeholder env vars get added for the build step
  • .github/workflows/cleanup-preview-deployments.yml — the existing preview-cleanup workflow that bounds how long a throwaway preview can linger
  • Inngest serve docs + dev server docs + testing reference — the three surfaces under validation
  • feasibility.html ADR-004 — the open decision this Subtask closes
  • PRODECT_FINDINGS.md — where the validation report lands