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-71Done

2.1.2 Service-layer type-parent validation

Estimate: 15m · Depends on: 2.1.1

Add an issuesService (and a thin workItemRepository if Story 1.4 didn't already ship one) enforcing the type-parent rules at the application layer before any write, so the API returns a clean typed error rather than relying on the DB constraint to reject with a raw Postgres error. The DB constraint from 1.4 stays as the structural backstop (defense in depth); this layer is the friendly gate.

Why both layers: the 1.4 DB constraint guarantees integrity even against direct writes, but a 500 from a constraint violation is a poor API contract. The service validates first and throws InvalidParentTypeError (→ 422) with a message naming the offending pair. Same pattern as the workspace invite errors from 1.2.5.

Acceptance criteria

  • issuesService.assertValidParent(parentType, childType) throws a typed InvalidParentTypeError (code INVALID_PARENT_TYPE) on illegal pairs.
  • The create/move paths (built in 2.1.3 and later Stories) call it before writing.
  • Depth rule honored: a subtask/bug at the leaf cannot parent anything (delegates to canParent from 2.1.1).
  • Vitest (real Postgres) proving the service rejects an illegal pair AND that the DB constraint still rejects a direct illegal write (both layers verified).

Context refs

  • lib/issues/issueTypes.ts from 2.1.1
  • lib/services/* + lib/repositories/* patterns + lib/workspaces/errors.ts (typed-error precedent from 1.2.5)
  • Story 1.4's DB constraint definition