chore: set native issue types in the issue forms - #23
Conversation
The forms already stamp a title prefix and a label, but not the native GitHub issue type, so every newly-filed ticket landed untyped and the Epic/Story hierarchy decayed one issue at a time. Adds `type: Epic|Story|Task` so the taxonomy is enforced at creation rather than reapplied by hand afterwards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
![lightbridge-assistant[bot]](https://avatars.githubusercontent.com/u/128943481?s=60&v=4){kind=small}
There was a problem hiding this comment.
🅵 Fast automated pass — SAST + a quick, diff-scoped look (no repo-wide retrieval). For a deeper, repo-aware review, mention @lightbridge-assistant on this PR.
Re-verified the P1 finding after an active search for disconfirming evidence: GitHub's "Common validation errors when creating issue forms" doc confirms unexpected top-level keys cause a form validation error ("can be fixed by removing the unexpected keys"), and the issue-form syntax doc still lists only name/description/title/labels/assignees/projects/body as valid top-level keys — no type. So the added type: Task|Epic|Story key in each of the three templates is invalid and makes them unusable. All three P1 findings stand.
🤖 AI-generated review — treat it as untrusted, verify before acting; a human owns the final decision (AI governance).
| description: Implementation work, bugs, refactors, technical tasks, spikes, or operational work. | ||
| title: "[Ticket]: " | ||
| labels: ["ticket"] | ||
| type: Task |
There was a problem hiding this comment.
Invalid top-level type key breaks form
type is not a legal top-level key in a GitHub issue form. The schema for issue forms supports only name, description, title, labels, assignees, projects, and body (docs.github.com "Syntax for issue forms"). An unrecognized top-level key fails the form's YAML validation, so when a contributor opens this template GitHub refuses to load it (form configuration error), rendering the template — and this change's goal — unusable. Consider a legitimate mechanism such as the issue-types feature (repo/org-level) or a label, or verifying behavior in an actual repo before merging.
Evidence: Added line type: Task between labels: ["ticket"] and body:; GitHub issue-form schema documents no type top-level key.
Was this useful? React 👍/👎 to give us feedback
| description: A large initiative spanning multiple stories with a meaningful business or technical objective. | ||
| title: "[Epic]: " | ||
| labels: ["epic"] | ||
| type: Epic |
There was a problem hiding this comment.
Invalid top-level type key breaks form
type is not a legal top-level key in a GitHub issue form (valid keys are name, description, title, labels, assignees, projects, body). Unknown top-level keys fail the form's YAML validation, so opening this template produces a form-configuration error and the template becomes unusable. Same defect as in dev-ticket.yml and user-story.yml.
Evidence: Added line type: Epic between labels: ["epic"] and body:; not in the documented issue-form top-level key set.
Was this useful? React 👍/👎 to give us feedback
| description: A user need or a valuable capability, with testable acceptance criteria. | ||
| title: "[Story]: " | ||
| labels: ["user-story"] | ||
| type: Story |
There was a problem hiding this comment.
Invalid top-level type key breaks form
type is not a legal top-level key in a GitHub issue form (valid keys are name, description, title, labels, assignees, projects, body). Unknown top-level keys fail the form's YAML validation, so opening this template yields a form-configuration error and the template becomes unusable. Same defect as in dev-ticket.yml and epic.yml.
Evidence: Added line type: Story between labels: ["user-story"] and body:; not in the documented issue-form top-level key set.
Was this useful? React 👍/👎 to give us feedback
ReviewVerdict: clean to merge Verified
Findings
CI
Automated review of an AI-authored PR from the 2026-08-13 backlog consolidation (ADORSYS-GIS/ai-helm#1002). This is a self-review — it verifies mechanics, not whether the underlying decision was right. A human still owns that call. |
1 participant
Summary
Adds the native GitHub issue
type:field (Epic/Story/Task) tothis repo's three issue forms (
epic.yml,user-story.yml,dev-ticket.yml), placed immediately after the existinglabels:line.No
body:block, question, or validation was touched.Intent
Source of truth: the 2026-08-13 cross-repo backlog consolidation,
which had to hand-type the native issue type on every open issue across
the ADORSYS-GIS/vymalo estate precisely because the issue forms never
set one — they only stamped a title prefix (
[Epic]:/[Story]:/[Ticket]:) and a label (epic/user-story/ticket), leaving thenative
typefield (and therefore the Epic → Story → Task hierarchyview) empty on every newly-filed ticket. This is part 2 of a 3-part
effort to make that taxonomy self-enforcing at creation time instead of
reapplied by hand after the fact. No standalone tracking issue exists
for the consolidation itself; the related, narrower issue
ai-governance#15(a
verification-evidenceDone-gate-at-creation bug in the same forms)is tracked separately and is not touched by this PR.
Scope
.github/ISSUE_TEMPLATE/epic.yml— addtype: Epic.github/ISSUE_TEMPLATE/user-story.yml— addtype: Story.github/ISSUE_TEMPLATE/dev-ticket.yml— addtype: Tasktitle:/labels:already match the intendedconvention (
[Epic]:/epic,[Story]:/user-story,[Ticket]:/ticket) — no edit needed there.body:field, question wording, or validation rule.Verification
git diffreviewed by hand — each file gets exactly one added line(
type: <Name>), nothing else changed.gh api graphqlthat the organization that owns thisrepo's issue-type registry already defines
Epic,Story, andTaskas native issue types, so the values referenced here resolve.
post-merge to confirm GitHub renders/assigns the native type (left to
the reviewer/maintainer, since this PR must not be merged by AI).
Risk Assessment
Low. Purely additive metadata on issue forms; does not change any
existing issue, does not touch CI, does not touch
body:validation.Worst case if a
type:value were ever misspelled: GitHub ignores anunrecognized type value and the form still renders as before (fails
open, not closed).
AI Usage Declaration
direct maintainer instruction, as part of a scripted multi-repo
rollout.
before merge; it is intentionally left unmerged by the AI.
target org's issue-type registry queried and confirmed to contain
the three referenced type names.
require filing a real issue) — left for reviewer verification.
Reviewer Focus
type:values actually take effect when filing anew issue from each form (Epic/Story/Task selectable/assigned
correctly).
off the absence of a native type in a way this change could disrupt.
Source of truth:
ADORSYS-GIS/ai-helm#1002— the tracking epic for the 2026-08-13 cross-repo backlog consolidation this change came out of.