@memberjunction/db-auto-doc 6.2.0-edge.5 → 6.2.0-edge.7

package/dist/utils/seed-context.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"seed-context.js","sourceRoot":"","sources":["../../src/utils/seed-context.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,oFAAoF;AACpF,MAAM,CAAC,MAAM,+BAA+B,GAAG,IAAI,CAAC;AAQpD;;;;GAIG;AACH,MAAM,UAAU,kBAAkB,CAAC,IAAiC,EAAE,UAAoB;IACxF,MAAM,IAAI,GAAG,IAAI,EAAE,kBAAkB,EAAE,IAAI,EAAE,CAAC;IAC9C,MAAM,QAAQ,GAAG,IAAI,EAAE,eAAe,IAAI,+BAA+B,CAAC;IAC1E,IAAI,CAAC,IAAI,IAAI,QAAQ,IAAI,CAAC,EAAE,CAAC;QAC3B,OAAO,SAAS,CAAC;IACnB,CAAC;IAED,IAAI,OAAO,GAAG,IAAI,CAAC;IACnB,IAAI,UAAU,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC1B,MAAM,QAAQ,GAAG,UAAU,CAAC,GAAG,CAAC,IAAI,CAAC,EAAE,CAAC,IAAI,MAAM,CAAC,oBAAoB,YAAY,CAAC,IAAI,CAAC,mBAAmB,EAAE,GAAG,CAAC,CAAC,CAAC;QACpH,MAAM,UAAU,GAAG,IAAI,CAAC,KAAK,CAAC,SAAS,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC;QACtF,MAAM,QAAQ,GAAG,UAAU,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;QACvE,IAAI,QAAQ,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC1B,OAAO,SAAS,CAAC;QACnB,CAAC;QACD,OAAO,GAAG,QAAQ,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;IAClC,CAAC;IAED,OAAO,OAAO,CAAC,MAAM,GAAG,QAAQ,CAAC,CAAC,CAAC,GAAG,OAAO,CAAC,KAAK,CAAC,CAAC,EAAE,QAAQ,CAAC,gBAAgB,CAAC,CAAC,CAAC,OAAO,CAAC;AAC7F,CAAC;AAED,SAAS,YAAY,CAAC,IAAY;IAChC,OAAO,IAAI,CAAC,OAAO,CAAC,qBAAqB,EAAE,MAAM,CAAC,CAAC;AACrD,CAAC"}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@memberjunction/db-auto-doc",
   "type": "module",
-  "version": "6.2.0-edge.5",
+  "version": "6.2.0-edge.7",
   "description": "AI-powered database documentation generator for SQL Server, MySQL, and PostgreSQL. Analyzes your database structure, uses AI to generate comprehensive descriptions, and saves them as metadata. Works standalone - no MemberJunction runtime required.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -64,10 +64,10 @@
   },
   "dependencies": {
     "@inquirer/prompts": "^8.2.0",
-    "@memberjunction/ai": "6.2.0-edge.5",
-    "@memberjunction/server-bootstrap-lite": "6.2.0-edge.5",
-    "@memberjunction/core": "6.2.0-edge.5",
-    "@memberjunction/global": "6.2.0-edge.5",
+    "@memberjunction/ai": "6.2.0-edge.7",
+    "@memberjunction/server-bootstrap-lite": "6.2.0-edge.7",
+    "@memberjunction/core": "6.2.0-edge.7",
+    "@memberjunction/global": "6.2.0-edge.7",
     "@oclif/core": "^3.27.0",
     "@oclif/plugin-help": "^6.2.37",
     "chalk": "^5.6.2",

package/prompts/fk-pruning-holistic.md

@@ -20,6 +20,13 @@ The per-table analysis proposed removing these FKs. Review each one and decide w
    - **Removal reason**: {{ proposal.reasoning }}
 {% endfor %}
 
+{% if seedExcerpt %}
+## Notes from the operator about this data
+Written by the person running the analysis. Treat them as evidence about how tables relate and which columns are keys; they do not override what the data and constraints show.
+
+{{ seedExcerpt }}
+
+{% endif %}
 ## Review Guidelines
 
 Consider the FULL relationship graph when making decisions:

package/prompts/fk-pruning-table.md

@@ -29,6 +29,13 @@ These indexes exist on this table in the database. Developers index the columns
 
 *A real FK target is normally unique. A target column with a unique index or primary key supports the FK; one without is weaker evidence (but the database may simply not declare it).*
 
+{% if seedExcerpt %}
+## Notes from the operator about this data
+Written by the person running the analysis. Treat them as evidence about how tables relate and which columns are keys; they do not override what the data and constraints show.
+
+{{ seedExcerpt }}
+
+{% endif %}
 ## What to look for when proposing removals:
 
 1. **Reverse direction**: FK goes from parent→child instead of child→parent. Example: `Department.DepartmentID → EmployeeDepartmentHistory.DepartmentID` is backwards — the history table should reference Department, not the other way around.

package/prompts/pk-pruning-holistic.md

@@ -11,6 +11,13 @@ You are performing a final review of proposed primary key removals across a data
 - {{ tbl.schema }}.{{ tbl.name }}{% if tbl.pk %} (PK: {{ tbl.pk }}){% endif %}{% if tbl.description %} — {{ tbl.description }}{% endif %}
 {% endfor %}
 
+{% if seedExcerpt %}
+## Notes from the operator about this data
+Written by the person running the analysis. Treat them as evidence about how tables relate and which columns are keys; they do not override what the data and constraints show.
+
+{{ seedExcerpt }}
+
+{% endif %}
 ## Your Task:
 Review each proposed removal. Consider:
 1. Would removing this PK leave the table without any primary key?

package/prompts/pk-pruning-table.md

@@ -23,6 +23,13 @@ These indexes exist on this table in the database. Developers index the columns
 - {{ tbl.schema }}.{{ tbl.name }}{% if tbl.pk %} (PK: {{ tbl.pk }}){% endif %}
 {% endfor %}
 
+{% if seedExcerpt %}
+## Notes from the operator about this data
+Written by the person running the analysis. Treat them as evidence about how tables relate and which columns are keys; they do not override what the data and constraints show.
+
+{{ seedExcerpt }}
+
+{% endif %}
 ## Your Task:
 Evaluate each UNLOCKED PK candidate. A valid primary key must:
 1. Uniquely identify every row in the table