Docs: add a laptop feedback issue form

[mrsabath]

What & why

Part of #977. A user running Cortex on their laptop had no structured way to report a problem or say what was confusing. This adds a GitHub issue form, Laptop feedback, so that feedback arrives with the context that makes it actionable.

The repository had no .github/ISSUE_TEMPLATE/ directory yet, so this creates it with one form. GitHub keeps the blank-issue option available alongside it.

The form

Fields chosen to match the "what to attach to a bug report" list already in the laptop troubleshooting docs:

• Kind of feedback (confusing / did not work / numbers / suggestion).
• What happened and what you expected.
• OS and architecture (uname -sm) — required.
• Agent and model.
• Cortex version (abctl --version).
• Service status and log (abctl service status), with a note to remove secrets.
• Whether another tool (git, gh, ssh, curl) broke.

Where it connects

• The abctl footer feedback link (feature: abctl observe — show a feedback/next-steps link in the footer #975, PR Feat: abctl footer shows a feedback link #978) points at rossoctl/cortex/issues, which surfaces this form.
• The docs give an end-of-page "give feedback" prompt that links here — a companion PR in rossoctl/rossoctl (part of the same docs: add a laptop feedback path — issue template and an end-of-page 'give feedback' call #977).

Note on verification

The repo's YAML lint and the check-yaml pre-commit hook validate issue forms in CI. The sandbox this was authored in has no local YAML validator, so structure was reviewed by hand against GitHub's issue-form schema. Please let CI confirm the form parses before merge; opened as a draft for that reason.

Checklist

• DCO sign-off; Assisted-By trailer
• Capitalized PR title prefix (Docs:)
• YAML lint / issue-form parse confirmed in CI (blocks leaving draft)

Assisted-By: Claude (Anthropic AI) noreply@anthropic.com

[coderabbitai]

Warning

Review limit reached

Next included review available in 59 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 6a4b0ef2-f2a5-432e-9675-a8884a6ba705

📥 Commits

Reviewing files that changed from the base of the PR and between 6b0022e and c3faf68.

📒 Files selected for processing (1)

• .github/ISSUE_TEMPLATE/laptop-feedback.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[huang195]

Dobra — the form itself is well built, and I mean that. The fields map onto what the troubleshooting docs already ask people to attach, uname -sm and abctl --version are the two things you genuinely need and cannot guess, the "remove any secret before you paste" note sits on the one field that will contain one, and the git/gh/ssh/curl checkbox is a sharp bit of instinct — that is the failure mode a proxy-installing tool creates and nobody thinks to ask about.

I read it against GitHub's issue-form schema line by line and it should parse: the markdown block carries no id/validations (both forbidden there), dropdown has label + options with required: true, checkboxes correctly puts required inside the option rather than beside it, all seven ids are unique, every type is valid, and render: text is an accepted Linguist language.

Now the part where I get to be a friend rather than a rubber stamp. Your verification note says "The repo's YAML lint and the check-yaml pre-commit hook validate issue forms in CI" — they do not. Both check that the file is well-formed YAML, which it is, and neither knows anything about GitHub's issue-form schema. GitHub validates that server-side, and only once the file is on the default branch; an invalid form surfaces as a config error in the chooser, never as a red check. So "issue-form parse confirmed in CI (blocks leaving draft)" cannot be ticked by CI — and the PR is not in draft anyway.

The honest pre-merge checks are the ones I ran: read it against the schema, then verify that everything it references actually exists. SECURITY.md is there (1,639 bytes on main), so that carve-out is not a 404. The labels were not, which is the inline comment below.

And a nice knock-on: this makes the suggestion on #978 worth taking — with a form in place, pointing the footer at /issues/new/choose lands people here rather than on a list of everyone else's bugs.

[huang195]

suggestion — Mariusz, neither of these labels exists. I asked the API for both:

GET /repos/rossoctl/cortex/labels/feedback  → 404
GET /repos/rossoctl/cortex/labels/laptop    → 404

GitHub will not create them for you; it quietly does not apply them. So the one part of this form that exists purely for triage becomes decoration, and the first feedback issue arrives naked with someone labelling it by hand forever after.

gh label create feedback and gh label create laptop before merge, or drop the key until they exist — either is fine, just not the current state. This is also precisely the class of problem no CI check here can see, which is why it is worth a minute now.

[huang195]

nit — this is now the only structured option in the chooser, and it is laptop-specific. Someone reporting an operator bug or a Helm problem meets "Laptop feedback" or "blank issue" and has to guess which one you meant.

One clause in this markdown block — "for anything that is not about running Cortex on your own machine, open a blank issue" — costs nothing and saves you re-filing. A config.yml with an explicit blank_issues_enabled: true would also pin the behaviour your description relies on, rather than inheriting it as a default someone can flip later.