ma-agents 3.5.0 → 3.5.2

package/_bmad-output/planning-artifacts/prd.md

@@ -1,9 +1,13 @@
 ---
-stepsCompleted: ['step-01-init', 'step-02-discovery', 'step-02b-vision', 'step-02c-executive-summary', 'step-03-success', 'step-04-journeys', 'step-05-domain', 'step-06-innovation', 'step-07-project-type', 'step-08-scoping', 'step-09-functional', 'step-10-nonfunctional', 'step-11-polish', 'step-12-complete', 'step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit', 'step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit-2026-03-24', 'step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit-2026-03-25']
+stepsCompleted: ['step-01-init', 'step-02-discovery', 'step-02b-vision', 'step-02c-executive-summary', 'step-03-success', 'step-04-journeys', 'step-05-domain', 'step-06-innovation', 'step-07-project-type', 'step-08-scoping', 'step-09-functional', 'step-10-nonfunctional', 'step-11-polish', 'step-12-complete', 'step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit', 'step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit-2026-03-24', 'step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit-2026-03-25', 'step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit-2026-04-07', 'step-e-01-discovery', 'step-e-02-review', 'step-e-03-edit-2026-04-08']
 workflowStatus: 'complete'
 completedDate: '2026-03-05'
-lastEdited: '2026-04-03'
+lastEdited: '2026-04-08'
 editHistory:
+  - date: '2026-04-08'
+    changes: 'Added F18: Software Quality Assurance (SQA) capability area (Planned). Added SQA agent (Gad) to Executive Summary specialized agents bullet. Added Test Engineer (Oren) journey reference to SQA workflows. Extended Specialized Agent Personas FR35 to include SQA. Added FR158–FR171: SQA agent persona and menu, Project Audit workflow (full/partial scope selection, 5 audit dimensions: code-to-story traceability, stories-to-architecture/PRD alignment, process compliance, sprint health, release state, written report output), IEEE/ISO/IEC 12207 compliance workflow (full/partial scope selection, 23 process areas across 4 groups, COMPLIANT/PARTIAL/NON-COMPLIANT/NOT-APPLICABLE/ORGANIZATION-SCOPE ratings, compliance matrix report, gap-driven backlog story creation). Added NFR42–NFR43: audit report reproducibility, air-gapped IEEE 12207 workflow.'
+  - date: '2026-04-07'
+    changes: 'Added F17: BMAD Knowledge Graph capability area (Planned). Added non-hierarchical knowledge graph innovation pattern. Extended Executive Summary with knowledge graph bullet. Added 3 measurable outcomes to Success Criteria. Extended Yael, Noam, and Alon journeys with graph navigation use cases. Added knowledge graph row to Journey Requirements Summary. Added FR141–FR157: graph data model (nodes as file-id#anchor, typed any-to-any directed edges with provenance including AI agent identity), files table for file-pointer-agnostic document registration (relative path/absolute path/URL), LLM-optimized JSON format with meta/files/nodes/edges structure, automatic skill emission with non-hierarchical multi-source edge support, VSCode-native navigation with browser fallback, interactive visualization with filtering and full provenance tooltips, air-gapped self-contained renderer. Added NFR38–NFR41: render performance, LLM-parseable format contract, additive-only emission, air-gapped renderer. Fixed 5 implementation leakage items from validation: removed force-directed algorithm specifics, checkbox UI specifics, internal write mechanism, VSCode URI scheme, and CSS/JS inlining mechanism.'
   - date: '2026-04-03'
     changes: 'Restructured PRD to remove phase-based organization. Replaced phased scoping with System Overview (Current Baseline, Capability Areas with status indicators, Future Directions). Regrouped Functional Requirements and Non-Functional Requirements by capability area instead of phase. Removed all Phase 1/2/3/4 labels, MVP Strategy & Philosophy, MVP Feature Set, Risk Mitigation Strategy subsection. Content preserved and redistributed into capability-based structure.'
   - date: '2026-04-03'
@@ -57,13 +61,14 @@ The core insight is convergence: AI agents need governance, and engineering meth
 
 - **Install AND enforce** — 28+ codified engineering skills install identically across 12 target agents with automatic translation to each agent's native format. Skills are not merely available — they are enforced via BMAD `critical_actions`, top-priority instruction injection, and per-agent enforcement hooks
 - **Full SDLC coverage via BMAD-METHOD** — integrated workflows spanning product discovery, requirements, architecture, sprint planning, implementation, QA, and retrospectives, orchestrated by specialized AI personas (PM, Architect, Developer, QA, Scrum Master, Tech Writer)
-- **Enterprise-grade specialized agents** — purpose-built personas for defense/enterprise needs: SRE (Alex), DevOps (Amit), Cyber Analyst (Yael), and MIL-STD-498 Expert (Joseph) with operational playbooks. Migrated to native BMAD 6.2.0 skill-based architecture: each agent is a full skill folder (`SKILL.md`, `prompts/`, `resources/`, `scripts/`) with internal commands replacing legacy `.customize.yaml` injection, and all 34 operational workflows (11 MIL-498 DIDs + 9 SRE + 6 DevOps + 8 Cyber) packaged as proper BMAD skill packages
+- **Enterprise-grade specialized agents** — purpose-built personas for defense/enterprise needs: SRE (Alex), DevOps (Amit), Cyber Analyst (Yael), MIL-STD-498 Expert (Joseph), and SQA Engineer (Gad) with operational playbooks and compliance workflows. Migrated to native BMAD 6.2.0 skill-based architecture: each agent is a full skill folder (`SKILL.md`, `prompts/`, `resources/`, `scripts/`) with internal commands replacing legacy `.customize.yaml` injection, and all 34 operational workflows (11 MIL-498 DIDs + 9 SRE + 6 DevOps + 8 Cyber) packaged as proper BMAD skill packages
 - **Bug management** — Agents autonomously detect problems in delivered code and propose bug issues. BMAD extension workflows generate structured bug stories. Bugs live in the backlog section of `sprint-status.yaml` alongside stories for unified sprint planning
 - **Unified sprint-status management** — All sprint, backlog, and epic data consolidated into a single `sprint-status.yaml` file with movement semantics (items move between backlog and sprints, never duplicated), done archival (completed items removed and archived), sprint close lifecycle, and Jira adapter readiness. Sprints defined by capacity, flat backlogs containing both stories and bugs, multi-criteria prioritization, and workflows to add/modify/close/remove-from sprints
 - **Agent activity visibility** — Real-time dashboard showing all active AI agents: type, assigned story, worktree, branch, and status, auto-refreshing every 30 seconds from existing project file structures
 - **BMAD-native extension architecture** — All BMAD-facing enhancements use official BMAD Builder extension points. With 6.2.0 migration, the extension module adopts the native `module.yaml` identity pattern (`code`, `description`, `module_version`) with setup skill and `module-help.csv` capability registration. Zero bmad-method core modifications. Extensions survive BMAD updates via the anti-zombie config pattern
 - **Environment agnostic** — supports on-prem, public cloud, and air-gapped deployments through universal skill format and multi-agent targeting
 - **Multi-repository project layout** — Supports enterprise project structures where planning knowledge, sprint management, and code live in separate repositories. The installer discovers repository locations (local or remote), clones as needed, and stamps paths into project-context.md so agents resolve artifact reads/writes to the correct repository without manual path management
+- **Non-hierarchical knowledge graph** — All BMAD-generated artifacts form a living any-to-any knowledge graph. An acceptance criterion in a story may reference the epic that scoped it, the architecture decision that constrained it, and the UX design that shaped it — simultaneously, with no assumption of hierarchy. A central files table maps short file IDs to arbitrary file pointers (relative paths, absolute paths, Confluence URLs, any document reference), so nodes can address any artifact regardless of where it lives. Maintained automatically by skills, stored as LLM-friendly JSON, and visualized as an interactive graph in VSCode. Every edge carries full provenance: creator name, AI agent identifier, and date
 - **Project knowledge preservation** — `_bmad-output` is version-controlled project knowledge (planning artifacts, implementation artifacts), never gitignored
 
 **Classification:** Developer Tool / Methodology Platform | Software Engineering domain | Medium-High complexity | Brownfield (v2.19.2), documented as greenfield PRD
@@ -112,6 +117,10 @@ Each capability area represents a permanent part of the product that is enhanced
 
 16. **Methodology Onboarding** — Methodology presentation bundled with BMAD installation, deployed to `_bmad-output/methodology/` for team onboarding. — **In Development**
 
+17. **BMAD Knowledge Graph** — Dynamic any-to-any knowledge graph built automatically from BMAD-generated artifacts.
+
+18. **Software Quality Assurance (SQA)** — Dedicated SQA agent (Gad) providing structured quality workflows for software projects: a multi-dimensional Project Audit (code-to-story traceability, stories-to-architecture/PRD alignment, process compliance, sprint health, release state) and an IEEE/ISO/IEC 12207 lifecycle process compliance assessment with compliance matrix, gap analysis, and backlog story generation for identified gaps. — **Planned** Any artifact can reference any other regardless of hierarchy — a story's AC may derive from the epic, an architecture decision, and a UX design simultaneously. A central `files` table maps short file IDs to arbitrary file pointers (relative paths, absolute paths, Confluence URLs, or any document reference). Nodes are addressable anchors within registered files (`file-id#heading`), edges are directional typed relationships with full provenance (creator name, AI agent identifier, date, label). Stored as LLM-friendly JSON at `_bmad-output/knowledge-graph.json`. Rendered as an interactive graph in VSCode webview (browser fallback) via `_bmad-output/knowledge-graph.html`. `open-graph` skill surfaces the visualization from any BMAD session. — **Planned**
+
 ### Future Directions
 
 The following capabilities extend the existing architecture. They are aspirational enhancements with no delivery dates or commitments.
@@ -138,6 +147,7 @@ The following capabilities extend the existing architecture. They are aspiration
 - Agents autonomously propose bug issues when they detect problems in already-delivered code
 - Sprint workflows use a single `sprint-status.yaml` as the source of truth — flat backlogs, capacity-based sprints, multi-criteria prioritization, movement semantics, done archival, and sprint close lifecycle
 - Projects that separate planning knowledge, sprint management, and code across repositories are fully supported — agents automatically resolve artifact paths to the correct repository
+- Engineers can open the BMAD knowledge graph from any BMAD session and navigate from any artifact node directly to the source document location — zero manual cross-reference maintenance required
 
 ### Technical Success
 
@@ -152,6 +162,7 @@ The following capabilities extend the existing architecture. They are aspiration
 - All 34 operational workflows (11 MIL-498 DIDs + 9 SRE + 6 DevOps + 8 Cyber) are proper BMAD 6.2.0 skill packages — no legacy YAML/XML workflow dependencies
 - Installer performs seamless in-place migration from 6.0.4 to 6.2.0 patterns during normal installation without user intervention
 - Agent activity dashboard reflects current agent state within 60 seconds of last file system change
+- Knowledge graph accurately reflects all traceability relationships emitted during the project lifecycle — no manual graph maintenance required, verified by confirming edge count matches artifact generation events
 
 ### Measurable Outcomes
 
@@ -160,6 +171,7 @@ The following capabilities extend the existing architecture. They are aspiration
 - Full SDLC coverage: systems engineering → requirements → architecture → implementation → QA → production
 - Zero manual steps required for skill format adaptation per agent
 - Bug and sprint workflows function as BMAD extensions without requiring bmad-method updates — unified `sprint-status.yaml` replaces fragmented multi-file sprint tracking
+- End-to-end traceability chain from PRD requirement to implementation story is navigable in the knowledge graph for every shipped feature — verifiable by traversing the graph from any story node to its originating PRD requirement
 
 ## User Journeys
 
@@ -177,15 +189,15 @@ Dana manages project phases, timelines, and deliverables. She uses BMAD's PM per
 
 ### 3. Product Manager — Noam
 
-Noam translates system requirements into development work. He uses BMAD's PM persona to create the PRD, break it into epics and stories with `/bmad-bmm-create-epics-and-stories`, and run sprint planning with `/bmad-bmm-sprint-planning`. During sprint planning, the Scrum Master asks Noam to define sprint capacity (number of items), and stories are moved from the backlog section of `sprint-status.yaml` into the sprint using multi-criteria prioritization — not just epic precedence. Bugs reported by developers are added to the backlog section alongside stories and prioritized into sprints. The single `sprint-status.yaml` file is the source of truth for all sprint and backlog state. He generates the SRS (Software Requirements Specification) and SDD (Software Design Description) from project artifacts using the MIL-STD-498 workflows. His stories are implementation-ready, containing acceptance criteria, technical context, and test expectations. He validates PRDs and checks implementation readiness before handoff to development.
+Noam translates system requirements into development work. He uses BMAD's PM persona to create the PRD, break it into epics and stories with `/bmad-bmm-create-epics-and-stories`, and run sprint planning with `/bmad-bmm-sprint-planning`. During sprint planning, the Scrum Master asks Noam to define sprint capacity (number of items), and stories are moved from the backlog section of `sprint-status.yaml` into the sprint using multi-criteria prioritization — not just epic precedence. Bugs reported by developers are added to the backlog section alongside stories and prioritized into sprints. The single `sprint-status.yaml` file is the source of truth for all sprint and backlog state. He generates the SRS (Software Requirements Specification) and SDD (Software Design Description) from project artifacts using the MIL-STD-498 workflows. His stories are implementation-ready, containing acceptance criteria, technical context, and test expectations. He validates PRDs and checks implementation readiness before handoff to development. He uses `/open-graph` to see which PRD requirements already have outbound edges to architecture decisions and epics — requirements with no outbound edges are highlighted as coverage gaps before sprint planning begins.
 
-**Capabilities revealed:** PRD creation/validation, epics & stories, unified sprint planning with single `sprint-status.yaml`, capacity-based sprints, movement semantics, bug prioritization, SRS/SDD generation, implementation readiness checks, story lifecycle management
+**Capabilities revealed:** PRD creation/validation, epics & stories, unified sprint planning with single `sprint-status.yaml`, capacity-based sprints, movement semantics, bug prioritization, SRS/SDD generation, implementation readiness checks, story lifecycle management, knowledge graph PRD coverage analysis
 
 ### 4. Architect — Yael
 
-Yael defines the technical architecture, UX design, technology stack, and integration points. She uses `/bmad-bmm-create-architecture` to document decisions and `/bmad-bmm-create-ux-design` for UX specifications. She generates IDD (Interface Design Description), IRS (Interface Requirements Specification), HRS (Hardware Requirements Specification), and architecture documents, as well as SRS for the technical requirements. She validates that architecture aligns with the PRD and epics using `/bmad-bmm-check-implementation-readiness`. She installs architecture-specific skills (logging, OpenTelemetry, Vercel/React best practices) to ensure the development team follows her architectural decisions through their AI agents.
+Yael defines the technical architecture, UX design, technology stack, and integration points. She uses `/bmad-bmm-create-architecture` to document decisions and `/bmad-bmm-create-ux-design` for UX specifications. She generates IDD (Interface Design Description), IRS (Interface Requirements Specification), HRS (Hardware Requirements Specification), and architecture documents, as well as SRS for the technical requirements. She validates that architecture aligns with the PRD and epics using `/bmad-bmm-check-implementation-readiness`. She installs architecture-specific skills (logging, OpenTelemetry, Vercel/React best practices) to ensure the development team follows her architectural decisions through their AI agents. She uses `/open-graph` to visualize the knowledge graph and verify that every architecture decision node links back to a PRD requirement — orphaned architecture nodes with no inbound edges from the PRD surface traceability gaps before epics are written.
 
-**Capabilities revealed:** Architecture creation/validation, UX design, IDD/IRS/HRS generation, implementation readiness, architecture skill enforcement, technology stack documentation
+**Capabilities revealed:** Architecture creation/validation, UX design, IDD/IRS/HRS generation, implementation readiness, architecture skill enforcement, technology stack documentation, knowledge graph traceability verification
 
 ### 5. Test Engineer — Oren
 
@@ -201,9 +213,9 @@ Amit manages CI/CD pipelines, repository structure, and deployment configuration
 
 ### 7. Chief Architect — Alon (Methodology Owner)
 
-Alon defines the enterprise development methodology and builds the tooling to enforce it. He uses ma-agents to package organizational engineering standards as portable skills, customizes BMAD agent personas to fit the organization's processes, and develops new specialized agents (SRE, Cyber, MIL-STD-498) for roles specific to defense. He selects which skills are mandatory (`always_load: true`), authors custom skills using the skill-creator, and runs `npx ma-agents` across projects to ensure uniform methodology adoption. He architects the BMAD extension module using BMAD 6.2.0's native `module.yaml` identity pattern with setup skill, designs bug management and sprint workflows, and ensures all extensions survive BMAD updates via the anti-zombie config pattern. When upgrading from earlier ma-agents versions (bundling bmad-method 6.0.4), Alon relies on the installer to perform in-place migration — rebuilding the 4 custom agents from `.customize.yaml` + XML definitions to native 6.2.0 skill-based agent folders (`SKILL.md`, `prompts/`, `resources/`, `scripts/`), converting all 34 operational workflows from legacy formats to proper SKILL.md packages, and cleaning up legacy artifacts automatically. He uses BMAD Builder's Agent Builder to create and maintain the 4 custom agents and Workflow Builder to create and maintain the 34 operational workflows — both tools produce standard skill folder output with lint gate validation. He uses the full BMAD workflow — from brainstorming through architecture to implementation — to develop ma-agents itself. He monitors the agent activity dashboard to maintain governance visibility across all active agents — verifying that agents are operating on the correct stories, branches, and worktrees in accordance with the git-workflow-skill. He configures multi-repository project layouts during installation — separating the knowledgebase (planning artifacts) and sprint management (stories, sprints, backlog) into dedicated repositories while keeping implementation code in the main repo. All BMAD workflows automatically resolve to the correct repository paths, and agents operating in the code repo discover planning context and story specs via the cross-reference file. He ensures `_bmad-output` is committed to version control as project knowledge.
+Alon defines the enterprise development methodology and builds the tooling to enforce it. He uses ma-agents to package organizational engineering standards as portable skills, customizes BMAD agent personas to fit the organization's processes, and develops new specialized agents (SRE, Cyber, MIL-STD-498) for roles specific to defense. He selects which skills are mandatory (`always_load: true`), authors custom skills using the skill-creator, and runs `npx ma-agents` across projects to ensure uniform methodology adoption. He architects the BMAD extension module using BMAD 6.2.0's native `module.yaml` identity pattern with setup skill, designs bug management and sprint workflows, and ensures all extensions survive BMAD updates via the anti-zombie config pattern. When upgrading from earlier ma-agents versions (bundling bmad-method 6.0.4), Alon relies on the installer to perform in-place migration — rebuilding the 4 custom agents from `.customize.yaml` + XML definitions to native 6.2.0 skill-based agent folders (`SKILL.md`, `prompts/`, `resources/`, `scripts/`), converting all 34 operational workflows from legacy formats to proper SKILL.md packages, and cleaning up legacy artifacts automatically. He uses BMAD Builder's Agent Builder to create and maintain the 4 custom agents and Workflow Builder to create and maintain the 34 operational workflows — both tools produce standard skill folder output with lint gate validation. He uses the full BMAD workflow — from brainstorming through architecture to implementation — to develop ma-agents itself. He monitors the agent activity dashboard to maintain governance visibility across all active agents — verifying that agents are operating on the correct stories, branches, and worktrees in accordance with the git-workflow-skill. He configures multi-repository project layouts during installation — separating the knowledgebase (planning artifacts) and sprint management (stories, sprints, backlog) into dedicated repositories while keeping implementation code in the main repo. All BMAD workflows automatically resolve to the correct repository paths, and agents operating in the code repo discover planning context and story specs via the cross-reference file. He ensures `_bmad-output` is committed to version control as project knowledge. He monitors the knowledge graph via `/open-graph` to maintain governance visibility across artifact traceability — confirming that all architecture decisions have inbound edges from documented PRD requirements and all epics trace to architecture nodes. Orphaned nodes surface planning gaps before implementation begins. He verifies that the graph's provenance metadata (creator, agent, date) accurately reflects which agents performed which design decisions.
 
-**Capabilities revealed:** Skill authoring and governance, BMAD 6.2.0 module architecture with `module.yaml` and setup skill, agent building via BMAD Builder (skill folder output), workflow building via Workflow Builder, 6.0.4→6.2.0 migration via installer, multi-repository project layout configuration, methodology definition, enterprise-wide deployment, custom agent development, bug/sprint workflow design, agent activity dashboard governance, BMAD self-application
+**Capabilities revealed:** Skill authoring and governance, BMAD 6.2.0 module architecture with `module.yaml` and setup skill, agent building via BMAD Builder (skill folder output), workflow building via Workflow Builder, 6.0.4→6.2.0 migration via installer, multi-repository project layout configuration, methodology definition, enterprise-wide deployment, custom agent development, bug/sprint workflow design, agent activity dashboard governance, knowledge graph traceability governance, BMAD self-application
 
 ### Journey Requirements Summary
 
@@ -229,6 +241,7 @@ Alon defines the enterprise development methodology and builds the tooling to en
 | BMAD 6.2.0 migration (agent rebuild, workflow conversion, module update, legacy cleanup) | Alon |
 | BMAD Builder agent/workflow creation and maintenance | Alon |
 | Multi-repository project layout (knowledgebase, sprint mgmt, code separation) | Alon, Dana, Noam |
+| Knowledge graph — automatic traceability, graph visualization, document navigation | Noam, Yael, Alon |
 
 ## Domain-Specific Requirements
 
@@ -271,6 +284,7 @@ Alon defines the enterprise development methodology and builds the tooling to en
 - **BMAD-native extension architecture** — Uses official BMAD Builder extension points to inject enforcement, workflows, and agent behaviors without modifying the BMAD core. With 6.2.0, the extension module adopts native module identity (`module.yaml` with `code` field), setup skill for config management, and agents/workflows as standard skill folders. Demonstrates that complex cross-cutting concerns (skill enforcement, bug management, sprint workflows, specialized agents) can be delivered as extension modules that survive upstream updates via the anti-zombie config pattern
 - **Bug-as-first-class-entity in AI development** — Agents autonomously detect defects in delivered code and propose structured bug reports to users. This closes the loop between code review and issue tracking within the AI agent workflow
 - **Structured skill format as implicit DSL** — The skill.json + SKILL.md + agent template system with frontmatter injection and resource mapping constitutes a domain-specific authoring format for packaging engineering practices into agent-consumable instructions
+- **Non-hierarchical SDLC knowledge graph** — Unlike traceability matrices that assume a strict parent-child hierarchy, this graph supports any-to-any relationships. A story's acceptance criterion can simultaneously reference the epic that scoped it, the architecture decision that constrained it, and the UX design that specified it — without any of these being "the" canonical source. A central files table maps short file IDs to arbitrary file pointers (relative paths, absolute paths, Confluence URLs, any document reference), so the graph is not bound to files in the repository. Relationships are first-class typed directed edges with full provenance (creator, AI agent, date). Built automatically by skills as they generate artifacts — no human cross-referencing required. The result is a living, queryable, visual map where influence flows in any direction: jumping from a node in the graph to the exact heading in any referenced document
 
 ### Validation Approach
 
@@ -425,7 +439,7 @@ ma-agents does not integrate as an IDE extension. Instead, it injects skill cont
 
 ### Specialized Agent Personas (MIL-STD-498 / SRE / DevOps / Cyber)
 
-- FR35: Engineers can target BMAD specialized agents (SRE, DevOps, Cyber, MIL-STD-498) for persona installation
+- FR35: Engineers can target BMAD specialized agents (SRE, DevOps, Cyber, MIL-STD-498, SQA) for persona installation
 - FR42: The Chief Architect can develop new specialized agent personas for enterprise-specific roles
 
 ### MIL-STD-498 Document Generation
@@ -610,6 +624,62 @@ sprints:
 - FR49: Document generation workflows maintain traceability across inter-role handoffs (SSS → SRS → SDD → STD)
 - FR50: Engineers can validate PRDs and other documents against established standards
 
+### BMAD Knowledge Graph
+
+#### Graph Data Model
+
+- FR141: Every addressable heading anchor in any registered document is a graph node. Node identity uses `file-id#heading-anchor` syntax, where `file-id` is a short identifier defined in the graph's `files` table (e.g., `prd#fr24`). The `files` table maps each `file-id` to a file pointer — which may be a relative path, absolute path, URL (e.g., Confluence page), or any other document reference. Nodes require no manual creation — they are derived from document structure at emit time and registered against the files table
+- FR142: Each graph edge is a directed typed relationship from a source node to a target node. Edges are not constrained to hierarchical parent-child relationships — any node may reference any other node regardless of document type or position in the artifact chain. Edge fields: `from` (source node id), `to` (target node id), `type` (one of: `implements`, `derives-from`, `validates`, `traces-to`, `refines`, `informed-by`), `label` (optional human-readable description), `created_by` (user name from BMAD config), `agent` (AI agent identifier — e.g., `claude-code`, `cursor`, `copilot`), `created_at` (ISO 8601 timestamp). No edge field may be null except `label`
+- FR143: The graph maintains a bidirectional index: for every node, both its outbound edges (what it references) and inbound backlinks (what references it) are queryable — enabling "what influenced this AC?" and "what was derived from this architecture decision?" without scanning all edges. A single node may have inbound edges from multiple unrelated documents simultaneously
+
+#### JSON Format
+
+- FR144: The knowledge graph is stored as a single JSON file at `_bmad-output/knowledge-graph.json`. The top-level structure is `{ "meta": {...}, "files": {...}, "nodes": [...], "edges": [...] }` — flat, no nesting beyond two levels, using string keys throughout. This structure is optimized for LLM read/write: any model can register a file, add a node, or add an edge by appending to the appropriate section without parsing complex schemas
+- FR145: The `files` table is a JSON object mapping short file IDs to file pointer objects: `{ "prd": { "pointer": "_bmad-output/planning-artifacts/prd.md", "title": "PRD", "pointer_type": "relative_path" }, "arch": { "pointer": "_bmad-output/planning-artifacts/architecture.md", "title": "Architecture", "pointer_type": "relative_path" }, "ux-conf": { "pointer": "https://confluence.example.com/page/456", "title": "UX Design", "pointer_type": "url" } }`. `pointer_type` is one of: `relative_path`, `absolute_path`, `url`. This decouples node identity from file location — files can live anywhere
+- FR146: Each node object: `{ "id": "file-id#anchor", "file": "file-id", "anchor": "anchor", "title": "Human readable heading text", "type": "requirement|architecture|epic|story|design|test" }`
+- FR147: Each edge object: `{ "id": "unique-edge-id", "from": "file-id#anchor", "to": "file-id#anchor", "type": "implements|derives-from|validates|traces-to|refines|informed-by", "label": "optional", "created_by": "name", "agent": "agent-id", "created_at": "ISO8601" }`
+- FR148: The `meta` object carries: `{ "schema_version": "1.0", "project": "project-name", "generated": "ISO8601", "last_updated": "ISO8601", "node_count": N, "edge_count": N, "file_count": N }`. All counts are updated on every write — enabling quick integrity checks without parsing the full arrays
+
+#### Automatic Skill Emission
+
+- FR149: BMAD skills that generate or update planning artifacts (create-prd, create-architecture, create-epics-and-stories, create-story, dev-story, bmad-create-ux-design) automatically append nodes and edges to `knowledge-graph.json` upon artifact completion — no user prompt required. If the file does not exist, the skill creates it with the correct schema
+- FR150: Before emitting nodes, the skill registers the source document in the `files` table if not already present — assigning a short file ID and recording the pointer and pointer type. Skills may emit edges referencing any previously registered file, not only files in the project repository. This allows a story skill to reference a Confluence UX spec or an external architecture document as an edge target, as long as that file has been registered in the `files` table
+- FR151: When a skill emits edges, it resolves source and target nodes from all artifacts that influenced the output — not only the direct parent in the artifact hierarchy. A story skill may emit `derives-from` edges to the epic, `informed-by` edges to architecture sections, and `informed-by` edges to UX design nodes simultaneously. Edge types are determined by the nature of the influence: architecture sections addressing PRD requirements emit `implements`; epics breaking down PRD features emit `derives-from`; stories implementing epics emit `traces-to`; external documents that shaped a decision emit `informed-by`; validation workflows emit `validates`
+- FR152: Skills never create duplicate nodes or files entries. Before appending, the skill checks if a node with the same `id` already exists — if so, updates `title` only and skips insertion. Before appending an edge, the skill checks for an existing edge with matching `from`, `to`, and `type` — if found, updates `created_at` and `agent` only. Before adding a file, the skill checks if a file-id already exists — if so, updates `pointer` and `title` only
+
+#### Visualization & Navigation
+
+- FR153: The `open-graph` skill generates or refreshes `_bmad-output/knowledge-graph.html` from `knowledge-graph.json` and opens it. When a VSCode environment is detected, the skill opens the file inside the editor. In non-VSCode environments, the skill opens the file in the system default browser
+- FR154: The rendered graph is an interactive visualization. Nodes are labeled with their `title`. Edge direction is shown with arrowheads. Node color encodes `type` (requirement, architecture, epic, story, design, test — 6 distinct colors with a legend). Clicking a node navigates to the source document at the exact heading anchor — using VSCode's native document navigation when available, or displaying a copyable document link otherwise. For nodes whose `files` entry has `pointer_type: url`, clicking opens the URL in the browser
+- FR155: Hovering over an edge displays a tooltip showing: edge `type`, `label` (if set), `created_by`, `agent`, and `created_at` — full provenance visible without leaving the graph
+- FR156: The graph supports filtering by node type and edge type via interactive controls in the visualization panel. Selecting a node highlights all its direct neighbors and their connecting edges, dimming everything else — isolating all influences on any artifact regardless of which documents they come from
+- FR157: The `knowledge-graph.html` renderer functions without network access and without a local server — no external CDN, font, or script dependencies
+
+### Software Quality Assurance (SQA)
+
+#### SQA Agent Persona
+
+- FR158: Quality engineers can activate the SQA Agent (Gad) — a purpose-built persona specializing in structured quality assurance workflows: project auditing, process compliance verification, and standards conformance assessment
+- FR159: On activation, Gad presents a numbered menu of available quality workflows with keyboard shortcuts and trigger phrases. Menu items include: Project Audit, IEEE/ISO/IEC 12207 Compliance, and Dismiss Agent. Chat mode is available for ad-hoc quality questions
+
+#### Project Audit Workflow
+
+- FR160: Gad's Project Audit workflow begins by asking whether to run a full audit (all five dimensions) or a partial audit (user selects which dimensions by number) — execution only begins after the user confirms scope
+- FR161: The Code-to-Stories Traceability dimension reads done and in-progress items from `sprint-status.yaml` and verifies that each story has traceable code evidence; it also surfaces significant code changes with no backing story, flagging each finding with its story ID and traceability status
+- FR162: The Stories-to-Architecture/PRD Alignment dimension maps each epic to its corresponding PRD section, verifies that stories do not introduce architectural decisions contradicting `architecture.md`, and identifies PRD requirements with no corresponding epic or story — producing a PRD coverage table (COVERED / MISSING / PARTIAL) and an architecture compliance issue list
+- FR163: The Process Compliance dimension evaluates development process adherence: commit message format conventions, feature-branch discipline (changes not committed directly to main), test file presence alongside new implementation files, and code review evidence — producing a process checklist with PASS / FAIL / UNKNOWN per item
+- FR164: The Sprint Health dimension reads all sprints from `sprint-status.yaml` and reports: completion percentage per sprint, overdue items, stalled in-progress items, blockers, and backlog grooming health (prioritization, epic linkage, item clarity)
+- FR165: The Release State dimension evaluates release readiness by mapping done stories to declared release scope, identifying blocking items preventing release, and reporting deployment environment status as provided by the user
+- FR166: After all selected dimensions execute, Gad produces a written audit report saved to `{output_folder}/sqa-audit-report-{YYYY-MM-DD}.md`. The report includes an executive summary, per-dimension findings tables with PASS / WARNING / FAIL severity, a prioritized action-item list, and a skipped-dimension list with required artifacts for each skip
+
+#### IEEE/ISO/IEC 12207 Compliance Workflow
+
+- FR167: Gad's IEEE/ISO/IEC 12207 compliance workflow begins by presenting the four process groups and asking whether to evaluate all groups or selected ones — evaluation only begins after the user confirms scope
+- FR168: The workflow evaluates 23 process areas across four IEEE/ISO/IEC 12207:2017 process groups: Technical Processes (11 areas: Business Analysis, Stakeholder Requirements, Software Requirements, Architecture, Design, System Analysis, Implementation, Integration, Verification, Validation, Transition), Technical Management Processes (8 areas: Project Planning, Project Assessment, Decision Management, Risk Management, Configuration Management, Information Management, Measurement, Quality Assurance), Agreement Processes (2 areas: Acquisition, Supply), and Organizational Enabling Processes (2 areas: Life Cycle Model Management, Knowledge Management)
+- FR169: Each evaluated process area receives a compliance rating: COMPLIANT (evidence satisfies process intent), PARTIAL (some evidence, gaps remain), NON-COMPLIANT (no evidence or clear violation), NOT APPLICABLE (process not relevant to this project type), or ORGANIZATION-SCOPE (verifiable only at organizational level, not from project artifacts). Ratings are derived from available project artifacts: `prd.md`, `architecture.md`, `sprint-status.yaml`, test files, git history, and changelog
+- FR170: The workflow produces a compliance matrix report saved to `{output_folder}/sqa-ieee12207-report-{YYYY-MM-DD}.md`. The report includes an executive summary, per-group compliance matrices (clause, process area, compliance rating, key evidence, gaps), a gap analysis separating critical gaps from partial compliance items, a prioritized recommended-action table, and a compliance summary table with counts per group and an overall compliance percentage
+- FR171: After any SQA workflow that identifies gaps, Gad offers to create structured bug or story entries in the project backlog for each P1 (critical) gap — invoking the `create-bug-story` workflow for each accepted item
+
 ## Non-Functional Requirements
 
 ### Security & Data Protection
@@ -676,9 +746,21 @@ sprints:
 - NFR32: All 23 converted workflows (11 MIL-498 + 9 SRE + 6 DevOps + 8 Cyber = 34 total; corrected: 11+9+6+8=34) produce identical output artifacts as their pre-migration equivalents — same document structure, same section headers, same template variables, verified by diff comparison of generated outputs
 - NFR33: The module setup skill's anti-zombie cleanup must be idempotent — running `npx ma-agents` multiple times produces the same `config.yaml`, `config.user.yaml`, and `module-help.csv` state regardless of prior runs
 
+### BMAD Knowledge Graph
+
+- NFR38: The `open-graph` skill shall render a graph of up to 500 nodes and 1000 edges in under 3 seconds from file load to interactive display — measured from skill invocation to first interactive frame in the renderer
+- NFR39: `knowledge-graph.json` must remain parseable and writable by any LLM without schema documentation. Validated by requiring that a model with no prior knowledge of the format can correctly register a file, add a node, and add an edge given only the existing file content as context — no external schema reference required
+- NFR40: Skill emission of files, nodes, and edges must be additive-only — skills never delete or overwrite existing entries, only append or update non-provenance fields. Existing provenance data (creator, agent, date) on an edge is never modified by subsequent runs
+- NFR41: The `knowledge-graph.html` renderer must function in air-gapped environments with no network access and without a local server — verified by loading the file with network access blocked and confirming full interactive functionality
+
 ### Project Context Generation
 
 - NFR22: The project-context *template* (`lib/templates/project-context.template.md`) must contain no hardcoded platform-specific paths or agent directory names — path-specific content is stamped at generation time, not embedded in the template source
 - NFR23: Project-context generation is additive-only — the installer never modifies or deletes an existing `_bmad-output/project-context.md` regardless of its content or age
 - NFR24: The project-context template is maintained as a standalone file (`lib/templates/project-context.template.md`), not as an inline string in installer code — allowing the template to be updated independently of installer logic
 - NFR25: The generated project-context.md includes a machine-readable generator version comment (e.g., `<!-- ma-agents-template-version: 1.0 -->`). When a future ma-agents version detects a lower template version in an existing file, it logs a warning suggesting the user run `/bmad-generate-project-context` to refresh — it never auto-overwrites
+
+### Software Quality Assurance (SQA)
+
+- NFR42: SQA audit findings driven by project artifacts (prd.md, architecture.md, epics.md, sprint-status.yaml) must be deterministic — re-running a workflow on unchanged artifacts must not introduce variance from execution alone. Findings that depend on user-provided inputs (git log output, deployment environment status) may differ across runs only when the user provides different data; this is expected behavior, not a defect.
+- NFR43: The IEEE/ISO/IEC 12207 compliance workflow must not require internet access — all evaluation logic, process area definitions, and rating criteria are embedded in the skill; no external standard document download or network call is made during execution

package/_bmad-output/planning-artifacts/validation-report-prd-2026-04-07.md

@@ -0,0 +1,330 @@
+---
+validationTarget: '_bmad-output/planning-artifacts/prd.md'
+validationDate: '2026-04-07'
+inputDocuments:
+  - _bmad-output/planning-artifacts/prd.md
+  - _bmad-output/planning-artifacts/product-brief-agents-2026-03-08.md
+  - README.md
+  - CONTRIBUTING.md
+  - DEVELOPMENT.md
+  - QUICK_START.md
+  - SKILLS_STRUCTURE.md
+  - docs/index.md
+  - docs/project-overview.md
+  - docs/architecture.md
+  - docs/source-tree-analysis.md
+  - docs/development-guide.md
+validationStepsCompleted: ['step-v-01-discovery', 'step-v-02-format-detection', 'step-v-03-density-validation', 'step-v-04-brief-coverage-validation', 'step-v-05-measurability-validation', 'step-v-06-traceability-validation', 'step-v-07-implementation-leakage-validation', 'step-v-08-domain-compliance-validation', 'step-v-09-project-type-validation', 'step-v-10-smart-validation', 'step-v-11-holistic-quality-validation', 'step-v-12-completeness-validation']
+validationStatus: COMPLETE
+holisticQualityRating: '4/5'
+overallStatus: 'Warning'
+---
+
+# PRD Validation Report
+
+**PRD Being Validated:** `_bmad-output/planning-artifacts/prd.md`
+**Validation Date:** 2026-04-07
+
+## Input Documents
+
+- PRD: `_bmad-output/planning-artifacts/prd.md` ✓
+- Product Brief: `_bmad-output/planning-artifacts/product-brief-agents-2026-03-08.md` ✓
+- README.md ✓
+- CONTRIBUTING.md ✓
+- DEVELOPMENT.md ✓
+- QUICK_START.md ✓
+- SKILLS_STRUCTURE.md ✓
+- docs/index.md ✓
+- docs/project-overview.md ✓
+- docs/architecture.md ✓
+- docs/source-tree-analysis.md ✓
+- docs/development-guide.md ✓
+
+## Format Detection
+
+**PRD Structure (## Level 2 headers):**
+1. Executive Summary
+2. System Overview
+3. Success Criteria
+4. User Journeys
+5. Domain-Specific Requirements
+6. Innovation & Novel Patterns
+7. Developer Tool Specific Requirements
+8. Functional Requirements
+9. Non-Functional Requirements
+
+**BMAD Core Sections Present:**
+- Executive Summary: Present ✓
+- Success Criteria: Present ✓
+- Product Scope: Present (as System Overview) ✓
+- User Journeys: Present ✓
+- Functional Requirements: Present ✓
+- Non-Functional Requirements: Present ✓
+
+**Format Classification:** BMAD Standard
+**Core Sections Present:** 6/6
+
+## Validation Findings
+
+---
+
+## Information Density Validation
+
+**Anti-Pattern Violations:**
+
+**Conversational Filler:** 0 occurrences
+**Wordy Phrases:** 0 occurrences
+**Redundant Phrases:** 0 occurrences
+
+**Total Violations:** 0
+
+**Severity Assessment:** Pass — PRD demonstrates excellent information density throughout.
+
+---
+
+## Product Brief Coverage
+
+**Product Brief:** `product-brief-agents-2026-03-08.md`
+
+### Coverage Map
+
+**Vision Statement ("Install AND Enforce"):** Fully Covered ✓ — Executive Summary, "What Makes This Special" section
+**Problem Statement (skills not enforced, 4 root causes):** Fully Covered ✓ — Executive Summary paragraph 2
+**Target Users (engineers, architects, DevOps, SRE, MIL-498):** Fully Covered ✓ — 7 User Journeys
+**Key Features — Pillar 1 (Skill Enforcement):** Fully Covered ✓ — FR51-FR55, NFR16-17
+**Key Features — Pillar 2 (OpenCode Support):** Fully Covered ✓ — FR56-FR57
+**Key Features — Pillar 3 (`_bmad-output` Policy):** Fully Covered ✓ — FR58-FR59
+**Goals/Success Criteria:** Fully Covered ✓ — Success Criteria section (>90% compliance rate, zero-reminder workflow)
+**Differentiators ("Install AND Enforce", BMAD-native, 12-agent):** Fully Covered ✓ — Innovation section
+
+**Note:** Knowledge Graph capability not in brief (brief predates this feature). Not a gap — expected scope evolution.
+
+### Coverage Summary
+
+**Overall Coverage:** 100% of brief content
+**Critical Gaps:** 0
+**Moderate Gaps:** 0
+**Informational Gaps:** 0
+
+**Recommendation:** PRD provides complete coverage of all Product Brief content with significant expansion.
+
+---
+
+## Measurability Validation
+
+### Functional Requirements
+
+**Total FRs Analyzed:** 155 (focusing on new FR141–FR155)
+
+**Format Violations (new FRs):** 0 — System-behavior format consistent with established PRD style (FR65, FR133, etc.)
+
+**Subjective Adjectives Found:** 0
+
+**Vague Quantifiers Found:** 0
+
+**Implementation Leakage in FRs:** 5 occurrences (see Implementation Leakage section below)
+
+**FR Violations Total:** 5 (all in new FR141–155, all implementation leakage category)
+
+### Non-Functional Requirements
+
+**Total NFRs Analyzed:** 41 (focusing on new NFR38–NFR41)
+
+- **NFR38:** Specific metric (3 seconds), capacity (500 nodes / 1000 edges), measurement method (skill invocation to first interactive frame) — Pass ✓
+- **NFR39:** Measurable via defined test (LLM adds node/edge with no external schema) — Pass ✓
+- **NFR40:** Behavioral constraint, verifiable by checking no deletions occur during emission — Pass ✓
+- **NFR41:** Verifiable by disabling network access — Pass ✓
+
+**Missing Metrics:** 0
+**Incomplete Template:** 0
+**NFR Violations Total:** 0
+
+### Overall Assessment
+
+**Total Requirements:** 155 FRs + 41 NFRs = 196
+**Total Violations:** 5 (all implementation leakage, not measurability failures)
+
+**Severity:** Warning (5 violations in new Knowledge Graph FRs)
+
+---
+
+## Traceability Validation
+
+### Chain Validation
+
+**Executive Summary → Success Criteria:** Intact ✓
+- New "Zettelkasten-inspired knowledge graph" bullet traces to new success criterion "Engineers can open the BMAD knowledge graph..."
+
+**Success Criteria → User Journeys:** Intact ✓
+- "Knowledge graph accurately reflects all traceability relationships" → Yael, Noam, Alon journey extensions
+- "End-to-end traceability chain navigable" → Alon governance journey
+
+**User Journeys → Functional Requirements:** Intact ✓
+- Yael (orphaned nodes, traceability gaps) → FR143 (bidirectional index), FR154 (filtering)
+- Noam (PRD coverage gaps, requirements with no outbound edges) → FR143, FR148, FR154
+- Alon (governance, confirmed inbound edges, provenance) → FR142 (provenance fields), FR143, FR148-150, FR153 (tooltip)
+
+**Scope → FR Alignment:** Intact ✓ — Capability Area #17 maps to FR141–FR155
+
+### Orphan Elements
+
+**Orphan Functional Requirements:** 0
+**Unsupported Success Criteria:** 0
+**User Journeys Without FRs:** 0
+
+### Traceability Matrix (Knowledge Graph FRs)
+
+| FR Range | Source Journey/Objective |
+|---|---|
+| FR141–143 (data model, index) | Capability #17, Noam/Alon journeys |
+| FR144–147 (JSON format) | "LLM-friendly JSON" in Capability #17, Exec Summary |
+| FR148–150 (skill emission) | "automatic traceability" in Exec Summary, Success Criteria |
+| FR151 (open-graph skill) | Yael/Noam/Alon journeys (`/open-graph`) |
+| FR152–155 (visualization) | Success Criteria, Yael/Noam/Alon journeys |
+
+**Total Traceability Issues:** 0
+
+**Severity:** Pass — traceability chain fully intact for all new content.
+
+---
+
+## Implementation Leakage Validation
+
+### Leakage by Category
+
+**Algorithm/Approach (new):** 1 violation
+- FR152: "force-directed interactive visualization" — specifies rendering algorithm. Should be "interactive graph visualization" (what), not "force-directed" (how).
+
+**UI Element (new):** 1 violation
+- FR154: "via checkboxes in the visualization panel" — specifies UI control type. Should be "via filtering controls" (what), not "checkboxes" (how).
+
+**Internal Mechanism (new):** 1 violation
+- FR148: "atomically: read current JSON, add new nodes/edges, write back" — describes the internal write mechanism. The atomicity requirement is valid; the read-write sequence belongs in architecture.
+
+**Integration Protocol (new):** 1 violation
+- FR151: "`vscode://file/{absolute-path}#{anchor}` URI scheme" — specific URI format is an integration protocol detail. The capability (navigate to document anchor) is valid; the URI scheme belongs in architecture.
+
+**Rendering Implementation (new):** 1 violation
+- FR155: "all JavaScript and CSS is inlined" — specifies the rendering implementation mechanism. The capability (self-contained, no external dependencies, air-gapped) is valid and should remain; "inlined" is the how.
+
+**Note on intentional product design decisions (NOT violations):**
+The following appear implementation-like but are intentional, capability-defining product decisions consistent with the PRD's established style (see FR123's CLI flags, FR133's YAML schema, FR480-519's full schema block):
+- JSON format choice and flat structure — defines the LLM-friendly format, which IS the capability
+- File paths (`knowledge-graph.json`, `knowledge-graph.html`) — product artifact locations
+- Node ID format (`filename#heading-anchor`) — the graph identity contract
+- Edge field names and schemas — the graph data model, which IS the product
+
+### Summary
+
+**Total Implementation Leakage Violations:** 5 (all in new FR141–155)
+
+**Severity:** Warning (exactly 5 violations)
+
+**Recommendation:** Remove algorithm, UI element, and mechanism specifics from 5 FRs listed above. Preserve the capability intent — move implementation choices to architecture. All violations are in the newly added Knowledge Graph FRs.
+
+---
+
+## Domain Compliance Validation
+
+**Domain:** `software_engineering_development_methodology`
+**Complexity:** Medium (developer tool with defense/MIL-498 component)
+
+**MIL-STD-498 compliance:** Documented in Domain-Specific Requirements section ✓
+**Enterprise SDLC governance:** Documented ✓
+**Audit trail:** ai-audit-trail skill documented (FR48) ✓
+**Air-gapped / disconnected environments:** FR44, NFR2, NFR35 ✓
+**No data exfiltration:** NFR1 ✓
+**Cross-platform:** NFR9, FR45 ✓
+
+**Assessment:** Pass — all relevant domain constraints properly documented.
+
+---
+
+## Project-Type Compliance Validation
+
+**Project Type:** `developer_tool_methodology_platform`
+
+| Requirement | Status |
+|---|---|
+| Developer Tool specific requirements section | Present ✓ |
+| Language matrix (runtime + content + authoring) | Present ✓ |
+| Installation methods documented | Present ✓ |
+| IDE / agent integration model | Present ✓ |
+| Documentation & methodology resources table | Present ✓ |
+| Implementation considerations section | Present ✓ |
+
+**Compliance Score:** 6/6 — Pass
+
+---
+
+## SMART Requirements Validation (FR141–FR155)
+
+**Total New FRs Analyzed:** 15
+
+| FR | Specific | Measurable | Attainable | Relevant | Traceable | Avg | Flag |
+|---|---|---|---|---|---|---|---|
+| FR141 | 4 | 4 | 5 | 5 | 5 | 4.6 | |
+| FR142 | 5 | 5 | 5 | 5 | 5 | 5.0 | |
+| FR143 | 4 | 4 | 4 | 5 | 5 | 4.4 | |
+| FR144 | 5 | 4 | 5 | 5 | 5 | 4.8 | |
+| FR145 | 5 | 5 | 5 | 4 | 4 | 4.6 | |
+| FR146 | 5 | 5 | 5 | 4 | 4 | 4.6 | |
+| FR147 | 5 | 5 | 5 | 4 | 4 | 4.6 | |
+| FR148 | 4 | 4 | 4 | 5 | 5 | 4.4 | |
+| FR149 | 4 | 4 | 4 | 5 | 5 | 4.4 | |
+| FR150 | 4 | 5 | 5 | 4 | 4 | 4.4 | |
+| FR151 | 4 | 4 | 4 | 5 | 5 | 4.4 | |
+| FR152 | 4 | 3 | 4 | 5 | 5 | 4.2 | |
+| FR153 | 5 | 5 | 5 | 5 | 5 | 5.0 | |
+| FR154 | 3 | 4 | 5 | 5 | 5 | 4.4 | |
+| FR155 | 5 | 5 | 5 | 5 | 5 | 5.0 | |
+
+**All scores ≥ 3:** 100% (15/15)
+**All scores ≥ 4:** 87% (13/15) — FR152 (Measurable=3), FR154 (Specific=3)
+**Overall Average Score:** 4.6/5.0
+
+**Severity:** Pass — all new FRs meet acceptable SMART thresholds.
+
+---
+
+## Holistic Quality Validation
+
+**Overall PRD Maturity:** Very high — this PRD has been through multiple validation and edit cycles with a deep edit history spanning from 2026-03-05 to 2026-04-07.
+
+**Strengths:**
+- Exceptional information density — zero filler phrases across ~700 lines
+- Strong user journey coverage (7 roles, all with capability-tagged summaries)
+- Rich innovation section with genuine novel patterns
+- NFR measurability is strong — nearly all NFRs have specific metrics and measurement methods
+- Full SDLC traceability from brief → PRD → journeys → FRs → NFRs
+- Consistent style and voice throughout
+
+**Areas for Improvement:**
+- 5 implementation leakage items in new Knowledge Graph FRs (see above)
+- FR145-147 (JSON schemas with exact field names) sit at the PRD/Architecture boundary — intentional product design choices, but worth flagging for downstream architecture doc to reference them explicitly
+- No SMART flags, but FR152/FR154 are the weakest new FRs
+
+**Holistic Quality Rating:** 4/5 — Excellent, minor improvements available
+
+---
+
+## Completeness Validation
+
+| Section | Status |
+|---|---|
+| Executive Summary | Present, comprehensive ✓ |
+| System Overview (Capability Areas 1-17) | Present, all 17 areas documented ✓ |
+| Success Criteria (User / Technical / Measurable) | Present ✓ |
+| User Journeys (7 roles) | Present ✓ |
+| Journey Requirements Summary table | Present, updated ✓ |
+| Domain-Specific Requirements | Present ✓ |
+| Innovation & Novel Patterns | Present ✓ |
+| Developer Tool Specific Requirements | Present ✓ |
+| Functional Requirements (FR1–FR155) | Present ✓ |
+| Non-Functional Requirements (NFR1–NFR41) | Present ✓ |
+| Frontmatter (classification, edit history) | Present, updated ✓ |
+
+**Completeness Score:** 11/11 sections — Pass
+
+**FR coverage of Capability Areas:**
+All 17 Capability Areas (including new #17 Knowledge Graph) have corresponding FRs. ✓

package/lib/bmad-cache/bmb/.claude-plugin/marketplace.json

@@ -6,17 +6,52 @@
   "license": "MIT",
   "homepage": "https://github.com/bmad-code-org/bmad-builder",
   "repository": "https://github.com/bmad-code-org/bmad-builder",
-  "keywords": ["bmad", "agent-builder", "workflow-builder", "skill-factory", "ai-agents"],
+  "keywords": ["bmad", "agent-builder", "workflow-builder", "module-builder", "skill-factory", "ai-agents"],
   "plugins": [
     {
       "name": "bmad-builder",
       "source": "./",
-      "description": "Build AI agents and workflows from a conversation. Three skills — Agent Builder, Workflow Builder, and Setup — guide you from idea to production-ready skill structure with built-in quality optimization. Part of the BMad Method ecosystem.",
-      "version": "1.1.0",
+      "description": "Build AI agents, workflows, and modules from a conversation. Four skills — Agent Builder, Workflow Builder, Module Builder, and Setup — guide you from idea to production-ready skill structure with built-in quality optimization. Part of the BMad Method ecosystem.",
+      "version": "1.5.0",
       "author": {
         "name": "Brian (BMad) Madison"
       },
-      "skills": ["./skills/bmad-agent-builder", "./skills/bmad-builder-setup", "./skills/bmad-workflow-builder"]
+      "skills": [
+        "./skills/bmad-agent-builder",
+        "./skills/bmad-bmb-setup",
+        "./skills/bmad-module-builder",
+        "./skills/bmad-workflow-builder"
+      ]
+    },
+    {
+      "name": "sample-plugins",
+      "source": "./",
+      "description": "Sample plugins demonstrating how to build BMad agents and skills. Includes a code coach, creative muse, diagram reviewer, dream weaver, sentinel, and excalidraw generator.",
+      "version": "1.0.0",
+      "author": {
+        "name": "Brian (BMad) Madison"
+      },
+      "skills": [
+        "./samples/bmad-agent-code-coach",
+        "./samples/bmad-agent-creative-muse",
+        "./samples/bmad-agent-diagram-reviewer",
+        "./samples/bmad-agent-dream-weaver",
+        "./samples/bmad-agent-sentinel",
+        "./samples/bmad-excalidraw",
+        "./samples/sample-module-setup"
+      ]
+    },
+    {
+      "name": "bmad-dream-weaver-agent",
+      "source": "./",
+      "description": "Dream journaling and interpretation agent with lucid dreaming coaching, pattern discovery, symbol analysis, and recall training.",
+      "version": "1.0.0",
+      "author": {
+        "name": "Brian (BMad) Madison"
+      },
+      "skills": [
+        "./samples/bmad-agent-dream-weaver"
+      ]
     }
   ]
 }