@yagni-app/code-staging 0.1.0-staging.1020.1 → 0.1.0-staging.1022.1

package/README.md

@@ -88,14 +88,16 @@ yagni -p "explain the deploy pipeline; ask_yagni if unsure"   # one-shot / print
 yagni logout         # revoke the token and clear it locally
 ```
 
-The agent runs on model tiers routed by YAGNI: `advanced`, `standard`, and
-`efficient` (cheapest) are the three selectable via `--model`; `peak`, the
-strongest tier, is reserved for the `/go` pipeline's own judgment steps and is
-not one of the three.
-Interactive sessions default to `balanced`, which drives on `advanced`; pass
-`--model standard` or `--model efficient` to switch a run. The `/go` pipeline
-routes its own steps automatically — judgment steps (plan, review) on `peak`,
-execution steps (map, implement, fix) on `standard`.
+The agent runs on five opaque model tiers routed by YAGNI: `balanced` (the
+interactive default), `peak` (the strongest, for hard judgment), `advanced`,
+`standard` (for execution) and `efficient` (cheapest). `balanced` is a strategy
+rather than a single rung: the session drives on the `advanced` tier and
+escalates a bounded number of hard judgment calls per session to `peak`, so the
+strongest model is consulted where being wrong is expensive instead of being
+paid for on every turn. Pass `--model peak`, `--model standard`, or `--model
+efficient` to pin a run to one tier. The `/go` pipeline routes its own steps
+automatically: judgment steps (plan, review) on `peak`, 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
@@ -114,6 +116,22 @@ flags like `--model` and `--print/-p` work.
   agent calls **`ask_yagni`** and gets a cited answer from the YAGNI app instead
   of guessing.
 
+### Works with your existing repo setup
+
+- A repo that already carries Claude Code assets keeps working with nothing to
+  edit: `.claude/skills` and `.claude/commands/*.md` load automatically (each
+  command becomes a `/name` slash command). Project-local assets load only
+  after a one-time per-folder trust prompt; set `YAGNI_DISABLE_CLAUDE_COMPAT=1`
+  to turn the bridge off.
+- `AGENTS.md` and `CLAUDE.md` context files load from the working directory and
+  its ancestors, unmodified.
+- MCP servers registered in your YAGNI workspace are available in-session: run
+  `/mcp` to list them. Calls are proxied through the YAGNI backend with your
+  own identity, so server credentials never reach the laptop and every call is
+  audited; mutating tools go through the same permission gate as file edits.
+  There is no local MCP config file: servers and credentials are managed in the
+  web app (Connections).
+
 ## Environments (profiles)
 
 YAGNI Code keeps a **sticky active environment**. Each environment ("profile") binds a
@@ -147,11 +165,37 @@ yagni use prod                           # switch back (sticky); prod is the def
 | `YAGNI_DISABLE_BRANDING`      | unset                    | `1` skips the YAGNI Code system-prompt rewrite entirely, so the engine's assembled prompt passes through byte-exact (no identity swap, no company-brief injection). |
 | `YAGNI_DISABLE_UPDATE_CHECK`  | unset                    | `1` silences the new-version notice and the background update check. |
 | `YAGNI_DISABLE_CLAUDE_COMPAT` | unset                    | `1` turns off the zero-config `.claude` assets bridge (skills and commands). |
+| `YAGNI_DISABLE_CRASH_REPORTS` | unset                    | `1` disables crash reporting (see "What leaves your machine"). |
 
 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.
 
+Device tokens are revocable from both ends: `yagni logout` revokes the current
+one, and a workspace admin can list every connected device and revoke any token
+from the web app (Settings, YAGNI Code, Connected devices). Tokens are stored
+hashed on the server and a revoked token stops validating immediately.
+
+### What leaves your machine
+
+Everything the agent needs (model calls, grounding lookups, MCP calls, usage
+metering) goes to your YAGNI backend over the authenticated session. No
+third-party analytics or telemetry SDK runs on your laptop, and the underlying
+engine's own telemetry and version pings are disabled at launch. Two outbound
+flows exist beyond your YAGNI backend and your own repo tooling, disclosed
+precisely:
+
+- **Update check.** In the background after launch, the CLI asks the npm
+  registry (or your configured private registry mirror) whether a newer
+  version of this package exists, so the next launch can show a one-line
+  nudge. Package metadata only; no code or workspace data. Disable with
+  `YAGNI_DISABLE_UPDATE_CHECK=1`.
+- **Crash reports.** When the client itself crashes, a sanitized crash report
+  (error class, scrubbed message and stack trace; secrets and env values
+  redacted, paths reduced) is sent to your YAGNI backend, not to any
+  third-party crash service, so we can fix the crash before you have to report
+  it. Disable with `YAGNI_DISABLE_CRASH_REPORTS=1`.
+
 ## Troubleshooting
 
 - **`Not logged in to environment "<name>" … Run \`yagni login\` first.`** — no

package/dist/login.d.ts

@@ -9,6 +9,13 @@ export interface LoginDeps {
     baseUrl?: string;
     /** Which profile to store the minted token in. Defaults to the active one. */
     profileName?: string;
+    /**
+     * Client identifier sent with the token poll so the backend can attribute
+     * the minted credential to the app that requested it. Defaults to "cli";
+     * the desktop shell (which reuses this flow) passes "desktop". The server
+     * treats unknown values as absent, so this can never break a login.
+     */
+    client?: string;
     fetchImpl?: typeof fetch;
     now?: () => number;
     sleep?: (ms: number) => Promise<void>;

package/dist/login.js

@@ -100,7 +100,9 @@ export async function login(deps = {}) {
             res = await fetchImpl(`${baseUrl}/api/yagni-code/auth/token`, {
                 method: "POST",
                 headers: { "content-type": "application/json" },
-                body: JSON.stringify({ device_code: start.device_code }),
+                // `client` attributes the minted token to the requesting app; servers
+                // that predate the field simply ignore it.
+                body: JSON.stringify({ device_code: start.device_code, client: deps.client ?? "cli" }),
                 signal: AbortSignal.timeout(POLL_REQUEST_TIMEOUT_MS),
             });
         }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yagni-app/code-staging",
-  "version": "0.1.0-staging.1020.1",
+  "version": "0.1.0-staging.1022.1",
   "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)",
@@ -38,5 +38,5 @@
     "@earendil-works/pi-tui": "0.83.0",
     "typebox": "^1.1.38"
   },
-  "yagniSourceSha": "db184c4a3d15bc4b5e140a5337f34be7dadbb943"
+  "yagniSourceSha": "7f34f64551f21aea107ba21cfe2f846bf84447d1"
 }