Peter.Morton
50b87297d2
- Refactor kmeContentSourceAdapter.js into getValidToken(), oidcAuthFlow(), and sitemapFlow(); add sitemap generation using hydra:member response structure - Add searchApiBaseUrl, tenant, proxyBaseUrl fields to kme_CSA_settings.json and kme_CSA_settings.json.example - Add 17 unit tests for sitemap flow and non-sitemap routing regression - Add 5 contract tests for sitemap endpoint (proxy-http.test.js) - Add [Unreleased] sitemap entry to CHANGELOG.md - Add full specs/002-sitemap-generation/ artifact directory (spec, plan, tasks, data-model, contracts, research, quickstart, checklist) - Update constitution.md: add redis as permitted global, refresh kme_CSA_settings references - Update copilot-instructions.md SPECKIT marker to sitemap plan
2.8 KiB
2.8 KiB
Specification Quality Checklist: Sitemap XML Generation
Purpose: Validate specification completeness and quality before proceeding to planning Created: 2025-07-14 Feature: spec.md
Content Quality
- No implementation details (languages, frameworks, APIs) — Note: FR-008/FR-009 reference
xmlBuilderand the VM sandbox constraint. These are explicitly mandated architectural constraints from the feature description, not incidental implementation choices; they belong in the spec as requirements. - Focused on user value and business needs
- Written for non-technical stakeholders — Technical terms (Redis, OIDC) are domain-specific to this integration; they cannot be abstracted away without losing meaning.
- All mandatory sections completed — User Scenarios, Requirements, Success Criteria, Assumptions all present
Requirement Completeness
- No [NEEDS CLARIFICATION] markers remain
- Requirements are testable and unambiguous — All FRs use precise MUST language with measurable conditions
- Success criteria are measurable — SC-001 (5-second response time), SC-002 (zero silent drops), SC-003 (zero regressions), SC-004 (XSD validation), SC-005 (10-second error bound)
- Success criteria are technology-agnostic — SC-004 references the public Sitemaps XSD standard, not an internal tool
- All acceptance scenarios are defined — 8 acceptance scenarios across 3 user stories
- Edge cases are identified — 5 edge cases documented (expired token, missing
vkm:url, large result sets, missing settings, missingxmlBuilder) - Scope is clearly bounded — v1 scope explicitly excludes pagination, multi-tenant, and optional sitemap elements
- Dependencies and assumptions identified — 8 assumptions documented
Feature Readiness
- All functional requirements have clear acceptance criteria — FR-001–FR-013 each trace to at least one acceptance scenario or edge case
- User scenarios cover primary flows — Happy path (P1), backwards compatibility (P2), error/degradation (P3)
- Feature meets measurable outcomes defined in Success Criteria — All 5 success criteria are verifiable without implementation knowledge
- No implementation details leak into specification — Architectural constraints are present as explicit requirements per the feature description
Notes
- All checklist items pass. The spec is ready for
/speckit.clarify(optional) or/speckit.plan. - The shape of the Knowledge Search Service response envelope (how results are nested) is assumed in the Assumptions section and flagged for confirmation during implementation.
- SC-001 (5 seconds) and the 10-second timeout assumption are reasonable defaults and can be revisited during planning if the team has SLA data for the KME environment.