Skip to content

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

Motir · Work items

MOTIR-1406Done

5.8.7 Integration vitest — reference-on-write → relates_to seam (real Postgres)

Type: test (integration vitest) · Executor: coding_agent · Repo: motir-core. Blocked by 5.8.3.

The story-level integration seam beyond each subtask's units: write a body through the REAL service and read the relationship BACK through the relationships DTO — catching key/DTO drift the units mask. Real Postgres (the motir-core test-DB harness), not mocks.

Cases

  • Save a description with a motir: token AND a bare MOTIR-N key -> two relates_to rows (source: mention), visible through getWorkItem/relationships DTO as "Relates to".
  • Same for explanationMd, title, and a comment body (addComment) — each field path auto-links.
  • No double-link: a pair already linked is_blocked_by (or duplicates) is NOT also auto-related.
  • Idempotent: re-saving the same body adds no second link; an updateWorkItem that REMOVES the reference leaves the link (non-destructive).
  • Self-reference skipped; an unresolved/forbidden/cross-project key dropped silently (no error, no link).
  • Concurrency: two near-simultaneous writes referencing the same target -> exactly one link (warm-pool TOCTOU, either winner accepted).

Acceptance criteria

  • All cases pass against real Postgres; fileParallelism/truncate conventions honoured.
  • Reads go through the SHIPPED relationships read path (not a raw table peek) so a DTO key change would fail the test.
  • The user-mention notification behaviour is asserted unchanged where it shares the write path.

Context refs: lib/services/workItemsService.ts, lib/services/commentsService.ts, the relationships DTO/read, the motir-core test-DB setup.