clud-bug 0.6.16 → 0.6.18

package/bin/clud-bug.js

@@ -76,6 +76,9 @@ Commands:
                         rate, 30-day rolling \$/LOC trend, per-repo/per-model
                         distributions, and outliers (> 2x org median).
                         Use --pr / --repo / --since / --limit / --json to filter.
+  eval                  Run the golden-set regression gate against the rendered review
+                        prompt (must-contain / must-not-contain / byte-budget). Same as
+                        \`node --test test/prompts.eval.test.js\` but works from any cwd.
 
 Options:
   --offline             Skip skills.sh; pin only the bundled baseline specimens.
@@ -126,12 +129,30 @@ async function main() {
     case 'update':  return runUpdateCmd(args);
     case 'edit-workflow': return runEditWorkflow(args);
     case 'usage':   return runUsage(args);
+    case 'eval':    return runEval();
     default:
       process.stderr.write(`Unknown command: ${cmd || '(none)'}\n\n${HELP}`);
       process.exit(2);
   }
 }
 
+// 0.0.E (v0.6.17): thin wrapper around the golden-set test file. Devs
+// who follow the README invoke `clud-bug eval` — this routes to the
+// same `node --test` runner CI uses, so dev and CI verdicts match.
+//
+// Dev-only: runs against the prompt bundled in PKG_ROOT (the cloned
+// clud-bug repo). `test/` is intentionally not in package.json `files`,
+// so invoking this from a globally installed copy will ENOENT. No args
+// supported yet — the README does not advertise any.
+async function runEval() {
+  const result = spawnSync(
+    'node',
+    ['--test', join(PKG_ROOT, 'test/prompts.eval.test.js')],
+    { stdio: 'inherit' },
+  );
+  process.exit(result.status ?? 1);
+}
+
 async function runInit(args) {
   const cwd = process.cwd();
   log(`🐛 Field season opens in ${cwd}.`);

package/lib/prompts.js

@@ -119,8 +119,35 @@ size discipline on those fetches pays back directly.
     comments — the FIX-PUSH FLOW handles those via reviewThreads
     GraphQL instead.
 
-If you genuinely cannot review safely without the elided content,
-say so plainly in the summary comment instead of speculating.
+Tee-hint on cap fire (v0.6.18, RTK-inspired):
+When ANY \`head -c "$MAX_*"\` cap fires (last line cut mid-token, or
+\`wc -c\` on the captured output equals the cap exactly), you MUST do
+two things, in order:
+
+  1. Attempt ONE targeted re-fetch with double the cap on the specific
+     truncated section. Example for diff: \`gh pr diff "$PR_NUMBER" |
+     head -c $((MAX_DIFF_BYTES * 2))\`. For skills: re-fetch the
+     specific \`.claude/skills/<name>/SKILL.md\` that hit the cap with
+     \`head -c $((MAX_SKILL_BYTES * 2))\` — name the file. For
+     comments: re-fetch with \`per_page=40\` AND \`head -c
+     $((MAX_COMMENT_BYTES * 2))\` — doubling per_page alone is wasted
+     work when the original truncation was byte-bound.
+
+  2. Add a \`### Diagnostics\` block above the Skills-referenced
+     footer (the \`<!-- last-reviewed-sha: ... -->\` marker still goes
+     last on its own line — Diagnostics is not the last thing in the
+     comment). Each line names a cap that fired, the section affected,
+     and the outcome of the re-fetch (e.g. "still truncated",
+     "recovered with 2x cap", "finding deferred — content beyond 2x").
+
+This makes truncation an auditable event in the review trail instead
+of a silent confidence reduction. The pattern is the producer-side
+half of RTK's \`force_tee_tail_hint\`: never elide without naming what
+was elided.
+
+If after the re-fetch you genuinely cannot review safely without the
+still-elided content, say so plainly in the summary comment instead
+of speculating.
 
 Skills are not background context — they are review rules with
 authority. Before flagging any finding, scan the loaded skills in

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "clud-bug",
-  "version": "0.6.16",
+  "version": "0.6.18",
   "description": "Skill-driven Claude PR review. Ship a brand-voice skill, get brand reviews. Each finding cites the skill that motivated it. CLI installs the workflow + a baseline kit; add more from skills.sh.",
   "homepage": "https://cludbug.dev",
   "bugs": "https://github.com/thrillmade/clud-bug/issues",

package/templates/workflow-py.yml.tmpl

@@ -156,6 +156,6 @@ jobs:
       # Strict-mode gate — composite action; see workflow.yml.tmpl for design notes.
       - name: Strict mode — fail check on critical findings
         if: success()
-        uses: thrillmade/clud-bug/.github/actions/strict-mode-gate@v0.6.16
+        uses: thrillmade/clud-bug/.github/actions/strict-mode-gate@v0.6.18
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}

package/templates/workflow-ts.yml.tmpl

@@ -156,6 +156,6 @@ jobs:
       # Strict-mode gate — composite action; see workflow.yml.tmpl for design notes.
       - name: Strict mode — fail check on critical findings
         if: success()
-        uses: thrillmade/clud-bug/.github/actions/strict-mode-gate@v0.6.16
+        uses: thrillmade/clud-bug/.github/actions/strict-mode-gate@v0.6.18
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}

package/templates/workflow.yml.tmpl

@@ -247,6 +247,6 @@ jobs:
       # Letting the action's own failure fail the check is louder and right.
       - name: Strict mode — fail check on critical findings
         if: success()
-        uses: thrillmade/clud-bug/.github/actions/strict-mode-gate@v0.6.16
+        uses: thrillmade/clud-bug/.github/actions/strict-mode-gate@v0.6.18
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}