Route agents to gusto feedback on friction and raw api calls

[azrosen92]

What

Routes agents to the existing gusto feedback command at two high-signal moments via a stderr-only nudge (the stdout JSON envelope stays byte-identical):

• friction — any command failure that emits an error envelope (API 4xx/5xx, validation/blocked_on, insufficient_scope, not_implemented, internal_error, and --fields usage errors).
• escape_hatch — every gusto api request, success or failure (reaching for the raw escape hatch is a command-gap signal).

Also:

• Fixes --category discoverability: it now uses commander .choices(), so an invalid value is rejected at parse time and the four valid values (bug, feature_request, general, praise) appear in --help. The nudge depends on this.
• Adds a feedback_nudge config key (tri-state, modeled on skills_auto_install) to opt out, and a per-category 24h throttle stored in a separate state file (atomic write, best-effort — never fails the command).

Why

gusto feedback works but was discoverable only via --help, so an agent that hit a gap had no idea the channel existed and the signal was lost. These are the two moments most worth capturing.

Guardrails

• No PII: the auto-populated --context is a strict allowlist — command slug, exit code, error code, request id, CLI version, environment, trigger. It never includes the response body, error.details, or any employee/admin identifier.
• Suppressed on: gusto feedback itself, gusto config, gusto auth login, confirmation_required (a working guardrail, not friction), and --dry-run.
• The emitted agent-mode command is copy-paste-safe (the --context argument is shell-escaped).

Testing

Unit tests cover fires/suppression per trigger, byte-identical stdout, the PII allowlist, throttle + opt-out, and --category parse-time rejection. typecheck + lint + format + DCO checks pass.

Related: AINT-805. Touches runner.ts alongside the command-header PR — whichever merges second needs a trivial rebase.

🤖 Generated with Claude Code

[boostsecurity-io-ai]

⚠️  1 New Security Finding

The latest commit contains 1 new security finding.

Findings Note: 1 finding is displayed as an inline comment.

Not a finding? Ignore it by adding a comment on the line with just the word noboost.

Scanner: boostsecurity - Semgrep

[boostsecurity-io-ai]

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Original Rule ID: rules-javascript-xss-generic

Details

The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

The application passes unsanitized user input to dangerous DOM manipulation methods
or HTTP response functions that can lead to Cross-Site Scripting (XSS). This rule
detects data flowing from untrusted sources like req.query, req.body, location.href,
document.querySelector().value, and function arguments into sensitive sinks including
innerHTML, outerHTML, document.write(), document.writeln(), jQuery methods
like $.html(), $.append(), and Express response methods like res.send(). These
sinks render content directly into the DOM or HTTP responses without automatic escaping.
When user-controlled data flows through these paths, attackers can inject malicious
JavaScript that executes in the victim's browser, potentially stealing session cookies,
accessing local storage, hijacking user accounts, or performing unauthorized API calls.
This vulnerability affects both DOM-based XSS (client-side sources like URL fragments),
reflected XSS (server-echoed input), and stored XSS (persisted malicious content).
 📘 Learn More

AI Remediation

This is a false positive: the stderr.write sink is a Node.js CLI stderr stream (a terminal/pipe), not an HTML DOM node or HTTP response, so no browser-side script execution can occur. The fields values are the command's own output-data object keys rendered as plain terminal text, which is never interpreted as HTML/JS, so CWE-79 (XSS) does not apply here.

At line 215, do the following changes:

 /** Print the gh-style "you must specify fields" hint to stderr, listing what's available. */
 function writeFieldsHint(fields: string[], deps: RunnerDeps): void {
   const stderr = deps.sinks?.stderr ?? process.stderr;
-  stderr.write(`Specify one or more comma-separated fields for \`--fields\`:\n${fieldLines(fields)}\n`);
+  stderr.write(`Specify one or more comma-separated fields for \`--fields\`:\n${fieldLines(fields)}\n`); // noboost
 }
 
 export function notImplementedHandler(commandPath: string): CommandHandler {

[jeff-gusto]

Parse-time failures never reach this tail. main() catches CommanderError and emits the standard error envelope directly, so unknown commands/options, missing positional arguments, and invalid .choices() values produce no friction nudge. That leaves part of the advertised "any command failure that emits an error envelope" behavior uncovered. Could the top-level Commander error path call the same nudge logic (while preserving the command suppressions)?

[jeff-gusto]

The runner only learns that this was a dry-run when a successful result explicitly carries dryRun: true, but most existing dry-run paths do not set that marker. For example, putResourceWithVersion returns a normal { ok: true, data } preview. Combining one of those previews with an invalid --fields selection makes the runner synthesize unknown_fields and emit a nudge even though --dry-run was passed. Errors returned before a preview short-circuit cannot carry this success-only marker either. Could invocation-level dry-run state be passed to the runner, or all applicable result paths be marked consistently?