@drisp/cli 0.7.7 → 0.7.9

package/dist/{WorkflowInstallWizard-VVEEJW25.js → WorkflowInstallWizard-FKASDA6N.js}

@@ -8,7 +8,7 @@ import {
   installWorkflowPlugins,
   resolveWorkflow,
   writeGlobalConfig
-} from "./chunk-HZ6GRLOM.js";
+} from "./chunk-FYXEDUQ6.js";
 import "./chunk-G3PMV62Z.js";
 
 // src/setup/steps/WorkflowInstallWizard.tsx
@@ -93,4 +93,4 @@ function WorkflowInstallWizard({ source, onDone }) {
 export {
   WorkflowInstallWizard as default
 };
-//# sourceMappingURL=WorkflowInstallWizard-VVEEJW25.js.map
+//# sourceMappingURL=WorkflowInstallWizard-FKASDA6N.js.map

package/dist/{chunk-HZ6GRLOM.js → chunk-FYXEDUQ6.js}

@@ -21227,6 +21227,11 @@ var BUILD_STRINGS = {
   templatePark: "Drisp was updated during this Build. Build again to re-plan.",
   notStarted: "Not started",
   waiting: "Waiting for child Runs.",
+  /**
+   * The Merge step's Sign-off when the member merges (`merge: you`, root ADR-0009): the `NEEDS_HUMAN` text a child
+   * parks with, `{sha}` being the full head SHA it asks about. The app reads it as "Blocked · Your merge".
+   */
+  mergeSignOff: "Your merge: this pull request is ready to merge at {sha}. Reply in this Thread to sign off on that commit, or say what to change.",
   notAGitHubRepository: "The project folder is not a git repository with a GitHub origin.",
   cycle: (identifiers) => `These issues block each other in Linear: ${identifiers.join(", ")}.`,
   /** The comment the Orchestrator posts with its one Linear write, moving a merged issue to Done. */
@@ -21255,7 +21260,7 @@ var GATES = [
   },
   {
     title: "Checks",
-    passesWhen: "{install}{checks} pass",
+    passesWhen: "{install}{checks} pass, each check run through `drisp build check <name> -- <command>` (for example `drisp build check typecheck -- make typecheck`), which records its outcome for the Build page",
     cannotPass: "This issue's checks still fail after repeated fixes. Open the Thread to see the failing output."
   },
   {
@@ -21281,7 +21286,7 @@ var GATES = [
 ];
 
 // src/core/workflows/builtins/orchestrator/workflow.md
-var workflow_default = '# Orchestrator: plan and run a Build\n\nYou plan and run a Drisp Build of one Plan: the open issues of one Linear project. The Run\'s prompt names the\nLinear project, the Plan key and the project folder, which is your working directory. You never write code here:\neach issue is built by its own child Run, which `drisp build tick` starts.\n\nThe Runner sets these for you:\n\n- `DRISP_RUN_ARTIFACTS`: this Run\'s artifact directory. Files you write there are shown to the member.\n- `DRISP_RUN_ID`, `DRISP_RUNNER_ID`, `DRISP_RUN_TOKEN`, `DRISP_HUB_URL`: this Run, its Runner and its right to start\n  child Runs; `drisp build` reads them itself.\n\n## 1. Read Linear (first Turn)\n\nWith the `linear` MCP server, read the project and every issue in it, then write\n`$DRISP_RUN_ARTIFACTS/input/plan-input.json` (create the `input` directory) in exactly this shape. Every issue carries\nevery field, empty when it has none. `readAt` is the output of\n`node -e "console.log(new Date().toISOString())"` run just before you read Linear; never write a time yourself:\n\n```json\n{\n	"version": 1,\n	"readAt": "<the command\'s output, e.g. 2026-10-11T09:30:00.000Z>",\n	"project": {\n		"id": "<the project\'s `uuid`, not its `id`>",\n		"name": "<the project\'s `name`>",\n		"slugId": "<the last `-`-separated part of the project\'s `url`>"\n	},\n	"issues": [\n		{\n			"id": "<the issue\'s `uuid`, not its `id`>",\n			"identifier": "<the issue\'s `id`, e.g. DRI-12>",\n			"title": "<the issue\'s `title`>",\n			"description": "<full current description>",\n			"acceptanceCriteria": "<acceptance criteria, empty when included in description>",\n			"external": false,\n			"url": "<the issue\'s `url`>",\n			"branchName": "<the issue\'s `gitBranchName`, or null>",\n			"state": {\n				"type": "<the issue\'s `statusType`: backlog|unstarted|started|completed|canceled|triage>",\n				"name": "<the issue\'s `status`>"\n			},\n			"labels": ["<each of the issue\'s `labels`>"],\n			"parentId": "<the parent issue\'s `uuid`, or null>",\n			"blockedBy": ["<the `uuid` of each issue in `relations.blockedBy`>"],\n			"prioritySortOrder": 0\n		}\n	]\n}\n```\n\nLinear\'s MCP names fields differently from this file, and the difference matters: the app finds each issue\'s row by\nits UUID, so a plan that carries identifiers shows no Build state on any row.\n\n- The MCP\'s `id` is the readable identifier (`DRI-12`, or `P-DRI-7` for a project); the UUID is in `uuid`. Every\n  `id`, `parentId` and `blockedBy` value in `plan-input.json` is a UUID (`7f7b03f7-accf-46b2-98fb-abadfed76594`).\n- An issue\'s `parentId` and `relations.blockedBy` from the MCP name issues by identifier. Look each one up: use the\n  `uuid` of the project\'s issue with that identifier, or `get_issue` it when it is outside the project.\n- Read relations with `get_issue` and `includeRelations: true`; read the project\'s issues with `list_issues` and\n  `fields` including `uuid`.\n- The project\'s `url` ends in its `slugId` (`\u2026/project/build-sandbox-b7640301cd64` \u2192 `b7640301cd64`).\n\n`drisp build plan` rejects a plan with an identifier where a UUID belongs and names the field to fix.\n\nAlso include every referenced blocker outside the project, with `external: true`, its current status and UUID. Follow blocker relations recursively; deduplicate by UUID. Never mark a project issue external. External issues are read only and never scheduled. Preserve actual prioritySortOrder when available.\n\nOnly ready-for-agent issues without conflicting ready-for-human, needs-info, needs-triage or wontfix labels are eligible. Do not invent or change labels to make an issue eligible.\n\nInclude every issue of the project, done and canceled ones too: the plan decides what to skip. Then run:\n\n```sh\ndrisp build plan --input "$DRISP_RUN_ARTIFACTS/input/plan-input.json"\n```\n\nIt prints one JSON object. Act on its `status`.\n\n## 2. `needs_fills`\n\n`fills` lists issues that need a `fill.json` (`identifier`, `title`, `url`, `path`) and `templateVersion` is the value\neach fill must carry. For each listed issue: read it through `linear` (description, acceptance criteria, comments) and\nthe repo\'s ADRs and CONTEXT files it touches, then write its `fill.json` at `path`:\n\n```json\n{\n	"version": 1,\n	"templateVersion": "<templateVersion, copied exactly>",\n	"areas": ["macos|web|cli|hub|protocol|docs", "\u2026"],\n	"qa": "none|web|macos|both",\n	"profile": "implementation|documentation|investigation",\n	"rationale": "<why these steps are appropriate>",\n	"acceptanceEvidence": [\n		"<each acceptance criterion and the evidence that demonstrates it>"\n	],\n	"sizeClass": "S|M|L",\n	"instructions": "<what the child needs beyond the issue>",\n	"ownWork": true\n}\n```\n\n- `areas`: the parts of the repo the change touches, each once.\n- `profile`: implementation for behavior changes, documentation for prose-only repository changes, investigation for findings with no repository changes. Implementation defaults to TDD and two-reviewer code review; documentation and investigation omit these by default. Choose the profile from the actual deliverable, not the issue size.\n- Optional `testFirst` and `review`: `{ "enabled": true|false, "reason": "<issue-specific justification>" }`. Retain tests and review for behavioral changes; omit only when not applicable and explain why. These selections also control required skills.\n- Optional `checks`: a nonempty list of actual validation commands from the repo, using the supported npm, vitest, make or git diff command families. Read repository tooling and add the relevant test/build checks: typechecking alone does not prove behavior. If a necessary command is unsupported, state that limitation in instructions and require human attention, never claim validation passed.\n- `acceptanceEvidence`: cover every criterion, including the method and expected outcome.\n- `qa`: `both` when both interfaces change, `web` when the change shows in a web page, `macos` when it shows in the macOS app, else `none`.\n- `sizeClass`: `S` for a change of a file or two, `M` for a feature across a few modules, `L` for a large or risky\n  change.\n- `instructions` (at most 6000 characters): start with one short paragraph saying what to build, then restate the\n  acceptance criteria, name the ADRs it touches and the parts of the codebase involved. Plain prose and `-` lists\n  only: no headings, code fences or HTML comments (`drisp build plan` rejects them).\n- `ownWork`: `false` only for an issue with sub-issues whose own description asks for nothing beyond them, such as\n  a PRD above its slices; the plan then skips it and waits for its sub-issues instead. Otherwise `true`.\n\nThen run `drisp build plan` again with the same `--input` path.\n\n## 3. `planned` or `failed`\n\nOn `planned` the Build plan is written and shown to the member, who decides whether to start it: end the Turn with\n`<!-- AWAITING_APPROVAL -->` as the Journal\'s last line. On `failed` the reason is shown instead: end with\n`<!-- WORKFLOW_COMPLETE -->`.\n\n## 4. Every later wake: tick\n\nYou are woken when the member answers the approval question (with Start, or with words of their own before it) and whenever one of your child Runs closes or parks.\nEach time: read Linear again into `$DRISP_RUN_ARTIFACTS/input/plan-input.json` as in step 1 (with a new `readAt`),\nincluding full descriptions, acceptance criteria, labels and external blocker status. A scope change holds the affected issue for a fresh Build and approval. Then run:\n\n```sh\ndrisp build tick --input "$DRISP_RUN_ARTIFACTS/input/plan-input.json"\n```\n\nIt prints one JSON object. Act on its `action`, and repeat until an action ends the Turn:\n\n- `refresh_input`: read Linear into the input again (a newer `readAt`) and tick again.\n- `replan`: the member wrote words before starting, and `guidance` lists every round of them, oldest first. Plan again\n  with them as the member\'s wishes: read the issues they concern (and the repo) as in step 2, rewrite the `fill.json`\n  of each issue the guidance changes (`instructions`, `areas`, `qa`, `sizeClass`, or `ownWork` to leave an issue out),\n  and run `drisp build plan` again with the same `--input` path. Then end as in step 3: with\n  `<!-- AWAITING_APPROVAL -->` on `planned`, `<!-- WORKFLOW_COMPLETE -->` on `failed`. Write nothing but those\n  `fill.json` files.\n- `repair`: for each of `issues`, read it in Linear first and skip an issue Linear now shows Done or Canceled (its\n  child got there first); otherwise move it to Done and post its `comment` verbatim through `linear`. Then read\n  Linear into the input again and tick again.\n- `rebase`: for each of `items`, in its `worktree`: `git rebase origin/main`, resolve the conflicts, then\n  `git push --force-with-lease origin <branch>` (the item\'s `branch`) if the branch is on the remote. Never push any\n  other branch. If a rebase cannot be resolved, `git rebase --abort`.\n  Then read Linear into the input again and tick again, adding `--rebase-failed <identifier>` for each that failed.\n- `wait`: end the Turn with `<!-- WAITING_ON_CHILDREN -->` as the Journal\'s last line.\n- `park`: end the Turn with `<!-- NEEDS_HUMAN: <message> -->` as the Journal\'s last line, copying `message`\n  verbatim.\n- `complete`: end the Turn with `<!-- WORKFLOW_COMPLETE -->` as the Journal\'s last line.\n\n## Rules\n\n- Never start, cancel or edit Runs, Workflows, worktrees or branches except as an action says; `drisp build` does\n  what is needed.\n- Never write to Linear except a `repair`; never open a pull request.\n- Write only `plan-input.json` and the `fill.json` files `drisp build plan` asks for. Never write `answer.json`.\n';
+var workflow_default = '# Orchestrator: plan and run a Build\n\nYou plan and run a Drisp Build of one Plan: the open issues of one Linear project. The Run\'s prompt names the\nLinear project, the Plan key and the project folder, which is your working directory. You never write code here:\neach issue is built by its own child Run, which `drisp build tick` starts.\n\nThe Runner sets these for you:\n\n- `DRISP_RUN_ARTIFACTS`: this Run\'s artifact directory. Files you write there are shown to the member.\n- `DRISP_RUN_ID`, `DRISP_RUNNER_ID`, `DRISP_RUN_TOKEN`, `DRISP_HUB_URL`: this Run, its Runner and its right to start\n  child Runs; `drisp build` reads them itself.\n\n## 1. Read Linear (first Turn)\n\nWith the `linear` MCP server, read the project and every issue in it, then write\n`$DRISP_RUN_ARTIFACTS/input/plan-input.json` (create the `input` directory) in exactly this shape. Every issue carries\nevery field, empty when it has none. `readAt` is the output of\n`node -e "console.log(new Date().toISOString())"` run just before you read Linear; never write a time yourself:\n\n```json\n{\n	"version": 1,\n	"readAt": "<the command\'s output, e.g. 2026-10-11T09:30:00.000Z>",\n	"project": {\n		"id": "<the project\'s `uuid`, not its `id`>",\n		"name": "<the project\'s `name`>",\n		"slugId": "<the last `-`-separated part of the project\'s `url`>"\n	},\n	"issues": [\n		{\n			"id": "<the issue\'s `uuid`, not its `id`>",\n			"identifier": "<the issue\'s `id`, e.g. DRI-12>",\n			"title": "<the issue\'s `title`>",\n			"description": "<full current description>",\n			"acceptanceCriteria": "<acceptance criteria, empty when included in description>",\n			"external": false,\n			"url": "<the issue\'s `url`>",\n			"branchName": "<the issue\'s `gitBranchName`, or null>",\n			"state": {\n				"type": "<the issue\'s `statusType`: backlog|unstarted|started|completed|canceled|triage>",\n				"name": "<the issue\'s `status`>"\n			},\n			"labels": ["<each of the issue\'s `labels`>"],\n			"parentId": "<the parent issue\'s `uuid`, or null>",\n			"blockedBy": ["<the `uuid` of each issue in `relations.blockedBy`>"],\n			"prioritySortOrder": 0\n		}\n	]\n}\n```\n\nLinear\'s MCP names fields differently from this file, and the difference matters: the app finds each issue\'s row by\nits UUID, so a plan that carries identifiers shows no Build state on any row.\n\n- The MCP\'s `id` is the readable identifier (`DRI-12`, or `P-DRI-7` for a project); the UUID is in `uuid`. Every\n  `id`, `parentId` and `blockedBy` value in `plan-input.json` is a UUID (`7f7b03f7-accf-46b2-98fb-abadfed76594`).\n- An issue\'s `parentId` and `relations.blockedBy` from the MCP name issues by identifier. Look each one up: use the\n  `uuid` of the project\'s issue with that identifier, or `get_issue` it when it is outside the project.\n- Read relations with `get_issue` and `includeRelations: true`; read the project\'s issues with `list_issues` and\n  `fields` including `uuid`.\n- The project\'s `url` ends in its `slugId` (`\u2026/project/build-sandbox-b7640301cd64` \u2192 `b7640301cd64`).\n\n`drisp build plan` rejects a plan with an identifier where a UUID belongs and names the field to fix.\n\nAlso include every referenced blocker outside the project, with `external: true`, its current status and UUID. Follow blocker relations recursively; deduplicate by UUID. Never mark a project issue external. External issues are read only and never scheduled. Preserve actual prioritySortOrder when available.\n\nOnly ready-for-agent issues without conflicting ready-for-human, needs-info, needs-triage or wontfix labels are eligible. Do not invent or change labels to make an issue eligible.\n\nInclude every issue of the project, done and canceled ones too: the plan decides what to skip. Then run:\n\n```sh\ndrisp build plan --input "$DRISP_RUN_ARTIFACTS/input/plan-input.json"\n```\n\nIt prints one JSON object. Act on its `status`.\n\n## 2. `needs_fills`\n\n`fills` lists issues that need a `fill.json` (`identifier`, `title`, `url`, `path`) and `templateVersion` is the value\neach fill must carry. A `reason`, when present, says what to correct in the listed fills (fills that disagree on\n`merge`, say); fix that and keep the rest of each fill. For each listed issue: read it through `linear` (description,\nacceptance criteria, comments) and the repo\'s ADRs and CONTEXT files it touches, then write its `fill.json` at `path`:\n\n```json\n{\n	"version": 1,\n	"templateVersion": "<templateVersion, copied exactly>",\n	"areas": ["macos|web|cli|hub|protocol|docs", "\u2026"],\n	"qa": "none|web|macos|both",\n	"profile": "implementation|documentation|investigation",\n	"rationale": "<why these steps are appropriate>",\n	"acceptanceEvidence": [\n		"<each acceptance criterion and the evidence that demonstrates it>"\n	],\n	"sizeClass": "S|M|L",\n	"merge": "agent|you",\n	"instructions": "<what the child needs beyond the issue>",\n	"ownWork": true\n}\n```\n\n- `areas`: the parts of the repo the change touches, each once.\n- `profile`: implementation for behavior changes, documentation for prose-only repository changes, investigation for findings with no repository changes. Implementation defaults to TDD and two-reviewer code review; documentation and investigation omit these by default. Choose the profile from the actual deliverable, not the issue size.\n- Optional `testFirst` and `review`: `{ "enabled": true|false, "reason": "<issue-specific justification>" }`. Retain tests and review for behavioral changes; omit only when not applicable and explain why. These selections also control required skills.\n- Optional `checks`: a nonempty list of actual validation commands from the repo, using the supported npm, vitest, make or git diff command families. Read repository tooling and add the relevant test/build checks: typechecking alone does not prove behavior. If a necessary command is unsupported, state that limitation in instructions and require human attention, never claim validation passed.\n- `acceptanceEvidence`: cover every criterion, including the method and expected outcome.\n- `qa`: `both` when both interfaces change, `web` when the change shows in a web page, `macos` when it shows in the macOS app, else `none`.\n- `sizeClass`: `S` for a change of a file or two, `M` for a feature across a few modules, `L` for a large or risky\n  change.\n- `merge`: who merges each pull request. `agent` (the default) unless the member\'s own words in this chat, in the\n  Run\'s prompt or a guidance reply, ask to merge themselves ("ask me before merging", "I\'ll merge"): then `you`, and\n  the child\'s Merge step waits for the member\'s Sign-off in its Thread. It is one choice for the whole Build: write the\n  same value in every fill. It is fixed once the member presses Start: if they ask to change it after Start, tell\n  them to Cancel the Build and Build again.\n- `instructions` (at most 6000 characters): start with one short paragraph saying what to build, then restate the\n  acceptance criteria, name the ADRs it touches and the parts of the codebase involved. Plain prose and `-` lists\n  only: no headings, code fences or HTML comments (`drisp build plan` rejects them).\n- `ownWork`: `false` only for an issue with sub-issues whose own description asks for nothing beyond them, such as\n  a PRD above its slices; the plan then skips it and waits for its sub-issues instead. Otherwise `true`.\n\nThen run `drisp build plan` again with the same `--input` path.\n\n## 3. `planned` or `failed`\n\nOn `planned` the Build plan is written and shown to the member, who decides whether to start it: end the Turn with\n`<!-- AWAITING_APPROVAL -->` as the Journal\'s last line. On `failed` the reason is shown instead: end with\n`<!-- WORKFLOW_COMPLETE -->`.\n\n## 4. Every later wake: tick\n\nYou are woken when the member answers the approval question (with Start, or with words of their own before it) and whenever one of your child Runs closes or parks.\nEach time: read Linear again into `$DRISP_RUN_ARTIFACTS/input/plan-input.json` as in step 1 (with a new `readAt`),\nincluding full descriptions, acceptance criteria, labels and external blocker status. A scope change holds the affected issue for a fresh Build and approval. Then run:\n\n```sh\ndrisp build tick --input "$DRISP_RUN_ARTIFACTS/input/plan-input.json"\n```\n\nIt prints one JSON object. Act on its `action`, and repeat until an action ends the Turn:\n\n- `refresh_input`: read Linear into the input again (a newer `readAt`) and tick again.\n- `replan`: the member wrote words before starting, and `guidance` lists every round of them, oldest first. Plan again\n  with them as the member\'s wishes: read the issues they concern (and the repo) as in step 2, rewrite the `fill.json`\n  of each issue the guidance changes (`instructions`, `areas`, `qa`, `sizeClass`, `merge` in every fill when the\n  member says who merges, or `ownWork` to leave an issue out),\n  and run `drisp build plan` again with the same `--input` path. Then end as in step 3: with\n  `<!-- AWAITING_APPROVAL -->` on `planned`, `<!-- WORKFLOW_COMPLETE -->` on `failed`. Write nothing but those\n  `fill.json` files.\n- `repair`: for each of `issues`, read it in Linear first and skip an issue Linear now shows Done or Canceled (its\n  child got there first); otherwise move it to Done and post its `comment` verbatim through `linear`. Then read\n  Linear into the input again and tick again.\n- `rebase`: for each of `items`, in its `worktree`: `git rebase origin/main`, resolve the conflicts, then\n  `git push --force-with-lease origin <branch>` (the item\'s `branch`) if the branch is on the remote. Never push any\n  other branch. If a rebase cannot be resolved, `git rebase --abort`.\n  Then read Linear into the input again and tick again, adding `--rebase-failed <identifier>` for each that failed.\n- `wait`: end the Turn with `<!-- WAITING_ON_CHILDREN -->` as the Journal\'s last line.\n- `park`: end the Turn with `<!-- NEEDS_HUMAN: <message> -->` as the Journal\'s last line, copying `message`\n  verbatim.\n- `complete`: end the Turn with `<!-- WORKFLOW_COMPLETE -->` as the Journal\'s last line.\n\n## Rules\n\n- Never start, cancel or edit Runs, Workflows, worktrees or branches except as an action says; `drisp build` does\n  what is needed.\n- Never write to Linear except a `repair`; never open a pull request.\n- Write only `plan-input.json` and the `fill.json` files `drisp build plan` asks for. Never write `answer.json`.\n';
 
 // src/core/workflows/builtins/orchestrator/index.ts
 var ORCHESTRATOR_WORKFLOW_NAME = "orchestrator";
@@ -21472,7 +21477,7 @@ is in \`ignored\`: it does not block the merge and its name goes in the evidence
 empty, wait a minute and run it again. When \`failed\` is not empty, fix the change; if it still fails, the Merge gate
 cannot pass. Never judge a check by its timing.
 
-Immediately before merging, verify the current revision again: {mergeVerify}. If evidence is stale, rerun the
+{signOff}Immediately before merging, verify the current revision again: {mergeVerify}. If evidence is stale, rerun the
 selected validation steps and record fresh receipts before continuing.
 
 Merge with \`gh pr merge --squash --delete-branch --match-head-commit <sha>\`, where \`<sha>\` is HEAD after the last
@@ -21503,6 +21508,18 @@ Evidence. Never create issues and never edit an issue's title or description.
 
 When every gate has passed, end with \`<!-- WORKFLOW_COMPLETE -->\` as the Journal's last line.
 `;
+var MERGE_SIGN_OFF = {
+  passesWhen: "the merge gate below holds, with the member\u2019s Sign-off on HEAD",
+  section: `Sign-off: this Build's member merges, so the merge waits for their Sign-off on the exact head commit. When
+everything above holds and HEAD is pushed, end the Turn with \`<!-- NEEDS_HUMAN: {signOffText} -->\` as the Journal's
+last line, where \`<sha>\` is the full \`git rev-parse HEAD\`. The member answers in this Thread. When their reply signs
+off on that commit, record it with \`{signOffCommand}\`, which refuses any SHA but HEAD; it is your attestation of
+their reply, so never record one they did not give. Any other reply is guidance: act on it, then ask again. A
+Sign-off names one commit: after a rebase or any new commit, ask again before merging.
+When \`gh pr merge\` fails because the branch is protected, the Merge gate cannot pass.
+
+`
+};
 var STAGE_TEMPLATE = `### {n}. {title}
 
 Start: run \`{stepCommand}\`.
@@ -21584,6 +21601,7 @@ var RENDERER_RULES = {
   permissions: {
     edit: ["Edit(./**)"],
     shell: [
+      "drisp build check",
       "drisp build checks",
       "drisp build step",
       "drisp build merged",
@@ -21721,11 +21739,11 @@ function selectedGates(fill) {
   ).map(
     (gate) => fill.profile === "investigation" && gate.title === "Checks" ? {
       ...gate,
-      passesWhen: "{install}{checks} pass; each finding is supported by a source or reproducible observation and each acceptance criterion has evidence; unresolved questions are stated explicitly"
+      passesWhen: "{install}{checks} pass, each check run through `drisp build check <name> -- <command>`; each finding is supported by a source or reproducible observation and each acceptance criterion has evidence; unresolved questions are stated explicitly"
     } : fill.profile === "investigation" && gate.title === "Evidence" ? {
       ...gate,
       passesWhen: "findings and evidence for each acceptance criterion are posted on the Linear issue, with unresolved questions explicitly stated; the issue is moved to Done only when all acceptance criteria are satisfied"
-    } : gate
+    } : fill.merge === "you" && gate.title === "Merge" ? { ...gate, passesWhen: MERGE_SIGN_OFF.passesWhen } : gate
   );
   if (!usesTestFirst(fill))
     gates.splice(1, 0, {
@@ -21753,6 +21771,7 @@ var fillSlots = (template, slots) => template.replace(/\{(\w+)\}/g, (whole, key)
 function selectionFlags(fill) {
   return `${fill.profile ? ` --profile ${fill.profile}` : ""}${fill.testFirst ? ` --test-first ${fill.testFirst.enabled}` : ""}${fill.review ? ` --review ${fill.review.enabled}` : ""}`;
 }
+var mergeFlag = (fill) => fill.merge === "you" ? " --merge you" : "";
 function renderStages(fill, checks, install) {
   const gates = selectedGates(fill);
   return gates.map((gate, index) => {
@@ -21768,11 +21787,12 @@ function renderStages(fill, checks, install) {
       stepCommand: command,
       passesWhen
     });
+    const finish = `${command}${gate.title === "Merge" ? mergeFlag(fill) : ""}`;
     return stage + (["Merge", "Evidence"].includes(gate.title) ? `
 
 Before doing this step: run \`${command} --verify\`. Missing or stale evidence must be refreshed first.` : "") + `
 
-Finish: write the actual result and supporting paths to \`.athena/evidence/step-${index + 1}.md\`, then run \`${command} --complete --evidence .athena/evidence/step-${index + 1}.md\`. This records an agent attestation, not independent verification.` + (gate.cannotPass ? fillSlots(CANNOT_PASS_TEMPLATE, { cannotPass: gate.cannotPass }) : NO_GATE_TEXT_TEMPLATE);
+Finish: write the actual result and supporting paths to \`.athena/evidence/step-${index + 1}.md\`, then run \`${finish} --complete --evidence .athena/evidence/step-${index + 1}.md\`. This records an agent attestation, not independent verification.` + (gate.cannotPass ? fillSlots(CANNOT_PASS_TEMPLATE, { cannotPass: gate.cannotPass }) : NO_GATE_TEXT_TEMPLATE);
   }).join("\n\n");
 }
 function render(fill, workflowName, layout) {
@@ -21818,6 +21838,7 @@ function render(fill, workflowName, layout) {
       "Your Linear writes are In Progress in Explore, findings and evidence, and Done in Evidence."
     );
   }
+  const mergeCommand = `drisp build step ${gateTitles(fill).indexOf("Merge") + 1} --qa ${fill.qa}${selectionFlags(fill)}`;
   const workflowMd = fillSlots(template, {
     identifier: parsed.identifier,
     instructions: [
@@ -21830,7 +21851,11 @@ function render(fill, workflowName, layout) {
       )
     ].filter(Boolean).join("\n\n"),
     gates: renderStages(fill, checks, installCommand(fill, layout)),
-    mergeVerify: `\`drisp build step ${gateTitles(fill).indexOf("Merge") + 1} --qa ${fill.qa}${selectionFlags(fill)} --verify\``,
+    signOff: fill.merge === "you" ? fillSlots(MERGE_SIGN_OFF.section, {
+      signOffText: BUILD_STRINGS.mergeSignOff.replace("{sha}", "<sha>"),
+      signOffCommand: `${mergeCommand} --merge you --sign-off <sha>`
+    }) : "",
+    mergeVerify: `\`${mergeCommand}${mergeFlag(fill)} --verify\``,
     checksEvidence: checks.map((command) => `${command} \u2713`).join(" \xB7 "),
     shellCommands: checksText(shellCommands(fill))
   });
@@ -22422,6 +22447,15 @@ function budgetTokens(memory) {
   if (memory.cumulativeTokens === null) return null;
   return Math.max(0, memory.cumulativeTokens - (memory.usage?.cacheRead ?? 0));
 }
+function runUsage(memory) {
+  const counted = budgetTokens(memory);
+  if (counted === null) return null;
+  const whole = (tokens) => Number.isFinite(tokens) ? Math.min(Math.max(0, Math.round(tokens)), Number.MAX_SAFE_INTEGER) : 0;
+  return {
+    counted: whole(counted),
+    cacheRead: whole(memory.usage?.cacheRead ?? 0)
+  };
+}
 function resourceInterruption(stop) {
   const names2 = {
     tokens: "token budget",
@@ -24282,6 +24316,8 @@ function collectMcpServersWithOptions(pluginDirs) {
 export {
   WAITING_ON_CHILDREN_STOP_REASON,
   AWAITING_APPROVAL_STOP_REASON,
+  budgetTokens,
+  runUsage,
   createSteerQueue,
   DEFAULT_PERMISSION_GRACE_MS,
   serializeRunMemory,
@@ -24321,6 +24357,7 @@ export {
   DESCRIPTION_TEMPLATE,
   QA_SECTIONS,
   WORKFLOW_MD_TEMPLATE,
+  MERGE_SIGN_OFF,
   STAGE_TEMPLATE,
   CANNOT_PASS_TEMPLATE,
   NO_GATE_TEXT_TEMPLATE,
@@ -24347,4 +24384,4 @@ export {
   compileWorkflowPlan,
   collectMcpServersWithOptions
 };
-//# sourceMappingURL=chunk-HZ6GRLOM.js.map
+//# sourceMappingURL=chunk-FYXEDUQ6.js.map