@yagni-app/code-staging 0.0.0 → 0.1.0-staging.1002.1

package/LICENSE.md

@@ -0,0 +1,55 @@
+# YAGNI Code License
+
+Copyright (c) 2026 YAGNI, Inc. (https://yagni.app). All rights reserved.
+
+This software is a proprietary client for the YAGNI service. It is licensed to
+you, not sold. Installing it from a public package registry does not make it
+open source and grants no rights beyond this license.
+
+## License grant
+
+Subject to this license and the YAGNI Terms of Service, YAGNI, Inc. ("YAGNI")
+grants you a limited, revocable, non-exclusive, non-transferable license to
+install and run this software, in unmodified form, solely to access and use
+the YAGNI service under an active YAGNI account or workspace.
+
+## Restrictions
+
+You may not:
+
+- copy, modify, adapt, or create derivative works of the software;
+- distribute, sublicense, rent, lease, sell, or otherwise transfer the
+  software or access to it;
+- reverse engineer, decompile, or disassemble the software, except to the
+  extent applicable law does not allow that restriction;
+- remove or alter any copyright, trademark, or other proprietary notices; or
+- use the software to build a product or service that competes with the YAGNI
+  service.
+
+## Ownership
+
+The software and all intellectual property rights in it remain the exclusive
+property of YAGNI and its licensors. Third-party packages installed alongside
+this one are licensed under their own terms.
+
+## Termination
+
+This license ends automatically if you breach it or when your access to the
+YAGNI service ends. When it ends, you must stop using the software and
+uninstall it.
+
+## Disclaimer of warranty
+
+THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING WITHOUT LIMITATION THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT.
+
+## Limitation of liability
+
+TO THE MAXIMUM EXTENT PERMITTED BY LAW, YAGNI WILL NOT BE LIABLE FOR ANY
+INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING
+FROM OR RELATED TO THE SOFTWARE, AND YAGNI'S TOTAL LIABILITY WILL NOT EXCEED
+THE AMOUNTS YOU PAID FOR THE YAGNI SERVICE IN THE TWELVE MONTHS BEFORE THE
+CLAIM AROSE.
+
+Questions about this license: jack@yagni.app.

package/README.md

@@ -0,0 +1,166 @@
+# YAGNI Code
+
+A terminal coding agent that already knows your company.
+
+YAGNI Code is a coding agent for your terminal, like Claude Code or Codex — but
+it is wired into the YAGNI app, your team's shared source of truth for how your
+company and codebase actually work. One YAGNI login routes everything:
+
+- the **model** runs on YAGNI-routed open-weight inference (you bring no API
+  keys), and
+- the agent **boots already grounded** in your company — conventions,
+  decisions, ownership, priorities, the "why" — and can consult it mid-task with
+  a built-in `ask_yagni` tool.
+
+**The bet:** a cheaper open-weight model that is *grounded in your context*
+beats a stronger model that is *guessing* on your own codebase. Because YAGNI
+Code and the YAGNI app are connected, you intervene less and the agent does more
+correct, autonomous work than a coding agent that starts blank.
+
+## Install
+
+```bash
+npm install -g @yagni-app/code
+```
+
+The command it installs is `yagni`:
+
+```bash
+yagni login     # device-code auth against your YAGNI workspace
+yagni doctor    # green/red readiness checklist
+yagni           # launch the agent in the current repo
+```
+
+Your workspace must have YAGNI Code enabled (the `yagni_code.enabled` feature
+flag) — ask your workspace admin. Maintainers: the alpha checklist is
+`docs/yagni-code-alpha.md`; publish-day steps live in
+`docs/yagni-code-publishing.md`.
+
+## Develop
+
+Working in this monorepo, install from the repo instead of the registry. Build
+the extension first — the CLI's build copies `pi-extension-yagni`'s `dist/` into
+its own `dist/extension/`, and fails loudly if the extension is not built — then
+build and link the CLI:
+
+```bash
+pnpm --filter pi-extension-yagni build
+pnpm --filter @yagni-app/code build
+npm i -g ./packages/yagni-code-cli      # or `pnpm --filter @yagni-app/code link --global`
+```
+
+Both packages are plain `tsc` builds that emit to `dist/`. The global
+`yagni` command is a symlink into this repo's `dist/`, so after the initial
+`npm i -g` you **never reinstall** — a rebuild is enough, and the next launch
+picks it up.
+
+Iterate with watch mode (one terminal each — run the commands bare, an inline
+`#` comment is passed through as a filename by zsh and breaks `tsc`):
+
+```bash
+pnpm --filter pi-extension-yagni dev
+pnpm --filter @yagni-app/code dev
+```
+
+Notes:
+
+- **Order matters when changing both.** The CLI bundles the extension, so build
+  (or have a watcher running) `pi-extension-yagni` before `@yagni-app/code`.
+- **Watch mode does not re-bundle.** The copy into `dist/extension/` happens on
+  `build`, not on `tsc --watch`, and the launcher prefers that copy. After an
+  extension change, run `pnpm --filter @yagni-app/code bundle` (cheap, copy
+  only) or a full `build`, or you will keep running the previous extension.
+- **`yagni` is long-lived.** A rebuild only takes effect the next time you
+  launch it — restart the CLI to pick up new code.
+- **Frontend/backend changes** (e.g. the `/v1` dev proxy) are served by
+  `pnpm dev` — Vite restarts on `vite.config.ts` changes and the backend runs
+  under `tsx` watch, so no manual rebuild there.
+- **Tests:** `pnpm --filter @yagni-app/code test` (`node:test` via `tsx`).
+
+## Use
+
+```bash
+yagni login          # device-code flow: open the URL, enter the code, approve
+yagni doctor         # green/red readiness checklist (engine, token, backend, perms)
+cd ~/code/my-repo
+yagni                # launch the agent in this repo (interactive)
+yagni -p "explain the deploy pipeline; ask_yagni if unsure"   # one-shot / print mode
+yagni logout         # revoke the token and clear it locally
+```
+
+The agent runs on three opaque model tiers routed by YAGNI: `advanced` (the strongest,
+for judgment), `standard` (for execution) and `efficient` (cheapest).
+Interactive sessions default to `advanced`; pass `--model standard` or `--model
+efficient` to switch a run. The `/go` pipeline routes its own steps automatically —
+judgment steps (plan, review) on `advanced`, execution steps (map, implement, fix) on
+`standard`.
+
+`login` opens a device-code flow: it prints a short code and a URL. Open the URL
+in a browser where you are signed in to YAGNI, enter the code, and approve. The
+token is stored in the active environment's profile (`~/.yagni-code/profiles/<name>.json`,
+mode `0600`). Re-run `login` any time to refresh it. See **Environments** below to
+point the CLI at a non-prod backend.
+
+Any arguments after `yagni` are passed straight through to the agent, so
+flags like `--model` and `--print/-p` work.
+
+### What "knows your company" means in practice
+
+- On startup, YAGNI Code loads a brief of your workspace (vision, goals,
+  conventions) and works from it immediately — no prompting required.
+- When a choice depends on something organization- or codebase-specific, the
+  agent calls **`ask_yagni`** and gets a cited answer from the YAGNI app instead
+  of guessing.
+
+## Environments (profiles)
+
+YAGNI Code keeps a **sticky active environment**. Each environment ("profile") binds a
+base URL to its own stored token, so you can point the CLI at prod, a local backend, or
+a staging host and switch between them without re-authenticating each time.
+
+```bash
+yagni use local                          # switch to the local dev backend (preset)
+yagni login                              # authorize the active environment
+yagni                                    # runs against `local` from now on (sticky)
+
+yagni use staging --base-url https://staging.example.com   # define a custom env
+yagni login
+yagni profiles                           # list environments; the active one is *-marked
+yagni use prod                           # switch back (sticky); prod is the default
+```
+
+- `prod` (→ `https://yagni.app`) is the default environment and a built-in preset.
+- `local` (→ `http://localhost:3456`, the `pnpm dev` backend) is the other preset.
+- Any other name needs `--base-url <url>` the first time you `use` it.
+- Each environment gets its own isolated pi state under `~/.yagni-code/agent/<name>`,
+  so prod sessions never bleed into staging.
+- `login` / `logout` always act on the **active** environment. `logout` clears its token
+  but keeps the binding, so a later `login` re-authorizes the same environment.
+
+## Configuration
+
+| Variable         | Default                  | Purpose                                            |
+| ---------------- | ------------------------ | -------------------------------------------------- |
+| `YAGNI_BASE_URL` | active environment's URL | Override the base URL for a **single run** (escape hatch). Prefer `yagni use` for anything sticky. |
+
+Credentials live in `~/.yagni-code/profiles/<name>.json` (mode `0600`); the active
+environment is recorded in `~/.yagni-code/config.json`. A pre-profiles
+`~/.yagni-code/credentials.json` is migrated automatically on first run.
+
+## Troubleshooting
+
+- **`Not logged in to environment "<name>" … Run \`yagni login\` first.`** — no
+  valid token for the active environment; run `yagni login` (or `yagni use`
+  a different one). Run `yagni doctor` for a full green/red readiness check.
+- **`Could not start login … Is YAGNI Code enabled for your workspace?`** —
+  YAGNI Code is not enabled for your workspace. Ask an admin to enable it.
+- **The login code expired** — approval wasn't completed in time; run
+  `yagni login` again.
+- **Talking to staging** — `yagni use staging --base-url https://<staging-host>`,
+  then `yagni login`.
+
+---
+
+Maintainers: YAGNI Code is built on the open-source `pi` coding agent, configured
+entirely through a first-party extension (no fork). The engineering details live
+in [`ARCHITECTURE.md`](./ARCHITECTURE.md).

package/dist/branding.d.ts

@@ -0,0 +1,25 @@
+/**
+ * YAGNI Code launcher branding.
+ *
+ * pi derives its entire app identity — terminal title, `process.title`, and the
+ * name of the env var it reads for its config dir — from `piConfig.name` in the
+ * package.json it loads from `PI_PACKAGE_DIR` (pi config.ts: `APP_NAME`,
+ * `APP_TITLE`, `ENV_AGENT_DIR`). We rebrand "pi"/"π" out of the chrome by
+ * pointing pi at a shadow package whose `piConfig.name` is set to this value.
+ *
+ * Because the SAME name drives `ENV_AGENT_DIR = `${APP_NAME.toUpperCase()}` +
+ * "_CODING_AGENT_DIR"`, this module is the single source of truth: the shadow
+ * package.json and the launcher's hermetic-dir env wiring must agree on the
+ * name, or pi reads a different env var than the launcher sets and silently
+ * falls back to `~/.pi/agent` — breaking the hermetic boundary that keeps the
+ * user's local provider keys from bypassing the YAGNI proxy.
+ */
+/** The app name pi will compute as `APP_NAME` (shown in the terminal title/tab). */
+export declare const PI_CONFIG_NAME = "YAGNI";
+/**
+ * The env var name pi reads for its config dir, derived exactly as pi does
+ * (`${APP_NAME.toUpperCase()}_CODING_AGENT_DIR`). For the default name this is
+ * `"YAGNI_CODING_AGENT_DIR"`.
+ */
+export declare function agentDirEnvVar(name?: string): string;
+//# sourceMappingURL=branding.d.ts.map

package/dist/branding.js

@@ -0,0 +1,27 @@
+/**
+ * YAGNI Code launcher branding.
+ *
+ * pi derives its entire app identity — terminal title, `process.title`, and the
+ * name of the env var it reads for its config dir — from `piConfig.name` in the
+ * package.json it loads from `PI_PACKAGE_DIR` (pi config.ts: `APP_NAME`,
+ * `APP_TITLE`, `ENV_AGENT_DIR`). We rebrand "pi"/"π" out of the chrome by
+ * pointing pi at a shadow package whose `piConfig.name` is set to this value.
+ *
+ * Because the SAME name drives `ENV_AGENT_DIR = `${APP_NAME.toUpperCase()}` +
+ * "_CODING_AGENT_DIR"`, this module is the single source of truth: the shadow
+ * package.json and the launcher's hermetic-dir env wiring must agree on the
+ * name, or pi reads a different env var than the launcher sets and silently
+ * falls back to `~/.pi/agent` — breaking the hermetic boundary that keeps the
+ * user's local provider keys from bypassing the YAGNI proxy.
+ */
+/** The app name pi will compute as `APP_NAME` (shown in the terminal title/tab). */
+export const PI_CONFIG_NAME = "YAGNI";
+/**
+ * The env var name pi reads for its config dir, derived exactly as pi does
+ * (`${APP_NAME.toUpperCase()}_CODING_AGENT_DIR`). For the default name this is
+ * `"YAGNI_CODING_AGENT_DIR"`.
+ */
+export function agentDirEnvVar(name = PI_CONFIG_NAME) {
+    return `${name.toUpperCase()}_CODING_AGENT_DIR`;
+}
+//# sourceMappingURL=branding.js.map

package/dist/claudeCompat.d.ts

@@ -0,0 +1,78 @@
+/**
+ * Zero-config Claude Code repo compat.
+ *
+ * A repo that already carries Claude Code assets keeps working under YAGNI
+ * Code with nothing to edit: `.claude/skills` loads through pi's skill
+ * discovery and `.claude/commands/*.md` through pi's prompt templates (the
+ * same markdown-with-frontmatter format Claude Code uses — filename becomes
+ * the `/name` command). The launcher passes both as per-run `--skill` /
+ * `--prompt-template` flags, so nothing repo-local is ever written and no
+ * per-profile settings file accumulates stale per-repo paths.
+ *
+ * Trust: pi gates project-local resources behind a per-folder trust decision
+ * stored in `<agentDir>/trust.json`. Explicit CLI paths bypass that gate, so
+ * the launcher enforces the SAME decision itself: project `.claude` dirs are
+ * wired only when the folder is trusted. With no recorded decision it asks
+ * once (interactive runs only) and persists the answer into pi's own
+ * trust.json — one trust model, shared with pi's prompt, and a "no" is
+ * remembered too. User-scope `~/.claude` dirs are the user's own machine and
+ * load without ceremony, matching how pi treats `~/.agents/skills`.
+ *
+ * Set YAGNI_DISABLE_CLAUDE_COMPAT=1 to turn the whole bridge off.
+ */
+export declare const CLAUDE_COMPAT_DISABLE_ENV = "YAGNI_DISABLE_CLAUDE_COMPAT";
+export interface ClaudeAssetDirs {
+    skills: string | null;
+    commands: string | null;
+}
+export interface ClaudeCompatProbe {
+    project: ClaudeAssetDirs;
+    user: ClaudeAssetDirs;
+    /** Nearest recorded trust decision for the cwd (pi trust.json), if any. */
+    projectTrust: boolean | null;
+    interactive: boolean;
+}
+export interface ClaudeCompatDecision {
+    /** Flags for user-scope dirs; always safe to pass. */
+    userArgv: string[];
+    /** Flags for project dirs; pass only once trust is established. */
+    projectArgv: string[];
+    /** Ask the user for a trust decision before wiring projectArgv. */
+    needsPrompt: boolean;
+}
+/** Pure policy: what to wire, and whether a trust prompt is required first. */
+export declare function decideClaudeCompat(probe: ClaudeCompatProbe): ClaudeCompatDecision;
+/** The `.claude` asset dirs under `root` that actually exist. */
+export declare function probeClaudeDirs(root: string): ClaudeAssetDirs;
+/**
+ * The nearest recorded decision for `cwd` or an ancestor, else null. Read-only
+ * and fail-soft: a missing or corrupt trust file just means "not decided".
+ */
+export declare function readTrustDecision(agentDir: string, cwd: string): boolean | null;
+/**
+ * Persist a decision into pi's trust.json, holding pi's mkdir-based lock
+ * (`trust.json.lock`) so a concurrently-running session can't lose a write.
+ * Fail-soft: if the lock never frees, skip the write — worst case the user is
+ * asked again next launch.
+ */
+export declare function writeTrustDecision(agentDir: string, cwd: string, decision: boolean): void;
+export interface ClaudeCompatDeps {
+    cwd: string;
+    /** The hermetic pi agent dir for the active profile (holds trust.json). */
+    agentDir: string;
+    homeDir?: string;
+    env?: NodeJS.ProcessEnv;
+    interactive?: boolean;
+    /** The one-time trust question; injectable for tests. */
+    confirm?: (question: string) => Promise<boolean>;
+}
+export declare function compatDisabled(env: NodeJS.ProcessEnv): boolean;
+/**
+ * The extra pi argv for this launch: user-scope dirs plus project dirs once
+ * trusted, asking (and persisting) the trust decision when needed. Everything
+ * is fail-soft — compat can only add flags, never break a launch.
+ */
+export declare function claudeCompatArgs(deps: ClaudeCompatDeps): Promise<string[]>;
+/** Whether pi's trust file exists yet (used only for messaging). */
+export declare function trustFileExists(agentDir: string): boolean;
+//# sourceMappingURL=claudeCompat.d.ts.map

package/dist/claudeCompat.js

@@ -0,0 +1,198 @@
+/**
+ * Zero-config Claude Code repo compat.
+ *
+ * A repo that already carries Claude Code assets keeps working under YAGNI
+ * Code with nothing to edit: `.claude/skills` loads through pi's skill
+ * discovery and `.claude/commands/*.md` through pi's prompt templates (the
+ * same markdown-with-frontmatter format Claude Code uses — filename becomes
+ * the `/name` command). The launcher passes both as per-run `--skill` /
+ * `--prompt-template` flags, so nothing repo-local is ever written and no
+ * per-profile settings file accumulates stale per-repo paths.
+ *
+ * Trust: pi gates project-local resources behind a per-folder trust decision
+ * stored in `<agentDir>/trust.json`. Explicit CLI paths bypass that gate, so
+ * the launcher enforces the SAME decision itself: project `.claude` dirs are
+ * wired only when the folder is trusted. With no recorded decision it asks
+ * once (interactive runs only) and persists the answer into pi's own
+ * trust.json — one trust model, shared with pi's prompt, and a "no" is
+ * remembered too. User-scope `~/.claude` dirs are the user's own machine and
+ * load without ceremony, matching how pi treats `~/.agents/skills`.
+ *
+ * Set YAGNI_DISABLE_CLAUDE_COMPAT=1 to turn the whole bridge off.
+ */
+import { existsSync, mkdirSync, readFileSync, realpathSync, renameSync, rmdirSync, statSync, writeFileSync } from "node:fs";
+import { homedir } from "node:os";
+import { dirname, join, resolve } from "node:path";
+export const CLAUDE_COMPAT_DISABLE_ENV = "YAGNI_DISABLE_CLAUDE_COMPAT";
+function dirsToArgv(dirs) {
+    const argv = [];
+    if (dirs.skills)
+        argv.push("--skill", dirs.skills);
+    if (dirs.commands)
+        argv.push("--prompt-template", dirs.commands);
+    return argv;
+}
+/** Pure policy: what to wire, and whether a trust prompt is required first. */
+export function decideClaudeCompat(probe) {
+    const projectArgv = dirsToArgv(probe.project);
+    return {
+        userArgv: dirsToArgv(probe.user),
+        projectArgv,
+        needsPrompt: probe.interactive && projectArgv.length > 0 && probe.projectTrust === null,
+    };
+}
+function isDirectory(path) {
+    try {
+        return statSync(path).isDirectory();
+    }
+    catch {
+        return false;
+    }
+}
+/** The `.claude` asset dirs under `root` that actually exist. */
+export function probeClaudeDirs(root) {
+    const skills = join(root, ".claude", "skills");
+    const commands = join(root, ".claude", "commands");
+    return {
+        skills: isDirectory(skills) ? skills : null,
+        commands: isDirectory(commands) ? commands : null,
+    };
+}
+// ── pi trust.json interop ───────────────────────────────────────────────────
+/** Match pi's normalization closely enough for key lookups: resolve + realpath. */
+function normalizeCwd(path) {
+    const resolved = resolve(path);
+    try {
+        return realpathSync(resolved);
+    }
+    catch {
+        return resolved;
+    }
+}
+function trustPath(agentDir) {
+    return join(agentDir, "trust.json");
+}
+function readTrustFile(path) {
+    try {
+        const parsed = JSON.parse(readFileSync(path, "utf8"));
+        if (!parsed || typeof parsed !== "object" || Array.isArray(parsed))
+            return {};
+        const data = {};
+        for (const [key, value] of Object.entries(parsed)) {
+            if (value === true || value === false || value === null)
+                data[key] = value;
+        }
+        return data;
+    }
+    catch {
+        return {};
+    }
+}
+/**
+ * The nearest recorded decision for `cwd` or an ancestor, else null. Read-only
+ * and fail-soft: a missing or corrupt trust file just means "not decided".
+ */
+export function readTrustDecision(agentDir, cwd) {
+    const data = readTrustFile(trustPath(agentDir));
+    let current = normalizeCwd(cwd);
+    while (true) {
+        const decision = data[current];
+        if (decision === true || decision === false)
+            return decision;
+        const parent = dirname(current);
+        if (parent === current)
+            return null;
+        current = parent;
+    }
+}
+/**
+ * Persist a decision into pi's trust.json, holding pi's mkdir-based lock
+ * (`trust.json.lock`) so a concurrently-running session can't lose a write.
+ * Fail-soft: if the lock never frees, skip the write — worst case the user is
+ * asked again next launch.
+ */
+export function writeTrustDecision(agentDir, cwd, decision) {
+    const path = trustPath(agentDir);
+    const lock = `${path}.lock`;
+    mkdirSync(agentDir, { recursive: true });
+    let locked = false;
+    for (let attempt = 0; attempt < 10; attempt++) {
+        try {
+            mkdirSync(lock);
+            locked = true;
+            break;
+        }
+        catch {
+            const start = Date.now();
+            while (Date.now() - start < 20) {
+                // Brief synchronous wait between lock attempts.
+            }
+        }
+    }
+    if (!locked)
+        return;
+    try {
+        const data = readTrustFile(path);
+        data[normalizeCwd(cwd)] = decision;
+        const sorted = {};
+        for (const key of Object.keys(data).sort())
+            sorted[key] = data[key];
+        const tmp = `${path}.tmp`;
+        writeFileSync(tmp, `${JSON.stringify(sorted, null, 2)}\n`, "utf8");
+        renameSync(tmp, path);
+    }
+    catch {
+        // Fail-soft: an unwritable trust file only costs a repeat prompt.
+    }
+    finally {
+        try {
+            rmdirSync(lock);
+        }
+        catch {
+            // Already gone.
+        }
+    }
+}
+export function compatDisabled(env) {
+    const value = env[CLAUDE_COMPAT_DISABLE_ENV];
+    return value !== undefined && value !== "" && value !== "0";
+}
+/**
+ * The extra pi argv for this launch: user-scope dirs plus project dirs once
+ * trusted, asking (and persisting) the trust decision when needed. Everything
+ * is fail-soft — compat can only add flags, never break a launch.
+ */
+export async function claudeCompatArgs(deps) {
+    const env = deps.env ?? process.env;
+    if (compatDisabled(env))
+        return [];
+    const home = deps.homeDir ?? homedir();
+    const projectTrust = readTrustDecision(deps.agentDir, deps.cwd);
+    const decision = decideClaudeCompat({
+        project: probeClaudeDirs(deps.cwd),
+        user: probeClaudeDirs(home),
+        projectTrust,
+        interactive: deps.interactive ?? (process.stdin.isTTY === true && process.stdout.isTTY === true),
+    });
+    const argv = [...decision.userArgv];
+    if (decision.projectArgv.length > 0) {
+        let trusted = projectTrust;
+        if (decision.needsPrompt && deps.confirm) {
+            try {
+                trusted = await deps.confirm("This folder has Claude Code assets (.claude/skills, .claude/commands). Trust this folder and load them?");
+                writeTrustDecision(deps.agentDir, deps.cwd, trusted);
+            }
+            catch {
+                trusted = null;
+            }
+        }
+        if (trusted === true)
+            argv.push(...decision.projectArgv);
+    }
+    return argv;
+}
+/** Whether pi's trust file exists yet (used only for messaging). */
+export function trustFileExists(agentDir) {
+    return existsSync(trustPath(agentDir));
+}
+//# sourceMappingURL=claudeCompat.js.map

package/dist/cli.d.ts

@@ -0,0 +1,55 @@
+#!/usr/bin/env node
+/**
+ * yagni — the thin launcher (package `yagni-code`, command `yagni`).
+ *
+ *   yagni login        device-code auth, stores a scoped token
+ *   yagni logout       revoke + delete the local token
+ *   yagni doctor       green/red readiness checklist
+ *   yagni [pi args…]   launch pi configured with the yagni provider +
+ *                      the ask_yagni tool (default command)
+ *
+ * The launcher holds NO model or business logic — it is credential plumbing
+ * plus a configured pi spawn. Everything that makes this "YAGNI Code" lives in
+ * pi-extension-yagni and the YAGNI backend.
+ */
+export declare const HELP_TEXT: string;
+/** Parse `use <name> [--base-url <url>]` argv into its parts. */
+export declare function parseUseArgs(args: string[]): {
+    name?: string;
+    baseUrl?: string;
+};
+/** `yagni use <name> [--base-url <url>]` — switch the sticky environment. */
+export declare function useCommand(args: string[]): Promise<number>;
+/** `yagni profiles` — list saved environments, marking the active one. */
+export declare function profilesCommand(): Promise<number>;
+/**
+ * Whether to show YAGNI Code's own help instead of launching the agent.
+ *
+ * `--help`/`-h` are intercepted ANYWHERE in argv (not just position 0) so the
+ * underlying agent's branded help never leaks (e.g. `yagni <flag> --help`).
+ */
+export declare function wantsHelp(argv: string[]): boolean;
+/**
+ * Whether to print YAGNI Code's own version instead of launching the agent.
+ *
+ * `--version` AND `-v` are intercepted ANYWHERE in argv for the same reason as
+ * `--help`: pi parses both as its version flag, so letting either through
+ * leaks the agent's branded version line (or a login error before it).
+ */
+export declare function wantsVersion(argv: string[]): boolean;
+/** The CLI's own version (see `currentCliVersion` — upgrade.ts owns it). */
+export declare function cliVersion(): string;
+export declare function main(argv: string[]): Promise<number>;
+/**
+ * Whether this module is the process entrypoint (vs. imported by a test).
+ *
+ * Symlink-safe: when `yagni-code` is installed globally, the shell runs it
+ * through a symlink in the bin dir, so `process.argv[1]` is that symlink path.
+ * Node resolves symlinks for `import.meta.url`, so a raw `argv[1] === metaPath`
+ * compare is ALWAYS false for a symlinked install and `main()` never runs (the
+ * "nothing happens" bug). We realpath both sides so the symlinked bin and a
+ * direct `node dist/cli.js` invocation both count as the entrypoint, while a
+ * test import (argv[1] points at the test runner) does not.
+ */
+export declare function isEntrypoint(argv1: string | undefined, moduleUrl: string): boolean;
+//# sourceMappingURL=cli.d.ts.map