@method-ai-hq/sdk 0.14.6 → 0.15.0

package/README.md

@@ -3,7 +3,7 @@
 MIT-licensed JavaScript API and the `method` CLI. Source and releases: https://github.com/method-ai-hq/method-sdk
 
 ```sh
-npm install https://github.com/method-ai-hq/method-sdk/releases/download/v0.14.6/method-ai-hq-sdk-0.14.6.tgz
+npm install https://github.com/method-ai-hq/method-sdk/releases/download/v0.15.0/method-ai-hq-sdk-0.15.0.tgz
 npx method --version
 ```
 

package/dist/packages/sdk/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@method-ai-hq/sdk",
-    "version": "0.14.6",
+    "version": "0.15.0",
     "description": "Build and run reusable .method files with checked steps and saved results.",
     "license": "MIT",
     "type": "module",

package/dist/packages/sdk/src/authoring-instructions.d.ts

@@ -5,7 +5,7 @@ export declare const designProcedure = "# Choose the design\n\n| Requirement | S
 /** The full check rules; in concepts. */
 export declare const checkRules = "# Checks\n\nAdd a check only when it catches a concrete failure that matters to the result. Output types and the runtime already validate shapes; do not repeat them. Do not check wording, headings, keywords, lengths, or counts unless the task requires them: \"write accurate prose\" is not a reason to match strings.\n\nUse the simplest check that proves the fact: a built-in equals, count, present, or file check, a script, or an agent check. Local file writes need no check: the runtime observes files connections itself. A change to a service, an API, email, or a browser that sends needs an effect that reads the result back, because a receipt or a 200 status shows only that the request was accepted. Use a built-in observer (http, sqlite, file) when one fits. When a change cannot or need not be observed, such as a browser step that only reads, write no_effect_reason instead.\n\nExisting checks and tests are implementation choices, not user requirements. Remove a check that is unnecessary, repeats other validation, or enforces a requirement that nobody asked for. Delete the tests and instructions that exist only for it, and do not replace it. Do not change useful output only to satisfy a check.\n";
 /** The rules that make a first Method work quickly. They come before every other part of the guide. */
-export declare const firstMethodRules = "# Build a Method\n\n1. **Sign in first.** Run `method status`. If it is not signed in, run `method login` and let the user approve in the browser. Signed in, model and classification steps need no keys, each run saves a version when the file changed, and runs appear on the dashboard.\n2. **Each model or classifier request is its own step**: `call`, `agent`, or `classify`, with its prompt in the Method, so the user can change one prompt, run again, and compare. A script never calls a model API. When the user already has code that does the work, keep its fixed logic as `run` steps and move each prompt and rubric into its own step; do not wrap the code. \"The same thing\" means the same behavior in steps. If a request cannot become a step because Method lacks a feature, tell the user what is missing.\n3. **Show the design, then build it in the same turn.** Show each step with its type, purpose, and output, and a table of the prompts and rubrics in the user's existing work, each with the step that holds it. Do not wait for approval unless the user asked to approve first. Ask only for information that you cannot find and that would change the design.\n4. **Run early and often.** Write the first steps, validate, run, then add the next steps. Fix errors. Fix each warning, or accept it with the user's reason. Never add a check only to remove a warning. A new run reuses every step whose definition and inputs did not change, so each run executes only what changed. `--rerun STEP` runs a step again anyway; `--fresh` runs every step.\n5. **Keep the inputs of the existing code.** If the code takes an ID and looks up the record, the Method takes the same ID and looks it up the same way.\n6. **Use the defaults without asking.** Model steps use the account's hosted models and `classify` uses Method's classifier, so no model or classifier keys are needed. To keep the model that existing code uses, add `models: {writer: provider/model}` to the Method and use `model: writer` in the steps (or `model: provider/model` on the step); it needs no key. Keep the models that the Method or the existing code names: when a model step fails, show the error and ask before you change its model. Run records go to the user's account. When the user asks that run data stay on this computer or not be uploaded, set `run_data: device`: the run's inputs, outputs, and files stay here, and the account keeps only each step's status and timing. Model steps still send each step's input to the model to answer it; nothing is kept. Tell the user that in one line, then run again.\n7. **Keys stay out of chat.** Declare each key that a script needs under `secrets:` with its purpose; every script of the Method receives all of its declared secrets. Run `method secret find` in the Method's folder: it lists the key files nearby and the names in each, never the values, and prints the import command. Run that command and tell the user which file each key came from: the key stays on this computer, so there is nothing to ask. If it finds nothing, ask the user to run `method secret set NAME`, which opens a private form in their browser. Never open, print, or search a key file (`cat`, `grep`, an editor), including Method's own secret store, and never ask for a value in chat: the values would go into the chat. When a run says Method's model credit is used up, run `method config model-key` yourself: it takes the user's own OpenRouter key from the one nearby key file that holds it, or opens a private form for it. Then run again.\n8. **Choose a sample yourself** from the user's data, and check that it has the sources the Method needs. Ask only when there is no good sample.\n9. **Iterate.** `method run` prints a `dashboard` link when the run starts and again with its result. Give the user the link as soon as the run starts. After a good run, show the result and the link, and ask what to change. Change the step and run again. Show only results that a run made: never write or edit a result by hand, and fix a wrong result in the Method, not in the data it reads. If you cannot run, say so.\n10. **Publish** with `method publish FILE --reason TEXT` when the user wants to share or schedule a version. It runs the Method's cases first.\n11. **Talk about the work, not about Method.** Unless the user asks, do not mention Method's versions, formats, settings files, or other internal files, and do not ask the user about them, about models, or about which saved version to use. Method updates itself and converts older Method files when it runs them. When the user asks whether a Method works, or asks you to make it work, run it with the inputs of a recent run and show the result and the dashboard link in a few sentences. Say that it works only after a run completed.\n12. **One file for each Method.** Change and run a Method in its own file. Do not copy it to a temporary or other folder to change it: Method does not run or save the copy while the Method's file exists, and names that file.\n13. **Questions in a run are for the user.** When a run stops with `needs_input`, ask the user its `question` in plain words, wait for the answer, and continue the run with it as the output says. Never answer it yourself.\n\nWhen a run fails, read its `fix` and `diagnostics`, change the step, and run again.\n";
+export declare const firstMethodRules = "# Build a Method\n\n1. **Sign in first.** Run `method status`. If it is not signed in, run `method login` and let the user approve in the browser. Signed in, model and classification steps need no keys, each run saves a version when the file changed, and runs appear on the dashboard.\n2. **Each model or classifier request is its own step**: `call`, `agent`, or `classify`, with its prompt in the Method, so the user can change one prompt, run again, and compare. A script never calls a model API. When the user already has code that does the work, keep its fixed logic as `run` steps and move each prompt and rubric into its own step; do not wrap the code. \"The same thing\" means the same behavior in steps. If a request cannot become a step because Method lacks a feature, tell the user what is missing.\n3. **Show the design, then build it in the same turn.** Show each step with its type, purpose, and output, and a table of the prompts and rubrics in the user's existing work, each with the step that holds it. Do not wait for approval unless the user asked to approve first. Ask only for information that you cannot find and that would change the design.\n4. **Run early and often.** Write the first steps, validate, run, then add the next steps. Fix errors. Fix each warning, or accept it with the user's reason. Never add a check only to remove a warning. A new run reuses every step whose definition and inputs did not change, so each run executes only what changed. `--rerun STEP` runs a step again anyway; `--fresh` runs every step.\n5. **Keep the inputs of the existing code.** If the code takes an ID and looks up the record, the Method takes the same ID and looks it up the same way.\n6. **Use the defaults without asking.** Model steps use the account's hosted models and `classify` uses Method's classifier, so no model or classifier keys are needed. To keep the model that existing code uses, add `models: {writer: provider/model}` to the Method and use `model: writer` in the steps (or `model: provider/model` on the step); it needs no key. Keep the models that the Method or the existing code names: when a model step fails, show the error and ask before you change its model. Run records go to the user's account. When the user asks that run data stay on this computer or not be uploaded, set `run_data: device`: the run's inputs, outputs, and files stay here, and the account keeps only each step's status and timing. Model steps still send each step's input to the model to answer it; nothing is kept. Tell the user that in one line, then run again.\n7. **Keys stay out of chat.** Declare each key that a script needs under `secrets:` with its purpose; every script of the Method receives all of its declared secrets. Run `method secret find` in the Method's folder: it lists the key files nearby and the names in each, never the values, and prints the import command. Run that command and tell the user which file each key came from: the key stays on this computer, so there is nothing to ask. If it finds nothing, ask the user to run `method secret set NAME`, which opens a private form in their browser. Never open, print, or search a key file (`cat`, `grep`, an editor), including Method's own secret store, and never ask for a value in chat: the values would go into the chat. When a run says Method's model credit is used up, run `method config model-key` yourself: it takes the user's own OpenRouter key from the one nearby key file that holds it, or opens a private form for it. Then run again.\n8. **Choose a sample yourself** from the user's data, and check that it has the sources the Method needs. Ask only when there is no good sample.\n9. **Iterate.** `method run` prints a `dashboard` link when the run starts and again with its result. Give the user the link as soon as the run starts. After a good run, show the result and the link, and ask what to change. Change the step and run again. Show only results that a run made: never write or edit a result by hand, and fix a wrong result in the Method, not in the data it reads. If you cannot run, say so.\n10. **Publish** with `method publish FILE --reason TEXT` when the user wants to share or schedule a version. It runs the Method's cases first.\n11. **Talk about the work, not about Method.** Unless the user asks, do not mention Method's versions, formats, settings files, or other internal files, and do not ask the user about them, about models, or about which saved version to use. Method updates itself and converts older Method files when it runs them. When the user asks whether a Method works, or asks you to make it work, run it with the inputs of a recent run (`--inputs-from RUN_ID`) and show the result and the dashboard link in a few sentences. Say that it works only after a run completed.\n12. **One file for each Method.** Change and run a Method in its own file. Do not copy it to a temporary or other folder to change it: Method does not run or save the copy while the Method's file exists, and names that file.\n13. **Questions in a run are for the user.** When a run stops with `needs_input`, ask the user its `question` in plain words, wait for the answer, and continue the run with it as the output says. Never answer it yourself.\n14. **Make each run easy to find and to run again.** Give the Method a `run_label` that tells its runs apart, such as `inputs.topic`. When an input can be empty and a default picks the value, point `run_label` at the step output that holds the resolved value, not at the input. Put the readable output, such as the report text or the message, in `result`, not only in files. Write a `run_prompt` that says where each input comes from (for example \"as_of is today's date in YYYY-MM-DD\") and what to show at the end. Leave SDK, runtime, and version details out of it.\n15. **Run again from the dashboard.** When the user pastes a \"Run again\" prompt from the dashboard, run with `--inputs-from RUN_ID` and change only what the prompt names: put those values in a file and add `--inputs FILE`.\n\nWhen a run fails, read its `fix` and `diagnostics`, change the step, and run again.\n";
 /** How to write the prompt inside a call, agent, or classify step. */
 export declare const promptRules = "# Write each prompt\n\n- **One task per prompt.** If a prompt says \"then\" or has several jobs, make several steps.\n- **Say what to do.** Leave out background that does not change the output.\n- **Show 1 to 3 examples of good output.** Take them from the user's work: examples in an existing prompt, a past output that the user approved, or the first run that the user accepts. Pass a long example as an input, not as text in the prompt.\n- **Put the output shape in `out`**, not in the prompt.\n- **Say what to do when the input does not have the answer**, for example \"leave due empty\". For classify, add an option such as `unclear`.\n\nBefore:\n\n```text\nYou are an expert support analyst with years of experience. Our company values clear\ncommunication. Read the tickets, decide which ones are urgent, write a summary, and\nreturn JSON with a \"summary\" key. Make it good.\n```\n\nAfter (urgency is a classify step before this one; the shape is in `out`):\n\n```text\nWrite a five-sentence summary of this week's support tickets for the team.\nStart with the high-urgency tickets. Quote no customer names.\nWrite it in the style of this summary from an earlier week:\n\n{{example}}\n```\n";
 /** Enough of the format to write a Method without reading the JSON schema. */

package/dist/packages/sdk/src/authoring-instructions.js

@@ -39,9 +39,11 @@ export const firstMethodRules = `# Build a Method
 8. **Choose a sample yourself** from the user's data, and check that it has the sources the Method needs. Ask only when there is no good sample.
 9. **Iterate.** \`method run\` prints a \`dashboard\` link when the run starts and again with its result. Give the user the link as soon as the run starts. After a good run, show the result and the link, and ask what to change. Change the step and run again. Show only results that a run made: never write or edit a result by hand, and fix a wrong result in the Method, not in the data it reads. If you cannot run, say so.
 10. **Publish** with \`method publish FILE --reason TEXT\` when the user wants to share or schedule a version. It runs the Method's cases first.
-11. **Talk about the work, not about Method.** Unless the user asks, do not mention Method's versions, formats, settings files, or other internal files, and do not ask the user about them, about models, or about which saved version to use. Method updates itself and converts older Method files when it runs them. When the user asks whether a Method works, or asks you to make it work, run it with the inputs of a recent run and show the result and the dashboard link in a few sentences. Say that it works only after a run completed.
+11. **Talk about the work, not about Method.** Unless the user asks, do not mention Method's versions, formats, settings files, or other internal files, and do not ask the user about them, about models, or about which saved version to use. Method updates itself and converts older Method files when it runs them. When the user asks whether a Method works, or asks you to make it work, run it with the inputs of a recent run (\`--inputs-from RUN_ID\`) and show the result and the dashboard link in a few sentences. Say that it works only after a run completed.
 12. **One file for each Method.** Change and run a Method in its own file. Do not copy it to a temporary or other folder to change it: Method does not run or save the copy while the Method's file exists, and names that file.
 13. **Questions in a run are for the user.** When a run stops with \`needs_input\`, ask the user its \`question\` in plain words, wait for the answer, and continue the run with it as the output says. Never answer it yourself.
+14. **Make each run easy to find and to run again.** Give the Method a \`run_label\` that tells its runs apart, such as \`inputs.topic\`. When an input can be empty and a default picks the value, point \`run_label\` at the step output that holds the resolved value, not at the input. Put the readable output, such as the report text or the message, in \`result\`, not only in files. Write a \`run_prompt\` that says where each input comes from (for example "as_of is today's date in YYYY-MM-DD") and what to show at the end. Leave SDK, runtime, and version details out of it.
+15. **Run again from the dashboard.** When the user pastes a "Run again" prompt from the dashboard, run with \`--inputs-from RUN_ID\` and change only what the prompt names: put those values in a file and add \`--inputs FILE\`.
 
 When a run fails, read its \`fix\` and \`diagnostics\`, change the step, and run again.
 `;

package/dist/packages/sdk/src/inputs-from.d.ts

@@ -0,0 +1,19 @@
+import type { MethodClient } from "./method-client.js";
+import type { parse } from "./local-cli.js";
+type Flags = ReturnType<typeof parse>["values"];
+type Inputs = Record<string, unknown>;
+/** The run folders on this computer where an earlier run can be: this folder's, the Method folder's, and the CLI's cache. */
+export declare function runFolders(methodFile?: string): string[];
+/**
+ * The inputs of an earlier run. An account run gives them from the server. A device run keeps them on the computer that
+ * ran it, so they come from its run folder; so do the inputs of any run when the server cannot be reached.
+ */
+export declare function inputsOfRun(runId: string, client: MethodClient | undefined, folders: string[]): Promise<Inputs>;
+/**
+ * --inputs-from RUN_ID: the inputs of that run become this run's inputs, saved as inputs-from.json in the run folder.
+ * --inputs FILE replaces single values. The returned flags name that file with --inputs.
+ */
+export declare function withInputsFrom(flags: Flags, runDir: string, methodFile: string | undefined, client: MethodClient | undefined): Promise<Flags>;
+/** Command arguments without the named options and their values. */
+export declare function withoutOptions(args: string[], names: string[]): string[];
+export {};

package/dist/packages/sdk/src/inputs-from.js

@@ -0,0 +1,102 @@
+import { existsSync, readdirSync, readFileSync } from "node:fs";
+import { dirname, join, resolve } from "node:path";
+import { inspectRun } from "./inspect.js";
+import { methodCache } from "./prepare.js";
+import { writePrivateJson } from "./files.js";
+import { authoringPath } from "./authoring.js";
+/** The run folders on this computer where an earlier run can be: this folder's, the Method folder's, and the CLI's cache. */
+export function runFolders(methodFile) {
+    return [...new Set([join(process.cwd(), ".method-runs"), ...(methodFile ? [join(dirname(resolve(methodFile)), ".method-runs")] : []), join(methodCache(), "runs")].map(path => resolve(path)))];
+}
+/** The inputs of a local run folder whose method-sync.json links it to the dashboard run RUN_ID. */
+function localInputs(runId, folders) {
+    for (const folder of folders) {
+        let names = [];
+        try {
+            names = readdirSync(folder);
+        }
+        catch {
+            continue;
+        }
+        for (const name of names) {
+            const directory = join(folder, name), link = join(directory, "method-sync.json");
+            if (!existsSync(link))
+                continue;
+            let state;
+            try {
+                state = JSON.parse(readFileSync(link, "utf8"));
+            }
+            catch {
+                continue;
+            }
+            if (state?.dashboard_id !== runId && state?.id !== runId)
+                continue;
+            try {
+                return inspectRun(directory).inputs;
+            }
+            catch {
+                for (const file of ["setup-inspection.json", "requested-inputs.json"]) {
+                    const path = join(directory, file);
+                    if (!existsSync(path))
+                        continue;
+                    const saved = JSON.parse(readFileSync(path, "utf8"));
+                    return file === "setup-inspection.json" ? saved.inputs ?? {} : saved;
+                }
+            }
+        }
+    }
+    return undefined;
+}
+/**
+ * The inputs of an earlier run. An account run gives them from the server. A device run keeps them on the computer that
+ * ran it, so they come from its run folder; so do the inputs of any run when the server cannot be reached.
+ */
+export async function inputsOfRun(runId, client, folders) {
+    let reason = "This computer is not signed in, so the account was not asked.";
+    if (client?.token()) {
+        try {
+            const { run } = await client.request(`/api/workspace/runs/${encodeURIComponent(runId)}`);
+            if (run?.inspection && run.inspection.content !== "device")
+                return run.inspection.inputs ?? {};
+            reason = "The account keeps no inputs for this run: its content stays on the computer that ran it.";
+        }
+        catch (error) {
+            reason = `The account did not give the run (${error instanceof Error ? error.message : String(error)}).`;
+        }
+    }
+    const found = localInputs(runId, folders);
+    if (found)
+        return found;
+    throw Object.assign(Error(`Found no inputs of run ${runId}. ${reason} No run folder for it (method-sync.json) is in ${folders.join(", ")}. Run this command on the computer that ran it, from its folder, or give the inputs with --inputs FILE.`), { code: "inputs_not_found" });
+}
+/**
+ * --inputs-from RUN_ID: the inputs of that run become this run's inputs, saved as inputs-from.json in the run folder.
+ * --inputs FILE replaces single values. The returned flags name that file with --inputs.
+ */
+export async function withInputsFrom(flags, runDir, methodFile, client) {
+    const runId = flags["inputs-from"];
+    if (!runId)
+        return flags;
+    if (flags.resume)
+        throw Error("A resumed run keeps the inputs it started with. Leave out --inputs-from.");
+    const earlier = await inputsOfRun(runId, client, runFolders(methodFile));
+    const explicit = flags.inputs ? JSON.parse(readFileSync(authoringPath(flags.inputs), "utf8")) : {};
+    const file = join(resolve(runDir), "inputs-from.json");
+    writePrivateJson(file, { ...earlier, ...explicit });
+    const { "inputs-from": _, ...rest } = flags;
+    return { ...rest, inputs: file };
+}
+/** Command arguments without the named options and their values. */
+export function withoutOptions(args, names) {
+    const out = [];
+    for (let i = 0; i < args.length; i++) {
+        const match = args[i].match(/^--([^=]+)(=.*)?$/);
+        if (match && names.includes(match[1])) {
+            if (match[2] === undefined)
+                i++;
+            continue;
+        }
+        out.push(args[i]);
+    }
+    return out;
+}

package/dist/packages/sdk/src/local-cli.d.ts

@@ -7,6 +7,7 @@ export declare function parse(args: string[]): {
         state?: string;
         out?: string;
         inputs?: string;
+        "inputs-from"?: string;
         workspace?: string;
         "run-dir"?: string;
         fresh?: boolean;

package/dist/packages/sdk/src/local-cli.js

@@ -17,12 +17,13 @@ import { Outbox, savedVersions } from "./outbox.js";
 import { readComputerSettings } from "./computer-settings.js";
 import { localSetup } from "./local-setup.js";
 import { readDocument } from "./authoring.js";
+import { withInputsFrom } from "./inputs-from.js";
 import { join } from "node:path";
 import { randomUUID } from "node:crypto";
 const help = "Use method run, steps, prompt, inspect, or doctor. See method help.";
 export function parse(args) {
     return parseArgs({ args, allowPositionals: true, options: {
-            server: { type: "string" }, agent: { type: "string" }, background: { type: "boolean" }, state: { type: "string" }, out: { type: "string" }, inputs: { type: "string" }, workspace: { type: "string" },
+            server: { type: "string" }, agent: { type: "string" }, background: { type: "boolean" }, state: { type: "string" }, out: { type: "string" }, inputs: { type: "string" }, "inputs-from": { type: "string" }, workspace: { type: "string" },
             "run-dir": { type: "string" }, fresh: { type: "boolean" }, rerun: { type: "string", multiple: true }, resume: { type: "boolean" }, human: { type: "string" }, retry: { type: "string", multiple: true },
             "include-files": { type: "boolean" }, verbose: { type: "boolean" }, help: { type: "boolean" }
         } });
@@ -38,6 +39,15 @@ export async function run(target, flags, syncFactory) {
         process.stderr.write(notice + "\n");
     (await import("./prepare.js")).pruneCachedRuns();
     flags = { ...flags, "run-dir": flags["run-dir"] ?? join(process.cwd(), ".method-runs", randomUUID()) };
+    if (flags["inputs-from"]) {
+        let client;
+        if (!syncFactory)
+            try {
+                client = new MethodClient(flags.server);
+            }
+            catch { /* not signed in to this server */ }
+        flags = await withInputsFrom(flags, flags["run-dir"], path, client);
+    }
     const account = syncFactory ? undefined : await accountSync(path, flags);
     try {
         await runCurrentFile(path, flags, syncFactory ?? account?.sync);

package/dist/packages/sdk/src/method-help.js

@@ -37,7 +37,7 @@ export const commandHelp = {
     explain: { usage: "method explain FILE [--step ID] [--no-round-trip] [--server URL]", purpose: "Explain each script step of the saved version in a script card.", arguments: "FILE is a local Method whose current content is a saved version (run or publish it while signed in). For each run step whose script has no card, code analysis finds the hosts, secrets, environment variables, files, and commands the script uses; a hosted model writes a one-sentence summary and 3 to 8 steps; every number, quoted name, and host in that text must appear in the code (one retry). The round trip writes a program from the steps alone and replays up to 3 recorded inputs of the step from local runs through both programs without network access. A script that calls the network is not replayed. --step explains one step. --no-round-trip skips the replay. A signed-in run starts this in the background; publish waits for it.", result: "One line per step with its summary and check results. Cards upload to the version; the dashboard shows them beside each script. A failed check is shown on the card and never blocks publish.", errors: "No saved version, local files that differ from the saved version, or no hosted-model credit. Without sign-in it prints one line and makes no card.", example: "method explain leads.method --step score", remote: true },
     publish: { usage: "method publish FILE [--reason TEXT] [--accept-failing-case ID[,ID]] [--cloud|--workers] [--env NAME] [--server URL]", purpose: "Mark a version as published, for sharing, schedules, and production runs.", arguments: "Runs the Method's cases first; a version that breaks an approved case is refused unless --accept-failing-case names it, and the version records that. Uses the version of the file's current content: it finishes that upload (no time limit while bytes move), checks the cases, then marks it published with the reason (default: Published.). --accept-failing-case needs --reason. The first save of a new file creates the Method. --cloud runs the production runs of the environment on Method Cloud; --workers runs them on your workers again. --env NAME selects the environment (default production).", result: "JSON with workflow_id, version_id, url, published_at, the cases line, and the open warnings and notes (issues). With --cloud or --workers: placement. Warnings and notes never block a publish.", errors: "An error issue (nothing is published), failing case, --accept-failing-case without --reason, or no network.", example: "method publish task.method --reason 'Shorter introduction'", remote: true },
     improve: { usage: "method improve FILE [--case ID] [--note TEXT] [--step ID] [--server URL]", purpose: "Ask Method to propose a better version of a Method.", arguments: "--note: the correction, in your words; it is about the newest run of the Method on this computer, which the improvement reads and a suggested case records. --step: improve only this step. --case: the case the change must pass. A Method with account run data improves in your account; see the progress on the dashboard. A Method with run_data: device improves on this computer, so its run content stays here; the result is a local proposal in .method/proposals/.", result: "JSON with the improvement and the dashboard link, or the local proposal ID. Nothing is published, and the file does not change.", errors: "No id: line (run the file once while signed in), an unknown step, or an improvement that is already running.", example: "method improve task.method --step summary --note 'Name the customer in the first sentence.'", remote: true },
-    proposals: { usage: "method proposals FILE [--wait] [--server URL]", purpose: "List the proposals of a Method.", arguments: "Lists the proposals in your account and the local proposals beside the file. --wait: when an improvement is running, wait until it ends (usually a few minutes), printing each step it reaches.", result: "JSON list of proposals with id, source, status, kind, cause, and steps, and the newest improvement that has no proposal yet, with its status. No changes.", errors: "", example: "method proposals task.method", remote: true },
+    proposals: { usage: "method proposals FILE [--wait] [--server URL]", purpose: "List the proposals of a Method.", arguments: "Lists the proposals in your account and the local proposals beside the file. --wait: when an improvement is running, wait until it ends (usually a few minutes), printing each step it reaches.", result: "JSON list of proposals with id, source, status, kind, cause, and steps, and the newest improvement that has no proposal yet, with its status. An improvement that found no safe change has outcome none, and next says what to do instead. No changes.", errors: "", example: "method proposals task.method", remote: true },
     apply: { usage: "method apply FILE [PROPOSAL_ID] [--resolved] [--server URL]", purpose: "Merge a proposal into the local file.", arguments: "Default: the newest accepted proposal, or else the newest local proposal. The merge is per step: a part that only the proposal changed takes the change; a part that you and the proposal both changed is a conflict. --resolved: you merged a conflict by hand; this marks the proposal applied. Commands that take a signed-in FILE apply an accepted proposal first and print one line.", result: "JSON with status applied and the changed steps; the file changes and the proposal is marked applied. Nothing is published. A conflict lists each part with the base, your, and the proposed value, changes nothing, and exits 1.", errors: "No proposal, a proposal that is not accepted, or a conflict.", example: "method apply task.method", remote: true },
     secret: { usage: "method secret find [FILE]\nmethod secret import FILE NAME...\nmethod secret set NAME\nmethod secret list [NAME...]", purpose: "Give this computer the values of a Method's declared secrets.", arguments: "find lists the KEY=VALUE files in this folder (3 levels down) and in the parent folder (2 levels down) with the key names in each, never values; for the Method FILE (or the only Method here) it says which declared secrets each file holds and prints the import command. import copies the named values from a KEY=VALUE file that the user names, without printing them. set opens a private form on 127.0.0.1 in the browser for one value. list shows names and where each value is found (shell, this computer, or missing), never values. Values are kept in ~/.config/method/secrets.json (mode 0600) and are never sent to Method. A value exported in the shell is used first. Every script of the Method receives all of its declared secrets.", result: "JSON with the saved names, or the list.", errors: "A name is missing from the file, or no value was entered.", example: "method secret find\nmethod secret import ../service/.env ARCHIVE_TOKEN" },
     connect: { usage: "method connect [APP_FOLDER] [--file METHOD_FILE]", purpose: "Connect an app to the Method in this folder, so the app runs it in production.", arguments: "Run it in the Method's folder. APP_FOLDER (default: this folder) is the app's folder. It makes a service key named after the app folder and writes METHOD_API_KEY to the app's .env (a new file, or a new or replaced line); it never prints the key. It adds .env to .gitignore in a git repository. When the Method has no published version, it publishes the current file. It detects Node (package.json) or Python (pyproject.toml, requirements.txt), and prints the install line and the code to add. Run it again: an app with a working key keeps it.", result: "JSON with the method_id, the published version, where the key is, install, code, secrets_to_set_on_the_host, and next.", errors: "No or several .method files (give --file), an app folder with no language marker, or a failing case at publish.", example: "method connect ../app", remote: true },
@@ -58,6 +58,7 @@ export const commandHelp = {
     run: { usage: "method run FILE.method [OPTIONS]\nmethod run WORKFLOW_ID [--version VERSION_ID] [--server URL] [OPTIONS]", purpose: "Run a local .method file, or a saved Method by ID. When this computer is signed in, a run of a local file starts at once and saves in the background: the version of the file's content and the run's records go to the dashboard through the outbox (~/.cache/method/outbox), and the last line says Saved as version N, or Will save when online; without sign-in the records stay in .method-runs. Steps whose definition and inputs match an earlier accepted run on this computer are reused.", arguments: `Models come from the Method's models: (or the account default); --agent codex|claude or method config agent runs model steps with a local agent. --workspace selects a different helper folder. See method authoring execution. Optional --state FILE initializes state for a new run. Resume with --resume --run-dir DIR; authorize unfinished work with --retry STEP:ITERATION.
 
 --inputs FILE: JSON input values.
+--inputs-from RUN_ID: use the inputs of that run; --inputs FILE overrides single values.
 --run-dir DIR: the folder for this run's records (new runs too; default .method-runs/ID).
 --agent codex|claude: run every model step of a new run with this local agent.
 --resume: continue the same saved run with its saved agent.
@@ -180,9 +181,9 @@ ${designExamples}
 A method has format, name, goal, steps, and result, and optional id, inputs, secrets, state, environment, files, models, limits, tools, run_data, run_label, and run_prompt (see the field reference in method authoring).
 Each step uses do or ask. The do kinds are run, call, agent, and classify. Give script actions a name and a purpose; describe script checks in reading.check. A classify action takes bound inputs, a question, and one of options (a named choice with probabilities), answer: yes_no (answer and the probability of yes), or levels (2-10 ordered names; the most likely level, an expected level index as score, and probabilities). Use a script to apply business rules to that result.
 run uses runtime and entrypoint; call uses model and prompt; agent can select browser: environment.NAME and optional custom tools.
-Optional run_label selects one saved text, number, or boolean value, such as inputs.topic or steps.prepare.outputs.plan.date. Step references must select a step without each or repeat. Choose a short non-sensitive value. The site uses the current Method's reference with each run's recorded inputs or outputs; absent or empty values keep timestamps. Set it with method set task.method /run_label --json '"steps.prepare.outputs.plan.date"'.
+Optional run_label selects one saved text, number, or boolean value, such as inputs.topic or steps.prepare.outputs.plan.date. Step references must select a step without each or repeat. Choose a short non-sensitive value that tells runs apart. When an input can be empty and a default picks the value, select the step output that holds the resolved value, not the input. The site uses the current Method's reference with each run's recorded inputs or outputs; absent or empty values keep timestamps. Set it with method set task.method /run_label --json '"steps.prepare.outputs.plan.date"'.
 
-Optional run_prompt is plain text for the outside agent that starts a saved Method. Write which Method to run, where to find its inputs, and what to show when finished. Save it with the Method version and update it when inputs or outputs change. The copy button appends the exact version link and shared CLI setup; do not repeat them in run_prompt. This field is not a step prompt and does not expand variables. Set it with method set task.method /run_prompt --text-file run-prompt.txt.
+Optional run_prompt is plain text for the outside agent that starts a saved Method. Write which Method to run, where each input comes from (for example "as_of is today's date in YYYY-MM-DD"), and what to show when finished. Leave out SDK, runtime, and version details. Save it with the Method version and update it when inputs or outputs change. The copy button appends the exact version link and shared CLI setup; do not repeat them in run_prompt. This field is not a step prompt and does not expand variables. Set it with method set task.method /run_prompt --text-file run-prompt.txt.
 
 Model and human prompts use {{date}} for the step input declared as in.date. Nested fields such as {{customer.name}} are allowed. Only text, numbers, and booleans can be inserted; pass lists and records as structured inputs. Whitespace inside braces is allowed. Escape a literal placeholder with a backslash before its opening braces (use a YAML block scalar). Values are inserted once, never evaluated or expanded again. Unknown variables, invalid paths, and non-scalar values fail validation. Missing runtime values fail before model execution. Defaults belong in input declarations. Human ask text uses the same scope; agent check prompts use {{inputs.date}} and {{outputs.answer}}. Script commands, labels, and tool descriptions are not templates. Single braces are ordinary text.
 Runs record prompt.rendered with the template and expanded instructions for each invocation and phase; the run page shows the recorded expansion, with templates in technical details. Model and agent work uses finite default limits; steps can override them.
@@ -252,7 +253,7 @@ destination and the rule used.”
 const execution = `
 # Execution setup
 
-Use method run FILE_OR_ID [--inputs inputs.json] [--state state.json] [--run-dir DIR] [--workspace HELPERS_FOLDER] [--agent codex|claude] [--background].
+Use method run FILE_OR_ID [--inputs inputs.json] [--inputs-from RUN_ID] [--state state.json] [--run-dir DIR] [--workspace HELPERS_FOLDER] [--agent codex|claude] [--background].
 A Method needs no configuration file. What changes the result is in the Method: models, limits, tools, and secrets (the names). What belongs to this computer is in ~/.config/method/computer.json: method config (local agent, own model key) and method bind (folders and connections). python and node are found on PATH and prepared automatically. A saved version carries its helpers; versions saved without files still need --workspace DIR.
 
 ## Models

package/dist/packages/sdk/src/method.js

@@ -32,23 +32,28 @@ export function setupFix(error) {
 function safePath(path) {
     return authoringPath(path);
 }
-async function dispatchRunWorker(args, flags, extra = []) {
+async function dispatchRunWorker(args, flags, extra = [], savedClient) {
     if (process.env.METHOD_RUN_WORKER === '1' || (!/[/\\]method\.(?:js|ts)$/.test(process.argv[1] ?? '') && !flags.background))
         return false;
     if (flags.resume && !flags['run-dir'])
         throw Error('Resume needs --run-dir.');
     const directory = safePath(flags['run-dir'] ?? join(methodCache(), 'runs', randomUUID()));
-    const workerArgs = [...args.filter(arg => arg !== '--background'), ...extra];
+    let workerArgs = [...args.filter(arg => arg !== '--background'), ...extra];
     if (!flags['run-dir'])
         workerArgs.push('--run-dir', directory);
-    // A new run of a signed-in computer is synced; a resumed run keeps the link that it has.
-    let server;
+    let client = savedClient;
     try {
-        const client = new MethodClient(flags.server);
-        if (!flags.resume && client.token())
-            server = client.server;
+        client ??= new MethodClient(flags.server);
     }
     catch { /* Not signed in to this server. */ }
+    // The earlier run's inputs are read before the run starts, so a run that cannot find them does not start.
+    if (flags['inputs-from']) {
+        const { withInputsFrom, withoutOptions } = await import('./inputs-from.js');
+        const resolved = await withInputsFrom(flags, directory, /\.method$/i.test(args[1] ?? '') ? args[1] : undefined, client);
+        workerArgs = [...withoutOptions(workerArgs, ['inputs-from', 'inputs']), '--inputs', resolved.inputs];
+    }
+    // A new run of a signed-in computer is synced; a resumed run keeps the link that it has.
+    const server = !flags.resume && client?.token() ? client.server : undefined;
     await startRunWorker(workerArgs, directory, flags.background, server);
     return true;
 }
@@ -370,7 +375,7 @@ export async function methodMain(args = process.argv.slice(2), clientFactory = s
         return;
     }
     const flags = parse(rest.slice(2)).values;
-    if (await dispatchRunWorker(args, flags, values.version ? [] : ['--version', saved.version_id]))
+    if (await dispatchRunWorker(args, flags, values.version ? [] : ['--version', saved.version_id], client))
         return;
     await runSaved(saved, flags, client);
 }

package/dist/packages/sdk/src/proposals.js

@@ -220,7 +220,7 @@ export async function proposalCommand(args, clientFactory) {
                 client.request(`/api/methods/${encodeURIComponent(methodId)}/proposals`),
                 client.request(`/api/methods/${encodeURIComponent(methodId)}/improvements`)
             ]);
-            // The newest improvement that has no proposal yet: still running, or failed. The agent needs to know which.
+            // The newest improvement that has no proposal: still running, failed, or ended with no safe change (outcome none).
             const latest = (improvements ?? []).find(i => !i.proposal_id);
             return { proposals, pending: latest && (latest.created_at ?? '') > String((proposals ?? [])[0]?.created_at ?? '') ? latest : undefined };
         };
@@ -239,10 +239,11 @@ export async function proposalCommand(args, clientFactory) {
         const failedStep = pending?.steps?.find((s) => s.status === 'failed')?.step_id;
         const next = !pending ? undefined
             : ['queued', 'running'].includes(pending.status) ? `Improvement ${pending.id} is ${pending.status}. Run method proposals ${target} --wait: it returns when the proposal is ready.`
-                : pending.status === 'failed' || pending.status === 'cancelled' ? `Improvement ${pending.id} ${pending.status}${failedStep ? ` at step ${failedStep}` : ''}${pending.error?.message ? `: ${pending.error.message}` : ''}. Run method improve ${target} again, or record the correction with method case new.`
-                    : undefined;
+                : pending.outcome === 'none' ? `The improvement found no safe change. Say what is wrong in a note on a run (method improve ${target} --note TEXT), or record a case with method case new.`
+                    : pending.status === 'failed' || pending.status === 'cancelled' ? `Improvement ${pending.id} ${pending.status}${failedStep ? ` at step ${failedStep}` : ''}${pending.error?.message ? `: ${pending.error.message}` : ''}. Run method improve ${target} again, or record the correction with method case new.`
+                        : undefined;
         return print({ file, method_id: methodId, proposals: [...(proposals ?? []).map(p => summary({ ...p, source: 'account' })), ...local].sort((a, b) => String(b.created_at).localeCompare(String(a.created_at))),
-            ...(pending ? { improvement: { id: pending.id, status: pending.status, ...(failedStep ? { failed_step: failedStep } : {}), ...(pending.error ? { error: pending.error } : {}) } } : {}), ...(next ? { next } : {}) });
+            ...(pending ? { improvement: { id: pending.id, status: pending.status, ...(pending.outcome === 'none' ? { outcome: 'none' } : {}), ...(failedStep ? { failed_step: failedStep } : {}), ...(pending.error ? { error: pending.error } : {}) } } : {}), ...(next ? { next } : {}) });
     }
     const local = localProposals(file);
     let proposal = wanted ? local.find(p => p.id === wanted) : undefined;

package/dist/packages/sdk/src/run-saved.js

@@ -10,6 +10,7 @@ import { MethodSync } from './method-sync.js';
 import { recordKnownVersion } from './outbox.js';
 import { writePrivateJson } from './files.js';
 import { readDocument } from './authoring.js';
+import { withInputsFrom } from './inputs-from.js';
 // Older versions are listed only after their saved-package tests pass.
 const supportedPackageRuntimes = new Set([runtimeVersion, '0.11.1', '0.11.0', '0.10.0', '0.9.5', '0.9.4', '0.9.3', '0.7.0', '0.7.1', '0.7.2', '0.8.0', '0.8.1', '0.8.2', '0.8.3']);
 /** A run whose steps all finished: completed, or unconfirmed (an external change could not be confirmed). */
@@ -44,6 +45,7 @@ export async function runSaved(saved, flags, client) {
             return completed;
         }
     }
+    flags = await withInputsFrom(flags, directory, undefined, client);
     const inputFile = join(directory, 'requested-inputs.json');
     const inputs = flags.inputs ? JSON.parse(readFileSync(resolve(flags.inputs), 'utf8')) : existsSync(inputFile) ? JSON.parse(readFileSync(inputFile, 'utf8')) : {};
     writePrivateJson(inputFile, inputs);

package/dist/packages/workflow-language/src/inspection.d.ts

@@ -984,7 +984,7 @@ export declare function inspectCatalog(workflow: Workflow): {
 export declare function copyInstructions(step: Step, inputs?: Record<string, Json>, resources?: Record<string, unknown>): string;
 export declare function observedValue(item: InspectItem, inspection: RunInspection, invocation?: string): Json | undefined;
 /**
- * The device form of a run record (run_data: device). Keep step status, kinds, names, and timing., kinds, names, and timing. Remove inputs, outputs,
- * prompts, files, and free text. The server accepts only this form when an organization keeps run content on devices.
+ * The device form of a run record (run_data: device). Keep step status, kinds, names, timing, and the phase of a failure. Remove inputs, outputs,
+ * prompts, files, errors, and free text. The server accepts only this form when an organization keeps run content on devices.
  */
 export declare function deviceOnly(inspection: RunInspection): RunInspection;

package/dist/packages/workflow-language/src/inspection.js

@@ -112,18 +112,19 @@ export function observedValue(item, inspection, invocation) {
     return value;
 }
 /**
- * The device form of a run record (run_data: device). Keep step status, kinds, names, and timing., kinds, names, and timing. Remove inputs, outputs,
- * prompts, files, and free text. The server accepts only this form when an organization keeps run content on devices.
+ * The device form of a run record (run_data: device). Keep step status, kinds, names, timing, and the phase of a failure. Remove inputs, outputs,
+ * prompts, files, errors, and free text. The server accepts only this form when an organization keeps run content on devices.
  */
 export function deviceOnly(inspection) {
+    const failure = (value) => value ? { failure: { phase: value.phase, expected: '', observed: '', evidence: [] } } : {};
     const event = ({ at, type, sequence, phase, duration_ms, usage, provider, model, kind, exit_code }) => Object.fromEntries(Object.entries({ at, type, sequence, phase, duration_ms, usage, provider, model, kind, exit_code }).filter(([, value]) => value !== undefined));
     return {
-        schema: inspection.schema, content: 'device', workflow: inspection.workflow, run_id: inspection.run_id, status: inspection.status,
+        schema: inspection.schema, content: 'device', workflow: inspection.workflow, run_id: inspection.run_id, status: inspection.status, ...failure(inspection.failure),
         ...(inspection.started_at ? { started_at: inspection.started_at } : {}), ...(inspection.device_name ? { device_name: inspection.device_name } : {}),
         inputs: {}, resources: Object.fromEntries(Object.entries(inspection.resources).map(([name, value]) => [name, { description: value.description }])),
         ...(inspection.events ? { events: inspection.events.map(event) } : {}),
         invocations: Object.fromEntries(Object.entries(inspection.invocations).map(([id, value]) => [id, {
-                step_id: value.step_id, status: value.status, ...(value.verification ? { verification: value.verification } : {}),
+                step_id: value.step_id, status: value.status, ...(value.verification ? { verification: value.verification } : {}), ...failure(value.failure),
                 checks: value.checks.map(check => ({ id: check.id, result: check.result, summary: '', evidence: [], method: check.method })), changes: {}, events: value.events.map(event),
             }])),
     };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@method-ai-hq/sdk",
-  "version": "0.14.6",
+  "version": "0.15.0",
   "description": "Build and run reusable .method files with checked steps and saved results.",
   "license": "MIT",
   "type": "module",