@kaddo/mcp 3.119.0 → 3.121.0

package/dist/index.js

@@ -4468,6 +4468,9 @@ function buildPocReportContext(dir) {
       `Canonical conclusion: ${poc.conclusion}. Do not contradict it.`,
       "Use the 15 canonical sections. Mark missing evidence as Not evaluated, Not applicable, or No evidence available.",
       "Distinguish measured, calculated, estimated, and projected values. Never include secret values.",
+      "Choose the representation that best communicates each grounded fact: Markdown tables for structured comparisons, Mermaid for grounded architecture, flows, or relationships, and prose for explanation and interpretation.",
+      "Do not invent data, entities, relationships, priorities, or metrics to create a table or diagram. Do not use ASCII diagrams when Mermaid can represent the same grounded flow.",
+      "In Traceability, use repository-relative Markdown links or paths. Never use file:/// URLs or local absolute filesystem paths.",
       "",
       "Selected sources:",
       sourceList
@@ -5734,6 +5737,49 @@ After a POC has a canonical conclusion and Core has prepared its deterministic r
 - Use \`Not evaluated in this POC.\`, \`Not applicable.\`, or \`No evidence available.\` when sources do not support a section.
 - Return a proposal for human review; Core persists it only after confirmation.
 
+## Representation selection
+
+- Use prose for context, interpretation, rationale, findings, and conclusions.
+- Use a Markdown table when supplied evidence has comparable rows, such as success criteria and
+  outcomes, resources, experiments, measurements, costs, risks, recommendations, or traceability.
+- Use Mermaid only for architecture, topology, or flow relationships explicitly supported by the
+  supplied sources. Prefer it to an ASCII diagram when both can represent the same grounded flow.
+- Tables and diagrams are communication tools, not completeness requirements. Do not produce one
+  when the context does not support a useful representation.
+- Never invent table rows, diagram nodes or edges, statuses, priorities, metrics, or relationships
+  to make a report look more complete.
+- Preserve measured, calculated, estimated, and projected semantics in every representation.
+- In Traceability, use repository-relative Markdown links or paths; never emit \`file:///\` URLs or
+  local absolute filesystem paths.
+
+## Section representation guide
+
+| Section | Preferred representation when supported by evidence |
+|---|---|
+| Executive Summary | Snapshot table and short prose |
+| Problem and Objective | Prose |
+| Hypothesis and Success Criteria | Evaluation matrix |
+| Scope, Constraints and Non-goals | Compact bullets or table |
+| Technical Approach and Architecture | Mermaid and prose |
+| Infrastructure and Project Resources | Table, with optional Mermaid |
+| Implementation and Relevant Technical Decisions | Table or concise prose |
+| Experiments and Validation | Validation matrix |
+| Results and Measurements | Measurement tables |
+| Cost and Efficiency Analysis | Comparison table |
+| Observability and Operational Findings | Table or prose |
+| Findings, Learnings, Limitations and Risks | Structured matrix |
+| Conclusion | Status and concise prose |
+| Recommendation and Next Steps | Recommendation matrix only when priority is evidenced |
+| Traceability and Sources | Relative-link table or list |
+
+## Quality checklist
+
+- Structured evidence uses tables when clearer than prose.
+- Grounded architecture or flows use Mermaid when useful; no decorative or unsupported diagrams exist.
+- Tables and Mermaid preserve source grounding and measurement semantics.
+- Traceability contains repository-portable paths.
+- The report is scannable before reading the full narrative.
+
 ## Required structure
 
 1. Executive Summary
@@ -13954,6 +14000,9 @@ function buildPocReportContext2(dir) {
       `Canonical conclusion: ${poc.conclusion}. Do not contradict it.`,
       "Use the 15 canonical sections. Mark missing evidence as Not evaluated, Not applicable, or No evidence available.",
       "Distinguish measured, calculated, estimated, and projected values. Never include secret values.",
+      "Choose the representation that best communicates each grounded fact: Markdown tables for structured comparisons, Mermaid for grounded architecture, flows, or relationships, and prose for explanation and interpretation.",
+      "Do not invent data, entities, relationships, priorities, or metrics to create a table or diagram. Do not use ASCII diagrams when Mermaid can represent the same grounded flow.",
+      "In Traceability, use repository-relative Markdown links or paths. Never use file:/// URLs or local absolute filesystem paths.",
       "",
       "Selected sources:",
       sourceList
@@ -14678,6 +14727,49 @@ After a POC has a canonical conclusion and Core has prepared its deterministic r
 - Use \`Not evaluated in this POC.\`, \`Not applicable.\`, or \`No evidence available.\` when sources do not support a section.
 - Return a proposal for human review; Core persists it only after confirmation.
 
+## Representation selection
+
+- Use prose for context, interpretation, rationale, findings, and conclusions.
+- Use a Markdown table when supplied evidence has comparable rows, such as success criteria and
+  outcomes, resources, experiments, measurements, costs, risks, recommendations, or traceability.
+- Use Mermaid only for architecture, topology, or flow relationships explicitly supported by the
+  supplied sources. Prefer it to an ASCII diagram when both can represent the same grounded flow.
+- Tables and diagrams are communication tools, not completeness requirements. Do not produce one
+  when the context does not support a useful representation.
+- Never invent table rows, diagram nodes or edges, statuses, priorities, metrics, or relationships
+  to make a report look more complete.
+- Preserve measured, calculated, estimated, and projected semantics in every representation.
+- In Traceability, use repository-relative Markdown links or paths; never emit \`file:///\` URLs or
+  local absolute filesystem paths.
+
+## Section representation guide
+
+| Section | Preferred representation when supported by evidence |
+|---|---|
+| Executive Summary | Snapshot table and short prose |
+| Problem and Objective | Prose |
+| Hypothesis and Success Criteria | Evaluation matrix |
+| Scope, Constraints and Non-goals | Compact bullets or table |
+| Technical Approach and Architecture | Mermaid and prose |
+| Infrastructure and Project Resources | Table, with optional Mermaid |
+| Implementation and Relevant Technical Decisions | Table or concise prose |
+| Experiments and Validation | Validation matrix |
+| Results and Measurements | Measurement tables |
+| Cost and Efficiency Analysis | Comparison table |
+| Observability and Operational Findings | Table or prose |
+| Findings, Learnings, Limitations and Risks | Structured matrix |
+| Conclusion | Status and concise prose |
+| Recommendation and Next Steps | Recommendation matrix only when priority is evidenced |
+| Traceability and Sources | Relative-link table or list |
+
+## Quality checklist
+
+- Structured evidence uses tables when clearer than prose.
+- Grounded architecture or flows use Mermaid when useful; no decorative or unsupported diagrams exist.
+- Tables and Mermaid preserve source grounding and measurement semantics.
+- Traceability contains repository-portable paths.
+- The report is scannable before reading the full narrative.
+
 ## Required structure
 
 1. Executive Summary

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kaddo/mcp",
-  "version": "3.119.0",
+  "version": "3.121.0",
   "description": "MCP server for Kaddo project knowledge: read-only resources/tools/prompts plus safe derived generation under .kaddo/.",
   "license": "MIT",
   "repository": {