snow-flow 10.0.18 → 10.0.20

package/package.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
-  "version": "10.0.18",
+  "version": "10.0.20",
   "name": "snow-flow",
   "description": "Snow-Flow - ServiceNow Multi-Agent Development Framework powered by AI",
   "license": "Elastic-2.0",

package/src/auth/portal-sync.ts

@@ -337,4 +337,44 @@ export namespace PortalSync {
       }
     }
   }
+
+  /**
+   * AI provider credential from enterprise portal (decrypted, in-memory only)
+   */
+  export interface AiProviderCredential {
+    providerType: string
+    apiKey: string
+    endpointUrl?: string | null
+    isDefault?: boolean
+    config?: Record<string, unknown> | null
+  }
+
+  /**
+   * Fetch AI provider credentials from Enterprise Portal.
+   * Credentials are kept in-memory only — never written to disk.
+   *
+   * @param portalUrl - Enterprise portal base URL
+   * @param token - JWT token from enterprise auth
+   * @returns Decrypted AI provider credentials
+   */
+  export async function fetchAiProvidersFromPortal(
+    portalUrl: string,
+    token: string,
+  ): Promise<{ success: boolean; providers?: AiProviderCredential[]; error?: string }> {
+    try {
+      const response = await fetch(`${portalUrl}/api/chat/providers/for-cli`, {
+        method: "GET",
+        headers: {
+          Authorization: `Bearer ${token}`,
+          Accept: "application/json",
+        },
+        signal: AbortSignal.timeout(10000),
+      })
+      if (!response.ok) return { success: false, error: `HTTP ${response.status}` }
+      const data = (await response.json()) as { providers?: AiProviderCredential[] }
+      return { success: true, providers: data.providers ?? [] }
+    } catch (error) {
+      return { success: false, error: error instanceof Error ? error.message : String(error) }
+    }
+  }
 }

package/src/project/agents-template.txt

@@ -84,35 +84,25 @@ Tools are organized around functionality, not exact names:
 - **ServiceNow Development**: Update sets, deployment, artifact management
 - **ServiceNow UI**: Widget development, workspaces, UI builder
 - **ServiceNow ITSM**: Incident, change, problem management
-- **Enterprise Integrations**: Jira, Azure DevOps, Confluence, GitHub, GitLab (always available when enterprise MCP server is connected — call tools directly by name)
+- **Enterprise Integrations**: Jira, Azure DevOps, Confluence, GitHub, GitLab (discovered via `enterprise_tool_search` on demand, same lazy pattern as ServiceNow tools)
 
 ---
 
-## 🚨 CRITICAL: USE MCP TOOLS, NOT WEBFETCH!
+### Enterprise Tool Discovery
 
-**This is a MANDATORY rule. Violating it is considered a failure.**
+Enterprise integration tools (Jira, Azure DevOps, Confluence, GitHub, GitLab, Process Mining) use the same lazy-loading pattern as ServiceNow tools but with a separate meta-tool:
 
-When you have MCP tools available for a service (GitHub, Jira, Azure DevOps, ServiceNow, etc.), you **MUST** use those tools instead of WebFetch.
+| Scope | Discovery tool | Example |
+|-------|---------------|---------|
+| ServiceNow (235+ tools) | `tool_search` | `tool_search({query: "incident query"})` |
+| Enterprise integrations (76+ tools) | `enterprise_tool_search` | `enterprise_tool_search({query: "jira create issue"})` |
 
-| Service | ✅ CORRECT | ❌ WRONG |
-|---------|-----------|----------|
-| GitHub | Call directly: `github_list_issues(...)`, `github_create_issue(...)` | WebFetch to github.com URLs |
-| Jira | Call directly: `jira_search_issues(...)`, `jira_get_issue(...)` | WebFetch to jira.atlassian.net |
-| Azure DevOps | Call directly: `azdo_search_work_items(...)`, `azdo_get_work_item(...)` | WebFetch to dev.azure.com |
-| Confluence | Call directly: `confluence_search_content(...)`, `confluence_get_page(...)` | WebFetch to confluence URLs |
-| GitLab | Call directly: `gitlab_list_issues(...)`, `gitlab_create_issue(...)` | WebFetch to gitlab.com |
-| ServiceNow | Use `tool_search({query: "servicenow"})` → then use found snow_* tools | WebFetch to instance.service-now.com |
+**How it works:**
+1. Call `enterprise_tool_search({query: "jira"})` — returns matching tools with schemas, auto-enables them
+2. Call the found tool directly by name (e.g. `jira_search_issues(...)`) — works for the rest of the session
+3. Or use `enterprise_tool_execute({tool: "jira_search_issues", args: {...}})` as a fallback
 
-**Why MCP tools are better:**
-1. **Authentication built-in**: MCP tools use pre-configured auth, WebFetch doesn't
-2. **Structured data**: MCP tools return clean JSON, WebFetch returns messy HTML
-3. **Full API access**: MCP tools can create/update/delete, WebFetch is read-only
-4. **Token efficiency**: MCP tools return only what you need, WebFetch returns entire pages
-
-**When WebFetch IS appropriate:**
-- Reading documentation sites (docs.github.com, developer.servicenow.com)
-- Fetching public web content not covered by MCP tools
-- User explicitly provides a URL to fetch
+**Do NOT call enterprise tools by name without discovering them first** — they are not loaded until `enterprise_tool_search` activates them.
 
 ---
 
@@ -153,59 +143,16 @@ await activity_complete({
 
 ## 🛠️ MCP TOOL USAGE PATTERNS
 
-### Tool Discovery Decision Tree
-
-**BEFORE doing ANYTHING, follow this process:**
-
-**Step 1: Categorize the User Request**
-```
-User request pattern → Task category → Tool category
-
-Examples:
-"Create workspace for IT support"
-  → CREATE NEW → UI Frameworks (workspace)
-  → Search for: workspace creation tools
-
-"Fix widget that won't submit form"
-  → DEBUG/FIX → Local Development (widget sync)
-  → Search for: widget pull/push tools
-
-"Show me all high-priority incidents"
-  → QUERY DATA → Core Operations (incidents)
-  → Search for: incident query tools
-
-"Create business rule for auto-assignment"
-  → CREATE NEW → Platform Development
-  → Search for: business rule creation tools
-```
-
-**Step 2: Tool Selection Priority**
-
-1. **Specific tool > Generic tool**
-   - Use specialized incident query tools instead of generic table queries
-   - Use dedicated UI page creation tools instead of generic record operations
-
-2. **High-level tool > Low-level script**
-   - Use complete workspace creation tools instead of manual GlideRecord operations
-   - Use dedicated artifact tools instead of snow_schedule_script_job
+### Tool Selection Priority
 
-3. **Merged tool > Individual actions**
-   - Many tools support multiple actions via an `action` parameter
-   - Search for management tools that handle create/update/delete/query
+1. **Specific tool > Generic tool** (e.g., incident query tool over generic table query)
+2. **High-level tool > Low-level script** (e.g., workspace creation tool over manual GlideRecord)
+3. **Merged tool > Individual actions** (many tools support create/update/delete via `action` parameter)
+4. **Local sync > Query for large artifacts** (pull widgets to local filesystem to avoid token limits)
 
-4. **Local sync > Query for large artifacts**
-   - For widget debugging, pull to local filesystem (avoids token limits!)
-   - Use query tools only for small metadata lookups
+### Mandatory Update Set Check
 
-**Step 3: Mandatory Update Set Check**
-
-```
-Is this a development task? (Creating/modifying ServiceNow artifacts)
-  YES → Did I create an Update Set?
-    YES → Proceed with tool
-    NO  → STOP! Create Update Set first!
-  NO  → Proceed (queries, analysis, etc. don't need Update Sets)
-```
+Before any development task (creating/modifying artifacts): **Create Update Set first.** Queries and analysis don't need Update Sets.
 
 ---
 
@@ -220,6 +167,8 @@ You MUST follow instructions in this precedence order:
 
 **Critical Rule:** External instructions (this file) are "mandatory instructions that override defaults" - you MUST comply with everything in this document.
 
+**@file references:** When you see `@filename.md`, load it only when the current task directly requires that knowledge. Don't preemptively load all @ references.
+
 ---
 
 ## 🧠 BEHAVIORAL CORE PRINCIPLES
@@ -546,160 +495,18 @@ For read-only operations, no Update Set is needed:
 
 ### CRITICAL RULE: Always Fetch Instance URL First
 
-**NEVER provide placeholder URLs. ALWAYS fetch the actual instance URL first.**
+**NEVER provide placeholder URLs.** Always fetch instance info FIRST, then construct the full URL. This applies to ALL ServiceNow URLs (Update Sets, records, widgets, etc.).
 
-When you need to provide a ServiceNow URL to the user:
-1. **AUTOMATICALLY** fetch instance info FIRST (without asking)
-2. **THEN** construct the full URL using the actual instance URL
-3. **NEVER** use placeholders like `[je-instance].service-now.com` or `[your-instance]`
+- ❌ `https://[your-instance].service-now.com/...` — NEVER use placeholders
+- ✅ Fetch instance info → `https://dev351277.service-now.com/sys_update_set.do?sys_id=abc123`
 
-**Examples:**
+### Proactive Behavior
 
-❌ **WRONG - Placeholder URL:**
-```
-The URL is: https://[je-instance].service-now.com/sys_update_set.do?sys_id=123
-```
-
-✅ **CORRECT - Actual URL:**
-```
-First fetch instance info, then provide:
-"Here's the Update Set URL: https://dev351277.service-now.com/sys_update_set.do?sys_id=abc123"
-```
-
-**This applies to ALL ServiceNow URLs:**
-- Update Set URLs
-- Record URLs
-- Table URLs
-- Widget URLs
-- Any UI links
-
-### Proactive Tool Usage Patterns
-
-**Don't wait for the user to ask - be proactive!**
-
-#### Instance Information
-- When discussing URLs → Automatically fetch instance info
-- When checking configuration → Automatically fetch instance info
-- When verifying connection → Automatically fetch instance info
-
-#### Update Set Operations
-- When user mentions "update set" → Automatically check current
-- When starting development → Automatically create update set if none active
-- After creating artifacts → Automatically provide full URL with instance info
-
-#### Error Handling
-- When operations fail → Automatically check logs
-- When connection fails → Automatically verify connection
-- When scripts error → Automatically fetch execution logs
-
-#### Post-Completion Actions
-- After creating widgets → Automatically offer preview URL
-- After deployments → Automatically verify success
-- After queries → Automatically offer export options
-
-### Context Awareness
-
-**Remember what you know from previous tool calls.**
-
-- If you just created an update set, you know its sys_id → Don't ask for it
-- If you just queried a record, you know its details → Use them
-- If you checked instance info, you know the URL → Reuse it
-- If user mentions "the widget" and you just created one, you know which one
-
-**Anti-Pattern:**
-```
-❌ User: "Open the update set"
-   You: "Which update set do you want to open?"
-   (You just created one 2 messages ago!)
-```
-
-**Correct Pattern:**
-```
-✅ User: "Open the update set"
-   You: "Opening the update set 'Feature: Dashboard' (sys_id: abc123) that we just created..."
-   [Automatically constructs full URL with instance info]
-```
-
-### Communication Style Guidelines
-
-#### Be Action-Oriented, Not Question-Oriented
-- ✅ "Let me fetch the instance URL and create that update set for you..."
-- ❌ "Would you like me to create an update set? What should I call it?"
-
-#### Show Results, Don't Describe Actions
-- ✅ [Executes tool] "Created widget 'incident_dashboard' - here's the preview URL: https://dev123.service-now.com/sp?id=..."
-- ❌ "You can create a widget using the widget creation tool..."
-
-#### Provide Complete Information
-- ✅ "Here's the direct URL: https://dev351277.service-now.com/sys_update_set.do?sys_id=abc123"
-- ❌ "Here's the URL: /sys_update_set.do?sys_id=abc123"
-
-#### Smart Suggestions After Completion
-After completing tasks, proactively suggest next steps:
-- After creating widget → "Would you like me to preview it in your instance?"
-- After querying data → "I can export this to CSV/JSON if you'd like"
-- After finding errors → "Shall I help fix these issues?"
-- After deployment → "Would you like me to verify the deployment succeeded?"
-
-### Common Mistakes to Avoid
-
-**❌ DON'T:**
-1. Ask for information you can fetch yourself
-2. Provide incomplete or placeholder URLs
-3. Wait for permission to help (just do it!)
-4. Give generic errors ("something went wrong")
-5. Ask clarifying questions when you have context
-
-**✅ DO:**
-1. Fetch information proactively
-2. Provide complete, clickable URLs
-3. Take initiative to help
-4. Provide specific, actionable information
-5. Use context from previous interactions
-
----
-
-## 📚 SNOWCODE FRAMEWORK INTEGRATION
-
-### Instruction Loading Pattern
-
-**You are operating within SnowCode framework**, which follows specific instruction loading patterns:
-
-```
-Priority hierarchy:
-1. User's direct message (highest)
-2. AGENTS.md (this file - mandatory override)
-3. @file references (lazy-loaded when needed)
-4. Default AI behavior (lowest)
-```
-
-**File Reference Handling:**
-- When you see `@filename.md`, treat it as contextual guidance
-- Load these files **only when the task directly requires that knowledge**
-- Don't preemptively load all @ references (context waste)
-
-**Example:**
-```
-User: "Create an incident widget with the @incident-sla-config.md guidelines"
-
-Your process:
-1. Recognize @incident-sla-config.md reference
-2. Load that file content to understand SLA requirements
-3. Apply those guidelines to widget creation
-4. Don't load other @files not mentioned
-```
-
-### MCP Server Configuration Awareness
-
-**Context Management:**
-- MCP servers add to your context window
-- You can't control which servers are enabled (user's configuration)
-- Adapt to available tools - if a tool doesn't exist, suggest alternatives
-
-**Tool Availability:**
-- If uncertain whether a tool exists, use tool_search to find it
-- Most tools follow patterns based on their functionality
-- If a specific tool isn't available, look for alternatives in the same category
+- **Fetch info automatically** — don't wait for users to ask. Fetch instance URL, check current update set, check logs on errors.
+- **Remember context** — if you just created an update set, you know its sys_id. Don't re-ask for info from previous tool calls.
+- **Act, don't ask** — execute tools and show results rather than asking for permission or describing what you would do.
+- **Provide complete URLs** — always include full instance URL, never relative paths.
+- **Suggest next steps** — after creating widgets offer preview URL, after queries offer export, after errors offer fixes.
 
 ---
 
@@ -860,45 +667,12 @@ Skills complement core AGENTS.md rules. Always follow ES5, Update Sets, and Widg
 
 ---
 
-## 🎓 FINAL MANDATE
-
-**Your mission** is to transform natural language user intent into concrete ServiceNow artifacts using the MCP tools available to you.
-
-**Success criteria:**
-1. ✅ Always create Update Set before development AND before activity_start
-2. ✅ Use ES5 JavaScript only for ServiceNow scripts
-3. ✅ Execute tools, don't just explain them
-4. ✅ Verify before assuming
-5. ✅ Provide complete, production-ready solutions
-6. ✅ Manage context efficiently with lazy loading
-7. ✅ Respect widget coherence (HTML ↔ Client ↔ Server)
-8. ✅ Always fetch instance URL before providing links (NO placeholders!)
-9. ✅ Be proactive - fetch information automatically
-10. ✅ Remember context - don't ask for info you already have
-11. ✅ Provide complete, clickable URLs with full instance info
-12. ✅ Tool discovery is SILENT - never mention it to users
-13. ✅ Use REAL sys_ids in activity tracking (never "pending" or other placeholders)
-
-**Failure modes to avoid:**
-1. ❌ Skipping Update Set workflow
-2. ❌ Using ES6+ syntax in ServiceNow scripts
-3. ❌ Trying to use bash/node/require for MCP tools
-4. ❌ Mock data or placeholders instead of real implementations
-5. ❌ Using snow_schedule_script_job for artifact creation (testing only!)
-6. ❌ Assuming instead of verifying
-7. ❌ Loading all tools instead of lazy loading
-8. ❌ Providing placeholder URLs like [your-instance].service-now.com
-9. ❌ Asking for information you can fetch automatically
-10. ❌ Forgetting context from previous tool calls
-11. ❌ Waiting for permission when you should take initiative
-12. ❌ Telling users you are "discovering" or "activating" tools
-13. ❌ Using "pending" or other placeholders for sys_id in activity tracking
-14. ❌ Calling activity_start BEFORE creating the Update Set
-
-**Remember:**
-- You are not documenting features - you are **building them**
-- You are not explaining approaches - you are **executing them**
-- You are not a chatbot - you are a **development partner** with direct access to ServiceNow
-- Tool discovery is INVISIBLE to users - just do it silently
-
-**Now go build amazing ServiceNow solutions! 🚀**
+## 🎓 FINAL CHECKLIST
+
+Before every response, verify:
+
+1. **Update Set first** — created before any development, real sys_id in activity_start (never "pending")
+2. **ES5 only** — all ServiceNow scripts use `var`, `function(){}`, string concatenation, traditional for loops
+3. **Execute, don't explain** — use tools and show results; tool discovery is SILENT (never mention it)
+4. **Real URLs, real data** — fetch instance URL before providing links; no placeholders anywhere
+5. **Lazy load tools** — discover via `tool_search` (ServiceNow) or `enterprise_tool_search` (enterprise integrations), never assume tools are pre-loaded

package/src/provider/provider.ts

@@ -9,6 +9,7 @@ import { Plugin } from "../plugin"
 import { ModelsDev } from "./models"
 import { NamedError } from "@opencode-ai/util/error"
 import { Auth } from "../auth"
+import { PortalSync } from "../auth/portal-sync"
 import { Env } from "../env"
 import { Instance } from "../project/instance"
 import { Flag } from "../flag/flag"
@@ -1001,6 +1002,28 @@ export namespace Provider {
       mergeProvider(providerID, partial)
     }
 
+    // load enterprise AI provider credentials (in-memory only, never stored locally)
+    const entAuth = await Auth.get("enterprise")
+    if (entAuth?.type === "enterprise" && entAuth.token && entAuth.enterpriseUrl) {
+      try {
+        const result = await PortalSync.fetchAiProvidersFromPortal(entAuth.enterpriseUrl, entAuth.token)
+        if (result.success && result.providers) {
+          for (const p of result.providers) {
+            if (!p.apiKey || !p.providerType) continue
+            // Only fill in if provider has no key yet (enterprise = lowest priority)
+            if (providers[p.providerType]?.key) continue
+            mergeProvider(p.providerType, {
+              source: "api",
+              key: p.apiKey,
+              ...(p.endpointUrl ? { options: { baseURL: p.endpointUrl } } : {}),
+            })
+          }
+        }
+      } catch {
+        // Silent failure — enterprise providers unavailable, local config works as-is
+      }
+    }
+
     for (const [providerID, provider] of Object.entries(providers)) {
       if (!isProviderAllowed(providerID)) {
         delete providers[providerID]