pullfrog 0.1.93 → 0.1.95

package/dist/internal.js

@@ -8,7 +8,7 @@ var __export = (target, all) => {
 // package.json
 var package_default = {
   name: "pullfrog",
-  version: "0.1.93",
+  version: "0.1.95",
   cliContractVersion: "1",
   type: "module",
   bin: {
@@ -50,7 +50,6 @@ var package_default = {
     "@standard-schema/spec": "1.1.0",
     "@toon-format/toon": "^1.0.0",
     "@types/node": "^24.7.2",
-    "@types/object-hash": "^3.0.6",
     "@types/semver": "^7.7.1",
     "@types/turndown": "^5.0.5",
     "agent-browser": "0.25.4",
@@ -64,8 +63,6 @@ var package_default = {
     fastmcp: "^3.34.0",
     "file-type": "^21.3.0",
     husky: "^9.0.0",
-    "lru-cache": "^11.0.0",
-    "object-hash": "^3.0.0",
     "opencode-ai": "1.18.29",
     "package-manager-detector": "^1.6.0",
     picocolors: "^1.1.1",
@@ -77,6 +74,7 @@ var package_default = {
     undici: "^7.22.0",
     vitest: "^4.0.17",
     yaml: "^2.8.2",
+    yes: "0.1.0",
     zod: "4.3.6"
   },
   repository: {
@@ -110,12 +108,6 @@ var package_default = {
       import: "./dist/internal.js",
       default: "./dist/internal.js"
     },
-    "./yes": {
-      "@pullfrog/source": "./yes/index.ts",
-      types: "./dist/yes/index.d.ts",
-      import: "./dist/yes.js",
-      default: "./dist/yes.js"
-    },
     "./package.json": "./package.json"
   },
   packageManager: "pnpm@10.27.0+sha512.72d699da16b1179c14ba9e64dc71c9a40988cbdc65c264cb0e489db7de917f20dcf4d64d8723625f2969ba52d4b7e2a1170682d9ac2a5dcaeaab732b7e16f04a"
@@ -15011,6 +15003,17 @@ var providers = {
         // see the big-pickle note above (#1077).
         isFree: true
       },
+      // Zen's FREE stealth preview (listed 2026-10-01), the fifth promo. Zen
+      // has not published its data terms yet, so the description claims none.
+      "fledge-alpha": {
+        displayName: "Fledge Alpha",
+        description: "Stealth preview, free for a limited time",
+        resolve: "opencode/fledge-alpha-free",
+        effort: ["low", "high", "max"],
+        // free to run, still gated on the provider's own OPENCODE_API_KEY —
+        // see the big-pickle note above (#1077).
+        isFree: true
+      },
       // Zen's live free MiMo, and the second free row in a menu that big-pickle
       // was alone in since `mimo-v2-pro-free` lost its model.
       mimo: {
@@ -15849,12 +15852,14 @@ The body has at most three parts, in this order:
 
 1. **Reviewed changes preamble** \u2014 a bolded \`**Reviewed changes**\` lead-in with one sentence on what was reviewed in this run (for \`IncrementalReview\`: what changed since the prior pullfrog review), then a bullet list of the substantive changes \u2014 short bolded title, one sentence each. A reviewer should understand the full reviewed scope from this list alone. Close the preamble with the metadata comment below.
 2. **Cross-cutting issue sections** (zero or more) \u2014 one \`### {emoji} {what's wrong, not what to do}\` heading per concern.
-3. **\`### \u2139\uFE0F Nitpicks\`** at the very bottom, if any \u2014 a flat bullet list, no technical-details block.
+3. **\`### \u2139\uFE0F Nitpicks\`** at the very bottom, if any \u2014 a flat bullet list, no technical-details block. Only for what has no runtime effect: a stale or wrong comment or doc, a misleading name, a typo, dead code, a missing test. Never formatting or whitespace.
 
 **Inline vs. body.** Concerns that anchor to a specific line go inline (the \`comments\` parameter), even when their implications are broad. Body \`### \` sections are reserved for concerns that have **no line to anchor to** \u2014 *absence* (something the diff should have done but didn't), *sequencing* (rollout / deletion / migration order), *design decisions only the human can make*, or *scope questions the diff raises but doesn't address*. With no non-anchorable concerns, the body is just the preamble + metadata.
 
 **Severity emoji** on every \`### \` heading, and nowhere else: \u{1F6A8} critical (blocks merge \u2014 data loss, security, broken core flow) \xB7 \u26A0\uFE0F important (must address before merging) \xB7 \u2139\uFE0F informational (mergeable as-is).
 
+**Behavior decides placement, not fix size.** A finding that changes what the code does \u2014 a wrong value or message, a crash, a race, a leak, a missed cleanup, a slow path \u2014 gets its own inline comment (or a \`### \` section if no line anchors it) at its real severity, however small the fix. Never put it in Nitpicks: before submitting, re-read each Nitpicks bullet and move any that fails this test inline.
+
 **Blank line between every block-level element.** GitHub's markdown parser requires one before and after HTML tags (\`<details>\`, \`<summary>\`, \`<sub>\`, \`<br/>\`) \u2014 without it GitHub treats what follows as a continuation of the HTML block and renders your markdown as literal text. This is a parser quirk, not a style preference, and it permanently breaks the posted review.
 
 ## Metadata comment
@@ -16027,9 +16032,9 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
 
 6. **aggregate & draft**: when specialist results land, merge findings; de-dup overlaps (two specialists catching the same issue = higher-confidence signal); trace each finding yourself before accepting it. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the PR (heuristic: if the finding's root cause lives in lines this PR added or modified, it's in scope; otherwise drop unless the PR plausibly introduced or amplified the regression), and anything not actionable. also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or worse, degrades elegance to nominally improve correctness) makes the codebase worse, not better.
 
-   **Hunt for non-anchored concerns before drafting.** After collecting your anchored findings, deliberately scan for concerns that have no specific line to point at \u2014 typically: deletion / cleanup plans for code the diff replaces or shadows; rollout sequencing (what happens to in-flight state during deploy / revert?); coverage gaps the diff implies but doesn't add; scope questions that only the human can answer (e.g. is the legacy path going away or is this a long-term dual track?); architectural risks the diff opens up that aren't a single-line bug. On substantial PRs (migrations, refactors, multi-file rewrites, version bumps that change runtime semantics), at least one such concern almost always exists; if you can't think of any, your bar is probably too high.
+   **Hunt for non-anchored concerns before drafting.** After collecting your anchored findings, deliberately scan for concerns that have no specific line to point at \u2014 typically: deletion / cleanup plans for code the diff replaces or shadows; rollout sequencing (what happens to in-flight state during deploy / revert?); scope questions that only the human can answer (e.g. is the legacy path going away or is this a long-term dual track?); architectural risks the diff opens up that aren't a single-line bug.
 
-   for surviving findings, draft inline comments with NEW line numbers from the diff \u2014 attach a \`<details>Technical details</details>\` block to any inline comment whose fix is non-trivial or has cross-file implications (see Inline technical details in the format below). every comment must be actionable, 2-3 sentences max in the visible part. use GitHub permalink format for code references. for impact-analysis findings (stale references after rename/remove), report them in the review body ordered by severity (runtime breakage > incorrect docs > stale comments) rather than as inline comments unless they're anchored to a specific line.
+   for surviving findings, draft inline comments with NEW line numbers from the diff \u2014 attach a \`<details>Technical details</details>\` block to any inline comment whose fix is non-trivial or has cross-file implications (see Inline technical details in the format below). every comment must be actionable, 2-3 sentences max in the visible part, one per root cause \u2014 name its other sites in that comment rather than repeating it. use GitHub permalink format for code references. for impact-analysis findings (stale references after rename/remove), report them in the review body ordered by severity (runtime breakage > incorrect docs > stale comments) rather than as inline comments unless they're anchored to a specific line.
 
 7. **submit**: ALWAYS submit exactly one review via \`${t("create_pull_request_review")}\`. Do NOT call \`report_progress\` \u2014 the review is the final record and the progress comment will be cleaned up automatically.
 
@@ -16050,9 +16055,9 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
      \`approved: false\`. Body opens with \`> [!CAUTION]\\n> This PR introduces ...\`, followed by the PR summary. Include all inline comments via \`comments\`.
    - **must-address non-critical findings** (real consequences if shipped \u2014 incorrect behavior in non-critical paths, missing validation on user input, regressions the author should fix before merge):
      \`approved: false\`. Body opens with \`> [!IMPORTANT]\\n> ...\`, followed by the PR summary. Reserve this tier for findings with concrete fallout \u2014 do NOT use \`[!IMPORTANT]\` for nits, style preferences, or "consider also" suggestions. Include all inline comments via \`comments\`.
-   - **minor suggestions only** (single-line nits, doc/comment polish, defer-able observations, "rough edges"):
+   - **minor suggestions only** (low-stakes findings, or Nitpicks only):
      \`approved: false\`. Body opens with \`> \u2139\uFE0F No critical issues \u2014 minor suggestions inline.\\n\\n\` followed by the PR summary. Include all inline comments via \`comments\`. Vary the wording after the emoji to fit the review (e.g. "Minor suggestions only.", "Two rough edges worth a look."), but always keep the \u2139\uFE0F prefix and keep it short.
-   - **informational observations** (mergeable as-is, nothing actionable \u2014 e.g. prior feedback addressed cleanly, surfacing a minor stale doc reference, calling out something noteworthy without recommending a change):
+   - **informational observations** (mergeable as-is, nothing actionable \u2014 e.g. prior feedback addressed cleanly, calling out something noteworthy without recommending a change):
      \`approved: true\`. Body opens with \`> \u2705 No new issues found.\\n\\n\` followed by the PR summary. Do NOT include inline \`comments\` \u2014 the \u2705 signals "no action needed", which contradicts an actionable anchor; if a point is concrete enough to anchor to a line, downgrade the whole review to "minor suggestions only" (\`approved: false\`) instead.
    - **no actionable issues**:
      \`approved: true\`. Body opens with \`> \u2705 No new issues found.\\n\\n\` followed by the PR summary.
@@ -16118,9 +16123,9 @@ ${PR_SUMMARY_FORMAT}`
 
 8. **aggregate, draft, self-critique**: merge findings (yours + output from every specialist you dispatched); de-dup overlaps; trace each finding yourself. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the new commits, anything not actionable, and anything that re-states prior review feedback (heuristic: if the finding's root cause lives in lines the *new commits* added or modified, it's in scope; otherwise drop). also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or degrades elegance to nominally improve correctness) makes the codebase worse, not better. To compute "lines the new commits added or modified": if \`incrementalDiffPath\` from step 2 is present, use it directly. Otherwise, take the prior Pullfrog review's \`commit_id\` (returned alongside each entry from \`${t("list_pull_request_reviews")}\` in step 4) and run \`git diff <prior-review-sha>..HEAD\` to isolate the lines added since that review.
 
-   **Hunt for non-anchored concerns before drafting.** After collecting your anchored findings, deliberately scan for concerns that have no specific line to point at \u2014 typically: deletion / cleanup plans for code the new commits replace or shadow; rollout sequencing (what happens to in-flight state during deploy / revert?); coverage gaps the new commits imply but don't add; scope questions that only the human can answer (e.g. is the legacy path going away or is this a long-term dual track?); architectural risks the new commits open up that aren't a single-line bug. On substantial incremental diffs (migrations, refactors, multi-file rewrites, version bumps that change runtime semantics), at least one such concern almost always exists; if you can't think of any, your bar is probably too high.
+   **Hunt for non-anchored concerns before drafting.** After collecting your anchored findings, deliberately scan for concerns that have no specific line to point at \u2014 typically: deletion / cleanup plans for code the new commits replace or shadow; rollout sequencing (what happens to in-flight state during deploy / revert?); scope questions that only the human can answer (e.g. is the legacy path going away or is this a long-term dual track?); architectural risks the new commits open up that aren't a single-line bug.
 
-   draft inline comments with NEW line numbers from the full PR diff \u2014 attach a \`<details>Technical details</details>\` block to any inline comment whose fix is non-trivial or has cross-file implications (see Inline technical details in the format below). every comment must be actionable, 2-3 sentences max in the visible part.
+   draft inline comments with NEW line numbers from the full PR diff \u2014 attach a \`<details>Technical details</details>\` block to any inline comment whose fix is non-trivial or has cross-file implications (see Inline technical details in the format below). every comment must be actionable, 2-3 sentences max in the visible part, one per root cause \u2014 name its other sites in that comment rather than repeating it.
 
 9. **build the review body**: use the same default format as Review mode (preamble + optional cross-cutting \`### \` sections + optional \`### \u2139\uFE0F Nitpicks\`) \u2014 scoped to the **incremental delta**, not the full PR. The "Reviewed changes" bullets describe what changed since the prior pullfrog review (each bullet starts with a past-tense verb, e.g. \`- Extracted shared CLI runtime into a single module\`). Do NOT include a separate "Prior review feedback" checklist \u2014 that's tracked in the rolling PR summary snapshot for the next agent run, and surfacing it in the user-facing body is noise (changes that addressed prior feedback are already covered by the Reviewed-changes bullets). In some cases you may receive a complete diff for the whole PR instead of an incremental one; when this happens, determine what changed since Pullfrog's most recent review yourself before drafting bullets.
 
@@ -16133,8 +16138,8 @@ ${PR_SUMMARY_FORMAT}`
    - IF NO NEW ISSUES, NON-SUBSTANTIVE CHANGES ONLY (trivial formatting, import reordering, comment tweaks): do NOT submit a review. Instead call \`${t("report_progress")}\` with a 1-2 sentence note explaining no review was warranted (e.g. "No new issues. Changes since last review are formatting-only."). this leaves a visible signal that the run completed.
    - ELSE IF NEW CRITICAL ISSUES (blocks merge \u2014 bugs, security, data loss, broken core flows): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> [!CAUTION]\\n> This PR introduces ...\`, followed by the PR summary using the default format below.
    - ELSE IF NEW MUST-ADDRESS NON-CRITICAL FINDINGS (real consequences if shipped \u2014 incorrect behavior, missing validation, regressions the author should fix before merge): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> [!IMPORTANT]\\n> ...\`, followed by the PR summary using the default format below. Do NOT use this tier for nits, style preferences, or "consider also" suggestions.
-   - ELSE IF NEW MINOR SUGGESTIONS ONLY (single-line nits, doc/comment polish, defer-able observations, "rough edges"): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> \u2139\uFE0F No critical issues \u2014 minor suggestions inline.\\n\\n\` (vary the wording after \u2139\uFE0F to fit the review), followed by the PR summary using the default format below.
-   - ELSE IF INFORMATIONAL OBSERVATIONS (mergeable as-is, but worth surfacing \u2014 e.g. prior feedback addressed cleanly with one minor stale doc reference, or a noteworthy positive observation): call \`${t("create_pull_request_review")}\` with \`approved: true\`, NO inline comments, and the review body. body opens with \`> \u2705 No new issues found.\\n\\n\` (or similar friendly green opener), followed by the PR summary using the default format below. If a point is concrete enough to anchor to a line, downgrade the whole review to "minor suggestions only" (\`approved: false\`) instead \u2014 the \u2705 signals "no action needed", which contradicts an actionable anchor.
+   - ELSE IF NEW MINOR SUGGESTIONS ONLY (low-stakes findings, or Nitpicks only): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> \u2139\uFE0F No critical issues \u2014 minor suggestions inline.\\n\\n\` (vary the wording after \u2139\uFE0F to fit the review), followed by the PR summary using the default format below.
+   - ELSE IF INFORMATIONAL OBSERVATIONS (mergeable as-is, but worth surfacing \u2014 e.g. prior feedback addressed cleanly, or a noteworthy positive observation): call \`${t("create_pull_request_review")}\` with \`approved: true\`, NO inline comments, and the review body. body opens with \`> \u2705 No new issues found.\\n\\n\` (or similar friendly green opener), followed by the PR summary using the default format below. If a point is concrete enough to anchor to a line, downgrade the whole review to "minor suggestions only" (\`approved: false\`) instead \u2014 the \u2705 signals "no action needed", which contradicts an actionable anchor.
    - ELSE IF NO NEW ISSUES, SUBSTANTIVE CHANGES (new functionality, behavior changes, or fixes to prior review feedback): call \`${t("create_pull_request_review")}\` to create a PR review. If all previous reviews have been properly addressed and no new issues were discovered, set \`approved: true\`. body opens with \`> \u2705 No new issues found.\\n\\n\`, followed by the PR summary using the default format below.
 
 ${PR_SUMMARY_FORMAT}`

package/dist/utils/codexHome.d.ts

@@ -78,5 +78,7 @@ export interface InstalledCodexHome {
  * call. callers treat null as "codex CLI can't use this credential".
  */
 export declare function installCodexHome(): InstalledCodexHome | null;
+/** subscriptions this run held but could not install, so a no-key error can name the real cause. */
+export declare const unhostedSubscriptions: Set<string>;
 /** false for a Codex or Grok subscription on a runner that cannot host it (`resolveDataHome`). */
 export declare function canInstallSubscription(name: string): boolean;

package/dist/utils/github.d.ts

@@ -1,6 +1,6 @@
 import { throttling } from "@octokit/plugin-throttling";
 import { Octokit } from "@octokit/rest";
-import * as yes from "../yes/index.ts";
+import * as yes from "yes";
 /** GitHub Actions OIDC request credentials, stashed before env wipes */
 export interface OidcCredentials {
     requestUrl: string;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pullfrog",
-  "version": "0.1.93",
+  "version": "0.1.95",
   "cliContractVersion": "1",
   "type": "module",
   "bin": {
@@ -42,7 +42,6 @@
     "@standard-schema/spec": "1.1.0",
     "@toon-format/toon": "^1.0.0",
     "@types/node": "^24.7.2",
-    "@types/object-hash": "^3.0.6",
     "@types/semver": "^7.7.1",
     "@types/turndown": "^5.0.5",
     "agent-browser": "0.25.4",
@@ -56,8 +55,6 @@
     "fastmcp": "^3.34.0",
     "file-type": "^21.3.0",
     "husky": "^9.0.0",
-    "lru-cache": "^11.0.0",
-    "object-hash": "^3.0.0",
     "opencode-ai": "1.18.29",
     "package-manager-detector": "^1.6.0",
     "picocolors": "^1.1.1",
@@ -69,6 +66,7 @@
     "undici": "^7.22.0",
     "vitest": "^4.0.17",
     "yaml": "^2.8.2",
+    "yes": "0.1.0",
     "zod": "4.3.6"
   },
   "repository": {
@@ -102,12 +100,6 @@
       "import": "./dist/internal.js",
       "default": "./dist/internal.js"
     },
-    "./yes": {
-      "@pullfrog/source": "./yes/index.ts",
-      "types": "./dist/yes/index.d.ts",
-      "import": "./dist/yes.js",
-      "default": "./dist/yes.js"
-    },
     "./package.json": "./package.json"
   },
   "packageManager": "pnpm@10.27.0+sha512.72d699da16b1179c14ba9e64dc71c9a40988cbdc65c264cb0e489db7de917f20dcf4d64d8723625f2969ba52d4b7e2a1170682d9ac2a5dcaeaab732b7e16f04a"

package/dist/yes/index.d.ts

@@ -1,59 +0,0 @@
-import type { StandardSchemaV1 } from "./standard-schema.ts";
-export type { StandardSchemaV1 } from "./standard-schema.ts";
-export declare function range(n: number): number[];
-export declare function range(start: number, end: number): number[];
-export declare function range(n: number, fn: (i: number) => number): number[];
-export declare function schedule(fn: (i: number) => number, count: number): number[];
-/**
- * read a retry delay (ms) from a thrown HTTP error's response headers, honoring
- * GitHub's rate-limit backoff hints on octokit errors (`error.response.headers`, or
- * `error.headers` on a GraphQL response error):
- *   - `retry-after` (RFC 9110 delta-seconds or an HTTP-date) — an explicit
- *     backoff directive whenever present (covers secondary rate limits, which
- *     carry it with `x-ratelimit-remaining > 0`).
- *   - else `x-ratelimit-reset` (epoch seconds) but ONLY when
- *     `x-ratelimit-remaining` is `"0"` — GitHub sends the reset header on ~every
- *     response (~1h ahead), so it's a backoff hint only under actual primary
- *     rate-limit exhaustion (matching octokit's throttling plugin). without this
- *     gate a non-rate-limit retried error (e.g. a permissions 403) would be
- *     wrongly delayed to the reset time.
- * returns `undefined` when no applicable hint is present/parseable.
- */
-export declare function retryAfterMs(error: unknown): number | undefined;
-type InferInput<S> = S extends StandardSchemaV1<infer I, any> ? I : never;
-type InferOutput<S> = S extends StandardSchemaV1<any, infer O> ? O : never;
-export interface OpOptions<TReturn = any> {
-    name?: string;
-    ttl?: number;
-    maxItems?: number;
-    retries?: number[];
-    /**
-     * honor a server backoff hint on retries: when a retried error carries a
-     * `retry-after` / `x-ratelimit-reset` header, schedule the next retry from
-     * that value (clamped to `[fixed delay, retryAfterCap]`) instead of the fixed
-     * `retries[attempt]` backoff. `true` uses the built-in `retryAfterMs` reader;
-     * a function extracts a delay-ms from a custom error shape. errors without the
-     * header fall back to the fixed backoff.
-     */
-    retryAfter?: boolean | ((error: unknown) => number | undefined);
-    /** cap (ms) on a honored retry-after hint. default 20000. */
-    retryAfterCap?: number;
-    cacheHit?: ((key: string) => void) | null;
-    cacheMiss?: ((key: string) => void) | null;
-    skipCache?: (result: TReturn) => boolean;
-    bail?: (error: unknown) => boolean;
-}
-export interface OpObjectOptions<TInputSchema extends StandardSchemaV1 | undefined = undefined, TOutputSchema extends StandardSchemaV1 | undefined = undefined, TRun extends (input: TInputSchema extends StandardSchemaV1 ? InferOutput<TInputSchema> : any, ctx?: any) => Promise<TOutputSchema extends StandardSchemaV1 ? InferInput<TOutputSchema> : any> = (input: TInputSchema extends StandardSchemaV1 ? InferOutput<TInputSchema> : any, ctx?: any) => Promise<TOutputSchema extends StandardSchemaV1 ? InferInput<TOutputSchema> : any>> extends OpOptions<TOutputSchema extends StandardSchemaV1 ? InferOutput<TOutputSchema> : Awaited<ReturnType<TRun>>> {
-    input?: TInputSchema;
-    output?: TOutputSchema;
-    run: TRun;
-}
-type AnyAsyncFn = (...args: any[]) => Promise<any>;
-type Input<F extends AnyAsyncFn> = Parameters<F>[0];
-export type OpFunction<F extends AnyAsyncFn> = F & {
-    clear: (key?: Input<F>) => void;
-    has: (key: Input<F>) => boolean;
-    invalidate: (predicate: (key: Input<F>) => boolean) => number;
-};
-export declare function op<F extends AnyAsyncFn>(fn: F, options?: OpOptions<Awaited<ReturnType<F>>>): OpFunction<F>;
-export declare function op<TInputSchema extends StandardSchemaV1 | undefined = undefined, TOutputSchema extends StandardSchemaV1 | undefined = undefined, TRun extends (input: TInputSchema extends StandardSchemaV1 ? InferOutput<TInputSchema> : any, ctx?: any) => Promise<TOutputSchema extends StandardSchemaV1 ? InferInput<TOutputSchema> : any> = (input: TInputSchema extends StandardSchemaV1 ? InferOutput<TInputSchema> : any, ctx?: any) => Promise<TOutputSchema extends StandardSchemaV1 ? InferInput<TOutputSchema> : any>>(options: OpObjectOptions<TInputSchema, TOutputSchema, TRun>): OpFunction<(input: TInputSchema extends StandardSchemaV1 ? InferInput<TInputSchema> : Parameters<TRun>[0], ctx?: TRun extends (input: any, ctx: infer C, ...rest: any[]) => any ? C : never) => Promise<TOutputSchema extends StandardSchemaV1 ? InferOutput<TOutputSchema> : Awaited<ReturnType<TRun>>>>;

package/dist/yes/standard-schema.d.ts

@@ -1,117 +0,0 @@
-/** The Standard Typed interface. This is a base type extended by other specs. */
-export interface StandardTypedV1<Input = unknown, Output = Input> {
-    /** The Standard properties. */
-    readonly "~standard": StandardTypedV1.Props<Input, Output>;
-}
-export declare namespace StandardTypedV1 {
-    /** The Standard Typed properties interface. */
-    interface Props<Input = unknown, Output = Input> {
-        /** The version number of the standard. */
-        readonly version: 1;
-        /** The vendor name of the schema library. */
-        readonly vendor: string;
-        /** Inferred types associated with the schema. */
-        readonly types?: Types<Input, Output> | undefined;
-    }
-    /** The Standard Typed types interface. */
-    interface Types<Input = unknown, Output = Input> {
-        /** The input type of the schema. */
-        readonly input: Input;
-        /** The output type of the schema. */
-        readonly output: Output;
-    }
-    /** Infers the input type of a Standard Typed. */
-    type InferInput<Schema extends StandardTypedV1> = NonNullable<Schema["~standard"]["types"]>["input"];
-    /** Infers the output type of a Standard Typed. */
-    type InferOutput<Schema extends StandardTypedV1> = NonNullable<Schema["~standard"]["types"]>["output"];
-}
-/** The Standard Schema interface. */
-export interface StandardSchemaV1<Input = unknown, Output = Input> {
-    /** The Standard Schema properties. */
-    readonly "~standard": StandardSchemaV1.Props<Input, Output>;
-}
-export declare namespace StandardSchemaV1 {
-    /** The Standard Schema properties interface. */
-    interface Props<Input = unknown, Output = Input> extends StandardTypedV1.Props<Input, Output> {
-        /** Validates unknown input values. */
-        readonly validate: (value: unknown, options?: StandardSchemaV1.Options | undefined) => Result<Output> | Promise<Result<Output>>;
-    }
-    /** The result interface of the validate function. */
-    type Result<Output> = SuccessResult<Output> | FailureResult;
-    /** The result interface if validation succeeds. */
-    interface SuccessResult<Output> {
-        /** The typed output value. */
-        readonly value: Output;
-        /** A falsy value for `issues` indicates success. */
-        readonly issues?: undefined;
-    }
-    interface Options {
-        /** Explicit support for additional vendor-specific parameters, if needed. */
-        readonly libraryOptions?: Record<string, unknown> | undefined;
-    }
-    /** The result interface if validation fails. */
-    interface FailureResult {
-        /** The issues of failed validation. */
-        readonly issues: ReadonlyArray<Issue>;
-    }
-    /** The issue interface of the failure output. */
-    interface Issue {
-        /** The error message of the issue. */
-        readonly message: string;
-        /** The path of the issue, if any. */
-        readonly path?: ReadonlyArray<PropertyKey | PathSegment> | undefined;
-    }
-    /** The path segment interface of the issue. */
-    interface PathSegment {
-        /** The key representing a path segment. */
-        readonly key: PropertyKey;
-    }
-    /** The Standard types interface. */
-    interface Types<Input = unknown, Output = Input> extends StandardTypedV1.Types<Input, Output> {
-    }
-    /** Infers the input type of a Standard. */
-    type InferInput<Schema extends StandardTypedV1> = StandardTypedV1.InferInput<Schema>;
-    /** Infers the output type of a Standard. */
-    type InferOutput<Schema extends StandardTypedV1> = StandardTypedV1.InferOutput<Schema>;
-}
-/** The Standard JSON Schema interface. */
-export interface StandardJSONSchemaV1<Input = unknown, Output = Input> {
-    /** The Standard JSON Schema properties. */
-    readonly "~standard": StandardJSONSchemaV1.Props<Input, Output>;
-}
-export declare namespace StandardJSONSchemaV1 {
-    /** The Standard JSON Schema properties interface. */
-    interface Props<Input = unknown, Output = Input> extends StandardTypedV1.Props<Input, Output> {
-        /** Methods for generating the input/output JSON Schema. */
-        readonly jsonSchema: StandardJSONSchemaV1.Converter;
-    }
-    /** The Standard JSON Schema converter interface. */
-    interface Converter {
-        /** Converts the input type to JSON Schema. May throw if conversion is not supported. */
-        readonly input: (options: StandardJSONSchemaV1.Options) => Record<string, unknown>;
-        /** Converts the output type to JSON Schema. May throw if conversion is not supported. */
-        readonly output: (options: StandardJSONSchemaV1.Options) => Record<string, unknown>;
-    }
-    /**
-     * The target version of the generated JSON Schema.
-     *
-     * It is *strongly recommended* that implementers support `"draft-2020-12"` and `"draft-07"`, as they are both in wide use. All other targets can be implemented on a best-effort basis. Libraries should throw if they don't support a specified target.
-     *
-     * The `"openapi-3.0"` target is intended as a standardized specifier for OpenAPI 3.0 which is a superset of JSON Schema `"draft-04"`.
-     */
-    type Target = "draft-2020-12" | "draft-07" | "openapi-3.0" | ({} & string);
-    /** The options for the input/output methods. */
-    interface Options {
-        /** Specifies the target version of the generated JSON Schema. Support for all versions is on a best-effort basis. If a given version is not supported, the library should throw. */
-        readonly target: Target;
-        /** Explicit support for additional vendor-specific parameters, if needed. */
-        readonly libraryOptions?: Record<string, unknown> | undefined;
-    }
-    /** The Standard types interface. */
-    interface Types<Input = unknown, Output = Input> extends StandardTypedV1.Types<Input, Output> {
-    }
-    /** Infers the input type of a Standard. */
-    type InferInput<Schema extends StandardTypedV1> = StandardTypedV1.InferInput<Schema>;
-    /** Infers the output type of a Standard. */
-    type InferOutput<Schema extends StandardTypedV1> = StandardTypedV1.InferOutput<Schema>;
-}