@harness-engineering/cli 1.24.3 → 1.25.0

package/dist/agents/skills/gemini-cli/harness-git-workflow/SKILL.md

@@ -139,7 +139,14 @@ git branch -d <branch-name>
 ```bash
 cd <worktree-path>
 git push -u origin <branch-name>
-gh pr create --title "<title>" --body "<description>"
+gh pr create --title "<title>" --body "$(cat <<'EOF'
+## Summary
+<PR body with real newlines — never use \n escape sequences>
+
+## Test plan
+<checklist>
+EOF
+)"
 # Report the PR URL to the user
 # Leave worktree in place until PR is merged
 ```
@@ -158,6 +165,14 @@ git worktree remove <worktree-path>
 git branch -D <branch-name>
 ```
 
+#### Step 3.5: Cross-Reference Conventions for Commit Messages and PR Bodies
+
+GitHub auto-links any `#N` token in commit messages, PR titles, and PR bodies to the issue or PR with that number. Treat `#N` as a reserved sigil — never use it for non-issue references.
+
+- **Do not** use `#N` for proposal success criteria, list ordinals, footnote refs, table rows, or any other in-document numbering. Write "criterion 9", "item 9", "step 3" instead. Using `#9` to mean "criterion 9" will silently cross-reference issue #9 — which is almost certainly an unrelated issue — and add a misleading back-reference to that issue's timeline.
+- **Do** reference the actual roadmap/tracker issue when finishing work tied to one. Use `Refs #<issue>` for context-only links and `Closes #<issue>` / `Fixes #<issue>` only when the merge should auto-close that issue.
+- **Before pushing or opening the PR**, scan the commit messages and PR body for stray `#N` tokens. For each one, confirm it points to the intended issue/PR — or rewrite it as plain text.
+
 #### Step 4: Clean Up
 
 1. **Remove the worktree** (unless keeping as-is or waiting for PR merge):
@@ -192,13 +207,14 @@ git branch -D <branch-name>
 
 ## Rationalizations to Reject
 
-| Rationalization                                                                                                                                       | Reality                                                                                                                                                                                                                                                        |
-| ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| "The tests are probably fine on the fresh branch — they were passing on main when I last checked. I'll skip baseline verification and start working." | Baseline verification is the condition that makes branch work trustworthy. A test failure discovered at finish time is ambiguous — it could be pre-existing or introduced by the work. Skipping baseline removes the only clean comparison point.              |
-| "The user said 'just merge it' — I'll merge without checking if the base branch has advanced since the worktree was created."                         | The pre-finish check for base branch divergence is mandatory before any finishing strategy. Merging without rebasing first can produce a merge that silently breaks tests that were passing on the branch but conflict with new commits on main.               |
-| "The worktree directory isn't gitignored, but it's inside a nested folder that's unlikely to be committed accidentally."                              | The `.gitignore` check is not about likelihood — it is about preventing accidental commits of worktree state that would corrupt the repository. If the worktree directory is not gitignored, add it before creating the worktree. No exceptions.               |
-| "The user chose to discard — I'll delete the branch and worktree immediately without showing the commits that will be lost."                          | The discard path requires showing the commit list from `git log main..HEAD --oneline` and receiving explicit confirmation before running `git worktree remove` and `git branch -D`. Work is being permanently deleted; the user must see what they are losing. |
-| "There's already a worktree for this branch at a different path — I'll create a second one since the user asked for a fresh setup."                   | Git does not allow two worktrees checked out to the same branch. Attempting to create a duplicate will fail. Instead, ask the user whether to use the existing worktree or create a new branch. Never assume a second worktree is the right answer.            |
+| Rationalization                                                                                                                                       | Reality                                                                                                                                                                                                                                                                                     |
+| ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "The tests are probably fine on the fresh branch — they were passing on main when I last checked. I'll skip baseline verification and start working." | Baseline verification is the condition that makes branch work trustworthy. A test failure discovered at finish time is ambiguous — it could be pre-existing or introduced by the work. Skipping baseline removes the only clean comparison point.                                           |
+| "The user said 'just merge it' — I'll merge without checking if the base branch has advanced since the worktree was created."                         | The pre-finish check for base branch divergence is mandatory before any finishing strategy. Merging without rebasing first can produce a merge that silently breaks tests that were passing on the branch but conflict with new commits on main.                                            |
+| "The worktree directory isn't gitignored, but it's inside a nested folder that's unlikely to be committed accidentally."                              | The `.gitignore` check is not about likelihood — it is about preventing accidental commits of worktree state that would corrupt the repository. If the worktree directory is not gitignored, add it before creating the worktree. No exceptions.                                            |
+| "The user chose to discard — I'll delete the branch and worktree immediately without showing the commits that will be lost."                          | The discard path requires showing the commit list from `git log main..HEAD --oneline` and receiving explicit confirmation before running `git worktree remove` and `git branch -D`. Work is being permanently deleted; the user must see what they are losing.                              |
+| "There's already a worktree for this branch at a different path — I'll create a second one since the user asked for a fresh setup."                   | Git does not allow two worktrees checked out to the same branch. Attempting to create a duplicate will fail. Instead, ask the user whether to use the existing worktree or create a new branch. Never assume a second worktree is the right answer.                                         |
+| "I'll use `#9` in the commit message to refer to 'success criterion 9' in the proposal — it's obviously an in-document reference."                    | `#N` is GitHub's reserved syntax for issue/PR links in commits and PR bodies. It will auto-link to issue/PR #9 regardless of intent and post a misleading back-reference on that unrelated issue. Write "criterion 9" (no `#`) and cite the real roadmap issue separately with `Refs #<n>`. |
 
 ## Examples
 
@@ -251,9 +267,14 @@ npm test                # still passes after rebase
 
 # User chooses: Push and create PR
 git push -u origin feat/notifications
-gh pr create --title "feat(notifications): email and in-app notifications" \
-  --body "Implements notification service with create, list, and expiry.
-  16 new tests. All passing."
+gh pr create --title "feat(notifications): email and in-app notifications" --body "$(cat <<'EOF'
+## Summary
+Implements notification service with create, list, and expiry.
+
+## Test plan
+- [x] 16 new tests, all passing
+EOF
+)"
 
 # Report: "PR created: https://github.com/org/repo/pull/42
 #  Worktree at .worktrees/notifications kept until PR merges."

package/dist/agents/skills/gemini-cli/harness-planning/SKILL.md

@@ -61,6 +61,22 @@ Work backward from the goal. Start with "what must be true when we are done?"
 4. **Identify key links.** How do artifacts connect? What imports what? What calls what?
 5. **Apply YAGNI.** For every artifact: "Is this required for an observable truth?" If not, cut it.
 
+6. **Surface uncertainties.** Before proceeding to Phase 2, explicitly list what you do NOT know. For each uncertainty, classify it:
+   - **Blocking:** Cannot decompose tasks without resolving this. Escalate to user.
+   - **Assumption:** Can proceed with a stated assumption. Document it. If wrong, specific tasks will need revision.
+   - **Deferrable:** Does not affect task decomposition. Note for execution phase.
+
+   Format:
+
+   ```
+   ## Uncertainties
+   - [BLOCKING] How should the API handle partial failures? (Spec does not define.)
+   - [ASSUMPTION] Database supports transactions. (If not, Task 3 needs redesign.)
+   - [DEFERRABLE] Exact error message wording. (Can be finalized during implementation.)
+   ```
+
+   **Read-only constraint:** Steps 1-5 above are research and analysis. Do not propose task structure, file organization, or implementation approaches during SCOPE. Record what must be true (observable truths) and what you do not know (uncertainties). Solutions belong in DECOMPOSE.
+
    When scope is ambiguous, use `emit_interaction`:
 
    ```json
@@ -335,6 +351,8 @@ Only apply when modifying existing documented behavior. When `docs/changes/` exi
 | "Tests for this task can be added in a follow-up task since the implementation is straightforward"            | No skipping TDD in tasks. Every code-producing task must start with writing a test. "Add tests later" is explicitly forbidden.                                          |
 | "The spec does not cover this edge case, but I can fill in the gap during planning"                           | When the spec is missing information, do not fill in the gaps yourself. Escalate. Filling gaps silently creates undocumented design decisions that no one reviewed.     |
 | "I discovered we need an additional file during decomposition, but updating the file map is just bookkeeping" | The file map must be complete. Every file that will be created or modified must appear in the file map before task decomposition.                                       |
+| "There are no real uncertainties — the spec is clear enough"                                                  | Every plan has unknowns. If you listed zero uncertainties, you skipped the step. Re-read the spec and list what is assumed but not stated.                              |
+| "I already know how to structure this, no need to finish scoping"                                             | Premature decomposition anchors on the first approach found. Complete SCOPE (observable truths + uncertainties) before proposing any task structure.                    |
 
 ## Examples
 
@@ -399,6 +417,7 @@ Files: src/types/notification.ts
 - **No plan without observable truths.** Must start with goal-backward acceptance criteria.
 - **No implementation during planning.** Write the plan, get approval, then use harness-execution.
 - **File map must be complete.** Every file to create or modify must appear before task decomposition.
+- **Uncertainties must be surfaced.** Phase 1 must produce an uncertainties list. Zero uncertainties means the step was skipped. Blocking uncertainties must be resolved before Phase 2.
 
 ## Escalation
 

package/dist/agents/skills/gemini-cli/harness-skill-authoring/SKILL.md

@@ -273,6 +273,40 @@ metadata: # Provenance and authorship metadata
 
 3. **Test by running the skill:** `harness skill run <name>`. Verify it loads correctly and the process instructions make sense in context.
 
+### Phase 5B: TDD FOR SKILLS — Test Before Signing Off
+
+Apply test-driven thinking to skill authoring. A skill is not complete until it has been tested against scenarios that exercise its discipline sections.
+
+1. **Write a test scenario.** Before declaring the skill complete, define 2-3 concrete scenarios that should trigger the skill's discipline mechanisms:
+   - One scenario that should trigger a Red Flag (if the skill has Red Flags)
+   - One scenario that should trigger a Rationalization rejection
+   - One scenario that should trigger a Gate (for rigid skills)
+
+   ```markdown
+   ## Skill Test Scenarios
+
+   ### Scenario 1: Red Flag — [quoted phrase from Red Flags section]
+
+   Input: [describe the situation]
+   Expected: Agent stops, cites the Red Flag, and takes corrective action
+
+   ### Scenario 2: Rationalization — [quoted phrase from Rationalizations section]
+
+   Input: [describe the tempting shortcut]
+   Expected: Agent rejects the rationalization and follows the prescribed process
+
+   ### Scenario 3: Gate — [gate condition]
+
+   Input: [describe a state that violates the gate]
+   Expected: Agent halts and does not proceed past the gate
+   ```
+
+2. **Mentally execute each scenario.** Walk through the skill's process with the test input. Does the skill's prose clearly direct the agent to the correct behavior? If not, the skill needs revision — not the test.
+
+3. **Check for gaps.** If you cannot construct a scenario that triggers a discipline section, the section may be too abstract. Revise it to include a concrete quoted phrase or condition.
+
+4. **Document test scenarios** in a comment block at the end of SKILL.md or in a companion `tests.md` file. These serve as regression tests for future skill edits.
+
 ### Skill Quality Checklist
 
 Evaluate every skill along two dimensions:
@@ -312,13 +346,14 @@ Use this checklist as a final quality gate before declaring a skill complete.
 
 ## Rationalizations to Reject
 
-| Rationalization                                                         | Reality                                                                                                                                  |
-| ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
-| "This skill is too simple to need all required sections"                | Every section exists for a reason. A short section is fine; a missing section means the skill was not fully thought through.             |
-| "The process section covers it — no need for explicit success criteria" | Process describes what to do. Success criteria describe how to know it worked. They serve different purposes.                            |
-| "Rationalizations to Reject is meta — this skill does not need it"      | This section is required for all user-facing skills, including this one. No exceptions.                                                  |
-| "I will add examples later once the skill is proven"                    | Examples are a required section. A skill without examples forces the agent to guess at correct behavior. Write at least one example now. |
-| "The When to Use section is obvious from the name"                      | Negative conditions (when NOT to use) prevent misapplication. The skill name conveys nothing about boundary conditions.                  |
+| Rationalization                                                         | Reality                                                                                                                                                                                                  |
+| ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| "This skill is too simple to need all required sections"                | Every section exists for a reason. A short section is fine; a missing section means the skill was not fully thought through.                                                                             |
+| "The process section covers it — no need for explicit success criteria" | Process describes what to do. Success criteria describe how to know it worked. They serve different purposes.                                                                                            |
+| "Rationalizations to Reject is meta — this skill does not need it"      | This section is required for all user-facing skills, including this one. No exceptions.                                                                                                                  |
+| "I will add examples later once the skill is proven"                    | Examples are a required section. A skill without examples forces the agent to guess at correct behavior. Write at least one example now.                                                                 |
+| "The When to Use section is obvious from the name"                      | Negative conditions (when NOT to use) prevent misapplication. The skill name conveys nothing about boundary conditions.                                                                                  |
+| "The skill works — I tested it by running it once"                      | A single happy-path run does not test discipline sections. Write scenarios that trigger Red Flags, Gates, and Rationalizations. A skill that passes happy path but fails discipline scenarios is a trap. |
 
 ## Examples
 

package/dist/agents/skills/gemini-cli/harness-verification/SKILL.md

@@ -259,6 +259,31 @@ Every verification claim MUST use one of:
 
 **Uncited claims:** Any verification assertion without direct evidence is a verification failure. This skill does not use `[UNVERIFIED]` -- if evidence cannot be produced, verdict is FAIL or INCOMPLETE.
 
+## Rubric Compression
+
+Verification checklists passed to subagents or used internally MUST use compressed single-line format. Each check is one line with pipe-delimited fields:
+
+```
+level|check-name|pass-criterion
+```
+
+**Example (Level 2 SUBSTANTIVE rubric):**
+
+```
+L2|no-stubs|No TODO/FIXME/throw-not-implemented in production code
+L2|no-empty-bodies|No empty function bodies, () => {}, or return null as sole logic
+L2|spec-complete|All behaviors specified in spec have corresponding implementation
+L2|real-logic|Functions contain meaningful logic, not just hardcoded returns
+```
+
+**Why:** Verbose checklist prose inflates verification context without improving accuracy. Dense single-line rubrics give the same signal in fewer tokens, leaving more budget for reading and analyzing actual file content.
+
+**Rules:**
+
+- Level prefix must be L1 (EXISTS), L2 (SUBSTANTIVE), or L3 (WIRED)
+- Maximum 80 characters per criterion text
+- Rubric entries are guidance — the verification levels define the authoritative checks
+
 ## Non-Determinism Tolerance
 
 Mechanical checks (tests, lint, types) are binary pass/fail. No tolerance.

package/dist/agents-md-MCUM4SIZ.js

@@ -0,0 +1,10 @@
+import {
+  generateAgentsMd
+} from "./chunk-5BQ5BOJL.js";
+import "./chunk-MI6MA6OP.js";
+import "./chunk-RL4VMEXL.js";
+import "./chunk-K2SON7TI.js";
+import "./chunk-KFQGP6VL.js";
+export {
+  generateAgentsMd
+};

package/dist/{architecture-FBSLURIB.js → architecture-HNIO6AUX.js}

@@ -1,13 +1,14 @@
 import {
   checkDependenciesDefinition,
   handleCheckDependencies
-} from "./chunk-A737JDL4.js";
-import "./chunk-Q3XYV5UC.js";
+} from "./chunk-CXJTVICF.js";
+import "./chunk-47N6R2F4.js";
 import "./chunk-EPUKTTJZ.js";
 import "./chunk-W6Y7ZW3Y.js";
-import "./chunk-H4U2QNY2.js";
-import "./chunk-5LMZA5LZ.js";
-import "./chunk-OZIHPMA7.js";
+import "./chunk-MI6MA6OP.js";
+import "./chunk-RL4VMEXL.js";
+import "./chunk-K2SON7TI.js";
+import "./chunk-KFQGP6VL.js";
 export {
   checkDependenciesDefinition,
   handleCheckDependencies

package/dist/{assess-project-74UVWPMB.js → assess-project-6MV5TNY3.js}

@@ -1,8 +1,9 @@
 import {
   assessProjectDefinition,
   handleAssessProject
-} from "./chunk-FJYP32IV.js";
+} from "./chunk-UQZBZINS.js";
 import "./chunk-W6Y7ZW3Y.js";
+import "./chunk-KFQGP6VL.js";
 export {
   assessProjectDefinition,
   handleAssessProject

package/dist/bin/harness-mcp.js

@@ -1,28 +1,29 @@
 #!/usr/bin/env node
 import {
   startServer
-} from "../chunk-O6UF33QH.js";
-import "../chunk-YPKKEP3O.js";
-import "../chunk-UFQQBGC3.js";
-import "../chunk-L5UONZ53.js";
-import "../chunk-FJYP32IV.js";
-import "../chunk-WEN5Z7CL.js";
-import "../chunk-A737JDL4.js";
-import "../chunk-Q3XYV5UC.js";
-import "../chunk-TB427QOK.js";
-import "../chunk-V2FGX2KD.js";
-import "../chunk-3VYWO6QN.js";
+} from "../chunk-RX7TUMBR.js";
+import "../chunk-FES2YEQU.js";
+import "../chunk-UV3BZMGT.js";
+import "../chunk-F23H3U5U.js";
+import "../chunk-UQZBZINS.js";
+import "../chunk-YTP2UDPV.js";
+import "../chunk-CXJTVICF.js";
+import "../chunk-47N6R2F4.js";
+import "../chunk-GEEYCQDS.js";
+import "../chunk-M55DGGF3.js";
+import "../chunk-TYV4EUAD.js";
 import "../chunk-EPUKTTJZ.js";
 import "../chunk-W6Y7ZW3Y.js";
-import "../chunk-5PMRARB5.js";
+import "../chunk-WIQA4BSH.js";
 import "../chunk-3ISINLYT.js";
 import "../chunk-6B6UN6SG.js";
-import "../chunk-TDLOFNNQ.js";
-import "../chunk-H4U2QNY2.js";
-import "../chunk-5LMZA5LZ.js";
-import "../chunk-OZIHPMA7.js";
-import "../chunk-ZOVATVQC.js";
+import "../chunk-BOQRTARD.js";
+import "../chunk-MI6MA6OP.js";
+import "../chunk-RL4VMEXL.js";
+import "../chunk-K2SON7TI.js";
+import "../chunk-HIK6OEUF.js";
 import "../chunk-3WGJMBKH.js";
+import "../chunk-KFQGP6VL.js";
 
 // src/bin/harness-mcp.ts
 import "dotenv/config";

package/dist/bin/harness.js

@@ -2,66 +2,69 @@
 import {
   createProgram,
   printFirstRunWelcome
-} from "../chunk-ZAMT24QN.js";
-import "../chunk-I4QR3HNH.js";
-import "../chunk-LOUH2LIC.js";
-import "../chunk-LVYPPKZI.js";
-import "../chunk-FP53DDB5.js";
+} from "../chunk-AZT567I6.js";
+import "../chunk-5BQ5BOJL.js";
+import "../chunk-EHRZMOQ2.js";
+import "../chunk-XTITAVUR.js";
+import "../chunk-FSNPBT74.js";
 import "../chunk-CQ553GZO.js";
-import "../chunk-LM5Z2WCA.js";
+import "../chunk-6VZQJ5CX.js";
 import "../chunk-GISMXMVL.js";
-import "../chunk-UQEUYRBP.js";
+import "../chunk-WWACIIBA.js";
 import "../chunk-TEFCFC4H.js";
-import "../chunk-SPTKLCKC.js";
-import "../chunk-NV4FPO7J.js";
+import "../chunk-FIQL2HND.js";
+import "../chunk-AT74HEQM.js";
 import "../chunk-KET4QQZB.js";
-import "../chunk-YDRB55Q4.js";
-import "../chunk-3XAPHB2Z.js";
+import "../chunk-P7PANON5.js";
+import "../chunk-4NK7Z3BP.js";
 import {
   dispatchSkillsFromGit
-} from "../chunk-O6UF33QH.js";
-import "../chunk-YPKKEP3O.js";
-import "../chunk-UFQQBGC3.js";
-import "../chunk-L5UONZ53.js";
-import "../chunk-FJYP32IV.js";
-import "../chunk-WEN5Z7CL.js";
-import "../chunk-A737JDL4.js";
-import "../chunk-Q3XYV5UC.js";
-import "../chunk-TB427QOK.js";
-import "../chunk-V2FGX2KD.js";
-import "../chunk-3VYWO6QN.js";
+} from "../chunk-RX7TUMBR.js";
+import "../chunk-FES2YEQU.js";
+import "../chunk-UV3BZMGT.js";
+import "../chunk-F23H3U5U.js";
+import "../chunk-UQZBZINS.js";
+import "../chunk-YTP2UDPV.js";
+import "../chunk-CXJTVICF.js";
+import "../chunk-47N6R2F4.js";
+import "../chunk-GEEYCQDS.js";
+import "../chunk-M55DGGF3.js";
+import "../chunk-TYV4EUAD.js";
 import "../chunk-EPUKTTJZ.js";
 import "../chunk-W6Y7ZW3Y.js";
 import {
   findConfigFile,
   loadConfig
-} from "../chunk-5PMRARB5.js";
+} from "../chunk-WIQA4BSH.js";
 import "../chunk-3ISINLYT.js";
 import "../chunk-6B6UN6SG.js";
-import "../chunk-TDLOFNNQ.js";
+import "../chunk-BOQRTARD.js";
 import {
   CLI_VERSION
 } from "../chunk-BM3PWGXQ.js";
 import {
   getUpdateNotification,
+  init_dist,
   isUpdateCheckEnabled,
   readCheckState,
   shouldRunCheck,
   spawnBackgroundCheck
-} from "../chunk-H4U2QNY2.js";
-import "../chunk-5LMZA5LZ.js";
-import "../chunk-OZIHPMA7.js";
-import "../chunk-XNEMDKV5.js";
+} from "../chunk-MI6MA6OP.js";
+import "../chunk-RL4VMEXL.js";
+import "../chunk-K2SON7TI.js";
+import "../chunk-RRHUCDRD.js";
 import "../chunk-EBJQ6N4M.js";
-import "../chunk-ZOVATVQC.js";
+import "../chunk-HIK6OEUF.js";
 import {
   handleError
 } from "../chunk-3WGJMBKH.js";
+import "../chunk-KFQGP6VL.js";
 
 // src/bin/harness.ts
 import "dotenv/config";
 
 // src/bin/update-check-hooks.ts
+init_dist();
 var DEFAULT_INTERVAL_MS = 864e5;
 var cachedConfigInterval = null;
 function readConfigInterval() {
@@ -115,6 +118,17 @@ import { execSync } from "child_process";
 import fs from "fs";
 import path from "path";
 var LAST_HEAD_FILE = ".harness/dispatch-last-head.txt";
+function resolveGitRoot(projectPath) {
+  try {
+    return execSync("git rev-parse --show-toplevel", {
+      cwd: projectPath,
+      encoding: "utf8",
+      stdio: ["pipe", "pipe", "pipe"]
+    }).trim();
+  } catch {
+    return path.resolve(projectPath);
+  }
+}
 function getCurrentHead(projectPath) {
   try {
     return execSync("git rev-parse HEAD", {
@@ -127,7 +141,8 @@ function getCurrentHead(projectPath) {
   }
 }
 function readLastHead(projectPath) {
-  const filePath = path.join(projectPath, LAST_HEAD_FILE);
+  const root = resolveGitRoot(projectPath);
+  const filePath = path.join(root, LAST_HEAD_FILE);
   try {
     return fs.readFileSync(filePath, "utf8").trim();
   } catch {
@@ -135,7 +150,8 @@ function readLastHead(projectPath) {
   }
 }
 function writeLastHead(projectPath, head) {
-  const filePath = path.join(projectPath, LAST_HEAD_FILE);
+  const root = resolveGitRoot(projectPath);
+  const filePath = path.join(root, LAST_HEAD_FILE);
   const dir = path.dirname(filePath);
   if (!fs.existsSync(dir)) {
     fs.mkdirSync(dir, { recursive: true });

package/dist/{check-phase-gate-WY6UICCL.js → check-phase-gate-VCBQHQAC.js}

@@ -1,13 +1,14 @@
 import {
   createCheckPhaseGateCommand,
   runCheckPhaseGate
-} from "./chunk-SPTKLCKC.js";
-import "./chunk-5PMRARB5.js";
-import "./chunk-H4U2QNY2.js";
-import "./chunk-5LMZA5LZ.js";
-import "./chunk-OZIHPMA7.js";
+} from "./chunk-FIQL2HND.js";
+import "./chunk-WIQA4BSH.js";
+import "./chunk-MI6MA6OP.js";
+import "./chunk-RL4VMEXL.js";
+import "./chunk-K2SON7TI.js";
 import "./chunk-EBJQ6N4M.js";
 import "./chunk-3WGJMBKH.js";
+import "./chunk-KFQGP6VL.js";
 export {
   createCheckPhaseGateCommand,
   runCheckPhaseGate

package/dist/{chunk-Q3XYV5UC.js → chunk-47N6R2F4.js}

@@ -1,9 +1,13 @@
+import {
+  init_dist
+} from "./chunk-MI6MA6OP.js";
 import {
   Err,
   Ok
-} from "./chunk-5LMZA5LZ.js";
+} from "./chunk-RL4VMEXL.js";
 
 // src/mcp/utils/config-resolver.ts
+init_dist();
 import * as fs from "fs";
 import * as path from "path";
 function resolveProjectConfig(projectPath) {

package/dist/{chunk-3XAPHB2Z.js → chunk-4NK7Z3BP.js}

@@ -2,7 +2,7 @@
 import { Command } from "commander";
 import * as path from "path";
 async function runScan(projectPath) {
-  const { GraphStore, CodeIngestor, TopologicalLinker, KnowledgeIngestor, GitIngestor } = await import("./dist-QW5G3GX3.js");
+  const { GraphStore, CodeIngestor, TopologicalLinker, KnowledgeIngestor, GitIngestor } = await import("./dist-RADHOOXG.js");
   const store = new GraphStore();
   const start = Date.now();
   await new CodeIngestor(store).ingest(projectPath);

package/dist/{chunk-I4QR3HNH.js → chunk-5BQ5BOJL.js}

@@ -1,9 +1,13 @@
+import {
+  init_dist
+} from "./chunk-MI6MA6OP.js";
 import {
   Err,
   Ok
-} from "./chunk-5LMZA5LZ.js";
+} from "./chunk-RL4VMEXL.js";
 
 // src/persona/generators/agents-md.ts
+init_dist();
 function formatPrTrigger(trigger) {
   const paths = trigger.conditions?.paths?.join(", ") ?? "all files";
   return `On PR (${paths})`;

package/dist/{chunk-LM5Z2WCA.js → chunk-6VZQJ5CX.js}

@@ -1,12 +1,16 @@
 import {
   toKebabCase
 } from "./chunk-KET4QQZB.js";
+import {
+  init_dist
+} from "./chunk-MI6MA6OP.js";
 import {
   Err,
   Ok
-} from "./chunk-5LMZA5LZ.js";
+} from "./chunk-RL4VMEXL.js";
 
 // src/persona/generators/runtime.ts
+init_dist();
 function generateRuntime(persona) {
   try {
     const config = {

package/dist/{chunk-NV4FPO7J.js → chunk-AT74HEQM.js}

@@ -4,7 +4,7 @@ import {
 import {
   listPersonas,
   loadPersona
-} from "./chunk-YDRB55Q4.js";
+} from "./chunk-P7PANON5.js";
 import {
   GENERATED_HEADER_AGENT,
   VALID_PLATFORMS,