@yagni-app/code-staging 0.3.1-staging.1103.1 → 0.3.1-staging.1108.1

package/dist/extension/pipeline/invocation.d.ts

@@ -3,9 +3,17 @@
  * `buildLaunch` (no spawn, no fs).
  *
  * `buildStageInvocation` produces the per-stage pi PASSTHROUGH argv exactly as
- * the subagent example assembles it (runSingleAgent L294-330):
+ * the subagent example assembles it (runSingleAgent L294-330), with an added
+ * honesty preamble delivered as the FIRST `--append-system-prompt` so the
+ * anti-fabrication rule appears before the persona body in the child's
+ * assembled system prompt:
  *   --mode json -p --no-session --model <tier> --tools <csv>
- *   --append-system-prompt <file> 'Task: <rendered>'
+ *   --append-system-prompt <honesty> --append-system-prompt <file> 'Task: <rendered>'
+ *
+ * Pi concatenates multiple `--append-system-prompt` values with `\n\n` in
+ * array order, so the child sees: [pi base] + [honesty] + [persona] +
+ * [project_context]. The preamble is placed first so open-weight models
+ * encounter the anti-fabrication rule before their role identity.
  *
  * `groundedChildArgv` prepends the grounding pi-args the yagni-code launcher
  * would otherwise add (`-e <self> --provider yagni`) because v1 spawns pi
@@ -17,6 +25,20 @@
  * chain's `step.task.replace(/{previous}/g, …)`.
  */
 import type { PipelineStage, ReviewLens } from "./types.js";
+/**
+ * Anti-fabrication preamble injected as the first `--append-system-prompt` on
+ * every child pi process (both /go stages and subagent tool calls). The
+ * driver-only `ENGINEERING_PRACTICE_SECTION` never reaches children (it's a
+ * launcher flag, and children build their own argv); this preamble ensures
+ * the honesty rule is present in every child regardless.
+ *
+ * Content constraints (same as the enrichment section — the branding scrub's
+ * `scrubOutsideProjectContext` replaces whole-word \bpi\b and the
+ * `PI_DOCS_BLOCK_RE` regex consumes consecutive `- ` bullet lines that follow
+ * a docs header): must not contain the standalone word "pi", must not open
+ * with a `- ` bullet line, no emojis.
+ */
+export declare const CHILD_HONESTY_PREAMBLE: string;
 /** Fill {ticket}/{previous}; an absent var renders as empty string. */
 export declare function renderTemplate(tmpl: string, vars: {
     ticket?: string;

package/dist/extension/pipeline/invocation.js

@@ -3,9 +3,17 @@
  * `buildLaunch` (no spawn, no fs).
  *
  * `buildStageInvocation` produces the per-stage pi PASSTHROUGH argv exactly as
- * the subagent example assembles it (runSingleAgent L294-330):
+ * the subagent example assembles it (runSingleAgent L294-330), with an added
+ * honesty preamble delivered as the FIRST `--append-system-prompt` so the
+ * anti-fabrication rule appears before the persona body in the child's
+ * assembled system prompt:
  *   --mode json -p --no-session --model <tier> --tools <csv>
- *   --append-system-prompt <file> 'Task: <rendered>'
+ *   --append-system-prompt <honesty> --append-system-prompt <file> 'Task: <rendered>'
+ *
+ * Pi concatenates multiple `--append-system-prompt` values with `\n\n` in
+ * array order, so the child sees: [pi base] + [honesty] + [persona] +
+ * [project_context]. The preamble is placed first so open-weight models
+ * encounter the anti-fabrication rule before their role identity.
  *
  * `groundedChildArgv` prepends the grounding pi-args the yagni-code launcher
  * would otherwise add (`-e <self> --provider yagni`) because v1 spawns pi
@@ -16,6 +24,24 @@
  * `renderTemplate` does the {ticket}/{previous} substitution, mirroring the
  * chain's `step.task.replace(/{previous}/g, …)`.
  */
+/**
+ * Anti-fabrication preamble injected as the first `--append-system-prompt` on
+ * every child pi process (both /go stages and subagent tool calls). The
+ * driver-only `ENGINEERING_PRACTICE_SECTION` never reaches children (it's a
+ * launcher flag, and children build their own argv); this preamble ensures
+ * the honesty rule is present in every child regardless.
+ *
+ * Content constraints (same as the enrichment section — the branding scrub's
+ * `scrubOutsideProjectContext` replaces whole-word \bpi\b and the
+ * `PI_DOCS_BLOCK_RE` regex consumes consecutive `- ` bullet lines that follow
+ * a docs header): must not contain the standalone word "pi", must not open
+ * with a `- ` bullet line, no emojis.
+ */
+export const CHILD_HONESTY_PREAMBLE = "Never fabricate file paths, file contents, function signatures, enum values, or code. " +
+    "If you cannot find something, say so explicitly — an honest \"not found\" is more valuable " +
+    "than a plausible-sounding invention. Every file path you cite must be a path you actually " +
+    "read with a tool. If you are uncertain whether something exists, say you are uncertain " +
+    "rather than presenting a guess as a finding.";
 /** Fill {ticket}/{previous}; an absent var renders as empty string. */
 export function renderTemplate(tmpl, vars) {
     return tmpl
@@ -41,6 +67,8 @@ export function buildStageInvocation(stage, ctx) {
         "--tools",
         stage.tools.join(","),
         "--append-system-prompt",
+        CHILD_HONESTY_PREAMBLE,
+        "--append-system-prompt",
         ctx.promptFilePath,
         `Task: ${task}`,
     ];

package/dist/extension/subagents.js

@@ -72,6 +72,8 @@ const GENERAL_BODY = `You are a capable software-engineering subagent with a fre
 
 You are grounded in how THIS company works: call ask_yagni before inferring a convention, an ownership rule, or anything organization-specific.
 
+Never fabricate file paths, contents, or findings. If you cannot find something, say so.
+
 Your final message is your report back to the driving agent, which has NOT seen what you read or did. Make it compressed and complete: what you did, what you found, exact file paths and key excerpts, and anything the driver must know before continuing.`;
 const GENERAL_AGENT = {
     name: GENERAL_AGENT_NAME,
@@ -87,6 +89,11 @@ not write code and you do not run commands; you read and report.
 You are grounded in how THIS company works: call ask_yagni before inferring a
 convention, an ownership rule, or anything organization-specific.
 
+Never fabricate file paths, contents, or code. Every path you cite must be
+one you actually read with a tool. If you cannot find something, say "not
+found" — a plausible-sounding invention is worse than no answer because the
+driving agent trusts your report.
+
 Your final message is your report back to the driving agent, which has NOT
 seen what you read. Make it compressed and complete: exact file paths, the
 key excerpts, and a one-paragraph map of how the pieces relate. Say what you
@@ -112,6 +119,9 @@ your final message instead of guessing.
 You are grounded in how THIS company works: call ask_yagni before inferring a
 convention, an ownership rule, or anything organization-specific.
 
+Never fabricate file paths or results. Report what you actually did and what
+you actually found.
+
 Your final message is your report back to the driving agent, which has NOT
 seen what you did. List every file you touched, what changed in each, the
 commands you ran with their outcomes, and anything you deliberately left
@@ -141,6 +151,9 @@ verifiers.
 You are grounded in how THIS company works: call ask_yagni before inferring
 a convention, an ownership rule, or anything organization-specific.
 
+Never fabricate file paths or findings. If you could not verify something,
+say exactly what you tried and why you could not.
+
 Your final message is your verdict back to the driving agent, which has NOT
 seen what you read. Format:
 ## Verdict

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.1103.1",
+  "version": "0.3.1-staging.1108.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": "5df84aa9651fc7d6dd30b38bb062e8ee3c71156d"
+  "yagniSourceSha": "4244ba837c0cfc0ad410d02e34df6ad82e32a848"
 }