feat(inquiry): redesign status lifecycle, add handler registry, fix runtime bugs

[agreenspan]

Summary

• Schema: replaces resolved/acknowledged with explicit approved, denied, changesRequested statuses — terminal decisions are now first-class enum values, not hidden inside a JSON outcome field
• Handler registry: new handlers/ folder with per-type subfolders (contentSchema, resolutionSchema, handleApprove, validate) and a central registry — adding a new inquiry type is additive with no changes to shared code
• Bug fixes: resolution.ts was silently no-oping on every approved invite (wrong type names), targetModel was never set on create (breaking resolve access checks), canceled was incorrectly accepted as a resolve outcome, searchableFields referenced non-existent schema fields

New structure

handlers/
  types.ts                          InquiryHandler type
  index.ts                          registry (InquiryType → handler)
  inviteOrganizationUser/           fully implemented
    contentSchema.ts
    resolutionSchema.ts
    handleApprove.ts
    validate.ts
    index.ts                        unique: true
  createSpace|updateSpace|transferSpace/  typed stubs
services/utils/
  assertUniqueInquiry.ts            409 if open inquiry exists between same parties
  resolveContent.ts                 merges resolution overrides onto content (target can modify terms)

New endpoint

POST /inquiries/:id/request-changes — target only, transitions to changesRequested, stores explanation in resolution JSON

Test plan

• Create inviteOrganizationUser inquiry → status sent
• Resolve with approved → OrganizationUser created, status approved
• Resolve with approved + modified role in body → override applied
• Attempt second invite same org+user while first is pending → 409
• Cancel as source → status canceled
• Target calls request-changes → status changesRequested
• Source resubmits (update + send) → target can resolve again

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
template-admin	Error		Mar 5, 2026 6:12am
template-superadmin	Error		Mar 5, 2026 6:12am
template-web	Error		Mar 5, 2026 6:12am

[agreenspan]

Code review

Found 3 issues:

1. transferSpace target resolution always 404s — the handler declares targets: [{ targetModel: Organization, targetOrganizationId: 'targetOrganizationId' }] but its contentSchema is z.object({}). resolveInquiryTarget reads body.content['targetOrganizationId'], gets undefined, and throws 404 "Target organization not found" on every create request.

template/apps/api/src/modules/inquiry/handlers/transferSpace/index.ts

Lines 8 to 14 in 0de4246

	export const transferSpaceHandler: InquiryHandler<TransferSpaceContent> = {
	sources: [{ sourceModel: InquiryResourceModel.Space, sourceSpaceId: 'spaceId' }],
	targets: [{ targetModel: InquiryResourceModel.Organization, targetOrganizationId: 'targetOrganizationId' }],
	contentSchema: z.object({}),
	resolutionInputSchema: baseResolutionInputSchema,
	resolutionSchema: baseResolutionInputSchema,
	handleApprove: async (_db, _inquiry, _resolvedContent) => {

2. Role elevation via update endpoint — a user with only manage org permission can create an inviteOrganizationUser inquiry with role: 'member', then PATCH the content to role: 'owner'. The permission re-check on update evaluates the existing inquiry (role=member, passes manage), not the incoming content, so the elevated role is persisted and takes effect on approval.

template/apps/api/src/modules/inquiry/controllers/inquiryUpdate.ts

Lines 13 to 18 in 0de4246

	validateInquiryIsEditable(inquiry);
	const handler = inquiryHandlers[inquiry.type];
	const effectiveContent = handler.contentSchema.parse(content ?? inquiry.content);
	if (handler.validate) await handler.validate(db, inquiry, effectiveContent);

3. Stale target FK fields written to DB on create — all 4 create controllers spread ...body before ...target. resolveInquiryTarget returns only the matched FK (e.g. { targetModel: User, targetUserId }) without nulling out the others. A client that sends targetOrganizationId alongside targetModel: User will have that stale FK persisted, since inquiryCreateBodySchema passes all three optional FK fields through.

template/apps/api/src/modules/organization/controllers/organizationCreateInquiry.ts

Lines 29 to 36 in 0de4246

	const inquiry = await db.inquiry.create({
	data: { ...body, content: content as Prisma.InputJsonValue, ...source, ...target, sentAt: body.status === InquiryStatus.sent ? new Date() : null },
	include: { targetUser: true, targetOrganization: true, targetSpace: true },
	});
	return respond.created(inquiry);
	});

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}