@yagni-app/code-staging 0.3.1-staging.1101.1 → 0.3.1-staging.1107.1

package/dist/crashReport.d.ts

@@ -29,6 +29,18 @@ export declare const MAX_CRASH_STACK_FRAMES = 40;
 export declare const MAX_CRASH_PAYLOAD_BYTES = 16384;
 /** Same truthiness rule as updateChecksDisabled: set and not "" / "0". */
 export declare function crashReportsDisabled(env?: NodeJS.ProcessEnv): boolean;
+/**
+ * True when this process is a test run. A crash reporter that phones home
+ * from a test suite files FICTIONAL crashes against real production
+ * telemetry — see the twin comment in `pi-extension-yagni/src/crashReport.ts`
+ * (Sentry YAGNI-BACKEND-2P / -2Q). Kept in sync with that copy.
+ *
+ * Deliberately broad: a false positive costs one unreported crash on a
+ * developer machine, a false negative pollutes production.
+ */
+export declare function runningUnderTest(env?: NodeJS.ProcessEnv): boolean;
+/** Reporting is off when the user disabled it OR this is a test process. */
+export declare function crashReportsSuppressed(env?: NodeJS.ProcessEnv): boolean;
 export interface SanitizeCrashOptions {
     /** Environment whose values get redacted (defaults to process.env). */
     env?: NodeJS.ProcessEnv;

package/dist/crashReport.js

@@ -33,6 +33,33 @@ export function crashReportsDisabled(env = process.env) {
     const value = env[CRASH_REPORT_DISABLE_ENV];
     return value !== undefined && value !== "" && value !== "0";
 }
+/**
+ * True when this process is a test run. A crash reporter that phones home
+ * from a test suite files FICTIONAL crashes against real production
+ * telemetry — see the twin comment in `pi-extension-yagni/src/crashReport.ts`
+ * (Sentry YAGNI-BACKEND-2P / -2Q). Kept in sync with that copy.
+ *
+ * Deliberately broad: a false positive costs one unreported crash on a
+ * developer machine, a false negative pollutes production.
+ */
+export function runningUnderTest(env = process.env) {
+    if (env.NODE_ENV === "test")
+        return true;
+    // node:test sets this in every spawned test-file process.
+    if (env.NODE_TEST_CONTEXT)
+        return true;
+    if (env.VITEST || env.JEST_WORKER_ID)
+        return true;
+    // npm/pnpm export the script name being run (`pnpm test`, `pnpm test:file`).
+    const script = env.npm_lifecycle_event;
+    if (script === "test" || (script !== undefined && script.startsWith("test:")))
+        return true;
+    return false;
+}
+/** Reporting is off when the user disabled it OR this is a test process. */
+export function crashReportsSuppressed(env = process.env) {
+    return crashReportsDisabled(env) || runningUnderTest(env);
+}
 // Mirrors scrubSecrets (backend yagniCode/scrubSecrets.ts and
 // pi-extension-yagni pipeline/scrubSecrets.ts) — keep in sync.
 const SECRET_PATTERNS = [
@@ -147,7 +174,7 @@ export function sanitizeCrashError(err, opts = {}) {
 export async function sendCrashReport(input) {
     try {
         const env = input.env ?? process.env;
-        if (crashReportsDisabled(env))
+        if (crashReportsSuppressed(env))
             return;
         const opts = { env, repoRoot: input.repoRoot };
         const stack = input.stack !== undefined

package/dist/extension/crashReport.d.ts

@@ -33,6 +33,24 @@ export declare const MAX_CRASH_STACK_FRAMES = 40;
 export declare const MAX_CRASH_PAYLOAD_BYTES = 16384;
 /** Same truthiness rule as the CLI's YAGNI_DISABLE_* family. */
 export declare function crashReportsDisabled(env?: NodeJS.ProcessEnv): boolean;
+/**
+ * True when this process is a test run.
+ *
+ * A crash reporter that phones home from a test suite reports FICTIONAL
+ * crashes against real production telemetry. That is not theoretical: the
+ * `/go` terminal catch builds a live reporter whenever its caller doesn't
+ * inject one, so `goCommand.test.ts`'s deliberate `throw new Error("boom")`
+ * POSTed to https://yagni.app on every run — 915 events across Sentry
+ * YAGNI-BACKEND-2P / -2Q, from a team that had never witnessed a crash.
+ *
+ * Injecting a stub at each call site fixes one test; this makes the whole
+ * class impossible, so a future test that forgets cannot re-open the leak.
+ * Detection is deliberately broad — a false positive costs one unreported
+ * crash on a developer machine, a false negative pollutes production.
+ */
+export declare function runningUnderTest(env?: NodeJS.ProcessEnv): boolean;
+/** Reporting is off when the user disabled it OR this is a test process. */
+export declare function crashReportsSuppressed(env?: NodeJS.ProcessEnv): boolean;
 export interface SanitizeCrashOptions {
     env?: NodeJS.ProcessEnv;
     repoRoot?: string;

package/dist/extension/crashReport.js

@@ -40,6 +40,39 @@ export function crashReportsDisabled(env = process.env) {
     const value = env[CRASH_REPORT_DISABLE_ENV];
     return value !== undefined && value !== "" && value !== "0";
 }
+/**
+ * True when this process is a test run.
+ *
+ * A crash reporter that phones home from a test suite reports FICTIONAL
+ * crashes against real production telemetry. That is not theoretical: the
+ * `/go` terminal catch builds a live reporter whenever its caller doesn't
+ * inject one, so `goCommand.test.ts`'s deliberate `throw new Error("boom")`
+ * POSTed to https://yagni.app on every run — 915 events across Sentry
+ * YAGNI-BACKEND-2P / -2Q, from a team that had never witnessed a crash.
+ *
+ * Injecting a stub at each call site fixes one test; this makes the whole
+ * class impossible, so a future test that forgets cannot re-open the leak.
+ * Detection is deliberately broad — a false positive costs one unreported
+ * crash on a developer machine, a false negative pollutes production.
+ */
+export function runningUnderTest(env = process.env) {
+    if (env.NODE_ENV === "test")
+        return true;
+    // node:test sets this in every spawned test-file process.
+    if (env.NODE_TEST_CONTEXT)
+        return true;
+    if (env.VITEST || env.JEST_WORKER_ID)
+        return true;
+    // npm/pnpm export the script name being run (`pnpm test`, `pnpm test:file`).
+    const script = env.npm_lifecycle_event;
+    if (script === "test" || (script !== undefined && script.startsWith("test:")))
+        return true;
+    return false;
+}
+/** Reporting is off when the user disabled it OR this is a test process. */
+export function crashReportsSuppressed(env = process.env) {
+    return crashReportsDisabled(env) || runningUnderTest(env);
+}
 const HOME_DIR_RE = /(?:\/(?:Users|home)\/|[A-Za-z]:\\Users\\)[^\s/\\]+/g;
 // Spaces deliberately allowed inside the token (real directories contain
 // them); prose after a path may fold into the kept basename — over-redacts
@@ -122,7 +155,7 @@ export function makeCrashReporter(opts) {
     return async (error, context, repoRoot) => {
         try {
             const env = opts.env ?? process.env;
-            if (crashReportsDisabled(env))
+            if (crashReportsSuppressed(env))
                 return;
             const token = opts.getToken();
             const sanitized = sanitizeCrashError(error, { env, repoRoot });
@@ -191,7 +224,7 @@ const DETACHED_SENDER_SRC = [
 export function reportFatalCrash(error, opts, context) {
     try {
         const env = opts.env ?? process.env;
-        if (crashReportsDisabled(env))
+        if (crashReportsSuppressed(env))
             return;
         const token = opts.getToken();
         if (!token)

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-staging",
-  "version": "0.3.1-staging.1101.1",
+  "version": "0.3.1-staging.1107.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)",
@@ -39,5 +39,5 @@
     "smol-toml": "^1.8.0",
     "typebox": "^1.3.11"
   },
-  "yagniSourceSha": "9433338f90e3be351fac886eb10f15a4562696da"
+  "yagniSourceSha": "7029b03b5a6d5eac5c16a0a25670cc64ea989f82"
 }