-
-
Notifications
You must be signed in to change notification settings - Fork 0
Testing Requirements
GraphEntityEntity/GraphRelationshipEntity persist with all fields, workspace isolation, cascade delete, FK validation, and RemoveVector correctness.
IngestTextAsync creates document + chunks, generates embeddings, registers vectors, handles empty content, defaults SourceType/SourceKey, and optionally triggers reindex.
ListDocumentsAsync pagination and filtering, GetDocumentChunksAsync ordering, DeleteDocumentAsync cascade and vector cleanup.
Create/Get/Update/List/Delete for entities and relationships with ID generation, timestamp management, FK validation, cascade behavior.
All CQRS command and query handlers delegate to IGraphRagService and wrap results in Result.
All 14 controller actions return correct HTTP status codes, content types, and error responses.
MCP tools serialize correctly, REPL workflow delegates to ContextClient, McpAgent tool adapter exposes all 14 tools.
Given configurable RepoRoot/Todo paths, when service starts, then path resolution is correct.
Given TODO API operations, when create/update/delete/query run, then contracts remain stable.
Given multi-tenant workspace configuration, when requests are made with different X-Workspace-Path headers, then data remains isolated per workspace on the single shared port.
Given vector + FTS data, when context search executes, then hybrid results are returned.
Given GitHub sync enabled, when issue sync runs, then ISSUE-* mapping is consistent.
Given STDIO mode, when tool requests are sent, then parity with HTTP behavior is preserved.
Given workspace registration, when a workspace is created, then its directory scaffold is created and an AGENTS-README-FIRST.yaml marker file is written to its root pointing to the shared host port.
Given tool registry with tags, when keyword search runs with a singular or plural term, then matching tools from both global and workspace scopes are returned. Given default buckets in config, when the server starts for the first time, then buckets are seeded and idempotent on subsequent starts.
Given per-workspace auth tokens and X-Workspace-Path header resolution, when a request to any /mcpserver/* endpoint lacks X-Api-Key, then the server returns 401. When a valid token is provided, workspace resolution uses the three-tier chain: X-Workspace-Path header → API key reverse lookup → default workspace.
Given valid pairing credentials, when the /pair login flow completes, then an HttpOnly session cookie is issued and the API key is returned. Given constant-time comparison, when two passwords of the same length differ by one character, then timing side-channel is not exploitable.
Given a configured tunnel provider, when the hosted service starts, then the tunnel process launches and GetStatusAsync returns a public URL. When the service stops, the process is terminated within 5 s.
Given an MCP client connecting to /mcp-transport, when a tool call is made, then the response is semantically equivalent to the corresponding REST endpoint result. Given a request without the required Accept header, then the endpoint returns 406.
Given a workspace, when StartAsync completes, then AGENTS-README-FIRST.yaml exists at the workspace root with the shared host port, endpoint paths, and auth token. When StopAsync completes, then the marker file is removed.
Given a TODO item with a title and description, when RequirementsService.AnalyzeAsync is called, then ExtractRequirementIds correctly parses both JSON-block and regex-fallback response formats and returns distinct, non-empty FR/TR ID lists.
Given a Markdown file with a # Session Log - {title} header, when MarkdownSessionLogParser.TryParse is called, then it returns a UnifiedSessionLogDto with matching title, model, status, and at least one entry. Given a file without the header, then TryParse returns null.
Given a CQRS Dispatcher with a registered command handler, when SendAsync is called with a valid command, then the handler is invoked and Result<T>.IsSuccess is true with the expected value.
Given a CQRS command handler that returns Result.Failure(error), when the Dispatcher processes the result, then it logs at Warning level with the error message and correlation context.
Given a CQRS command handler that throws an exception, when the Dispatcher catches it, then Result<T>.IsFailure is true, Result<T>.Exception is set, and the Dispatcher logs at Error level with exception details.
Given a new CorrelationId, when Next() is called multiple times, then the base ID remains stable and the counter increments sequentially. Given a correlation string "12345678.3", when CorrelationId.Parse is called, then BaseId is 12345678 and the counter is 3.
Given a CallContext used as ILogger, when LogInformation is called, then the log entry is captured in CallContext.LogEntries with the correct level, message, and timestamp. Given the Dispatcher's ILoggerProvider, when a DispatcherLogger emits a log with a correlation scope, then the structured output includes correlationBaseId and correlationStep as separate fields.
Given two pipeline behaviors registered in order, when a command is dispatched, then the first behavior's pre-processing runs before the second, and the second's post-processing runs before the first's. Given a behavior that returns Result.Failure without calling next, then the handler is never invoked.
Given an empty database, when AgentService.SeedBuiltInDefaultsAsync is called, then 7 built-in agent definitions are created. Given a database already containing built-in agents, when SeedBuiltInDefaultsAsync is called again, then no duplicates are created (idempotent).
Given the AgentService, when UpsertDefinitionAsync creates a new definition and GetDefinitionAsync retrieves it, then all fields match. When DeleteDefinitionAsync is called on a non-built-in definition, then it succeeds. When called on a built-in definition, then it returns IsFailure with an appropriate error.
Given a workspace with an agent configured, when BanAgentAsync is called with Global = false, then only that workspace's agent is banned. When called with Global = true, then all workspaces with that agent are banned. When UnbanAgentAsync is called, then the agent is re-enabled.
Given a Director LoginHandler, when the device authorization flow completes successfully, then Result<LoginResult>.IsSuccess is true and the token is cached. When the flow times out, then Result<LoginResult>.IsFailure with an appropriate error.
Given a Director LaunchAgentHandler, when the agent is enabled and not banned, then the agent process is spawned and Result<LaunchResult>.IsSuccess. When the agent is banned, then Result<LaunchResult>.IsFailure with a ban reason.
Given a Director InitWorkspaceHandler, when called on a valid workspace path, then agents.yaml is created and agents are registered via the MCP Server API. When the workspace path doesn't exist, then Result.IsFailure.
Given a Director BanAgentHandler, when called with a valid agent ID and reason, then the MCP Server API is called to ban the agent and a Ban event is logged. When the agent doesn't exist, then Result.IsFailure.
Given seeded canonical requirements docs, when RequirementsDocumentService loads them, then FR/TR/TEST/mapping entries are parsed correctly and generated Markdown preserves the canonical header and entry formats.
Given /mcpserver/requirements CRUD endpoints, when an FR entry is created, generated via /mcpserver/requirements/generate?doc=functional, and deleted, then the generated document reflects each mutation and the deleted entry is no longer returned.
Given /mcpserver/requirements/generate?doc=all, when the endpoint is called, then it writes Functional-Requirements.md, Technical-Requirements.md, Testing-Requirements.md, TR-per-FR-Mapping.md, and Requirements-Matrix.md to the workspace, preserves existing matrix rows, appends missing FR/TR/TEST IDs, and returns export metadata.
Given concurrent requirement mutations, when RequirementsDocumentService persists updates, then writes remain atomic and the resulting Markdown files remain parseable without temp-file residue.
Given MCP STDIO requirements tools (requirements_list, requirements_generate, requirements_create, requirements_update, requirements_delete), when agents invoke them, then results are semantically equivalent to the corresponding REST requirements endpoints.
Given the three-tier workspace resolution chain, when X-Workspace-Path header is present, then it takes priority over API key reverse lookup; when absent, API key resolves workspace; when neither is present, the default workspace is used.
Given EF Core global query filter on WorkspaceId, when entities are inserted for workspace A and queried from workspace B context, then workspace A's entities are not visible from workspace B.
Given the Director client with WorkspacePath set, when API calls are made, then the X-Workspace-Path header is sent on all requests and workspace switching only changes the header, not the base URL.
Given the typed client library with McpServerClientOptions.WorkspacePath set, when requests are sent, then the X-Workspace-Path header is present alongside X-Api-Key.
Given a TODO item in workspace A, when POST /mcpserver/todo/{id}/move is called with targetWorkspacePath pointing to workspace B, then the item is created in workspace B with all fields preserved and deleted from workspace A. Given an invalid target workspace path, then the endpoint returns 400.
Given voice conversation endpoints, when a session is created with a DeviceId, then GET /mcpserver/voice/session?deviceId= returns the active session. When DELETE is called, then the session is destroyed and subsequent status queries return 404.
Given an active voice session, when POST /mcpserver/voice/session/{id}/turn is called with transcript text, then a VoiceTurnResponse is returned with assistant text. When POST /mcpserver/voice/session/{id}/turn/stream is called, then SSE events are streamed with type values of chunk, tool_status, done, or error.
Given a voice session with SessionIdleTimeoutMinutes configured, when the session is idle beyond the timeout, then the IdleShutdownCommand is sent and the session is terminated. Given a device with an active session, when a new session is requested for the same device, then the existing session is returned (one-per-device enforcement).
Given a Windows service running as LocalSystem, when DesktopProcessLauncher.LaunchWithStdio is called, then a process is created on the interactive desktop with redirected stdio pipes via CreateProcessAsUser. Given LaunchVisible, then a visible console window is created.
Given an appsettings.yaml file with configuration overrides, when the server starts, then YAML values override appsettings.json values for matching keys. Given the YAML file is absent, then startup succeeds using JSON configuration only.
Given the template service with a YAML file, when GET /mcpserver/templates is called with optional category, tag, and keyword query parameters, then a filtered list of PromptTemplate items is returned. When no filters are provided, all templates are returned.
Given a valid PromptTemplateCreateRequest, when POST /mcpserver/templates is called, then a new template is persisted to YAML and returned with 201 Created. When a duplicate ID is submitted, then 409 Conflict is returned. When PUT /mcpserver/templates/{id} is called with partial update fields, only specified fields are changed. When DELETE /mcpserver/templates/{id} is called, the template is removed.
Given a stored template with Handlebars content and declared variables, when POST /mcpserver/templates/{id}/test is called with variable values, then PromptTemplateTestResult contains the rendered content. When required variables are missing, then MissingVariables is populated and Success is false. When POST /mcpserver/templates/test is called with inline template content, the inline content is rendered without requiring a stored template.
Given the Director TUI with a Templates tab, when TemplateListViewModel.RefreshCommand executes, then the CQRS ListTemplatesQuery flows through ListTemplatesQueryHandler → ITemplateApiClient → TemplateClient → REST API and populates the table view. When a template is selected and the test action is invoked via TemplateDetailViewModel, then TestTemplateQuery renders the template and displays output.
Given FileMarkerPromptProvider with a valid templates/default-marker-prompt.hbs.yaml file, when GetGlobalPromptTemplateAsync is called, then the template content is returned and cached. When the file is missing, then null is returned and MarkerFileService.DefaultPromptTemplate is used as fallback.
Given TodoPromptProvider with todo prompt templates stored in IPromptTemplateService by well-known IDs (todo-status-prompt, todo-implement-prompt, todo-plan-prompt), when the provider is queried, then file-loaded content is returned. When templates are missing from the store, then TodoPromptDefaults built-in constants are returned as fallback.
Given PairingHtmlRenderer with pairing HTML templates stored in IPromptTemplateService by well-known IDs (pairing-login-page, pairing-key-page, pairing-not-configured-page), when rendering methods are called with substitution parameters, then {errorBanner}, {apiKey}, and {serverUrl} tokens are replaced. When templates are missing, then PairingHtml static method output is returned as fallback.
Given Mcp:AgentPool:Agents configuration, when options bind and validate, then each definition accepts AgentName, AgentPath, AgentModel, AgentSeed, AgentParameters, IsInteractiveDefault, IsTodoPlanDefault, IsTodoStatusDefault, and IsTodoImplementDefault. Duplicate AgentName values (case-insensitive) or ambiguous defaults fail validation.
Given one-shot or interactive requests with no AgentName, when context is Plan, Status, Implement, or AdHoc, then the default agent mapped for that intent is selected. Given an explicit AgentName, explicit assignment overrides default routing.
Given one-shot request payloads, when both promptTemplateId and ad-hoc promptText are supplied or both are missing without resolvable context template, then the API returns 400. Given template-resolved mode, missing id returns 400.
Given one-shot context without template ID, when context is Plan, Status, or Implement, then existing context-based template resolution is used. Given context AdHoc without template ID and no ad-hoc prompt text, then the API returns 400.
Given prompt resolution requests with template ID, caller values, workspace-context values, and id, when rendering executes, then output includes {id} substitution and caller values override workspace-context values on key conflicts.
Given no eligible pooled agent is idle, when one-shot requests are enqueued, then requests remain queued and transition to processing once an eligible agent becomes available, followed by terminal states (completed, failed, or canceled).
Given queue operations, when move up/down is requested for queued items, then order changes correctly; when requested for the currently processing item, the operation is rejected. Cancel/remove semantics correctly update queue state and persisted metadata.
Given pool lifecycle transitions, when queued/processing/completed/failed events occur, then notification SSE emits events in order with payload fields AgentName, LastRequestPrompt, and SessionId.
Given multiple clients connected to a read-only response stream, when one client disconnects, then remaining subscribers continue receiving stream data and active pooled work is unaffected.
Given a pooled agent processing a one-shot request, when an interactive voice connection targets that agent, then interactive linkage is established without canceling or reassigning the one-shot operation.
Given an interactive stream connection, when the client disconnects, then User is AFK. is sent to the agent. When the client reconnects and stream establishment completes, then User is here. is sent. These messages are not sent for one-shot sessions.
Given Director Agent Pool tab actions (connect, recycle, stop/start, queue move up/down, cancel/remove, free-form enqueue), when invoked from UI commands, then the correct REST endpoints are called and UI state refreshes from server snapshots and notifications.
Given McpServer.Support.Mcp stateful services and registries, when architecture validation runs, then each authoritative data source is DI-owned (singleton/scoped), no stateful service is created outside DI, change notifications use INotifyPropertyChanged, and consumers pull current state from the source-of-truth service.
Given TODO create/update and session log submit/append requests, when IDs violate canonical naming formats (TODO persisted ids: ^[A-Z][A-Z0-9]*(?:-[A-Z0-9]+)+-\d{3}$ or ^ISSUE-\d+$, sessionId: <Agent>-<yyyyMMddTHHmmssZ>-<suffix>, requestId: req-<yyyyMMddTHHmmssZ>-<slugOrOrdinal>), then APIs reject with validation errors and no data mutation occurs; valid IDs are accepted across YAML and SQLite TODO backends.
Given ChannelChangeEventBus, when events are published with zero, one, or multiple subscribers, then publish does not throw and each active subscriber receives events independently; canceled subscriptions stop enumeration.
Given TODO, session log, and repo mutation services, when create/update/delete-style operations succeed, then each service publishes one change event with the expected category/action/entityId values.
Given extended mutation services (ToolRegistryService, WorkspaceService, AgentService), when representative create/update operations succeed, then each service publishes the expected category/action event.
Given GET /mcpserver/events, when a client subscribes, then the response content type is text/event-stream.
Given GET /mcpserver/events?category=todo, when a TODO change event is published, then the stream includes an event: todo payload containing the matching entity ID.
Given category filtering on /mcpserver/events, when non-matching categories are published, then filtered subscribers do not receive those non-matching domain events.
Given workspace-scoped GitHub auth endpoints, when a token is set via PUT /mcpserver/gh/auth/token, then GET /mcpserver/gh/auth/status reports hasStoredToken=true; when DELETE /mcpserver/gh/auth/token is called, the token is removed.
Given GitHub OAuth bootstrap endpoints, when GET /mcpserver/gh/oauth/config is called, then effective configuration fields are returned; when OAuth is not fully configured, GET /mcpserver/gh/oauth/authorize-url returns 400 with a clear error.
Given GitHubCliService with a stored workspace token, when GitHub commands are executed, then IProcessRunner receives a ProcessRunRequest containing GitHubTokenOverride; when no token exists and fallback is enabled, standard CLI execution is used.
Given GitHub Actions workflow operations, when list/detail/rerun/cancel paths are invoked, then gh CLI commands and REST/client contracts for /mcpserver/gh/actions/runs* remain consistent and parse expected run/job/step metadata.
Given natural-language workspace policy directives, when POST /mcpserver/workspace/policy or workspace_policy_apply is invoked with valid directives, then targeted workspace ban lists are mutated and invalid directives return structured 400 errors.
Given audited copilot decoration, when invoke and streaming operations execute, then session-log submissions include copilot_invocation actions and completed status records.
Given ingestion options without the required new-project allowlist patterns, when host configuration post-processing runs, then src/McpServer.Cqrs, src/McpServer.Cqrs.Mvvm, src/McpServer.UI.Core, and src/McpServer.Director glob patterns are enforced; marker prompt output includes the Available Capabilities section for these projects.
Given direct website URL ingestion requests, when POST /mcpserver/context/ingest-website or context_ingest_website runs, then valid HTTP/HTTPS pages ingest as external-web sources, URL outcomes are returned, SSRF/private/link-local targets are blocked, redirects are bounded, and source dedup/update behavior is preserved by source key.
Given a .NET 9 host application that registers the hosted Microsoft Agent Framework library against an MCP Server workspace, when the built-in agent workflow runs, then session log turns are created/updated through canonical identifiers, TODO plan/status/implementation operations execute through the existing MCP Server contracts, repository read/list/write tools browse repo-relative paths without host-specific glue code, local desktop process launch reuses the authenticated workspace desktop-launch contract, mcp_powershell_session_* tools execute commands inside a persistent in-process PowerShell session hosted by the agent itself, and host applications can drive the same local runspace interactively through IMcpHostedAgent.PowerShellSessions.
Given representative controller and middleware failure paths across the server, when an unhandled exception produces HTTP 500, then the response body contains a non-empty detailed error description for the failed operation, excludes secrets and raw stack traces, and remains consistent across endpoints through the shared error-handling path.
Given the admin configuration management surface, when configuration values are read or patched through the configuration controller and YAML helper, then effective settings are exposed as flattened key-value pairs, submitted YAML-backed keys are persisted and reloaded, and standard JWT Bearer admin authorization keeps the endpoints unavailable when OIDC is disabled.
Given a TODO create request with id ISSUE-NEW, when GitHub issue creation succeeds, then the server persists the TODO using the canonical ISSUE-{number} id returned by GitHub, includes GitHub correlation metadata in the TODO note, and returns the canonical id from the create surface instead of the temporary alias.
Given workspace-scoped GitHub CLI execution, when gh commands run with either a stored workspace token or fallback authentication, then the process runner receives the resolved workspace root as the working directory.
Given an existing ISSUE-{number} TODO updated through any server TODO update surface, when the local update succeeds, then the server preserves the existing description, syncs title/state/priority metadata back to GitHub using canonical priority: HIGH|MEDIUM|LOW labels, and posts a GitHub issue comment describing the applied change set.
Given an ISSUE-NEW TODO created through the HTTP API, when GitHub-origin comments are added and GitHub-to-TODO sync runs, then the TODO note gains the generated GitHub comment section without altering the TODO description. When the TODO priority changes and a TODO-authored note comment is appended, then the GitHub issue receives the canonical updated priority label and a GitHub comment containing the appended note text. When the GitHub issue is later closed externally and GitHub-to-TODO sync runs again, then the TODO is marked done.
Given an empty authoritative SQLite TODO store and an existing TODO.yaml, when initialization runs and later authoritative mutations project back to YAML, then bootstrap import, deterministic projection ordering, projection-only YAML behavior, and preservation of notes, completed, and code-review-remediation metadata are all verified by automated tests.
Given a TODO item mutated through create/update/delete and queried through storage, REST, typed client, and integration surfaces, when audit history is requested, then append-only ordered states, delete-history retention, not-found behavior, and explicit projection-failure classification are all verified by automated tests.
Given a Parseable-bound log event with more than 250 structured properties and user properties that collide with reserved Parseable field names, when ParseableEventFormatter serializes the event, then the payload contains at most 250 top-level fields, canonical reserved metadata is preserved, and overflow non-reserved properties are deterministically omitted.
Given the repository Azure DevOps pipeline definition, when tracked paths change on main or develop or through a pull request, then azure-pipelines.yml triggers the core CI workflow, runs config validation/build/test/docs/MSIX/package jobs with the documented branch and variable gates, and skips optional feed/docs publication safely when the required Azure DevOps variables are absent.
Given a PowerShell McpSession workspace with an active session cached in .mcpSession/current-session.json, when the legacy .mcpServer/session.yaml wrapper is missing and the module is reinitialized or resolves a session without an explicit Session argument, then it reuses the cached current session object and session ID. When the session is completed, both cache files are removed.
Given trust-bootstrap marker rendering and the public PowerShell bootstrap modules, when the marker signature is valid and /health echoes the submitted nonce exactly, then McpSession, McpTodo, and McpContext initialize successfully and proceed with MCP usage. When the signature is invalid or the nonce does not match, then each bootstrap module emits MCP_UNTRUSTED, does not probe additional endpoints, and aborts MCP usage before session-log or TODO traffic continues.
Given the provider-factory, native encryption, and maintenance-command workstreams, when SQLite, PostgreSQL, and SQL Server are configured for clean-database integration runs, then provider-specific migrations apply successfully and the live encryption state matches the configured state. When encryption is enabled or disabled on an existing database, then the provider-specific transition workflow shall expose a no-data-loss maintenance procedure and dry-run plan before mutation, with automated dry-run tests covering SQLite SEE, PostgreSQL pg_tde, and SQL Server TDE command generation. SQL Server provider and migration integration coverage shall use self-managed SQL Server LocalDB instances that are created and torn down by the test harness, while SQL Server TDE validation shall run against a separate non-LocalDB SQL Server target because LocalDB cannot validate TDE.
Given a Byrd execution TODO, when unit tests are not defined, then the service rejects transition to Implementing; when unit tests are defined through the test-plan API, then the TODO advances to TestReady.
Given a Byrd execution TODO linked to requirements, session turns, and modified files, when bounded execution context or checkpoint delta context is requested, then the server returns only concise snippets, recent turn summaries, relevant files, artifacts, commits, and updated next action for that TODO.
Given the Byrd execution REST controller, STDIO MCP tools, typed client, and adb_step surface, when representative phase creation, active TODO lookup, status progression, and screenshot validation calls are executed, then structured contracts remain stable and Android validation results are returned without arbitrary shell passthrough.
Given requirements export with doc=all and format=wiki, when generation runs, then docs/Project/wiki contains both azure/ and github/ folders, each manifest includes generatedAtUtc, Azure includes .order, and GitHub includes _Sidebar.md and _Footer.md.
Given wiki ingest with Azure and GitHub document folders, when manifest and file modified timestamps identify a newer source, then import selects that source; when the two checks disagree, import fails unless preferredWikiFormat is supplied.
Given the REPL requirements workflow, when wiki export or import is invoked, then export returns format, docType, generatedAtUtc, outputRoot, and written file metadata, and import accepts path-keyed documents with per-document timestamps.
Given Codex, Claude Code, Copilot, and Cline agent plugins, when requirements wiki workflows are used, then each plugin exposes the wiki requirements contract and routes generate/ingest envelopes without expecting archive bytes.
Question CRUD (happy, validation, 404).
Answer CRUD (orphan rejection on deleted question, cascade delete).
Accept-answer flow (single-accept invariant, un-accept clears).
Tag filter AND-semantics + empty-result case.
Vote increment / decrement on Question and Answer; concurrency atomicity.
Comment thread create / list / delete with depth-cap enforcement.
FAQ endpoint projection shape, ordering, deeplink format.
Search: created question/answer text is found via IContextSearchService; removed on delete.
Author resolution precedence (body > API key > JWT > anonymous-rejected).
Workspace isolation (mirror EfTodoService_WorkspaceIsolationTests).
MCP STDIO tool parity for each REST endpoint.
QaClient end-to-end against CustomWebApplicationFactory.
QaWorkflow unit tests in tests/McpServer.Repl.Core.Tests (NSubstitute over QaClient); REPL agent-stdio integration test in tests/McpServer.Repl.IntegrationTests that spawns the host with ReplChildProcessHelper, sends a workflow.qa.* YAML envelope, asserts the response shape.
PowerShell module Pester tests (if a tools/powershell/tests/ pattern exists, otherwise smoke-script invoked from ./build.ps1 Test or a new ValidatePowerShell target).
Skill smoke test: each new qa/SKILL.md is loaded by the plugin packager and its frontmatter passes the standard skill validation script in each plugin repo.
Audit emission tests: one audit row per mutation, correct Action, Version monotonic per (EntityKind, EntityId), Actor populated via IQaAuthorResolver, SnapshotJson round-trips.
Audit query tests: paging contract, filter combinations, empty-result case, workspace isolation (audits from workspace A invisible to workspace B).
Vote audit: an UPDATE ... SET VoteCount = VoteCount + @delta plus an audit row are emitted in a single transaction (both succeed or both rollback). Audit row's Actor is populated from IQaAuthorResolver, so voter identity is captured per event.
Answer-with-sources: round-trip CreateAnswerRequest.Sources -> AnswerEntity.SourcesJson -> AnswerDto.Sources; FAQ projection includes the sources array; deletion of an answer hard-deletes the sources via the existing cascade.
Skill mandate text test: each sibling-plugin skills/qa/SKILL.md contains the exact mandatory rule block (regex match on the callout) and the sources[] schema example. Validation is a small PowerShell or dotnet test content-check (tests/McpServer.Qa.Validation/SkillMandateTests.cs or a tools/plugin-skill-check.ps1 invoked from ./build.ps1 Test).
Close / duplicate flow tests: close-with-reason, reopen, mark-as-duplicate (canonical link both ways), FAQ excludes closed by default, FAQ surfaces duplicate redirect when requested with ?includeClosed=true, audit rows captured per transition.
Sanitization test corpus: XSS-payload corpus validates that every common attack vector is stripped on Question/Answer/Comment write; bodyHtml contains only allow-listed tags/attributes; raw body is preserved verbatim; round-trip Markdown -> HTML matches snapshot.
FAQ wiki page generation test: build target produces deterministic Markdown matching the snapshot fixture, wiki index files updated, generated page renders cleanly in both Azure DevOps and GitHub wiki conventions (e.g., _Sidebar.md / .order references present).
Voter-history endpoint: posting N votes from M distinct actors produces N audit rows; GET /questions/{id}/voters returns exactly those rows projected to { actor, action, createdAt }; same for answers; workspace isolation enforced.
One-vote-per-user enforcement: same actor posts vote_up twice -> second call is no-op (no counter change, no second audit row); actor posts vote_up then vote_down -> counter delta is -2, audit row recorded with action vote_change; actor revokes vote -> counter delta is -1, audit row vote_revoke; unique index prevents duplicate QaVoteEntity rows under concurrent calls (test with parallel writes against in-memory SQLite using Task.WhenAll).
Current vote state endpoint: GET /questions/{id}/votes returns one row per active voter from QaVoteEntity after a sequence of apply / change / revoke calls; revoked voters do not appear; workspace isolation enforced.
Hub-and-spoke federation tests cover config role defaults, durable proxy/workspace/operation storage, hub enrollment and status, LocalProxy /mcp-transport routing, operation headers, queued write fallback, replay candidate persistence, stale-version conflict creation, and provider migration compilation.
Acceptance Criteria:
- Adapter diagnostics tests fail if any required domain is uncovered or reports incorrect local-only/apply-supported status.
- Proxy tests prove live-forwarded domains keep working and only replayable mutating requests are queued during hub outage.
- Topology tests prove stale base-version operations create conflicts and suppress fanout.
- Replay and fanout tests prove signed envelopes are verified before local apply.
Given templates/prompt-templates.yaml, when the marker-template contract tests run, then default-marker-prompt contains the frontier-to-implementation planning guidance, explicit requirements capture guidance, and TDD unit-test planning guidance.
Unit tests must fail red until WorkspaceService is database-authoritative and DbForeignKeyContractTests prove every WorkspaceId entity has a Workspaces FK with non-cascade delete behavior.
Unit tests must fail red until persistent delete paths preserve rows through soft-delete metadata and every mutable entity writes DataAuditLog rows for create, update, and soft-delete operations.
Unit and provider tests must fail red until TODO requirement links and requirement traceability links enforce FKs, missing requirements are backfilled, and SQLite, SQL Server, and PostgreSQL migrations preserve data.
Add or update a documentation contract test proving docs/Development-Process-draft-v3.md captures the plan creation requirements for decision-complete frontier-model handoff plans, FR/TR/TEST traceability, TDD-first red/green behavior, and zero-failure zero-skip Byrd gates.
Bats coverage must prove workflow.requirements.updateFr, updateTr, and updateTest accept priority changes and do not fail inside the Codex plugin wrapper.
Validate that outstanding-session consolidation creates MCP-backed requirements and TODO traceability, inventories dirty workspaces, preserves unrelated changes, blocks unsafe deploys, and records zero-failure zero-skip validation gates before completion.
Given a TODO description containing Markdown headings, lists, code fences, blank lines, leading indentation, and trailing content, create, update, read, audit, and projection paths preserve the exact meaningful formatting with zero failures and zero skips.
Automated tests shall verify client request serialization, controller mixed-batch acceptance and whole-batch rejection, repository transaction rollback, and REPL schema validation for requirements batch commands.
Plugin validation shall include shell syntax checks, Cline bridge JSON-stdio tests, Cline schema preflight tests, and JSON Schema parse checks for the published REPL request schema.
Given agent-facing documentation, marker templates, pipeline references, and generated requirements wiki outputs, automated tests shall verify single-line JSON stdio guidance, current plugin registry guidance, existing pipeline file references, and Azure/GitHub wiki output file parity.
Build.Tests SHALL verify build.ps1 relaunches through a PowerShell host with -NoLogo, -NoProfile, and -NonInteractive, Build.Tests pwsh.exe helpers include those flags, and live deployment guidance examples include those flags.
Bats validation covers AC-SKILLS-001 through AC-SKILLS-006 for mcpserver-codex-plugin, mcpserver-claude-code-plugin, mcpserver-claude-cowork-plugin, mcpserver-copilot-plugin, and mcpserver-grok-plugin.
Acceptance Criteria:
- Every target plugin contains non-empty SKILL.md files for sync-logs, commit-sync, and wrap-up. (evidence: Codex manifest Bats, Copilot skills Bats, and full Claude Code, Cowork, and Grok skills Bats passed.)
- Every new skill has YAML frontmatter with name and description. (evidence: Shell Bats workflow skill frontmatter assertions passed.)
- sync-logs documents status check, session/turn handling, dialog/action appends, background-session discovery, factual summary, and no raw REST. (evidence: Shell Bats sync-logs AC-SKILLS-003 assertions passed.)
- commit-sync documents pause, repo-scope report, explicit acknowledgement, full dirty-tree staging, commit SHA capture, push result, and no force/rewrite behavior. (evidence: Shell Bats commit-sync AC-SKILLS-004 assertions passed.)
- wrap-up documents marker trust, requirement reconciliation, wiki export, validation, commit/push, session-log reconciliation, and turn completion/failure. (evidence: Shell Bats wrap-up AC-SKILLS-005 assertions passed.)
- Manifests or package files expose/package the new skills using each plugin's existing convention. (evidence: Codex/Claude/Grok skillsPath, Copilot skill entries, and Cowork skills directory convention validated.)
Jest validation covers AC-SKILLS-001 through AC-SKILLS-006 for mcpserver-cline-plugin, mcpserver-cline-v2-plugin, and mcpserver-opencode-plugin.
Acceptance Criteria:
- Every target plugin contains non-empty SKILL.md files for sync-logs, commit-sync, and wrap-up. (evidence: Cline, Cline v2, and OpenCode skills Jest tests passed.)
- Every new skill has YAML frontmatter with name and description. (evidence: TypeScript skills Jest frontmatter assertions passed.)
- sync-logs documents status check, session/turn handling, dialog/action appends, background-session discovery, factual summary, and no raw REST. (evidence: TypeScript sync-logs AC-SKILLS-003 assertions passed.)
- commit-sync documents pause, repo-scope report, explicit acknowledgement, full dirty-tree staging, commit SHA capture, push result, and no force/rewrite behavior. (evidence: TypeScript commit-sync AC-SKILLS-004 assertions passed.)
- wrap-up documents marker trust, requirement reconciliation, wiki export, validation, commit/push, session-log reconciliation, and turn completion/failure. (evidence: TypeScript wrap-up AC-SKILLS-005 assertions passed.)
- package.json exposes or packages the skills directory using the plugin's existing distribution convention. (evidence: package.json files include skills/ and npm build/test passed for all TypeScript plugins.)
Process validation covers red/green/final evidence and the zero-failure zero-skip focused validation gate for the workflow-skill rollout.
Acceptance Criteria:
- Validation tests fail before the skills/manifest changes and pass after implementation, with red and green command output captured in session-log actions. (evidence: Red gate failures and green/final passing commands were run and recorded in session-log actions.)
- Final validation has zero failures and zero skips in the executed focused scope. (evidence: Final Bats/Jest output reported all ok/pass and no skipped tests; git diff --check passed across all modified repos.)
Unit and integration validation shall prove generated requirements exports render TEST descriptions readably and display acceptance criteria as a bulleted list for both GitHub and Azure wiki outputs.
Acceptance Criteria:
- Focused tests fail before the renderer change because wiki testing output still uses dense table rows for descriptions. (evidence: Red run of RequirementsDocumentServiceTests failed on missing TEST-MCP-001 subsection before renderer update.)
- Focused tests pass after the renderer change and assert AC bullets in both GitHub and Azure wiki outputs. (evidence: Focused service test run passed 10 of 10; combined requirements service and AC run passed 15 of 15.)
- Final validation has zero failures and zero skips in the executed scope. (evidence: build Compile succeeded; focused RequirementsDocumentService and RequirementAcceptanceCriteria tests passed 15 of 15; RequirementsControllerTests passed 7 of 7; no skipped tests were reported.)
Regression tests SHALL verify all plugin batch requirement methods accept unindented YAML records, indented YAML records, and inline JSON-array records while preserving nested acceptanceCriteria arrays and boolean isSatisfied fields.
Given a TODO update payload that changes implementationTasks[].done and omits top-level done, when the plugin wrapper builds the TODO update HTTP body, then the body preserves nested task done values and omits parent done so the server cannot accidentally complete the TODO.
Acceptance Criteria:
- Regression test fails if nested implementation task completion is promoted to top-level done. (evidence: Bats output reported ok 1 TODO HTTP body does not promote implementation task done to parent done in all five plugin repositories.)
Given mocked successful and failed session/compact hook dependencies, when SessionStart, SessionEnd, PreCompact, and PostCompact scripts run, then each status-only path emits {} and PostCompact emits no additionalContext.
Acceptance Criteria:
- Hook regression tests assert exact {} output for session-start, session-end, pre-compact, and post-compact. (evidence: tests/hooks.bats passed in the affected plugin repositories with exact-output assertions.)
- Copilot has hook regression coverage equivalent to the affected script surface. (evidence: Added F:\GitHub\mcpserver-copilot-plugin\tests\hooks.bats and passed 6/6.)
Verify GitHubCliService passes command-scoped safe.directory environment variables for workspace-scoped calls and uses gh --repo without workspace cwd when a repository is configured.
Verify the PowerShell wrapper returns a non-zero result with a timeout diagnostic when a plugin helper command hangs beyond TimeoutSeconds, while normal helper wrapper tests still pass.
Regression tests SHALL verify all plugin batch requirement methods accept unindented YAML records, indented YAML records, and inline JSON-array records while preserving nested acceptanceCriteria arrays and boolean isSatisfied fields.
Storage isolation tests SHALL prove Global memories and Workspace memories in two workspaces list as Global plus current workspace only, and that update/remove by ID cannot mutate another workspace-local memory.
CRUD behavior tests SHALL prove add, list, update, remove, soft-delete omission, scope preservation, scope changes, invalid ID, invalid text, invalid category, and invalid scope failures.
ID generation tests SHALL prove MEMORY-{CATEGORY}-{NNN} IDs are globally unique across Global and Workspace scopes, category counters are independent, and manually supplied duplicate active IDs are rejected.
REST/client contract tests SHALL prove MemoryController and MemoryClient route, serialize, and deserialize memory scope, text, ID, and version correctly, and that McpServerClient.Memory propagates workspace and auth settings.
REPL contract tests SHALL prove workflow.memory.add, workflow.memory.list, workflow.memory.update, and workflow.memory.remove dispatch through typed REPL workflow code, support scope values where applicable, and return standard result/error envelopes.
Marker-template contract tests SHALL prove default-marker-prompt contains the MCP Memories section, exact REQUIRED MEMORIES header, memory tool names, ID format, scope guidance, no-secrets guidance, agent-local import safeguards, updatedBy attribution, and session-log action guidance.
Acceptance Criteria:
- Contract tests fail if the marker prompt omits the MCP Memories section, REQUIRED MEMORIES header, memory tool names, ID format, scope guidance, or no-secrets guidance. (evidence: MemoryContractArtifactTests.GeneratedMarkerPrompt_IncludesMemoryInstructions.)
- Contract tests fail if memory context documentation omits agent-local import safeguards, updatedBy attribution, or session-log action guidance. (evidence: MemoryContractArtifactTests.MemoryContextDocumentation_IncludesImportAndAttributionRules.)
YAML schema and stdio contract tests SHALL prove valid workflow.memory.* envelopes pass; add without text fails; add/update with invalid scope fails; update/remove without ID fails; invalid MEMORY ID fails; unknown memory methods fail; and docs/stdio-tool-contract.json includes all memory tools.
Scope ordering tests SHALL prove list surfaces and required-memory injection return Global memories first sorted by ID and Workspace memories second sorted by ID, excluding workspace rows from other workspaces.
Agent plugin validation SHALL prove each supported plugin exposes memory tools and either injects REQUIRED MEMORIES with Global-first ordering at supported request boundaries or documents the host limitation with an explicit memory-list fallback.
Memory federation tests SHALL prove memory adapter diagnostics, /mcpserver/memory domain inference, explicit-ID queued create eligibility, no-ID create rejection, queued memory update/delete replay metadata, signed envelope apply, stale base-version conflict behavior, fanout row creation, recipient apply, workspace ownership enforcement, invalid payload conflicts, version behavior, timestamp preservation, and idempotent soft-delete semantics.
Acceptance Criteria:
- Registry coverage includes memory as covered, non-local-only, and apply-supported.
- Proxy tests prove explicit-ID memory creates queue and no-ID memory creates do not queue.
- Proxy tests prove memory update/delete operations queue with domain memory and the path resource ID.
- Adapter tests prove create preserves ID, scope, workspace ownership, category, raw text, timestamps, and version.
- Adapter tests prove update increments version and preserves workspace ownership.
- Adapter tests prove delete soft-deletes and replayed delete is idempotent.
- Adapter tests prove cross-workspace operations, invalid JSON, and invalid IDs conflict without mutation.
- Federation operation tests prove signed memory envelopes apply, stale versions conflict without overwrite, and hub fanout can be applied by a recipient.
✅ Complete - Given a REPL host process, when a well-formed YAML command envelope is sent to stdin, then a YAML response envelope is emitted to stdout with type: result and the expected result payload. Covered by: Iteration1_IntegrationTests, YamlFramingTests, YamlEnvelopeShapeTests
✅ Complete - Given a REPL host process, when malformed YAML is sent to stdin, then a structured error response is emitted with type: error and descriptive error details, without crashing the host process. Covered by: FakeYamlSerializerTests, YamlFramingTests
✅ Complete - Given a REPL host with no bootstrap invocation, when an operational command is sent, then the response contains type: error and appropriate error code. Covered by: ProtocolHandshakeTests, TrustBootstrapFlowTests
✅ Complete - Given a REPL host, when trust bootstrap is invoked with a valid marker file, then the host verifies the marker signature, performs the health nonce challenge, caches the API key, and returns success. Covered by: TrustBootstrapFlowTests, MarkerFileTrustTests, MockTrustBootstrapServiceTests
✅ Complete - Given a REPL host with completed bootstrap, when the API key in the marker file is rotated, then the host detects rotation via marker file watch and emits appropriate notifications. Covered by: AuthRotationTests, AuthKeyAndWorkspaceTests, StubAuthRotationHandlerTests
✅ Complete - Given bootstrapped REPL commands for TODO operations (workflow.todo.*), when invoked with valid args, then results match the equivalent client operation semantics. Covered by: TodoWorkflowTests, Iteration3IntegrationTests, TodoWorkflowTestExtensions
✅ Complete - Given bootstrapped REPL commands for session log operations (workflow.session.*), when invoked with valid args, then results match the equivalent client operation semantics. Covered by: SessionLogWorkflowTests, SessionLogWorkflowIntegration2Tests, SessionLogWorkflowProductionTests, Iteration2IntegrationTests
Given TryResolveWithDiagnostics with a workspace path containing no marker file, when called, then the error message enumerates every directory walked from the start path to its root. Covered by: MarkerFileClientOptionsResolverTests.TryResolveWithDiagnostics_WhenMarkerMissing_EnumeratesSearchedPaths
Given an explicit workspacePathOverride pointing to a workspace with a valid marker, when TryResolveWithDiagnostics is called, then resolution succeeds and the returned options carry the marker's API key. Covered by: MarkerFileClientOptionsResolverTests.TryResolveWithDiagnostics_AcceptsExplicitWorkspaceArgument
Given a marker file whose canonicalization is tampered, when TryResolveWithDiagnostics is called, then the error names the marker path and identifies "signature" failure. Covered by: MarkerFileClientOptionsResolverTests.TryResolveWithDiagnostics_WhenSignatureFails_ReportsReason
Given a marker whose HMAC payload is signed with LF-only (\n) line endings (matching the production server's MarkerFileService.AppendPayloadLine), when TryResolveWithDiagnostics is called on Windows or any platform where Environment.NewLine differs from \n, then signature verification succeeds. Covered by: MarkerFileClientOptionsResolverTests.TryResolveWithDiagnostics_VerifiesSignatureBuiltWithLfLineEndings
✅ Complete - Given bootstrapped REPL commands for context operations (client.context.*), when invoked with valid args, then results match the equivalent client operation semantics. Covered by: GenericClientPassthroughTests, Iteration5IntegrationTests
✅ Complete - Given bootstrapped REPL commands for requirements management (workflow.requirements.*), when invoked with valid args, then results match the equivalent client operation semantics. Covered by: RequirementsWorkflowTests, Iteration4IntegrationTests
✅ Complete - Given bootstrapped REPL commands for workspace selection, when invoked with valid workspace paths, then workspace context resolution matches expected behavior. Covered by: WorkspaceSelectionTests, AuthKeyAndWorkspaceTests
✅ Complete - Given generic client passthrough operations, when invoked with valid method/args, then operations delegate to the correct client type and method without duplicating logic. Covered by: GenericClientPassthroughTests, Iteration5IntegrationTests
✅ Complete - Given streaming TODO operations (streamStatus, streamPlan, streamImplement), when invoked, then events stream correctly with proper cancellation handling. Covered by: TodoWorkflowTests (streaming event tests)
✅ Complete - Given a REPL host, when EOF is received on stdin, then the host terminates gracefully. Covered by: EndToEndFlowTests
✅ Complete - Given a workflow operation that throws an exception, when the command is executed, then a structured error response is emitted and the command loop continues. Covered by: SessionLogWorkflowTests, TodoWorkflowTests (error handling paths)
✅ Complete - Given request IDs in command envelopes, when commands are executed, then response envelopes echo the same request ID for request/response matching. Covered by: RequestResponseCorrelationTests, YamlEnvelopeShapeTests
✅ Complete - Given workflow implementations, when registered in DI, then all dependencies are resolved from the container and no services are instantiated via new outside DI. Covered by: McpServerClientIntegrationTests, DI registration tests
✅ Complete - Given workspace selection via workspace selector, when commands target specific workspaces, then workspace context is properly scoped. Covered by: WorkspaceSelectionTests, AuthKeyAndWorkspaceTests
✅ Complete - Given orchestration rules for trust and auth, when workflows execute, then trust-before-auth and nonce-validation rules are enforced. Covered by: OrchestrationRulesTests, TrustBootstrapFlowTests
✅ Complete - Given namespace-organized command shapes, when workflows execute, then operations delegate to typed client contracts without duplicating business logic. Covered by: TodoWorkflowTests, SessionLogWorkflowTests, RequirementsWorkflowTests, GenericClientPassthroughTests
✅ Complete - Given concurrent REPL operations, when workflows maintain stateful context, then session state and TODO selection are properly isolated per workflow instance. Covered by: SessionLogWorkflowTests (state management), TodoWorkflowTests (selection state)
Creating FR/TR/TEST with acceptanceCriteria and reading them back returns an identical AcceptanceCriterion list (id/text/isSatisfied/evidence), workspace-scoped.
Null or empty acceptanceCriteria round-trips as an empty list with no null leakage.
The requirements document renderer emits a deterministic Acceptance Criteria block and the parser tolerates it without throwing.
copy-from-todo copies a TODO's acceptance criteria onto a requirement verbatim.
Bash plugin repl-invoke shim tests cover acceptanceCriteria create/update blocks and copyAcceptanceCriteriaFromTodo dispatch, with focused Bats gates passing for all five Bash plugins.
Acceptance Criteria:
- Codex, Claude Code, Claude Cowork, Copilot, and Grok Bash plugin focused Bats gates pass for acceptanceCriteria and copyAcceptanceCriteriaFromTodo. (evidence: Focused WSL Bats filters returned AC_EXIT=0 and COPY_EXIT=0 for all five Bash plugin repos.)
TypeScript plugin tests cover requirements acceptanceCriteria schemas, typed parameter shaping, and live-equivalent request handling for Cline, Cline v2, and Opencode.
Acceptance Criteria:
- Cline, Cline v2, and Opencode build/test gates pass with acceptanceCriteria coverage. (evidence: Cline and Cline v2 npm build/test passed; Opencode npm build and full Jest passed with coverage thresholds.)
Validate the Bash plugin family emits and hydrates acceptanceCriteria on FR/TR/TEST requirement create/update commands and exposes copyAcceptanceCriteriaFromTodo.
Plugin regression tests prove caller-supplied acceptanceCriteria is not silently lost when requirement create/update responses explicitly report an empty criteria list.
Acceptance Criteria:
- Direct sourced shell assertions pass for all five Bash plugin repos: criteria-only update emits caller criteria, no-criteria create omits criteria, and explicit empty response returns requirements_acceptance_criteria_not_captured. (evidence: Focused shell assertions passed for Codex, Claude Code, Claude Cowork, Copilot, and Grok.)
- Focused Jest tests pass for Cline, Cline v2, and OpenCode covering criteria-only update forwarding and explicit empty-response failure. (evidence: Cline and Cline v2 requirements.test.ts passed; OpenCode complex-tools.test.ts passed with coverage disabled for focused scope after full file tests passed.)
- TypeScript plugin builds pass after the guard is added. (evidence: npm run build passed for Cline, Cline v2, and OpenCode.)
In each bash plugin, tests/repl-invoke-shim.bats (or tests/plugin-helpers.bats) proves typed-params emits acceptanceCriteria on create and hydrates it from existing on partial update with zero failures and zero skips.
Plugin regression tests prove caller-supplied acceptanceCriteria is not silently lost when requirement create/update responses explicitly report an empty criteria list.
Per plugin family, a live invocation of workflow.requirements.createFr with acceptanceCriteria populated round-trips through the deployed server (commit 6d376ea+) and the resulting REST GET returns the structured criteria.
In each TS plugin, tests/requirements.test.ts (or tests/complex-tools.test.ts) proves req_create_fr/req_update_fr/req_create_test forward acceptanceCriteria into the request payload with zero failures and zero skips.
Live criteria round-trip works
Acceptance Criteria:
- Criterion A
- Criterion B (evidence: passed via integration test)
Given a SessionLogService constructed with a non-null WorkspaceContext, when SubmitAsync persists a session, then SessionLogEntity.WorkspaceId and every child entity's WorkspaceId equal the context's WorkspacePath. Covered by: SessionLogServiceTests.SubmitAsync_StampsWorkspaceIdOnSessionEntity, SessionLogServiceTests.SubmitAsync_StampsWorkspaceIdOnEveryChildEntity
Given a SessionLogService constructed with workspaceContext: null and a DbContext without _workspaceId, when SubmitAsync persists a session, then SessionLogEntity.WorkspaceId remains empty string. Covered by: SessionLogServiceTests.SubmitAsync_WithNullWorkspaceContext_KeepsWorkspaceIdEmpty
Given a malformed POST body that fails JSON deserialization against UnifiedSessionLogDto, when the controller returns 400, then the response content-type is application/problem+json and the errors object contains $.workspace (or the offending field path), never the dto parameter name. Covered by: SessionLogControllerTests.WhenPostingMalformedWorkspaceFieldThenReturnsProblemDetailsWithoutDtoKey
Given a POST body missing sourceType, when domain validation rejects it, then the response is application/problem+json with sourceType cited (not the legacy {"error":"..."} plain shape). Covered by: SessionLogControllerTests.WhenPostingMissingSourceTypeThenReturnsProblemDetails
Given a successful POST to /mcpserver/sessionlog, when GET /mcpserver/sessionlog/{agent}/{sessionId} is called under the same workspace context, then the response is 200 OK with the round-tripped session. Covered by: SessionLogControllerTests.WhenPostingThenGetBySessionIdReturnsRecord
Given a session exists, when POST /mcpserver/sessionlog/{agent}/{sessionId}/turn carries a UnifiedRequestEntryDto, then 201 is returned and the subsequent GET shows the appended turn. Covered by: SessionLogControllerTests.WhenPostingTurnViaRestThenTurnIsRetrievable, SessionLogServiceTests.UpsertTurnAsync_NewTurn_AppendsWithoutDeletingSiblings
Given the turn-append route, when PUT is used instead of POST, then 405 is returned with Allow: POST. Covered by: SessionLogControllerTests.WhenPuttingTurnRouteThenReturns405WithAllowHeader
Generated from MCP requirements wiki export.