orbitx 0.0.7 → 0.0.9

package/dist/skills/shopping.js

@@ -0,0 +1,71 @@
+import Skill from "../core/skill.js";
+import { BrowserTools } from "../tools/browser/index.js";
+import { UtilTools } from "../tools/utils/index.js";
+export const ShoppingSkill = () => new Skill({
+    name: "shopping",
+    description: "Use this skill whenever the user wants help choosing, comparing, or buying a product — 'what's the best X', 'help me find a Y', 'is this a good deal', 'which should I buy', or a request for a specific product recommendation. Drives a real browser to find actual current listings, actual prices, actual direct links, and actual reviews — never recommends from memory or general reputation alone, since prices, models, and availability change constantly. Covers finding and comparing multiple competing options (not just one), surfacing real customer review sentiment (including scrolling to load reviews sections that don't render on initial page load), and giving the user a direct link and price for anything recommended. Trigger this for purchase-decision questions specifically; for general product knowledge questions with no purchase intent ('how does a HEPA filter work'), this skill isn't needed.",
+    tools: [
+        ...BrowserTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# Shopping Skill
+
+## Mindset
+Product recommendations go stale immediately — prices change daily, models get discontinued, "best" lists from training data are often already wrong by the time they're read back. Never recommend a specific product from memory or general brand reputation alone. Every specific product named in a shopping answer needs: a real, currently-open listing, a real current price, a real direct link, and — where the decision is non-trivial — real review evidence actually read from the page, not inferred from the product's category or brand alone.
+
+The job is not "name a good product." The job is "help the user actually buy the right thing" — which means giving them a link they can click, a price they can trust as current, and enough comparative context (competitors, review sentiment, actual tradeoffs) that they're not making the decision on vibes.
+
+## Core loop
+1. Open a browser session (DuckDuckGo or Bing as entry point — not Google, same reasoning as the research skill: it blocks headless browsers). If the user named a specific retailer/site, go straight there instead.
+2. Search for the product category, read the results outline, and open several promising, genuinely different listings — not five results from the same retailer, and not just the first result.
+3. On each listing page, actually read: the current price, the product's real name/model, and whether it's in stock — don't report a price you haven't actually seen rendered on the page in this session, since cached/remembered prices are routinely wrong.
+4. Get the actual review section loaded and read (see "Reviews" below) rather than trusting a star rating alone.
+5. Repeat for at least 2–3 genuinely competing products before making a recommendation — see "Never recommend just one option" below.
+6. Present the comparison with direct links and current prices for everything named.
+
+## Never recommend just one option
+A shopping answer that names a single product with no comparison is not doing the job, even if that product happens to be great. Unless the user has already narrowed to one specific item and just wants a check on it, always surface competitors:
+- Open listings for at least 2–3 realistic alternatives in the same category/price band, not just variations of the same brand.
+- Compare on the dimensions that actually matter for the category (price, key specs, review sentiment, warranty/return policy) rather than an arbitrary feature list.
+- Be explicit about tradeoffs — "A is cheaper but has weaker reviews on durability; B costs more but consistently gets praised for X" — rather than a flat ranked list with no reasoning shown.
+- If the user's ask is narrow ("is this specific product good") rather than "what should I buy," you can lead with a direct answer about that product, but still mention how it stacks up against its obvious alternatives rather than evaluating it in isolation.
+
+## Prices and links — accuracy is the whole point
+- Every price quoted must be one you actually observed rendered on the page during this session. Prices from memory, from a search snippet alone, or extrapolated from an old listing are not acceptable — retailers change prices constantly and a stale number actively misleads a purchase decision.
+- Always give the user the actual URL you found the listing at, not a guessed or reconstructed URL — only link to pages you actually opened and read in this session (never fabricate a plausible-looking product URL).
+- Note the currency and, if relevant to the user's likely location, flag if a price appears to be in a different currency/region than expected.
+- If a price shown seems to be a temporary sale/limited-time deal, say so — don't present a flash-sale price as the item's normal price.
+- If stock status is visible (in stock / limited stock / out of stock / backordered), report it — a great deal on an out-of-stock item isn't actionable.
+- If prices differ noticeably across retailers for what's genuinely the same item, surface the cheapest legitimate option rather than defaulting to whichever site you happened to open first.
+
+## Reviews — read them, don't infer them
+A star rating alone is weak evidence — 4.2 stars can mean "consistently solid" or "half the reviews say it broke in a month and half say it's great," and those are very different signals for a buyer. Actually read review content:
+- **Reviews sections often don't render on initial page load.** Many e-commerce and retailer sites lazy-load the reviews section only once it's scrolled into view, or require clicking a "Reviews" tab/anchor link separately from the main product description. If you read a page and don't see review text (even though a star rating and review count are shown near the top), don't conclude there are no reviews — check whether there's a "Reviews" tab/link to click, and if the page is long, scroll down toward where a review count was shown and re-read, since that section may only populate once it's in view. This is a common trap: an agent that reads only the top of the page and reports "no reviews shown" when reviews exist further down or behind a tab is giving a false negative.
+- After getting the reviews section to actually load, read a real sample — not just the single top-featured/most-helpful review, which retailers sometimes curate. Skim across several individual reviews, and specifically look at a mix of high and low ratings to catch recurring complaints that a single glowing top review would hide.
+- Look for *recurring* specific complaints or praise across multiple reviewers (e.g. several independent reviewers mentioning the same durability issue, or the same standout feature) rather than treating one person's review as representative.
+- If a retailer's on-page reviews look thin, curated, or suspiciously uniform (all 5-star, generic phrasing, no verified-purchase indication), treat that as lower-confidence evidence and consider checking a second, independent source (a different retailer's listing for the same product, or a review-aggregation/comparison site) rather than relying solely on the first one seen.
+- Report review sentiment honestly, including negatives — "mostly positive, but a recurring complaint about X" is more useful and more trustworthy than an uncritical "highly rated" gloss that ignores visible negative signal on the same page.
+
+## Handling pages that need extra interaction to show what you need
+Beyond reviews specifically, several other common shopping-page patterns require action before the real content is visible:
+- **"Show more" / "See all specs" buttons** that collapse full specifications by default — click through rather than reporting only the abbreviated spec list.
+- **Variant selectors** (size, color, storage capacity) that change the displayed price/stock/images when selected — if the user cares about a specific variant, actually select it and re-read rather than reporting the default variant's price as if it applies to all.
+- **Comparison tables** on some retailer sites that require selecting products into a "compare" tray before the table renders — worth doing if the user is choosing between options on the same site.
+- **Pagination or "load more" on review lists** — if you want a broader review sample than the first page shows, page/load further rather than judging sentiment from only the first handful.
+- After any of these interactions, re-read the page — refs and rendered content are stale the moment an interaction changes the DOM, same as any other browser-driven task.
+
+## Handling obstacles
+- Bot checks, CAPTCHAs, or hard login walls on a retailer page: don't fight them — abandon that listing and check the same product on a different retailer.
+- If a retailer's page is slow/JS-heavy and content (price, reviews) looks like it hasn't finished loading, wait briefly and re-check rather than reading a half-loaded page as final — same discipline as the research skill.
+- If you genuinely can't get a real current price or working link for something after reasonable effort, say so plainly rather than presenting a stale or guessed price with unwarranted confidence.
+
+## What a finished shopping answer looks like
+- At least 2–3 real, comparable options (unless the user asked about one specific item) with current prices and direct links to what you actually opened.
+- Honest review sentiment for each, based on actually-read review content — including scrolling/clicking through to reach reviews that weren't visible on first load — not just a star-rating gloss.
+- Clear tradeoffs stated between the options, not just a ranked list with no reasoning.
+- Explicit notes on anything time-sensitive (a sale price, limited stock) so the user knows the information's shelf life.
+`
+});
+export default ShoppingSkill;
+//# sourceMappingURL=shopping.js.map

package/dist/skills/shopping.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"shopping.js","sourceRoot":"","sources":["../../src/skills/shopping.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EAAE,YAAY,EAAE,MAAM,2BAA2B,CAAC;AACzD,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAEpD,MAAM,CAAC,MAAM,aAAa,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IACzC,IAAI,EAAE,UAAU;IAChB,WAAW,EAAE,y4BAAy4B;IACt5B,KAAK,EAAE;QACH,GAAG,YAAY,EAAE;QACjB,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyDjB;CACA,CAAC,CAAC;AAEH,eAAe,aAAa,CAAC"}

package/dist/skills/ui-ux-design.d.ts

@@ -0,0 +1,4 @@
+import Skill from "../core/skill.js";
+export declare const UiUxDesignSkill: () => Skill;
+export default UiUxDesignSkill;
+//# sourceMappingURL=ui-ux-design.d.ts.map

package/dist/skills/ui-ux-design.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"ui-ux-design.d.ts","sourceRoot":"","sources":["../../src/skills/ui-ux-design.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AAMrC,eAAO,MAAM,eAAe,aAgE1B,CAAC;AAEH,eAAe,eAAe,CAAC"}

package/dist/skills/ui-ux-design.js

@@ -0,0 +1,70 @@
+import Skill from "../core/skill.js";
+import { FsTools, } from "../tools/fs/index.js";
+import { UtilTools } from "../tools/utils/index.js";
+export const UiUxDesignSkill = () => new Skill({
+    name: "ui-ux-design",
+    description: "Use this skill whenever building or modifying any user-facing UI — web pages, components, forms, dashboards, landing pages, mobile-web layouts — regardless of framework. Covers visual design quality (layout, spacing, typography, color, hierarchy), interaction design (feedback states, loading/empty/error states, affordances), accessibility, and responsive behavior. Trigger this alongside react-frontend (or any other frontend skill) for any real UI work, not just when the user explicitly asks for 'good design' — a functionally-working but visually generic or inaccessible UI is not production-ready. Also trigger when asked to review, critique, or improve the look/feel/usability of an existing interface.",
+    tools: [
+        ...FsTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# UI/UX Design Skill
+
+## Purpose
+A UI that "works" (renders, handles clicks, doesn't crash) is not the same as a UI that's actually good. This skill is the design-quality pass that happens alongside building the feature, not a separate polish step reserved for later. Generic, default-Bootstrap-looking, inaccessible, or state-incomplete UI is not a finished deliverable even if every button technically fires its handler.
+
+## Core rule
+Never ship a UI as "done" if it only handles the happy path visually — no loading state, no empty state, no error state — or if it's built from unexamined framework defaults with no deliberate visual decisions made. A production UI has been through at least one real design decision on layout, hierarchy, and states; it wasn't just assembled from default component styles and called finished.
+
+## Visual hierarchy and layout
+- Every screen needs one clear primary action/focus — not three equally-weighted buttons competing for attention. Decide what matters most on this screen and make it visually dominant (size, color, position); make secondary actions visually secondary.
+- Use consistent spacing based on a scale (e.g. 4px/8px increments), not arbitrary one-off pixel values scattered across components — inconsistent spacing is one of the fastest ways a UI reads as "unpolished" even when nothing is technically broken.
+- Group related elements with proximity and whitespace rather than borders/dividers for every separation — over-boxing everything reads as cluttered.
+- Respect a consistent grid/alignment — misaligned edges across a page (a card 3px off from the one next to it) are visually cheap to fix and expensive to ignore.
+
+## Typography
+- Limit to 2 typefaces (often just 1 with weight variation) and a deliberate type scale (e.g. 12/14/16/20/24/32px) rather than ad hoc font sizes chosen per-element.
+- Body text needs sufficient line-height (typically 1.4–1.6x font size) and a comfortable measure (line length) — don't let text run edge-to-edge on wide containers; constrain max-width for readability.
+- Don't rely on font size alone for hierarchy — weight, color, and spacing all contribute; a heading that's just "bigger" with the same weight and color as body text often isn't distinct enough.
+
+## Color and contrast
+- Establish a small deliberate palette (primary, secondary/accent, neutral grays, semantic colors for success/warning/error) rather than picking colors ad hoc per component.
+- Check text-to-background contrast meets at least WCAG AA (4.5:1 for normal text, 3:1 for large text) — don't ship light-gray-on-white body text or low-contrast placeholder-style text for actual content.
+- Don't rely on color alone to convey meaning (e.g. red/green only for status) — pair with an icon, label, or pattern so the UI still communicates for colorblind users.
+
+## Interaction and feedback states
+Every interactive element needs its full state set considered, not just the default appearance:
+- **Hover/focus/active/disabled** states for buttons, links, and inputs — a button that looks identical whether it's clickable or disabled is a real usability bug.
+- **Loading state** for anything async (data fetch, form submit) — never leave a screen visually static while something is happening in the background; use a spinner, skeleton, or disabled+labeled button ("Saving...") so the user knows work is in progress.
+- **Empty state** for any list/table/dashboard that can have zero items — a blank white screen with no explanation is a dead end; show a message and, where relevant, a clear next action.
+- **Error state** for anything that can fail (failed fetch, failed validation, failed submit) — surface a specific, human-readable message near the relevant field/section, not just a console error or a generic toast with no detail.
+- Form validation errors should appear near the field they concern and describe what's wrong and how to fix it ("Email must include an @") rather than a generic "Invalid input."
+
+## Accessibility (non-negotiable baseline)
+- All interactive elements must be reachable and operable via keyboard alone (tab order, enter/space to activate) — don't build click-only interactions with a \`div\` + \`onClick\` where a real \`button\`/\`a\` element would give this for free.
+- Use semantic HTML elements (\`button\`, \`nav\`, \`header\`, \`main\`, \`label\`) over generic \`div\`/\`span\` with visual-only styling — screen readers depend on semantics, not appearance.
+- Every form input needs an associated \`label\` (via \`htmlFor\`/\`id\` or wrapping) — a placeholder is not a label and disappears on focus.
+- Every meaningful image needs alt text; purely decorative images should have empty alt (\`alt=""\`) so screen readers skip them rather than reading a filename.
+- Don't trap focus or remove visible focus outlines (\`outline: none\`) without providing a clear visible alternative focus style — keyboard users need to see where they are.
+
+## Responsive behavior
+- Design/verify at minimum three widths: mobile (~375px), tablet (~768px), desktop (~1280px+) — don't build and check only at one viewport and assume the rest follows.
+- Avoid fixed pixel widths on containers that should flex; use relative units and flexible layouts (flexbox/grid) so content reflows rather than overflowing or clipping at smaller widths.
+- Touch targets on mobile-facing UI need adequate size (roughly 44x44px minimum) — don't shrink tappable controls to fit more on screen.
+
+## Avoiding "generic AI-generated UI" look
+- Don't default to purple-gradient-on-white with a centered card and a drop shadow on everything — that's a recognizable unexamined default, not a design decision. Make at least one deliberate, specific visual choice appropriate to the actual product/brand context rather than reaching for the first framework default.
+- Vary visual weight deliberately rather than making every card/section the same size, padding, and shadow — sameness across a page reads as templated.
+- If the user hasn't specified a visual direction, pick one (a specific mood/tone — minimal, playful, editorial, dense-data, etc.) and apply it consistently rather than landing in an undirected middle.
+
+## Verifying the design actually holds up
+Writing the CSS/markup is not the job — confirming it renders and behaves as intended is:
+1. Actually view the rendered result (screenshot, browser tool, or dev server) rather than judging by reading JSX/CSS alone — layout bugs are often invisible in source and obvious on screen.
+2. Check it at multiple viewport widths, not just the one the dev tools happened to default to.
+3. Tab through interactive elements to confirm keyboard operability and visible focus states actually work, not just that they're coded.
+4. Trigger the loading/empty/error states deliberately (e.g. throttle network, submit invalid input, clear a list) to confirm they render as intended rather than assuming the conditional logic is correct from reading it.
+`
+});
+export default UiUxDesignSkill;
+//# sourceMappingURL=ui-ux-design.js.map

package/dist/skills/ui-ux-design.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"ui-ux-design.js","sourceRoot":"","sources":["../../src/skills/ui-ux-design.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EACH,OAAO,GACV,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAEpD,MAAM,CAAC,MAAM,eAAe,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IAC3C,IAAI,EAAE,cAAc;IACpB,WAAW,EAAE,usBAAusB;IACptB,KAAK,EAAE;QACH,GAAG,OAAO,EAAE;QACZ,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwDjB;CACA,CAAC,CAAC;AAEH,eAAe,eAAe,CAAC"}

package/dist/skills/web-end-to-end-test.d.ts

@@ -0,0 +1,4 @@
+import Skill from "../core/skill.js";
+export declare const WebEndToEndTestSkill: () => Skill;
+export default WebEndToEndTestSkill;
+//# sourceMappingURL=web-end-to-end-test.d.ts.map

package/dist/skills/web-end-to-end-test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"web-end-to-end-test.d.ts","sourceRoot":"","sources":["../../src/skills/web-end-to-end-test.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AAKrC,eAAO,MAAM,oBAAoB,aAsE/B,CAAC;AAEH,eAAe,oBAAoB,CAAC"}

package/dist/skills/web-end-to-end-test.js

@@ -0,0 +1,76 @@
+import Skill from "../core/skill.js";
+import { BrowserTools } from "../tools/browser/index.js";
+import { UtilTools } from "../tools/utils/index.js";
+export const WebEndToEndTestSkill = () => new Skill({
+    name: "web-end-to-end-test",
+    description: "Use this skill whenever the user asks to test, check, verify, QA, or confirm that a website or web application actually works — a login flow, a form, a checkout, a button, a newly built feature, a bug fix, or any user-facing behavior on a live or locally-running web app. Also use this proactively right after building or changing a frontend or full-stack feature, before calling it done — not just when explicitly asked to test. Drives a real headless browser to act like an actual user: fills forms, clicks buttons, navigates, and then verifies the real outcome via the rendered page, console errors, and network requests/responses — never by reading source code and assuming it works. Covers both the UI layer (does it render/click/navigate correctly) and the API layer it talks to (does the backend actually receive the right request and respond correctly) — trigger this for full-stack verification, not just visual checks. Trigger this any time \"does it work\", \"test this\", or \"make sure X happens when Y\" applies to a running web app rather than to static code review.",
+    tools: [
+        ...BrowserTools(),
+        ...UtilTools()
+    ],
+    instructions: `
+# Web End-to-End Test Skill
+
+## Before you start: know what "pass" means
+Before touching the browser, be explicit (to yourself, and to the user if it's ambiguous) about what you're testing and what a pass looks like. "Test the login form" is vague — pin it down: "submitting valid credentials navigates to /dashboard and shows the user's name; submitting invalid credentials shows an error message and stays on /login." Vague test goals produce vague, unreliable verdicts. If the ask is genuinely ambiguous about scope (one flow vs. the whole app) or environment (which URL/port), ask before starting rather than guessing.
+
+This skill pairs with code-verification (typecheck/build/lint clean before you even open a browser) — don't use browser-driven testing as a substitute for a basic static check; use both. code-verification catches "doesn't compile"; this skill catches "compiles but doesn't actually behave correctly."
+
+## Core loop
+1. **Open a session** at the app's URL and keep its session id for the whole test.
+2. **Read the page** to get an outline of the UI with reference ids for every element you'll need to interact with. You act only on refs you actually read — never guess a selector.
+3. **Drive the interaction exactly like a real user would**: fill fields, click buttons and links, submit forms. For a form with no visible submit button, submit it the way a real user still could — via enter-to-submit on a field, or a direct form submission.
+4. **Re-read after every state-changing action.** Never assume a click worked. Take a fresh read and inspect the new state — refs from before the action are stale the instant the DOM changes, so don't reuse them.
+5. **Assert on real evidence, not assumptions** — see below.
+6. **Report a clear verdict per scenario**: pass or fail, with the concrete evidence observed (what the page showed, what console/network showed) — never just "it seems to work."
+
+## Workflow order: real functionality first, then stop and offer more
+When this skill runs at the end of building or changing a feature, test in this order and don't skip ahead:
+1. **First, verify the real, intended functionality actually works** — the happy path a genuine user would take, end to end, with valid realistic input. This is the test that matters most and is never optional.
+2. **Once the real functionality is confirmed working, stop iterating and report.** Give the user a clear pass/fail verdict on what they asked you to build, with the evidence observed.
+3. **Then separately offer, don't just do, further testing**: tell the user something like "if you want, I can also test some invalid-input/edge-case and basic security handling on the frontend." Don't launch into a long negative-testing pass unprompted — it burns time and tool calls the user may not want yet, and premature edge-case failures can distract from confirming the actual feature works at all.
+4. **Only run negative/edge-case/security testing after the user says yes** (or if they asked for it as part of the original request up front). When they do confirm, keep it to basic, frontend-facing checks — this is not a substitute for a dedicated security audit (see backend-security for that).
+
+## What counts as evidence
+Never conclude "it works" just because an action didn't visibly error. Confirm the actual expected outcome:
+- **Visible outcome**: re-read the page and check the outline genuinely shows what should be there — a success message, the new URL's content, a newly-rendered element, an item now present in a list.
+- **Console output**: check for logged JS errors a user wouldn't see but that indicate something broke silently. An action that "completes" but throws a console error afterward is not a pass.
+- **Network activity**: for anything that should hit an API (form submit, add-to-cart, save), confirm the request was actually sent and that the response status/body match what's expected. A button that looks like it worked but never called the API is a classic silent failure this catches.
+- **Load state**: before asserting on a page's content, make sure the page has actually finished loading and isn't still mid-request — especially on JS-heavy apps where content renders asynchronously after navigation. If it's still loading, wait briefly and recheck rather than reading too early.
+
+## Timing: don't mistake "not rendered yet" for "broken"
+This is the single most common false-positive in this skill: reading the page immediately after an action, seeing no error message and no success message either, and concluding the app is broken — when the truth is the request/response/re-render simply hadn't landed yet. Before you report any failure that looks like "expected error/success message never appeared" or "the app just sat there and did nothing", stop and rule out timing first:
+1. **Check network status before trusting a "nothing happened" read.** If browser-network-status still reports \`loading\`, or you never explicitly checked it, that's not evidence of a bug — it's evidence you read too early. Wait briefly and re-read before drawing any conclusion.
+2. **Never read exactly once and decide.** If the first re-read after an action shows no visible change, wait a short beat and read again (once, maybe twice) before concluding anything is wrong. A single immediate read that finds nothing is not a failed assertion — it's an incomplete one.
+3. **Don't overcorrect into a stall either.** This cuts both ways: don't loop indefinitely re-reading the same page hoping something eventually appears. A couple of short, deliberate re-checks (confirming network is idle, then reading) is enough — if the expected outcome still isn't there after that, check console and network activity for the real cause (see "Investigating a failure" below) instead of continuing to poll blindly.
+4. **When in doubt about whether "no error appeared" means pass or means "too early", check the concrete signal, not the absence of one.** "The error message isn't on the page" only means the app is broken if you've also confirmed the request actually completed (network idle, response received) and the render had a chance to happen. If either of those hasn't happened yet, that's the actual reason nothing showed up — go verify it, don't guess.
+5. **Same logic applies to slow-appearing errors on invalid input.** A validation error that renders after the request round-trip completes is not "the error didn't appear" if you checked before the round-trip finished — confirm network idle first, then check for the message.
+
+## Backend/API-layer verification (not just the UI)
+A UI test that only checks "did the page show a success message" can miss a backend that silently no-oped, wrote the wrong data, or returned a misleading status. When the flow under test involves a real backend, verify both sides:
+- **Confirm the actual request sent**, not just that one was sent — check the network activity for method, endpoint, and payload, and sanity-check the payload matches what the form/action should have produced (right field names, right values, not sending stale/empty data).
+- **Confirm the actual response**, not just "no error was thrown" — check the status code is what's expected (200/201 for success, proper 4xx for a deliberately invalid submission — not a 200 with an error buried in the body, unless that's genuinely the API's documented contract) and that the response body contains what the UI then rendered, rather than assuming the UI's display is an accurate reflection of what the server actually returned.
+- **Where feasible, verify server-side state directly** rather than only trusting the UI's re-render as proof — e.g. if there's an accessible way to query the backend/DB state directly (an admin endpoint, a status API, a way to run a query via bash-run against a local dev DB), confirm the write actually persisted rather than inferring it purely from the client re-rendering an optimistic update that hasn't actually been confirmed by the server.
+- **Test the API's error handling directly, not just via the UI**: if the environment allows issuing a raw request (e.g. \`curl\` via bash-run, or a direct fetch from the browser tools) with a deliberately malformed/unauthorized payload, do so, and confirm the backend rejects it correctly — a UI that happens to only ever send valid data can mask a backend that has no real server-side validation at all (see backend-security for what proper validation looks like).
+- If the frontend and backend are both something you built in this session, don't let a clean-looking UI substitute for confirming the backend actually did the right thing — the UI can be wrong about what happened, especially if it optimistically updates before the server confirms.
+
+## Negative / edge case testing (only after confirming real functionality, and only if the user wants it)
+Don't test only the happy path when this step is in scope. For any input field, try: empty submission, obviously invalid input (bad email format, out-of-range number), and boundary values — then confirm the app's error handling actually surfaces a message to the user (check the re-read outline for an error string) rather than silently failing or crashing (check console for a thrown error). Where a backend is involved, also confirm the *server* rejected the invalid input (see above) rather than only checking that the frontend's own client-side validation caught it — client-side-only validation that passes this test but has no server-side counterpart is a real gap to flag, not a pass.
+
+## Investigating a failure
+When something doesn't behave as expected:
+1. Re-read the page to see the actual current state.
+2. Check console output for a thrown error explaining what happened.
+3. Check network activity to see if a request was even sent, and if so, whether the server returned an error status or unexpected body.
+4. If the backend is available to inspect directly (logs, a local dev server's own console output via bash-logs), check there too — a frontend-only investigation can miss that the real failure was a server-side exception that got swallowed into a generic error response.
+5. Inspect page internals directly only as a last resort, for something the outline genuinely can't show (e.g. a specific JS variable's value) — don't use this to drive the test itself, since that stops testing the real user-facing UI.
+Report the root cause found, not just "the test failed."
+
+## Hygiene
+- Use one session per logical test flow so navigation/interaction history stays coherent. Open a fresh session for an unrelated flow (e.g. testing signup vs. testing checkout as an already-logged-in user) so state from one doesn't leak into the other.
+- Always close a session once its test flow is complete.
+- If you started a backend dev server specifically to run this test (rather than testing against something already running), stop it once verification is complete, consistent with node-backend's/react-frontend's own process hygiene — don't leave test-only processes running indefinitely.
+`
+});
+export default WebEndToEndTestSkill;
+//# sourceMappingURL=web-end-to-end-test.js.map

package/dist/skills/web-end-to-end-test.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"web-end-to-end-test.js","sourceRoot":"","sources":["../../src/skills/web-end-to-end-test.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,kBAAkB,CAAC;AACrC,OAAO,EAAE,YAAY,EAAE,MAAM,2BAA2B,CAAC;AACzD,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAGpD,MAAM,CAAC,MAAM,oBAAoB,GAAG,GAAG,EAAE,CAAC,IAAI,KAAK,CAAC;IAChD,IAAI,EAAE,qBAAqB;IAC3B,WAAW,EAAE,2jCAA2jC;IACxkC,KAAK,EAAE;QACH,GAAG,YAAY,EAAE;QACjB,GAAG,SAAS,EAAE;KACjB;IACD,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA8DjB;CACA,CAAC,CAAC;AAEH,eAAe,oBAAoB,CAAC"}

package/dist/templates/simple.d.ts

@@ -6,7 +6,7 @@ import type Skill from "../core/skill.js";
 export declare class SimpleAgent extends BaseAgent {
     constructor({ aiProvider, instruction, tools, skills, maxMemorizeToken, initData }: {
         instruction: string;
-        tools: MCPTool[];
+        tools?: MCPTool<any>[];
         aiProvider: AIProvider;
         skills?: Skill[];
         maxMemorizeToken?: number;

package/dist/templates/simple.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"simple.d.ts","sourceRoot":"","sources":["../../src/templates/simple.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,wBAAwB,CAAC;AACtD,OAAO,KAAK,UAAU,MAAM,wBAAwB,CAAC;AACrD,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAC9C,OAAO,KAAK,OAAO,MAAM,gBAAgB,CAAC;AAI1C,OAAO,KAAK,KAAK,MAAM,kBAAkB,CAAC;AAE1C,qBAAa,WAAY,SAAQ,SAAS;gBAC1B,EACR,UAAU,EACV,WAAgB,EAChB,KAAU,EACV,MAAW,EACX,gBAAwB,EACxB,QAUC,EACJ,EAAE;QACC,WAAW,EAAE,MAAM,CAAC;QACpB,KAAK,EAAE,OAAO,EAAE,CAAC;QACjB,UAAU,EAAE,UAAU,CAAC;QACvB,MAAM,CAAC,EAAE,KAAK,EAAE,CAAC;QACjB,gBAAgB,CAAC,EAAE,MAAM,CAAC;QAC1B,QAAQ,CAAC,EAAE;YACP,MAAM,EAAE,MAAM,CAAC;YACf,YAAY,EAAE,OAAO,EAAE,CAAC;YACxB,mBAAmB,EAAE,MAAM,CAAC;YAC5B,kBAAkB,EAAE,MAAM,CAAC;YAC3B,gBAAgB,EAAE,MAAM,CAAC;YACzB,eAAe,EAAE,OAAO,EAAE,CAAC;YAC3B,sBAAsB,EAAE,MAAM,CAAC;YAC/B,qBAAqB,EAAE,MAAM,CAAC;YAC9B,mBAAmB,EAAE,MAAM,CAAC;SAC/B,CAAA;KACJ;CAiBJ;AAED,eAAe,WAAW,CAAC"}
+{"version":3,"file":"simple.d.ts","sourceRoot":"","sources":["../../src/templates/simple.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,wBAAwB,CAAC;AACtD,OAAO,KAAK,UAAU,MAAM,wBAAwB,CAAC;AACrD,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAC9C,OAAO,KAAK,OAAO,MAAM,gBAAgB,CAAC;AAI1C,OAAO,KAAK,KAAK,MAAM,kBAAkB,CAAC;AAE1C,qBAAa,WAAY,SAAQ,SAAS;gBAC1B,EACR,UAAU,EACV,WAAgB,EAChB,KAAU,EACV,MAAW,EACX,gBAAwB,EACxB,QAUC,EACJ,EAAE;QACC,WAAW,EAAE,MAAM,CAAC;QACpB,KAAK,CAAC,EAAE,OAAO,CAAC,GAAG,CAAC,EAAE,CAAC;QACvB,UAAU,EAAE,UAAU,CAAC;QACvB,MAAM,CAAC,EAAE,KAAK,EAAE,CAAC;QACjB,gBAAgB,CAAC,EAAE,MAAM,CAAC;QAC1B,QAAQ,CAAC,EAAE;YACP,MAAM,EAAE,MAAM,CAAC;YACf,YAAY,EAAE,OAAO,EAAE,CAAC;YACxB,mBAAmB,EAAE,MAAM,CAAC;YAC5B,kBAAkB,EAAE,MAAM,CAAC;YAC3B,gBAAgB,EAAE,MAAM,CAAC;YACzB,eAAe,EAAE,OAAO,EAAE,CAAC;YAC3B,sBAAsB,EAAE,MAAM,CAAC;YAC/B,qBAAqB,EAAE,MAAM,CAAC;YAC9B,mBAAmB,EAAE,MAAM,CAAC;SAC/B,CAAA;KACJ;CAsBJ;AAED,eAAe,WAAW,CAAC"}

package/dist/templates/simple.js

@@ -19,6 +19,10 @@ export class SimpleAgent extends BaseAgent {
         tools.forEach(tool => {
             mcpServer.registerTool(tool);
         });
+        [...new Set(skills.flatMap(s => s.getSkill().tools))].filter(t => !tools.includes(t)).forEach(tool => {
+            mcpServer.registerTool(tool);
+            tools.push(tool);
+        });
         const mcpClient = new MCPClient("DEFAULT_ENV", conn);
         super({
             aiProvider,

package/dist/templates/simple.js.map

@@ -1 +1 @@
-{"version":3,"file":"simple.js","sourceRoot":"","sources":["../../src/templates/simple.ts"],"names":[],"mappings":"AAEA,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAE9C,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAC9C,OAAO,aAAa,MAAM,2BAA2B,CAAC;AACtD,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAG9C,MAAM,OAAO,WAAY,SAAQ,SAAS;IACtC,YAAY,EACR,UAAU,EACV,WAAW,GAAG,EAAE,EAChB,KAAK,GAAG,EAAE,EACV,MAAM,GAAG,EAAE,EACX,gBAAgB,GAAG,KAAK,EACxB,QAAQ,GAAG;QACP,MAAM,EAAE,EAAE;QACV,YAAY,EAAE,EAAE;QAChB,mBAAmB,EAAE,CAAC;QACtB,kBAAkB,EAAE,CAAC;QACrB,gBAAgB,EAAE,CAAC;QACnB,eAAe,EAAE,EAAE;QACnB,sBAAsB,EAAE,CAAC;QACzB,qBAAqB,EAAE,CAAC;QACxB,mBAAmB,EAAE,CAAC;KACzB,EAkBJ;QACG,MAAM,IAAI,GAAG,IAAI,aAAa,EAAE,CAAC;QACjC,MAAM,SAAS,GAAG,IAAI,SAAS,CAAC,IAAI,CAAC,CAAC;QACtC,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,EAAE;YACjB,SAAS,CAAC,YAAY,CAAC,IAAI,CAAC,CAAC;QACjC,CAAC,CAAC,CAAC;QACH,MAAM,SAAS,GAAG,IAAI,SAAS,CAAC,aAAa,EAAE,IAAI,CAAC,CAAC;QACrD,KAAK,CAAC;YACF,UAAU;YACV,WAAW;YACX,SAAS;YACT,YAAY,EAAE,KAAK;YACnB,MAAM;YACN,gBAAgB;YAChB,QAAQ;SACX,CAAC,CAAC;IACP,CAAC;CACJ;AAED,eAAe,WAAW,CAAC"}
+{"version":3,"file":"simple.js","sourceRoot":"","sources":["../../src/templates/simple.ts"],"names":[],"mappings":"AAEA,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAE9C,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAC9C,OAAO,aAAa,MAAM,2BAA2B,CAAC;AACtD,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAG9C,MAAM,OAAO,WAAY,SAAQ,SAAS;IACtC,YAAY,EACR,UAAU,EACV,WAAW,GAAG,EAAE,EAChB,KAAK,GAAG,EAAE,EACV,MAAM,GAAG,EAAE,EACX,gBAAgB,GAAG,KAAK,EACxB,QAAQ,GAAG;QACP,MAAM,EAAE,EAAE;QACV,YAAY,EAAE,EAAE;QAChB,mBAAmB,EAAE,CAAC;QACtB,kBAAkB,EAAE,CAAC;QACrB,gBAAgB,EAAE,CAAC;QACnB,eAAe,EAAE,EAAE;QACnB,sBAAsB,EAAE,CAAC;QACzB,qBAAqB,EAAE,CAAC;QACxB,mBAAmB,EAAE,CAAC;KACzB,EAkBJ;QACG,MAAM,IAAI,GAAG,IAAI,aAAa,EAAE,CAAC;QACjC,MAAM,SAAS,GAAG,IAAI,SAAS,CAAC,IAAI,CAAC,CAAC;QACtC,KAAK,CAAC,OAAO,CAAC,IAAI,CAAC,EAAE;YACjB,SAAS,CAAC,YAAY,CAAC,IAAI,CAAC,CAAC;QACjC,CAAC,CAAC,CAAC;QACH,CAAC,GAAG,IAAI,GAAG,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,QAAQ,EAAE,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,IAAI,CAAC,EAAE;YACjG,SAAS,CAAC,YAAY,CAAC,IAAI,CAAC,CAAC;YAC7B,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QACrB,CAAC,CAAC,CAAC;QAEH,MAAM,SAAS,GAAG,IAAI,SAAS,CAAC,aAAa,EAAE,IAAI,CAAC,CAAC;QACrD,KAAK,CAAC;YACF,UAAU;YACV,WAAW;YACX,SAAS;YACT,YAAY,EAAE,KAAK;YACnB,MAAM;YACN,gBAAgB;YAChB,QAAQ;SACX,CAAC,CAAC;IACP,CAAC;CACJ;AAED,eAAe,WAAW,CAAC"}

package/dist/tests/mcp.test.js

@@ -1,55 +1,3 @@
-import { describe, test } from "node:test";
-import assert from "node:assert/strict";
-import os from "os";
-import MCPIPCConnection from "../core/mcp-ipc-connection.js";
-import MCPServer from "../core/mcp-server.js";
-import MCPClient from "../core/mcp-client.js";
-import { GetCurrentTimeTool } from "../tools/utils/index.js";
-import { FetchTool, WebSearchTool } from "../tools/www/index.js";
-describe("MCP Client and Server", async () => {
-    const path1 = os.platform() == "win32" ? `\\\\.\\pipe\\test${Math.random() * 1000}` : `/tmp/mcp_test${Math.random() * 1000}.sock`;
-    const path2 = os.platform() == "win32" ? `\\\\.\\pipe\\test${Math.random() * 1000}` : `/tmp/mcp_test${Math.random() * 1000}.sock`;
-    const ipcConnection11 = new MCPIPCConnection(path1);
-    const ipcConnection21 = new MCPIPCConnection(path2);
-    const ipcConnection12 = new MCPIPCConnection(path1);
-    const ipcConnection22 = new MCPIPCConnection(path2);
-    let mcpServer1;
-    let mcpServer2;
-    let mcpClient;
-    await test("should connect MCP Client to Servers and get empty tools", async () => {
-        mcpServer1 = new MCPServer(ipcConnection11);
-        mcpServer2 = new MCPServer(ipcConnection21);
-        mcpClient = new MCPClient("DEFAULT_ENV", [ipcConnection12, ipcConnection22]);
-        const result = await mcpClient.getTools();
-        assert.equal(result.length, 0);
-    });
-    await test("should register tool on client side", async () => {
-        mcpClient.registerTool(GetCurrentTimeTool);
-        const result = await mcpClient.getTools();
-        assert.equal(result.length, 1);
-    });
-    await test("should register tool on server1 side", async () => {
-        mcpServer1.registerTool(FetchTool);
-        const result = await mcpClient.getTools();
-        assert.equal(result.length, 2);
-    });
-    await test("should register tool on server2 side", async () => {
-        mcpServer2.registerTool(WebSearchTool);
-        const result = await mcpClient.getTools();
-        assert.equal(result.length, 3);
-    });
-    await test("should call tool on client side", async () => {
-        const result = await mcpClient.callTool(GetCurrentTimeTool.getOptions().name, {});
-        assert.ok(typeof result == "string");
-    });
-    await test("should call tool on server1 side", async () => {
-        const result = await mcpClient.callTool(FetchTool.getOptions().name, { url: "https://google.com" });
-        assert.ok(typeof result == "string");
-    });
-    await test("should call tool on server2 side", async () => {
-        const result = await mcpClient.callTool(WebSearchTool.getOptions().name, { query: "test" });
-        assert.ok(typeof result == "string");
-    });
-    // Need Close Connections
-});
+export {};
+// TODO need to write new TEST files later
 //# sourceMappingURL=mcp.test.js.map

package/dist/tests/mcp.test.js.map

@@ -1 +1 @@
-{"version":3,"file":"mcp.test.js","sourceRoot":"","sources":["../../src/tests/mcp.test.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAC3C,OAAO,MAAM,MAAM,oBAAoB,CAAC;AACxC,OAAO,EAAE,MAAM,IAAI,CAAC;AACpB,OAAO,gBAAgB,MAAM,+BAA+B,CAAC;AAC7D,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAC9C,OAAO,SAAS,MAAM,uBAAuB,CAAC;AAC9C,OAAO,EAAE,kBAAkB,EAAE,MAAM,yBAAyB,CAAC;AAC7D,OAAO,EAAE,SAAS,EAAE,aAAa,EAAE,MAAM,uBAAuB,CAAC;AAEjE,QAAQ,CAAC,uBAAuB,EAAE,KAAK,IAAI,EAAE;IACzC,MAAM,KAAK,GAAG,EAAE,CAAC,QAAQ,EAAE,IAAI,OAAO,CAAC,CAAC,CAAC,oBAAoB,IAAI,CAAC,MAAM,EAAE,GAAG,IAAI,EAAE,CAAC,CAAC,CAAC,gBAAgB,IAAI,CAAC,MAAM,EAAE,GAAG,IAAI,OAAO,CAAC;IAClI,MAAM,KAAK,GAAG,EAAE,CAAC,QAAQ,EAAE,IAAI,OAAO,CAAC,CAAC,CAAC,oBAAoB,IAAI,CAAC,MAAM,EAAE,GAAG,IAAI,EAAE,CAAC,CAAC,CAAC,gBAAgB,IAAI,CAAC,MAAM,EAAE,GAAG,IAAI,OAAO,CAAC;IAElI,MAAM,eAAe,GAAG,IAAI,gBAAgB,CAAC,KAAK,CAAC,CAAC;IACpD,MAAM,eAAe,GAAG,IAAI,gBAAgB,CAAC,KAAK,CAAC,CAAC;IAEpD,MAAM,eAAe,GAAG,IAAI,gBAAgB,CAAC,KAAK,CAAC,CAAC;IACpD,MAAM,eAAe,GAAG,IAAI,gBAAgB,CAAC,KAAK,CAAC,CAAC;IAEpD,IAAI,UAAqB,CAAC;IAC1B,IAAI,UAAqB,CAAC;IAC1B,IAAI,SAAoB,CAAC;IAEzB,MAAM,IAAI,CAAC,0DAA0D,EAAE,KAAK,IAAI,EAAE;QAC9E,UAAU,GAAG,IAAI,SAAS,CAAC,eAAe,CAAC,CAAC;QAC5C,UAAU,GAAG,IAAI,SAAS,CAAC,eAAe,CAAC,CAAC;QAC5C,SAAS,GAAG,IAAI,SAAS,CAAC,aAAa,EAAE,CAAC,eAAe,EAAE,eAAe,CAAC,CAAC,CAAC;QAC7E,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,QAAQ,EAAE,CAAC;QAC1C,MAAM,CAAC,KAAK,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC,CAAC,CAAC;IACnC,CAAC,CAAC,CAAC;IAEH,MAAM,IAAI,CAAC,qCAAqC,EAAE,KAAK,IAAI,EAAE;QACzD,SAAS,CAAC,YAAY,CAAC,kBAAkB,CAAC,CAAC;QAC3C,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,QAAQ,EAAE,CAAC;QAE1C,MAAM,CAAC,KAAK,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC,CAAC,CAAC;IACnC,CAAC,CAAC,CAAC;IAEH,MAAM,IAAI,CAAC,sCAAsC,EAAE,KAAK,IAAI,EAAE;QAC1D,UAAU,CAAC,YAAY,CAAC,SAAS,CAAC,CAAC;QACnC,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,QAAQ,EAAE,CAAC;QAE1C,MAAM,CAAC,KAAK,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC,CAAC,CAAC;IACnC,CAAC,CAAC,CAAC;IAEH,MAAM,IAAI,CAAC,sCAAsC,EAAE,KAAK,IAAI,EAAE;QAC1D,UAAU,CAAC,YAAY,CAAC,aAAa,CAAC,CAAC;QACvC,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,QAAQ,EAAE,CAAC;QAE1C,MAAM,CAAC,KAAK,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC,CAAC,CAAC;IACnC,CAAC,CAAC,CAAC;IAEH,MAAM,IAAI,CAAC,iCAAiC,EAAE,KAAK,IAAI,EAAE;QACrD,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,QAAQ,CAAC,kBAAkB,CAAC,UAAU,EAAE,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;QAElF,MAAM,CAAC,EAAE,CAAC,OAAO,MAAM,IAAI,QAAQ,CAAC,CAAC;IACzC,CAAC,CAAC,CAAC;IAEH,MAAM,IAAI,CAAC,kCAAkC,EAAE,KAAK,IAAI,EAAE;QACtD,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,QAAQ,CAAC,SAAS,CAAC,UAAU,EAAE,CAAC,IAAI,EAAE,EAAE,GAAG,EAAE,oBAAoB,EAAE,CAAC,CAAC;QAEpG,MAAM,CAAC,EAAE,CAAC,OAAO,MAAM,IAAI,QAAQ,CAAC,CAAC;IACzC,CAAC,CAAC,CAAC;IAEH,MAAM,IAAI,CAAC,kCAAkC,EAAE,KAAK,IAAI,EAAE;QACtD,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,QAAQ,CAAC,aAAa,CAAC,UAAU,EAAE,CAAC,IAAI,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,CAAC,CAAC;QAE5F,MAAM,CAAC,EAAE,CAAC,OAAO,MAAM,IAAI,QAAQ,CAAC,CAAC;IACzC,CAAC,CAAC,CAAC;IAGH,yBAAyB;AAC7B,CAAC,CAAC,CAAC"}
+{"version":3,"file":"mcp.test.js","sourceRoot":"","sources":["../../src/tests/mcp.test.ts"],"names":[],"mappings":";AAAA,0CAA0C"}

package/dist/tools/bash/index.d.ts

@@ -0,0 +1,10 @@
+export { BashRunTool } from "./run.js";
+export { BashWaitTool } from "./wait.js";
+export { BashLogsTool } from "./logs.js";
+export { BashListTool } from "./list.js";
+export { BashWriteInputTool } from "./write-input.js";
+export { BashTerminateTool } from "./terminate.js";
+export { BashInteraction } from "./interaction.js";
+export type { BashEvent } from "./interaction.js";
+export declare const BashTools: () => (import("../../index.js").MCPTool<undefined> | import("../../index.js").MCPTool<import("./interaction.js").BashInteraction>)[];
+//# sourceMappingURL=index.d.ts.map

package/dist/tools/bash/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../src/tools/bash/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AACvC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,kBAAkB,EAAE,MAAM,kBAAkB,CAAC;AACtD,OAAO,EAAE,iBAAiB,EAAE,MAAM,gBAAgB,CAAC;AACnD,OAAO,EAAE,eAAe,EAAE,MAAM,kBAAkB,CAAC;AACnD,YAAY,EAAE,SAAS,EAAE,MAAM,kBAAkB,CAAC;AAWlD,eAAO,MAAM,SAAS,sIAOrB,CAAC"}

package/dist/tools/bash/index.js

@@ -0,0 +1,22 @@
+export { BashRunTool } from "./run.js";
+export { BashWaitTool } from "./wait.js";
+export { BashLogsTool } from "./logs.js";
+export { BashListTool } from "./list.js";
+export { BashWriteInputTool } from "./write-input.js";
+export { BashTerminateTool } from "./terminate.js";
+export { BashInteraction } from "./interaction.js";
+import { BashRunTool } from "./run.js";
+import { BashWaitTool } from "./wait.js";
+import { BashLogsTool } from "./logs.js";
+import { BashListTool } from "./list.js";
+import { BashWriteInputTool } from "./write-input.js";
+import { BashTerminateTool } from "./terminate.js";
+export const BashTools = () => [
+    BashRunTool(),
+    BashWaitTool(),
+    BashLogsTool(),
+    BashListTool(),
+    BashWriteInputTool(),
+    BashTerminateTool()
+];
+//# sourceMappingURL=index.js.map

package/dist/tools/bash/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../src/tools/bash/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AACvC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,kBAAkB,EAAE,MAAM,kBAAkB,CAAC;AACtD,OAAO,EAAE,iBAAiB,EAAE,MAAM,gBAAgB,CAAC;AACnD,OAAO,EAAE,eAAe,EAAE,MAAM,kBAAkB,CAAC;AAInD,OAAO,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AACvC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,YAAY,EAAE,MAAM,WAAW,CAAC;AACzC,OAAO,EAAE,kBAAkB,EAAE,MAAM,kBAAkB,CAAC;AACtD,OAAO,EAAE,iBAAiB,EAAE,MAAM,gBAAgB,CAAC;AAGnD,MAAM,CAAC,MAAM,SAAS,GAAG,GAAG,EAAE,CAAC;IAC3B,WAAW,EAAE;IACb,YAAY,EAAE;IACd,YAAY,EAAE;IACd,YAAY,EAAE;IACd,kBAAkB,EAAE;IACpB,iBAAiB,EAAE;CACtB,CAAC"}

package/dist/tools/bash/interaction.d.ts

@@ -0,0 +1,29 @@
+import { MCPCustomClass } from "../../core/mcp.js";
+export type BashEvent = {
+    type: "process-started";
+    processId: string;
+    command: string;
+} | {
+    type: "waiting";
+    processId: string;
+} | {
+    type: "input-sent";
+    processId: string;
+} | {
+    type: "terminated";
+    processId: string;
+} | {
+    type: "process-exited";
+    processId: string;
+    exitCode: number | null;
+};
+/**
+ * Shared custom interaction class for all bash tools. A frontend can listen
+ * on getEvents() to reflect live process activity (e.g. "Running npm run
+ * dev...", "Waiting for build to finish...") without polling.
+ */
+export declare class BashInteraction extends MCPCustomClass {
+    emitBashEvent(event: BashEvent): void;
+}
+export default BashInteraction;
+//# sourceMappingURL=interaction.d.ts.map

package/dist/tools/bash/interaction.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"interaction.d.ts","sourceRoot":"","sources":["../../../src/tools/bash/interaction.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAE,MAAM,mBAAmB,CAAC;AAEnD,MAAM,MAAM,SAAS,GACf;IAAE,IAAI,EAAE,iBAAiB,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,GAC/D;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,SAAS,EAAE,MAAM,CAAA;CAAE,GACtC;IAAE,IAAI,EAAE,YAAY,CAAC;IAAC,SAAS,EAAE,MAAM,CAAA;CAAE,GACzC;IAAE,IAAI,EAAE,YAAY,CAAC;IAAC,SAAS,EAAE,MAAM,CAAA;CAAE,GACzC;IAAE,IAAI,EAAE,gBAAgB,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,CAAC;AAE7E;;;;GAIG;AACH,qBAAa,eAAgB,SAAQ,cAAc;IAC/C,aAAa,CAAC,KAAK,EAAE,SAAS;CAGjC;AAED,eAAe,eAAe,CAAC"}

package/dist/tools/bash/interaction.js

@@ -0,0 +1,13 @@
+import { MCPCustomClass } from "../../core/mcp.js";
+/**
+ * Shared custom interaction class for all bash tools. A frontend can listen
+ * on getEvents() to reflect live process activity (e.g. "Running npm run
+ * dev...", "Waiting for build to finish...") without polling.
+ */
+export class BashInteraction extends MCPCustomClass {
+    emitBashEvent(event) {
+        this.getEvents().emit("bash", event);
+    }
+}
+export default BashInteraction;
+//# sourceMappingURL=interaction.js.map

package/dist/tools/bash/interaction.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"interaction.js","sourceRoot":"","sources":["../../../src/tools/bash/interaction.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAE,MAAM,mBAAmB,CAAC;AASnD;;;;GAIG;AACH,MAAM,OAAO,eAAgB,SAAQ,cAAc;IAC/C,aAAa,CAAC,KAAgB;QAC1B,IAAI,CAAC,SAAS,EAAE,CAAC,IAAI,CAAC,MAAM,EAAE,KAAK,CAAC,CAAC;IACzC,CAAC;CACJ;AAED,eAAe,eAAe,CAAC"}

package/dist/tools/bash/list.d.ts

@@ -0,0 +1,4 @@
+import { MCPTool } from "../../core/mcp.js";
+export declare const BashListTool: () => MCPTool<undefined>;
+export default BashListTool;
+//# sourceMappingURL=list.d.ts.map

package/dist/tools/bash/list.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"list.d.ts","sourceRoot":"","sources":["../../../src/tools/bash/list.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAY,MAAM,mBAAmB,CAAC;AAGtD,eAAO,MAAM,YAAY,0BAmBvB,CAAC;AAEH,eAAe,YAAY,CAAC"}

package/dist/tools/bash/list.js

@@ -0,0 +1,23 @@
+import { MCPTool } from "../../core/mcp.js";
+import { listProcesses } from "./process-manager.js";
+export const BashListTool = () => new MCPTool({
+    name: "bash-list",
+    description: "list every bash process launched so far (running or finished) with its status, so a still-running one can be checked on or terminated",
+    inputs: [],
+    execute: async (_envID, _inputs, _mcp) => {
+        const processes = listProcesses().map((p) => ({
+            processId: p.id,
+            command: p.command,
+            cwd: p.cwd,
+            status: p.status,
+            exitCode: p.exitCode,
+            startedAt: p.startedAt,
+            endedAt: p.endedAt,
+        }));
+        return {
+            processes,
+        };
+    },
+});
+export default BashListTool;
+//# sourceMappingURL=list.js.map

package/dist/tools/bash/list.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"list.js","sourceRoot":"","sources":["../../../src/tools/bash/list.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAY,MAAM,mBAAmB,CAAC;AACtD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AAErD,MAAM,CAAC,MAAM,YAAY,GAAG,GAAG,EAAE,CAAC,IAAI,OAAO,CAAC;IAC1C,IAAI,EAAE,WAAW;IACjB,WAAW,EAAE,uIAAuI;IACpJ,MAAM,EAAE,EAAE;IACV,OAAO,EAAE,KAAK,EAAE,MAAc,EAAE,OAA4B,EAAE,IAAU,EAAgB,EAAE;QACtF,MAAM,SAAS,GAAG,aAAa,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;YAC1C,SAAS,EAAE,CAAC,CAAC,EAAE;YACf,OAAO,EAAE,CAAC,CAAC,OAAO;YAClB,GAAG,EAAE,CAAC,CAAC,GAAG;YACV,MAAM,EAAE,CAAC,CAAC,MAAM;YAChB,QAAQ,EAAE,CAAC,CAAC,QAAQ;YACpB,SAAS,EAAE,CAAC,CAAC,SAAS;YACtB,OAAO,EAAE,CAAC,CAAC,OAAO;SACrB,CAAC,CAAC,CAAC;QAEJ,OAAO;YACH,SAAS;SACZ,CAAC;IACN,CAAC;CACJ,CAAC,CAAC;AAEH,eAAe,YAAY,CAAC"}

package/dist/tools/bash/logs.d.ts

@@ -0,0 +1,4 @@
+import { MCPTool } from "../../core/mcp.js";
+export declare const BashLogsTool: () => MCPTool<undefined>;
+export default BashLogsTool;
+//# sourceMappingURL=logs.d.ts.map

package/dist/tools/bash/logs.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"logs.d.ts","sourceRoot":"","sources":["../../../src/tools/bash/logs.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAY,MAAM,mBAAmB,CAAC;AAGtD,eAAO,MAAM,YAAY,0BA8CvB,CAAC;AAEH,eAAe,YAAY,CAAC"}

package/dist/tools/bash/logs.js

@@ -0,0 +1,47 @@
+import { MCPTool } from "../../core/mcp.js";
+import { getProcess } from "./process-manager.js";
+export const BashLogsTool = () => new MCPTool({
+    name: "bash-logs",
+    description: "read a process's combined stdout/stderr log, paging through it by line (use offsetLine/limitLine for long logs instead of tailLines from bash-run/bash-wait)",
+    inputs: [
+        {
+            name: "processId",
+            type: "string",
+            description: "id of the process to read logs from",
+            required: true,
+        },
+        {
+            name: "offsetLine",
+            type: "number",
+            description: "line offset to start reading from",
+            required: false,
+            default: 0,
+        },
+        {
+            name: "limitLine",
+            type: "number",
+            description: "max number of lines to return",
+            required: false,
+            default: 200,
+        },
+    ],
+    execute: async (_envID, inputs, _mcp) => {
+        const { processId, offsetLine = 0, limitLine = 200 } = inputs;
+        if (!processId || typeof processId !== "string") {
+            throw new Error("processId must be a non-empty string");
+        }
+        const proc = getProcess(processId);
+        const lines = proc.getAllLines();
+        const totalLines = lines.length;
+        const start = Math.max(0, Math.min(offsetLine, totalLines));
+        const end = Math.max(start, Math.min(start + limitLine, totalLines));
+        return {
+            content: lines.slice(start, end).join("\n"),
+            totalLines,
+            status: proc.status,
+            exitCode: proc.exitCode,
+        };
+    },
+});
+export default BashLogsTool;
+//# sourceMappingURL=logs.js.map

package/dist/tools/bash/logs.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"logs.js","sourceRoot":"","sources":["../../../src/tools/bash/logs.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAY,MAAM,mBAAmB,CAAC;AACtD,OAAO,EAAE,UAAU,EAAE,MAAM,sBAAsB,CAAC;AAElD,MAAM,CAAC,MAAM,YAAY,GAAG,GAAG,EAAE,CAAC,IAAI,OAAO,CAAC;IAC1C,IAAI,EAAE,WAAW;IACjB,WAAW,EACP,8JAA8J;IAClK,MAAM,EAAE;QACJ;YACI,IAAI,EAAE,WAAW;YACjB,IAAI,EAAE,QAAQ;YACd,WAAW,EAAE,qCAAqC;YAClD,QAAQ,EAAE,IAAI;SACjB;QACD;YACI,IAAI,EAAE,YAAY;YAClB,IAAI,EAAE,QAAQ;YACd,WAAW,EAAE,mCAAmC;YAChD,QAAQ,EAAE,KAAK;YACf,OAAO,EAAE,CAAC;SACb;QACD;YACI,IAAI,EAAE,WAAW;YACjB,IAAI,EAAE,QAAQ;YACd,WAAW,EAAE,+BAA+B;YAC5C,QAAQ,EAAE,KAAK;YACf,OAAO,EAAE,GAAG;SACf;KACJ;IACD,OAAO,EAAE,KAAK,EAAE,MAAc,EAAE,MAA2B,EAAE,IAAU,EAAgB,EAAE;QACrF,MAAM,EAAE,SAAS,EAAE,UAAU,GAAG,CAAC,EAAE,SAAS,GAAG,GAAG,EAAE,GAAG,MAAM,CAAC;QAE9D,IAAI,CAAC,SAAS,IAAI,OAAO,SAAS,KAAK,QAAQ,EAAE,CAAC;YAC9C,MAAM,IAAI,KAAK,CAAC,sCAAsC,CAAC,CAAC;QAC5D,CAAC;QAED,MAAM,IAAI,GAAG,UAAU,CAAC,SAAS,CAAC,CAAC;QACnC,MAAM,KAAK,GAAG,IAAI,CAAC,WAAW,EAAE,CAAC;QACjC,MAAM,UAAU,GAAG,KAAK,CAAC,MAAM,CAAC;QAChC,MAAM,KAAK,GAAG,IAAI,CAAC,GAAG,CAAC,CAAC,EAAE,IAAI,CAAC,GAAG,CAAC,UAAU,EAAE,UAAU,CAAC,CAAC,CAAC;QAC5D,MAAM,GAAG,GAAG,IAAI,CAAC,GAAG,CAAC,KAAK,EAAE,IAAI,CAAC,GAAG,CAAC,KAAK,GAAG,SAAS,EAAE,UAAU,CAAC,CAAC,CAAC;QAErE,OAAO;YACH,OAAO,EAAE,KAAK,CAAC,KAAK,CAAC,KAAK,EAAE,GAAG,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;YAC3C,UAAU;YACV,MAAM,EAAE,IAAI,CAAC,MAAM;YACnB,QAAQ,EAAE,IAAI,CAAC,QAAQ;SAC1B,CAAC;IACN,CAAC;CACJ,CAAC,CAAC;AAEH,eAAe,YAAY,CAAC"}