chore(#3430): fix openspec validate warnings across boost specs

workspaces/boost/openspec/changes/agent-creation-discovery/specs/agent-creation-paths/spec.md

@@ -79,3 +79,14 @@ All agent creation paths register the agent for lifecycle governance.
 - **AND** the agent enters the `Draft` lifecycle stage
 - **AND** the `createdBy` field is set to the authenticated user's identity
 - **AND** lifecycle actions (promote, withdraw, delete) are available per the agent's governance state
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/agent-creation-discovery/specs/agent-gallery/spec.md

@@ -38,3 +38,14 @@ Agents from all providers are merged into a single discoverable list.
 - **THEN** `useAgentGalleryData()` merges agents from all providers with a 155ms timeout
 - **AND** guard merge + dedup ensures no duplicates
 - **AND** featured agents are configured via `ChatExperiencePanel`
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/agent-creation-discovery/specs/catalog-entities/spec.md

@@ -37,7 +37,7 @@ Cross-cutting entities (MCP servers, vector stores) that aren't provider-specifi
 
 ### Requirement: AI Agent Catalog Entities
 
-Agents are represented as Backstage catalog entities with lifecycle, ownership, and relations.
+Agents MUST be represented as Backstage catalog entities with lifecycle, ownership, and relations.
 
 #### Scenario: Kagenti module emits agent entities
 
@@ -65,7 +65,7 @@ Agents are represented as Backstage catalog entities with lifecycle, ownership,
 
 ### Requirement: AI Model Catalog Entities
 
-AI models are represented as catalog entities, eliminating duplicate caches.
+AI models MUST be represented as catalog entities, eliminating duplicate caches.
 
 #### Scenario: Provider modules emit model entities
 
@@ -76,7 +76,7 @@ AI models are represented as catalog entities, eliminating duplicate caches.
 
 ### Requirement: MCP Server Catalog Entities
 
-MCP servers are represented as catalog entities.
+MCP servers MUST be represented as catalog entities.
 
 #### Scenario: Core plugin emits MCP server entities
 
@@ -88,7 +88,7 @@ MCP servers are represented as catalog entities.
 
 ### Requirement: Vector Store Catalog Entities
 
-RAG vector stores are represented as catalog entities.
+RAG vector stores MUST be represented as catalog entities.
 
 #### Scenario: Core plugin emits vector store entities
 
@@ -99,7 +99,7 @@ RAG vector stores are represented as catalog entities.
 
 ### Requirement: Entity Providers as Independent Backend Services
 
-Entity providers are independently deployable Backstage backend services.
+Entity providers MUST be independently deployable Backstage backend services.
 
 #### Scenario: Standalone entity provider deployment (without boost)
 

workspaces/boost/openspec/changes/agent-creation-discovery/specs/mcp-tools/spec.md

@@ -48,3 +48,14 @@ Kagenti provides dedicated tool lifecycle management.
 - **THEN** a new tool is configured and deployed
 - **AND** `ToolInvokeDialog` allows direct testing of the tool
 - **AND** backend proxy mode supports air-gapped environments
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/ai-chat-interaction-experience/specs/conversation-history/spec.md

@@ -71,3 +71,14 @@ Professional developers can inspect agent execution for transparency and debuggi
 - **WHEN** the user expands a tool call in the execution trace
 - **THEN** full input arguments and output are visible
 - **AND** timing data (phase chips) shows duration of each phase
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/ai-chat-interaction-experience/specs/frontend-composability/spec.md

@@ -8,7 +8,7 @@ The frontend must be decomposed from a monolithic `BoostPage` into composable ex
 
 ### Requirement: Composable Routable Extensions
 
-Deployers can mount chat, admin, and agent studio independently.
+Deployers MUST be able to mount chat, admin, and agent studio independently.
 
 #### Scenario: Independent chat extension
 
@@ -31,7 +31,7 @@ Deployers can mount chat, admin, and agent studio independently.
 
 ### Requirement: Lazy Loading in Primary Paths
 
-Provider-specific and admin components are loaded only when needed.
+Provider-specific and admin components MUST be loaded only when needed.
 
 #### Scenario: ChatView lazy loads provider-specific components
 
@@ -48,7 +48,7 @@ Provider-specific and admin components are loaded only when needed.
 
 ### Requirement: Config-Driven Feature Flags
 
-Deployers control feature visibility via `app-config.yaml`.
+Deployers MUST be able to control feature visibility via `app-config.yaml`.
 
 #### Scenario: Feature flags in app-config
 
@@ -75,7 +75,7 @@ Deployers control feature visibility via `app-config.yaml`.
 
 ### Requirement: UX/UXD Design Alignment
 
-All frontend components and UI flows align with RHDH usability and visual design standards.
+All frontend components and UI flows MUST align with RHDH usability and visual design standards.
 
 #### Scenario: Implementation from UX/UXD mockups
 

workspaces/boost/openspec/changes/ai-chat-interaction-experience/specs/hitl-approval/spec.md

@@ -60,3 +60,14 @@ Every approval decision is persisted for auditability.
 - **WHEN** a user approves or rejects a tool call
 - **THEN** the decision (approve/reject), timestamp, parameters, and user identity are stored in the session history
 - **AND** they are visible in the execution trace panel (dev mode)
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/ai-chat-interaction-experience/specs/rag-knowledge/spec.md

@@ -34,3 +34,14 @@ The agent searches the knowledge base and provides cited answers.
 - **WHEN** multiple vector stores are configured and scoped to the active agent
 - **THEN** the search spans all configured vector stores
 - **AND** results show which store each source came from
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/ai-chat-interaction-experience/specs/streaming-chat/spec.md

@@ -56,3 +56,14 @@ Conversations are persisted automatically.
 - **WHEN** a streaming response completes successfully
 - **THEN** the conversation (session and messages) is auto-saved via `ChatSessionService`
 - **AND** the session appears in the conversation history panel
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/platform-operations-deployment/specs/cache-migration/spec.md

@@ -24,7 +24,7 @@ NOTE: Provider-specific caches are covered in the platform-architecture change.
 
 ### Requirement: RuntimeConfigResolver Caching
 
-The highest-traffic cache uses Backstage cacheService.
+The highest-traffic cache MUST use Backstage cacheService.
 
 #### Scenario: Config cache uses cacheService
 
@@ -35,7 +35,7 @@ The highest-traffic cache uses Backstage cacheService.
 
 ### Requirement: Conversation and Session Caching
 
-Session correlation and conversation maps use cacheService.
+Session correlation and conversation maps MUST use cacheService.
 
 #### Scenario: ConversationRegistry uses cacheService
 
@@ -51,7 +51,7 @@ Session correlation and conversation maps use cacheService.
 
 ### Requirement: Document Sync Hash Caching
 
-Content hashes for change detection use cacheService.
+Content hashes for change detection MUST use cacheService.
 
 #### Scenario: DocumentSyncService uses cacheService
 
@@ -61,7 +61,7 @@ Content hashes for change detection use cacheService.
 
 ### Requirement: Client and Config Service Caching
 
-Singleton client instances and config services use cacheService.
+Singleton client instances and config services MUST use cacheService.
 
 #### Scenario: ClientManager uses cacheService
 

workspaces/boost/openspec/changes/platform-operations-deployment/specs/deployment/spec.md

@@ -33,3 +33,14 @@ Deploy Boost as a traditional Backstage plugin with npm packages.
 - **THEN** frontend route, sidebar entry, icon, and backend plugin are registered manually
 - **AND** `app-config.yaml` is configured
 - **AND** the application is rebuilt and deployed
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/platform-operations-deployment/specs/rag-pipelines/spec.md

@@ -56,3 +56,14 @@ Test retrieval quality before deploying to production.
 - **AND** `RagResultsTable` shows retrieved chunks with `ChunkCard`, `ScoreBar`, and relevance scores
 - **AND** thresholds are adjustable to tune precision vs. recall
 - **AND** `GeneratedAnswerCard` shows the answer that would be generated from the retrieved context
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/platform-operations-deployment/specs/runtime-config/spec.md

@@ -65,7 +65,7 @@ First-time administrators receive guided setup.
 
 ### Requirement: Schema-Driven Config Validation
 
-Hand-written validators are replaced with schema-derived validation.
+Hand-written validators MUST be replaced with schema-derived validation.
 
 #### Scenario: Validation from single source of truth
 
@@ -82,7 +82,7 @@ Hand-written validators are replaced with schema-derived validation.
 
 ### Requirement: New Config Categories
 
-New features require additional runtime configuration fields.
+The following new features MUST have runtime configuration fields as specified below.
 
 #### Scenario: Agent approval configuration
 
@@ -120,7 +120,7 @@ New features require additional runtime configuration fields.
 
 ### Requirement: Config Schema Versioning
 
-DB-stored config values survive schema changes across upgrades.
+DB-stored config values MUST survive schema changes across upgrades.
 
 #### Scenario: Schema evolution on startup
 

workspaces/boost/openspec/changes/platform-operations-deployment/specs/white-label/spec.md

@@ -38,3 +38,14 @@ Featured agents and conversation starters are configurable.
 - **THEN** featured agents for the welcome screen strip are configurable
 - **AND** per-agent conversation starters are configurable
 - **AND** changes apply at runtime
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/pluggable-ai-platform-architecture/specs/multi-agent-orchestration/spec.md

@@ -56,3 +56,14 @@ The OpenAI Agent SDK (via Llama Stack Responses API) handles agent orchestration
 - **THEN** the OpenAI Agent SDK manages agent handoff transitions via the Responses API
 - **AND** it coordinates tool execution within agent turns
 - **AND** orchestration is defined via YAML configuration (not custom code)
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/pluggable-ai-platform-architecture/specs/normalized-streaming/spec.md

@@ -38,3 +38,14 @@ The frontend processes normalized events identically regardless of provider.
 - **THEN** `StreamingMessage.reducer` processes it based on the `NormalizedStreamEvent` discriminator
 - **AND** `useStreamingStateBatching` batches rapid events for performant rendering
 - **AND** `VirtualizedMessageList` renders the accumulated state
+
+## ADDED Requirements
+
+### Requirement: Specification Coverage
+
+This capability area MUST have its existing behavior documented as baseline acceptance criteria.
+
+#### Scenario: Baseline validation
+
+- **WHEN** the existing implementation is validated against this specification
+- **THEN** all scenarios described in the EXISTING Requirements section MUST pass

workspaces/boost/openspec/changes/pluggable-ai-platform-architecture/specs/provider-abstraction/spec.md

@@ -42,7 +42,7 @@ Providers register via a Backstage extension point, requiring zero Boost source
 
 ### Requirement: AI Provider Service Ref for Cross-Plugin Consumption
 
-Other Backstage plugins must be able to consume the active AI provider via Backstage's dependency injection, not just register providers.
+Other Backstage plugins MUST be able to consume the active AI provider via Backstage's dependency injection, not just register providers.
 
 #### Scenario: External plugin consumes active AI provider
 
@@ -61,7 +61,7 @@ Other Backstage plugins must be able to consume the active AI provider via Backs
 
 ### Requirement: Shared Types in Common Package
 
-Provider interfaces and conversation types must live in the common package so both frontend and backend can consume them without circular dependencies.
+Provider interfaces and conversation types MUST live in the common package so both frontend and backend can consume them without circular dependencies.
 
 #### Scenario: AgenticProvider types moved to common
 

workspaces/boost/openspec/changes/pluggable-ai-platform-architecture/specs/provider-hot-swap/spec.md

@@ -48,7 +48,7 @@ The frontend detects provider changes and performs a full state reset.
 
 ### Requirement: Capability-Driven Rendering Replaces Provider ID Checks
 
-Frontend layout decisions must use the `ProviderCapabilities` interface, not provider identity strings.
+Frontend layout decisions MUST use the `ProviderCapabilities` interface, not provider identity strings.
 
 #### Scenario: Layout adapts via capabilities not provider ID
 

workspaces/boost/openspec/changes/pluggable-ai-platform-architecture/specs/provider-packaging/spec.md

@@ -8,7 +8,7 @@ Each AI platform provider must be packaged as an independent Backstage backend m
 
 ### Requirement: ResponsesApiProvider as Backstage Backend Module
 
-The Llama Stack provider is packaged as an independent Backstage backend module that registers via the extension point.
+The Llama Stack provider MUST be packaged as an independent Backstage backend module that registers via the extension point.
 
 #### Scenario: Module registration
 
@@ -40,7 +40,7 @@ The Llama Stack provider is packaged as an independent Backstage backend module
 
 ### Requirement: KagentiProvider as Backstage Backend Module
 
-The Kagenti provider is packaged as an independent Backstage backend module.
+The Kagenti provider MUST be packaged as an independent Backstage backend module.
 
 #### Scenario: Module registration
 
@@ -67,7 +67,7 @@ The Kagenti provider is packaged as an independent Backstage backend module.
 
 ### Requirement: Standalone Toolkit Packages
 
-Provider-internal subsystems with zero Backstage coupling are extracted as standalone packages.
+Provider-internal subsystems with zero Backstage coupling MUST be extracted as standalone packages.
 
 #### Scenario: toolscope extracted as standalone package