feat(feedback): key surveys by kind and discriminate the payload on it

[theCodeDrift]

Stack (root → tip):

• docs(openspec): propose feedback-channels #477
  • ➡️ feat(feedback): key surveys by kind and discriminate the payload on it #478 (you are here)
    • feat(feedback): send each kind to its survey, fill a bug's version info, and point to issues when telemetry is off #479
      • 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

• survey/constants.ts holds the three surveys in one registry keyed by kind. RULE_SURVEY_ID names the invited survey wherever the invite, the cadence and dismiss refer to it.
• schemas/feedback.ts is a z.discriminatedUnion("kind", …) of strict objects, and each declares kind as a required literal with no default. A missing or unknown kind fails naming kind. A key belonging to another kind fails naming that key.
• buildSurveyResponse maps each payload through the survey its kind selects.

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 3m 47s —— View job

---

Review mode: incremental — read 0 prior review thread(s) before reviewing.

.prior-review.json contained no reviewThreads, reviews, or comments beyond the @claude /review trigger itself, so this is the first review of this PR. Everything below is assessed fresh against the full diff.

Summary

This PR restructures the survey machinery from one flat survey to a SURVEYS registry keyed by kind, and turns schemas/feedback.ts into a z.discriminatedUnion("kind", …) of three strict branches (rule/general/bug). The mechanical rename (SURVEY_ID/SURVEY_QUESTIONS → RULE_SURVEY_ID/SURVEYS) is applied consistently across invite.ts, cadence call sites, and every test file I checked — no stray references to the old names remain anywhere in packages/cli. The new schema's strictness, discriminator wiring, and test coverage (missing/unknown kind, cross-kind key rejection, per-branch JSON Schema const) all line up correctly with what openspec/changes/feedback-channels/design.md and tasks.md describe for task group 1, which is the scope this PR covers.

Two things worth a look, posted inline:

1. packages/cli/src/commands/feedback.ts:142 — sendCommand unconditionally advances the rule survey's cadence (writeNextAsk(RULE_SURVEY_ID, …)) regardless of the payload's kind. Since this PR's own schema change is what makes a general/bug payload constructible, sending one today would incorrectly suppress the next rule-survey invite. This tracks task 2.2 in tasks.md (still unchecked), so it reads as deliberately sequenced into a later PR in the stack — flagging so it's confirmed to land before the stack reaches main.
2. packages/cli/src/survey/constants.ts:29 — the doc comment cites bugVersionInformation in commands/feedback.ts, which doesn't exist yet anywhere in the repo (task 2.1, also unchecked). Stated in the present tense, it reads as if the function already exists. Minor, but worth tense-shifting or deferring the comment to the PR that adds it.

I also checked the cross-PR concern the PR description itself calls out — agent/feedback.md still only describes the rule branch (no mention of kind in its prose or steps), while the schema it embeds via TOPIC_INPUT_SCHEMAS now requires kind: "rule". That's exactly the gap the PR body already names ("the recipe the invite names still describes a single survey"), scheduled for task 3.1's rename/rewrite later in the stack, so I'm not re-raising it as a new finding — just confirming it's real and already tracked.

No security, performance, or test-adequacy concerns beyond the above. The new test files (feedback-schema.test.ts, feedback-command.test.ts, survey-cadence.test.ts) exercise the new discriminated branches, the strict-object rejection paths, and the bug/general $survey_id mapping with good specificity.

[theCodeDrift]

Re: @github-actions — "Claude finished @theCodeDrift's task in 3m 47s"
#478 (comment)

Both inline findings (rule-cadence gating on kind, and bugVersionInformation) are implemented in #479 and land with this stack atomically; replied on each thread. No change in this layer.

— AI Coding Agent