Peter.Morton
f840587e5e
- Add contentFetchFlow() to proxy (FR-001 through FR-012) - Add extractArticleBody() helper with vkm:articleBody / articleBody fallback - Dynamic proxyBaseUrl derivation from x-forwarded-proto/host headers - Forward query/size/category params on /sitemap.xml requests - Add Accept: application/ld+json header to content API calls - Remove oidcAuthFlow() - unmatched requests now return 404 Not Found - Fix xmlbuilder2 import: default import, call as xmlbuilder2.create(...) - Version bump 0.2.0 → 0.3.0 - 45/45 tests passing Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
xmlbuilder2and 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, missingxmlbuilder2) - 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.