studiograph 1.3.48-next.13 → 1.3.48-next.130

package/package.json

@@ -1,9 +1,12 @@
 {
   "name": "studiograph",
-  "version": "1.3.48-next.13",
+  "version": "1.3.48-next.130",
   "description": "Team-based AI agent platform with Git-backed knowledge graphs",
   "type": "module",
   "main": "dist/index.js",
+  "workspaces": [
+    "web"
+  ],
   "repository": {
     "type": "git",
     "url": "https://github.com/studiograph/studiograph"
@@ -20,13 +23,15 @@
     "README.md"
   ],
   "scripts": {
-    "build": "node --max-old-space-size=8192 node_modules/typescript/bin/tsc && mkdir -p dist/agent/prompts dist/agent/skills dist/server/chrome && cp src/agent/prompts/*.md dist/agent/prompts/ && cp -r src/agent/skills/* dist/agent/skills/ && cp src/server/chrome/* dist/server/chrome/",
-    "build:web": "cd web && npm run build",
+    "build": "node --max-old-space-size=8192 node_modules/typescript/bin/tsc && mkdir -p dist/agent/prompts dist/agent/skills && cp src/agent/prompts/*.md dist/agent/prompts/ && cp -r src/agent/skills/* dist/agent/skills/",
+    "build:web": "npm --workspace studiograph-web run build",
     "build:all": "npm run build && npm run build:web",
     "dev": "tsc --watch",
-    "dev:web": "cd web && npm run dev",
+    "dev:web": "npm --workspace studiograph-web run dev",
     "test": "vitest",
-    "lint": "eslint src --ext .ts",
+    "test:unit": "vitest run --project unit",
+    "test:integration": "vitest run --project integration",
+    "lint": "node --max-old-space-size=8192 node_modules/typescript/bin/tsc --noEmit",
     "prepublishOnly": "npm run build:all",
     "release:next": "npm publish --tag next"
   },
@@ -43,20 +48,23 @@
     "@ai-sdk/anthropic": "^3.0.46",
     "@ai-sdk/google": "^3.0.30",
     "@ai-sdk/openai": "^3.0.30",
-    "@anthropic-ai/sdk": "^0.78.0",
     "@aws-sdk/client-s3": "^3.500.0",
+    "@aws-sdk/s3-request-presigner": "^3.1045.0",
     "@clack/prompts": "^0.7.0",
     "@fastify/cookie": "^11.0.2",
     "@fastify/cors": "^10.1.0",
     "@fastify/multipart": "^9.4.0",
     "@fastify/websocket": "^11.2.0",
-    "@lancedb/lancedb": "^0.26.2",
-    "@mariozechner/pi-agent-core": "^0.54.2",
-    "@mariozechner/pi-ai": "^0.54.2",
-    "@mariozechner/pi-tui": "^0.54.2",
+    "@lancedb/lancedb": "^0.27.2",
+    "@mariozechner/pi-agent-core": "^0.70.2",
+    "@mariozechner/pi-ai": "^0.70.2",
+    "@mariozechner/pi-tui": "^0.70.2",
     "@modelcontextprotocol/sdk": "^1.26.0",
     "@mozilla/readability": "^0.6.0",
+    "@noble/ciphers": "^1.3.0",
+    "@types/archiver": "^7.0.0",
     "ai": "^6.0.97",
+    "archiver": "^7.0.1",
     "bcryptjs": "^3.0.3",
     "better-sqlite3": "^12.6.2",
     "chalk": "^5.6.2",
@@ -65,6 +73,7 @@
     "consola": "^3.4.2",
     "csv-parse": "^5.6.0",
     "csv-stringify": "^6.6.0",
+    "diff-match-patch": "^1.0.5",
     "fastify": "^5.7.4",
     "glob": "^10.3.10",
     "graphology": "^0.26.0",
@@ -77,9 +86,10 @@
     "ora": "^9.3.0",
     "pdf-parse": "^2.4.5",
     "picocolors": "^1.1.1",
+    "typebox": "^1.1.33",
     "y-protocols": "^1.0.7",
     "yjs": "^13.6.30",
-    "zod": "^3.22.4"
+    "zod": "^4.3.6"
   },
   "optionalDependencies": {
     "playwright": "^1.58.2"
@@ -87,15 +97,19 @@
   "devDependencies": {
     "@types/bcryptjs": "^2.4.6",
     "@types/better-sqlite3": "^7.6.13",
+    "@types/diff-match-patch": "^1.0.36",
     "@types/jsonwebtoken": "^9.0.10",
     "@types/node": "^20.11.0",
     "@types/ws": "^8.18.1",
-    "@typescript-eslint/eslint-plugin": "^6.19.0",
-    "@typescript-eslint/parser": "^6.19.0",
     "clsx": "^2.1.1",
-    "eslint": "^8.56.0",
     "tailwind-merge": "^3.5.0",
     "typescript": "^5.3.3",
     "vitest": "^1.2.0"
+  },
+  "overrides": {
+    "basic-ftp": "^6.0.1",
+    "fast-uri": "^3.1.2",
+    "fast-xml-builder": "^1.2.0",
+    "hono": "^4.12.18"
   }
 }

package/dist/agent/role-loader.d.ts

@@ -1,24 +0,0 @@
-/**
- * Role Loader — agent role definitions
- *
- * Roles are markdown files in src/agent/roles/ with YAML frontmatter.
- * Each role defines a specialized persona with a system prompt extension
- * that gets injected into the agent's context when the role is active.
- *
- * Frontmatter fields:
- *   name:        kebab-case identifier
- *   label:       human-readable display name
- *   description: shown in role selector
- *   icon:        Carbon icon name for the UI
- */
-export interface AgentRole {
-    name: string;
-    label: string;
-    description: string;
-    icon: string;
-    prompt: string;
-}
-/**
- * Load all role definitions from the roles directory.
- */
-export declare function loadRoles(rolesDir: string): AgentRole[];

package/dist/agent/role-loader.js

@@ -1,67 +0,0 @@
-/**
- * Role Loader — agent role definitions
- *
- * Roles are markdown files in src/agent/roles/ with YAML frontmatter.
- * Each role defines a specialized persona with a system prompt extension
- * that gets injected into the agent's context when the role is active.
- *
- * Frontmatter fields:
- *   name:        kebab-case identifier
- *   label:       human-readable display name
- *   description: shown in role selector
- *   icon:        Carbon icon name for the UI
- */
-import { existsSync, readdirSync, readFileSync } from 'fs';
-import { join, extname } from 'path';
-/**
- * Load all role definitions from the roles directory.
- */
-export function loadRoles(rolesDir) {
-    if (!existsSync(rolesDir))
-        return [];
-    const roles = [];
-    for (const file of readdirSync(rolesDir)) {
-        if (extname(file) !== '.md')
-            continue;
-        try {
-            const content = readFileSync(join(rolesDir, file), 'utf-8');
-            const { meta, body } = parseFrontmatter(content);
-            roles.push({
-                name: meta.name || file.replace('.md', ''),
-                label: meta.label || meta.name || file.replace('.md', ''),
-                description: meta.description || '',
-                icon: meta.icon || 'Chat',
-                prompt: body.trim(),
-            });
-        }
-        catch {
-            // Skip malformed files
-        }
-    }
-    // Ensure 'general' is always first
-    roles.sort((a, b) => {
-        if (a.name === 'general')
-            return -1;
-        if (b.name === 'general')
-            return 1;
-        return a.label.localeCompare(b.label);
-    });
-    return roles;
-}
-function parseFrontmatter(content) {
-    const match = content.match(/^---\r?\n([\s\S]*?)\r?\n---\r?\n?([\s\S]*)$/);
-    if (!match)
-        return { meta: {}, body: content };
-    const meta = {};
-    for (const line of match[1].split('\n')) {
-        const colon = line.indexOf(':');
-        if (colon === -1)
-            continue;
-        const key = line.slice(0, colon).trim();
-        const value = line.slice(colon + 1).trim();
-        if (key)
-            meta[key] = value;
-    }
-    return { meta, body: match[2] };
-}
-//# sourceMappingURL=role-loader.js.map

package/dist/agent/role-loader.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"role-loader.js","sourceRoot":"","sources":["../../src/agent/role-loader.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,EAAE,UAAU,EAAE,WAAW,EAAE,YAAY,EAAE,MAAM,IAAI,CAAC;AAC3D,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,MAAM,CAAC;AAUrC;;GAEG;AACH,MAAM,UAAU,SAAS,CAAC,QAAgB;IACxC,IAAI,CAAC,UAAU,CAAC,QAAQ,CAAC;QAAE,OAAO,EAAE,CAAC;IAErC,MAAM,KAAK,GAAgB,EAAE,CAAC;IAE9B,KAAK,MAAM,IAAI,IAAI,WAAW,CAAC,QAAQ,CAAC,EAAE,CAAC;QACzC,IAAI,OAAO,CAAC,IAAI,CAAC,KAAK,KAAK;YAAE,SAAS;QAEtC,IAAI,CAAC;YACH,MAAM,OAAO,GAAG,YAAY,CAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,EAAE,OAAO,CAAC,CAAC;YAC5D,MAAM,EAAE,IAAI,EAAE,IAAI,EAAE,GAAG,gBAAgB,CAAC,OAAO,CAAC,CAAC;YAEjD,KAAK,CAAC,IAAI,CAAC;gBACT,IAAI,EAAE,IAAI,CAAC,IAAI,IAAI,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,EAAE,CAAC;gBAC1C,KAAK,EAAE,IAAI,CAAC,KAAK,IAAI,IAAI,CAAC,IAAI,IAAI,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,EAAE,CAAC;gBACzD,WAAW,EAAE,IAAI,CAAC,WAAW,IAAI,EAAE;gBACnC,IAAI,EAAE,IAAI,CAAC,IAAI,IAAI,MAAM;gBACzB,MAAM,EAAE,IAAI,CAAC,IAAI,EAAE;aACpB,CAAC,CAAC;QACL,CAAC;QAAC,MAAM,CAAC;YACP,uBAAuB;QACzB,CAAC;IACH,CAAC;IAED,mCAAmC;IACnC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE;QAClB,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;YAAE,OAAO,CAAC,CAAC,CAAC;QACpC,IAAI,CAAC,CAAC,IAAI,KAAK,SAAS;YAAE,OAAO,CAAC,CAAC;QACnC,OAAO,CAAC,CAAC,KAAK,CAAC,aAAa,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC;IACxC,CAAC,CAAC,CAAC;IAEH,OAAO,KAAK,CAAC;AACf,CAAC;AAED,SAAS,gBAAgB,CAAC,OAAe;IACvC,MAAM,KAAK,GAAG,OAAO,CAAC,KAAK,CAAC,6CAA6C,CAAC,CAAC;IAC3E,IAAI,CAAC,KAAK;QAAE,OAAO,EAAE,IAAI,EAAE,EAAE,EAAE,IAAI,EAAE,OAAO,EAAE,CAAC;IAE/C,MAAM,IAAI,GAA2B,EAAE,CAAC;IACxC,KAAK,MAAM,IAAI,IAAI,KAAK,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC;QACxC,MAAM,KAAK,GAAG,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC;QAChC,IAAI,KAAK,KAAK,CAAC,CAAC;YAAE,SAAS;QAC3B,MAAM,GAAG,GAAG,IAAI,CAAC,KAAK,CAAC,CAAC,EAAE,KAAK,CAAC,CAAC,IAAI,EAAE,CAAC;QACxC,MAAM,KAAK,GAAG,IAAI,CAAC,KAAK,CAAC,KAAK,GAAG,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;QAC3C,IAAI,GAAG;YAAE,IAAI,CAAC,GAAG,CAAC,GAAG,KAAK,CAAC;IAC7B,CAAC;IAED,OAAO,EAAE,IAAI,EAAE,IAAI,EAAE,KAAK,CAAC,CAAC,CAAC,EAAE,CAAC;AAClC,CAAC"}

package/dist/agent/skills/enrich-entities.md

@@ -1,136 +0,0 @@
----
-name: enrich-entities
-description: Proactively suggest enrichment for incomplete entities using context
-loading: eager
----
-
-# Entity Enrichment
-
-When you discover incomplete entities (missing recommended fields), proactively suggest enrichment using contextual inference.
-
-## Batch Enrichment (automated)
-
-For bulk enrichment of entities with low completeness scores, use the `enrich_run` tool:
-
-1. `enrich_run({ dryRun: true })` — preview what would be enriched
-2. Present summary to user, get confirmation
-3. `enrich_run()` — run enrichment (writes in-place, no git commit)
-4. "Review changes with `studiograph review`, then commit with `studiograph commit`"
-5. `workspace_commit({ messagePrefix: "enrich" })` — or let user commit via CLI
-
-Use `enrich_abort` to discard all changes if the results aren't satisfactory.
-
-## When to Enrich
-
-**Proactive discovery:**
-- User asks to "clean up" or "enrich" entities
-- You call `lint_entities` and find incomplete records
-- You fetch an entity and notice missing recommended fields
-
-**During normal work:**
-- User asks about a specific entity and you notice gaps
-- You're creating related entities and spot incomplete references
-
-## How to Enrich
-
-### 1. Discover gaps
-Use `lint_entities` to find incomplete entities:
-```
-lint_entities({ entityType: "project" })
-→ 12 projects missing client, start_date, or end_date
-```
-
-### 2. Gather context for each incomplete entity
-- **Fetch the entity:** `get_entity({ entityId: "..." })`
-- **Find related entities:** `get_backlinks({ entityId: "..." })`
-- **Search for references:** Look in meeting notes, proposals, briefs
-- **Check memory:** Review past conversations about this entity
-
-### 3. Infer missing values from context
-
-**Missing client:**
-- Search entity markdown body for `[[client-name]]` wikilinks
-- Check backlinks from meetings, proposals, deals
-- Look for client mentions in related artifacts
-
-**Missing dates:**
-- Extract from related meetings (kickoff = start_date)
-- Check proposal expected_start or contract signed_date
-- Look for date mentions in project description
-
-**Missing relationships:**
-- Scan for wikilinks in markdown body
-- Check what entities reference this one (backlinks)
-- Infer from entity type (artifact → deliverable → project)
-
-### 4. Suggest, don't assume
-Always confirm before updating:
-
-> "I notice this project is missing a client. I see Meridian Health mentioned in 3 related meetings and the project brief. Should I add `client: [[meridian-rebrand]]`?"
-
-Wait for user confirmation, then call `update_entity`.
-
-## Example Workflows
-
-**Batch enrichment:**
-```
-User: "Help me fill in missing clients for incomplete projects"
-
-You:
-1. lint_entities({ entityType: "project" }) → 8 missing client
-2. For each project:
-   - get_entity() → read markdown body
-   - get_backlinks() → find meetings, proposals
-   - Search for client wikilinks
-   - Suggest: "Add client: [[acme]]?" → confirm → update
-3. Report: "Enriched 6/8 projects. 2 need manual review (no clear client in context)."
-```
-
-**Focused enrichment:**
-```
-User: "Fill in missing deal values"
-
-You:
-1. lint_entities({ entityType: "deal" }) → 5 deals missing deal_value
-2. For each deal:
-   - get_backlinks() → find related proposal
-   - get_entity() on proposal → extract fees
-   - Suggest: "This deal's proposal shows $50k. Add deal_value: 50000?" → confirm → update
-```
-
-**Inline during work:**
-```
-User: "Show me the Acme project"
-
-You:
-1. get_entity({ entityId: "acme-rebrand" })
-2. Notice missing: client, start_date
-3. Get context: search for Acme client entity, check proposal
-4. Suggest inline: "This project is missing a client and start date. I found the Acme client entity and a proposal dated 2026-01-15. Should I add those?"
-```
-
-## Guidelines
-
-**Do:**
-- Use multiple context sources (backlinks, search, memory, markdown body)
-- Present evidence: "I see X mentioned in 3 meetings"
-- Batch similar fields: "Should I add client and start_date?"
-- Report progress: "Enriched 8/12, 4 need review"
-
-**Don't:**
-- Update without confirmation
-- Guess when evidence is weak ("I'm not sure which client this is")
-- Over-enrich — only fill recommended fields that are clearly missing
-- Make up data — if no context exists, say so: "I couldn't find a clear client reference. Would you like to specify it?"
-
-## Priority Fields
-
-Focus enrichment on high-value semantic fields:
-1. **Relationships** — client, project, deliverable (wikilinks)
-2. **Dates** — start_date, due_date, expected_close
-3. **People** — assignee, decision_makers, attendees
-4. **Values** — deal_value, fees, budget
-
-Low-priority (often intentionally omitted):
-- Tags, notes, optional descriptions
-- Status (user may want to set this themselves)

package/dist/agent/skills/obsidian-source-setup.md

@@ -1,246 +0,0 @@
----
-name: obsidian-source-setup
-description: Scaffold an Obsidian vault into a sync source config — explore vault structure, map directories to entity types, build field maps from frontmatter
-loading: on-demand
----
-
-# Obsidian Source Setup
-
-Guide for mapping any Obsidian vault to a Studiograph sync source config. Every vault is different — follow these steps to explore the vault and build a config tailored to its structure.
-
-## Step 1: Explore the Vault
-
-Before writing any config, understand the vault's organization.
-
-1. **List top-level directories** — use the Obsidian MCP connector or read the filesystem directly:
-   - Note every top-level folder name
-   - Identify which are content folders vs system folders (`.obsidian/`, `.smart-env/`, `Attachments/`, `Templates/`)
-   - Check for subdirectory structure (e.g., `Organizations/Clients/`, `Organizations/Vendors/`)
-
-2. **Count files per directory** — understand the scale:
-   - Large directories (100+) are likely core entity types
-   - Small directories (<10) may not be worth a dedicated mapping
-
-3. **Check for nested content** — some vaults use flat files, others use subfolders:
-   - `People/John Smith.md` (flat) — each file is one entity
-   - `Projects/Acme/Acme.md` + `Projects/Acme/SOW.md` (nested) — folder per entity with sub-documents
-
-## Step 2: Sample Frontmatter
-
-Read the first 25-30 lines of 2-3 files per directory to see what YAML frontmatter exists.
-
-**Key things to look for:**
-- Which fields are present (even if empty)
-- Wikilink references: `client: "[[Acme Corp]]"` or `related_people: ["[[John Smith]]"]`
-- Tag conventions: `tags: [project/active]`, `tags: ["#person"]`, `tags: [sop, operations]`
-- Date formats: `date: 2026-01-15`, `start_date: 2026-01-15`
-- Status encoding: frontmatter `status:` field vs tag-based `tags: [project/active]`
-
-**Frontmatter vs no frontmatter:**
-- Files WITH frontmatter (YAML between `---` fences) → use `frontmatter` extraction mode
-- Files WITHOUT frontmatter (plain markdown) → use `unstructured` mode (LLM extraction, slower)
-- If a directory has a mix, prefer `frontmatter` — files without frontmatter will be skipped, which is often acceptable
-
-## Step 3: Map Directories to Entity Types
-
-For each content directory, decide which Studiograph entity type it maps to. Use the directory name, file content, and frontmatter fields as signals.
-
-### Entity Type Reference
-
-**Project repo types** (time-bound, engagement-specific):
-| Type | Use when | Key fields |
-|------|----------|------------|
-| `project` | Client engagements, initiatives | name, client, start_date, end_date, status, team |
-| `meeting` | Meetings, events, conferences | name, date, attendees, agenda, action_items |
-| `task` | Action items, tickets | name, assignee, due_date, status, priority |
-| `deliverable` | Outputs, milestones | name, project, status, due_date |
-| `brief` | Project briefs, RFPs | project_name, client, objectives |
-| `artifact` | Files, documents, assets | name, type, project, url |
-| `decision` | Architectural/business decisions | title, date, status, rationale |
-
-**Function repo types** (operational, cross-project):
-| Type | Use when | Key fields |
-|------|----------|------------|
-| `person` | People, contacts, team members | name, role, email, status, organization |
-| `client` | Companies, organizations (as clients) | name, type, status, industry, contacts |
-| `vendor` | Vendors, partners, freelancers | name, type, status, services |
-| `deal` | Sales pipeline entries | name, client, stage, deal_value |
-| `proposal` | Proposals, SOWs | name, client, status, deliverables |
-| `contract` | Contracts, agreements | name, type, client, status |
-| `financial-plan` | Budgets, rate cards, P&L | name, type, period |
-| `role` | Job descriptions, org structure | title, department, level, type |
-
-**Shared resource types** (reference, reusable):
-| Type | Use when | Key fields |
-|------|----------|------------|
-| `process` | SOPs, workflows, methodologies | name, description, steps, owner |
-| `standard` | Guidelines, conventions | name, category, guidelines |
-| `template` | Reusable templates | name, category, template_content |
-| `reference` | Articles, research, bookmarks | name, type, source, link |
-| `technique` | Methods, frameworks | name, category, difficulty |
-| `practice-area` | Service lines, capabilities | name, description, capabilities |
-| `case-study` | Portfolio work, showcases | title, client, year, practice_areas |
-
-### Common Obsidian Directory Mappings
-
-These are patterns seen across vaults — adapt to the actual vault:
-
-| Directory pattern | Likely entity type | Notes |
-|-------------------|--------------------|-------|
-| `Projects/` | `project` | May have sub-documents (see nested content below) |
-| `People/`, `Contacts/` | `person` | Usually flat files |
-| `Team/`, `Staff/` | `person` | Often richer frontmatter than external contacts |
-| `Clients/`, `Companies/`, `Organizations/` | `client` | May have subdirectories by relationship type |
-| `Meetings/`, `Meeting Notes/` | `meeting` | Date-prefixed filenames common |
-| `Tasks/`, `Action Items/` | `task` | May overlap with a task manager integration |
-| `SOPs/`, `Processes/`, `Workflows/` | `process` | Often has category/status/owner fields |
-| `Areas/`, `Practice Areas/`, `Capabilities/` | `practice-area` | May lack frontmatter |
-| `Case Studies/`, `Portfolio/`, `Work/` | `case-study` | Often has client, year, url fields |
-| `Research/`, `References/`, `Resources/` | `reference` | Bookmarks, articles, links |
-| `HR/`, `Roles/`, `Job Descriptions/` | `role` | Job postings, org structure |
-| `Finances/`, `Finance/`, `Budgets/` | `financial-plan` | Rate cards, P&L, budgets |
-| `Standards/`, `Guidelines/` | `standard` | Naming conventions, code standards |
-| `Templates/` | `template` | Reusable document templates |
-| `Proposals/`, `SOWs/` | `proposal` | Client proposals |
-| `Contracts/` | `contract` | Agreements, NDAs |
-| `Events/`, `Conferences/` | `meeting` | No dedicated event type — meeting is closest |
-| `Emails/` | `artifact` | No dedicated email type |
-| `Archive/` | same as active, disabled | Enable later if needed |
-
-### Directories to Skip
-
-- `.obsidian/` — Obsidian config
-- `.smart-env/` — Smart Connections plugin data
-- `Attachments/`, `Assets/`, `Media/` — binary files
-- `Templates/` — often just scaffolding, not real entities (evaluate per vault)
-- `Daily Notes/` — usually ephemeral, not entity-worthy
-- `Clippings/` — web clippings, low signal
-
-### Handling Nested Project Content
-
-When a `Projects/` directory has subfolders with multiple files per project, ALL files get classified as the mapping's entity type. Sub-documents (meeting agendas, SOWs, concepts) become project entities.
-
-**Options:**
-1. **Accept and review** — the `studiograph review` step lets users fix misclassifications before committing
-2. **Use `unstructured` mode** — the LLM can infer the correct entity type from content (slower, costs per file)
-3. **Co-locate sub-files** — if sub-documents reference their parent project in frontmatter (e.g., `related_projects: ["[[My Project]]"]`), add `co_locate: { parent_field: "related_projects", subfolder: "notes" }` to write them as sub-content
-
-## Step 4: Choose Extraction Mode Per Mapping
-
-| Condition | Mode | Cost |
-|-----------|------|------|
-| Files have YAML frontmatter with useful fields | `frontmatter` | Free (no LLM) |
-| Files are plain markdown, no frontmatter | `unstructured` | LLM call per file |
-| Mix of both | `frontmatter` | Free — files without frontmatter are skipped |
-| Small directory (<20 files) with no frontmatter | `unstructured` | Acceptable LLM cost |
-| Large directory (100+) with no frontmatter | `frontmatter` or skip | `unstructured` would be expensive |
-
-## Step 5: Build Field Maps
-
-For each `frontmatter` mapping, build a `field_map` from the sampled YAML fields.
-
-**Rules:**
-- Keys are the Obsidian frontmatter field names (as they appear in the YAML)
-- Values are the Studiograph entity field names (from the entity type reference above)
-- Only map fields that actually exist in the frontmatter — don't invent mappings
-- Wikilink fields (`"[[Entity Name]]"`) map naturally — the sync pipeline handles them
-- Always include `tags` if the vault uses tags
-- Use `id_from: "_filename"` and `content_from: "_body"` for all Obsidian mappings
-
-**Common Obsidian frontmatter fields and their typical targets:**
-
-| Obsidian field | Target field | Notes |
-|----------------|-------------|-------|
-| `title` / `name` | `name` or `title` | Entity display name |
-| `status` | `status` | Map values with `status_map` if conventions differ |
-| `client` | `client` | Often a wikilink |
-| `date` | `date` | ISO date |
-| `start_date` / `end_date` | `start_date` / `end_date` | Date range |
-| `tags` | `tags` | Array of strings |
-| `email` | `email` | |
-| `role` / `title` (on person) | `role` | Obsidian often uses `title` for role |
-| `related_people` | `contacts` or `attendees` | Usually wikilink array |
-| `related_organizations` | `related_organizations` | Usually wikilink array |
-| `related_projects` | `related_projects` | Usually wikilink array |
-| `related_areas` | `related_areas` | Usually wikilink array |
-| `url` / `website` | `website_url` or `link` | |
-| `sectors` | `sectors` | Industry/domain tags |
-| `practice_areas` | `practice_areas` | Service line references |
-| `year` | `year` | For case studies |
-
-## Step 6: Determine Target Repos
-
-Check which repos exist in the workspace (`ls` the workspace directory or use `graph_list_repos`). Map entity types to existing repos:
-
-| Entity types | Typical repo |
-|-------------|-------------|
-| project, case-study, deliverable, brief, artifact | `projects` |
-| person, role | `people` |
-| client, vendor | `clients` |
-| meeting | `meetings` |
-| process, standard, template, reference, technique, practice-area | A shared-resource repo if one exists, otherwise `projects` |
-| deal, proposal, contract, financial-plan | A function repo if one exists, otherwise `projects` |
-
-If a needed repo doesn't exist, the sync pipeline auto-creates it on `sync_apply`.
-
-## Step 7: Write the Config
-
-Generate `.studiograph/sources/obsidian.json` with all mappings. Present it to the user for review before writing.
-
-**Template:**
-```json
-{
-  "name": "obsidian-<vault-name>",
-  "connector": "obsidian-<vault-name>",
-  "enabled": true,
-  "added_at": "<ISO timestamp>",
-  "entity_mappings": [
-    {
-      "source_type": "<descriptive-name>",
-      "entity_type": "<studiograph-type>",
-      "target_repo": "<repo-name>",
-      "extraction_mode": "frontmatter",
-      "enabled": true,
-      "directory_patterns": ["<VaultDir>/"],
-      "list_tool": "list_vault_files",
-      "read_tool": "get_vault_file",
-      "field_map": { ... },
-      "id_from": "_filename",
-      "content_from": "_body"
-    }
-  ]
-}
-```
-
-**Checklist before writing:**
-- [ ] Every content directory has a mapping (or a reason to skip)
-- [ ] `directory_patterns` use trailing slash and match the vault's exact directory names (case-sensitive)
-- [ ] `list_tool` and `read_tool` are set to `"list_vault_files"` and `"get_vault_file"` for Obsidian
-- [ ] Field maps only reference frontmatter fields that actually exist
-- [ ] Directories with no frontmatter use `unstructured` mode or are skipped
-- [ ] Subdirectories are handled (e.g., `Organizations/Clients/` not just `Organizations/`)
-- [ ] `target_repo` values match existing repos or the user is aware new ones will be created
-- [ ] Disabled mappings are marked `enabled: false` with a comment-like `source_type` explaining why
-
-## Multiple Vaults
-
-Each vault needs its own connector and source config. The MCP Tools binary is vault-specific — it connects to the Local REST API instance running in its vault.
-
-1. Install both plugins (Local REST API + MCP Tools) in each vault
-2. Create a connector per vault at `~/.studiograph/connectors/obsidian-<name>.json`, each pointing to that vault's `mcp-server` binary and API key
-3. Create a source config per vault at `.studiograph/sources/obsidian-<name>.json` with directory patterns matching that vault's structure
-4. Run `studiograph sync` (no arguments) to sync all enabled sources in one pass
-
-**Port conflict:** Each vault's Local REST API runs on port 27124 by default. Only one vault can use a given port at a time. If both vaults need to be open simultaneously, change the port in one vault's Local REST API settings.
-
-See `docs/obsidian-setup.md` for full connector setup and troubleshooting.
-
-## After Setup
-
-1. **Dry run:** `sync_run({ sources: ["obsidian"], dryRun: true })` — verify extraction counts look right
-2. **Full run:** `sync_run({ sources: ["obsidian"] })` — extract to staging
-3. **Review:** `sync_status` then `studiograph review` — spot-check entity types and field values
-4. **Apply:** `sync_apply` — write entity files
-5. **Commit:** `studiograph commit` — git commit across repos
-
-See the `sync-setup` skill for the full sync workflow and the `sync-configuration` skill for field map syntax details.

package/dist/agent/skills/skill-loader.d.ts

@@ -1,48 +0,0 @@
-/**
- * Skill Loader — prompt skills for the Studiograph agent.
- *
- * Skills are markdown files with YAML frontmatter that inject domain-specific
- * knowledge into the agent's system prompt. Two formats supported:
- *
- *   Directory skill:
- *     skills/create-deck/
- *       skill.md        ← required entrypoint
- *       slide-types.md  ← optional sub-files
- *
- *   Single-file skill:
- *     skills/quick-tip.md
- *
- * Frontmatter fields:
- *   name:        kebab-case identifier (defaults to directory/filename)
- *   description: shown in skill index so agent knows when to load it
- *   loading:     "on-demand" (default) | "eager" (inlined in system prompt)
- */
-export interface SkillMeta {
-    name: string;
-    description: string;
-    loading: 'eager' | 'on-demand';
-    dir: string;
-    entrypoint: string;
-    isDirectory: boolean;
-}
-/**
- * Scan one or more skill directories and return a de-duplicated skill index.
- * Directories are processed in order — first occurrence of a name wins,
- * so workspace-level skills override app-bundled skills.
- */
-export declare function loadSkillIndex(skillsDirs: string[]): SkillMeta[];
-/**
- * Load the full content of a skill's entrypoint or a named sub-file.
- * Sanitises the file parameter to prevent path traversal.
- */
-export declare function loadSkillContent(meta: SkillMeta, file?: string): string;
-/**
- * Build the skill index section to append to the system prompt.
- * Eager skills are inlined separately; this lists only on-demand skills.
- */
-export declare function buildSkillIndexPrompt(skills: SkillMeta[]): string;
-/**
- * Return the full content of all eager skills, to be injected directly
- * into the system prompt at startup.
- */
-export declare function loadEagerSkills(skills: SkillMeta[]): string;