@yagni-app/code 0.3.1 → 0.3.3

package/dist/goHeadless.js

@@ -0,0 +1,132 @@
+/**
+ * `yagni go --headless …` — the scriptable front door to the /go pipeline.
+ *
+ * The pipeline itself lives in the bundled extension (pi-extension-yagni's
+ * `pipeline/headlessGo.ts`). The launcher keeps its usual job: resolve the
+ * active environment's credentials, build the hermetic child environment, point
+ * the pipeline's child resolver at the pinned pi binary, and hand over. As
+ * everywhere else in this package, the extension is reached by FILE PATH and
+ * called through a locally-declared structural type — the two packages stay
+ * independent, and the CLI never takes a build-time dependency on a private
+ * workspace package.
+ *
+ * The mission sandbox invokes exactly this command (`--ticket-file`,
+ * `--plan-file`, optional `--memo-file`, `--run-id`, `--json`), so what Jack
+ * runs locally and what the fleet executes are the same binary and the same
+ * pipeline.
+ */
+import { randomUUID } from "node:crypto";
+import { mkdirSync } from "node:fs";
+import { pathToFileURL } from "node:url";
+import { agentDirEnvVar } from "./branding.js";
+import { agentDir, credentialsDir } from "./credentials.js";
+import { credentialsFromProfile, profilePath, readActiveProfile } from "./profiles.js";
+import { resolveHeadlessGoPath, resolvePiCliPath } from "./paths.js";
+/** Mirrors HEADLESS_GO_EXIT in the extension; duplicated to keep the packages independent. */
+export const GO_EXIT = { verified: 0, unverified: 1, usage: 2 };
+async function defaultLoadHeadless() {
+    const mod = (await import(pathToFileURL(resolveHeadlessGoPath()).href));
+    if (typeof mod?.runHeadlessGo !== "function") {
+        throw new Error("The bundled pipeline is missing its headless entry point.");
+    }
+    return mod;
+}
+/**
+ * Build the environment every pipeline stage child inherits: the proxy
+ * credentials (so the `yagni` provider and the grounding tools reach the
+ * backend), the hermetic pi agent dir, and pi's quiet flags. `YAGNI_CALLER` /
+ * `YAGNI_RUN_ID` are NOT set here — the pipeline stamps a per-stage caller onto
+ * every child, and the run id rides the `--run-id` flag.
+ */
+export function buildHeadlessChildEnv(opts) {
+    const piAgentDir = agentDir(opts.profileName);
+    return {
+        ...opts.baseEnv,
+        YAGNI_SESSION_ID: opts.sessionId ?? randomUUID(),
+        YAGNI_TOKEN: opts.token,
+        YAGNI_BASE_URL: opts.baseUrl,
+        ...(opts.expiresAt ? { YAGNI_TOKEN_EXPIRES_AT: opts.expiresAt } : {}),
+        ...(opts.workspaceId ? { YAGNI_WORKSPACE_ID: opts.workspaceId } : {}),
+        YAGNI_PROFILE_PATH: profilePath(opts.profileName),
+        YAGNI_CODE_HOME: credentialsDir(),
+        ...(opts.cliVersion ? { YAGNI_CODE_VERSION: opts.cliVersion } : {}),
+        [agentDirEnvVar()]: piAgentDir,
+        PI_CODING_AGENT_DIR: piAgentDir,
+        PI_SKIP_VERSION_CHECK: "1",
+        PI_TELEMETRY: "0",
+    };
+}
+/**
+ * Run `yagni go`. Returns the process exit code: 0 only on a verified
+ * candidate, 1 on any other pipeline outcome, 2 on a usage or credential
+ * problem. Never throws.
+ */
+export async function goCommand(args, deps = {}, cliVersion) {
+    const writeErr = deps.writeErr ?? ((line) => void process.stderr.write(`${line}\n`));
+    const baseEnv = deps.env ?? process.env;
+    const profile = await (deps.loadCredentials ?? (async () => {
+        const active = await readActiveProfile();
+        const creds = credentialsFromProfile(active);
+        return {
+            name: active.name,
+            baseUrl: creds?.baseUrl ?? active.baseUrl,
+            ...(creds?.token ? { token: creds.token } : {}),
+            ...(creds?.expiresAt ? { expiresAt: creds.expiresAt } : {}),
+            ...(creds?.workspaceId ? { workspaceId: creds.workspaceId } : {}),
+        };
+    }))();
+    // A mission sandbox has no profile on disk: it is handed a run-scoped
+    // capability token in the environment instead (the same `YAGNI_TOKEN` /
+    // `YAGNI_BASE_URL` pair every stage child already runs with). Fall back to it
+    // ONLY when nothing is logged in, so an exported token can never quietly
+    // hijack a developer's active profile.
+    const envToken = baseEnv.YAGNI_TOKEN?.trim();
+    const envBaseUrl = baseEnv.YAGNI_BASE_URL?.trim();
+    const token = profile.token ?? (envToken || undefined);
+    const baseUrl = profile.token ? profile.baseUrl : (envBaseUrl || profile.baseUrl);
+    if (!token) {
+        writeErr(`Not logged in to environment "${profile.name}" (${profile.baseUrl}). Run \`yagni login\` first.`);
+        return GO_EXIT.usage;
+    }
+    const childEnv = buildHeadlessChildEnv({
+        baseEnv,
+        token,
+        baseUrl,
+        profileName: profile.name,
+        ...(profile.expiresAt ? { expiresAt: profile.expiresAt } : {}),
+        ...(profile.workspaceId ? { workspaceId: profile.workspaceId } : {}),
+        ...(cliVersion ? { cliVersion } : {}),
+    });
+    // The hermetic agent dir must exist before a stage child tries to read it.
+    try {
+        mkdirSync(childEnv[agentDirEnvVar()], { recursive: true, mode: 0o700 });
+    }
+    catch {
+        /* best-effort: pi creates it too, and a failure here is not worth stopping for */
+    }
+    // The pipeline spawns each stage as `node <piCli> -e <extension> …`, resolving
+    // piCli from `process.argv[1]` (in a session that IS pi). Headlessly the entry
+    // process is this launcher, so point the resolver at pi's own CLI entry.
+    try {
+        process.argv[1] = (deps.piCliPath ?? resolvePiCliPath)();
+    }
+    catch (err) {
+        writeErr(`Could not locate the agent binary: ${err instanceof Error ? err.message : String(err)}`);
+        return GO_EXIT.usage;
+    }
+    let headless;
+    try {
+        headless = await (deps.loadHeadless ?? defaultLoadHeadless)();
+    }
+    catch (err) {
+        writeErr(err instanceof Error ? err.message : String(err));
+        return GO_EXIT.usage;
+    }
+    const outcome = await headless.runHeadlessGo(args, {
+        cwd: deps.cwd ?? process.cwd(),
+        env: baseEnv,
+        childEnv,
+    });
+    return outcome.exitCode;
+}
+//# sourceMappingURL=goHeadless.js.map

package/dist/paths.d.ts

@@ -20,6 +20,15 @@
  * and a fresh checkout working before anything is bundled.
  */
 export declare function resolveExtensionPath(): string;
+/**
+ * Absolute path to the extension's headless pipeline entry
+ * (`pipeline/headlessGo.js`), the module `yagni go --headless` imports.
+ *
+ * Derived from the extension entry so the bundled-vs-workspace fallback above
+ * is resolved once. Only this one module is loaded (not the whole extension):
+ * it pulls in the pipeline alone, with none of pi's TUI surface.
+ */
+export declare function resolveHeadlessGoPath(): string;
 /**
  * Absolute path to pi's package root — the dir whose package.json names the
  * package. The shadow package dir is built from this (we read its package.json

package/dist/paths.js

@@ -31,6 +31,18 @@ export function resolveExtensionPath() {
         return bundled;
     return resolveModulePath("pi-extension-yagni");
 }
+/**
+ * Absolute path to the extension's headless pipeline entry
+ * (`pipeline/headlessGo.js`), the module `yagni go --headless` imports.
+ *
+ * Derived from the extension entry so the bundled-vs-workspace fallback above
+ * is resolved once. Only this one module is loaded (not the whole extension):
+ * it pulls in the pipeline alone, with none of pi's TUI surface.
+ */
+export function resolveHeadlessGoPath() {
+    const entry = resolveExtensionPath();
+    return join(dirname(entry), "pipeline", "headlessGo.js");
+}
 /**
  * Absolute path to pi's package root — the dir whose package.json names the
  * package. The shadow package dir is built from this (we read its package.json

package/dist/promptEnrichment.d.ts

@@ -36,5 +36,5 @@ export declare function promptEnrichmentDisabled(env: NodeJS.ProcessEnv): boolea
  * model, and the load-bearing instructions (ask_yagni contract, delegation)
  * live elsewhere in the prompt.
  */
-export declare const ENGINEERING_PRACTICE_SECTION = "Engineering practice:\n\nBias to action: when the user asks you to implement, fix, or change something, use your tools to make the actual edits and run the actual commands \u2014 do not answer with a description of what you would do, or with code for the user to apply themselves. When the user asks HOW to approach something, answer the question first; do not jump into making changes they have not asked for.\n\nConventions:\n- Never assume a library is available, however well known. Before using one, confirm the project already depends on it (its package manifest, or imports in neighboring files).\n- When editing, read the surrounding code and its imports first; match the file's existing style, naming, and patterns rather than introducing your own.\n- When creating a new file or component, study an existing sibling first and follow its structure.\n- Never write code that logs or exposes secrets, keys, or credentials.\n\nVerification:\n- Consider what the code you are changing is supposed to do (from its name, location, and callers) before you change it.\n- Verify changes with the project's own tests when possible. Never assume a test framework or command \u2014 check the README, package scripts, or neighboring tests for the real one.\n- After completing a task, run the project's lint and typecheck commands if you know them; if you cannot find them, ask the user and suggest recording them in AGENTS.md for next time.\n\nVersion control:\n- No unsolicited commits: commit only when the user asked for one or the task at hand clearly calls for it.\n\nGit safety:\n- You may be in a dirty git worktree. Never revert existing changes you did not make unless explicitly asked \u2014 these were made by the user.\n- If there are unrelated changes in files you are touching, read and work with them rather than reverting.\n- If changes appear in unrelated files, ignore them and do not revert.\n- Do not amend a commit unless explicitly asked.\n- If you notice unexpected changes you did not make while working, stop immediately and ask the user.\n- Never use destructive git commands (git reset --hard, git checkout --) unless the user explicitly requests or approves them.\n\nTodo discipline:\n- Track multi-step work with todo_write: keep exactly one item in_progress at a time, mark items completed the moment they are done, and add newly discovered steps as pending.\n- Do not batch-complete items or create single-step plans. Skip planning for trivially small work (~25% of tasks).\n\nMode awareness:\n- In auto mode, proactively run tests, lint, and typecheck after your changes.\n- In review mode, propose verification steps but wait for approval before running them.\n- In plan mode, explore and design only \u2014 the gate holds all writes.\n\nCommunication:\n- Answer directly, without preamble or postamble (\"Here is what I will do next...\", \"Based on the information provided...\"). Match the length of your answer to the question.\n- After making edits, report the outcome briefly; do not restate the diff or explain the code you just wrote unless asked.\n- Do not add code comments that narrate what you changed or why the change is correct; comments are for future readers of the code.\n- Reference code as file_path:line_number so the user can jump to it.\n- Before running a non-trivial command that changes state, say in one line what it does and why.\n- Never guess or fabricate URLs. Only use URLs the user provided or that appear in local files.\n- No emojis unless the user asks for them.";
+export declare const ENGINEERING_PRACTICE_SECTION = "Engineering practice:\n\nAnswering vs acting: distinguish what the user is asking for before responding. When the user asks you to analyze, investigate, find a root cause, study how something works, explore an approach, or asks a strategic or advisory question (\"should we...\", \"what's your read on...\", \"go/no-go on...\"), answer in prose \u2014 do not start coding or editing files. When the user asks you to implement, fix, or change something, use your tools to make the actual edits and run the actual commands \u2014 do not answer with a description of what you would do, or with code for the user to apply themselves.\n\nConventions:\n- Never assume a library is available, however well known. Before using one, confirm the project already depends on it (its package manifest, or imports in neighboring files).\n- When editing, read the surrounding code and its imports first; match the file's existing style, naming, and patterns rather than introducing your own.\n- When creating a new file or component, study an existing sibling first and follow its structure.\n- Never write code that logs or exposes secrets, keys, or credentials.\n\nVerification:\n- Consider what the code you are changing is supposed to do (from its name, location, and callers) before you change it.\n- Verify changes with the project's own tests when possible. Never assume a test framework or command \u2014 check the README, package scripts, or neighboring tests for the real one.\n- After completing a task, run the project's lint and typecheck commands if you know them; if you cannot find them, ask the user and suggest recording them in AGENTS.md for next time.\n\nVersion control:\n- No unsolicited commits: commit only when the user asked for one or the task at hand clearly calls for it.\n\nGit safety:\n- You may be in a dirty git worktree. Never revert existing changes you did not make unless explicitly asked \u2014 these were made by the user.\n- If there are unrelated changes in files you are touching, read and work with them rather than reverting.\n- If changes appear in unrelated files, ignore them and do not revert.\n- Do not amend a commit unless explicitly asked.\n- If you notice unexpected changes you did not make while working, stop immediately and ask the user.\n- Never use destructive git commands (git reset --hard, git checkout --) unless the user explicitly requests or approves them.\n\nTodo discipline:\n- Track multi-step work with todo_write: keep exactly one item in_progress at a time, mark items completed the moment they are done, and add newly discovered steps as pending.\n- Do not batch-complete items or create single-step plans. Skip planning for trivially small work (~25% of tasks).\n\nMode awareness:\n- In auto mode, proactively run tests, lint, and typecheck after your changes.\n- In review mode, propose verification steps but wait for approval before running them.\n- In plan mode, explore and design only \u2014 the gate holds all writes.\n\nCommunication:\n- Answer directly, without preamble or postamble (\"Here is what I will do next...\", \"Based on the information provided...\"). Match the length of your answer to the question.\n- After making edits, report the outcome briefly; do not restate the diff or explain the code you just wrote unless asked.\n- Do not add code comments that narrate what you changed or why the change is correct; comments are for future readers of the code.\n- Reference code as file_path:line_number so the user can jump to it.\n- Before running a non-trivial command that changes state, say in one line what it does and why.\n- Never guess or fabricate URLs. Only use URLs the user provided or that appear in local files.\n- No emojis unless the user asks for them.";
 //# sourceMappingURL=promptEnrichment.d.ts.map

package/dist/promptEnrichment.js

@@ -41,7 +41,7 @@ export function promptEnrichmentDisabled(env) {
  */
 export const ENGINEERING_PRACTICE_SECTION = `Engineering practice:
 
-Bias to action: when the user asks you to implement, fix, or change something, use your tools to make the actual edits and run the actual commands — do not answer with a description of what you would do, or with code for the user to apply themselves. When the user asks HOW to approach something, answer the question first; do not jump into making changes they have not asked for.
+Answering vs acting: distinguish what the user is asking for before responding. When the user asks you to analyze, investigate, find a root cause, study how something works, explore an approach, or asks a strategic or advisory question ("should we...", "what's your read on...", "go/no-go on..."), answer in prose — do not start coding or editing files. When the user asks you to implement, fix, or change something, use your tools to make the actual edits and run the actual commands — do not answer with a description of what you would do, or with code for the user to apply themselves.
 
 Conventions:
 - Never assume a library is available, however well known. Before using one, confirm the project already depends on it (its package manifest, or imports in neighboring files).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yagni-app/code",
-  "version": "0.3.1",
+  "version": "0.3.3",
   "description": "YAGNI Code: a terminal coding agent that already knows your company. One YAGNI login routes the model and grounds the agent in your team's context.",
   "license": "SEE LICENSE IN LICENSE.md",
   "author": "YAGNI, Inc. <jack@yagni.app> (https://yagni.app)",
@@ -39,5 +39,5 @@
     "smol-toml": "^1.8.0",
     "typebox": "^1.3.11"
   },
-  "yagniSourceSha": "27482c0e8f72e0f171de23bd39e774d9661c0bc6"
+  "yagniSourceSha": "36ebf50cf01b962741558ccbf04485ef2231d1e1"
 }