@sous-io/sous 0.1.1 → 0.2.0

package/src/utils/value-prompt.ts

@@ -0,0 +1,119 @@
+/**
+ * The value question sous asks for a recipe variable.
+ *
+ * It behaves like the stock `input` prompt (typing, backspace, Enter alone
+ * accepting the default, a validation message that re-asks) with one addition:
+ * Tab resolves the question with `{ kind: "advanced" }` instead of inserting a
+ * tab or inlining the default, so the caller can show the advanced view and
+ * then ask the same question again. A secret passes `mask`, which hides what is
+ * typed. Built on the public `@inquirer/core` hooks only.
+ */
+
+import {
+  createPrompt,
+  isEnterKey,
+  isTabKey,
+  useKeypress,
+  usePrefix,
+  useState,
+  type Status,
+} from "@inquirer/core";
+import { promptBottom } from "./formatting.js";
+
+/** What the value question needs in order to ask itself. */
+export interface ValuePromptConfig {
+  /** The one-line question. */
+  message: string;
+  /** The value Enter alone accepts. */
+  default?: string;
+  /** A line under the question: the key legend, in the stock prompts' style. */
+  hint?: string;
+  /** Whether to hide what is typed, for a secret. */
+  mask?: boolean;
+  /** Checks an answer, returning true or the reason it was refused. */
+  validate?: (value: string) => boolean | string | Promise<boolean | string>;
+}
+
+/** How the question ended: with an answer, or with a request for the advanced view. */
+export type ValuePromptResult = { kind: "value"; value: string } | { kind: "advanced" };
+
+/** Everything the renderer draws, so it can be tested without a terminal. */
+export interface ValuePromptView extends Omit<ValuePromptConfig, "validate"> {
+  /** The prompt prefix (the question mark, or the check mark once answered). */
+  prefix: string;
+  /** What has been typed so far. */
+  value: string;
+  /** The validation message, when the last answer was refused. */
+  error?: string;
+  /** Whether the question has been answered, which drops the legend and the padding. */
+  answered?: boolean;
+}
+
+/**
+ * Draws the question: prefix, message, the default in parentheses and what has
+ * been typed, plus the block underneath carrying the validation message when
+ * there is one and the key legend otherwise, and the padding that keeps the
+ * question off the terminal's last row.
+ *
+ * @param view - The prompt's state.
+ * @returns The question line and the block under it.
+ */
+export function renderValuePrompt(view: ValuePromptView): [string, string] {
+  const shown = view.mask === true ? "*".repeat(view.value.length) : view.value;
+  const suffix = view.default !== undefined && view.default !== "" ? ` (${view.default})` : "";
+  const line = `${view.prefix} ${view.message}${suffix}: ${shown}`.trimEnd();
+
+  if (view.answered === true) return [line, ""];
+  return [line, promptBottom(view.error ?? view.hint ?? "")];
+}
+
+/** Asks for one value, with Tab bound to the advanced view. */
+export const valuePrompt = createPrompt<ValuePromptResult, ValuePromptConfig>((config, done) => {
+  const [status, setStatus] = useState<Status>("idle");
+  const [value, setValue] = useState("");
+  const [error, setError] = useState<string | undefined>(undefined);
+  const prefix = usePrefix({ status });
+
+  useKeypress(async (key, rl) => {
+    if (status !== "idle") return;
+
+    if (isTabKey(key)) {
+      // Readline has already put a literal tab in the buffer; take it back out.
+      rl.clearLine(0);
+      rl.write(value);
+      setStatus("done");
+      done({ kind: "advanced" });
+      return;
+    }
+
+    if (isEnterKey(key)) {
+      const answer = value === "" ? (config.default ?? "") : value;
+      setStatus("loading");
+      const checked = config.validate === undefined ? true : await config.validate(answer);
+      if (checked === true) {
+        setValue(answer);
+        setStatus("done");
+        done({ kind: "value", value: answer });
+        return;
+      }
+      rl.write(value);
+      setError(typeof checked === "string" ? checked : "That answer is not valid.");
+      setStatus("idle");
+      return;
+    }
+
+    setValue(rl.line);
+    setError(undefined);
+  });
+
+  return renderValuePrompt({
+    prefix,
+    message: config.message,
+    value,
+    ...(status === "done" ? { answered: true } : {}),
+    ...(config.default === undefined ? {} : { default: config.default }),
+    ...(config.hint === undefined ? {} : { hint: config.hint }),
+    ...(config.mask === undefined ? {} : { mask: config.mask }),
+    ...(error === undefined ? {} : { error }),
+  });
+});

package/shared-prompts/_partials/resume-task.md

@@ -1,51 +0,0 @@
-The agent performing this work MUST load `about-task-files`.
-
-## Delegation
-
-Per the sub-agent delegation pattern (`~sous-shared/_partials/sub-agent-delegation.md`), the
-orchestrator delegates steps 1 and 2 (find and read the task file, extract status) to a background
-sub-agent, which reports back a concise summary. Step 3 is orchestrator-only.
-
-## Steps
-
-### 1. Find the Task File
-
-Run `git status` to get the current branch name. Look for the task file at:
-```
-{{ taskFileRoot }}/[branch-name].md
-```
-
-If not found, run a fresh `git status` to confirm the branch before concluding the file doesn't exist. If it truly doesn't exist, report that back; the orchestrator asks the user whether to create one (load `start-task`).
-
-### 2. Read and Analyze
-
-Read the entire task file. Identify:
-- Overall objective
-- What has been completed (checked items, status markers)
-- What remains (unchecked items, TODOs)
-- Any blockers or pending issues
-- Recent decisions and learnings
-
-### 3. Present Status and Next Steps
-
-Orchestrator-only; sub-agents cannot talk to the user. A sub-agent doing steps 1 and 2 returns its
-summary to the orchestrator, which presents:
-
-```
-Based on the task file, here's where we are:
-
-**Current Status:**
-[Brief summary of completed phases and where work stopped]
-
-**Recommended Next Steps:**
-1. [First thing to do]
-2. [Second thing]
-3. [etc.]
-
-Would you like me to:
-- A) Proceed with these next steps?
-- B) Focus on something specific?
-- C) Something else?
-```
-
-**Do not begin work until the user confirms.** If the task file has contradictions or outdated information, point them out before proceeding.

package/shared-prompts/_partials/sub-agent-delegation.md

@@ -1,32 +0,0 @@
-# Sub-Agent Delegation
-
-Several shared skills say work is "delegated" and cite the sub-agent delegation pattern. This is
-that pattern. Include this partial in a project's core memory (`@~sous-shared/_partials/sub-agent-delegation.md`)
-if the project wants the agent to follow it by default.
-
-The main chat session is an **orchestrator**: it does the reasoning, the decisions, and all
-interaction with the user, and it delegates execution to sub-agents. The orchestrator usually runs
-an expensive model, so pushing execution down to cheaper sub-agents cuts cost and, because
-sub-agents run in parallel, finishes sooner.
-
-**Orchestrator-only:** planning, decisions, anything that needs the user (questions, approvals,
-drafts), and very small actions where delegating costs more than doing it (a quick file read, a
-one-line edit).
-
-**Delegated:** anything with real work in it, including research, code changes, doc and task file
-writing, and multi-step lookups.
-
-**Rules:**
-
-- Run sub-agents in the background and in parallel by default; batch independent dispatches into one
-  message. Go synchronous only when the result blocks the very next step.
-- Prompts must be self-contained. Sub-agents start with fresh context and cannot see the
-  conversation, so state every fact, path, ID, and decision they need, and name the skills they
-  should load. Anything the sub-agent can gather itself (branch name, commits, test output) should
-  be left to it.
-- Sub-agents cannot talk to the user. Questions and user-facing messages go back to the orchestrator
-  to relay.
-- Every sub-agent reports a concise summary of what it did or found, not a file dump.
-- The orchestrator spot-checks load-bearing results (task files, code diffs, outward-facing writes)
-  in a cheap, targeted way; it does not re-read everything.
-- Never fabricate or predict a pending sub-agent's result. Wait for it.

package/shared-prompts/_partials/update-task-file.md

@@ -1,52 +0,0 @@
-The agent performing this work MUST load `about-task-files`.
-
-**CRITICAL: Do NOTHING ELSE. Update the task file IMMEDIATELY. Use as few edits as possible.**
-
-## Delegation
-
-Per the sub-agent delegation pattern (`~sous-shared/_partials/sub-agent-delegation.md`), writing the
-task file is delegated work. The orchestrator does not edit the file itself; it hands an Opus
-sub-agent everything below in one self-contained prompt:
-
-- The task file path (branch name), or instructions to derive it from `git status`.
-- The facts and decisions to record. Compiling these is orchestrator-only; sub-agents cannot see
-  this conversation, so anything known only from the conversation must be stated in the prompt.
-- Anything the sub-agent can gather itself (commit list, changed files, test/build output), which it
-  should collect rather than have the orchestrator paste in.
-
-The sub-agent loads `about-task-files`, edits the file, and reports back a concise summary of what
-it wrote. The orchestrator spot-checks with a targeted diff, not a full re-read.
-
-## What to Include
-
-Update the task file with all of the following:
-
-1. **Progress since last update** — what was completed, what is in progress, current status
-2. **Decisions made** — technical approach chosen, alternatives considered and rejected
-3. **Remaining work** — everything still needed, prioritized next steps, known dependencies
-4. **Pending issues** — unresolved problems, blockers, questions needing answers
-5. **Learnings** — insights, patterns discovered, things to remember
-6. **Commits made** — commit IDs and brief description of each
-7. **Testing URLs** — web URLs currently in use, database query results referenced
-8. **Files changed** — absolute paths with line numbers, what was done and why
-9. **Unresolved errors** — test failures, build errors, TypeScript errors — with paths and line numbers
-
-## Checklist Management
-
-- Mark completed items `[x]`
-- Add `[ ]` for newly identified tasks
-- Remove or condense sections no longer relevant
-
-## Consistency Check
-
-Scan the existing file for contradictions or outdated information. Correct before saving.
-
-## After Update
-
-**STOP immediately.** Do not:
-- Continue working on the task
-- Start new work
-- Make additional changes
-
-A sub-agent reports what it wrote and stops. The orchestrator then waits; the user will end the
-session and start a new one.

package/shared-prompts/memories/automated-browser-tasks/INDEX.tpl.md

@@ -1,52 +0,0 @@
-# Automated Browser Tasks
-
-This project can drive a real web browser to accomplish tasks — logging in as
-you (using your existing Chrome session), navigating, and extracting data —
-**headlessly**, without opening a visible browser or interrupting your work.
-
-**When a task needs a browser and no API or MCP server can do it, this is the
-default path.** Do not tell the user to click through a browser manually if it
-can be scripted.
-
-**Running a non-mutating task is normal workflow — do it without asking.** A task
-that only navigates and reads (extracts data; submits nothing, changes no state,
-sends nothing outward) is investigation, the same category as reading a file or
-running a query. Running an existing read-only task is not a "manual action" and
-not "outward-facing," so it does not need the user's permission — especially while
-investigating. Just run it and report what it found; pausing to ask first only
-wastes a round trip on a no-risk action. (Creating or modifying a task script, or
-running a task that mutates external state, is a separate case — apply normal
-judgment there.)
-
-The agent performing the work MUST load the `about-automated-browser-tasks` skill
-before writing, running, or modifying any of these tasks. It explains the `ctx`
-API, the auth model, and the scriptwriting conventions. The action skills
-`create-automated-browser-task`, `update-automated-browser-task`, and
-`running-automated-browser-tasks` cover those specific operations (including
-exact runner invocation).
-
-Browser runs are slow and multi-step, so they are delegated to a background
-sub-agent, per the sub-agent delegation pattern
-(`~sous-shared/_partials/sub-agent-delegation.md`). The sub-agent loads the skills
-itself and reports the result plus any link or actionable message.
-
-## Available Tasks
-
-{% getFiles browserTasks root=browserAutomationScriptsDir include="*.mjs" import="meta" -%}
-{% if browserTasks.size > 0 -%}
-{%- for t in browserTasks %}
-### {{ t.meta.name }}
-
-{{ t.meta.description }}
-
-- Script: `{{ t.path }}`
-{%- if t.meta.params %}
-- Parameters:
-{%- for p in t.meta.params %}
-  - `{{ p[0] }}` ({% if p[1].required %}required{% else %}optional{% if p[1].default %}, default: `{{ p[1].default }}`{% endif %}{% endif %}) — {{ p[1].description | split: ". " | first }}.
-{%- endfor %}
-{%- endif %}
-{% endfor -%}
-{% else -%}
-_No automation tasks exist yet. Load `create-automated-browser-task` to add one._
-{% endif %}

package/shared-prompts/skills/automated-browser-tasks/about-automated-browser-tasks/SKILL.tpl.md

@@ -1,102 +0,0 @@
----
-name: about-automated-browser-tasks
-description: >
-  YOU MUST load this skill when the user asks you to do anything that requires
-  interacting with a web browser, or when no MCP server or API can accomplish a
-  task and the only path forward is browser-based actions. Before telling the
-  user to do something manually in a browser, check for an existing automation
-  script and offer to run or write one. When browser work is needed, look for an
-  existing script first; create one only if none exists.
-user-invocable: false
----
-
-# Automated Browser Tasks
-
-This system lets you write, run, and reuse headless browser automation scripts
-(Playwright) that authenticate as the user by borrowing their existing Chrome
-session — no manual login, no visible browser, Chrome stays open.
-
-When a task needs a browser and no API/MCP server can do it, this is the default
-path. Do not instruct the user to click through a browser manually if the task
-can be scripted.
-
-## How It Works (cold-start orientation)
-
-1. **Auth is automatic.** A harness reads cookies from the user's Chrome profile,
-   decrypts them locally (via the OS keyring), and injects them into a fresh
-   headless browser context. Scripts "just work" as the logged-in user.
-2. **Scripts are small modules.** Each script file exports `meta` (name,
-   description, params) and `execute(ctx)`. The harness resolves + validates
-   params, builds `ctx`, and runs `execute`.
-3. **You run scripts by absolute path** through the runner:
-   ```bash
-   node <scriptsDir>/run.mjs <absolute-path-to-script.mjs> [--param=value ...]
-   ```
-4. **Scripts return a result object**; the runner prints it and writes any
-   `outputFile`. Auth failures are detected and reported with an actionable
-   message telling the user to log in, then you retry.
-
-The framework code (harness, chrome-state, keyring, logger, utils, params,
-run) lives in this skill's `scripts/` directory. User scripts live in the
-project's configured scripts directory and are invoked by path.
-
-## The `ctx` Object
-
-Every script's `execute(ctx)` receives:
-
-- `ctx.page` — Playwright `Page`
-- `ctx.context` / `ctx.browser` — Playwright context / browser
-- `ctx.params` — fully resolved + validated params
-- `ctx.settings` — compiled project settings (from `settings.mjs`)
-- `ctx.timeout` — overall timeout (ms)
-- `ctx.logger` — prefixed logger; `ctx.logger.child('section')` for sections
-- `ctx.utils` — generic action helpers (modal dismissal, waits, text extraction, …)
-- `ctx.debug` — exploration & debugging tools (dump, describe, findText, watch, …)
-- `ctx.checkAuth()` — throws `AuthError` if redirected to a login page
-- `ctx.runChild(script, params)` — run another script in the same browser context
-
-Full details: [references/ctx-api.md](references/ctx-api.md).
-
-## Writing Scripts — Non-Negotiable Conventions
-
-- `execute()` is a thin orchestrator; logic lives in small named step functions.
-- EVERY function (including `execute`) has a full JSDoc block (`@param`/`@returns`).
-- Destructure what you need off `ctx`/`params` at the top of each function.
-- Use `ctx.logger`, never `console.log`.
-- Do NOT validate params in the script — declare rules in `meta.params`.
-- Fail fast; do not catch-and-continue. Fix root causes, not symptoms.
-
-Full conventions: [references/script-conventions.md](references/script-conventions.md).
-
-## Reference Files
-
-- [references/architecture.md](references/architecture.md) — components and data flow
-- [references/ctx-api.md](references/ctx-api.md) — complete `ctx` and `ctx.utils` API
-- [references/auth-and-sessions.md](references/auth-and-sessions.md) — how auth works, auth failures, retries
-- [references/script-conventions.md](references/script-conventions.md) — full scriptwriting rules
-- [references/installation.md](references/installation.md) — dependencies and setup
-
-## Examples
-
-- [examples/simple-fetch.mjs](examples/simple-fetch.mjs) — single-page data extraction
-- [examples/chained-workflow.mjs](examples/chained-workflow.mjs) — a script calling another via `ctx.runChild`
-- [examples/auth-failure-handling.mjs](examples/auth-failure-handling.mjs) — the auth-failure + retry pattern
-
-# Other Skills
-
-The agent performing the work MUST load `create-automated-browser-task` when
-creating a new automation script, `update-automated-browser-task` when modifying an
-existing script, and `running-automated-browser-tasks` when running a script.
-
-Per the sub-agent delegation pattern
-(`~sous-shared/_partials/sub-agent-delegation.md`), all three are delegated to a background
-sub-agent, which loads the skills itself and reports back. Auth failures and other
-user-facing messages go to the orchestrator to relay; sub-agents cannot talk to the
-user.
-
-## Source for this Skill
-
-This skill was pulled from the `sous` project's "shared skills" library. It was compiled from a template and
-the output file should not be edited directly.
-
-- Source Path: {{ sousTemplatePath }}

package/shared-prompts/skills/automated-browser-tasks/about-automated-browser-tasks/examples/auth-failure-handling.mjs

@@ -1,81 +0,0 @@
-/**
- * auth-failure-handling
- *
- * Demonstrates the auth-failure contract. Scripts do NOT log in and do NOT
- * recover mid-run: they call `ctx.checkAuth()` after navigation and let the
- * harness convert a login-page redirect into a structured auth error. The agent
- * relays the message, the user logs in, and the SAME command is re-run.
- *
- * This script targets a page that requires authentication and simply reports
- * whether it reached real content — illustrating where checkAuth belongs.
- */
-
-export const meta = {
-  name: 'auth-failure-handling',
-  description: 'Visit an authenticated page and confirm we are logged in (auth-pattern demo).',
-  params: {
-    url: {
-      required: true,
-      description:
-        'Absolute URL of a page that requires authentication. If the Chrome ' +
-        'session is expired, the harness will surface an actionable auth error.',
-      validate: /^https?:\/\/.+/,
-      invalidMessage: 'url must be an absolute http(s) URL.',
-    },
-    readySelector: {
-      required: true,
-      description:
-        'CSS selector for an element that only appears once the authenticated ' +
-        'content has loaded (e.g. a user avatar or app shell). Used to confirm we ' +
-        'are past any login wall.',
-    },
-  },
-};
-
-/**
- * Entry point. Navigates, checks auth, then confirms authed content rendered.
- *
- * @param {object} ctx - The harness context.
- * @returns {Promise<object>} `{ found, url, message }`.
- */
-export async function execute(ctx) {
-  const { page, params } = ctx;
-  const { url, readySelector } = params;
-
-  await openAuthedPage(ctx, url, readySelector);
-
-  return {
-    found: true,
-    url: page.url(),
-    message: 'Reached authenticated content successfully.',
-  };
-}
-
-/**
- * Navigate to an authenticated page and confirm we reached it — the canonical
- * auth-handling pattern. Many SPAs resolve auth client-side a beat AFTER load and
- * redirect to a login page, so we do NOT check the URL immediately. Instead we
- * wait for the success signal (`readySelector`, an element that only renders for
- * authenticated users). Only if that wait times out do we call `checkAuth()`: by
- * then the URL has settled, so a login page becomes a clear AuthError (which the
- * harness reports as `{ error: 'auth', message }`), while anything else re-throws
- * as a genuine render timeout. The script never tries to log in itself.
- *
- * @param {object} ctx - The harness context.
- * @param {string} url - The authenticated URL to load.
- * @param {string} readySelector - Element proving authed content rendered.
- * @returns {Promise<void>}
- */
-async function openAuthedPage(ctx, url, readySelector) {
-  const { page, logger, timeout, checkAuth } = ctx;
-  const log = logger.child('navigate');
-  log.info(`Loading authenticated page ${url}`);
-  await page.goto(url, { waitUntil: 'domcontentloaded', timeout });
-  try {
-    await page.locator(readySelector).first().waitFor({ state: 'visible', timeout });
-    log.info('Authenticated content is present');
-  } catch (renderTimeout) {
-    await checkAuth(); // throws AuthError if the settled URL is a login page
-    throw renderTimeout;
-  }
-}

package/shared-prompts/skills/automated-browser-tasks/about-automated-browser-tasks/examples/chained-workflow.mjs

@@ -1,126 +0,0 @@
-/**
- * chained-workflow
- *
- * Demonstrates composing scripts: one script invokes another via
- * `ctx.runChild`, reusing the same authenticated browser context. The child
- * runs in-process and returns its result object directly.
- *
- * Here the parent collects a list of item URLs from an index page, then runs a
- * child "fetch" script against each one. In a real project the child would be a
- * separate script file imported at the top; it is inlined here so the example
- * is self-contained.
- */
-
-export const meta = {
-  name: 'chained-workflow',
-  description: 'Collect links from an index page, then fetch each via a child script.',
-  params: {
-    indexUrl: {
-      required: true,
-      description:
-        'Absolute URL of the index/listing page to scrape links from. Loaded as ' +
-        'the authenticated user.',
-      validate: /^https?:\/\/.+/,
-      invalidMessage: 'indexUrl must be an absolute http(s) URL.',
-    },
-    linkSelector: {
-      required: false,
-      default: 'a[href]',
-      description:
-        'CSS selector matching the links to follow on the index page. Defaults ' +
-        'to all anchors with an href.',
-    },
-    limit: {
-      required: false,
-      default: 3,
-      description:
-        'Maximum number of links to follow, to keep runs bounded. Provided as a ' +
-        'string on the CLI and coerced to a number.',
-      validate: (v) => Number(v) > 0 || 'limit must be a positive number',
-    },
-  },
-};
-
-/** A small child script run once per collected link. Normally its own file. */
-const fetchTitle = {
-  meta: {
-    name: 'fetch-title',
-    params: {
-      url: { required: true, validate: /^https?:\/\/.+/, invalidMessage: 'url must be absolute http(s)' },
-    },
-  },
-  /**
-   * Load a URL and return its document title.
-   *
-   * @param {object} ctx - The harness context (shares the parent's browser).
-   * @returns {Promise<object>} `{ url, title }`.
-   */
-  async execute(ctx) {
-    const { page, params, logger, timeout, checkAuth } = ctx;
-    logger.child('navigate').info(`Fetching ${params.url}`);
-    // domcontentloaded is enough here: the <title> is in the initial document.
-    await page.goto(params.url, { waitUntil: 'domcontentloaded', timeout });
-    await checkAuth();
-    return { url: page.url(), title: await page.title() };
-  },
-};
-
-/**
- * Entry point. Collects links from the index, then fetches each via a child.
- *
- * @param {object} ctx - The harness context.
- * @returns {Promise<object>} `{ found, count, results }`.
- */
-export async function execute(ctx) {
-  const { params } = ctx;
-  const { indexUrl, linkSelector, limit } = params;
-
-  const links = await collectLinks(ctx, indexUrl, linkSelector, Number(limit));
-  const results = await fetchEach(ctx, links);
-
-  return { found: results.length > 0, count: results.length, results };
-}
-
-/**
- * Load the index page and collect up to `limit` link URLs.
- *
- * @param {object} ctx - The harness context.
- * @param {string} indexUrl - The listing page URL.
- * @param {string} selector - Selector matching links to follow.
- * @param {number} limit - Max links to return.
- * @returns {Promise<string[]>} Absolute link URLs.
- */
-async function collectLinks(ctx, indexUrl, selector, limit) {
-  const { page, logger, timeout, checkAuth } = ctx;
-  const log = logger.child('collect');
-  log.info(`Loading index ${indexUrl}`);
-  await page.goto(indexUrl, { waitUntil: 'domcontentloaded', timeout });
-  // Success signal: the links we intend to read are present. If they never
-  // appear, check auth (login redirects resolve late) before failing.
-  try {
-    await page.locator(selector).first().waitFor({ state: 'visible', timeout });
-  } catch (renderTimeout) {
-    await checkAuth();
-    throw renderTimeout;
-  }
-
-  const hrefs = await page.$$eval(selector, (els) => els.map((el) => el.href));
-  const unique = [...new Set(hrefs.filter(Boolean))].slice(0, limit);
-  log.info(`Collected ${unique.length} link(s)`);
-  return unique;
-}
-
-/**
- * Run the child fetch script against each link, in sequence.
- *
- * @param {object} ctx - The harness context.
- * @param {string[]} links - URLs to fetch.
- * @returns {Promise<object[]>} One child result per link.
- */
-async function fetchEach(ctx, links) {
-  const results = [];
-  for (const url of links) {
-    results.push(await ctx.runChild(fetchTitle, { url }));
-  }
-  return results;
-}