morpheus-cli 0.4.14 → 0.4.15

package/dist/channels/telegram.js

@@ -130,7 +130,12 @@ export class TelegramAdapter {
                             await ctx.reply((await toMd(response)).text, { parse_mode: 'MarkdownV2' });
                         }
                         catch {
-                            await ctx.reply(response);
+                            try {
+                                ctx.reply(response, { parse_mode: 'MarkdownV2' });
+                            }
+                            catch {
+                                await ctx.reply(response);
+                            }
                         }
                         this.display.log(`Responded to @${user}: ${response}`, { source: 'Telegram' });
                     }

package/dist/runtime/apoc.js

@@ -41,7 +41,7 @@ export class Apoc {
     }
     async initialize() {
         const apocConfig = this.config.apoc || this.config.llm;
-        console.log(`Apoc configuration: ${JSON.stringify(apocConfig)}`);
+        // console.log(`Apoc configuration: ${JSON.stringify(apocConfig)}`);
         const working_dir = this.config.apoc?.working_dir || process.cwd();
         const timeout_ms = this.config.apoc?.timeout_ms || 30_000;
         // Import all devkit tool factories (side-effect registration)
@@ -96,20 +96,119 @@ OPERATING RULES:
 4. If something fails, report the error and what you tried.
 5. Stay focused on the delegated task only.
 
-BROWSER WORKFLOW RULES (when using browser tools):
-1. ALWAYS call browser_navigate first to load the page.
-2. ALWAYS call browser_get_dom before browser_click or browser_fill to inspect the page structure and choose the correct CSS selectors. Never guess selectors — analyze the DOM.
-3. Analyze the DOM to identify interactive elements (inputs, buttons, links), their selectors (id, class, name), and the page flow.
-4. If the task requires information you don't have (e.g. email, password, form fields, personal data), DO NOT proceed. Instead, immediately return to Oracle with a clear message listing exactly what information is needed from the user. Example: "To complete the login form I need: email address and password."
-5. After clicking or filling, call browser_get_dom again to verify the page changed as expected.
-6. Report what was done, the final URL, and any relevant content extracted.
-
-SEARCH & FACT-CHECKING RULES (when using browser_search to answer factual questions):
-1. Call browser_search first to get a list of relevant sources.
-2. ALWAYS open at least 3 of the returned URLs with browser_navigate to read the actual content. Do not rely solely on the snippet — snippets may be outdated or incomplete.
-3. Cross-reference the information across the sources. If they agree, report the fact with confidence. If they disagree, report all versions found and indicate the discrepancy.
-4. Prefer authoritative sources (official team sites, major sports outlets, official event pages) over aggregators.
-5. Include the source URLs in your final report so Oracle can pass them to the user.
+
+────────────────────────────────────────
+BROWSER AUTOMATION PROTOCOL
+────────────────────────────────────────
+
+When using browser tools (browser_navigate, browser_get_dom, browser_click, browser_fill), follow this protocol exactly.
+
+GENERAL PRINCIPLES
+- Never guess selectors.
+- Never assume page state.
+- Always verify page transitions.
+- Always extract evidence of success.
+- If required user data is missing, STOP and return to Oracle immediately.
+
+PHASE 1 — Navigation
+1. ALWAYS call browser_navigate first.
+2. Use:
+   - wait_until: "networkidle0" for SPAs or JS-heavy pages.
+   - wait_until: "domcontentloaded" for simple pages.
+3. After navigation, confirm current_url and title.
+4. If navigation fails, report the error and stop.
+
+PHASE 2 — DOM Inspection (MANDATORY BEFORE ACTION)
+1. ALWAYS call browser_get_dom before browser_click or browser_fill.
+2. Identify stable selectors (prefer id > name > role > unique class).
+3. Understand page structure and expected flow before interacting.
+4. Never click or fill blindly.
+
+PHASE 3 — Interaction
+When clicking:
+- Prefer stable selectors.
+- If ambiguous, refine selector.
+- Use visible text only if selector is unstable.
+
+When filling:
+- Confirm correct input field via DOM.
+- Fill field.
+- Submit using press_enter OR clicking submit button.
+
+If login or personal data is required:
+STOP and return required fields clearly.
+
+PHASE 4 — State Verification (MANDATORY)
+After ANY interaction:
+1. Call browser_get_dom again.
+2. Verify URL change or content change.
+3. Confirm success or detect error message.
+
+If expected change did not occur:
+- Reinspect DOM.
+- Attempt one justified alternative.
+- If still failing, report failure clearly.
+
+Maximum 2 attempts per step.
+Never assume success.
+
+PHASE 5 — Reporting
+Include:
+- Step-by-step actions
+- Final URL
+- Evidence of success
+- Errors encountered
+- Completion status (true/false)
+
+
+────────────────────────────────────────
+WEB RESEARCH PROTOCOL
+────────────────────────────────────────
+
+When using browser_search for factual verification, follow this protocol strictly.
+
+PHASE 1 — Query Design
+1. Identify core entity, information type, and time constraint.
+2. Build a precise search query.
+3. If time-sensitive, include the current year.
+
+PHASE 2 — Source Discovery
+1. Call browser_search.
+2. Collect results.
+3. Prioritize:
+   - Official sources
+   - Major authoritative publications
+4. Reformulate query if necessary.
+
+PHASE 3 — Source Validation (MANDATORY)
+1. Open at least 3 distinct URLs with browser_navigate.
+2. Read actual page content.
+3. NEVER rely only on search snippets.
+4. Ignore inaccessible pages.
+
+PHASE 4 — Cross-Verification
+1. Extract relevant information from each source.
+2. Compare findings:
+   - Agreement → verified
+   - Minor differences → report variation
+   - Conflict → report discrepancy
+3. Require confirmation from at least 2 reliable sources.
+4. If not confirmed, state clearly:
+   "Information could not be confidently verified."
+
+PHASE 5 — Structured Report
+Include:
+- Direct answer
+- Short explanation
+- Source URLs
+- Confidence level (High / Medium / Low)
+
+ANTI-HALLUCINATION RULES
+- Never answer from prior knowledge without verification.
+- Never stop after reading only one source.
+- Treat time-sensitive information as volatile.
+
+
 
 ${context ? `CONTEXT FROM ORACLE:\n${context}` : ""}
     `);

package/dist/runtime/oracle.js

@@ -165,6 +165,78 @@ If a tool can compute, fetch, inspect, or verify something, prefer tool usage.
 
 Never hallucinate values retrievable via tools.
 
+--------------------------------------------------
+DELEGATION DECISION PROTOCOL
+--------------------------------------------------
+
+Before responding, classify the request into one of the following categories:
+
+CATEGORY A — Execution / System / External State
+If the request involves:
+- Filesystem access
+- Code execution
+- Git operations
+- Package management
+- Process inspection
+- Networking
+- Environment state
+- Browser automation
+- Web navigation
+- Web research
+- Fact verification
+- Current or time-sensitive data
+
+You MUST delegate to the appropriate tool (e.g., apoc_delegate).
+
+CATEGORY B — Factual Question Requiring Verification
+If the question involves:
+- Rankings
+- Results
+- Versions
+- News
+- Public figures
+- Statistics
+- Events
+- Anything that may have changed over time
+
+You MUST delegate to Apoc for verification.
+
+CATEGORY C — Pure Reasoning / Conceptual
+If the request can be fully answered through reasoning alone without external validation,
+you may answer directly without delegating.
+
+If uncertainty exists about whether verification is required,
+DELEGATE.
+
+--------------------------------------------------
+APOC DELEGATION STANDARD
+--------------------------------------------------
+
+When delegating to Apoc:
+
+- Provide a clear objective.
+- Specify verification requirements if factual.
+- Define expected output structure if needed.
+- Pass relevant context from the conversation.
+- Never send vague tasks.
+
+Weak delegation example (forbidden):
+"Search who won the championship."
+
+Correct delegation example:
+"Find who won the 2023 NBA Championship. Verify using at least 3 reliable sources. Provide URLs and confidence level."
+
+--------------------------------------------------
+UNCERTAINTY RULE
+--------------------------------------------------
+
+If the answer cannot be produced with high confidence without external verification,
+you MUST delegate.
+
+Never fabricate certainty.
+Never simulate tool results.
+When in doubt, delegate.
+
 
 7. FINAL ANSWER POLICY
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "morpheus-cli",
-  "version": "0.4.14",
+  "version": "0.4.15",
   "description": "Morpheus is a local AI agent for developers, running as a CLI daemon that connects to LLMs, local tools, and MCPs, enabling interaction via Terminal, Telegram, and Discord. Inspired by the character Morpheus from *The Matrix*, the project acts as an intelligent orchestrator, bridging the gap between the developer and complex systems.",
   "bin": {
     "morpheus": "./bin/morpheus.js"