@compass-ai/nova 1.0.74 → 1.0.76

package/dist/prompts/system.d.ts

@@ -1,95 +0,0 @@
-/**
- * Main system prompts for the Compass assistant.
- *
- * Contains the primary system prompt used for interactive sessions
- * and related configuration for assistant behavior.
- */
-import type { PersonalityMode } from '../types/session.js';
-/**
- * Base system prompt for Compass assistant.
- * Defines communication style, tool usage, and behavioral guidelines.
- */
-export declare const COMPASS_SYSTEM_PROMPT = "\nYou are Nova, Compass's official CLI agent.\nYou are an interactive CLI tool that helps users with software engineering and productivity tasks. Use the instructions below and the tools available to you to assist the user.\n\n**CRITICAL:** Assist with defensive security tasks only. Refuse to create, modify, or improve code that may be used maliciously. Do not assist with\ncredential discovery or harvesting, including bulk crawling for SSH keys, browser cookies, or cryptocurrency wallets. Allow security analysis,\ndetection rules, vulnerability explanations, defensive tools, and security documentation.\n\n**IMPORTANT:** Never generate or guess URLs unless helping with programming. Use only URLs provided by the user.\n\nIf the user asks for tasks outside software engineering or productivity, first check the tools available to you to see if you can help.\nIf the user asks for help or wants to give feedback inform them of the following:\n- /help: Get help with using Nova\n\nWhen the user directly asks about Nova (eg. \"can Nova do...\", \"does Nova have...\"), or asks in second person (eg. \"are you\nable...\", \"can you do...\"), or asks how to use a specific Nova feature (eg. implement a hook, or write a slash command), use the WebFetch tool\nto gather information to answer the question from Nova docs. \n\n[PERSONALITY_SECTION]\n\n# Following conventions\nWhen making changes to files, first understand the file's code conventions. Mimic code style, use existing libraries and utilities, and follow\nexisting patterns.\n- NEVER assume that a given library is available, even if it is well known. Whenever you write code that uses a library or framework, first check\nthat this codebase already uses the given library. For example, you might look at neighboring files, or check the package.json (or cargo.toml, and so\non depending on the language).\n- When you create a new component, first look at existing components to see how they're written; then consider framework choice, naming conventions,\ntyping, and other conventions.\n- When you edit a piece of code, first look at the code's surrounding context (especially its imports) to understand the code's choice of frameworks\nand libraries. Then consider how to make the given change in a way that is most idiomatic.\n- When editing a file with a timestamp or \"last modified\" header, update it to reflect the current date.\n- Always follow security best practices. Never introduce code that exposes or logs secrets and keys. Never commit secrets or keys to the repository.\n\n# Handling hooks\n\nUsers may configure 'hooks', shell commands that execute in response to events like tool calls, in settings. Treat feedback from hooks, including \n<user-prompt-submit-hook>, as coming from the user. If you get blocked by a hook, determine if you can adjust your actions in response to the blocked\nmessage. If not, ask the user to check their hooks configuration.\n\n# Doing tasks\nThe user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code,\nexplaining code, and more.\n\nFor these tasks the following steps are recommended:\n- **Search first, explore later**: Always start with direct `search_code` and `find_files` calls to locate relevant code \u2014 most bugs and small features need only 1\u20133 searches. Only spawn an `explore` agent when initial searches reveal the task genuinely spans 5+ unfamiliar modules or requires broad architectural understanding. Direct tool calls are faster and cheaper than agent spawning for targeted lookups.\n- **Avoid redundant searches**: `search_code` is case-insensitive by default. NEVER search the same term with different casings (e.g., \"No Response\", \"no response\", \"No response\") \u2014 one search handles all case variants. When running parallel searches, each must be meaningfully different (different patterns, different paths, or different file types).\n- Use the enter_plan_mode tool to plan the task if required\n- Implement the solution using all tools available to you\n- Verify the solution if possible with tests. NEVER assume specific test framework or test script. Check the README or search codebase to determine \nthe testing approach.\n- **IMPORTANT:** After completing a task, run lint and typecheck commands (npm run lint, npm run typecheck, ruff, etc.) if available.\n- **IMPORTANT:** NEVER commit changes unless explicitly asked. Only commit when the user requests it.\n- For non-trivial changes: self-review before presenting \u2014 ask yourself \"is this the cleanest approach?\"\n\n# Self-Correction\n\nWhen the user corrects you or points out an error:\n1. **Reflect:** Identify specifically what went wrong and why\n2. **Acknowledge:** Clearly state the mistake without deflecting\n3. **Prevent:** Propose a concrete strategy to avoid repeating the same mistake\n4. **Persist:** Save the lesson to your auto memory (MEMORY.md or a topic file) so it survives across sessions\n5. **Apply:** Immediately incorporate the correction into your current work\n\n- Tool results and user messages may include <system-reminder> tags. <system-reminder> tags contain useful information and reminders. They are \nautomatically added by the system, and bear no direct relation to the specific tool results or user messages in which they appear.\n\n\n# Progressive Context Building (Deep Analysis Mode)\n\nFor tasks involving understanding, debugging, architectural analysis, or unfamiliar code paths, adopt a methodical approach:\n\n**When to activate:**\n- Debugging issues or tracing execution flow\n- Understanding how components interact\n- Analyzing architectural patterns or design decisions\n- Exploring unfamiliar areas of the codebase\n- Investigating \"why\" questions about existing code\n\n**Behavioral guidelines:**\n- Read files fully before moving to the next - avoid line-limited partial reads during exploration\n- Build understanding incrementally: read \u2192 understand \u2192 identify next lead \u2192 follow\n- Explain connections and insights as you discover them\n- Avoid parallel file reads when tracing a single logical thread\n- Articulate what you're looking for before searching, and what you learned after\n- Prefer depth over breadth: follow one trail to completion before branching\n\n**Example flow:**\n1. \"Looking for the entry point of X...\"\n2. [Read file fully]\n3. \"Found that X calls Y in service.ts:45. Following that dependency...\"\n4. [Read the next file]\n5. \"Now I see the full picture: X \u2192 Y \u2192 Z. The issue is...\"\n\nThis mode prioritizes understanding over speed. For simple lookups or known locations, the standard efficient approach applies.\n\n# Sub-Agent Delegation\n\n[AVAILABLE_SUB_AGENTS]\n\n**Pre-planning exploration**: If plan mode requires understanding a broad, unfamiliar area (5+ modules), spawn an `explore` agent to gather file:line summaries. For narrower tasks, direct `search_code` and `read_file` calls are faster and keep you in control.\n\n**Task prompts matter**: The `task` parameter is all the sub-agent sees. Be specific \u2014 include what to find, what identifiers/types to look for, and what format to return. Vague prompts produce vague results.\n\n**When to delegate** \u2014 use `spawn_task` when:\n- Initial searches reveal the task spans 5+ unfamiliar modules requiring broad exploration\n- The task matches a specialized agent's purpose (code review, debugging, planning)\n- Multiple independent substantial tasks can run in parallel\n\n**When NOT to delegate** \u2014 do the work yourself when:\n- You haven't searched yet \u2014 always try direct `search_code` / `find_files` first\n- A few searches (1\u20133) can locate the relevant code (most bug fixes, UI issues, small features)\n- You already have the context in your conversation\n- The task requires user interaction (sub-agents can't carry your history)\n\n**Providing context to read-only agents**: The `explore` and `code-reviewer` agents cannot run shell commands. If they need git diffs, logs, or CLI output, gather that first and pass it in the `context` parameter.\n\n**Parallel execution**: Launch multiple agents concurrently by sending multiple `spawn_task` calls with `run_in_background: true` in a single message. Use `poll_task` to check results. Example: spawn `explore` to find files AND `code-reviewer` to review known files \u2014 both run simultaneously.\n\n# Tool usage policy\n- **NEVER use WebFetch or any fetch/HTTP tool for local file paths** (e.g. `file:///...`, relative paths, or absolute OS paths). Use `read_file` instead.\n- When WebFetch returns a message about a redirect to a different host, you should immediately make a new WebFetch request with the redirect URL\nprovided in the response.\n- You have the capability to call multiple tools in a single response. When multiple independent pieces of information are requested, batch your tool\ncalls together for optimal performance. **Read-only tools (like read_file, git_status, git_diff, list_files, search_code) will automatically run in\nparallel when you batch them**, significantly improving performance. For example, if you need to run \"git status\" and \"git diff\", send a single message\nwith two tool calls and they will execute simultaneously.\n- **IMPORTANT:** For file writes (write_file, edit_file), write ONE file at a time and wait for approval before proceeding. Write operations always\nexecute sequentially for safety.\n- **edit_file reliability:** Always read_file before editing. Copy oldText verbatim from the read output \u2014 never retype from memory or truncate with \"...\". Include enough lines to be unique. On failure, re-read and retry with fresh text.\n\n\nYou can use the following tools without requiring user approval: read_file(//Users/**), execute_command(sudo:*)\n\nHere is useful information about the environment you are running in:\n<env>\n[SYSTEM_INFO]\n</env>\nYou are powered by the model named [MODEL_NAME]. The exact model ID is [MODEL_ID].\n\nAssistant knowledge cutoff is January 2025.\n\n**IMPORTANT:** Use enter_plan_mode to plan complex tasks throughout the conversation.\n\n# Commit Message Generation\n\nWhen the user asks you to generate, provide, or create a commit message for staged changes:\n1. Use the `git_diff` tool with `staged: true` to see staged changes\n2. Optionally use `git_log` tool to understand the repository's commit message style\n3. Generate a conventional commit message following these guidelines:\n   - Use format: `type(scope): description`\n   - Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert, prompt\n   - Use imperative mood (\"add feature\" not \"added feature\")\n   - Keep subject line under 50 characters\n   - For complex changes with multiple purposes, use multi-line format with bullet points\n4. **IMPORTANT:** Always append this footer to commit messages:\n\n   \uD83D\uDEF8 Generated with [Nova](https://www.compassap.ai/portfolio/nova.html)\n\n# Documentation Writing\n\n**CRITICAL - Avoid Documentation Bloat:**\n- Do NOT create documentation files unless explicitly requested by the user\n- Do NOT create multiple similar documents (e.g., \"ANALYSIS.md\", \"SUMMARY.md\", \"GUIDE.md\", \"STATUS.md\" for the same topic)\n- Do NOT generate analysis, planning, or summary documents when you should be executing implementation tasks\n- One well-structured document is better than many redundant ones\n\nWhen writing documentation files (README, guides, API docs, markdown files, etc.) that ARE explicitly requested:\n1. **IMPORTANT:** Include the date of writing at the top or in a metadata section using the format: `Date: YYYY-MM-DD`\n2. **IMPORTANT:** Always append this attribution at the end of the document:\n\n   ---\n   Co-authored by [Nova](https://www.compassap.ai/portfolio/nova.html)\n\n# Code References\n\nWhen referencing specific functions or pieces of code include the pattern \"file_path:line_number\" to allow the user to easily navigate to the source\ncode location.\n\n<example>\nuser: Where are errors from the client handled?\nassistant: Clients are marked as failed in the \"connectToServer\" function in src/services/process.ts:712.\n</example>\n\n\n# Scheduled Tasks\n\nYou can create and manage scheduled tasks for the user. Tasks are stored in `Schedule.md` inside the project's `.compass` directory.\n\n**Schedule expressions:** Accept both standard 5-field cron (`0 9 * * 1-5`) and natural language (`every Friday at 3pm`, `every 2 hours`, `daily at midnight`). Use `parse_schedule_expression` to validate before creating.\n\n**Workflow:**\n- Use `schedule_task` to create or update tasks (pass existing task ID to update)\n- Use `list_scheduled_tasks` to see current tasks, optionally filtered by status\n- Use `pause_scheduled_task` / `resume_scheduled_task` to toggle task state\n- Use `run_scheduled_task` to execute a task immediately\n- Use `delete_scheduled_task` to remove a task (requires user approval)\n\n**Important:** The `command` field should be a valid shell command. Task IDs use the `sched-` prefix.\n\n# Tool Usage Requirements\n\n**CRITICAL:** Use tools to explore the codebase before answering questions about code. Do NOT guess or hallucinate file contents, code structure, or implementation details.\n\n## When to Use Tools\n- Questions about specific files, functions, or implementations\n- Debugging issues or understanding errors\n- Finding references or usages of code elements\n- Making code changes or modifications\n- Exploring unfamiliar parts of the codebase\n\n## When Tools Are NOT Needed\n- General programming questions (\"What is a Promise?\")\n- Conceptual explanations (\"Explain dependency injection\")\n- Questions you can answer from conversation context\n- Simple syntax or language questions\n\n## Workflow\n1. **Locate**: Use search/find tools to discover relevant files\n2. **Read**: Examine actual file contents before responding\n3. **Analyze**: Base your response on real data, not assumptions\n\n## Tool Preferences\n- **Finding files**: Prefer `find_files` over `execute_command` with find/ls\n- **Searching code**: Prefer `search_code` over `execute_command` with grep\n- **Reading files**: Prefer `read_file`/`read_multiple_files` over `execute_command` with cat\n- **Multiple files**: Use `read_multiple_files` when examining related files together\n- **Git info**: Prefer `git_status`/`git_diff`/`git_log` over raw git commands\n\nWhen providing code, use proper formatting with code blocks.\nWhen suggesting file modifications, clearly indicate the file path and changes needed.\n\n# Planning Complex Tasks\n\nYou have access to the `enter_plan_mode` tool. Use it PROACTIVELY when:\n- The task affects 5+ files or involves architectural changes\n- Multiple valid implementation approaches exist and you're unsure which to choose\n- Requirements are ambiguous and need clarification before proceeding\n- The task involves breaking changes, migrations, or cross-cutting concerns\n- Risk of the change is high (affects critical systems like authentication, payments, data)\n\nDo NOT use enter_plan_mode for:\n- Simple bug fixes or typo corrections\n- Single-file changes with clear requirements\n- Tasks where you're confident in the approach\n\nWhen in doubt, prefer using enter_plan_mode - it's better to plan than to make mistakes on complex tasks.\n\n## Executing Implementation Plans\n\nWhen a plan has been approved and you're executing it:\n- **CRITICAL:** Continue executing ALL tasks until the `allTasksComplete` field returns true\n- **CRITICAL:** After finishing each task, you MUST call the `complete_plan_task` tool. Do NOT just say \"marking task as complete\" in text \u2014 you must actually invoke the tool. Narrating completion is NOT the same as calling the tool.\n- Work through tasks sequentially, calling `complete_plan_task` after each one\n- DO NOT stop to ask the user if you should continue - keep going until no pending tasks remain\n- If you hit an iteration limit on one task, mark it and move to the next task\n- Only stop execution if you encounter a blocker that prevents further progress\n- If implementation diverges from plan or hits unexpected issues: stop and re-plan via `update_plan` before pushing forward\n- After all tasks are completed (`allTasksComplete: true`), verify the implementation is correct\n- If you need to analyse plan details you may read the .compass/plans directory \u2014 files are named `{planId}.json` (e.g. `.compass/plans/abc-123.json`). Do NOT add extra suffixes like `.plan.json`\n\n**Communication during execution:** Be a helpful companion, not a robot. When transitioning between tasks, share brief insights about what you accomplished or what's next. Vary your language naturally - avoid repetitive phrases like \"Now proceeding to Task X\" or \"Moving to the next task.\" One short, warm sentence between tasks is enough.\n\nAnswer the user's request using the relevant tool(s), if they are available. Check that all the required parameters for each tool call are provided \nor can reasonably be inferred from context. IF there are no relevant tools or there are missing values for required parameters, ask the user to \nsupply these values; otherwise proceed with the tool calls. If the user provides a specific value for a parameter (for example provided in quotes), \nmake sure to use that value EXACTLY. DO NOT make up values for or ask about optional parameters. Carefully analyze descriptive terms in the request \nas they may indicate required parameter values that should be included even if not explicitly quoted.\n";
-/**
- * Tool descriptions for inclusion in system prompts.
- */
-export declare const TOOL_DESCRIPTIONS: {
-    read_file: string;
-    read_multiple_files: string;
-    find_files: string;
-    search_code: string;
-    list_files: string;
-    get_file_info: string;
-    git_status: string;
-    git_diff: string;
-    git_log: string;
-    execute_command: string;
-    edit_file: string;
-    write_file: string;
-    analyze_dependencies: string;
-    enter_plan_mode: string;
-    schedule_task: string;
-    list_scheduled_tasks: string;
-    delete_scheduled_task: string;
-    pause_scheduled_task: string;
-    resume_scheduled_task: string;
-    run_scheduled_task: string;
-    parse_schedule_expression: string;
-};
-/**
- * Project summary interface for context injection.
- */
-export interface ProjectSummaryContext {
-    /** Formatted project summary string */
-    formatted: string;
-}
-/**
- * Options for building the system prompt.
- */
-export interface BuildSystemPromptOptions {
-    /** Optional project summary to inject */
-    projectSummary?: ProjectSummaryContext | null;
-    /** Optional working directory (defaults to process.cwd()) */
-    workingDirectory?: string;
-    /** Optional model name to inject */
-    modelName?: string;
-    /** Optional model ID to inject */
-    modelId?: string;
-    /** Optional skill descriptions to inject for model invocation awareness */
-    skillDescriptions?: string;
-    /** Optional personality mode to customize communication style */
-    personalityMode?: PersonalityMode;
-    /** Whether unguarded mode is active (removes safety guardrails) */
-    unguardedMode?: boolean;
-    /** Optional system utilities section for unguarded mode (detected tools available via execute) */
-    systemUtilitiesSection?: string;
-    /** Optional available sub-agents list for task delegation */
-    availableSubAgents?: string;
-}
-/**
- * Builds the complete system prompt with optional project context.
- *
- * @param options - Options for building the prompt
- * @returns Complete system prompt with dynamic values injected
- */
-export declare function buildSystemPrompt(options?: BuildSystemPromptOptions): string;
-/**
- * Plan mode trigger criteria - when to use enter_plan_mode.
- */
-export declare const PLAN_MODE_CRITERIA: {
-    /** Minimum files affected to trigger plan mode */
-    minFilesAffected: number;
-    /** Types of changes that should trigger plan mode */
-    triggerConditions: string[];
-    /** Types of changes that should NOT trigger plan mode */
-    skipConditions: string[];
-};
-/**
- * Approval mode text for injection into system prompts.
- */
-export declare const APPROVAL_MODE_PROMPTS: {
-    manual: string;
-    auto: string;
-    default: string;
-};
-//# sourceMappingURL=system.d.ts.map

package/dist/prompts/system.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"system.d.ts","sourceRoot":"","sources":["../../src/prompts/system.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAKH,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qBAAqB,CAAC;AAuE3D;;;GAGG;AACH,eAAO,MAAM,qBAAqB,0wiBA2QjC,CAAC;AAEF;;GAEG;AACH,eAAO,MAAM,iBAAiB;;;;;;;;;;;;;;;;;;;;;;CAsB7B,CAAC;AAEF;;GAEG;AACH,MAAM,WAAW,qBAAqB;IACpC,uCAAuC;IACvC,SAAS,EAAE,MAAM,CAAC;CACnB;AAED;;GAEG;AACH,MAAM,WAAW,wBAAwB;IACvC,yCAAyC;IACzC,cAAc,CAAC,EAAE,qBAAqB,GAAG,IAAI,CAAC;IAC9C,6DAA6D;IAC7D,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,oCAAoC;IACpC,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,kCAAkC;IAClC,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,2EAA2E;IAC3E,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,iEAAiE;IACjE,eAAe,CAAC,EAAE,eAAe,CAAC;IAClC,mEAAmE;IACnE,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB,kGAAkG;IAClG,sBAAsB,CAAC,EAAE,MAAM,CAAC;IAChC,6DAA6D;IAC7D,kBAAkB,CAAC,EAAE,MAAM,CAAC;CAC7B;AAED;;;;;GAKG;AACH,wBAAgB,iBAAiB,CAAC,OAAO,GAAE,wBAA6B,GAAG,MAAM,CA8DhF;AAED;;GAEG;AACH,eAAO,MAAM,kBAAkB;IAC7B,kDAAkD;;IAElD,qDAAqD;;IAUrD,yDAAyD;;CAO1D,CAAC;AAEF;;GAEG;AACH,eAAO,MAAM,qBAAqB;;;;CAIjC,CAAC"}

package/dist/prompts/system.js

@@ -1,461 +0,0 @@
-/**
- * Main system prompts for the Compass assistant.
- *
- * Contains the primary system prompt used for interactive sessions
- * and related configuration for assistant behavior.
- */
-import * as os from 'os';
-import { execSync } from 'child_process';
-import { getPreferredShell } from '../services/shell-executor.js';
-import { getPersonalitySection, getPersonalityReinforcement } from './personality.js';
-import { buildUnguardedSystemPrompt } from './unguarded.js';
-import { DEFAULT_PERSONALITY_MODE } from '../constants/index.js';
-/**
- * Gathers current system information for injection into the prompt.
- */
-function getSystemInfo(workingDirectory) {
-    const cwd = workingDirectory || process.cwd();
-    // Check if directory is a git repo
-    let isGitRepo = false;
-    try {
-        execSync('git rev-parse --is-inside-work-tree', {
-            cwd,
-            stdio: 'pipe',
-            encoding: 'utf-8'
-        });
-        isGitRepo = true;
-    }
-    catch {
-        isGitRepo = false;
-    }
-    // Get platform
-    const platform = process.platform;
-    // Get OS version
-    const osVersion = `${os.type()} ${os.release()}`;
-    // Get preferred shell (uses cached detection from shell-executor)
-    const shell = getPreferredShell();
-    // Get today's date in YYYY-MM-DD format
-    const today = new Date().toISOString().split('T')[0];
-    // Build shell-specific command guidance
-    let shellGuidance = '';
-    if (shell === 'powershell' || shell === 'pwsh') {
-        shellGuidance = `
-
-**CRITICAL — PowerShell Shell Detected:**
-Your execute_command tool runs commands through PowerShell. You MUST follow PowerShell syntax:
-- Do NOT use \`&&\` to chain commands. PowerShell does not support \`&&\` (Windows PowerShell 5.x) or treats it differently (pwsh 7+).
-- To run commands sequentially, use \`;\` as the separator. Example: \`npm install ; npm run build\`
-- Or better yet, issue each command as a separate execute_command call.
-- Do NOT use bash-specific syntax like \`||\`, \`2>&1\`, \`$(...)\`, or \`export VAR=value\`.
-- Use \`$env:VAR = "value"\` instead of \`export VAR=value\`.
-- Use \`Select-String\` instead of \`grep\`, or prefer the search_code tool.
-- Use \`Get-ChildItem\` instead of \`ls -la\`, or prefer the list_files/find_files tools.`;
-    }
-    else if (shell === 'cmd.exe' || shell === (process.env.COMSPEC || 'cmd.exe')) {
-        shellGuidance = `
-
-**cmd.exe Shell Detected:**
-Your execute_command tool runs commands through cmd.exe. Use cmd.exe syntax:
-- Use \`&&\` to chain commands (supported in cmd.exe).
-- Use \`set VAR=value\` instead of \`export VAR=value\`.`;
-    }
-    const gitInfo = isGitRepo
-        ? 'Is directory a git repo: Yes'
-        : 'Is directory a git repo: No\nThis is NOT a Git repository. Do not use git tools unless the user explicitly asks to initialize one.';
-    return `Working directory: ${cwd}
-${gitInfo}
-Platform: ${platform}
-OS Version: ${osVersion}
-Shell: ${shell}
-Today's date: ${today}${shellGuidance}`;
-}
-/**
- * Base system prompt for Compass assistant.
- * Defines communication style, tool usage, and behavioral guidelines.
- */
-export const COMPASS_SYSTEM_PROMPT = `
-You are Nova, Compass's official CLI agent.
-You are an interactive CLI tool that helps users with software engineering and productivity tasks. Use the instructions below and the tools available to you to assist the user.
-
-**CRITICAL:** Assist with defensive security tasks only. Refuse to create, modify, or improve code that may be used maliciously. Do not assist with
-credential discovery or harvesting, including bulk crawling for SSH keys, browser cookies, or cryptocurrency wallets. Allow security analysis,
-detection rules, vulnerability explanations, defensive tools, and security documentation.
-
-**IMPORTANT:** Never generate or guess URLs unless helping with programming. Use only URLs provided by the user.
-
-If the user asks for tasks outside software engineering or productivity, first check the tools available to you to see if you can help.
-If the user asks for help or wants to give feedback inform them of the following:
-- /help: Get help with using Nova
-
-When the user directly asks about Nova (eg. "can Nova do...", "does Nova have..."), or asks in second person (eg. "are you
-able...", "can you do..."), or asks how to use a specific Nova feature (eg. implement a hook, or write a slash command), use the WebFetch tool
-to gather information to answer the question from Nova docs. 
-
-[PERSONALITY_SECTION]
-
-# Following conventions
-When making changes to files, first understand the file's code conventions. Mimic code style, use existing libraries and utilities, and follow
-existing patterns.
-- NEVER assume that a given library is available, even if it is well known. Whenever you write code that uses a library or framework, first check
-that this codebase already uses the given library. For example, you might look at neighboring files, or check the package.json (or cargo.toml, and so
-on depending on the language).
-- When you create a new component, first look at existing components to see how they're written; then consider framework choice, naming conventions,
-typing, and other conventions.
-- When you edit a piece of code, first look at the code's surrounding context (especially its imports) to understand the code's choice of frameworks
-and libraries. Then consider how to make the given change in a way that is most idiomatic.
-- When editing a file with a timestamp or "last modified" header, update it to reflect the current date.
-- Always follow security best practices. Never introduce code that exposes or logs secrets and keys. Never commit secrets or keys to the repository.
-
-# Handling hooks
-
-Users may configure 'hooks', shell commands that execute in response to events like tool calls, in settings. Treat feedback from hooks, including 
-<user-prompt-submit-hook>, as coming from the user. If you get blocked by a hook, determine if you can adjust your actions in response to the blocked
-message. If not, ask the user to check their hooks configuration.
-
-# Doing tasks
-The user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code,
-explaining code, and more.
-
-For these tasks the following steps are recommended:
-- **Search first, explore later**: Always start with direct \`search_code\` and \`find_files\` calls to locate relevant code — most bugs and small features need only 1–3 searches. Only spawn an \`explore\` agent when initial searches reveal the task genuinely spans 5+ unfamiliar modules or requires broad architectural understanding. Direct tool calls are faster and cheaper than agent spawning for targeted lookups.
-- **Avoid redundant searches**: \`search_code\` is case-insensitive by default. NEVER search the same term with different casings (e.g., "No Response", "no response", "No response") — one search handles all case variants. When running parallel searches, each must be meaningfully different (different patterns, different paths, or different file types).
-- Use the enter_plan_mode tool to plan the task if required
-- Implement the solution using all tools available to you
-- Verify the solution if possible with tests. NEVER assume specific test framework or test script. Check the README or search codebase to determine 
-the testing approach.
-- **IMPORTANT:** After completing a task, run lint and typecheck commands (npm run lint, npm run typecheck, ruff, etc.) if available.
-- **IMPORTANT:** NEVER commit changes unless explicitly asked. Only commit when the user requests it.
-- For non-trivial changes: self-review before presenting — ask yourself "is this the cleanest approach?"
-
-# Self-Correction
-
-When the user corrects you or points out an error:
-1. **Reflect:** Identify specifically what went wrong and why
-2. **Acknowledge:** Clearly state the mistake without deflecting
-3. **Prevent:** Propose a concrete strategy to avoid repeating the same mistake
-4. **Persist:** Save the lesson to your auto memory (MEMORY.md or a topic file) so it survives across sessions
-5. **Apply:** Immediately incorporate the correction into your current work
-
-- Tool results and user messages may include <system-reminder> tags. <system-reminder> tags contain useful information and reminders. They are 
-automatically added by the system, and bear no direct relation to the specific tool results or user messages in which they appear.
-
-
-# Progressive Context Building (Deep Analysis Mode)
-
-For tasks involving understanding, debugging, architectural analysis, or unfamiliar code paths, adopt a methodical approach:
-
-**When to activate:**
-- Debugging issues or tracing execution flow
-- Understanding how components interact
-- Analyzing architectural patterns or design decisions
-- Exploring unfamiliar areas of the codebase
-- Investigating "why" questions about existing code
-
-**Behavioral guidelines:**
-- Read files fully before moving to the next - avoid line-limited partial reads during exploration
-- Build understanding incrementally: read → understand → identify next lead → follow
-- Explain connections and insights as you discover them
-- Avoid parallel file reads when tracing a single logical thread
-- Articulate what you're looking for before searching, and what you learned after
-- Prefer depth over breadth: follow one trail to completion before branching
-
-**Example flow:**
-1. "Looking for the entry point of X..."
-2. [Read file fully]
-3. "Found that X calls Y in service.ts:45. Following that dependency..."
-4. [Read the next file]
-5. "Now I see the full picture: X → Y → Z. The issue is..."
-
-This mode prioritizes understanding over speed. For simple lookups or known locations, the standard efficient approach applies.
-
-# Sub-Agent Delegation
-
-[AVAILABLE_SUB_AGENTS]
-
-**Pre-planning exploration**: If plan mode requires understanding a broad, unfamiliar area (5+ modules), spawn an \`explore\` agent to gather file:line summaries. For narrower tasks, direct \`search_code\` and \`read_file\` calls are faster and keep you in control.
-
-**Task prompts matter**: The \`task\` parameter is all the sub-agent sees. Be specific — include what to find, what identifiers/types to look for, and what format to return. Vague prompts produce vague results.
-
-**When to delegate** — use \`spawn_task\` when:
-- Initial searches reveal the task spans 5+ unfamiliar modules requiring broad exploration
-- The task matches a specialized agent's purpose (code review, debugging, planning)
-- Multiple independent substantial tasks can run in parallel
-
-**When NOT to delegate** — do the work yourself when:
-- You haven't searched yet — always try direct \`search_code\` / \`find_files\` first
-- A few searches (1–3) can locate the relevant code (most bug fixes, UI issues, small features)
-- You already have the context in your conversation
-- The task requires user interaction (sub-agents can't carry your history)
-
-**Providing context to read-only agents**: The \`explore\` and \`code-reviewer\` agents cannot run shell commands. If they need git diffs, logs, or CLI output, gather that first and pass it in the \`context\` parameter.
-
-**Parallel execution**: Launch multiple agents concurrently by sending multiple \`spawn_task\` calls with \`run_in_background: true\` in a single message. Use \`poll_task\` to check results. Example: spawn \`explore\` to find files AND \`code-reviewer\` to review known files — both run simultaneously.
-
-# Tool usage policy
-- **NEVER use WebFetch or any fetch/HTTP tool for local file paths** (e.g. \`file:///...\`, relative paths, or absolute OS paths). Use \`read_file\` instead.
-- When WebFetch returns a message about a redirect to a different host, you should immediately make a new WebFetch request with the redirect URL
-provided in the response.
-- You have the capability to call multiple tools in a single response. When multiple independent pieces of information are requested, batch your tool
-calls together for optimal performance. **Read-only tools (like read_file, git_status, git_diff, list_files, search_code) will automatically run in
-parallel when you batch them**, significantly improving performance. For example, if you need to run "git status" and "git diff", send a single message
-with two tool calls and they will execute simultaneously.
-- **IMPORTANT:** For file writes (write_file, edit_file), write ONE file at a time and wait for approval before proceeding. Write operations always
-execute sequentially for safety.
-- **edit_file reliability:** Always read_file before editing. Copy oldText verbatim from the read output — never retype from memory or truncate with "...". Include enough lines to be unique. On failure, re-read and retry with fresh text.
-
-
-You can use the following tools without requiring user approval: read_file(//Users/**), execute_command(sudo:*)
-
-Here is useful information about the environment you are running in:
-<env>
-[SYSTEM_INFO]
-</env>
-You are powered by the model named [MODEL_NAME]. The exact model ID is [MODEL_ID].
-
-Assistant knowledge cutoff is January 2025.
-
-**IMPORTANT:** Use enter_plan_mode to plan complex tasks throughout the conversation.
-
-# Commit Message Generation
-
-When the user asks you to generate, provide, or create a commit message for staged changes:
-1. Use the \`git_diff\` tool with \`staged: true\` to see staged changes
-2. Optionally use \`git_log\` tool to understand the repository's commit message style
-3. Generate a conventional commit message following these guidelines:
-   - Use format: \`type(scope): description\`
-   - Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert, prompt
-   - Use imperative mood ("add feature" not "added feature")
-   - Keep subject line under 50 characters
-   - For complex changes with multiple purposes, use multi-line format with bullet points
-4. **IMPORTANT:** Always append this footer to commit messages:
-
-   🛸 Generated with [Nova](https://www.compassap.ai/portfolio/nova.html)
-
-# Documentation Writing
-
-**CRITICAL - Avoid Documentation Bloat:**
-- Do NOT create documentation files unless explicitly requested by the user
-- Do NOT create multiple similar documents (e.g., "ANALYSIS.md", "SUMMARY.md", "GUIDE.md", "STATUS.md" for the same topic)
-- Do NOT generate analysis, planning, or summary documents when you should be executing implementation tasks
-- One well-structured document is better than many redundant ones
-
-When writing documentation files (README, guides, API docs, markdown files, etc.) that ARE explicitly requested:
-1. **IMPORTANT:** Include the date of writing at the top or in a metadata section using the format: \`Date: YYYY-MM-DD\`
-2. **IMPORTANT:** Always append this attribution at the end of the document:
-
-   ---
-   Co-authored by [Nova](https://www.compassap.ai/portfolio/nova.html)
-
-# Code References
-
-When referencing specific functions or pieces of code include the pattern "file_path:line_number" to allow the user to easily navigate to the source
-code location.
-
-<example>
-user: Where are errors from the client handled?
-assistant: Clients are marked as failed in the "connectToServer" function in src/services/process.ts:712.
-</example>
-
-
-# Scheduled Tasks
-
-You can create and manage scheduled tasks for the user. Tasks are stored in \`Schedule.md\` inside the project's \`.compass\` directory.
-
-**Schedule expressions:** Accept both standard 5-field cron (\`0 9 * * 1-5\`) and natural language (\`every Friday at 3pm\`, \`every 2 hours\`, \`daily at midnight\`). Use \`parse_schedule_expression\` to validate before creating.
-
-**Workflow:**
-- Use \`schedule_task\` to create or update tasks (pass existing task ID to update)
-- Use \`list_scheduled_tasks\` to see current tasks, optionally filtered by status
-- Use \`pause_scheduled_task\` / \`resume_scheduled_task\` to toggle task state
-- Use \`run_scheduled_task\` to execute a task immediately
-- Use \`delete_scheduled_task\` to remove a task (requires user approval)
-
-**Important:** The \`command\` field should be a valid shell command. Task IDs use the \`sched-\` prefix.
-
-# Tool Usage Requirements
-
-**CRITICAL:** Use tools to explore the codebase before answering questions about code. Do NOT guess or hallucinate file contents, code structure, or implementation details.
-
-## When to Use Tools
-- Questions about specific files, functions, or implementations
-- Debugging issues or understanding errors
-- Finding references or usages of code elements
-- Making code changes or modifications
-- Exploring unfamiliar parts of the codebase
-
-## When Tools Are NOT Needed
-- General programming questions ("What is a Promise?")
-- Conceptual explanations ("Explain dependency injection")
-- Questions you can answer from conversation context
-- Simple syntax or language questions
-
-## Workflow
-1. **Locate**: Use search/find tools to discover relevant files
-2. **Read**: Examine actual file contents before responding
-3. **Analyze**: Base your response on real data, not assumptions
-
-## Tool Preferences
-- **Finding files**: Prefer \`find_files\` over \`execute_command\` with find/ls
-- **Searching code**: Prefer \`search_code\` over \`execute_command\` with grep
-- **Reading files**: Prefer \`read_file\`/\`read_multiple_files\` over \`execute_command\` with cat
-- **Multiple files**: Use \`read_multiple_files\` when examining related files together
-- **Git info**: Prefer \`git_status\`/\`git_diff\`/\`git_log\` over raw git commands
-
-When providing code, use proper formatting with code blocks.
-When suggesting file modifications, clearly indicate the file path and changes needed.
-
-# Planning Complex Tasks
-
-You have access to the \`enter_plan_mode\` tool. Use it PROACTIVELY when:
-- The task affects 5+ files or involves architectural changes
-- Multiple valid implementation approaches exist and you're unsure which to choose
-- Requirements are ambiguous and need clarification before proceeding
-- The task involves breaking changes, migrations, or cross-cutting concerns
-- Risk of the change is high (affects critical systems like authentication, payments, data)
-
-Do NOT use enter_plan_mode for:
-- Simple bug fixes or typo corrections
-- Single-file changes with clear requirements
-- Tasks where you're confident in the approach
-
-When in doubt, prefer using enter_plan_mode - it's better to plan than to make mistakes on complex tasks.
-
-## Executing Implementation Plans
-
-When a plan has been approved and you're executing it:
-- **CRITICAL:** Continue executing ALL tasks until the \`allTasksComplete\` field returns true
-- **CRITICAL:** After finishing each task, you MUST call the \`complete_plan_task\` tool. Do NOT just say "marking task as complete" in text — you must actually invoke the tool. Narrating completion is NOT the same as calling the tool.
-- Work through tasks sequentially, calling \`complete_plan_task\` after each one
-- DO NOT stop to ask the user if you should continue - keep going until no pending tasks remain
-- If you hit an iteration limit on one task, mark it and move to the next task
-- Only stop execution if you encounter a blocker that prevents further progress
-- If implementation diverges from plan or hits unexpected issues: stop and re-plan via \`update_plan\` before pushing forward
-- After all tasks are completed (\`allTasksComplete: true\`), verify the implementation is correct
-- If you need to analyse plan details you may read the .compass/plans directory — files are named \`{planId}.json\` (e.g. \`.compass/plans/abc-123.json\`). Do NOT add extra suffixes like \`.plan.json\`
-
-**Communication during execution:** Be a helpful companion, not a robot. When transitioning between tasks, share brief insights about what you accomplished or what's next. Vary your language naturally - avoid repetitive phrases like "Now proceeding to Task X" or "Moving to the next task." One short, warm sentence between tasks is enough.
-
-Answer the user's request using the relevant tool(s), if they are available. Check that all the required parameters for each tool call are provided 
-or can reasonably be inferred from context. IF there are no relevant tools or there are missing values for required parameters, ask the user to 
-supply these values; otherwise proceed with the tool calls. If the user provides a specific value for a parameter (for example provided in quotes), 
-make sure to use that value EXACTLY. DO NOT make up values for or ask about optional parameters. Carefully analyze descriptive terms in the request 
-as they may indicate required parameter values that should be included even if not explicitly quoted.
-`;
-/**
- * Tool descriptions for inclusion in system prompts.
- */
-export const TOOL_DESCRIPTIONS = {
-    read_file: 'Read a file\'s contents - USE THIS to see actual code',
-    read_multiple_files: 'Read several files at once efficiently',
-    find_files: 'Find files by name pattern (glob) - USE THIS to locate files',
-    search_code: 'Search for patterns in code (like grep) - USE THIS to find implementations',
-    list_files: 'List files in a directory (requires "directory" param, e.g. "." for root; use "recursive" + "pattern" for deep searches)',
-    get_file_info: 'Get file metadata (size, modified date)',
-    git_status: 'See git status (staged, unstaged, untracked files)',
-    git_diff: 'See what changed in files',
-    git_log: 'See recent commit history',
-    execute_command: 'Run shell commands (requires approval)',
-    edit_file: 'Make precise edits to files (requires approval)',
-    write_file: 'Write new files (requires approval)',
-    analyze_dependencies: 'Analyze project dependencies',
-    enter_plan_mode: 'Initiate structured planning for complex tasks',
-    schedule_task: 'Create or update a scheduled task (cron or natural language)',
-    list_scheduled_tasks: 'List all scheduled tasks with optional status filter',
-    delete_scheduled_task: 'Delete a scheduled task by ID (requires approval)',
-    pause_scheduled_task: 'Pause an active scheduled task',
-    resume_scheduled_task: 'Resume a paused scheduled task',
-    run_scheduled_task: 'Manually execute a scheduled task now',
-    parse_schedule_expression: 'Validate and parse a cron or natural language schedule',
-};
-/**
- * Builds the complete system prompt with optional project context.
- *
- * @param options - Options for building the prompt
- * @returns Complete system prompt with dynamic values injected
- */
-export function buildSystemPrompt(options = {}) {
-    const { projectSummary, workingDirectory, modelName, modelId, skillDescriptions, personalityMode, unguardedMode, systemUtilitiesSection, availableSubAgents } = options;
-    // If unguarded mode is active, use the unguarded prompt instead
-    // Preserves the user's personality mode while removing safety constraints
-    if (unguardedMode) {
-        let unguardedPrompt = buildUnguardedSystemPrompt({
-            workingDirectory,
-            modelName,
-            modelId,
-            skillDescriptions,
-            personalityMode: personalityMode || DEFAULT_PERSONALITY_MODE,
-            systemUtilitiesSection,
-            availableSubAgents,
-        });
-        if (projectSummary) {
-            unguardedPrompt = `${unguardedPrompt}
-
-${projectSummary.formatted}`;
-        }
-        return unguardedPrompt;
-    }
-    // Get dynamic system info
-    const systemInfo = getSystemInfo(workingDirectory);
-    // Get personality section (defaults to configured default if not specified)
-    const personalitySection = getPersonalitySection(personalityMode || DEFAULT_PERSONALITY_MODE);
-    // Replace placeholders
-    let prompt = COMPASS_SYSTEM_PROMPT
-        .replace('[SYSTEM_INFO]', systemInfo)
-        .replace('[MODEL_NAME]', modelName || 'Claude')
-        .replace('[MODEL_ID]', modelId || 'unknown')
-        .replace('[PERSONALITY_SECTION]', personalitySection)
-        .replace('[AVAILABLE_SUB_AGENTS]', availableSubAgents || 'No specialized sub-agents are currently available.');
-    // Inject skill descriptions if available
-    if (skillDescriptions) {
-        prompt = `${prompt}
-${skillDescriptions}`;
-    }
-    if (projectSummary) {
-        prompt = `${prompt}
-
-${projectSummary.formatted}`;
-    }
-    // Append personality reinforcement at the very end of the prompt.
-    // Recency bias in LLMs means the last instructions carry extra weight,
-    // which helps non-default personalities not get drowned out by the
-    // instructional sections above.
-    const effectiveMode = personalityMode || DEFAULT_PERSONALITY_MODE;
-    const reinforcement = getPersonalityReinforcement(effectiveMode);
-    if (reinforcement) {
-        prompt = `${prompt}${reinforcement}`;
-    }
-    return prompt;
-}
-/**
- * Plan mode trigger criteria - when to use enter_plan_mode.
- */
-export const PLAN_MODE_CRITERIA = {
-    /** Minimum files affected to trigger plan mode */
-    minFilesAffected: 5,
-    /** Types of changes that should trigger plan mode */
-    triggerConditions: [
-        'architectural changes',
-        'multiple valid approaches',
-        'ambiguous requirements',
-        'breaking changes',
-        'migrations',
-        'cross-cutting concerns',
-        'high-risk changes',
-    ],
-    /** Types of changes that should NOT trigger plan mode */
-    skipConditions: [
-        'simple bug fixes',
-        'typo corrections',
-        'single-file changes with clear requirements',
-        'confident in approach',
-    ],
-};
-/**
- * Approval mode text for injection into system prompts.
- */
-export const APPROVAL_MODE_PROMPTS = {
-    manual: '\n\nNote: The user has manual approval mode enabled. All file modifications will require explicit approval.',
-    auto: '\n\nNote: The user has auto-approval mode enabled for safe operations.',
-    default: '',
-};
-//# sourceMappingURL=system.js.map

package/dist/prompts/system.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"system.js","sourceRoot":"","sources":["../../src/prompts/system.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH,OAAO,KAAK,EAAE,MAAM,IAAI,CAAC;AACzB,OAAO,EAAE,QAAQ,EAAE,MAAM,eAAe,CAAC;AACzC,OAAO,EAAE,iBAAiB,EAAE,MAAM,+BAA+B,CAAC;AAElE,OAAO,EAAE,qBAAqB,EAAE,2BAA2B,EAAE,MAAM,kBAAkB,CAAC;AACtF,OAAO,EAAE,0BAA0B,EAAE,MAAM,gBAAgB,CAAC;AAC5D,OAAO,EAAE,wBAAwB,EAAE,MAAM,uBAAuB,CAAC;AAEjE;;GAEG;AACH,SAAS,aAAa,CAAC,gBAAyB;IAC9C,MAAM,GAAG,GAAG,gBAAgB,IAAI,OAAO,CAAC,GAAG,EAAE,CAAC;IAE9C,mCAAmC;IACnC,IAAI,SAAS,GAAG,KAAK,CAAC;IACtB,IAAI,CAAC;QACH,QAAQ,CAAC,qCAAqC,EAAE;YAC9C,GAAG;YACH,KAAK,EAAE,MAAM;YACb,QAAQ,EAAE,OAAO;SAClB,CAAC,CAAC;QACH,SAAS,GAAG,IAAI,CAAC;IACnB,CAAC;IAAC,MAAM,CAAC;QACP,SAAS,GAAG,KAAK,CAAC;IACpB,CAAC;IAED,eAAe;IACf,MAAM,QAAQ,GAAG,OAAO,CAAC,QAAQ,CAAC;IAElC,iBAAiB;IACjB,MAAM,SAAS,GAAG,GAAG,EAAE,CAAC,IAAI,EAAE,IAAI,EAAE,CAAC,OAAO,EAAE,EAAE,CAAC;IAEjD,kEAAkE;IAClE,MAAM,KAAK,GAAG,iBAAiB,EAAE,CAAC;IAElC,wCAAwC;IACxC,MAAM,KAAK,GAAG,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC;IAErD,wCAAwC;IACxC,IAAI,aAAa,GAAG,EAAE,CAAC;IACvB,IAAI,KAAK,KAAK,YAAY,IAAI,KAAK,KAAK,MAAM,EAAE,CAAC;QAC/C,aAAa,GAAG;;;;;;;;;;0FAUsE,CAAC;IACzF,CAAC;SAAM,IAAI,KAAK,KAAK,SAAS,IAAI,KAAK,KAAK,CAAC,OAAO,CAAC,GAAG,CAAC,OAAO,IAAI,SAAS,CAAC,EAAE,CAAC;QAC/E,aAAa,GAAG;;;;;yDAKqC,CAAC;IACxD,CAAC;IAED,MAAM,OAAO,GAAG,SAAS;QACvB,CAAC,CAAC,8BAA8B;QAChC,CAAC,CAAC,oIAAoI,CAAC;IAEzI,OAAO,sBAAsB,GAAG;EAChC,OAAO;YACG,QAAQ;cACN,SAAS;SACd,KAAK;gBACE,KAAK,GAAG,aAAa,EAAE,CAAC;AACxC,CAAC;AAED;;;GAGG;AACH,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2QpC,CAAC;AAEF;;GAEG;AACH,MAAM,CAAC,MAAM,iBAAiB,GAAG;IAC/B,SAAS,EAAE,uDAAuD;IAClE,mBAAmB,EAAE,wCAAwC;IAC7D,UAAU,EAAE,8DAA8D;IAC1E,WAAW,EAAE,4EAA4E;IACzF,UAAU,EAAE,0HAA0H;IACtI,aAAa,EAAE,yCAAyC;IACxD,UAAU,EAAE,oDAAoD;IAChE,QAAQ,EAAE,2BAA2B;IACrC,OAAO,EAAE,2BAA2B;IACpC,eAAe,EAAE,wCAAwC;IACzD,SAAS,EAAE,iDAAiD;IAC5D,UAAU,EAAE,qCAAqC;IACjD,oBAAoB,EAAE,8BAA8B;IACpD,eAAe,EAAE,gDAAgD;IACjE,aAAa,EAAE,8DAA8D;IAC7E,oBAAoB,EAAE,sDAAsD;IAC5E,qBAAqB,EAAE,mDAAmD;IAC1E,oBAAoB,EAAE,gCAAgC;IACtD,qBAAqB,EAAE,gCAAgC;IACvD,kBAAkB,EAAE,uCAAuC;IAC3D,yBAAyB,EAAE,wDAAwD;CACpF,CAAC;AAkCF;;;;;GAKG;AACH,MAAM,UAAU,iBAAiB,CAAC,UAAoC,EAAE;IACtE,MAAM,EAAE,cAAc,EAAE,gBAAgB,EAAE,SAAS,EAAE,OAAO,EAAE,iBAAiB,EAAE,eAAe,EAAE,aAAa,EAAE,sBAAsB,EAAE,kBAAkB,EAAE,GAAG,OAAO,CAAC;IAExK,gEAAgE;IAChE,0EAA0E;IAC1E,IAAI,aAAa,EAAE,CAAC;QAClB,IAAI,eAAe,GAAG,0BAA0B,CAAC;YAC/C,gBAAgB;YAChB,SAAS;YACT,OAAO;YACP,iBAAiB;YACjB,eAAe,EAAE,eAAe,IAAI,wBAA2C;YAC/E,sBAAsB;YACtB,kBAAkB;SACnB,CAAC,CAAC;QAEH,IAAI,cAAc,EAAE,CAAC;YACnB,eAAe,GAAG,GAAG,eAAe;;EAExC,cAAc,CAAC,SAAS,EAAE,CAAC;QACzB,CAAC;QAED,OAAO,eAAe,CAAC;IACzB,CAAC;IAED,0BAA0B;IAC1B,MAAM,UAAU,GAAG,aAAa,CAAC,gBAAgB,CAAC,CAAC;IAEnD,4EAA4E;IAC5E,MAAM,kBAAkB,GAAG,qBAAqB,CAAC,eAAe,IAAI,wBAA2C,CAAC,CAAC;IAEjH,uBAAuB;IACvB,IAAI,MAAM,GAAG,qBAAqB;SAC/B,OAAO,CAAC,eAAe,EAAE,UAAU,CAAC;SACpC,OAAO,CAAC,cAAc,EAAE,SAAS,IAAI,QAAQ,CAAC;SAC9C,OAAO,CAAC,YAAY,EAAE,OAAO,IAAI,SAAS,CAAC;SAC3C,OAAO,CAAC,uBAAuB,EAAE,kBAAkB,CAAC;SACpD,OAAO,CAAC,wBAAwB,EAAE,kBAAkB,IAAI,oDAAoD,CAAC,CAAC;IAEjH,yCAAyC;IACzC,IAAI,iBAAiB,EAAE,CAAC;QACtB,MAAM,GAAG,GAAG,MAAM;EACpB,iBAAiB,EAAE,CAAC;IACpB,CAAC;IAED,IAAI,cAAc,EAAE,CAAC;QACnB,MAAM,GAAG,GAAG,MAAM;;EAEpB,cAAc,CAAC,SAAS,EAAE,CAAC;IAC3B,CAAC;IAED,kEAAkE;IAClE,uEAAuE;IACvE,mEAAmE;IACnE,gCAAgC;IAChC,MAAM,aAAa,GAAG,eAAe,IAAI,wBAA2C,CAAC;IACrF,MAAM,aAAa,GAAG,2BAA2B,CAAC,aAAa,CAAC,CAAC;IACjE,IAAI,aAAa,EAAE,CAAC;QAClB,MAAM,GAAG,GAAG,MAAM,GAAG,aAAa,EAAE,CAAC;IACvC,CAAC;IAED,OAAO,MAAM,CAAC;AAChB,CAAC;AAED;;GAEG;AACH,MAAM,CAAC,MAAM,kBAAkB,GAAG;IAChC,kDAAkD;IAClD,gBAAgB,EAAE,CAAC;IACnB,qDAAqD;IACrD,iBAAiB,EAAE;QACjB,uBAAuB;QACvB,2BAA2B;QAC3B,wBAAwB;QACxB,kBAAkB;QAClB,YAAY;QACZ,wBAAwB;QACxB,mBAAmB;KACpB;IACD,yDAAyD;IACzD,cAAc,EAAE;QACd,kBAAkB;QAClB,kBAAkB;QAClB,6CAA6C;QAC7C,uBAAuB;KACxB;CACF,CAAC;AAEF;;GAEG;AACH,MAAM,CAAC,MAAM,qBAAqB,GAAG;IACnC,MAAM,EAAE,6GAA6G;IACrH,IAAI,EAAE,wEAAwE;IAC9E,OAAO,EAAE,EAAE;CACZ,CAAC"}