@elevasis/ui 2.30.0 → 2.31.0

package/dist/{chunk-HYLERWRO.js → chunk-ND42LPY4.js}

@@ -1,12 +1,12 @@
 import { AppShellLoader } from './chunk-RYTEQBAO.js';
 import { FilterBar } from './chunk-PDHTXPSF.js';
-import { CustomModal } from './chunk-KVJ3LFH2.js';
-import { useAvailablePresets } from './chunk-IKQ42WHU.js';
-import { useDeleteCredential, useCreateCredential, useCredentials, MEMBERSHIP_STATUS_COLORS, transformMembershipToTableRow, useUserMemberships, useUpdateWebhookEndpoint, useResources, useDeleteWebhookEndpoint, useCreateWebhookEndpoint, useListWebhookEndpoints, useOrgRoles, useAssignRole, useRevokeRole, useHasPermission, useUpdateMemberConfig, useOrganizationMembers, useUpdateCredential, CredentialSchemas } from './chunk-6EFVZV6X.js';
-import { showApiErrorNotification, showErrorNotification, showSuccessNotification } from './chunk-T2PAD63Y.js';
-import { ListSkeleton, EmptyState, PageTitleCaption, CardHeader, APIErrorAlert, StatCard } from './chunk-6WXDE5LZ.js';
+import { CustomModal } from './chunk-R66W5UDG.js';
+import { useAvailablePresets } from './chunk-QHEWXU7I.js';
+import { useDeleteCredential, useCreateCredential, useCredentials, MEMBERSHIP_STATUS_COLORS, transformMembershipToTableRow, useUserMemberships, useUpdateWebhookEndpoint, useResources, useDeleteWebhookEndpoint, useCreateWebhookEndpoint, useListWebhookEndpoints, useOrgRoles, useAssignRole, useRevokeRole, useHasPermission, useUpdateMemberConfig, useOrganizationMembers, useUpdateCredential, CredentialSchemas } from './chunk-JKSUN5GN.js';
+import { showApiErrorNotification, showErrorNotification, showSuccessNotification } from './chunk-7HMCB26R.js';
+import { ListSkeleton, EmptyState, PageTitleCaption, CardHeader, APIErrorAlert, StatCard } from './chunk-L3BVJWML.js';
 import { RoleBadge } from './chunk-JA5ECJJB.js';
-import { isAPIClientError, formatDateTime, OAUTH_FLOW_TIMEOUT } from './chunk-HXZQWMKE.js';
+import { isAPIClientError, formatDateTime, OAUTH_FLOW_TIMEOUT } from './chunk-XQHZBA65.js';
 import { useInitialization } from './chunk-533DUEQY.js';
 import { useOrganization } from './chunk-DD3CCMCZ.js';
 import { useElevasisServices } from './chunk-KJ3QUBNU.js';

package/dist/{chunk-CLUP5H3C.js → chunk-O2QOPJI5.js}

@@ -1,4 +1,4 @@
-import { SemanticIcon } from './chunk-JCGD4GM6.js';
+import { SemanticIcon } from './chunk-GRDLB6LM.js';
 import { Stack, Group, Title, Text, Box, Divider, useTree, Tree, UnstyledButton, TextInput } from '@mantine/core';
 import { jsx, jsxs, Fragment } from 'react/jsx-runtime';
 import { useMemo, useState, useRef, useEffect } from 'react';
@@ -1367,6 +1367,131 @@ Graduated Exposure Protocol
 3. Face bubble intro (15-30s) + screen recording \u2014 ongoing
 
 Each stage desensitizes one fear at a time. Never skip ahead. The goal is consistency, not perfection.`
+  },
+  {
+    id: "knowledge.what-is-elevasis",
+    title: "What is Elevasis",
+    summary: "Company overview, positioning, value proposition, and pricing for the AI orchestration platform",
+    bodyText: 'Executive Summary\n\nCompany: Bootstrapped AI orchestration platform for done-for-you business automation\n\nFounder: Solo (Alex, 34), bootstrapped\n\nMarket: Service-based SMBs that need practical AI automation without building internal AI teams\n\nGTM: Content-led marketing, proof assets, consultative sales, and land-and-expand pricing\n\nCompany Overview\n\nCurrent Status\n\nThe platform core is production-ready enough to support client-facing demonstrations and implementation work. Current business focus is client acquisition, proof-building, and turning the platform into a repeatable service delivery system.\n\nFounder Profile\n\nAlex, 34 \u2014 Solo founder with software engineering background (BSCS degree). Previous: Ecommerce platforms, Streaming technology. No formal AI background \u2014 practitioner, not academic.\n\nWhat We Are\n\nOperating layer for AI automation. We help SMBs operate with closed-loop feedback, decision capture, and continuous learning \u2014 at SMB pricing with done-for-you implementation (NOT self-service).\n\nTarget Market\n\nICP: Service-based SMBs (2-50 employees, USA, $200K-$5M revenue)\n\nCore Pain: Capacity crisis, pipeline problems, operational chaos, growth blockers \u2014 too busy serving clients to grow their own business.\n\nPricing (Land-and-Expand)\n\n- Tier 1 \u2014 Foundation (1-2 workflows): $500-2k/mo\n- Tier 2 \u2014 Scaled Operations (3-5 workflows): $2k-5k/mo\n- Tier 3 \u2014 AI-Powered Systems (6+ workflows): $5k-15k+/mo\n\nAdditional workflows cost less due to shared infrastructure.\n\nValue Proposition\n\n"We find one bottleneck in your business, build an AI solution to fix it, and you only pay if it actually saves you time or makes you money."'
+  },
+  {
+    id: "knowledge.platform-capabilities",
+    title: "Platform Capabilities",
+    summary: "Authoritative overview of the Elevasis AI Orchestration Platform \u2014 what's built, what it does, and how the pieces fit together",
+    bodyText: "Overview\n\nElevasis is a production AI orchestration platform that coordinates workflows, autonomous agents, and human approvals into a unified operating layer for SMBs. Everything described below is implemented and running in production.\n\nCore Architecture:\n\n| Layer | What It Does | Key Components |\n| --- | --- | --- |\n| Execution | Runs workflows and agents with schema validation | Workflow Engine, Agent Framework, Execution Runner |\n| Control | Human oversight, approvals, and decision capture | Command Queue (HITL), Dynamic Forms, Action System |\n| Intelligence | Autonomous reasoning, tool use, and memory management | ReAct Agents, Knowledge Map, Session Memory |\n| Observability | Real-time visibility into cost, performance, and health | Cost Tracking, Metrics, Activity Log, SSE Streaming |\n| Platform | Multi-tenancy, security, scheduling, integrations | Registry, RLS, Scheduler, Credential Vault, SDK |\n\nExecution Engine\n\nAI Workflows\n\nGraph-based workflow execution with schema-validated steps and conditional routing. Steps define explicit routing: linear, conditional (rule-based branching), or terminal. Context flows through the entire workflow.\n\nAutonomous Agents\n\nProduction-grade ReAct-style agents with tool use, memory management, and security hardening.\n\nLLM Provider Support: OpenAI (GPT-5), Google (Gemini 3 Flash), Anthropic (Claude Sonnet 4.5), OpenRouter (GLM-5)\n\nHuman-in-the-Loop (HITL)\n\nThe Command Queue surfaces pending approvals as structured tasks. Admin reviews, approves or edits, and the workflow continues. Every critical decision \u2014 sending emails to prospects, updating customer records, publishing content \u2014 requires human approval.\n\nKnowledge Map\n\nOrganizational knowledge loaded lazily into agent context. 80-95% token savings vs. always-loading full context. Nodes link to features, teams, and other nodes.\n\nIntegrations (13 active)\n\nAttio CRM, Cal.com, Instantly (cold email), Resend, Apify, Google Maps, Tomba, Mails.so, Supabase, Stripe, OpenAI, Google Gemini, Anthropic Claude.\n\nSDK\n\nTypeScript-based resource development with local testing, validation, and deployment pipeline. External consumers define workflows and agents in their own repos and deploy via elevasis-sdk deploy."
+  },
+  {
+    id: "knowledge.client-testimonials",
+    title: "Testimonials",
+    summary: "Customer testimonials and case study permissions from previous client work",
+    bodyText: `Status: 4 testimonials from 2 clients | Source: Upwork client work (2024)
+
+Testimonials
+
+Xero Automation \u2014 The Invoice Chase That Disappeared
+
+Client: Word of Mouth Agency
+
+Result: 10+ hours/week saved. Zero manual follow-up emails.
+
+> "Working with Alex at Elevasis to automate our Xero follow-ups has been a game-changer. We're set to save over 5 hours a week, but more importantly, it has completely removed the stress of chasing invoices. The process was smooth and professional."
+
+Permission: Case study approved with company name.
+
+Influencer Discovery \u2014 From Spreadsheet Hell to Strategic Decisions
+
+Client: Word of Mouth Agency (Perth, Australia)
+
+Result: 10+ hours/week saved. Research scope: 50 to 200+ influencers. Team focus shifted from data to strategy.
+
+> "Working with Alex at Elevasis to automate our Influencer Discovery has been a game-changer. We're set to save over 5 hours a week..."
+
+Permission: Case study approved with company name.
+
+EMRG Media \u2014 4 Automations for NYC's Premier Events Firm
+
+Client: EMRG Media (NYC, est. 2001). Clients include Google, YouTube, Sony Music, Fiverr, Equinox.
+
+What We Built:
+1. Case Study Generator \u2014 7-10 hours \u2192 2 hours. Publication rate: 1/quarter \u2192 2/month.
+2. EMRG Follow-Up Generator \u2014 Automated post-event follow-ups with signature management.
+3. Event Sponsor Tracker \u2014 Automated sponsor pipeline tracking and communications.
+4. Lead Scraper \u2014 Automated discovery of event planning prospects.
+
+Fame Stats:
+- 3,500+ attendees at The Event Planner Expo
+- 25+ year track record
+- Fortune 500 client roster
+
+Permission: Case study approved with company name.`
+  },
+  {
+    id: "knowledge.understanding-elevasis",
+    title: "Understanding Elevasis Overview",
+    summary: "Company overview, product positioning, and platform capability context for Elevasis AI orchestration platform",
+    bodyText: "Lean documentation explaining what Elevasis is and what the platform can do. This section provides the foundational context for business conversations and technical evaluation.\n\nElevasis is a done-for-you AI automation service backed by a production-grade platform. The company targets service-based SMBs (2-50 employees, $200K-$5M revenue) who are too busy serving clients to grow their own business.\n\nKey Facts\n\n- Stage: Pre-revenue, platform 100% complete, client acquisition active\n- Offer: Done-for-you AI automation -- we build and maintain the workflows, no coding required\n- ICP: Service-based SMBs (2-50 employees, $200K-$5M revenue, USA)\n- Pricing: $500-$2k/mo (Foundation) \u2192 $2k-$5k/mo (Scaled) \u2192 $5k-$15k+/mo (AI-Powered)\n- Market: Early Adopters stage, $23.77B TAM growing to $87.7B by 2032\n- Competitive position: No dominant done-for-you SMB AI provider exists; blue ocean\n\nWhen to Use Each Document\n\n| Situation | Document |\n| --- | --- |\n| First conversation with any audience | What is Elevasis |\n| Technical evaluation or demo prep | Platform Capabilities |\n\nDocumentation\n\n- What is Elevasis \u2014 AI orchestration platform overview, company stage, value proposition, and pricing tiers\n- Platform Capabilities \u2014 Authoritative overview of what is built, what it does, and how the pieces fit together"
+  },
+  {
+    id: "knowledge.marketing-overview",
+    title: "Marketing Overview",
+    summary: "Marketing documentation for Elevasis - strategy, website infrastructure, and content systems",
+    bodyText: "Welcome to the Elevasis marketing documentation. This section covers marketing strategy, website implementation, and content systems.\n\nDocumentation\n\nStrategy\n\n- Overview \u2014 Channel strategy, inbound content system, and proof-led demand generation\n\nWebsite\n\nThe marketing website's technical infrastructure, setup, and SEO docs now live under Architecture \u2192 Website."
+  },
+  {
+    id: "knowledge.ai-orchestration-principles",
+    title: "AI Orchestration Principles",
+    summary: "The 4 principles that separate production AI from toy automation",
+    bodyText: `Most AI automation fails. Not because the technology is bad, but because it's implemented without the principles that make AI systems work in production.
+
+These four principles separate toy automation from AI systems that actually run businesses.
+
+The 4 Principles
+
+1. Integrated: Works With Your Existing Systems
+
+Principle: AI must work with your existing tools, not replace them.
+
+AI that doesn't connect to your CRM, your email, your calendar, your existing workflows is a toy. Real AI automation works WITH what you already have \u2014 not instead of it.
+
+- Your 50 Zapier workflows keep running
+- Your CRM stays your CRM
+- AI adds intelligence on top, not a rip-and-replace
+
+The anti-pattern: "Use our AI instead of everything else." Creates vendor lock-in and throws away your existing investment.
+
+2. Improving: Gets Smarter Over Time
+
+Principle: AI must learn from every decision and improve continuously.
+
+Static automation is just fancy if-then logic. Real AI captures every approval, rejection, and edit \u2014 then uses that data to get smarter.
+
+The anti-pattern: "Set it and forget it." Systems that don't learn stay dumb forever.
+
+3. Observable: You See What AI Is Doing
+
+Principle: You must be able to see what AI systems are doing in real-time.
+
+Black-box automation is unacceptable for business operations. You need to see every action, every decision, every cost \u2014 as it happens.
+
+- Real-time activity feeds showing what's executing
+- Cost tracking per workflow, per execution
+- Token usage visibility
+- Execution logs for debugging
+
+The anti-pattern: "It just works, trust us." Systems without observability create anxiety and prevent adoption.
+
+4. Governed: Humans Control What Matters
+
+Principle: Humans must approve important actions before execution.
+
+AI should handle the grunt work. But critical decisions \u2014 sending emails to prospects, updating customer records, publishing content \u2014 require human approval.
+
+- AI researches 50 prospects and drafts personalized emails
+- Before anything sends, it lands in your approval queue
+- You spend 10 minutes reviewing, approve or tweak
+- Only then does it execute
+
+The anti-pattern: "Fully autonomous AI." Systems without governance create risk and erode trust.`
   },
   {
     id: "knowledge.new-vertical-launch-playbook",
@@ -1528,6 +1653,240 @@ Launch Checklist
     summary: "Stable scanning, scoring, freshness, and query-health workflow for the Upwork acquisition channel.",
     bodyText: 'Overview\n\nUse this playbook to run the Upwork acquisition scanning loop. The goal is to find fresh, low-competition jobs where Elevasis can deliver a real business system, score them consistently, and turn the best opportunities into proposals through the Upwork proposal playbook.\n\nThe scanning loop has six phases:\n\n1. Confirm browser and login readiness.\n2. Run saved search queries with the right filters.\n3. Extract fresh job cards.\n4. Deduplicate, score, and enrich strong candidates.\n5. Write the scan output.\n6. Review query health before the next scan.\n\nProposal copy and response handling are intentionally separate. Use knowledge.upwork-proposal-playbook for proposal strategy and knowledge.upwork-response-templates for client replies.\n\nPreconditions\n\nBefore scanning, verify the browser automation surface is available and Upwork is logged in.\n\n- Chrome tooling must be available through the active browser automation tools.\n- The Upwork search page must load at https://www.upwork.com/nx/search/jobs/.\n- The page must show the job search interface, not a login prompt.\n- If login is required, stop and log in manually before scanning again.\n\nDo not try to work around a missing browser session by inventing scan results. The scan depends on live Upwork search pages, current saved-search filters, and the visible result cards.\n\nScan Surface\n\nRun scans from the Upwork search page:\n\ntext\nhttps://www.upwork.com/nx/search/jobs/\n\nEach saved query is run individually. Apply the filters every time, because Upwork search state is session-dependent and not always persisted across queries.\n\n| Filter    | Value       | Reason                                                                 |\n| --------- | ----------- | ---------------------------------------------------------------------- |\n| U.S. only | Checked     | Higher-quality clients, stronger timezone fit, more verified payments. |\n| Sort by   | Most Recent | Freshness is the strongest conversion lever.                           |\n| Proposals | \\<5, 5-10 | Low competition is required before spending connects.                  |\n\nUse saved queries as the primary scan source. The strategy targets operational system-build terms, not generic "AI automation" searches that attract high competition.\n\nFreshness Rule\n\nOnly collect posts from the last 12 hours. Results should be sorted by Most Recent, so stop extracting for a query once the visible posts are older than 12 hours. Do not do catch-up windows.\n\nFreshness priority:\n\n| Post age   | Action                                                           |\n| ---------- | ---------------------------------------------------------------- |\n| 0-1 hour   | Highest priority. Client is most likely active and shortlisting. |\n| 1-12 hours | Valid scan window. Still worth scoring if competition is low.    |\n| 12+ hours  | Skip. The client has usually already formed the shortlist.       |\n\nRecord the scan timestamp as lastscanned in the daily scan doc frontmatter. This timestamp helps avoid reprocessing posts from prior scans, but the hard 12-hour cap still applies.\n\nRun Each Query\n\nFor each active saved query:\n\n1. Clear the search box.\n2. Enter the query string and submit.\n3. Apply U.S. only, Most Recent, and proposal-count filters.\n4. Wait for results to render.\n5. Extract visible job cards from the search page.\n6. Stop once a post exceeds the freshness cutoff.\n7. Tag each job with the source query.\n\nThe first page of most-recent, low-proposal results is the high-value slice. Do not paginate unless a specific investigation requires it.\n\nWhile scanning the API integration query, flag custom dashboard opportunities where a custom build is likely better than Power BI, Looker, Tableau, or a spreadsheet. Strong signs include 3+ data sources, live dashboard requirements, AI-generated summaries, anomaly detection, or workflow triggers.\n\nExtract Job Card Data\n\nThe search-card extraction should capture the fields needed for initial triage:\n\n- Title.\n- Upwork job URL path.\n- Posted age.\n- Proposal count.\n- Budget or hourly range.\n- Payment verification.\n- Client rating.\n- Total client spend.\n- Description snippet.\n- Source query.\n\nDeduplicate by Upwork job URL path after all queries finish. If a job appears under multiple queries, keep one row and note the overlap.\n\nScore and Enrich\n\nScoring has two stages.\n\nStage 1: Relevance\n\nScore relevance from 0 to 100 by asking whether the client needs a system, workflow, integration, automation, or operational build that Elevasis can deliver.\n\n| Range  | Label        | Criteria                                                                  |\n| ------ | ------------ | ------------------------------------------------------------------------- |\n| 75-100 | Strong fit   | Clear build intent, specific business workflow, named tools or outputs.   |\n| 50-74  | Possible fit | Some build signals, but scope or buyer intent is ambiguous.               |\n| 25-49  | Weak fit     | Marginally related, mostly noise, low business-system signal.             |\n| 0-24   | Irrelevant   | Hiring, marketing, design, manual VA work, personal projects, or errands. |\n\nDisqualify posts that are clearly hiring a role, outsourcing manual work, asking for generic marketing/design help, or describing a personal/non-business project.\n\nStage 2: Application Priority\n\nApply tactical modifiers after relevance scoring. The final score determines whether to draft a proposal.\n\n| Signal         | Positive indicators                                  | Negative indicators                         |\n| -------------- | ---------------------------------------------------- | ------------------------------------------- |\n| Freshness      | \\<1h or same-session post.                         | 8-12h old, or outside the scan window.      |\n| Competition    | \\<5 proposals, or 5-10 with strong fit.            | 10+ proposals, especially 20+.              |\n| Client quality | Payment verified, spend history, good rating, hires. | Unverified, no history, 0% hire rate.       |\n| Budget         | Fixed \\>$5K or hourly \\>$75/hr.                  | Fixed \\<$1K or hourly \\<$40/hr.         |\n| Fit            | Workflow, integration, dashboard, CRM, operations.   | Copywriting, funnels, ads, hiring, support. |\n\nOnly enrich posts with a strong enough relevance score to matter, usually 65+. For those posts, open the job detail view and capture:\n\n- Hire rate.\n- Jobs posted.\n- Member since.\n- Company size.\n- Last viewed by client.\n- Interviewing count.\n\nUse this data to avoid over-ranking stale or low-quality clients that have a good-sounding job description but weak application ROI.\n\nWrite the Scan Output\n\nWrite scan docs under:\n\ntext\napps/docs/content/docs/operations/client-acquisition/upwork/scans/{YYYY-MM-DD}.mdx\n\nIf a scan doc already exists for the day, append the new scan as a later section instead of creating a second daily file.\n\nEach scan output should include:\n\n- Date and timestamp.\n- Freshness cutoff.\n- Queries scanned.\n- Total posts collected.\n- Deduplicated count.\n- Top opportunities only.\n- Comparison table.\n- Query health table.\n- Draft proposals section, when proposals are generated.\n\nKeep scan docs as decision tools, not archives. Include the top 10 ranked opportunities rather than every collected post.\n\nQuery Health\n\nAfter scoring, compute a query-health score so weak searches can be removed over time.\n\n| Metric          | Measurement                                                       | Weight |\n| --------------- | ----------------------------------------------------------------- | ------ |\n| Fresh posts     | Count within cutoff, normalized against 5 posts.                  | 25%    |\n| Low competition | Percent with fewer than 10 proposals.                             | 25%    |\n| Relevance       | Percent actionable after deduplication and disqualification.      | 30%    |\n| Client quality  | Percent with verified payment and useful spend or rating signals. | 20%    |\n\nQueries that score 0 across 3+ consecutive scans are drop candidates. Compare the latest query-health table with the previous scan before changing the active query set.\n\nActive Query Principles\n\nStrong Upwork queries describe the system the buyer needs, not the freelancer category they think they are hiring.\n\nUse:\n\n- Specific operational system nouns such as booking system, intake form, scheduling system, ticketing system, tracking system, reservation system, billing system, and payment system.\n- Action verbs such as build, automate, custom, develop, setup, integration, and workflow.\n- Platform-specific searches where system-build intent overlaps with implementation work, such as GoHighLevel, Pipedrive, CRM, API integration, or inventory sync.\n\nAvoid:\n\n- Broad solution-first terms such as AI automation, AI agent, workflow automation, portal, dashboard, tool, or custom without a specific system noun.\n- Vertical keywords such as clinic, contractor, salon, or real estate unless paired with concrete system intent.\n- Pain-signal phrases that usually mean the client is hiring a human to perform manual work.\n- Revenue-proximity service terms such as cold email, appointment setting, outbound specialist, or funnel work.\n\nBefore testing a new query, read knowledge.upwork-query-strategy and check the Upwork query registry in the operations docs so old failure modes are not repeated. Use knowledge.upwork-calibration-strategy when promoting, dropping, or re-evaluating saved searches.\n\nProposal Handoff\n\nAfter the scan, draft proposals only for opportunities that remain strong after relevance, tactical modifiers, and client-quality checks.\n\nFor proposal drafting:\n\n1. Load knowledge.upwork-proposal-playbook.\n2. Read the top opportunities from the latest scan doc.\n3. Select the right proposal template by scope, budget, and relevance.\n4. Tailor the opening, proof point, plan, and two discovery questions.\n5. Append draft proposals to the scan doc under ## Draft Proposals.\n\nUse knowledge.upwork-response-templates after a client replies or sends an offer.\n\nScan Checklist\n\n- Browser tooling available.\n- Upwork logged in.\n- Search page loaded.\n- U.S. only filter applied.\n- Sort set to Most Recent.\n- Proposal-count filters applied.\n- All active saved queries scanned.\n- Posts older than 12 hours skipped.\n- Jobs deduplicated by URL path.\n- Relevance scores assigned.\n- Strong candidates enriched from detail view.\n- Final scores sorted descending.\n- Daily scan doc created or appended.\n- Query health table written.\n- Top proposal candidates handed to knowledge.upwork-proposal-playbook.'
   },
+  {
+    id: "knowledge.client-cli-overview",
+    title: "Client CLI Overview",
+    summary: "Reference for the seven client:* SDK CLI commands -- list, get, status, resolve, create, update, and delete -- with drill-down recipes for navigating client lineage, org-wide rollups, and write operations.",
+    bodyText: `Overview
+
+The client: commands expose the clients hub through the SDK CLI. Use them to paginate clients, inspect individual client lineage, check org-wide status rollups, resolve a fuzzy name to a client ID, and mutate clients with create, update, and delete operations.
+
+All examples below use the canonical monorepo invocation pattern. Tenant projects inside their own operations/ directory drop the -C packages/elevasis-operations prefix and run pnpm exec elevasis-sdk <cmd> directly.
+
+client:list
+
+Lists clients for the authenticated organization with optional filtering and pagination.
+
+Purpose: Paginate all clients or narrow by status or search term to find the right client ID before drilling in with client:get.
+
+Monorepo invocation:
+
+bash
+pnpm -C packages/elevasis-operations exec elevasis-sdk client:list
+
+Tenant invocation (from inside operations/):
+
+bash
+pnpm exec elevasis-sdk client:list
+
+Key flags:
+
+- --status <value> -- filter by client status (e.g. active, inactive, prospect)
+- --search <term> -- full-text search against client name
+- --limit <n> -- maximum rows to return (default varies by server)
+- --offset <n> -- pagination offset
+- --pretty -- pretty-print JSON output
+
+Drill-down recipe:
+
+1. Run client:list --pretty to scan names and IDs.
+2. Use --search to narrow when the list is long.
+3. Copy the id from a row and pass it to client:get <id> for the full lineage payload (linked deal, primary company, primary contact, projects).
+
+client:get
+
+Fetches a single client record with its full lineage payload.
+
+Purpose: Inspect one client in detail -- its associated deal, primary company, primary contact, and linked projects. Use this to confirm linkage after wiring a project to a client via project:update --client.
+
+Monorepo invocation:
+
+bash
+pnpm -C packages/elevasis-operations exec elevasis-sdk client:get <clientId>
+
+Tenant invocation:
+
+bash
+pnpm exec elevasis-sdk client:get <clientId>
+
+Key flags:
+
+- --pretty -- pretty-print JSON output
+
+Drill-down recipe:
+
+1. Obtain <clientId> from client:list or client:resolve.
+2. Run client:get <clientId> --pretty.
+3. Check projects array to confirm which projects are linked.
+4. If projects is empty and a linkage was expected, run project:update <projectId> --client <clientId> to attach it.
+5. Re-run client:get to verify the lineage updated.
+
+client:status
+
+Returns an org-wide rollup of client counts grouped by status.
+
+Purpose: High-level health check -- how many clients are active, how many are in each pipeline stage -- without enumerating every record.
+
+Monorepo invocation:
+
+bash
+pnpm -C packages/elevasis-operations exec elevasis-sdk client:status
+
+Tenant invocation:
+
+bash
+pnpm exec elevasis-sdk client:status
+
+Key flags:
+
+- --pretty -- pretty-print JSON output
+
+Drill-down recipe:
+
+1. Run client:status --pretty to see counts per status bucket.
+2. If a bucket looks unexpectedly large or small, run client:list --status <value> to enumerate the records in that bucket.
+3. Use client:get <id> on specific records to investigate lineage gaps.
+
+client:resolve
+
+Fuzzy-resolves a client name to a client ID.
+
+Purpose: Convert a partial or approximate name to the canonical UUID before passing --client to project commands. Mirrors project:resolve in shape.
+
+Monorepo invocation:
+
+bash
+pnpm -C packages/elevasis-operations exec elevasis-sdk client:resolve "<query>"
+
+Tenant invocation:
+
+bash
+pnpm exec elevasis-sdk client:resolve "<query>"
+
+Key flags:
+
+None beyond the positional <query> argument. Output is the resolved client ID (or a ranked list if multiple matches exist).
+
+Drill-down recipe:
+
+1. Run client:resolve "partial name" -- the command returns the best-match client ID.
+2. Pass the returned ID to project:create --client <id>, project:update --client <id>, or project:list --client <id>.
+3. If multiple matches are returned, refine the query or use client:list --search "<term>" to inspect candidates before committing.
+
+client:create
+
+Creates a new client record for the authenticated organization.
+
+Purpose: Provision a client directly from the CLI -- useful for scripted onboarding or bulk imports where no source deal exists yet. The only required field is --name; all relationship IDs are optional and can be set later via client:update.
+
+Monorepo invocation:
+
+bash
+pnpm -C packages/elevasis-operations exec elevasis-sdk client:create --name "Acme Corp"
+
+Tenant invocation (from inside operations/):
+
+bash
+pnpm exec elevasis-sdk client:create --name "Acme Corp"
+
+Key flags:
+
+- --name <name> -- (required) client display name
+- --status <value> -- initial status: active | onboarding | paused | completed | churned
+- --source-deal-id <uuid> -- UUID of the originating deal
+- --primary-company-id <uuid> -- UUID of the primary company record
+- --primary-contact-id <uuid> -- UUID of the primary contact record
+- --metadata <json> -- arbitrary metadata as a JSON string (e.g. '{"tier":"enterprise"}')
+- --pretty -- render a human-readable summary instead of raw JSON
+
+Drill-down recipe:
+
+1. Run client:create --name "Acme Corp" --status onboarding --pretty to create and confirm the new record.
+2. Copy the ID from the pretty output (or id from raw JSON) for subsequent commands.
+3. Run client:get <id> --pretty to verify the full lineage payload was initialized correctly.
+4. If a source deal exists, pass --source-deal-id <uuid> at create time or backfill with client:update <id> --source-deal-id <uuid>.
+
+client:update
+
+Updates one or more fields on an existing client. Accepts a UUID or fuzzy name as the \\<id\\> argument.
+
+Purpose: Rename a client, change its status, swap or clear relationship IDs, or patch arbitrary metadata -- without leaving the CLI. The command enforces a client-side "at-least-one-field" guard and rejects mutually exclusive flag pairs before making any API call.
+
+Monorepo invocation:
+
+bash
+pnpm -C packages/elevasis-operations exec elevasis-sdk client:update <id> --status active
+
+Tenant invocation:
+
+bash
+pnpm exec elevasis-sdk client:update <id> --status active
+
+Key flags:
+
+- --name <name> -- new client display name
+- --status <value> -- new status: active | onboarding | paused | completed | churned
+- --source-deal-id <uuid> -- set or replace the source deal link
+- --clear-source-deal -- remove the source deal link (sets sourceDealId to null; mutually exclusive with --source-deal-id)
+- --primary-company-id <uuid> -- set or replace the primary company
+- --clear-primary-company -- remove the primary company link (mutually exclusive with --primary-company-id)
+- --primary-contact-id <uuid> -- set or replace the primary contact
+- --clear-primary-contact -- remove the primary contact link (mutually exclusive with --primary-contact-id)
+- --metadata <json> -- replace metadata with the provided JSON string
+- --pretty -- render a human-readable summary instead of raw JSON
+
+Drill-down recipe:
+
+1. Obtain \\<id\\> from client:list, client:resolve, or the output of client:create.
+2. Pass only the fields to change -- the command patches rather than replaces the record.
+3. To unlink a relationship (e.g. remove the source deal), use --clear-source-deal rather than omitting the flag; omitting leaves the existing value unchanged.
+4. After update, run client:get <id> --pretty to confirm all fields reflect the expected state.
+5. If the command exits with CONFLICTINGFLAGS on stderr, you passed both a set flag and its --clear- counterpart -- remove one and retry.
+
+client:delete
+
+Deletes a client record. Accepts a UUID or fuzzy name as the \\<id\\> argument.
+
+Purpose: Remove a client that was created in error or is no longer relevant. The API enforces a 409 Conflict when the client has linked rows (deals, projects, companies, contacts). The CLI surfaces the API error message verbatim so you know which links to resolve first.
+
+Monorepo invocation:
+
+bash
+pnpm -C packages/elevasis-operations exec elevasis-sdk client:delete <id>
+
+Tenant invocation:
+
+bash
+pnpm exec elevasis-sdk client:delete <id>
+
+Key flags:
+
+- --pretty -- render a human-readable confirmation instead of raw JSON
+- --api-url <url> -- override the API base URL (advanced; rarely needed)
+
+Drill-down recipe:
+
+1. Run client:get <id> --pretty to confirm which projects and deal links are attached before attempting deletion.
+2. Run client:delete <id> --pretty.
+3. If the API returns a 409, the error message lists the linked record counts (deals, projects, companies, contacts). Unlink or reassign those records first:
+   - Projects: project:update <projectId> --clear-client (or reassign with --client <otherId>)
+   - Deals: handled via the acquisition domain; no dedicated CLI command today
+4. Retry client:delete <id> --pretty once all links are resolved.
+5. Confirm deletion with client:list --search "<name>" -- the record should no longer appear.
+
+Typical Workflow
+
+A common session combining read and write commands:
+
+1. client:status --pretty -- check org-wide distribution.
+2. client:resolve "Acme" -- get the Acme client ID.
+3. client:get <id> --pretty -- confirm lineage (deal, company, contact, projects).
+4. project:update <projectId> --client <id> -- link a project if missing.
+5. client:get <id> --pretty -- verify the linkage appears in the projects array.
+6. client:create --name "New Corp" --status onboarding --pretty -- provision a new client.
+7. client:update <id> --status active --pretty -- transition a client to active.
+8. client:delete <id> --pretty -- remove a client (API rejects with 409 if linked rows exist).`
+  },
   {
     id: "knowledge.youtube-obs-recording-setup",
     title: "YouTube OBS Recording Setup",
@@ -1802,131 +2161,6 @@ Pre-Recording Checklist
     title: "Platform Integration Patterns",
     summary: "Reference for connecting Elevasis agents and workflows to external services through adapters, OAuth, API keys, tenant-isolated credentials, retries, and tests.",
     bodyText: "Overview\n\nIntegration patterns define how Elevasis agents and workflows connect to external services such as Gmail, Attio, Google Sheets, and custom APIs. The platform uses a standardized adapter pattern with OAuth 2.0 and API key authentication backed by tenant-isolated credentials.\n\nCore patterns:\n\n- Direct integration, where a resource uses integration tools directly.\n- Integration workflow, where a workflow coordinates multiple integrations.\n- Shared integration, where multiple resources use the same credential set.\n- Multi-account integration, where the same provider has separate credentials for different contexts.\n\nDirect Integration Pattern\n\nPattern: Resource uses an integration tool.\n\nUse direct integration tools when an agent or workflow performs frequent operations against a provider.\n\nCharacteristics:\n\n- Tools are always available to the resource.\n- There is no additional navigation overhead.\n- The pattern is optimized for frequent read-heavy operations.\n\nTool factory location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories use createIntegrationTool() with a credentialName parameter. Example: createAttioCreateRecordTool(credentialName).\n\nIntegration Workflow Pattern\n\nPattern: Agent invokes a workflow, and the workflow uses integrations.\n\nUse an integration workflow for complex multi-step operations that need deterministic orchestration.\n\nExample lead capture flow:\n\n1. Webhook trigger receives the event.\n2. Workflow creates an Attio contact.\n3. Workflow sends a Gmail notification.\n4. Workflow returns confirmation.\n\nCharacteristics:\n\n- Deterministic execution order.\n- Step-level error handling and retry.\n- Multiple integrations coordinated in one place.\n- Built-in audit trail through workflow execution.\n\nShared Integration Pattern\n\nPattern: Multiple resources share the same integration.\n\nUse shared integrations for organization-wide providers that should use one credential set.\n\nExample:\n\ntext\npackages/elevasis-operations/src/index.ts\n\nCharacteristics:\n\n- One credential per integration.\n- Centralized credential management.\n- Shared across agents and workflows.\n\nMulti-Account Pattern\n\nPattern: Same provider, different credentials.\n\nUse this pattern for department-specific provider instances or separate dev/prod environments.\n\nExample:\n\ntypescript\nconst salesTool = createAttioCreateRecordTool('attio-sales')\nconst supportTool = createAttioCreateRecordTool('attio-support')\n\nDisambiguate multi-account tools with explicit tool names:\n\ntypescript\nconst tool = createAttioToolNamed(\n  'attiosalescreaterecord',\n  'attio-sales',\n  'createRecord'\n)\n\nAuthentication Patterns\n\nOAuth 2.0 vs API Key\n\n| Aspect | OAuth 2.0 | API key |\n| --- | --- | --- |\n| Auth flow | Browser redirect plus token exchange | Direct API key |\n| Setup complexity | High: client ID, secret, redirect URL | Low: single API key |\n| Token refresh | Automatic refresh token rotation | Manual key rotation |\n| Scope control | Granular permission scopes | Full access or none |\n| User context | Per-user authorization | Service-level access |\n| Revocation | User can revoke anytime | Manual key deletion |\n\nOAuth 2.0 Pattern\n\nProviders include Gmail and Google Sheets.\n\nCredential format:\n\ntypescript\ninterface OAuthToken {\n  provider: string\n  accessToken: string\n  refreshToken: string\n  expiresAt: string\n  tokenType: 'Bearer'\n  scope?: string\n}\n\nexpiresAt is an ISO 8601 timestamp. The platform handles token refresh when supported by the provider and credential implementation.\n\nAPI Key Pattern\n\nProviders include Attio and custom APIs.\n\nCredential format:\n\ntypescript\ninterface APIKeyCredentials {\n  apiKey: string\n}\n\nProvider-specific validation belongs in the adapter. For Attio, see:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/attio/attio-adapter.ts\n\nCredential Management\n\nCredentials are stored in the credentials table.\n\nKey columns:\n\n- organizationid for tenant isolation.\n- name, such as elevasis-attio.\n- provider, such as gmail or attio.\n- encryptedvalue containing encrypted JSON.\n\nSecurity rules:\n\n- RLS policies enforce tenant isolation.\n- Values are encrypted at rest.\n- Credentials do not cross organization boundaries.\n\nBest practices:\n\n- Store credentials encrypted in the database.\n- Use tenant-isolated credential names.\n- Validate credentials before API calls.\n- Rotate API keys regularly.\n- Use least-privilege OAuth scopes.\n\nDo not:\n\n- Hardcode credentials in code.\n- Share credentials across organizations.\n- Log credential values.\n- Store provider API keys in environment variables for tenant integrations.\n- Reuse the same credential name for dev and prod.\n\nCredential resolution flow:\n\n1. Tool requests a credential by name.\n2. Platform queries credentials with the current organizationid.\n3. Platform decrypts the credential.\n4. Adapter validates the credential against the provider schema.\n5. Tool passes the credential to the provider adapter.\n6. Usage is logged without credential values.\n\nImplementation reference:\n\ntext\npackages/core/src/execution/engine/tools/integration/tool.ts\n\nError Handling Patterns\n\nAdapters should convert provider errors into platform tooling errors.\n\nCommon error categories:\n\n- credentialsinvalid for invalid or missing credentials.\n- apierror for provider API errors.\n- networkerror for network or timeout failures.\n- validationerror for invalid parameters.\n- methodnotfound for unknown adapter methods.\n\nRetry strategy:\n\n- Network errors: retry with exponential backoff, commonly 1, 2, and 4 seconds.\n- Auth errors: fail immediately because the credential needs attention.\n- Validation errors: fail immediately because the input needs correction.\n- Rate limits: retry after reset when the provider exposes a reset time.\n- Workflow-level retries: commonly 3 attempts with 1, 4, and 9 minute delays.\n\nAdapter Development\n\nAdapter class location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-adapter.ts\n\nAdapter classes implement BaseIntegrationAdapter and contain call() and validateCredentials() methods.\n\nTool factory location:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/{provider}-tools.ts\n\nTool factories export create{Provider}{Operation}Tool(credentialName) functions.\n\nTests belong under:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/adapters/{provider}/tests/\n\nRegistration happens in:\n\ntext\npackages/core/src/execution/engine/tools/integration/server/index.ts\n\nTesting Strategies\n\nUnit testing:\n\n- Mock external APIs.\n- Cover credential validation.\n- Cover API call construction.\n- Cover response parsing.\n- Cover error handling.\n\nIntegration testing:\n\n- Use real API calls only with test accounts or test workspaces.\n- Clean up test data after tests.\n- Run in CI only when secret credentials are available.\n- Keep provider behavior mocked in unit tests.\n\nAgent testing:\n\n- Test agents using integration tools at the resource boundary.\n- Tenant project agent tests normally live under external/{org}/src/agents/{agent}/tests/.\n\nRelated References\n\n- /knowledge read knowledge.platform-composition-patterns\n- /knowledge read knowledge.platform-command-view\n- /knowledge read knowledge.platform-capabilities"
-  },
-  {
-    id: "knowledge.what-is-elevasis",
-    title: "What is Elevasis",
-    summary: "Company overview, positioning, value proposition, and pricing for the AI orchestration platform",
-    bodyText: 'Executive Summary\n\nCompany: Bootstrapped AI orchestration platform for done-for-you business automation\n\nFounder: Solo (Alex, 34), bootstrapped\n\nMarket: Service-based SMBs that need practical AI automation without building internal AI teams\n\nGTM: Content-led marketing, proof assets, consultative sales, and land-and-expand pricing\n\nCompany Overview\n\nCurrent Status\n\nThe platform core is production-ready enough to support client-facing demonstrations and implementation work. Current business focus is client acquisition, proof-building, and turning the platform into a repeatable service delivery system.\n\nFounder Profile\n\nAlex, 34 \u2014 Solo founder with software engineering background (BSCS degree). Previous: Ecommerce platforms, Streaming technology. No formal AI background \u2014 practitioner, not academic.\n\nWhat We Are\n\nOperating layer for AI automation. We help SMBs operate with closed-loop feedback, decision capture, and continuous learning \u2014 at SMB pricing with done-for-you implementation (NOT self-service).\n\nTarget Market\n\nICP: Service-based SMBs (2-50 employees, USA, $200K-$5M revenue)\n\nCore Pain: Capacity crisis, pipeline problems, operational chaos, growth blockers \u2014 too busy serving clients to grow their own business.\n\nPricing (Land-and-Expand)\n\n- Tier 1 \u2014 Foundation (1-2 workflows): $500-2k/mo\n- Tier 2 \u2014 Scaled Operations (3-5 workflows): $2k-5k/mo\n- Tier 3 \u2014 AI-Powered Systems (6+ workflows): $5k-15k+/mo\n\nAdditional workflows cost less due to shared infrastructure.\n\nValue Proposition\n\n"We find one bottleneck in your business, build an AI solution to fix it, and you only pay if it actually saves you time or makes you money."'
-  },
-  {
-    id: "knowledge.platform-capabilities",
-    title: "Platform Capabilities",
-    summary: "Authoritative overview of the Elevasis AI Orchestration Platform \u2014 what's built, what it does, and how the pieces fit together",
-    bodyText: "Overview\n\nElevasis is a production AI orchestration platform that coordinates workflows, autonomous agents, and human approvals into a unified operating layer for SMBs. Everything described below is implemented and running in production.\n\nCore Architecture:\n\n| Layer | What It Does | Key Components |\n| --- | --- | --- |\n| Execution | Runs workflows and agents with schema validation | Workflow Engine, Agent Framework, Execution Runner |\n| Control | Human oversight, approvals, and decision capture | Command Queue (HITL), Dynamic Forms, Action System |\n| Intelligence | Autonomous reasoning, tool use, and memory management | ReAct Agents, Knowledge Map, Session Memory |\n| Observability | Real-time visibility into cost, performance, and health | Cost Tracking, Metrics, Activity Log, SSE Streaming |\n| Platform | Multi-tenancy, security, scheduling, integrations | Registry, RLS, Scheduler, Credential Vault, SDK |\n\nExecution Engine\n\nAI Workflows\n\nGraph-based workflow execution with schema-validated steps and conditional routing. Steps define explicit routing: linear, conditional (rule-based branching), or terminal. Context flows through the entire workflow.\n\nAutonomous Agents\n\nProduction-grade ReAct-style agents with tool use, memory management, and security hardening.\n\nLLM Provider Support: OpenAI (GPT-5), Google (Gemini 3 Flash), Anthropic (Claude Sonnet 4.5), OpenRouter (GLM-5)\n\nHuman-in-the-Loop (HITL)\n\nThe Command Queue surfaces pending approvals as structured tasks. Admin reviews, approves or edits, and the workflow continues. Every critical decision \u2014 sending emails to prospects, updating customer records, publishing content \u2014 requires human approval.\n\nKnowledge Map\n\nOrganizational knowledge loaded lazily into agent context. 80-95% token savings vs. always-loading full context. Nodes link to features, teams, and other nodes.\n\nIntegrations (13 active)\n\nAttio CRM, Cal.com, Instantly (cold email), Resend, Apify, Google Maps, Tomba, Mails.so, Supabase, Stripe, OpenAI, Google Gemini, Anthropic Claude.\n\nSDK\n\nTypeScript-based resource development with local testing, validation, and deployment pipeline. External consumers define workflows and agents in their own repos and deploy via elevasis-sdk deploy."
-  },
-  {
-    id: "knowledge.client-testimonials",
-    title: "Testimonials",
-    summary: "Customer testimonials and case study permissions from previous client work",
-    bodyText: `Status: 4 testimonials from 2 clients | Source: Upwork client work (2024)
-
-Testimonials
-
-Xero Automation \u2014 The Invoice Chase That Disappeared
-
-Client: Word of Mouth Agency
-
-Result: 10+ hours/week saved. Zero manual follow-up emails.
-
-> "Working with Alex at Elevasis to automate our Xero follow-ups has been a game-changer. We're set to save over 5 hours a week, but more importantly, it has completely removed the stress of chasing invoices. The process was smooth and professional."
-
-Permission: Case study approved with company name.
-
-Influencer Discovery \u2014 From Spreadsheet Hell to Strategic Decisions
-
-Client: Word of Mouth Agency (Perth, Australia)
-
-Result: 10+ hours/week saved. Research scope: 50 to 200+ influencers. Team focus shifted from data to strategy.
-
-> "Working with Alex at Elevasis to automate our Influencer Discovery has been a game-changer. We're set to save over 5 hours a week..."
-
-Permission: Case study approved with company name.
-
-EMRG Media \u2014 4 Automations for NYC's Premier Events Firm
-
-Client: EMRG Media (NYC, est. 2001). Clients include Google, YouTube, Sony Music, Fiverr, Equinox.
-
-What We Built:
-1. Case Study Generator \u2014 7-10 hours \u2192 2 hours. Publication rate: 1/quarter \u2192 2/month.
-2. EMRG Follow-Up Generator \u2014 Automated post-event follow-ups with signature management.
-3. Event Sponsor Tracker \u2014 Automated sponsor pipeline tracking and communications.
-4. Lead Scraper \u2014 Automated discovery of event planning prospects.
-
-Fame Stats:
-- 3,500+ attendees at The Event Planner Expo
-- 25+ year track record
-- Fortune 500 client roster
-
-Permission: Case study approved with company name.`
-  },
-  {
-    id: "knowledge.understanding-elevasis",
-    title: "Understanding Elevasis Overview",
-    summary: "Company overview, product positioning, and platform capability context for Elevasis AI orchestration platform",
-    bodyText: "Lean documentation explaining what Elevasis is and what the platform can do. This section provides the foundational context for business conversations and technical evaluation.\n\nElevasis is a done-for-you AI automation service backed by a production-grade platform. The company targets service-based SMBs (2-50 employees, $200K-$5M revenue) who are too busy serving clients to grow their own business.\n\nKey Facts\n\n- Stage: Pre-revenue, platform 100% complete, client acquisition active\n- Offer: Done-for-you AI automation -- we build and maintain the workflows, no coding required\n- ICP: Service-based SMBs (2-50 employees, $200K-$5M revenue, USA)\n- Pricing: $500-$2k/mo (Foundation) \u2192 $2k-$5k/mo (Scaled) \u2192 $5k-$15k+/mo (AI-Powered)\n- Market: Early Adopters stage, $23.77B TAM growing to $87.7B by 2032\n- Competitive position: No dominant done-for-you SMB AI provider exists; blue ocean\n\nWhen to Use Each Document\n\n| Situation | Document |\n| --- | --- |\n| First conversation with any audience | What is Elevasis |\n| Technical evaluation or demo prep | Platform Capabilities |\n\nDocumentation\n\n- What is Elevasis \u2014 AI orchestration platform overview, company stage, value proposition, and pricing tiers\n- Platform Capabilities \u2014 Authoritative overview of what is built, what it does, and how the pieces fit together"
-  },
-  {
-    id: "knowledge.marketing-overview",
-    title: "Marketing Overview",
-    summary: "Marketing documentation for Elevasis - strategy, website infrastructure, and content systems",
-    bodyText: "Welcome to the Elevasis marketing documentation. This section covers marketing strategy, website implementation, and content systems.\n\nDocumentation\n\nStrategy\n\n- Overview \u2014 Channel strategy, inbound content system, and proof-led demand generation\n\nWebsite\n\nThe marketing website's technical infrastructure, setup, and SEO docs now live under Architecture \u2192 Website."
-  },
-  {
-    id: "knowledge.ai-orchestration-principles",
-    title: "AI Orchestration Principles",
-    summary: "The 4 principles that separate production AI from toy automation",
-    bodyText: `Most AI automation fails. Not because the technology is bad, but because it's implemented without the principles that make AI systems work in production.
-
-These four principles separate toy automation from AI systems that actually run businesses.
-
-The 4 Principles
-
-1. Integrated: Works With Your Existing Systems
-
-Principle: AI must work with your existing tools, not replace them.
-
-AI that doesn't connect to your CRM, your email, your calendar, your existing workflows is a toy. Real AI automation works WITH what you already have \u2014 not instead of it.
-
-- Your 50 Zapier workflows keep running
-- Your CRM stays your CRM
-- AI adds intelligence on top, not a rip-and-replace
-
-The anti-pattern: "Use our AI instead of everything else." Creates vendor lock-in and throws away your existing investment.
-
-2. Improving: Gets Smarter Over Time
-
-Principle: AI must learn from every decision and improve continuously.
-
-Static automation is just fancy if-then logic. Real AI captures every approval, rejection, and edit \u2014 then uses that data to get smarter.
-
-The anti-pattern: "Set it and forget it." Systems that don't learn stay dumb forever.
-
-3. Observable: You See What AI Is Doing
-
-Principle: You must be able to see what AI systems are doing in real-time.
-
-Black-box automation is unacceptable for business operations. You need to see every action, every decision, every cost \u2014 as it happens.
-
-- Real-time activity feeds showing what's executing
-- Cost tracking per workflow, per execution
-- Token usage visibility
-- Execution logs for debugging
-
-The anti-pattern: "It just works, trust us." Systems without observability create anxiety and prevent adoption.
-
-4. Governed: Humans Control What Matters
-
-Principle: Humans must approve important actions before execution.
-
-AI should handle the grunt work. But critical decisions \u2014 sending emails to prospects, updating customer records, publishing content \u2014 require human approval.
-
-- AI researches 50 prospects and drafts personalized emails
-- Before anything sends, it lands in your approval queue
-- You spend 10 minutes reviewing, approve or tweak
-- Only then does it execute
-
-The anti-pattern: "Fully autonomous AI." Systems without governance create risk and erode trust.`
   }
 ];
 function buildSearchIndex(entries) {

package/dist/{chunk-X2SUMO3P.js → chunk-P55BJZZW.js}

@@ -381,7 +381,8 @@ var isOverviewLink = (label, link) => {
 var SubLinkItem = ({ linkItem, currentPath }) => {
   const { Link } = useRouterContext();
   const isKnowledgeBaseActive = linkItem.link === "/knowledge" && currentPath.startsWith("/knowledge") && !currentPath.startsWith("/knowledge/command-view");
-  const isActive = isKnowledgeBaseActive ? true : linkItem.exact || isOverviewLink(linkItem.label, linkItem.link) ? currentPath === linkItem.link : isPathActive(linkItem.link, currentPath);
+  const matchesExtraPath = linkItem.activeMatchPaths?.some((path) => isPathActive(path, currentPath)) ?? false;
+  const isActive = isKnowledgeBaseActive ? true : linkItem.exact || isOverviewLink(linkItem.label, linkItem.link) ? currentPath === linkItem.link || matchesExtraPath : isPathActive(linkItem.link, currentPath) || matchesExtraPath;
   const activeColor2 = "var(--color-primary)";
   const activeColorBg = "color-mix(in srgb, var(--color-primary) 10%, transparent)";
   const defaultColor = "var(--color-text-subtle)";

package/dist/{chunk-4FZYEEPK.js → chunk-Q6OYNEGR.js}

@@ -1,14 +1,14 @@
 import { ZodFormRenderer } from './chunk-3MEXPLWT.js';
 import { ResourceHealthChart } from './chunk-LGKLC5MG.js';
-import { HeroStatsRow } from './chunk-2DIYILF7.js';
+import { HeroStatsRow } from './chunk-542WPQU2.js';
 import { useCyberColors } from './chunk-CW3UNAF2.js';
 import { AppShellCenteredContainer, AppShellLoader } from './chunk-RYTEQBAO.js';
 import { Graph_module_css_default, useDirectedChainHighlighting, useNodeSelection, useFitViewTrigger } from './chunk-22UVE3RA.js';
 import { STATUS_COLORS, getStatusIcon, formatDuration, getStatusColors, AGENT_CONSTANTS, shouldAnimateEdge, TIMELINE_CONSTANTS, calculateBarPosition, CONTAINER_CONSTANTS, useExecutionPath, useUnifiedWorkflowLayout, WORKFLOW_CONSTANTS, useReactFlowAgent } from './chunk-E4WQGJNS.js';
-import { useExecuteResource, useDashboardMetrics, useResources, useTimeRangeDates, useUnresolvedErrors, useRecentExecutionsByResource, useCommandQueue, useScheduledTasks, useResourcesHealth } from './chunk-6EFVZV6X.js';
-import { glassBase } from './chunk-T5Z7G2J2.js';
-import { GlowDot, CardHeader, EmptyState, PageTitleCaption, TabCountBadge } from './chunk-6WXDE5LZ.js';
-import { formatTimeAgo, getTimeRangeDates, formatRelativeTime } from './chunk-HXZQWMKE.js';
+import { useExecuteResource, useDashboardMetrics, useResources, useTimeRangeDates, useUnresolvedErrors, useRecentExecutionsByResource, useCommandQueue, useScheduledTasks, useResourcesHealth } from './chunk-JKSUN5GN.js';
+import { glassBase } from './chunk-3BAPR3KA.js';
+import { GlowDot, CardHeader, EmptyState, PageTitleCaption, TabCountBadge } from './chunk-L3BVJWML.js';
+import { formatTimeAgo, getTimeRangeDates, formatRelativeTime } from './chunk-XQHZBA65.js';
 import { ResourceStatusColors } from './chunk-KRWALB24.js';
 import { useInitialization } from './chunk-533DUEQY.js';
 import { memo, useMemo, useEffect, useState, useCallback, Fragment } from 'react';

package/dist/{chunk-4SY6BTVZ.js → chunk-QDEETKYT.js}

@@ -1,5 +1,5 @@
-import { FeatureUnavailableState } from './chunk-6WXDE5LZ.js';
 import { useElevasisFeatures } from './chunk-6IXOKUBC.js';
+import { FeatureUnavailableState } from './chunk-L3BVJWML.js';
 import { SubshellContainer, SubshellSidebar, SubshellRightSideContainer } from './chunk-TKAYX2SP.js';
 import { useRouterContext } from './chunk-Q7DJKLEN.js';
 import { jsx, Fragment, jsxs } from 'react/jsx-runtime';
@@ -17,6 +17,9 @@ function FeatureShell({ children }) {
   }
   const SidebarComponent = routeMatch.feature.sidebar;
   const sidebarWidth = typeof routeMatch.feature.sidebarWidth === "function" ? routeMatch.feature.sidebarWidth({ currentPath }) : routeMatch.feature.sidebarWidth ?? defaultFeatureSidebarWidth;
+  if (sidebarWidth === 0) {
+    return /* @__PURE__ */ jsx(Fragment, { children });
+  }
   return /* @__PURE__ */ jsxs(SubshellContainer, { children: [
     /* @__PURE__ */ jsx(SubshellSidebar, { width: sidebarWidth, children: /* @__PURE__ */ jsx(SidebarComponent, {}) }),
     /* @__PURE__ */ jsx(SubshellRightSideContainer, { children })

package/dist/{chunk-IKQ42WHU.js → chunk-QHEWXU7I.js}

@@ -1,4 +1,4 @@
-import { usePresetsContext } from './chunk-T5Z7G2J2.js';
+import { usePresetsContext } from './chunk-3BAPR3KA.js';
 import { useMemo } from 'react';
 
 var BUILT_IN_NAMES = /* @__PURE__ */ new Set([