studiograph 1.3.47 → 1.3.48-beta.1

package/dist/agent/skills/interview/skill.md

@@ -0,0 +1,204 @@
+---
+name: interview
+description: Conversational interview that builds organizational context in the knowledge graph — always running, stoppable, resumable
+loading: eager
+---
+
+# Interview Agent
+
+You are an interviewer. Your primary job is to build the user's organizational knowledge graph through conversation. Every time you respond, you should be working toward filling in the graph.
+
+## Core Behavior
+
+**At the start of every conversation**, assess the graph state by calling `list_entities` across all folders. Then:
+
+- **If the workspace has no folders (or no entries):** This is a brand-new workspace. Introduce yourself as their knowledge graph assistant and begin the interview script. Start by asking for their website and organization name. Create the first folder as you go (see "Folder Structure" below).
+- **If the graph has baseline coverage but gaps remain:** Pick up where the gaps are. Ask the next most valuable question based on what's missing.
+- **If the user asks something unrelated:** Handle their request, then return to the interview with your next question.
+
+### Workspace identity vs. user identity — don't conflate them
+
+The workspace's `team_name` (set at `studiograph init`) is the **authoritative organization name** for this graph. It's what the user explicitly chose. The user's **display name and email** are session context for identifying *who is talking to you*, not what the workspace is about.
+
+These two are often different — many workspaces are personal projects, side ventures, or research scratchpads unrelated to where the user works. Anchor on `team_name` when discussing the organization. Treat the email domain as a hint worth confirming, not a fact to assert.
+
+**Don't:** "Sounds good. To pick things back up, could you tell me a bit about Schema's core mission and the primary focus of the work you do?" — when `team_name` is "Watowa" and the email is `christian@schemadesign.com`, you've inferred the wrong organization.
+
+**Do:** "Could you tell me a bit about Watowa's core mission?" or, if the email/workspace mismatch is striking and you want to disambiguate: "Is Watowa related to Schema Design (which I noticed from your email), or a separate project?"
+
+Never derive organization facts from the email domain alone — the model may know about the firm and pattern-match plausible sentences ("strategic design firm doing data visualization"), but plausible isn't the same as accurate.
+
+**Always end your response with the next interview question.** The interview is always running. You don't wait for the user to ask you to continue — you proactively drive the conversation forward.
+
+The only time you don't ask a follow-up question is if the user explicitly says "stop", "that's enough", or "no more questions."
+
+**If the user says "skip", "skip this", "skip this question", "next", or otherwise asks to move past the current question:** Acknowledge briefly ("Sure, we can come back to that.") and ask the next-most-valuable question on a *different* topic — don't re-phrase the same question. Treat the skipped topic as a known gap the agent can revisit later, not as something the user refused.
+
+## Language
+
+Always say "entries" when talking to the user, never "entities". "Entities" is an internal term — users see "entries".
+
+## Entry Types
+
+The full canonical list of entry types is in the system prompt's "Entry Types" section. You are not restricted to the defaults — use the most specific canonical type for each topic. Don't collapse a decision into a note or a deliverable into a document just because the default picker tier is smaller; the catalog has dedicated types.
+
+Quick mapping for interview topics:
+
+- **Processes, workflows, SOPs** → `process`
+- **Standards, guidelines, principles** → `guideline`
+- **Decisions (ADR-style records)** → `decision`
+- **Deals, pipeline, prospects** → `deal` (with the prospect as `organization`, category `prospect`)
+- **Capabilities, practice areas, expertise** → `practice-area`, or embed inside the organization entry body
+- **Deliverables, scoped outputs to a client** → `deliverable`, linked to its project
+- **Case studies, portfolio pieces** → `case-study`
+- **Published content (articles, talks, posts)** → `publication`
+- **Presentations, slide decks** → `deck`
+- **Reusable agent instructions the team wants you to follow** → `skill` (see "Listening for Skill-Worthy Patterns" below)
+- **Freeform thinking with no obvious fit** → `note`
+- **Authored docs that don't fit a more specific type** → `document`
+
+If `create_entity` rejects a type, the error lists the allowed types (full canonical set + workspace custom types). Pick the closest and carry on — don't loop.
+
+## The Script
+
+Follow the 10-topic script in the `question-domains` sub-file for the initial interview. The topics in order:
+
+1. Organization (name, what you do, size, positioning)
+2. Team (people, roles, locations)
+3. Clients (current client organizations, key contacts)
+4. Active Projects (workstreams, status, who's on them)
+5. Pipeline & Deals (prospects, active deals)
+6. Processes & Workflows (meeting cadence, how work flows)
+7. Tools & Systems (tech stack)
+8. Capabilities & Expertise (specialties, what you're known for)
+9. Goals & Strategy (current priorities, direction)
+10. Standards & Guidelines (communication style, preferences)
+
+**Before starting the script**, ask: "Do you have a website for your organization? Sharing it helps me ask better questions." If provided, fetch it with `web_fetch` and use the extracted context to adapt your questions.
+
+After all 10 topics have baseline coverage, call `mark_onboarded` to record that the user's onboarding is complete. Then **synthesize the workspace description**: read the current ABOUT.md (if any) and the graph entities you've created, and call `update_workspace_about` with a concise markdown narrative covering the organization's identity, team, capabilities, and values. If the user had already written an ABOUT.md, preserve their voice and any unique context while weaving in the structured facts from the graph. After that, switch to deepening — ask about sparse entries, missing relationships, stale data, and new content from any source.
+
+## Script Rules
+
+1. **One question at a time.** Never compound questions.
+2. **Create entries immediately** from each answer. Don't batch or wait until the end.
+3. **Use wikilinks** to connect entries from the start (person → organization, project → client).
+4. **Adapt phrasing** based on website context and prior answers. If a topic is already covered, acknowledge it and ask only for gaps.
+5. **Allow detours.** If the user mentions something interesting off-script, follow up briefly, then return to the script.
+6. **Always come back to the interview.** After handling any request, end with your next question.
+7. **Dig deeper on sparse answers.** If the user gives a short or vague answer, ask a follow-up to draw out more detail before moving on. "You mentioned X — can you tell me more about that?" One follow-up is enough; don't interrogate.
+
+## Folder Structure
+
+Do NOT put everything in a single folder. Set up this structure as the interview progresses:
+
+| Folder | Graph Type | What Goes Here |
+|---|---|---|
+| `{org-name}` | function | The org entry itself, team (person), practice areas, processes, guidelines, strategy notes |
+| `clients` | function | Client organizations, key client contacts |
+| `projects` | function | Active project entries (one per engagement) |
+| `case-studies` | shared-resource | Portfolio case studies from past work |
+| `new-business` | function | Prospect organizations, deals, pipeline entries |
+
+Create folders as needed — `{org-name}` first, then others as the relevant topics come up.
+
+## Entry Quality
+
+**Don't create sparse entries.** Every entry should have:
+- All relevant frontmatter fields populated (omit optional fields entirely if unknown — never set them to empty strings like `email: ''` or `start_date: ''`)
+- A meaningful markdown body — at least 2-3 sentences or a structured overview
+- Wikilinks to related entries
+
+**For people entries:** Don't just write "Role at Org, based in Location." Include what they do, what they're responsible for, who they work closely with.
+
+**For prospect/target entries:** Include why they're a target, what the angle would be, any existing connections.
+
+## Listening for Skill-Worthy Patterns
+
+Throughout the interview — especially during Topic 10 (Standards & Guidelines) but at any point — listen for the user describing a **repeatable working pattern** they'd want you to follow in future conversations. These are different from facts about the organization; they're instructions on *how this team wants the agent to operate*.
+
+Examples of skill-worthy signals:
+
+- "Our proposals always open with context, then scope, then pricing."
+- "When we summarize a meeting we always put action items in a bulleted list at the top."
+- "We never use bullet points in client emails — always paragraphs."
+- "For every new project we create a kickoff doc with these sections…"
+- "Decisions are logged with a What / Why / Alternatives structure."
+
+When you hear one, **opportunistically offer to capture it as a skill**:
+
+> "That sounds like a pattern I could reuse — want me to save it as a skill so I follow it next time you ask me to write a proposal?"
+
+On confirmation, call `create_entity` with `type: 'skill'`:
+- `entity_id` — kebab-case name the agent will call via `load_skill` (e.g., `proposal-writing`, `meeting-summary-format`, `client-email-style`)
+- `data.description` — short sentence the skill index will show
+- `content` — markdown body with the actual instruction, written in second person ("When the user asks you to write a proposal, always…")
+
+Put team-wide skills in a shared folder; personal skills in `repo: "private"`. Don't set `loading: eager` unless the user explicitly wants the instruction inlined into every agent turn (admin-only in shared folders).
+
+Don't *ask* about skills as a topic. Listen for them and offer. Many users won't have strong conventions and that's fine — skip.
+
+## Assessing Graph State
+
+Use `list_entities` across all folders to inventory what exists. Map entries to script topics. The full canonical type catalog is available — use the dedicated type for each check rather than falling back to tagged notes.
+
+- Has an `organization` entry? → Topic 1 covered
+- Has `person` entries with org links? → Topic 2 covered
+- Has client `organization` entries? → Topic 3 covered
+- Has `project` entries? → Topic 4 covered
+- Has `deal` entries or prospect `organization` entries? → Topic 5 covered
+- Has `process` entries? → Topic 6 covered
+- Has tool/system `reference` or `note` entries → Topic 7 covered
+- Has `practice-area` entries (or capability coverage in the org entry body) → Topic 8 covered
+- Has strategy/goals `note` entries → Topic 9 covered
+- Has `guideline` entries or `skill` entries → Topic 10 covered
+
+The first uncovered topic is your next question. If all are covered, look for the sparsest entries and deepen those.
+
+Load `question-domains` for the full question bank and `entity-templates` for extraction patterns.
+
+## Team Member Onboarding
+
+When a team member (not the workspace owner) starts a conversation and the graph is already populated:
+
+1. **Identify the user from the current session** — the user's `handle`, display name, and email are available from the system context. **Their linked person entity is already auto-provisioned at registration time** (the user↔person bridge). Read `linkedPersonRef` via `permission_list_users` or accept it from the session context — do NOT call `search_entities` to find them, and do NOT call `link_person_to_user` for the user themselves; the link is already in place.
+2. **If the bridge somehow has no record** (legacy account, ambiguous migration, team_repo unconfigured), `search_entities` falls back as today. Surface the gap to the user and offer to run `link_person_to_user` if they identify the right record.
+3. **Welcome them** by name and show their current profile: "Welcome, [name]. I can see you're listed as [role] at [org]. Let me ask a few questions to fill out your profile and enrich the graph with your perspective."
+
+### User ↔ Person bridge rules
+
+- The user's own record: **already linked.** Read `personRef` from session context; write enrichments via `update_entity`. Never call `link_person_to_user` for the current user.
+- Team members the user *mentions* during the interview ("Sarah is our designer"): create person entities with `email` if known, but **do not set `user_handle`**. They have no account yet — `ensurePersonForUser` will auto-link them by email when they register.
+- Existing-entity bridging only when the user *explicitly* asks ("[[chris]] is me", "this person record is actually [[fritz]]"). Use `permission_list_users` first to confirm the target handle, then call `link_person_to_user`.
+- Unlink (`unlink_person_from_user`) is reserved for fixing a wrong link the user flags. It leaves the entity intact — only the bridge is severed.
+
+### Onboarding Questions (5 questions max)
+
+The onboarding is not just about the person's profile — it's an opportunity to enrich the broader graph from their unique perspective. Each answer should update their profile AND create or enrich related entries.
+
+1. **Background** — "Tell me about your background — what did you do before, what are you most deep in?"
+   → Update their person entry with a rich bio.
+
+2. **Current work** — "What are you working on right now? Walk me through your projects, your role, and the tools or technologies you're using."
+   → Link them to projects. Update project entries with technical detail. Create tool/technology entries for anything mentioned that isn't in the graph yet.
+
+3. **Client contacts** — "Who do you work with on the client side?"
+   → Create person entries for contacts not yet in the graph. Link to client organizations.
+
+4. **Working style** — "How do you prefer to work? Any preferences or processes the team should know about?"
+   → Update their profile. Create `note` or `document` entries (tagged `Process`) for workflows not yet captured. If the user describes a concrete pattern the agent should follow when doing specific jobs, offer to save it as a `skill` entry instead (see "Listening for Skill-Worthy Patterns").
+
+5. **What's missing** — "Is there anything about how the team works or your projects that you think should be documented?"
+   → Create entries (decisions, references, notes) based on their answer.
+
+After all 5 questions are answered, call `mark_onboarded` to record that the member's onboarding is complete. Then synthesize the workspace description: read the current ABOUT.md and graph entities, and call `update_workspace_about` with an updated narrative that incorporates any new context from this member's answers. Preserve existing voice and content while weaving in new facts.
+
+### Key Principle
+
+**Every answer should ripple outward.** Don't just update the person entry — use each answer as a chance to enrich projects, create tools, add contacts, capture processes, and fill gaps across the graph. The member's perspective is a new source of context that the owner interview may have missed or oversimplified.
+
+### Do NOT:
+- Re-ask org-level questions (firm description, strategy, positioning)
+- Create new folders or restructure the graph
+- Override the owner's entries without good reason — add to them, don't replace
+- Run the full 10-topic script — this is targeted, not comprehensive

package/dist/agent/skills/schema-rules.md

@@ -0,0 +1,54 @@
+---
+name: schema-rules
+description: Critical rules for creating and updating entities — enum discovery, field types, common pitfalls
+loading: eager
+---
+
+# Entity Schema Rules
+
+These rules apply whenever you create or update entries. For the full field reference, load the `entity-schema` skill.
+
+## Golden Rules
+
+**Only pass fields you have real values for.** Do not include optional fields like `deal_value`, `email`, `website`, `start_date`, etc. unless you have an actual value. Never pass empty strings for optional fields — omit them entirely from the `data` object.
+
+**Never wrap the `content` parameter in quotes.** The `content` field is raw markdown, not a JSON string. Do not add leading or trailing `"` characters. Pass the markdown directly.
+
+## Enum Fields — Always Check the Schema
+
+Many entity fields are enums (a closed set of allowed values). Field names that signal an enum include `stage`, `status`, `category`, `priority`, `audience`, `source`, `type`. **Do not guess enum values from memory.** Allowed values change as the product evolves, and a guessed value that "sounds right" (e.g. `negotiating` vs the actual `negotiation`) will fail validation.
+
+**Before writing any enum-shaped field on create or update:**
+
+1. Call `get_entity_schema(entityType)` to fetch the authoritative schema for the entity type.
+2. Inspect the returned `fields` object. For each enum field, the descriptor includes:
+   - `type: "enum"` (or `"enum[]"` for arrays of enums)
+   - `enum: [...]` — the full list of allowed values
+   - `default: ...` — the value applied when the field is omitted (when present)
+3. Use only values from the `enum` array. If you want the default, omit the field entirely.
+
+You may cache the schema response within a single conversation turn, but re-fetch when starting work on a different entity type or after a schema change is mentioned.
+
+## Field Types (from `get_entity_schema`)
+
+- `string` — free text
+- `string` with format `url` — must be a valid URL with protocol (e.g., `https://example.com`)
+- `string` with format `email` — must be a valid email
+- `datetime` — ISO 8601 datetime (auto-stamped on `created_at` / `updated_at` — do not pass these)
+- `number` — actual number, not a quoted string
+- `boolean` — `true` / `false`
+- `enum` — one of the values listed under the field's `enum` array
+- `string[]` — array of strings; for wikilink arrays (`attendees`, `services`, etc.) each entry is a wikilink id like `[[acme-corp]]`
+- `enum[]` — array of enum values; each entry must be one of `itemEnum`
+
+Dates use exactly two fields. `date` (type `date`) is every entity's salient date — its meaning is type-specific and shown in the field's `label` (a task's "Due date", a deal's "Close date", a project's "End date"). `start_date` (type `date`, only on project/event/task/deliverable/deal) is the optional earlier bound of a range `[start_date, date]`. Both must be `YYYY-MM-DD` (date-only — not a datetime) or omitted; anything else is rejected.
+
+## Error Recovery
+
+When an entry creation or update fails with a validation error, read the message carefully:
+
+- If it names an enum field (e.g. `stage: Invalid enum value`), call `get_entity_schema` for that entity type, pick a valid value from the `enum` list, and retry.
+- If it complains about a URL or email format, drop the field rather than substituting a placeholder.
+- If it complains about a missing required field, ask the user or omit the entry and explain.
+
+Do not skip the entry silently — either retry with corrected data or tell the user what went wrong.

package/dist/agent/tools/capture-tools.d.ts

@@ -0,0 +1,31 @@
+/**
+ * Capture-flow Tools for Studiograph Agent
+ *
+ * Single tool used by the quick-capture surface (POST /api/capture[/stream]).
+ * When the agent decides nothing in the user's input is worth saving as an
+ * entity, it calls `nothing_to_capture(reason)` and stops. The server
+ * captures the structured reason and surfaces it in the toast — no freeform
+ * assistant prose, no followup-suggestion marker leaking through.
+ *
+ * The tool is registered globally on every agent (so the Anthropic tool
+ * schema is consistent across sessions), but it's only meaningful when the
+ * capture flow has wired up `onNothingToCapture` in the AgentContext. In
+ * other contexts the callback is absent and the tool is effectively a
+ * no-op confirming back to the agent.
+ */
+import { Type as T } from 'typebox';
+export declare function createCaptureTools(onNothingToCapture: () => ((reason: string) => void) | null | undefined): {
+    name: string;
+    label: string;
+    description: string;
+    parameters: T.TObject<{
+        reason: T.TString;
+    }>;
+    execute: (_toolCallId: string, params: any) => Promise<{
+        content: {
+            type: "text";
+            text: string;
+        }[];
+        details: any;
+    }>;
+}[];

package/dist/agent/tools/capture-tools.js

@@ -0,0 +1,40 @@
+/**
+ * Capture-flow Tools for Studiograph Agent
+ *
+ * Single tool used by the quick-capture surface (POST /api/capture[/stream]).
+ * When the agent decides nothing in the user's input is worth saving as an
+ * entity, it calls `nothing_to_capture(reason)` and stops. The server
+ * captures the structured reason and surfaces it in the toast — no freeform
+ * assistant prose, no followup-suggestion marker leaking through.
+ *
+ * The tool is registered globally on every agent (so the Anthropic tool
+ * schema is consistent across sessions), but it's only meaningful when the
+ * capture flow has wired up `onNothingToCapture` in the AgentContext. In
+ * other contexts the callback is absent and the tool is effectively a
+ * no-op confirming back to the agent.
+ */
+import { Type as T } from 'typebox';
+import { wrapToolResult } from './graph-tools.js';
+export function createCaptureTools(onNothingToCapture) {
+    return [
+        {
+            name: 'nothing_to_capture',
+            label: 'Nothing to Capture',
+            description: 'Use ONLY in the quick-capture flow when the user\'s input contains no substantive content worth saving as an entity (e.g. an error page, an empty URL fetch, a redirect-only page, or pure noise). Call this with a brief one-line reason and STOP — do not produce any assistant text after, do not emit followups. Do not use this when the input is a normal note or article you should save: in that case call create_entity instead.',
+            parameters: T.Object({
+                reason: T.String({ description: 'One short sentence explaining why nothing is worth capturing. Shown to the user verbatim.' }),
+            }),
+            execute: async (_toolCallId, params) => {
+                const reason = String(params?.reason ?? '').trim();
+                if (!reason) {
+                    return wrapToolResult({ success: false, error: 'reason is required' });
+                }
+                const cb = onNothingToCapture();
+                if (cb)
+                    cb(reason);
+                return wrapToolResult({ success: true, recorded: true });
+            },
+        },
+    ];
+}
+//# sourceMappingURL=capture-tools.js.map

package/dist/agent/tools/capture-tools.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"capture-tools.js","sourceRoot":"","sources":["../../../src/agent/tools/capture-tools.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AAEH,OAAO,EAAE,IAAI,IAAI,CAAC,EAAE,MAAM,SAAS,CAAC;AACpC,OAAO,EAAE,cAAc,EAAE,MAAM,kBAAkB,CAAC;AAElD,MAAM,UAAU,kBAAkB,CAChC,kBAAuE;IAEvE,OAAO;QACL;YACE,IAAI,EAAE,oBAAoB;YAC1B,KAAK,EAAE,oBAAoB;YAC3B,WAAW,EAAE,2aAA2a;YACxb,UAAU,EAAE,CAAC,CAAC,MAAM,CAAC;gBACnB,MAAM,EAAE,CAAC,CAAC,MAAM,CAAC,EAAE,WAAW,EAAE,2FAA2F,EAAE,CAAC;aAC/H,CAAC;YACF,OAAO,EAAE,KAAK,EAAE,WAAmB,EAAE,MAAW,EAAE,EAAE;gBAClD,MAAM,MAAM,GAAG,MAAM,CAAC,MAAM,EAAE,MAAM,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;gBACnD,IAAI,CAAC,MAAM,EAAE,CAAC;oBACZ,OAAO,cAAc,CAAC,EAAE,OAAO,EAAE,KAAK,EAAE,KAAK,EAAE,oBAAoB,EAAE,CAAC,CAAC;gBACzE,CAAC;gBACD,MAAM,EAAE,GAAG,kBAAkB,EAAE,CAAC;gBAChC,IAAI,EAAE;oBAAE,EAAE,CAAC,MAAM,CAAC,CAAC;gBACnB,OAAO,cAAc,CAAC,EAAE,OAAO,EAAE,IAAI,EAAE,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;YAC3D,CAAC;SACF;KACF,CAAC;AACJ,CAAC"}

package/dist/agent/tools/folder-tools.d.ts

@@ -0,0 +1,47 @@
+/**
+ * Folder Management Tools for the Studiograph Agent
+ *
+ * Five tools that let the agent operate on the folder layout within a repo:
+ *   - list_folders     — read the folder tree of a repo
+ *   - create_subfolder — create a new subfolder inside an existing repo
+ *                        (distinct from graph-tools' `create_folder`, which
+ *                        creates a brand-new top-level repo)
+ *   - rename_folder    — rename / move within the same repo
+ *   - move_entity      — relocate an entry to a different folder within the
+ *                        same repo (distinct from graph-tools'
+ *                        `transfer_entity`, which moves across repos)
+ *   - delete_folder    — remove a folder (recursive opt-in, blast-radius reported)
+ *
+ * The system prompt restraint rule applies to all of these:
+ * never reorganize/rename/delete without explicit user request.
+ */
+import { Type as T } from 'typebox';
+import { WorkspaceManager } from '../../core/workspace-manager.js';
+import { type AuthUser, type AuthService } from '../../services/auth-service.js';
+import type { MutationEvent } from './graph-tools.js';
+export declare function createFolderTools(workspaceManager: WorkspaceManager, gitUser: {
+    id: string;
+    name: string;
+    email: string;
+}, onMutation?: (m: MutationEvent) => void, getCurrentUser?: () => AuthUser | null, authService?: AuthService | null, 
+/**
+ * Same activity hook as createGraphTools. Currently accepted but not wrapped
+ * around individual folder ops — folder mutations are rare relative to entity
+ * mutations, and the chip wouldn't have time to render before completing.
+ * Param exists so the orchestrator can pass a single callback symmetrically.
+ */
+_onAgentActivity?: (action: 'enter' | 'leave' | 'heartbeat', repo: string) => void): {
+    name: string;
+    label: string;
+    description: string;
+    parameters: T.TObject<{
+        repo: T.TString;
+    }>;
+    execute: (_toolCallId: string, params: any) => Promise<{
+        content: {
+            type: "text";
+            text: string;
+        }[];
+        details: any;
+    }>;
+}[];

package/dist/agent/tools/folder-tools.js

@@ -0,0 +1,249 @@
+/**
+ * Folder Management Tools for the Studiograph Agent
+ *
+ * Five tools that let the agent operate on the folder layout within a repo:
+ *   - list_folders     — read the folder tree of a repo
+ *   - create_subfolder — create a new subfolder inside an existing repo
+ *                        (distinct from graph-tools' `create_folder`, which
+ *                        creates a brand-new top-level repo)
+ *   - rename_folder    — rename / move within the same repo
+ *   - move_entity      — relocate an entry to a different folder within the
+ *                        same repo (distinct from graph-tools'
+ *                        `transfer_entity`, which moves across repos)
+ *   - delete_folder    — remove a folder (recursive opt-in, blast-radius reported)
+ *
+ * The system prompt restraint rule applies to all of these:
+ * never reorganize/rename/delete without explicit user request.
+ */
+import { Type as T } from 'typebox';
+import * as access from '../../services/access-control.js';
+import { wrapToolResult } from './graph-tools.js';
+function canAccessRepo(repoName, workspaceManager, getCurrentUser, authService) {
+    const user = getCurrentUser();
+    if (!user)
+        return true;
+    if (!authService)
+        return true;
+    return access.hasRepoAccess(user, repoName, workspaceManager, authService);
+}
+export function createFolderTools(workspaceManager, gitUser, onMutation, getCurrentUser, authService, 
+/**
+ * Same activity hook as createGraphTools. Currently accepted but not wrapped
+ * around individual folder ops — folder mutations are rare relative to entity
+ * mutations, and the chip wouldn't have time to render before completing.
+ * Param exists so the orchestrator can pass a single callback symmetrically.
+ */
+// eslint-disable-next-line @typescript-eslint/no-unused-vars
+_onAgentActivity) {
+    const getUser = getCurrentUser ?? (() => null);
+    const authSvc = authService ?? null;
+    function effectiveGitUser() {
+        const user = getUser();
+        if (user?.handle) {
+            return {
+                id: user.handle,
+                name: user.displayName ?? user.handle,
+                email: `${user.handle}@studiograph.local`,
+            };
+        }
+        return gitUser;
+    }
+    function resolveRepoOrFail(repoName) {
+        if (!canAccessRepo(repoName, workspaceManager, getUser, authSvc)) {
+            return { error: `Folder "${repoName}" not found` };
+        }
+        try {
+            return { graph: workspaceManager.getGraph(repoName) };
+        }
+        catch (err) {
+            return { error: err?.message ?? `Could not open folder "${repoName}"` };
+        }
+    }
+    return [
+        // ── list_folders ────────────────────────────────────────────────
+        {
+            name: 'list_folders',
+            label: 'List Folders',
+            description: 'List every nested folder inside a repo, returning repo-relative POSIX paths and any explicit display_name override. Empty array means the repo has no subfolders. Use this BEFORE creating a new folder to avoid duplicating an existing one.',
+            parameters: T.Object({
+                repo: T.String({ description: 'Folder name to inspect' }),
+            }),
+            execute: async (_toolCallId, params) => {
+                try {
+                    const resolved = resolveRepoOrFail(params.repo);
+                    if ('error' in resolved)
+                        return wrapToolResult({ success: false, error: resolved.error });
+                    const folders = resolved.graph.listFolders().map((f) => {
+                        const entry = { path: f.path };
+                        if (f.display_name)
+                            entry.display_name = f.display_name;
+                        return entry;
+                    });
+                    return wrapToolResult({
+                        success: true,
+                        repo: params.repo,
+                        folders,
+                        message: folders.length === 0
+                            ? `Folder "${params.repo}" has no subfolders.`
+                            : `Found ${folders.length} subfolder${folders.length === 1 ? '' : 's'} in "${params.repo}".`,
+                    });
+                }
+                catch (err) {
+                    return wrapToolResult({ success: false, error: err instanceof Error ? err.message : 'Unknown error' });
+                }
+            },
+        },
+        // ── create_subfolder ─────────────────────────────────────────────
+        // Distinct from graph-tools' `create_folder`, which creates a new
+        // top-level shared repo. This one nests inside an existing repo.
+        {
+            name: 'create_subfolder',
+            label: 'Create Subfolder',
+            description: 'Create a new subfolder inside an existing repo. Path is repo-relative POSIX (e.g. "clients/acme"). Parent segments are auto-created. Pass display_name to override the title-cased fallback (use when the user wants casing the folder name can\'t express, e.g. "HR" or "Schema_OS"). For creating a brand-new top-level shared folder, use create_folder instead. Confirm with the user before calling — folders shape how the user organises their work.',
+            parameters: T.Object({
+                repo: T.String({ description: 'Folder name to create the subfolder inside' }),
+                path: T.String({ description: 'Repo-relative POSIX path of the new subfolder (e.g. "clients/acme")' }),
+                display_name: T.Optional(T.String({ description: 'Optional human-readable label. Omit when the title-cased folder name is the right display.' })),
+            }),
+            execute: async (_toolCallId, params) => {
+                try {
+                    const resolved = resolveRepoOrFail(params.repo);
+                    if ('error' in resolved)
+                        return wrapToolResult({ success: false, error: resolved.error });
+                    const actor = effectiveGitUser();
+                    await resolved.graph.createFolder(params.path, undefined, actor, {
+                        displayName: params.display_name,
+                    });
+                    // entityType "_folder" is the existing sentinel (see graph-tools'
+                    // create_folder) that tells the client this is a folder-tree
+                    // mutation, not an entry mutation — the realtime handler maps it
+                    // to refreshRepoAfterFolderMutation so the sidebar + folder list
+                    // view pick up the new subfolder without a manual reload.
+                    onMutation?.({ action: 'created', repo: params.repo, entityType: '_folder', entityId: params.path });
+                    return wrapToolResult({
+                        success: true,
+                        repo: params.repo,
+                        path: params.path,
+                        message: `Created folder ${params.repo}/${params.path}. Auto-committed.`,
+                    });
+                }
+                catch (err) {
+                    return wrapToolResult({ success: false, error: err instanceof Error ? err.message : 'Unknown error' });
+                }
+            },
+        },
+        // ── rename_folder ────────────────────────────────────────────────
+        {
+            name: 'rename_folder',
+            label: 'Rename Folder',
+            description: 'Rename or move a subfolder within the same repo, optionally updating its display_name in the same commit. To update only the display_name without moving, set `to` equal to `from`. ALL descendant entries follow when the path changes — their on-disk paths change. NEVER call this without explicit user instruction. Surface what will move ("Rename clients/acme → clients/acme-corp and update path of N entries?") and wait for confirmation.',
+            parameters: T.Object({
+                repo: T.String({ description: 'Folder name containing the subfolder' }),
+                from: T.String({ description: 'Current repo-relative path of the subfolder' }),
+                to: T.String({ description: 'New repo-relative path of the subfolder. Pass the same value as `from` to update display_name only.' }),
+                display_name: T.Optional(T.String({ description: 'New human-readable label. Pass empty string to clear the override and revert to the title-cased folder name.' })),
+            }),
+            execute: async (_toolCallId, params) => {
+                try {
+                    const resolved = resolveRepoOrFail(params.repo);
+                    if ('error' in resolved)
+                        return wrapToolResult({ success: false, error: resolved.error });
+                    const actor = effectiveGitUser();
+                    await resolved.graph.renameFolder(params.from, params.to, undefined, actor, {
+                        displayName: params.display_name === undefined ? undefined : params.display_name,
+                    });
+                    onMutation?.({ action: 'updated', repo: params.repo, entityType: '_folder', entityId: params.to });
+                    return wrapToolResult({
+                        success: true,
+                        repo: params.repo,
+                        from: params.from,
+                        to: params.to,
+                        message: `Renamed ${params.repo}/${params.from} → ${params.repo}/${params.to}. Auto-committed.`,
+                    });
+                }
+                catch (err) {
+                    return wrapToolResult({ success: false, error: err instanceof Error ? err.message : 'Unknown error' });
+                }
+            },
+        },
+        // ── move_entity ──────────────────────────────────────────────────
+        {
+            name: 'move_entity',
+            label: 'Move Entry',
+            description: 'Move an entry to a different folder within the SAME repo. Only the entry\'s folder_path changes — its id and type are preserved. For cross-repo moves the user should use the bulk-move dialog (no agent tool yet).',
+            parameters: T.Object({
+                repo: T.String({ description: 'Folder name containing the entry' }),
+                entityType: T.String({ description: 'Entity type of the entry being moved' }),
+                entityId: T.String({ description: 'ID of the entry being moved' }),
+                folder_path: T.String({ description: 'Target repo-relative folder path. Empty string = repo root.' }),
+            }),
+            execute: async (_toolCallId, params) => {
+                try {
+                    const resolved = resolveRepoOrFail(params.repo);
+                    if ('error' in resolved)
+                        return wrapToolResult({ success: false, error: resolved.error });
+                    const actor = effectiveGitUser();
+                    const moved = await resolved.graph.move(params.entityType, params.entityId, params.folder_path, undefined, actor);
+                    onMutation?.({ action: 'updated', repo: params.repo, entityType: params.entityType, entityId: params.entityId });
+                    return wrapToolResult({
+                        success: true,
+                        repo: params.repo,
+                        entityType: params.entityType,
+                        entityId: params.entityId,
+                        folder_path: params.folder_path,
+                        path: moved.path,
+                        message: `Moved ${params.entityType}/${params.entityId} to ${params.repo}/${params.folder_path || '(root)'}. Auto-committed.`,
+                    });
+                }
+                catch (err) {
+                    return wrapToolResult({ success: false, error: err instanceof Error ? err.message : 'Unknown error' });
+                }
+            },
+        },
+        // ── delete_folder ────────────────────────────────────────────────
+        {
+            name: 'delete_folder',
+            label: 'Delete Folder',
+            description: 'Delete a subfolder. Defaults to non-recursive — if the folder has entries or subfolders the call FAILS with a blast_radius payload (entriesDeleted, subfoldersDeleted) so you can present the impact to the user. Re-invoke with recursive: true ONLY after explicit user confirmation. NEVER pass recursive: true on the first attempt.',
+            parameters: T.Object({
+                repo: T.String({ description: 'Folder name containing the subfolder to delete' }),
+                path: T.String({ description: 'Repo-relative path of the subfolder to delete' }),
+                recursive: T.Optional(T.Boolean({ description: 'Set to true ONLY after the user has confirmed the blast radius. Defaults to false.' })),
+            }),
+            execute: async (_toolCallId, params) => {
+                try {
+                    const resolved = resolveRepoOrFail(params.repo);
+                    if ('error' in resolved)
+                        return wrapToolResult({ success: false, error: resolved.error });
+                    const actor = effectiveGitUser();
+                    const result = await resolved.graph.deleteFolder(params.path, {
+                        recursive: params.recursive === true,
+                        user: actor,
+                    });
+                    onMutation?.({ action: 'deleted', repo: params.repo, entityType: '_folder', entityId: params.path });
+                    return wrapToolResult({
+                        success: true,
+                        repo: params.repo,
+                        path: params.path,
+                        entriesDeleted: result.entriesDeleted,
+                        subfoldersDeleted: result.subfoldersDeleted,
+                        message: `Deleted folder ${params.repo}/${params.path}${result.entriesDeleted > 0 || result.subfoldersDeleted > 0 ? ` (${result.entriesDeleted} entries, ${result.subfoldersDeleted} subfolders)` : ''}. Auto-committed.`,
+                    });
+                }
+                catch (err) {
+                    // Surface the blast radius so the agent can ask the user before retrying recursively.
+                    if (err?.code === 'FOLDER_NOT_EMPTY' && err.blastRadius) {
+                        return wrapToolResult({
+                            success: false,
+                            code: 'FOLDER_NOT_EMPTY',
+                            blast_radius: err.blastRadius,
+                            message: `Folder ${params.repo}/${params.path} is not empty: ${err.blastRadius.entriesDeleted} entries, ${err.blastRadius.subfoldersDeleted} subfolders. Confirm with the user before re-invoking with recursive: true.`,
+                        });
+                    }
+                    return wrapToolResult({ success: false, error: err instanceof Error ? err.message : 'Unknown error' });
+                }
+            },
+        },
+    ];
+}
+//# sourceMappingURL=folder-tools.js.map