Create a review-ready software requirements specification from Markdown

Using only the source material and requirements I provide, create the complete document as raw GitHub-Flavored Markdown (.md). Do not generate, attach, or encode a DOCX/PDF; use the response budget for accurate, useful content.

OUTPUT CONTRACT
- Return only the finished Markdown document: no preamble, commentary, or code fence around the whole response.
- Use exactly one `#` H1 for the document title, then sequential `##` and `###` headings without skipping levels.
- Keep paragraphs concise, sections complete, terminology consistent, and the hierarchy easy to scan.
- Never invent facts, metrics, quotations, requirements, URLs, or citations. Mark missing inputs as `[TBD: specific information needed]`.
- Do not add HTML, manual page numbers, a manually typed table of contents, base64 data, or decorative filler. Unmarkdown generates pagination and the table of contents from the heading structure.

MARKDOWN TOOLKIT — use each feature only when it improves the document
- `**bold**` for labels or key terms, `_italic_` for light emphasis, and `~~strikethrough~~` only for explicit revisions.
- Unordered `-` lists, ordered `1.` steps, and `- [ ]` task lists for actions or review checklists.
- `> blockquotes` for warnings, decisions, constraints, or important callouts.
- GFM tables with a header and separator row; keep every row the same width and keep cells concise.
- Fenced code blocks with a language tag such as `json`, `yaml`, `bash`, `typescript`, or `sql`; never use a fence around the whole document.
- Mermaid diagrams in a fenced `mermaid` block when a flow, sequence, architecture, state, or dependency diagram adds real value.
- Descriptive links as `[label](https://example.com)` and `---` rules only between major document parts.
- Prepare a separate alphabetical Index page by marking important terms at their first relevant mention with `[[index: Term]]`. Use `[[index: Primary term: Subentry]]` for a nested entry. Do not type an Index heading, page numbers, or the index list yourself; Unmarkdown generates the final Index page and page references during Word export.
- Escape Markdown control characters when they are meant to appear literally.

DOCUMENT STANDARD
Build a review-ready Software Requirements Specification with traceable, testable requirements.
- Include metadata, purpose, scope, stakeholders, system overview, assumptions, constraints, actors, interfaces, data, functional requirements, non-functional requirements, security, and acceptance criteria.
- Use tables for requirements: `ID | Requirement | Rationale | Priority | Verification`, with unique `FR-001` and `NFR-001` identifiers and unambiguous 'shall' statements.
- Add a Mermaid context or workflow diagram when useful, plus a traceability table linking requirements to acceptance tests.
- Flag unresolved requirements as `[TBD: decision/input]`; do not fabricate performance targets.

FINAL QUALITY CHECK
- Verify heading order, table column counts, list indentation, code-fence pairing, requirement/decision IDs, and internal consistency.
- Remove empty sections and generic filler. Preserve `[TBD: ...]` markers instead of guessing.
- End with the final document content, ready to save directly as a `.md` file and convert in unmarkdown.in.