@yagni-app/code-staging 1.2.12-staging.2140.1 → 1.2.12-staging.2145.1

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

@@ -36,7 +36,7 @@ import type { PipelineStage } from "./types.js";
  * each fix. Its words never name the harness (the branding scrub rewrites
  * that word) and open with no bullet.
  */
-export declare const WORK_A_TICKET_SKILL = "---\nname: work-a-ticket\ndescription: How YAGNI works a ticket in one session, from reading it to a committed, honestly reported change. Read, run and plan with options and a recommendation, stop for approval, build the smallest change with subagents, verify with a fresh one, commit and report.\n---\n\n# How YAGNI works a ticket\n\nYou work one ticket for a Team, in its repository, checked out in your working directory on a machine that is yours for the whole run. A person approves your plan before anything is built. YAGNI pushes your commits, opens the pull request, waits for CI and the review, and brings you back with what they asked. Each time YAGNI resumes you, its message says which turn this is and what it needs back. This is a playbook, not a contract: use your judgement, and say what you did.\n\n## 1. Understand the ticket\n\nRead the ticket, its evidence and every image it names, the design, the memo, the checks, the Team's playbook and the Plan line's instructions. Read the code the ticket touches, and send searcher subagents for wide reads, in parallel. Settle facts by running things rather than guessing: the tests, a type check, the app, Docker, a query. Installing what a check needs is fine. Read the decision ledger (team_read with yagni_decisions_read_for_repository) and ask_yagni before you ask a person anything.\n\n## 2. Plan, then stop\n\nName the files and the steps. Where there is a real choice of approach, give the options, each with what it changes and what it costs, and recommend one. End the turn with the plan in the format the message gives, and stop. You have no edit or write tool until the plan is approved, and anything you change in tracked files before then is put back.\n\n## 3. Build\n\nThe option the person approved is binding. The plan's steps are guidance: when the code shows a better step, take it, and record the departure and why. Prefer the smallest change that meets the ticket: no drive-by refactors and no files the ticket does not need. Hand fully specified chunks of work (the files, the change, the check that proves it) to the implementer subagent, and keep the judgement calls yourself. Run the checks that prove the change. A check that already failed on the unchanged code is not yours to fix; say so.\n\n## 4. Verify\n\nBefore you finish, dispatch a fresh verification subagent on your diff, with the ticket and the plan, and fix what it finds that is real. For a large change, send two or three with different lenses and treat their agreement as confirmation.\n\n## 5. Commit and report\n\nCommit on the branch you are on, with clear messages. Never push, never open or edit a pull request, and never change the git identity or config. Write the report the message asks for last, and honestly: each check you ran with its real exit code, what you could not verify and why, and every departure from the plan and why. A check you did not run is not a pass.\n\n## Rules that always hold\n\nNever fabricate a path, a result or a check: \"not found\" and \"not verified\" are answers. Never print, commit or send a token or a variable's value. If the disk fills (\"no space left on device\"), stop and say so; do not delete or prune to go on. Call record_decision only for a consequential product or architecture call the plan did not settle.\n";
+export declare const WORK_A_TICKET_SKILL = "---\nname: work-a-ticket\ndescription: How YAGNI works a ticket in one session, from reading it to a committed, honestly reported change. Read, run and plan with options and a recommendation, stop for approval, build the smallest change with subagents, verify with a fresh one, commit and report.\n---\n\n# How YAGNI works a ticket\n\nYou work one ticket for a Team, in its repository, checked out in your working directory on a machine that is yours for the whole run. A person approves your plan before anything is built. YAGNI pushes your commits, opens the pull request, waits for CI and the review, and brings you back with what they asked. Each time YAGNI resumes you, its message says which turn this is and what it needs back. This is a playbook, not a contract: use your judgement, and say what you did.\n\n## 1. Understand the ticket\n\nRead the ticket, its evidence and every image it names, the design, the memo, the checks, the Team's playbook and the Plan line's instructions. Read the code the ticket touches, and send searcher subagents for wide reads, in parallel. Settle facts by running things rather than guessing: the tests, a type check, the app, Docker, a query. Installing what a check needs is fine. Read the decision ledger (team_read with yagni_decisions_read_for_repository) and ask_yagni before you ask a person anything.\n\n## 2. Plan, then stop\n\nName the files and the steps. Where there is a real choice of approach, give the options, each with what it changes and what it costs, and recommend one. End the turn with the plan in the format the message gives, and stop. You have no edit or write tool until the plan is approved, and anything you change in tracked files before then is put back.\n\n## 3. Build\n\nThe option the person approved is binding. The plan's steps are guidance: when the code shows a better step, take it, and record the departure and why. Prefer the smallest change that meets the ticket: no drive-by refactors and no files the ticket does not need. Hand fully specified chunks of work (the files, the change, the check that proves it) to the implementer subagent, and keep the judgement calls yourself. Run the checks that prove the change. A check that already failed on the unchanged code is not yours to fix; say so.\n\n## 4. Verify\n\nBefore you finish, dispatch a fresh verification subagent on your diff, with the ticket and the plan, and fix what it finds that is real. Send one. Only for a risky change (a migration, auth, money, data that cannot be restored) send two or three with different lenses and treat their agreement as confirmation.\n\n## 5. Commit and report\n\nCommit on the branch you are on, with clear messages. Never push, never open or edit a pull request, and never change the git identity or config. Write the report the message asks for last, and honestly: each check you ran with its real exit code, what you could not verify and why, and every departure from the plan and why. A check you did not run is not a pass.\n\n## Rules that always hold\n\nNever fabricate a path, a result or a check: \"not found\" and \"not verified\" are answers. Never print, commit or send a token or a variable's value. If the disk fills (\"no space left on device\"), stop and say so; do not delete or prune to go on. Call record_decision only for a consequential product or architecture call the plan did not settle.\n";
 /** Persona body keyed by the agent name referenced in `stages.ts`. */
 export declare const PERSONA_BODIES: Record<string, string>;
 /**

package/dist/extension/pipeline/personas.js

@@ -103,7 +103,7 @@ The option the person approved is binding. The plan's steps are guidance: when t
 
 ## 4. Verify
 
-Before you finish, dispatch a fresh verification subagent on your diff, with the ticket and the plan, and fix what it finds that is real. For a large change, send two or three with different lenses and treat their agreement as confirmation.
+Before you finish, dispatch a fresh verification subagent on your diff, with the ticket and the plan, and fix what it finds that is real. Send one. Only for a risky change (a migration, auth, money, data that cannot be restored) send two or three with different lenses and treat their agreement as confirmation.
 
 ## 5. Commit and report
 

package/dist/extension/subagents.d.ts

@@ -62,7 +62,13 @@ export interface SubagentDef {
     /** The agent's system prompt (the markdown body). */
     body: string;
     source: SubagentSource;
+    /** This agent's own wall clock, when shorter than {@link SUBAGENT_WALL_TIMEOUT_MS}. */
+    wallTimeoutMs?: number;
 }
+/** How long one verification subagent may run: a review of a finished diff,
+ * not a second build (on staging 2026-10-28, advanced-tier verifiers ran 34
+ * minutes after an 11-minute build). */
+export declare const VERIFICATION_WALL_TIMEOUT_MS: number;
 /** Claude Code model names → YAGNI tiers; YAGNI tiers pass through. */
 export declare function mapModelTier(model: string | undefined): ModelTier;
 /**
@@ -154,7 +160,7 @@ export declare const SUBAGENT_WALL_TIMEOUT_MS: number;
  * Exported so a test can pin the composed policy the production path actually
  * runs (every unit test injects runStageImpl instead).
  */
-export declare function subagentRunPolicy(): ResiliencePolicy;
+export declare function subagentRunPolicy(wallTimeoutMs?: number): ResiliencePolicy;
 /**
  * The per-attempt telemetry adapter: one content-free error-sink row per
  * resilience attempt (agent, taskIndex, outcome, timeoutKind, exit code,

package/dist/extension/subagents.js

@@ -212,23 +212,29 @@ What you could not check, and why.
 
 A HOLDS after real digging is valuable; a rubber stamp is not. If you found
 nothing, say exactly what you tried to break and how.`;
+/** How long one verification subagent may run: a review of a finished diff,
+ * not a second build (on staging 2026-10-28, advanced-tier verifiers ran 34
+ * minutes after an 11-minute build). */
+export const VERIFICATION_WALL_TIMEOUT_MS = 15 * 60_000;
 /** The diamond's reduce layer: refute-first review of completed work on the
- * advanced tier (judgment is the whole job, so the premium is worth paying —
- * the server clamps subagent children at advanced anyway). It has no
- * edit/write tools; bash is included for `git diff`-style inspection and is
- * restricted to read-only USE by the persona, the same prompt-level stance as
- * /go's reviewer — not a technical guarantee. */
+ * peak tier (judgment is the whole job, so the premium is worth paying; the
+ * server exempts this caller from its advanced ceiling for subagents). One by
+ * default, on a fifteen-minute clock. It has no edit/write tools; bash is
+ * included for `git diff`-style inspection and is restricted to read-only USE
+ * by the persona, the same prompt-level stance as /go's reviewer — not a
+ * technical guarantee. */
 const VERIFICATION_AGENT = {
     name: "verification",
     description: "Adversarial verification of completed work: tries to refute a change, " +
         "plan, or claim and reports concrete failure scenarios. Does not edit " +
-        "files. Fan out 2-3 with different lenses (correctness, edge cases, " +
-        "codebase fit) for anything significant and treat agreement as " +
-        "confirmation.",
-    model: "advanced",
+        "files. Send one; send two or three with different lenses (correctness, " +
+        "edge cases, codebase fit) only for a risky change such as a migration, " +
+        "auth or money, and treat agreement as confirmation.",
+    model: "peak",
     tools: ["read", "grep", "find", "ls", "bash", "ask_yagni"],
     body: VERIFICATION_BODY,
     source: "builtin",
+    wallTimeoutMs: VERIFICATION_WALL_TIMEOUT_MS,
 };
 // Concrete tiers a subagent can actually run on. `balanced` is deliberately NOT
 // a member here even though it is a member of `ModelTier`: a subagent needs
@@ -485,8 +491,8 @@ export const SUBAGENT_WALL_TIMEOUT_MS = 2 * 60 * 60_000;
  * Exported so a test can pin the composed policy the production path actually
  * runs (every unit test injects runStageImpl instead).
  */
-export function subagentRunPolicy() {
-    return { ...DEFAULT_RESILIENCE_POLICY, wallTimeoutMs: SUBAGENT_WALL_TIMEOUT_MS, retryWallTimeout: false };
+export function subagentRunPolicy(wallTimeoutMs = SUBAGENT_WALL_TIMEOUT_MS) {
+    return { ...DEFAULT_RESILIENCE_POLICY, wallTimeoutMs, retryWallTimeout: false };
 }
 /**
  * The per-attempt telemetry adapter: one content-free error-sink row per
@@ -525,10 +531,22 @@ export function makeSubagentTool(deps = {}) {
     // text). The write-gate keys on the resolved agent's tools,
     // passed per task below — the synthetic stage id is "implement" and would
     // otherwise block retry of a read-only verifier forever.
-    const run = deps.runStageImpl ??
-        withResilience(runStage, subagentRunPolicy(), {
-            telemetry: subagentTelemetry(deps.env ?? process.env),
-        });
+    // One wrapped runner per wall clock: an agent with its own (verification)
+    // gets a runner built on it, every other agent shares the lane's default.
+    const runners = new Map();
+    const runFor = (def) => {
+        if (deps.runStageImpl)
+            return deps.runStageImpl;
+        const wall = def.wallTimeoutMs ?? SUBAGENT_WALL_TIMEOUT_MS;
+        let runner = runners.get(wall);
+        if (!runner) {
+            runner = withResilience(runStage, subagentRunPolicy(wall), {
+                telemetry: subagentTelemetry(deps.env ?? process.env),
+            });
+            runners.set(wall, runner);
+        }
+        return runner;
+    };
     const discover = deps.discover ?? discoverSubagents;
     const grounded = deps.grounded !== false;
     // Resolve the effective body for a spawned subagent: the grounding-free
@@ -647,7 +665,7 @@ export function makeSubagentTool(deps = {}) {
                 outcomes = await Promise.all(resolved.map(async ({ def, task }, index) => {
                     const progress = progresses[index];
                     const { stage, ctx: stageCtx } = buildSubagentStage(def, task, { grounded });
-                    const result = await run(stage, stageCtx, {
+                    const result = await runFor(def)(stage, stageCtx, {
                         cwd,
                         signal,
                         // Write-gate input: whether the agent's DECLARED tool list has

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yagni-app/code-staging",
-  "version": "1.2.12-staging.2140.1",
+  "version": "1.2.12-staging.2145.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)",
@@ -58,5 +58,5 @@
     "turndown": "^7.2.4",
     "typebox": "^1.3.15"
   },
-  "yagniSourceSha": "1d9c69f9bf3799e4a3ff4650aacebb1ba5f3820e"
+  "yagniSourceSha": "4064b7ebffbbfcea04ce43830817cd6e35df7d77"
 }