Populates the five real problem-management stubs (investigation, root-causes, solutions, verification, resolutions -- problems is confirmed dead/unwired scaffold and stays untouched) with doc04's sequential workflow engine: - investigation: version-row-per-attempt (never overwritten), with a customer-safe read path that always strips internalNotes. - root-causes/solutions/verification: a strict existence chain (investigation -> root cause -> solution -> approval -> implementation -> verification), each step resolve-or-409 on its own precondition, matching doc06's schema field-for-field with no invented columns. - resolutions: gated on a successfully verified solution (no stored solutionId FK, per doc06 -- resolved via a join at write time), moving the ticket to RESOLUTION_PENDING_CUSTOMER; explicit customer confirmation and a durable auto-close sweep (the previously-unregistered CLEANUP queue stub, mirroring 008's breach-detection job) both resolve it from there. - reopen (ticketing/tickets): two real, separately-audited transitions (RESOLVED|CLOSED -> REOPENED -> IN_PROGRESS), touching no prior problem-resolution record and no SLARun -- closes the loop 008's own spec.md left open. Verification-failure escalation reuses 003/007's existing HUMAN_ESCALATION transition directly rather than adding an eleventh trigger type to 008's already-shipped escalation rules. Customer-facing confirm-resolution/reopen needed a body-shape variant of 002's inbound trust boundary that didn't previously exist: fastify.authenticateProductIntegration hard-required a full ticket-creation-shaped body. Extracted the shared token/scope/replay verification into verifyIntegrationIdentity and added a narrower authenticateProductIntegrationIdentity decorator + identityOnlyRequestSchema on top of it -- purely additive, ticket creation's own behavior is unchanged. Also fixes a real test-data-hygiene bug surfaced by running this feature's suite alongside 008's: a wildcard-scoped HierarchyNode and an intentionally-global SLAPolicy in 008's own test fixtures were silently affecting other test files' tickets sharing the same live Postgres. Verified against throwaway Docker Postgres/Redis: typecheck, lint, architecture-check all clean; full regression (tests/unit + tests/integration together, 172 tests) passes except the 2 pre-existing MinIO-dependent attachment failures, unrelated to this feature. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
34 lines
1.1 KiB
TypeScript
34 lines
1.1 KiB
TypeScript
import { describe, it, expect } from 'vitest';
|
|
import { createRootCauseSchema, ROOT_CAUSE_TYPES } from '@/modules/problem-management/root-causes/schema/root-cause.schema';
|
|
|
|
describe('createRootCauseSchema', () => {
|
|
it('accepts every documented root cause type', () => {
|
|
for (const type of ROOT_CAUSE_TYPES) {
|
|
const result = createRootCauseSchema.safeParse({ type, description: 'some cause' });
|
|
expect(result.success).toBe(true);
|
|
}
|
|
});
|
|
|
|
it('rejects a type outside the five documented values', () => {
|
|
const result = createRootCauseSchema.safeParse({
|
|
type: 'user_error',
|
|
description: 'not a real type',
|
|
});
|
|
expect(result.success).toBe(false);
|
|
});
|
|
|
|
it('rejects an empty description', () => {
|
|
const result = createRootCauseSchema.safeParse({ type: 'technical', description: '' });
|
|
expect(result.success).toBe(false);
|
|
});
|
|
|
|
it('rejects unknown extra fields (strict schema)', () => {
|
|
const result = createRootCauseSchema.safeParse({
|
|
type: 'technical',
|
|
description: 'x',
|
|
extra: 'not allowed',
|
|
});
|
|
expect(result.success).toBe(false);
|
|
});
|
|
});
|