| name | Requirements Management |
| description | Use when the user asks to "list requirements", "add requirement", "create FR", "create TR", "create test requirement", "generate requirements document", or "ingest requirements". |
| version | 0.1.0 |
Requirements Management
Overview
To manage functional requirements (FR), technical requirements (TR), test requirements (TEST), and their traceability mappings, use this plugin's declared hook/wrapper (or the REPL transport) for the workflow.requirements.* namespace. Do not substitute raw REST calls, generic PowerShell.MCP wrapper, helper modules, or another agent's plugin for normal requirements work.
The plugin wrapper validates documented params and emits single-line JSON to REPL stdio. Any direct REPL diagnostic call must use one single-line JSON request envelope, not formatted YAML.
The database is the source of truth for requirements. Markdown files are import/export projections only. Every operation is scoped to the workspace resolved from the signed marker, and generated workspace output must contain only the requested workspace's FR, TR, TEST, and traceability links.
Initialization
Call workflow.sessionlog.bootstrap through this plugin's declared hook/wrapper to initialize the session log subsystem before issuing any workflow commands. This call is idempotent and should be made once per conversation context.
type: request
payload:
requestId: req-20260409T120000Z-bootstrap-001
method: workflow.sessionlog.bootstrap
params: {}
Requirement Scope Layers
Plugin version 1.13.0 and newer exposes native layer operations. Treat this section as the layer API reference when plugin status reports these methods; do not ask the operator or inspect wrapper source just to learn the parameter shapes.
workflow.requirements.listLayers / req_list_layers / client.Requirements.ListRequirementLayersAsync: omit params.workflow.requirements.createLayer / req_create_layer / client.Requirements.CreateRequirementLayerAsync: required params are key, order, and name; optional params are description and scopeEndLayerKey.workflow.requirements.updateLayer / req_update_layer / client.Requirements.UpdateRequirementLayerAsync: required param is key; optional params are name, description, and scopeEndLayerKey. Layer order is immutable; create a new layer rather than attempting to update order.workflow.requirements.effective / req_effective / client.Requirements.GetEffectiveRequirementsAsync: optional param is layerKey; omit layerKey to use the active workspace layer.
Use camelCase exactly in YAML:
type: request
payload:
requestId: req-20260409T115900Z-listlayers-001
method: workflow.requirements.listLayers
params: {}
type: request
payload:
requestId: req-20260409T115901Z-createlayer-001
method: workflow.requirements.createLayer
params:
key: future
order: 20
name: Future Layer
description: Requirements that are documented but not currently enforceable
type: request
payload:
requestId: req-20260409T115902Z-updatelayer-001
method: workflow.requirements.updateLayer
params:
key: future
name: Future Layer
scopeEndLayerKey: release
type: request
payload:
requestId: req-20260409T115903Z-effective-001
method: workflow.requirements.effective
params:
layerKey: future
FR, TR, TEST, and batch create/update commands also accept requirement scope fields:
scopeStartLayerKey: first layer where the requirement is effective.scopeEndLayerKey: last layer where the requirement is effective; omit for open-ended scope.
Omit both fields for requirements that are effective in the default/current layer.
Requirement ID Conventions
Three ID spaces are in use:
- FR - Functional Requirements:
^FR-[A-Z]+-\d{3}$, e.g. FR-MCP-001, FR-AUTH-042
- TR - Technical Requirements:
^TR-[A-Z]+-[A-Z]+-\d{3}$, e.g. TR-MCP-ARCH-001, TR-AUTH-SEC-002
- TEST - Test Requirements:
^TEST-[A-Z]+-\d{3}$, e.g. TEST-MCP-001, TEST-AUTH-003
All IDs must be uppercase. TR IDs require both an area and a subarea segment; FR and TEST IDs require only an area segment.
Functional Requirements (FR)
Listing FRs
To retrieve a filtered list of functional requirements:
type: request
payload:
requestId: req-20260409T120000Z-listfr-001
method: workflow.requirements.listFr
params:
area: MCP
status: in_progress
All params are optional; omit to return all FRs. The result contains an items array:
type: result
payload:
requestId: req-20260409T120000Z-listfr-001
result:
items:
- id: FR-MCP-001
title: Agent authentication
description: System must authenticate AI agents via API key
status: completed
priority: critical
area: MCP
createdAt: 2026-03-01T10:00:00Z
updatedAt: 2026-04-09T12:00:00Z
totalCount: 1
Valid status values: pending, in_progress, completed, deferred.
Getting a Single FR
To fetch one functional requirement by ID:
type: request
payload:
requestId: req-20260409T120001Z-getfr-001
method: workflow.requirements.getFr
params:
id: FR-MCP-001
Creating an FR
To record a new functional requirement:
type: request
payload:
requestId: req-20260409T120002Z-createfr-001
method: workflow.requirements.createFr
params:
id: FR-MCP-003
title: Context search
description: System must support semantic search across workspace documents
priority: high
area: MCP
notes: Use hybrid search combining BM25 and vector embeddings
Required fields: id, title, description, priority, area. The notes field is optional.
Acceptance Criteria
FR, TR, and TEST create/update commands accept structured acceptanceCriteria entries with the same shape used by TODO execution criteria:
method: workflow.requirements.createFr
params:
id: FR-MCP-XXX-001
title: Acceptance criteria example
description: Requirement records preserve structured pass/fail criteria.
priority: high
area: MCP
acceptanceCriteria:
- id: ac-1
text: Round-trip preserves criterion text
isSatisfied: false
- id: ac-2
text: Evidence is retained when supplied
isSatisfied: true
evidence: tests/Services/RequirementAcceptanceCriteriaTests.cs
To copy criteria from an execution TODO onto a requirement, call workflow.requirements.copyAcceptanceCriteriaFromTodo:
method: workflow.requirements.copyAcceptanceCriteriaFromTodo
params:
kind: fr
id: FR-MCP-XXX-001
todoId: PLAN-MCP-001
This maps to POST /mcpserver/requirements/{kind}/{id}/acceptance-criteria/copy-from-todo with body { "todoId": "PLAN-MCP-001" }.
Batch Create Or Update
When creating or updating multiple records, prefer the atomic batch commands instead of Markdown ingestion. Batch commands accept YAML records: arrays and fail all records if any record is invalid, conflicts, or is missing during update.
Use per-kind commands when every record is the same type:
type: request
payload:
requestId: req-20260409T120002Z-createfr-batch-001
method: workflow.requirements.createFrBatch
params:
records:
- id: FR-MCP-004
title: Batch requirements
description: The system must accept multiple requirement records in one request.
priority: high
- id: FR-MCP-005
title: Atomic validation
description: The system must reject the whole batch when one record is invalid.
priority: high
Use workflow.requirements.updateFrBatch, createTrBatch, updateTrBatch, createTestBatch, and updateTestBatch for per-kind batches. For mixed FR/TR/TEST arrays, use workflow.requirements.createBatch or workflow.requirements.updateBatch and include kind: fr|tr|test on each record.
Updating an FR
To modify an existing FR:
type: request
payload:
requestId: req-20260409T120003Z-updatefr-001
method: workflow.requirements.updateFr
params:
id: FR-MCP-003
status: completed
notes: Implemented with HybridSearchService using all-MiniLM-L6-v2 embeddings
Deleting an FR
type: request
payload:
requestId: req-20260409T120004Z-deletefr-001
method: workflow.requirements.deleteFr
params:
id: FR-MCP-003
Technical Requirements (TR)
TR IDs require both area and subarea segments. The full ID format is TR-<AREA>-<SUBAREA>-###.
Listing TRs
type: request
payload:
requestId: req-20260409T120005Z-listtr-001
method: workflow.requirements.listTr
params:
area: MCP
subarea: PERF
Creating a TR
type: request
payload:
requestId: req-20260409T120006Z-createtr-001
method: workflow.requirements.createTr
params:
id: TR-MCP-PERF-001
title: API response time SLA
description: All API endpoints must respond within 500ms at p99
priority: high
area: MCP
subarea: PERF
notes: Measured at gateway, excluding network transit time
Updating a TR
type: request
payload:
requestId: req-20260409T120007Z-updatetr-001
method: workflow.requirements.updateTr
params:
id: TR-MCP-PERF-001
status: in_progress
notes: Baseline established at 320ms p99 under load test
Deleting a TR
type: request
payload:
requestId: req-20260409T120008Z-deletetr-001
method: workflow.requirements.deleteTr
params:
id: TR-MCP-PERF-001
Test Requirements (TEST)
Listing TEST Requirements
type: request
payload:
requestId: req-20260409T120009Z-listtest-001
method: workflow.requirements.listTest
params:
area: MCP
Creating a TEST Requirement
type: request
payload:
requestId: req-20260409T120010Z-createtest-001
method: workflow.requirements.createTest
params:
id: TEST-MCP-001
title: Agent authentication unit test
description: Verify API key authentication rejects invalid tokens with 401
priority: critical
area: MCP
notes: Uses in-memory EF provider with CustomWebApplicationFactory
Updating and Deleting TEST Requirements
Follow the same pattern as FR: use workflow.requirements.updateTest and workflow.requirements.deleteTest with the same parameter shapes.
Requirement Mappings
Mappings link an FR to one or more TRs and TEST IDs in the current workspace, forming the traceability matrix.
Listing Mappings
type: request
payload:
requestId: req-20260409T120011Z-listmap-001
method: workflow.requirements.listMappings
params:
frId: FR-MCP-001
Creating a Mapping
type: request
payload:
requestId: req-20260409T120012Z-createmap-001
method: workflow.requirements.createMapping
params:
frId: FR-MCP-001
trIds:
- TR-MCP-ARCH-001
testIds:
- TEST-MCP-001
notes: Core authentication flow covered by ARCH constraint and unit test
Legacy single-link trId and testId inputs are accepted for compatibility. Prefer trIds and testIds for all new calls.
The result confirms the stored mapping:
type: result
payload:
requestId: req-20260409T120012Z-createmap-001
result:
item:
frId: FR-MCP-001
trId: TR-MCP-ARCH-001
testId: TEST-MCP-001
createdAt: 2026-04-09T12:00:12Z
notes: Core authentication flow covered by ARCH constraint and unit test
Deleting a Mapping
type: request
payload:
requestId: req-20260409T120013Z-deletemap-001
method: workflow.requirements.deleteMapping
params:
frId: FR-MCP-001
trId: TR-MCP-ARCH-001
Document Generation
To generate formatted requirements documents from the current workspace database slice:
type: request
payload:
requestId: req-20260409T120014Z-gendoc-001
method: workflow.requirements.generateDocument
params:
format: markdown
docType: matrix
Valid docType values:
functional - numbered list of all FR entries with status and descriptiontechnical - numbered list of all TR entries grouped by area/subareatesting - numbered list of all TEST entries with linked FR IDsmatrix - traceability matrix table: FR × TR × TEST × statusall - complete export package
type: result
payload:
requestId: req-20260409T120014Z-gendoc-001
result:
content: |
# Requirement Traceability Matrix
| FR ID | TR ID | TEST ID | Status |
|------------|-----------------|--------------|--------|
| FR-MCP-001 | TR-MCP-ARCH-001 | TEST-MCP-001 | done |
| FR-MCP-002 | TR-MCP-ARCH-002 | TEST-MCP-003 | open |
format: markdown
docType: matrix
generatedAt: 2026-04-09T12:00:14Z
Wiki Export
Use format: wiki with docType: all to export wiki files directly into the workspace. The normal result returns metadata, not archive bytes. Files are written under docs/Project/wiki/azure and docs/Project/wiki/github. Each folder includes .mcp-requirements-manifest.json; Azure also includes .order; GitHub also includes _Sidebar.md and _Footer.md. When an older REPL cannot serialize the metadata result, the wrapper may return contentBase64 with contentType: application/json; decode it to read the same export metadata.
type: request
payload:
requestId: req-20260409T120014Z-gendoc-wiki-001
method: workflow.requirements.generateDocument
params:
format: wiki
docType: all
type: result
payload:
requestId: req-20260409T120014Z-gendoc-wiki-001
result:
format: wiki
docType: all
generatedAtUtc: 2026-04-09T12:00:14Z
outputRoot: F:\GitHub\McpServer\docs\Project\wiki
files:
- relativePath: azure/Home.md
fullPath: F:\GitHub\McpServer\docs\Project\wiki\azure\Home.md
contentType: text/markdown
lastModifiedUtc: 2026-04-09T12:00:14Z
Bulk Ingestion
To import requirements from an existing Markdown document:
type: request
payload:
requestId: req-20260409T120015Z-ingest-001
method: workflow.requirements.ingestDocument
params:
content: |
## FR-MCP-010: GraphRAG ingestion
The system must support ingestion of raw text into the GraphRAG corpus.
Priority: high | Area: MCP | Status: pending
Ingested text must be split into chunks and embedded using all-MiniLM-L6-v2.
Priority: high | Area: MCP | Subarea: GRAPH | Status: pending
format: markdown
To import wiki documents, pass a path-keyed documents map and include lastModifiedUtc per entry when available. Use sourceFormat: auto or wiki; set preferredWikiFormat: azure|github only when the Azure and GitHub timestamp checks disagree. The server compares both .mcp-requirements-manifest.json generatedAtUtc values and the latest lastModifiedUtc per platform. If both checks agree, the newer platform is selected. If they disagree and no preference is supplied, import fails. The selected platform folder is authoritative: missing records are deleted, changed records are updated, new records are created, and identical records are ignored.
type: request
payload:
requestId: req-20260409T120015Z-ingest-wiki-001
method: workflow.requirements.ingestDocument
params:
format: wiki
sourceFormat: wiki
preferredWikiFormat: github
documents:
github/.mcp-requirements-manifest.json:
content: '{"generatedAtUtc":"2026-04-09T12:00:14Z"}'
lastModifiedUtc: 2026-04-09T12:00:14Z
github/Functional-Requirements.md:
content: |
# Functional Requirements (MCP Server)
lastModifiedUtc: 2026-04-09T12:00:15Z
The server parses the document, creates, updates, deletes, or ignores matching FR/TR/TEST/mapping records, and returns a summary:
type: result
payload:
requestId: req-20260409T120015Z-ingest-001
result:
created: 2
updated: 0
skipped: 0
errors: []
Error Handling
Common error codes:
requirement_not_found - no requirement with the given IDrequirement_already_exists - ID already in use; update instead of createinvalid_requirement_id - ID does not match the expected regex for its typemapping_not_found - mapping between the specified FR and TR does not existinvalid_mapping - mapping references a non-existent FR, TR, or TEST IDdocument_generation_error - failed to render the requested document formatdocument_ingestion_error - could not parse or persist the ingested document
Workflow Recommendations
When discovering or agreeing on new requirements during a session:
- Create the FR record immediately using
workflow.requirements.createFr
- Create the corresponding TR records using
workflow.requirements.createTr
- Create the TEST record using
workflow.requirements.createTest
- Link them with
workflow.requirements.createMapping
- Include the new IDs in the session log turn tags via
workflow.sessionlog.updateTurn
Capture requirements as they emerge; do not defer to end of session. Requirements traceability is validated in CI and build failures result from missing mappings.
