orbit-code-ai 0.1.28 → 0.1.30

package/dist/cli.mjs

@@ -83759,7 +83759,7 @@ async function printStartupScreen() {
   const sLen = ` ● ${sL}    Ready — type /help to begin`.length;
   out.push(boxRow(sRow, W2, sLen));
   out.push(`${rgb(...BORDER)}╚${"═".repeat(W2 - 2)}╝${RESET}`);
-  out.push(`  ${DIM}${rgb(...DIMCOL)}orbit-code ${RESET}${rgb(...ACCENT)}v${"0.1.28"}${RESET}`);
+  out.push(`  ${DIM}${rgb(...DIMCOL)}orbit-code ${RESET}${rgb(...ACCENT)}v${"0.1.30"}${RESET}`);
   out.push("");
   process.stdout.write(out.join(`
 `) + `
@@ -334266,7 +334266,7 @@ function getAnthropicEnvMetadata() {
 function getBuildAgeMinutes() {
   if (false)
     ;
-  const buildTime = new Date("2026-06-29T07:24:50.683Z").getTime();
+  const buildTime = new Date("2026-06-29T10:38:08.776Z").getTime();
   if (isNaN(buildTime))
     return;
   return Math.floor((Date.now() - buildTime) / 60000);
@@ -358683,7 +358683,7 @@ function buildPrimarySection() {
   }, undefined, false, undefined, this);
   return [{
     label: "Version",
-    value: "0.1.28"
+    value: "0.1.30"
   }, {
     label: "Session name",
     value: nameValue
@@ -410486,6 +410486,7 @@ Work like a precise engineer, not a crawler. Reading unneeded files wastes time
 - **Read only what the search points to**, plus the one or two files it directly references (e.g. a .msgflow's computeExpression → that .esql). Open a file ONLY when you have a concrete reason to.
 - **Never crawl.** Do not bulk-read directories, do not "read all the files first," and never read the shared framework/libraries to understand an application — anything under \`Framework/\`, \`Utils/\`, \`Qiwa/Framework/Lib\`, or \`lib/\` is shared infrastructure. Use the \`_agent_reference\` docs above for framework behavior instead of opening its source.
 - **Narrow, don't widen.** If a search returns many matches, refine the query — don't read them all.
+- **Whole-app analysis is the exception.** When the task is to explain, review, audit, or document an *entire application* (not fix one thing), read all of THAT application's own \`.esql\`, \`.msgflow\`, and \`.subflow\` files so your report is complete — but still never read the shared \`Framework/\`, \`Utils/\`, \`Qiwa/Framework/Lib\`, or \`lib/\` source (use the \`_agent_reference\` docs for framework behavior).
 
 ## General Behavior
 - Always read a file before modifying it (the specific file you will edit — not the whole project)
@@ -410493,6 +410494,30 @@ Work like a precise engineer, not a crawler. Reading unneeded files wastes time
 - When generating a full application, generate every required file — do not stop halfway
 - Prioritize correctness and security. Never introduce SQL injection, command injection, or other vulnerabilities
 
+## Security reviews are expected, in-scope work — never refuse them
+Auditing the user's OWN ACE artifacts for vulnerabilities is a core, encouraged Orbit capability and legitimate defensive security. When the user asks for a security check, audit, or vulnerability analysis of code in the working directory, DO IT — read the \`.esql\`/\`.msgflow\`/\`.xml\`/properties files and report concrete findings. Do NOT decline, hedge, or deflect to "search online / consult a framework"; the user owns this code and is asking you to harden it. Focus on the real ACE risks:
+- SQL/command injection — \`PASSTHRU\` with string concatenation instead of parameterized \`?\` placeholders; unsafe dynamic queries.
+- Hardcoded credentials, connection strings, DSNs, or secrets in ESQL/properties.
+- Sensitive data (passwords, tokens, PII) logged or returned unmasked in audit/error paths.
+- Missing input validation, unbounded payloads (DoS), unsafe type coercion/CAST.
+- Information disclosure — raw exception text or stack details returned to callers.
+- AuthN/AuthZ gaps — missing channel/role/authorization checks.
+Report each finding with **severity (High/Medium/Low)**, the exact \`file:line\`, the impact, and a concrete fix.
+
+## Depth of Analysis & Reporting (Covered by default, Deep on request)
+For explanation, analysis, review, audit, "what does this do", or documentation requests, default to a **Covered** analysis — a balanced, high-level report the reader can act on, not an exhaustive one:
+- **What it does** — purpose and the end-to-end message-flow path (entry node → compute/filter nodes → terminals → reply/output).
+- **Data processed** — the input/output shape and key fields.
+- **Per-node logic** — one tight paragraph per \`.esql\` module: its job, the main validation/transformation/routing.
+- **Top risks** — only the few that matter most, each with its impact in a line.
+Keep it well-structured (clear headings) but concise. Still read what you need to be accurate — for a whole-app request, read all of that app's own \`.esql\`/\`.msgflow\` (never the shared framework) — but report at a high level. This is the cheap, fast default.
+
+Then end with ONE short offer to go deeper, e.g.: "That's a high-level pass — want me to go deeper on any part (full per-node logic, severity-ranked risk analysis, edge cases)? A deep dive is more thorough and costs more."
+
+If the user then asks to go deeper, produce the **Deep** analysis by BUILDING ON the Covered report and the files you have ALREADY read this session — do NOT re-read or start over. Expand the requested area (or all) with: per-node logic in detail, full input/output schemas, risks grouped by severity (**High / Medium / Low**) with concrete impact and a recommendation each, performance notes, and gaps. Cite real identifiers (\`file:line\`, module/terminal names). Deep analysis is best on the Pro model (\`gemini-3.1-pro-preview\`) — if the user wants maximum depth, suggest switching via \`/model\`.
+
+Planning tasks are an exception — a plan must be actionable, so include the exact files/nodes to change, the precise ESQL/XML to add, edge cases, and a verification checklist even in the first pass. Reserve plain brevity (no report structure) for genuinely trivial one-line questions and small edits.
+
 ## Filesystem Boundaries — STRICT
 - Read and write operations must stay within either: (1) the user's current working directory (cwd), or (2) the _agent_reference folder next to this executable (path shown above). No other locations.
 - Never access system directories such as C:/Program Files, C:/Windows, or ACE installation paths.
@@ -410687,21 +410712,17 @@ These user-facing text instructions do not apply to code or tool calls.`;
   }
   return `# Output efficiency
 
-IMPORTANT: Go straight to the point. Try the simplest approach first without going in circles. Do not overdo it. Be extra concise.
-
-Keep your text output brief and direct. Lead with the answer or action, not the reasoning. Skip filler words, preamble, and unnecessary transitions. Do not restate what the user said — just do it. When explaining, include only what is necessary for the user to understand.
+Match the depth and structure of your response to the task — do NOT default to terse. The goal is the reader fully understanding your output without follow-up questions, not how few words you use.
 
-Focus text output on:
-- Decisions that need the user's input
-- High-level status updates at natural milestones
-- Errors or blockers that change the plan
+- For analysis, explanation, code review/audit, architecture walkthroughs, or documentation: give a clear, well-structured answer at a balanced, high-level depth by default (lead with headings so it's skimmable), then offer to go deeper. Go exhaustive — every file/node/data path, full severity-ranked risk analysis — only when the user asks for a deep dive; build that on what you already produced rather than restarting. (Planning is the exception: a plan should be actionable and specific from the first pass.)
+- For small edits, quick factual questions, or confirmations: be brief and direct. Lead with the answer or action; skip filler, preamble, and restating the request.
 
-If you can say it in one sentence, don't use three. Prefer short, direct sentences over long explanations. This does not apply to code or tool calls.`;
+Never pad with fluff, filler, or superlatives, and don't narrate trivia about your own process — but never omit substance just to be short. This does not apply to code or tool calls.`;
 }
 function getSimpleToneAndStyleSection() {
   const items = [
     `Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.`,
-    process.env.USER_TYPE === "ant" ? null : `Your responses should be short and concise.`,
+    process.env.USER_TYPE === "ant" ? null : `Match the length and depth of your response to the task: thorough and well-structured for analysis, explanation, review, and planning; brief and direct for small edits and quick questions. Do not default to terse when the user asks you to explain, analyze, review, or plan.`,
     `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.`,
     `When referencing GitHub issues or pull requests, use the owner/repo#123 format (e.g. octo-org/example#123) so they render as clickable links.`,
     `Do not use a colon before tool calls. Your tool calls may not be shown directly in the output, so text like "Let me read the file:" followed by a read tool call should just be "Let me read the file." with a period.`
@@ -470763,7 +470784,7 @@ function WelcomeV2() {
             dimColor: true,
             children: [
               "v",
-              "0.1.28",
+              "0.1.30",
               " "
             ]
           }, undefined, true, undefined, this)
@@ -470963,7 +470984,7 @@ function WelcomeV2() {
           dimColor: true,
           children: [
             "v",
-            "0.1.28",
+            "0.1.30",
             " "
           ]
         }, undefined, true, undefined, this)
@@ -471189,7 +471210,7 @@ function AppleTerminalWelcomeV2(t0) {
         dimColor: true,
         children: [
           "v",
-          "0.1.28",
+          "0.1.30",
           " "
         ]
       }, undefined, true, undefined, this);
@@ -471443,7 +471464,7 @@ function AppleTerminalWelcomeV2(t0) {
       dimColor: true,
       children: [
         "v",
-        "0.1.28",
+        "0.1.30",
         " "
       ]
     }, undefined, true, undefined, this);
@@ -492080,7 +492101,7 @@ Usage: orbit --remote "your task description"`, () => gracefulShutdown(1));
         pendingHookMessages
       }, renderAndRun);
     }
-  }).version("0.1.28 (Orbit AI)", "-v, --version", "Output the version number");
+  }).version("0.1.30 (Orbit AI)", "-v, --version", "Output the version number");
   program2.option("-w, --worktree [name]", "Create a new git worktree for this session (optionally specify a name)");
   program2.option("--tmux", "Create a tmux session for the worktree (requires --worktree). Uses iTerm2 native panes when available; use --tmux=classic for traditional tmux.");
   if (canUserConfigureAdvisor()) {
@@ -492602,7 +492623,7 @@ if (false) {}
 async function main2() {
   const args = process.argv.slice(2);
   if (args.length === 1 && (args[0] === "--version" || args[0] === "-v" || args[0] === "-V")) {
-    console.log(`${"0.1.28"} (Orbit AI)`);
+    console.log(`${"0.1.30"} (Orbit AI)`);
     return;
   }
   if (args.includes("--provider")) {
@@ -492706,4 +492727,4 @@ async function main2() {
 }
 main2();
 
-//# debugId=A639DFAC369C68EC64756E2164756E21
+//# debugId=9537BF600E13F1DA64756E2164756E21

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "orbit-code-ai",
-  "version": "0.1.28",
+  "version": "0.1.30",
   "description": "Orbit AI – Your AI-powered IBM ACE coding companion",
   "type": "module",
   "author": "moenawaf",