docs(issue-tracker): require --type on issue creation; reconcile Related scope

[kyle-sexton]

No related issue: rule additions decided on melodic-software/medley#1623 and melodic-software/claude-code-plugins#975

Summary

• Adds the rule that CLI/agent issue creation always passes --type with one of the org's enabled native types (Task/Bug/Feature); the web-UI issue form already surfaces the Types field so that path can't skip it. Placed in conventions/process/issue-tracker.md's existing "The type axis" section.
• Corrects an existing claim in that same paragraph beyond the two dictated edits: the doc asserted a no:type search qualifier exists to find untyped issues. Empirically disproved against the live org (org:melodic-software is:issue is:open no:type returned the unfiltered total of 336, identical to the query with no no:type clause at all — GitHub silently drops the unrecognized qualifier rather than erroring). Replaced with an accurate description: search exposes a positive type:"Bug"-style qualifier per enabled type but no negation for "untyped"; finding the untyped remainder means comparing per-type counts against the total, or reading an issue's type field (null when unset).
• Reconciles the ## Related PR-section requirement from requires-ci-scoped phrasing ("became the org-wide rule when the shared pr-issue-linkage gate generalized it to every requires-ci repository") to the fleet-wide convention locked in claude-code-plugins#975's Q12 decision — the practice applies org- and account-wide by convention even where no CI gate exists to check it mechanically (e.g. songwriting, knowledge-corpus). Preserves the one-line historical note that it began as provisioning's stricter convention (decisions log fix(lychee): exclude private constellation repos from the online lane #58/feat(dotnet): enable NuGet lock files in the overlay #59).

Related

• melodic-software/medley#1623
• pull-request skill: pre-create gate must verify non-empty '## Related' section claude-code-plugins#975
• Program: PR convention policy-as-data — one policy file, one validator, thin CI runners, plugin mechanism #173

🤖 Generated with Claude Code

KNOWN ISSUE: hosted CI may fail 0-step/2s (billing) — environmental, note and continue.

[claude]

Claude finished @kyle-sexton's task in 1m 30s —— View job

---

PR Review

• Gather context (PR diff, changed file, REVIEW.md)
• Read changed file in full
• Review for correctness, consistency, and alignment with project guidelines
• Post findings

---

One changed file: conventions/process/issue-tracker.md. Three distinct changes — a factual correction to the no:type claim, a new --type enforcement rule, and a scope expansion for the ## Related requirement. The "always check" blockers in REVIEW.md are all infrastructure/security concerns that don't apply to a prose-only documentation change.

Overall verdict: looks good. The no:type correction is grounded in empirical evidence (explained in the PR body), the new rule is clear and actionable, and the ## Related scope change is consistent with a fleet-wide decision. Two minor nits below.

---

🟡 Nit 1 — | inside a code span looks like shell pipe syntax

conventions/process/issue-tracker.md line 28

`gh issue create --type Task|Bug|Feature`

In a backtick span, | reads as a shell pipe, not a choice separator. A reader skimming the snippet might parse this as three piped commands. The intent is to list the three valid values. Conventional metasyntax for "choose one" is angle brackets: `gh issue create --type <Task|Bug|Feature>`, or the alternatives can be listed in surrounding prose with the command shown without the values.

---

🟡 Nit 2 — "can't skip it" may be stronger than warranted

conventions/process/issue-tracker.md line 28

the web UI's issue form already surfaces the Types field, so that path can't skip it

"Can't skip it" implies the field is enforced/required on the form. If the field is surfaced but still optional (no required-field validation on the web form), a user who clears the selector can still submit without a type. The weaker phrasing "is unlikely to skip it" or "surfaces the Types field as a first-class input, reducing the risk of an unset type" matches the actual guarantee more precisely. If the org has configured the field as required on the form, a parenthetical confirming that would make the strong claim defensible. Fix this →

---

No other findings. The no:type fix is accurate and well-explained. The fleet-wide ## Related restatement is correct and the historical preservation of decisions log #58/#59 plus the pr-issue-linkage gate note is clean.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 28f227c7ca

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[kyle-sexton]

🔒 babysit-prs lane claiming this PR for on-branch fix work this cycle (amendment-round: 16, safe tier). Will fix clear branch-owned findings and push; will not resolve threads or merge (safe tier). Releasing claim implicitly once this cycle's cadence report posts.

[claude]

Claude finished @kyle-sexton's task in 2m 8s —— View job

---

PR Review — Amendment Round

• Gather context (PR diff, changed file)
• Check if previous nits were addressed
• Prepare fixes
• Attempt push (blocked — permissions)

---

Both nits from the prior review are still present in the current file. I prepared the fix locally but the push was denied (403 — github-actions[bot] lacks write access to this repo). Applying manually is straightforward:

File: conventions/process/issue-tracker.md, line 28

-**Issue creation always sets the type.** CLI and agent-driven issue creation passes `--type` with one of the org's enabled native types (`gh issue create --type Task|Bug|Feature`); the web UI's issue form already surfaces the Types field, so that path can't skip it.
+**Issue creation always sets the type.** CLI and agent-driven issue creation passes `--type` with one of the org's enabled native types (`gh issue create --type <Task|Bug|Feature>`); the web UI's issue form already surfaces the Types field as a first-class input, making it unlikely that path skips it.

Two changes in one line:

1. Task|Bug|Feature → <Task|Bug|Feature> — angle-bracket metasyntax makes clear | is a choice separator, not a shell pipe.
2. so that path can't skip it → making it unlikely that path skips it — the paragraph above already notes GitHub does not require the type field; the stronger claim contradicted that. (If the org has configured the Types field as required on the web form, the stronger phrasing is defensible — a parenthetical to that effect would settle it.)

No other findings. The no:type empirical correction and the fleet-wide ## Related restatement are both clean.

[claude]

Claude finished @kyle-sexton's task in 1m 17s —— View job

---

PR Amendment Review

• Gather context and read changed file
• Check whether prior nits were addressed in commit 4ebdc5b
• Review current diff for any remaining issues

---

Both nits from the prior review round are resolved in commit 4ebdc5b:

Nit 1 — shell-hostile | in code span: Resolved. The example was rewritten to \gh issue create --type Task`with the alternatives(or `Bug`/`Feature`, whichever applies)` in surrounding prose. A concrete single-value example is cleaner than any metasyntax would be.

Nit 2 — "can't skip it" overclaim: Resolved, and resolved more accurately than the suggested softening. Rather than hedging to "unlikely to skip it," the new text states the fact plainly: "GitHub does not force it to be filled in there either; setting it is this policy's requirement, not something the platform enforces on either path." This is internally consistent with the paragraph above it (which already explains that GitHub doesn't require a type) and more useful to the reader than a hedged probability claim.

Both Codex P2 findings are also addressed by the same edits.

No remaining findings. The three substantive changes in this PR — the no:type empirical correction, the new --type enforcement rule, and the fleet-wide ## Related scope expansion — are all accurate, internally consistent, and well-placed.