@wanshi-kg/wanshi 0.1.0

package/dist/core/llm/prompts/templates/partials/examples/legal.md

@@ -0,0 +1,153 @@
+### Example 1: Service agreement (date → observation on the document)
+
+Input:
+
+## File information
+
+Path: `contracts/services-001.txt`
+
+## Content to analyze
+```
+This Agreement ("Agreement") is made and entered into on February 10, 2022
+("Effective Date") by and between John Smith ("John") and Jane Doe ("Jane") for
+the provision of services.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Services Agreement",
+      "entityType": "document",
+      "observations": [
+        "Service-provision contract effective 2022-02-10",
+        "Between John Smith and Jane Doe"
+      ]
+    },
+    {
+      "name": "John Smith",
+      "entityType": "person",
+      "observations": ["Signatory to the Services Agreement"]
+    },
+    {
+      "name": "Jane Doe",
+      "entityType": "person",
+      "observations": ["Signatory to the Services Agreement"]
+    }
+  ],
+  "relations": [
+    { "from": "John Smith", "to": "Services Agreement", "relationType": ["signed"] },
+    { "from": "Jane Doe",   "to": "Services Agreement", "relationType": ["signed"] }
+  ]
+}
+```
+
+Note: the effective date is an observation on the document, not a `February 10, 2022`
+node. The relationship between the two parties is captured by each being a signatory
+to the shared document — no need for a separate symmetric `counterparties` edge in
+both directions. Type is `person`, not `Person` (lowercase, reused).
+
+---
+
+### Example 2: Court filing
+
+Input:
+
+## File information
+
+Path: `cases/acme-vs-globex.txt`
+
+## Content to analyze
+```
+Case No. 22-CV-0148, Acme Corp. v. Globex Inc., filed in the Northern District of
+California. Acme alleges breach of the Master Supply Agreement.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Acme Corp. v. Globex Inc.",
+      "entityType": "document",
+      "observations": [
+        "Civil case No. 22-CV-0148",
+        "Alleges breach of the Master Supply Agreement"
+      ]
+    },
+    {
+      "name": "Acme Corp.",
+      "entityType": "organization",
+      "observations": ["Plaintiff alleging breach of contract"]
+    },
+    {
+      "name": "Globex Inc.",
+      "entityType": "organization",
+      "observations": ["Defendant"]
+    },
+    {
+      "name": "Northern District of California",
+      "entityType": "court",
+      "observations": ["Venue for case 22-CV-0148"]
+    },
+    {
+      "name": "Master Supply Agreement",
+      "entityType": "document",
+      "observations": ["Contract alleged to have been breached"]
+    }
+  ],
+  "relations": [
+    { "from": "Acme Corp.",  "to": "Acme Corp. v. Globex Inc.", "relationType": ["party_to"] },
+    { "from": "Globex Inc.", "to": "Acme Corp. v. Globex Inc.", "relationType": ["party_to"] },
+    { "from": "Acme Corp. v. Globex Inc.", "to": "Northern District of California", "relationType": ["filed_in"] },
+    { "from": "Acme Corp. v. Globex Inc.", "to": "Master Supply Agreement", "relationType": ["references"] }
+  ]
+}
+```
+
+---
+
+### Example 3: Statute definition
+
+Input:
+
+## File information
+
+Path: `statutes/privacy-act-s4.txt`
+
+## Content to analyze
+```
+Section 4 of the Privacy Act defines "personal data" as any information relating to
+an identified or identifiable natural person.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Privacy Act",
+      "entityType": "statute",
+      "observations": ["Section 4 defines the term 'personal data'"]
+    },
+    {
+      "name": "personal data",
+      "entityType": "term",
+      "observations": ["Any information relating to an identified or identifiable natural person"]
+    }
+  ],
+  "relations": [
+    { "from": "Privacy Act", "to": "personal data", "relationType": ["defines"] }
+  ]
+}
+```
+
+Note: type set is small and reused (`document, person, organization, court, statute,
+term`). Every predicate is one canonical verb from the legal set (`signed`,
+`party_to`, `filed_in`, `references`, `defines`) — none restates endpoint types, none
+is a two-synonym array, and direction is consistent (party → document, document →
+court).

package/dist/core/llm/prompts/templates/partials/examples/logs.md

@@ -0,0 +1,127 @@
+### Example 1: Apache access log (timestamp → observation, real predicate)
+
+Input:
+
+## File information
+
+Path: `logs/apache_access.log`
+
+## Content to analyze
+```
+192.168.1.100 - - [10/Oct/2022:14:30:00 +0000] "GET /index.html HTTP/1.1" 200 1234 "-" "Mozilla/5.0"
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "192.168.1.100",
+      "entityType": "ip_address",
+      "observations": ["Client that issued a GET request", "User agent Mozilla/5.0"]
+    },
+    {
+      "name": "GET /index.html",
+      "entityType": "request",
+      "observations": [
+        "HTTP/1.1 GET for /index.html at 2022-10-10 14:30:00 UTC",
+        "Responded 200 with 1234 bytes"
+      ]
+    }
+  ],
+  "relations": [
+    { "from": "192.168.1.100", "to": "GET /index.html", "relationType": ["requests"] }
+  ]
+}
+```
+
+Note: the timestamp is an observation on the request, not a `TIMESTAMP` hub node that
+every edge points at. The relation is one real interaction with a verb-like predicate
+(`requests`) — never `["SOURCE_IP", "REQUEST_METHOD"]`, which just restates the two
+endpoint types and is not a predicate at all. Types are lowercase and reused.
+
+---
+
+### Example 2: Auth failure (actors + error)
+
+Input:
+
+## File information
+
+Path: `logs/auth.log`
+
+## Content to analyze
+```
+2022-10-10 14:32:11 sshd[2451]: Failed password for invalid user admin from 203.0.113.7 port 52344
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "203.0.113.7",
+      "entityType": "ip_address",
+      "observations": ["Source of a failed SSH login attempt at 2022-10-10 14:32:11"]
+    },
+    {
+      "name": "admin",
+      "entityType": "user",
+      "observations": ["Invalid user targeted in the failed login"]
+    },
+    {
+      "name": "sshd",
+      "entityType": "service",
+      "observations": ["SSH daemon (pid 2451) that rejected the login"]
+    }
+  ],
+  "relations": [
+    { "from": "203.0.113.7", "to": "admin", "relationType": ["authenticates_as"] },
+    { "from": "203.0.113.7", "to": "sshd",  "relationType": ["targets"] }
+  ]
+}
+```
+
+---
+
+### Example 3: Application error
+
+Input:
+
+## File information
+
+Path: `logs/app.log`
+
+## Content to analyze
+```
+2022-10-10 14:35:02 ERROR OrderService - NullPointerException while processing order 8841
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "OrderService",
+      "entityType": "service",
+      "observations": ["Raised a NullPointerException while processing order 8841 at 2022-10-10 14:35:02"]
+    },
+    {
+      "name": "NullPointerException",
+      "entityType": "error",
+      "observations": ["Thrown during order processing in OrderService"]
+    }
+  ],
+  "relations": [
+    { "from": "OrderService", "to": "NullPointerException", "relationType": ["reports"] }
+  ]
+}
+```
+
+Note: across the file the type set stays small (`ip_address, user, service, request,
+error`) and every relation is a single real interaction — `requests`,
+`authenticates_as`, `targets`, `reports`. No timestamp nodes, no type-pair
+"predicates", no self-loops, consistent actor → object direction.

package/dist/core/llm/prompts/templates/partials/examples/medical.md

@@ -0,0 +1,218 @@
+### Example 1: Patient record with vitals (literals → observations)
+
+Input:
+
+## File information
+
+Path: `records/john-smith.txt`
+
+## Content to analyze
+```
+Patient Name: John Smith, Date: 2022-01-01, Test Result: Blood Pressure 120/80 mmHg,
+Heart Rate 70 bpm.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "John Smith",
+      "entityType": "person",
+      "observations": [
+        "Patient; record dated 2022-01-01",
+        "Blood pressure 120/80 mmHg",
+        "Heart rate 70 bpm"
+      ]
+    }
+  ],
+  "relations": []
+}
+```
+
+Note: `120/80 mmHg` and `70 bpm` are measured values, not nodes. They live as
+observations on the patient. The type is `person`, not `Patient Name` — the name is
+the patient's name, the type is the category. One real entity → empty `relations`.
+
+---
+
+### Example 2: Prescription
+
+Input:
+
+## File information
+
+Path: `rx/jane-doe.txt`
+
+## Content to analyze
+```
+Patient Name: Jane Doe, Medication: Amoxicillin 500mg, Dosage: 2 tablets,
+Frequency: 3 times a day.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Jane Doe",
+      "entityType": "person",
+      "observations": ["Patient prescribed Amoxicillin"]
+    },
+    {
+      "name": "Amoxicillin",
+      "entityType": "medication",
+      "observations": ["Prescribed at 500mg, 2 tablets, 3 times a day"]
+    }
+  ],
+  "relations": [
+    { "from": "Jane Doe", "to": "Amoxicillin", "relationType": ["prescribed"] }
+  ]
+}
+```
+
+Note: dosage and frequency are observations on the medication, not `2 tablets` /
+`3 times a day` nodes. The medication name is canonical (`Amoxicillin`), with the
+specific strength in the observation so the same drug merges across records.
+
+---
+
+### Example 3: Medical record (diagnosis + medication)
+
+Input:
+
+## File information
+
+Path: `records/bob-johnson.txt`
+
+## Content to analyze
+```
+Patient Name: Bob Johnson, Date: 2020-01-01, Diagnosis: Diabetes Type 2,
+Medication: Metformin 1000mg.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Bob Johnson",
+      "entityType": "person",
+      "observations": ["Patient; record dated 2020-01-01"]
+    },
+    {
+      "name": "Diabetes Type 2",
+      "entityType": "condition",
+      "observations": ["Chronic metabolic condition"]
+    },
+    {
+      "name": "Metformin",
+      "entityType": "medication",
+      "observations": ["Prescribed at 1000mg"]
+    }
+  ],
+  "relations": [
+    { "from": "Bob Johnson", "to": "Diabetes Type 2", "relationType": ["diagnosed_with"] },
+    { "from": "Bob Johnson", "to": "Metformin",       "relationType": ["prescribed"] }
+  ]
+}
+```
+
+---
+
+### Example 4: Lab report (test → result)
+
+Input:
+
+## File information
+
+Path: `labs/rachel-kim.txt`
+
+## Content to analyze
+```
+Patient Name: Rachel Kim, Date: 2022-10-01, Test: Blood Test, Result: Abnormal —
+elevated white cell count.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Rachel Kim",
+      "entityType": "person",
+      "observations": ["Patient; blood test dated 2022-10-01"]
+    },
+    {
+      "name": "Blood Test",
+      "entityType": "test",
+      "observations": ["Result abnormal: elevated white cell count"]
+    }
+  ],
+  "relations": [
+    { "from": "Rachel Kim", "to": "Blood Test", "relationType": ["underwent"] }
+  ]
+}
+```
+
+Note: `Abnormal` is not a `result` node — the finding is an observation on the test.
+A bare result value with no further entity to anchor it is just an observation.
+
+---
+
+### Example 5: Allergy + procedure with provider
+
+Input:
+
+## File information
+
+Path: `records/laura-davis.txt`
+
+## Content to analyze
+```
+Patient Name: Laura Davis, Date: 2022-08-01, Allergy: Penicillin (causes rash),
+Procedure: Appendectomy performed by Dr. Johnson.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Laura Davis",
+      "entityType": "person",
+      "observations": ["Patient; record dated 2022-08-01", "Allergic to penicillin (rash)"]
+    },
+    {
+      "name": "Penicillin",
+      "entityType": "medication",
+      "observations": ["Causes a rash in this patient"]
+    },
+    {
+      "name": "Appendectomy",
+      "entityType": "procedure",
+      "observations": ["Surgical removal of the appendix"]
+    },
+    {
+      "name": "Dr. Johnson",
+      "entityType": "provider",
+      "observations": ["Surgeon who performed the appendectomy"]
+    }
+  ],
+  "relations": [
+    { "from": "Laura Davis",  "to": "Penicillin",   "relationType": ["allergic_to"] },
+    { "from": "Laura Davis",  "to": "Appendectomy", "relationType": ["underwent"] },
+    { "from": "Laura Davis",  "to": "Dr. Johnson",  "relationType": ["treated_by"] }
+  ]
+}
+```
+
+Note: type set stays small and reused (`person, medication, condition, test,
+procedure, provider`). Every predicate is a single verb-like label from the medical
+set; none restates the endpoint types (`has Blood Pressure` is gone). Direction is
+consistent: patient → thing.

package/dist/core/llm/prompts/templates/partials/examples/notes.md

@@ -0,0 +1,201 @@
+### Example 1
+
+Input:
+
+## File Information
+
+Path: `docs/api-glossary.md`
+
+## Content to Analyze
+
+```
+# REST API Glossary
+
+## Idempotency
+An operation is **idempotent** if performing it multiple times produces the same result as
+performing it once. In REST, PUT and DELETE are required to be idempotent by the HTTP spec;
+POST is not. Clients should retry idempotent requests on network failure.
+Related: safe method, retry semantics, PUT vs PATCH.
+
+## Rate Limiting
+The server enforces a maximum number of requests per time window per API key. Exceeded
+limits return HTTP 429 Too Many Requests with a `Retry-After` header.
+Standards: IETF RFC 6585 (additional HTTP status codes).
+Related: quota, throttling, backoff strategy.
+
+## Pagination (Cursor-based)
+Results are returned in pages using an opaque cursor token rather than page numbers.
+The response includes a `next_cursor` field; pass it as `?cursor=<value>` in the next
+request. Cursors are stable against concurrent inserts.
+Related: offset pagination, keyset pagination, infinite scroll.
+
+## Webhook
+An HTTP callback registered by the client to receive event notifications from the server.
+The server POSTs a signed JSON payload to the client's endpoint when the event fires.
+Clients should verify the `X-Signature-256` header to authenticate payloads.
+Related: polling, event streaming, idempotency key.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Idempotency",
+      "entityType": "concept",
+      "observations": [
+        "Property where repeated operations produce the same result as one execution",
+        "Required by HTTP spec for PUT and DELETE methods",
+        "Enables safe client retries on network failures"
+      ]
+    },
+    {
+      "name": "Rate Limiting",
+      "entityType": "concept",
+      "observations": [
+        "Server-enforced cap on requests per time window per API key",
+        "Returns HTTP 429 with Retry-After header when exceeded",
+        "Governed by IETF RFC 6585"
+      ]
+    },
+    {
+      "name": "Cursor-based Pagination",
+      "entityType": "concept",
+      "observations": [
+        "Uses opaque cursor token instead of page numbers",
+        "Cursor passed via ?cursor= query parameter",
+        "Stable against concurrent inserts unlike offset pagination"
+      ]
+    },
+    {
+      "name": "Webhook",
+      "entityType": "concept",
+      "observations": [
+        "HTTP callback for server-to-client event notifications",
+        "Server POSTs signed JSON payload to registered client endpoint",
+        "Signature verified via X-Signature-256 header"
+      ]
+    },
+    {
+      "name": "IETF RFC 6585",
+      "entityType": "standard",
+      "observations": ["Defines additional HTTP status codes including 429 Too Many Requests"]
+    }
+  ],
+  "relations": [
+    { "from": "Rate Limiting",          "to": "IETF RFC 6585",          "relationType": ["governed_by"] },
+    { "from": "Idempotency",            "to": "Webhook",                 "relationType": ["related_to"] }
+  ]
+}
+```
+
+---
+
+### Example 2
+
+Input:
+
+## File Information
+
+Path: `docs/feature-catalog.md`
+
+## Content to Analyze
+
+```
+# Product Feature Catalog — Nexus Platform
+
+## Real-time Collaboration
+Simultaneous editing with conflict-free replicated data types (CRDTs).
+Tiers: Pro, Enterprise.
+Requires: WebSocket support in client environment.
+Compatible with: Document Editor, Whiteboard, Code Review modules.
+
+## SSO / SAML 2.0
+Single sign-on via SAML 2.0 identity providers (Okta, Azure AD, Google Workspace).
+Tiers: Enterprise only.
+Requires: Admin configuration of IdP metadata URL and certificate.
+Compatible with: All modules. Incompatible with: Legacy API key auth (cannot be used simultaneously).
+
+## Audit Log
+Immutable, tamper-evident log of all user actions and configuration changes.
+Exported as JSON or CSV. Retention: 90 days (Pro), 2 years (Enterprise).
+Tiers: Pro, Enterprise.
+Compatible with: SIEM integrations (Splunk, Datadog).
+
+## AI Summarization
+One-click summary of documents, threads, and activity feeds using LLM backend.
+Tiers: Pro (10 summaries/day), Enterprise (unlimited).
+Requires: Nexus AI add-on license.
+Compatible with: Document Editor, Inbox modules.
+```
+
+Output:
+
+```json
+{
+  "entities": [
+    {
+      "name": "Real-time Collaboration",
+      "entityType": "feature",
+      "observations": [
+        "Uses CRDTs for conflict-free simultaneous editing",
+        "Available on Pro and Enterprise tiers",
+        "Requires WebSocket support in client environment"
+      ]
+    },
+    {
+      "name": "SSO / SAML 2.0",
+      "entityType": "feature",
+      "observations": [
+        "Enterprise-only feature",
+        "Supports Okta, Azure AD, Google Workspace as identity providers",
+        "Incompatible with legacy API key authentication when enabled"
+      ]
+    },
+    {
+      "name": "Audit Log",
+      "entityType": "feature",
+      "observations": [
+        "Immutable, tamper-evident action log",
+        "Retention: 90 days (Pro), 2 years (Enterprise)",
+        "Exportable as JSON or CSV; compatible with SIEM tools"
+      ]
+    },
+    {
+      "name": "AI Summarization",
+      "entityType": "feature",
+      "observations": [
+        "LLM-backed document and thread summarization",
+        "Pro tier: 10 summaries/day; Enterprise: unlimited",
+        "Requires Nexus AI add-on license"
+      ]
+    },
+    {
+      "name": "Pro",
+      "entityType": "tier",
+      "observations": ["Mid-tier plan; includes Real-time Collaboration, Audit Log, AI Summarization (limited)"]
+    },
+    {
+      "name": "Enterprise",
+      "entityType": "tier",
+      "observations": ["Top-tier plan; includes all features with extended limits"]
+    },
+    {
+      "name": "Nexus AI add-on",
+      "entityType": "dependency",
+      "observations": ["Required license for AI Summarization feature"]
+    }
+  ],
+  "relations": [
+    { "from": "Real-time Collaboration", "to": "Pro",              "relationType": ["included_in"] },
+    { "from": "Real-time Collaboration", "to": "Enterprise",       "relationType": ["included_in"] },
+    { "from": "SSO / SAML 2.0",         "to": "Enterprise",       "relationType": ["included_in"] },
+    { "from": "Audit Log",               "to": "Pro",              "relationType": ["included_in"] },
+    { "from": "Audit Log",               "to": "Enterprise",       "relationType": ["included_in"] },
+    { "from": "AI Summarization",        "to": "Pro",              "relationType": ["included_in"] },
+    { "from": "AI Summarization",        "to": "Enterprise",       "relationType": ["included_in"] },
+    { "from": "AI Summarization",        "to": "Nexus AI add-on",  "relationType": ["requires"] }
+  ]
+}
+```