@loadmill/droid-cua 2.3.0 → 2.5.0

package/build/src/prompts/base.js

@@ -0,0 +1,139 @@
+function buildCustomInstructionsSection(sections = []) {
+    const nonEmptySections = sections
+        .map((section) => ({
+        title: section?.title,
+        text: typeof section?.text === "string" ? section.text.trim() : ""
+    }))
+        .filter((section) => section.title && section.text);
+    if (nonEmptySections.length === 0) {
+        return "";
+    }
+    const renderedSections = nonEmptySections
+        .map((section) => `${section.title}:\n${section.text}`)
+        .join("\n\n");
+    return `USER CUSTOM INSTRUCTIONS:
+Follow these user-configured instructions in addition to the default behavior below.
+Prefer these custom instructions when deciding how to behave.
+
+${renderedSections}`;
+}
+function appendCustomSections(prompt, sections = []) {
+    const customSection = buildCustomInstructionsSection(sections);
+    if (!customSection) {
+        return prompt;
+    }
+    return `${prompt}
+
+${customSection}
+`;
+}
+function buildStrictModeRuntimeSection(runtimeOptions = {}) {
+    if (runtimeOptions?.strictMode !== true) {
+        return "";
+    }
+    return `STRICT MODE - Observation-First Runtime:
+- The runtime may execute only the first meaningful action from any multi-step action chain you propose.
+- After that first action, it will re-observe the device and continue from a fresh screenshot.
+- If you propose multiple steps, assume only the first may happen before the next turn.
+- Do not assume later proposed actions succeeded unless the next screenshot confirms them.`;
+}
+function describeControlledDevice(deviceInfo = {}) {
+    const platform = typeof deviceInfo.platform === "string" ? deviceInfo.platform.trim().toLowerCase() : "";
+    const deviceName = typeof deviceInfo.device_name === "string" ? deviceInfo.device_name.trim() : "";
+    if (platform === "ios") {
+        return deviceName ? `an iOS simulator (${deviceName})` : "an iOS device";
+    }
+    if (platform === "android") {
+        return deviceName ? `an Android device (${deviceName})` : "an Android device";
+    }
+    return "a mobile device";
+}
+function buildBaseSystemPrompt(deviceInfo, customInstructions = {}) {
+    const controlledDevice = describeControlledDevice(deviceInfo);
+    const prompt = `
+  You are controlling ${controlledDevice} in a sandboxed testing environment.
+  Follow the user's instructions to interact with the device.
+
+  The device screen has been scaled down for display.
+  You can interact with any part of the visible phone screen, including system UI, browser UI, and app content.
+
+  The screen you see is ${deviceInfo.scaled_width} x ${deviceInfo.scaled_height} pixels.
+  Pixel (0,0) is at the top-left corner.
+
+  When aiming for visual targets:
+  - Reason carefully about the approximate pixel position.
+  - Click precisely based on your visual estimate.
+
+  Available actions: click, scroll, type, keypress, wait, screenshot.
+
+  CRITICAL - Mobile Input Constraints:
+  - This is a mobile device, not a desktop. Do NOT use desktop keyboard shortcuts or modifier chords.
+  - NEVER emit key combinations such as CTRL+A, CMD+A, CTRL+C, CTRL+V, ALT+TAB, SHIFT+ENTER, or similar shortcuts.
+  - Use 'keypress' only for a single mobile-safe key when absolutely necessary.
+  - To replace text, tap into the field and type the desired value. If correction is needed, use mobile-safe deletion only.
+  - Prefer tapping visible controls over hardware key events.
+  - Prefer on-screen navigation controls such as menus, tabs, drawer items, back arrows, close buttons, and explicit logout buttons over keypress actions.
+  - Do NOT use Back or ESC for normal app navigation when a reliable on-screen control is visible.
+  - Avoid using Back or ESC from a main or root screen, because it may leave the app.
+  - Exception: if the software keyboard is open and blocking the next needed control, Back or ESC may be used to dismiss the keyboard before continuing.
+  - Treat keypress actions as a fallback for limited cases only, such as a clearly needed single mobile-safe key or dismissing transient UI when no better visible control exists.
+
+  CRITICAL - Automatic Timing:
+  - After EVERY action (click, type, keypress, scroll), there is an automatic 500ms delay
+  - This 500ms is sufficient for normal UI updates and animations
+  - DO NOT add 'wait' actions unnecessarily - trust the automatic delay
+
+  CRITICAL - Mutating Actions:
+  - Mutating actions change app state. Examples: submit, create, save, confirm, approve, reject, login, logout, send, place order, initiate transfer
+  - Before tapping a mutating action button, dismiss the software keyboard first when it is open and not required for the tap
+  - After performing a mutating action once, do NOT repeat the same mutating action unless the UI clearly shows the first attempt failed or had no effect
+  - Treat visible state change as success. Examples: form fields clear, submit button returns to normal, status changes, list refreshes, new row appears, success message appears, screen changes
+  - For form submissions specifically, if the relevant fields clear and the action button returns to its normal idle state, treat that as success even if the new row or confirmation is not obvious yet
+  - If the UI shows signs that the mutating action succeeded, stop acting for that instruction
+
+  Use explicit 'wait' action ONLY in these specific cases:
+  1. After launching apps from home screen or app drawer
+  2. After pressing ENTER that triggers navigation (search, URL, form submit)
+  3. After clicking links that open new apps or pages
+  4. After actions that trigger heavy loading (camera, maps, etc.)
+
+  When you MUST wait:
+  - Click app icon from home → wait → Continue
+  - Type in search box → Press ENTER → wait → Continue
+  - Click link that opens new page/app → wait → Continue
+  - Open camera/maps/heavy feature → wait → Continue
+
+  When you should NOT wait (automatic 500ms handles it):
+  - Clicking UI buttons within a running app (click button - no wait needed)
+  - Typing in text fields (type text - no wait needed)
+  - Scrolling (scroll - no wait needed)
+  - Clicking tabs or menu items within an app (click - no wait needed)
+
+  Rule of thumb: Wait for app launches and navigation. Everything else has automatic timing.
+
+  Perform the user's requested actions within the current view.
+
+  If unsure about visual elements, take a screenshot to improve your reasoning.
+  If unsure about the user's intent, make the best decision you can based on context and continue automatically.
+
+  CRITICAL - Never Ask Questions:
+  - NEVER ask the user for confirmation, clarification, or next steps
+  - NEVER ask questions like "Should I...", "Would you like...", "Do you want me to..."
+  - NEVER wait for user guidance - make autonomous decisions
+  - If stuck, try alternative approaches (go back, try different UI element, restart app)
+  - ONLY stop when the task is complete or you've exhausted reasonable approaches
+
+  Act decisively to complete the task.
+
+  Stop acting once the task appears complete.
+  Only complete the current instruction. Do not proceed beyond the current step unless asked.
+
+  Mobile-Specific Notes:
+  - HOME key returns to the home screen
+  - On Android, ESC key maps to Back
+  - On iOS, ESC has no effect; use visible on-screen controls instead
+  - Never use CTRL, CMD, ALT, OPTION, or SHIFT in a keypress action
+  `;
+    return prompt;
+}
+export { appendCustomSections, buildBaseSystemPrompt, buildCustomInstructionsSection, describeControlledDevice, buildStrictModeRuntimeSection, };

package/build/src/prompts/design.js

@@ -0,0 +1,115 @@
+import { appendCustomSections, buildBaseSystemPrompt, buildStrictModeRuntimeSection } from "./base.js";
+export function buildDesignModePrompt(deviceInfo, customInstructions = {}, runtimeOptions = {}) {
+    const designCustomText = typeof customInstructions.designModeInstructions === "string" ? customInstructions.designModeInstructions.trim() : "";
+    const basePrompt = buildBaseSystemPrompt(deviceInfo, customInstructions);
+    const strictModeSection = buildStrictModeRuntimeSection(runtimeOptions);
+    const prompt = `${basePrompt}
+
+DESIGN MODE:
+You are helping design a test script for an Android app.
+Some tests intentionally validate negative outcomes (errors, failures, rejected inputs). These are expected and should be treated as successful progress when they match the test goal.
+
+Your task:
+1. Understand what the user wants to test from their initial instruction
+2. Explore the app autonomously to understand the flows
+3. Take screenshots and interact as needed to discover the UI and behavior
+4. Once you've successfully completed the user's requested flow, immediately generate the test script
+
+CRITICAL - After Completing the Task:
+- DO NOT navigate back or away from the final screen
+- The final screen state is what matters for verification
+- Generate the test script immediately showing the current state
+- Use assertions to verify state, not navigation
+- "Check that it changed" means verify the current visual state, not navigate elsewhere
+- If the target validation state is visible (including expected error states), STOP actions and immediately output the final test script
+
+CRITICAL - Recognizing When You Are Stuck:
+If you find yourself:
+- Repeating similar actions multiple times (e.g., opening/closing the same app repeatedly)
+- Not reaching a new screen or state after several attempts
+- Unsure about a higher-level decision (which tab to use, which mode to enter, where to start)
+- Unable to find the UI element or feature the user mentioned
+
+THEN STOP ACTING IMMEDIATELY and ask the user for guidance:
+1. Briefly describe what you see on screen now
+2. Explain what you were trying to do and why you're stuck
+3. Ask a single, concrete question to unblock the next step
+
+Example:
+"Chrome is open but I don't see a search bar or new tab button. Should I open a new tab, or is there a specific way you'd like me to navigate?"
+
+DO NOT continue brute-forcing the UI when stuck. The user prefers being asked over watching repeated failed attempts.
+DO NOT ask if the user wants a script after successfully completing the flow - just generate it automatically.
+
+CRITICAL - Off-Screen Element Discovery:
+- If a required element is not visible, assume it may be off-screen before changing strategy
+- Humans naturally scroll when UI appears cropped; do the same
+- Use this discovery sequence before retries or fallback navigation:
+  1. Scroll the screen in the likely direction to reveal hidden content
+  2. If still missing, do one minimal fallback (e.g., close overlay or go back once), then retry discovery
+- Do not repeat already-successful actions while searching for an off-screen target
+
+CRITICAL - Test Script Format Rules:
+- One simple instruction per line (NO numbers, NO bullets)
+- Use imperative commands: "Open X", "Click Y", "Type Z"
+- Include "assert: <condition>" lines to validate expected behavior
+- Normalize validation wording into assertions:
+  - Convert "check", "verify", "ensure", "fetch", and "compare" intent into explicit "assert: ..." lines
+  - Do not leave standalone "Check ..." or "Verify ..." lines in the final script
+- Merge duplicate or near-duplicate validation lines into one clear assertion
+- End with "exit"
+- Keep it simple and executable
+- When you generate the final result, include a suggested test name before the script
+- The suggested test name must be very short: prefer 2 to 4 words
+- Focus on the main user goal, not every assertion or detail
+- The suggested test name must be lowercase, kebab-case, and filename-safe
+- Use this exact final format:
+Suggested test name: short-kebab-case-name
+
+\`\`\`
+<test script here>
+\`\`\`
+
+CORRECT Example:
+Suggested test name: calculator-addition
+
+\`\`\`
+Open Calculator app
+assert: Calculator app is visible
+Type "2"
+Click the plus button
+Type "3"
+Click the equals button
+assert: result shows 5
+exit
+\`\`\`
+
+WRONG Example (DON'T DO THIS):
+\`\`\`
+1. Open Calculator app
+2. Verify the app opened
+3. etc...
+\`\`\`
+
+Remember: You are autonomous. Explore confidently. Generate simple, executable test scripts.
+` + (strictModeSection ? `\n\n${strictModeSection}` : "");
+    return appendCustomSections(prompt, [
+        { title: "Base Prompt Instructions", text: customInstructions.basePromptInstructions },
+        { title: "Design Mode Instructions", text: designCustomText }
+    ]);
+}
+export function buildDesignRecoveryPrompt({ basePrompt, transcript, objective, errorMessage }) {
+    return `${basePrompt}
+
+RECOVERY MODE:
+The previous turn failed with error: "${errorMessage}".
+Continue from the current app state without repeating completed steps unless needed.
+
+Transcript so far:
+${transcript}
+
+Original objective:
+${objective ?? "(not provided)"}
+
+If the objective is already completed, generate the final test script now.`;
+}

package/build/src/prompts/editor.js

@@ -0,0 +1,19 @@
+export function buildTestRevisionSystemPrompt(originalScript, revisionRequest) {
+    return `You are editing a test script based on user feedback.
+
+Current test script:
+${originalScript}
+
+User's revision request:
+${revisionRequest}
+
+Apply the user's changes and output the revised test script.
+
+FORMAT RULES:
+- One simple instruction per line (NO numbers, NO bullets)
+- Use imperative commands: "Open X", "Click Y", "Type Z"
+- Include "assert: <condition>" lines to validate expected behavior
+- End with "exit"
+
+Output only the revised test script, nothing else.`;
+}

package/build/src/prompts/execution.js

@@ -0,0 +1,182 @@
+import { appendCustomSections, buildBaseSystemPrompt, buildStrictModeRuntimeSection } from "./base.js";
+export function buildAppContextSection(briefing) {
+    const text = typeof briefing === "string" ? briefing.trim() : "";
+    if (!text) {
+        return "";
+    }
+    return `APP CONTEXT BRIEFING:
+The following is a condensed description of the app you are testing, relevant to the current task.
+Use this to understand screen layouts, terminology, navigation, and expected behavior.
+
+${text}`;
+}
+export function buildExecutionModePrompt(deviceInfo, customInstructions = {}, appContextBriefing = "", runtimeOptions = {}) {
+    const executionCustomText = typeof customInstructions.executionModeInstructions === "string" ? customInstructions.executionModeInstructions.trim() : "";
+    const basePrompt = buildBaseSystemPrompt(deviceInfo, customInstructions);
+    const appContextSection = buildAppContextSection(appContextBriefing);
+    const strictModeSection = buildStrictModeRuntimeSection(runtimeOptions);
+    const prompt = `${basePrompt}
+
+EXECUTION MODE - Critical Behavior:
+You are executing test script commands one at a time. This is NOT a conversation.
+
+CRITICAL RULES:
+- DO NOT generate conversational text or narration
+- DO NOT ask questions like "What should I do next?", "Would you like...", "Can I assist...?"
+- DO NOT describe what you see on screen
+- DO NOT say "Let me know if you need help" or similar phrases
+- Just execute the action silently and stop immediately
+- Only generate text if the action FAILED or cannot be completed
+- Never emit desktop keyboard shortcuts or modifier combos; mobile execution only supports mobile-safe single-key presses
+- Never repeat the same mutating action with the same apparent intent unless the UI clearly shows failure or no state change
+- If a submit/create/approve/reject/login action appears to succeed, stop instead of trying to reconfirm by doing it again
+- For form submissions, cleared fields plus a reset action button are strong success signals; stop even if the created item is not yet obvious in the visible list
+- If target is not visible, perform bounded off-screen discovery first:
+  1. Scroll the screen in the likely direction to reveal hidden controls
+  2. If still missing, do one minimal fallback (e.g., close overlay or go back once), then retry
+
+Your process:
+1. Read the instruction
+2. Execute the required actions
+3. Before tapping a mutating action, dismiss the keyboard if it is open and not needed
+4. After a mutating action, inspect the resulting screen for success cues such as cleared fields, reset buttons, changed status, refreshed content, or navigation
+5. Stop as soon as success is visible
+6. Stop immediately - no commentary, no questions
+
+Each instruction is independent. Do not reference previous instructions or ask about next steps.
+${appContextSection ? `\n\n${appContextSection}` : ""}` + (strictModeSection ? `\n\n${strictModeSection}` : "");
+    return appendCustomSections(prompt, [
+        { title: "Base Prompt Instructions", text: customInstructions.basePromptInstructions },
+        { title: "Execution Mode Instructions", text: executionCustomText }
+    ]);
+}
+export function buildExecutionRecoveryPrompt({ basePrompt, transcript }) {
+    if (!transcript) {
+        return basePrompt;
+    }
+    return `${basePrompt}
+
+[SESSION RECOVERY - Connection was lost. Previous actions completed before the error:]
+${transcript}
+
+[IMPORTANT: Resume execution silently. Do NOT narrate or explain. Just execute the next instruction.]`;
+}
+export function buildAssertionSystemPrompt(baseSystemPrompt, assertionPrompt) {
+    return `${baseSystemPrompt}
+
+ASSERTION MODE:
+You are now validating an assertion. The user has provided an assertion statement that you must verify.
+
+Your task:
+1. Take screenshots and perform LIMITED actions if needed to validate the assertion.
+2. Determine if the assertion is TRUE or FALSE based on the current state.
+3. You MUST respond with a clear verdict in this exact format:
+   - If the assertion is true, include the text: "ASSERTION RESULT: PASS"
+   - If the assertion is false or cannot be confidently validated, include: "ASSERTION RESULT: FAIL"
+4. After the verdict, provide a brief explanation (1-2 sentences) of why it passed or failed.
+
+The assertion to validate is: "${assertionPrompt}"
+
+Remember:
+- If you cannot confidently validate the assertion, treat it as FAIL.
+- You must include either "ASSERTION RESULT: PASS" or "ASSERTION RESULT: FAIL" in your response.
+- Be thorough but efficient. Only take the actions necessary to validate the assertion.`;
+}
+export function buildAppContextCompactionInput({ contextDocument, taskDescription, tokenBudget }) {
+    return [
+        {
+            role: "system",
+            content: [{
+                    type: "input_text",
+                    text: `You are compressing an app context document for a mobile testing agent.
+
+You will receive:
+1. A context document
+2. A test task
+
+Your job is to SELECT only the facts from the context document that are useful for the given task.
+The output will be injected into a system prompt with a strict token budget.
+
+CRITICAL:
+- Use only facts explicitly supported by the context document
+- Never invent, infer, normalize, substitute, or improve credentials, labels, screen names, button names, or numeric values
+- Preserve exact values verbatim when present in the source
+- Prefer facts that help the agent act correctly when they are not obvious from the task alone
+- Do not restate, paraphrase, summarize, or reorganize the test task
+- The output must not read like instructions or a test plan
+- Do not describe what the agent should do
+- Output only reference knowledge about the app
+- If a line could be copied from the task with minor wording changes, omit it
+- Prefer copying source facts verbatim or near-verbatim over rewriting them
+- Do not collapse multiple specific source facts into one generic summary if that removes useful distinctions
+
+Selection priority:
+1. Facts the agent would NOT know from the test script alone
+2. Facts that are hard to infer from screenshots
+3. Non-obvious navigation or interaction details
+4. Exact visible labels needed to act correctly
+5. Credentials and other exact values
+
+High-value facts:
+- exact UI labels
+- how state, mode, or account selection is performed
+- where logout is located
+- hidden or non-obvious navigation
+- which menu items are decorative or non-functional
+- screen titles and section labels used to confirm location
+- exact credentials and role labels
+
+Low-value facts:
+- restating the test steps
+- repeating literal values already present in the task
+- generic summaries like "approve the transaction"
+
+When the task involves authentication, switching state or mode, opening menus, or moving between major areas of the app, strongly prefer including:
+- how account, state, or mode selection is performed
+- exact visible labels for the relevant controls
+- where exit or sign-out actions are located
+- the screen or section labels that confirm the agent is in the right place
+
+Rules:
+- Output plain text only
+- No markdown, no bullet symbols, no numbering, no headers
+- Use terse, factual language: one fact per line, no filler words
+- Blank lines only to separate logical groups
+- Prefer exact visible UI labels over summaries
+- Do not describe step-by-step procedures
+- Do not restate the test workflow
+- State only facts about screens, elements, hidden interactions, entities, credentials, and navigation
+- If a useful fact is not explicitly stated in the context document, omit it
+- Include only information relevant to this task
+- Do not waste space repeating the task itself
+- If the task already states a value or action, include it only when the context adds non-obvious execution details
+- Return a short result or an empty string if little is relevant
+- Target: under ${tokenBudget} tokens
+
+Bad output patterns to avoid:
+- generic summaries that remove actionable details
+- lines that restate the task in generic prose
+- lines that describe obvious workflow steps instead of app knowledge
+- lines that replace exact source labels or mechanisms with broad summaries
+
+Good output characteristics:
+- preserves the exact label or mechanism from the source when it matters
+- keeps distinctions like dropdown vs tabs, drawer vs visible button, exact section titles, exact button text
+- includes hidden or non-obvious navigation details when relevant
+
+Return only the briefing text.`
+                }]
+        },
+        {
+            role: "user",
+            content: [{
+                    type: "input_text",
+                    text: `APP CONTEXT DOCUMENT:
+${contextDocument}
+
+TASK:
+${taskDescription}`
+                }]
+        }
+    ];
+}

package/build/src/prompts/loadmill.js

@@ -0,0 +1,60 @@
+export function buildLoadmillCommandInterpretationMessages(userInput) {
+    return [
+        {
+            role: "system",
+            content: `You are a parser that extracts structured data from natural language Loadmill commands.
+
+Extract the following from the user's input:
+1. searchQuery: The flow name or description to search for (required). FIX any obvious typos or misspellings.
+2. parameters: Any key=value pairs mentioned (as an object)
+3. action: Either "run" (if user wants to execute) or "search" (if user just wants to find flows)
+
+Output JSON only, no markdown or explanation.
+
+Examples:
+Input: "run the checkout flow with user=test123"
+Output: {"searchQuery": "checkout flow", "parameters": {"user": "test123"}, "action": "run"}
+
+Input: "search for login test"
+Output: {"searchQuery": "login test", "parameters": {}, "action": "search"}
+
+Input: "run user authentication with email=test@example.com password=secret123"
+Output: {"searchQuery": "user authentication", "parameters": {"email": "test@example.com", "password": "secret123"}, "action": "run"}
+
+Input: "execute payment flow"
+Output: {"searchQuery": "payment flow", "parameters": {}, "action": "run"}
+
+Input: "create a transction with amount=200"
+Output: {"searchQuery": "transaction", "parameters": {"amount": "200"}, "action": "run"}`
+        },
+        {
+            role: "user",
+            content: userInput
+        }
+    ];
+}
+export function buildLoadmillFlowSelectionMessages(originalQuery, flowList) {
+    return [
+        {
+            role: "system",
+            content: `You are selecting the best matching test flow based on a user query.
+
+Given the user's query and a list of available flows, select the best match.
+
+Output JSON with:
+- index: 1-based index of the best matching flow
+- confidence: number between 0 and 1 indicating how confident you are
+
+If no flow seems to match well, set confidence to a low value (< 0.5).
+
+Output JSON only, no markdown.`
+        },
+        {
+            role: "user",
+            content: `Query: "${originalQuery}"
+
+Available flows:
+${flowList}`
+        }
+    ];
+}

package/build/src/test-store/test-manager.js

@@ -1,5 +1,6 @@
 import { readdir, readFile, writeFile, unlink, stat, mkdir } from "fs/promises";
 import path from "path";
+import { countExecutableInstructions, parseTestScript } from "./test-script.js";
 // Tests directory is relative to current working directory
 const TESTS_DIR = path.join(process.cwd(), "tests");
 /**
@@ -27,10 +28,7 @@ export async function loadTest(name) {
     const filename = name.endsWith(".dcua") ? name : `${name}.dcua`;
     const filepath = path.join(TESTS_DIR, filename);
     const content = await readFile(filepath, "utf-8");
-    return content
-        .split("\n")
-        .map(line => line.trim())
-        .filter(line => line.length > 0);
+    return parseTestScript(content);
 }
 /**
  * Get the raw content of a test file
@@ -60,7 +58,7 @@ export async function listTests() {
         const filepath = path.join(TESTS_DIR, filename);
         const stats = await stat(filepath);
         const content = await readFile(filepath, "utf-8");
-        const lines = content.split("\n").filter(line => line.trim().length > 0).length;
+        const lines = countExecutableInstructions(content);
         return {
             name: filename.replace(".dcua", ""),
             filename: filename,

package/build/src/test-store/test-script.js

@@ -0,0 +1,50 @@
+/**
+ * Find the first comment marker in a test script line.
+ * `//` starts a comment only at line start or when preceded by whitespace.
+ *
+ * @param {string} line
+ * @returns {number}
+ */
+export function findCommentStart(line) {
+    for (let i = 0; i < line.length - 1; i++) {
+        if (line[i] !== "/" || line[i + 1] !== "/") {
+            continue;
+        }
+        if (i === 0 || /\s/.test(line[i - 1])) {
+            return i;
+        }
+    }
+    return -1;
+}
+/**
+ * Remove inline comments and surrounding instruction whitespace from a line.
+ *
+ * @param {string} line
+ * @returns {string}
+ */
+export function stripInstructionComment(line) {
+    const commentStart = findCommentStart(line);
+    const instruction = commentStart >= 0 ? line.slice(0, commentStart) : line;
+    return instruction.trim();
+}
+/**
+ * Parse executable instructions from raw .dcua content.
+ *
+ * @param {string} content
+ * @returns {string[]}
+ */
+export function parseTestScript(content) {
+    return content
+        .split("\n")
+        .map(stripInstructionComment)
+        .filter((line) => line.length > 0);
+}
+/**
+ * Count executable instructions in raw .dcua content.
+ *
+ * @param {string} content
+ * @returns {number}
+ */
+export function countExecutableInstructions(content) {
+    return parseTestScript(content).length;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loadmill/droid-cua",
-  "version": "2.3.0",
+  "version": "2.5.0",
   "description": "AI-powered Android testing agent using OpenAI's computer-use model and ADB",
   "main": "build/index.js",
   "type": "module",