feat(feedback): send each kind to its survey, fill a bug's version info, and point to issues when telemetry is off

[theCodeDrift]

Stack (root → tip):

• docs(openspec): propose feedback-channels #477
  • feat(feedback): key surveys by kind and discriminate the payload on it #478
    • ➡️ feat(feedback): send each kind to its survey, fill a bug's version info, and point to issues when telemetry is off #479 (you are here)
      • feat(agent): add the feedback and bug-report recipes, and rename the invited survey's recipe to rule-feedback #480
        • feat(skill): route feedback and bug reports to their recipes #481
          • docs(openspec): archive feedback-channels #482

• The CLI answers a bug report's "Version Information" question itself, from local state only: the CLI version, the installed scaffold version, the rules reconciliation marker, the platform and the Node version. There is no login, email, org, repository URL or path in it, and no network call.
• Only a rule send advances the invite cadence. General feedback and bug reports leave it alone.
• With telemetry off, send still validates first, then sends nothing and names https://github.com/taskless/cli/issues.

This stack lands with gh stack merge, which merges every PR to main in one all-or-nothing operation, so no layer reaches main on its own. That matters because the layers only work together. For example, #478 requires kind on the payload while the recipe the invite names still describes a single survey, and #480 lists bug-report in the index before the skill routes to it.

[theCodeDrift]

@claude /review

[github-actions]

Claude finished @theCodeDrift's task in 2m 18s —— View job

---

Review complete

Review mode: incremental — read 0 prior review thread(s) before reviewing. .prior-review.json contains only the trigger comment (@claude /review) with no reviews or reviewThreads entries, so this is the first review of this PR — there is nothing previously-raised to carry forward or mark addressed.

• Read .prior-review.json (empty — first review)
• Fetch PR diff and metadata (gh pr diff, gh pr view)
• Read changed files in full context (feedback.ts, survey/constants.ts, schemas/feedback.ts, filesystem/manifest.ts, survey/cadence.ts)
• Review packages/cli/src/commands/feedback.ts changes
• Review packages/cli/test/feedback-command.test.ts changes
• Review openspec/changes/feedback-channels/tasks.md changes
• Post inline comments for concrete findings (none found — see below)
• Post final summary

Assessment: no new findings. I read the full diff plus the surrounding context it depends on (SURVEYS/FEEDBACK_KINDS in survey/constants.ts, the discriminated inputSchema in schemas/feedback.ts, readManifest/TasklessManifest in filesystem/manifest.ts, and cadence.ts) and didn't find a correctness, security, performance, or test-adequacy issue:

• bugVersionInformation reads the manifest from join(cwd, TASKLESS_DIRECTORY), matching the established pattern in commands/info.ts; it swallows both the ENOENT case (readRawManifest already resolves that to {version:0, raw:{}}) and a genuinely unreadable/corrupt manifest (the unreadableManifest CLIError) via the same .then(success, () => null) idiom used elsewhere, so a broken .taskless/taskless.json degrades the report to the three CLI-only lines rather than failing the send — matches the stated contract.
• The answer is built from __VERSION__, process.platform/arch/version, and the two manifest fields only — no login, email, org, path, or network call, as the docstring and task 2.1 require.
• buildSurveyResponse's new cliAnswer parameter only affects a question whose key is undefined, which today is only the bug survey's version-information question, so general/rule sends are unaffected by the new parameter.
• Cadence (writeNextAsk) is now gated on input.kind === "rule" exactly, matching task 2.2 and verified by the new "leaves the cadence alone" test for both general and bug.
• The telemetry-off path for send (SEND_DISABLED) now runs for all three kinds, after validation and before any manifest read or capture — so an invalid payload is still rejected before the opt-out is checked, and no unnecessary FS read happens when telemetry is off. ISSUES_URL is exported once and reused in the message and the test, so there's a single source of truth for it.
• Test coverage is thorough: per-kind survey id routing, cadence isolation for general/bug, version info present with and without a .taskless/ manifest, confirmation that no other kind receives the version-info key, opt-out behavior parametrized across all three kinds, and the missing-kind rejection path. I didn't find a gap worth adding.
• tasks.md just checks off 2.1–2.3, consistent with what's implemented.

Nothing here depends on file history (blame/log), so the "file history is the one real gap" caveat doesn't bite for this diff — everything was decidable from the diff plus current file contents.
(branch)