support_backend/specs/009-problem-resolution/checklists/requirements.md

Specification Quality Checklist: Problem Resolution

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-09-03 Feature: spec.md

Content Quality

• No implementation details (languages, frameworks, APIs)
• Focused on user value and business needs
• Written for non-technical stakeholders
• All mandatory sections completed

Requirement Completeness

• No [NEEDS CLARIFICATION] markers remain
• Requirements are testable and unambiguous
• Success criteria are measurable
• Success criteria are technology-agnostic (no implementation details)
• All acceptance scenarios are defined
• Edge cases are identified
• Scope is clearly bounded
• Dependencies and assumptions identified

Feature Readiness

• All functional requirements have clear acceptance criteria
• User scenarios cover primary flows
• Feature meets measurable outcomes defined in Success Criteria
• No implementation details leak into specification

Notes

• Scope is Phase 9 per docs/10-implementation-roadmap.md: Investigation → Root Cause → Solution → Solution Implementation → Solution Verification → Resolution, plus customer confirmation and reopen — the full doc 04 §3-9 workflow narrative, matching doc 06's "Domain: Problem Resolution" schema exactly (no new fields invented beyond what's already documented).
• src/modules/problem-management/{investigation,root-causes,solutions,resolutions,verification} are the five real target stub directories for this feature (each currently a one-file stub returning a hardcoded placeholder). src/modules/problem-management/problems was found to be a dead, unwired duplicate scaffold for Problem — the real, actively-used Problem model and repository already live in ticketing/tickets since 003 — this feature does not touch problem-management/problems, matching this session's established discipline of only replacing stubs a documented phase's roadmap item actually calls for.
• This feature explicitly closes a loop 008-sla-escalation's own spec.md left open in its Edge Cases: "reopening... may need its own SLA-run-restart decision" — resolved here as "no new SLA run on reopen" (FR-018), keeping 008's already-shipped 1:1-with-first-assignment boundary unchanged rather than reopening (no pun intended) that feature's own scope.
• Verification-failure escalation deliberately reuses 003/007's existing HUMAN_ESCALATION transition rather than inventing a new escalation-rule trigger type in 008's system — flagged explicitly in Assumptions as a scope decision, not an oversight.
• All items pass; no revision iterations were needed.

Implementation Notes (added during /speckit-implement)

• fastify.authenticateProductIntegration (002) turned out to unconditionally require a full ticket-creation-shaped body (source/problem included) — reusing it as planned for confirm-resolution/reopen made every call fail validation before token verification ran. Fixed by extracting the shared verification logic (everything after the body's own shape is known) into verifyIntegrationIdentity in product-integration-auth.plugin.ts, and adding a new, narrower identityOnlyRequestSchema ({productId, tenantId, userId}) plus a new authenticateProductIntegrationIdentity decorator built on the same shared function — purely additive, POST /v1/support/requests's own behavior is unchanged.
• Two pre-existing scaffold gaps were closed for this feature's FK validation needs: TicketsRepository gained findPendingCustomerConfirmationOlderThan (the auto-close sweep's own query), and ticketsRepository/TicketsRepository are now exported from ticketing/tickets's public index.ts (same "extend an existing module's public surface" precedent as problemsRepository before it).
• Running this feature's own integration suite alongside 008's surfaced a real test-data-hygiene bug in 008's already-committed test file: its second hierarchy node used productScope: [] (a wildcard matching every product, per HierarchyNode's own documented scope-matching rule) purely to have a valid, different target node for its own scoped-escalation test — but since every test file's tickets share one live Postgres database, that wildcard node (and, similarly, 008's intentionally-global SLAPolicy test fixture) silently affected other files' tickets running in the same suite, including this feature's own. Fixed by scoping that node to its own test's product (it never needed to be global) and by deactivating the global SLAPolicy fixture immediately after the one scenario that needs it, rather than leaving it live for the rest of the file's run — both fixes are to tests/integration/sla-escalation-flow.test.ts only, no production code changed. Full regression (tests/unit + tests/integration together, 172 tests) is clean except the 2 pre-existing MinIO-dependent attachment failures.