thinkwork-cli 0.13.1 → 1.0.0

package/dist/workspace-defaults/files/catalog-skills/brain-brief-builder/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: brain-brief-builder
+description: Draft a new v2 Brain brief from a conversation. Use when someone asks to create, build, or set up a new Brain brief, report template, or recurring data brief from scratch. Interviews the operator, drafts the template through the Brain's capture endpoints, and hands back a builder link for review.
+license: Apache-2.0
+compatibility: The tenant's provisioned Company Brain connector with the Brief Builder v2 tools on its surface.
+metadata:
+  skill-format: agentskills
+---
+
+# Brain Brief Builder
+
+Turn a conversation into a draft v2 Brain brief: a short interview, one
+template-create call, a rule-capture pass per data section, and a link into
+the Brain console builder where the operator reviews, tweaks, and saves.
+Zero-to-one creation lives here — there is no console entry point for
+drafting a brief with the agent, and this skill never suggests one.
+
+## First Move
+
+1. Use this skill when someone asks to create a new Brain brief from
+   scratch. Running an existing brief is `brain_brief_launch`, not this
+   skill; a one-off saved answer is `brain_report_create`.
+2. Use the Brief Builder tools on the Company Brain connector:
+   `brain_brief_template_create`, `brain_brief_rule_propose`,
+   `brain_brief_rule_propose_result`, `brain_brief_rule_preview`,
+   `brain_brief_rule_accept`. Trust the live tool descriptions and
+   argument schemas over this skill if they disagree, and report the
+   drift in your handoff.
+3. If those tools are missing, report that the tenant's Company Brain
+   connector does not yet expose the Brief Builder surface and stop —
+   do not improvise a brief through other tools.
+
+## Interview
+
+Keep it short — a handful of questions, batched where natural. You need:
+
+1. **Coverage and audience.** What should the brief cover, and who reads
+   it? This becomes the template name and the document instructions.
+2. **Sections.** Which sections, in order? For each: a fixed title, a
+   section type from the closed vocabulary — `stat`, `table`, `chart`,
+   `narrative` — and for a `chart` section exactly one chart type from
+   the house vocabulary: `line`, `band`, `rule`, `annotation`, `dot`,
+   `spark`, `bar`, `funnel`. Only a chart carries a chart type.
+3. **Data and narrative instructions.** For each non-narrative section,
+   what should the data show (plain-language data instructions — the
+   capture lane compiles them; you never write SQL) and what should the
+   narrative say about it. A section may name an earlier SQL-backed
+   section's result as its `input`; chains must stay acyclic.
+4. **One optional parameter.** A brief has at most one input parameter,
+   entity-typed: an entity type plus a display template (for example
+   `first_name + ' ' + last_name`). Members are picked later in the
+   builder's parameter sheet — never collect emails, and refer to people
+   by display name only.
+
+Do not ask about cadence or recipients: schedules and delivery are
+configured on the brief in the console, not stored in the template.
+
+## Draft The Template
+
+Make one `brain_brief_template_create` call with the interview's answers
+as an `engine: "v2"` body — sections carry their instructions, but no
+rules yet (rules only ever come from the capture lane below). Shape:
+
+```json
+{
+  "name": "Sales Rep Daily",
+  "body": {
+    "engine": "v2",
+    "instructions": "A daily performance brief for one sales rep. Confident, factual, no filler.",
+    "parameter": {
+      "entity_type": "Person",
+      "display_template": "first_name + ' ' + last_name"
+    },
+    "sections": [
+      {
+        "key": "open-pipeline",
+        "title": "Open Pipeline",
+        "type": "stat",
+        "data_rule": "Total open opportunity value and count for the selected rep.",
+        "narrative": "One sentence on how the headline number moved."
+      },
+      {
+        "key": "recent-orders",
+        "title": "Recent Orders",
+        "type": "table",
+        "data_rule": "The rep's orders from the last 7 days with customer, date, and value.",
+        "narrative": "Call out anything unusual; if nothing is unusual, say so."
+      },
+      {
+        "key": "stage-funnel",
+        "title": "Stage Funnel",
+        "type": "chart",
+        "chart_type": "funnel",
+        "input": "recent-orders",
+        "data_rule": "Opportunity counts by pipeline stage for the selected rep.",
+        "narrative": "Where the funnel narrows and why it might."
+      },
+      {
+        "key": "day-ahead",
+        "title": "The Day Ahead",
+        "type": "narrative",
+        "narrative": "Two or three priorities for today, grounded in the sections above."
+      }
+    ]
+  }
+}
+```
+
+The create result carries the `template_id` and a `builder_url`. Keep
+both. If the create is refused (an unknown type, a chart type outside
+the vocabulary, a cyclic input chain, a second parameter), relay the
+refusal's reason, fix the draft with the operator, and retry.
+
+## Capture The Rules
+
+For each section that carries data instructions, in template order:
+
+1. `brain_brief_rule_propose` with the `template_id` and the section's
+   `key`. The Brain compiles the section's data instructions into a
+   proposed, typed rule; the call returns a `task_id`.
+2. Poll `brain_brief_rule_propose_result` with that `task_id` until the
+   proposal is ready. If the proposal fails, relay its reason and ask
+   whether to reword the section's data instructions or drop the
+   section.
+3. `brain_brief_rule_preview` with the proposed rule. Show the operator
+   what came back — the real preview rows, honestly, including a zero-row
+   preview ("the reading was taken and nothing matched" is a real
+   answer, not a failure).
+4. Only after the operator confirms a previewed rule,
+   `brain_brief_rule_accept` it. Never accept a rule that was not
+   previewed in this conversation, and never accept on the operator's
+   silence.
+
+Never author a rule yourself. You do not write SQL, graph queries, or
+retrieval specs — proposals come from the capture lane and nowhere else.
+If the operator wants a different rule, reword the data instructions and
+re-propose.
+
+## Fence Refusals
+
+Propose and preview run through the Brain's data fences. When a call
+answers with a fence refusal — for example, no marts are classified for
+the domain the section asks about, or the owner's reach does not cover a
+table — relay the fence's reason to the operator verbatim, do not accept
+anything for that section, and stop capturing it. Never substitute
+fabricated rows, a guessed query, or a softened restatement of the
+refusal. Classification and access are operator actions in the Brain
+console; say so and move on to the remaining sections or finish.
+
+## Handoff
+
+Finish with a short summary — the template name, the sections drafted,
+which rules were accepted and which sections still need attention — and
+the builder link for review: the `builder_url` from the create result,
+or the Brain console path `/analytics/reports/builder?template=<template_id>`.
+The operator reviews, tweaks, picks parameter members, and saves there.
+Refer to every person by display name, never by email.
+
+## Stop Conditions
+
+Stop and ask before proceeding when: the Brief Builder tools are missing
+from the connector; the operator's answers leave a section without a
+type or a chart without a chart type; a second parameter is requested;
+every data section's capture was refused by a fence; or the operator
+asks you to accept a rule whose preview they have not seen.

package/dist/workspace-defaults/files/catalog-skills/n8n-workflow-operator/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: n8n-workflow-operator
+description: Create, update, validate, test, and debug n8n workflows through the tenant's registered n8n MCP server. Use when a request names n8n, workflows, executions, Code node packages, workflow migration, automation drafts, or asks to create an automation from a thread.
+license: Apache-2.0
+compatibility: A registered n8n MCP server backed by a tenant n8n instance with instance-level MCP enabled.
+metadata:
+  skill-format: agentskills
+---
+
+# n8n Workflow Operator
+
+Use n8n as a shared tenant automation runtime. Read live workflow and node
+state, make draft-safe changes, validate the result, and leave production
+activation to the shared native n8n operator unless the human explicitly says
+otherwise.
+
+## First Move
+
+1. Use this skill before any n8n workflow create, update, validation, test, or
+   debug action.
+2. Use the n8n MCP tools exposed by the tenant's registered n8n MCP server. It
+   authenticates with a tenant service credential, not per-user n8n activation.
+3. If n8n tools are missing, report that an operator must register the n8n MCP
+   server in Connectors, enable instance-level MCP in n8n, and enable MCP
+   access on the workflow, project, or folder.
+4. Trust live MCP tool descriptions and node schemas over memory. n8n changes
+   quickly; if a live tool or schema disagrees with this skill, follow the live
+   tool and report the drift in the handoff.
+
+## Authoring Loop
+
+For requests such as "create a workflow", "edit this workflow", or "make a
+smoke test":
+
+1. Classify the pattern: manual trigger, webhook, schedule, HTTP API
+   integration, database sync, AI agent, or batch processing.
+2. Read [MCP tooling](references/mcp-tooling.md), then discover live node
+   schemas before configuring nodes.
+3. Read [workflow authoring](references/workflow-authoring.md), then create or
+   update an inactive draft. Use UUID-shaped node ids, current `typeVersion`
+   values, and no placeholder credentials or secrets.
+4. Validate iteratively. Treat validation errors as normal feedback: fix the
+   specific field, then validate again.
+5. Fetch the workflow after every create or update and inspect `connections` so
+   silently dropped or wrong wires are caught before handoff.
+6. Test only when safe. n8n test runs execute real HTTP calls, writes, sends,
+   and other side effects.
+7. Finish with [validation and handoff](references/validation-and-handoff.md).
+
+## ThinkWork Agent-Step Bridge
+
+1. For n8n-to-ThinkWork agent work, use the v1 agent-step bridge with stock
+   HTTP Request and Wait nodes. Do not suggest a custom ThinkWork n8n node in
+   v1.
+2. The HTTP Request node calls ThinkWork's
+   `/api/integrations/n8n/agent-steps` endpoint with the separate inbound
+   bridge credential. Do not reuse the native n8n MCP service credential.
+3. The workflow must pass target Space, target agent, instructions, structured
+   input, workflow id/name, execution id, step id, correlation id, optional
+   request id, optional timeout, and the current Wait-node resume URL from
+   `$execution.resumeUrl`.
+4. The Wait node should use On webhook call. Downstream nodes should branch on
+   the resumed payload's `status` and read `output`, `error`, `summary`,
+   and `links`; they should not scrape ThinkWork thread pages.
+5. Explain idempotency as workflow id + execution id + correlation id + step
+   id. Retrying the same bridge step should recover or replay the existing
+   ThinkWork thread rather than creating a duplicate.
+
+## Stop Conditions
+
+Stop before writing when multiple workflows match, the workflow/project/folder
+does not have MCP access enabled, credentials are unknown, a test would touch
+production side effects, the user asks for production activation without using
+the native n8n operator account, or the live MCP tool surface conflicts with
+the requested action.

package/dist/workspace-defaults/files/catalog-skills/n8n-workflow-operator/references/mcp-tooling.md

@@ -0,0 +1,40 @@
+# MCP Tooling
+
+Use live n8n MCP tools as the source of truth for tool names, argument shapes,
+node schemas, and current `typeVersion` values.
+
+## Tool Selection
+
+1. Search for nodes before configuring them.
+2. Read the node schema before setting parameters. Standard detail is enough for
+   most nodes; use deeper docs only when the required field is unclear.
+3. Validate nodes or workflows as soon as the tool surface supports it.
+4. Prefer partial workflow updates for edits to existing workflows. Include a
+   short intent when the tool accepts one.
+5. Fetch the workflow after create/update and inspect `connections`.
+
+## Node Type Formats
+
+Use the form expected by the tool being called:
+
+1. Node discovery and node validation tools use short forms, for example
+   `nodes-base.httpRequest`.
+2. Workflow JSON uses full forms, for example
+   `n8n-nodes-base.httpRequest`.
+3. If a tool returns both forms, carry both forward instead of reconstructing
+   from memory.
+
+## Credentials And Secrets
+
+1. Never emit fake credential ids such as `REPLACE_ME`.
+2. If the real credential id is unknown, omit the `credentials` block so the
+   native UI can show a usable selector.
+3. Never put tokens, API keys, or passwords in Set nodes, Code nodes,
+   expressions, or plain text fields. Use the n8n credential system.
+4. The ThinkWork agent-step bridge credential is separate from the n8n MCP
+   service credential.
+
+## Shortened Tool Names
+
+The ThinkWork runtime may expose long MCP tool names in shortened form. Choose
+tools by descriptions and parameter schemas, not memorized exact names.

package/dist/workspace-defaults/files/catalog-skills/n8n-workflow-operator/references/validation-and-handoff.md

@@ -0,0 +1,40 @@
+# Validation And Handoff
+
+Validation passing is necessary, not sufficient. A workflow can validate and
+still have wrong wires, missing branches, or unsafe runtime behavior.
+
+## Validation Loop
+
+1. Validate configured nodes when available.
+2. Create or update the inactive workflow.
+3. Validate the complete workflow.
+4. Fix one concrete error at a time, then validate again.
+5. Treat warnings as context-sensitive. Production workflows should address
+   missing error handling, retry, rate-limit, and credential warnings unless
+   there is a clear reason to accept them.
+
+## Verify After Write
+
+After every create or update:
+
+1. Fetch the workflow by id.
+2. Confirm workflow id, name, active state, tags, project or folder, trigger
+   nodes, credential references, and MCP access state.
+3. Inspect `connections` directly. Confirm each expected branch, error output,
+   and merge input is wired to the intended node.
+4. If multiple workflows match, stop and ask for the exact workflow id or URL.
+
+## Test Evidence
+
+1. Ask before any test that can create records, call external APIs, send
+   messages, or mutate production systems.
+2. Prefer disposable inputs and read-only endpoints.
+3. Record execution ids, failure messages, validation errors, and evidence
+   links in the handoff.
+
+## Handoff Checklist
+
+Include workflow id, workflow name, draft/test status, package requirements,
+credential assumptions, MCP access state, validation result, connection
+verification result, test evidence, and the native n8n UI action required from
+the shared operator.

package/dist/workspace-defaults/files/catalog-skills/n8n-workflow-operator/references/workflow-authoring.md

@@ -0,0 +1,46 @@
+# Workflow Authoring
+
+Build the smallest inactive draft that proves the requested automation shape,
+then validate and verify it before handoff.
+
+## Pattern Choice
+
+1. Manual trigger: use for user-triggered smoke tests and safe demos.
+2. Webhook: use when an external system pushes an event.
+3. Schedule: use for recurring fetch, report, and maintenance workflows.
+4. HTTP API integration: use for read/write calls to external REST APIs.
+5. Database sync: use for ETL and record reconciliation.
+6. AI agent: use when the workflow needs model reasoning or n8n agent tools.
+7. Batch processing: use when item count, pagination, or rate limits matter.
+
+## Construction Rules
+
+1. Prefer HTTP Request nodes over Code nodes for ordinary GET/POST calls.
+2. Prefer expressions in the consuming field for simple data mapping.
+3. Use `{{ ... }}` expressions in n8n fields. Use direct JavaScript only inside
+   Code nodes.
+4. Avoid Set/Edit Fields nodes that feed a single consumer; inline the
+   expression at the consuming field.
+5. For webhook workflows, user payload fields are under `$json.body`, not at
+   the root.
+6. For branchy workflows, reference upstream nodes by name instead of relying on
+   ambiguous `$json` at branch convergence.
+7. Search for existing workflows or templates before creating a larger reusable
+   workflow from scratch.
+
+## Draft Safety
+
+1. Keep created workflows inactive unless the human explicitly completes
+   production activation in the native n8n UI.
+2. Prefer disabled copies or disposable draft workflows for edits.
+3. Run only read-only or low-risk test executions without additional
+   confirmation.
+4. Do not trigger a production webhook, schedule, message send, database write,
+   or destructive external side effect as a smoke test.
+
+## Code Nodes
+
+Use Code nodes only for multi-item aggregation, allowlisted package use, or
+logic that cannot be expressed in fields. For Code nodes, use only packages
+already available to the tenant's n8n deployment. Ask an operator to add a
+package rather than assuming one is present.

package/dist/workspace-defaults/files/skills/artifact-builder/references/crm-dashboard.md

@@ -15,7 +15,7 @@ Do not use emoji as icons, status markers, bullets, tab labels, headings, empty
 Use the best sources available in this order:
 
 1. Thread context and any attached or already retrieved CRM rows.
-2. Available CRM, connector, MCP, context, workspace, memory, or Hindsight tools.
+2. Available CRM, connector, MCP, context, workspace, or memory tools.
 3. Email, calendar, and web context when the prompt asks for stale activity, next meetings, or external account risk.
 4. A small demo or fixture-shaped dataset only when live sources are missing. Make limitations visible only when they materially affect the displayed result.
 

package/dist/workspace-defaults/files/skills/document-composer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: document-composer
-description: 'Compose document deliverables — reports, plans, briefs, and any other genre registered for this workspace — as markdown that the platform compiles into a beautiful house-style document, saved as a durable artifact via emit_document. Use whenever the deliverable is document-shaped: the user asks for a plan, report, brief, write-up, analysis, proposal, or ideation summary, or asks to "write this up", "make a document", "put together a report", or when a substantial multi-section answer deserves a durable, shareable form instead of chat text.'
+description: 'Compose document deliverables — plans, memos, meeting notes, ideation summaries, external research write-ups, and any other genre registered for this workspace — as markdown that the platform compiles into a beautiful house-style document, saved as a durable artifact via emit_document. Use whenever the deliverable is document-shaped: the user asks for a plan, write-up, proposal, or ideation summary, or asks to "write this up" or "make a document", or when a substantial multi-section answer deserves a durable, shareable form instead of chat text. NOT for briefs or reports when a Company Brain is attached — those are minted by the Brain via brain_report_create, never composed here.'
 ---
 
 # Document Composer
@@ -11,10 +11,29 @@ single body. The platform compiles the polished house-style HTML render
 (layout, typography, dark mode, charts) at emission; you never write HTML.
 The thread shows a compact card linking to the full-page reader.
 
+## Briefs and reports belong to the Brain
+
+**When a Company Brain connection is attached, you never compose a brief or
+report yourself.** A brief composed locally has no flag lane, no cortex
+review, and no learning loop — it is worthless to the business. If the
+deliverable is a brief or report over company data (anything you gathered
+through `brain_ask`, `brain_ask_submit` / `brain_ask_result`,
+`brain_analytics_query`, `brain_search`, or any other `brain_*` tool), hand it
+over to the Brain: call `brain_report_create` with the sections you composed.
+It runs the rules, files a living report, and delivers the real brief card to
+this thread. The runtime enforces this — `emit_document` refuses the `report`
+and `brief` genres (and brief/report-titled documents) when a Brain is
+attached, answering `{ ok: false, reason: "brief_is_brain_owned", ... }`.
+When you see that refusal, do not retry under another genre or title: route
+to `brain_report_create`.
+
+Without a Brain attached, `report` and `brief` remain ordinary genres here.
+
 ## When to reach for a document
 
-- The user asks for a plan, report, brief, analysis, proposal, or ideation
-  summary — or to "write this up" / "make a document".
+- The user asks for a plan, analysis, proposal, or ideation summary — or to
+  "write this up" / "make a document". (A brief or report with a Brain
+  attached is the Brain's — see above.)
 - Your answer is substantial (multiple sections, comparisons, decisions,
   metrics) and will be revisited or shared. A document outlives the thread.
 - NOT for short answers, quick lists, or conversational replies — those stay

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "thinkwork-cli",
-  "version": "0.13.1",
+  "version": "1.0.0",
   "description": "Thinkwork CLI — deploy, manage, and interact with your Thinkwork stack",
   "license": "Apache-2.0",
   "type": "module",
@@ -11,7 +11,7 @@
     "dist"
   ],
   "scripts": {
-    "build": "tsup src/cli.ts --format esm --dts --clean && node scripts/bundle-terraform.js",
+    "build": "tsup && node scripts/bundle-terraform.js",
     "dev": "tsx src/cli.ts",
     "codegen": "graphql-codegen --config codegen.ts",
     "typecheck": "tsc --noEmit",
@@ -33,6 +33,7 @@
     "@graphql-codegen/cli": "^5.0.6",
     "@graphql-codegen/client-preset": "^4.8.2",
     "@thinkwork/admin-ops": "workspace:*",
+    "@thinkwork/api": "workspace:*",
     "@thinkwork/database-pg": "workspace:*",
     "@types/node": "^25.6.0",
     "tsup": "^8.0.0",

package/dist/drizzle/0261_thread_turns_origin_turn_index.sql

@@ -1,11 +0,0 @@
--- THINK-307 KTD4: the retry dispatcher's successor-turn guard, THINK-308's
--- finalize reconciliation, and THINK-309's recovery resolver all look up
--- thread_turns by origin_turn_id; no index covers that column today.
--- Additive — safe to apply ahead of code deploy.
---
--- Hand-rolled (drizzle meta journal is not in use for this change);
--- apply with: psql "$DATABASE_URL" -f drizzle/0261_thread_turns_origin_turn_index.sql
--- creates: public.idx_thread_turns_origin_turn
-
-CREATE INDEX IF NOT EXISTS idx_thread_turns_origin_turn
-  ON public.thread_turns (origin_turn_id);

package/dist/plugins/company-data/README.md

@@ -1,49 +0,0 @@
-# Company Data Plugin
-
-The Company Data plugin is the package-owned source boundary for the
-first-party operational facts substrate. This slice publishes the stable
-catalog identity and normal ThinkWork install path before any live Company Data
-runtime exists.
-
-The shell intentionally does not deploy extraction runners, projection database
-schema, mapping workflows, schedules, pipelines, MCP servers, skills,
-credentials, datalake, warehouse, query engine, monitoring, analytics UI, BI,
-Context Engine providers, live operator UI, source-system writes, or
-Terraform-managed resources. Future Company Data work should extend this
-`company-data` package and version line with explicit requirements,
-handler-backed components, and deployed verification before introducing runtime
-capability.
-
-## Owned Source
-
-- `src/manifest.ts` declares the catalog manifest with empty OAuth scopes,
-  no capabilities, and one declared-only `ui-surface` component.
-- `test/manifest.test.ts` validates the shell boundary, manifest shape,
-  customer-facing operational facts copy, and deferred-resource language.
-
-## Shell Scope
-
-V1 is deliberately narrow:
-
-- Company Data appears in the first-party plugin catalog as
-  `company-data@0.1.0`.
-- Tenant administrators can install the shell through the normal plugin
-  install flow.
-- The plugin engine records only the install and one no-op UI-surface component
-  with an empty handler reference.
-- Live extraction runtime, projection schema, mapping workflows, schedules,
-  pipelines, MCP servers, skills, credentials, Context Engine providers,
-  analytics UI, BI, lakehouse query UI, source-system writes, and
-  infrastructure are deferred follow-up work.
-
-## Verification Notes
-
-Package-local verification:
-
-```bash
-pnpm --filter @thinkwork/plugin-company-data test
-pnpm --filter @thinkwork/plugin-company-data typecheck
-pnpm --filter @thinkwork/plugin-catalog test
-pnpm --filter @thinkwork/plugin-catalog typecheck
-node scripts/verify-plugin-source-boundary.mjs
-```

package/dist/plugins/company-data/package.json

@@ -1,21 +0,0 @@
-{
-  "name": "@thinkwork/plugin-company-data",
-  "version": "0.0.0",
-  "private": true,
-  "type": "module",
-  "main": "./src/index.ts",
-  "exports": {
-    ".": "./src/index.ts",
-    "./manifest": "./src/manifest.ts"
-  },
-  "scripts": {
-    "build": "tsc --build",
-    "typecheck": "tsc --noEmit",
-    "test": "vitest run"
-  },
-  "devDependencies": {
-    "@thinkwork/plugin-catalog": "workspace:*",
-    "typescript": "^5.5.0",
-    "vitest": "^2.0.0"
-  }
-}

package/dist/plugins/company-data/src/index.ts

@@ -1,30 +0,0 @@
-import { companyDataManifest } from "./manifest";
-
-export const companyDataPluginPackage = {
-  packageKey: "company-data",
-  sourceRoot: "plugins/company-data",
-  manifest: companyDataManifest,
-  ownedSources: [
-    {
-      kind: "manifest",
-      path: "plugins/company-data/src/manifest.ts",
-      description:
-        "Company Data catalog manifest for the shell-only plugin identity.",
-    },
-    {
-      kind: "docs",
-      path: "plugins/company-data/README.md",
-      description:
-        "Company Data package ownership and deferred resource notes.",
-    },
-    {
-      kind: "tests",
-      path: "plugins/company-data/test",
-      description:
-        "Company Data package-local manifest and shell-boundary tests.",
-    },
-  ],
-  compatibilityLinks: [],
-} as const;
-
-export { companyDataManifest };

package/dist/plugins/company-data/src/manifest.ts

@@ -1,26 +0,0 @@
-import type { PluginManifest } from "@thinkwork/plugin-catalog/contracts";
-
-export const COMPANY_DATA_SETTINGS_SURFACE =
-  "settings.plugins.detail.tab" as const;
-
-export const companyDataManifest = {
-  pluginKey: "company-data",
-  displayName: "ThinkWork Data Warehouse",
-  description:
-    "Establishes a governed operational facts substrate for agent and UI reads. Extraction runners, projection databases, Context Engine providers, MCP tools, analytics, BI, and source-system writes belong to later ThinkWork Data Warehouse releases.",
-  versions: [
-    {
-      version: "0.1.0",
-      requiredOauthScopes: [],
-      capabilities: [],
-      components: [
-        {
-          type: "ui-surface",
-          key: "settings",
-          displayName: "ThinkWork Data Warehouse settings",
-          intendedMount: COMPANY_DATA_SETTINGS_SURFACE,
-        },
-      ],
-    },
-  ],
-} satisfies PluginManifest;