2026-09-02 14:46:59 +05:30
|
|
|
# Specification Quality Checklist: Ticket Creation, Messages & Attachments
|
|
|
|
|
|
|
|
|
|
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
|
|
|
|
**Created**: 2026-09-02
|
|
|
|
|
**Feature**: [spec.md](../spec.md)
|
|
|
|
|
|
|
|
|
|
## Content Quality
|
|
|
|
|
|
|
|
|
|
- [x] No implementation details (languages, frameworks, APIs)
|
|
|
|
|
- [x] Focused on user value and business needs
|
|
|
|
|
- [x] Written for non-technical stakeholders
|
|
|
|
|
- [x] All mandatory sections completed
|
|
|
|
|
|
|
|
|
|
## Requirement Completeness
|
|
|
|
|
|
|
|
|
|
- [x] No [NEEDS CLARIFICATION] markers remain
|
|
|
|
|
- [x] Requirements are testable and unambiguous
|
|
|
|
|
- [x] Success criteria are measurable
|
|
|
|
|
- [x] Success criteria are technology-agnostic (no implementation details)
|
|
|
|
|
- [x] All acceptance scenarios are defined
|
|
|
|
|
- [x] Edge cases are identified
|
|
|
|
|
- [x] Scope is clearly bounded
|
|
|
|
|
- [x] Dependencies and assumptions identified
|
|
|
|
|
|
|
|
|
|
## Feature Readiness
|
|
|
|
|
|
|
|
|
|
- [x] All functional requirements have clear acceptance criteria
|
|
|
|
|
- [x] User scenarios cover primary flows
|
|
|
|
|
- [x] Feature meets measurable outcomes defined in Success Criteria
|
|
|
|
|
- [x] No implementation details leak into specification
|
|
|
|
|
|
|
|
|
|
## Notes
|
|
|
|
|
|
|
|
|
|
- Scope is deliberately Phase 5 only (per docs/10-implementation-roadmap.md): ticket/problem
|
|
|
|
|
creation, messages, attachments, lifecycle state machine. Investigation/root cause/solution/
|
|
|
|
|
resolution (Phase 9) and AI diagnosis (Phase 4) are explicitly out of scope — see Assumptions.
|
|
|
|
|
- Recurring-problem matching is intentionally left to an explicit caller-supplied reference for
|
|
|
|
|
this feature; real fuzzy/semantic matching is deferred to the future AI-support feature.
|
|
|
|
|
- Malware-scanner choice and RLS adoption are left to `/speckit-plan` / business confirmation
|
|
|
|
|
respectively, not decided here.
|
|
|
|
|
- All items pass; no revision iterations were needed.
|
2026-09-02 15:21:37 +05:30
|
|
|
|
|
|
|
|
## Implementation notes (added during /speckit-implement)
|
|
|
|
|
|
|
|
|
|
- **Found and fixed a real cross-product ticket-code collision bug**: `deriveProductCode`
|
|
|
|
|
truncates to 4 alphabetic characters, so different products can legitimately derive the same
|
|
|
|
|
prefix (e.g. every test product in this repo's own test suite starts with `TEST...`, all
|
|
|
|
|
deriving `"TEST"`). The initial sequence-counting query (`countForProductAndYear`) was scoped
|
|
|
|
|
by internal `productId`, but the `code` column's uniqueness is global — two different products
|
|
|
|
|
sharing a prefix would each independently compute sequence `1` and collide. Fixed by rescoping
|
|
|
|
|
the count to the actual code prefix (`countForCodePrefix`, `WHERE code LIKE 'PREFIX-YEAR-%'`),
|
|
|
|
|
which correctly reflects what the unique constraint actually guards. The existing retry-on-
|
|
|
|
|
conflict loop (`isTicketCodeConflict`, `MAX_CODE_RETRIES`) still exists as the concurrency
|
|
|
|
|
backstop for the rare race between two concurrent creates computing the same count-based
|
|
|
|
|
sequence simultaneously — confirmed exercising this retry path for real during the verification
|
|
|
|
|
run below (visible as caught-and-retried `P2002` errors in the test log, not test failures).
|
|
|
|
|
- **Found and fixed a second-order issue this feature introduces for the existing 002-saas-
|
|
|
|
|
integration test suite**: three of its integration tests' `afterAll` cleanup deleted
|
|
|
|
|
`ProductIntegration` then `Product` directly. Now that a successful `/v1/support/requests` call
|
|
|
|
|
also creates a `Ticket`/`Problem` (this feature), deleting the `Product` first failed on the
|
|
|
|
|
`problems_productId_fkey` RESTRICT constraint. Fixed by adding `ticketMessage`/`ticket`/
|
|
|
|
|
`problem` cleanup before the existing steps in
|
|
|
|
|
`tests/integration/product-integration-auth.test.ts`,
|
|
|
|
|
`tests/integration/product-integrations-admin.test.ts`, and
|
|
|
|
|
`tests/integration/inbound-rate-limit.test.ts`.
|
|
|
|
|
- All 9 integration test files (24 tests total, spanning both this feature and the pre-existing
|
|
|
|
|
002-saas-integration suite) were run and passed against a real Postgres, Redis, and MinIO
|
|
|
|
|
(temporary Docker containers) — including a real presigned-PUT upload and presigned-GET
|
|
|
|
|
download round-trip against MinIO, not a mock.
|
