Agent Diagnostic

• Investigated by reading .github/workflows/issue-triage.yml and .github/ISSUE_TEMPLATE/bug_report.yml side-by-side.
• Confirmed that GitHub issue form templates always render textarea field labels as ### (H3) headings in the submitted issue body — this is fixed GitHub platform behavior.
• The workflow regex searches for ## Agent Diagnostic (H2), which never matches a body generated by the form template.
• Verified no other workflows parse the issue body heading format — only issue-triage.yml is affected.
• Fix is in issue-triage.yml: change the regex to match ### instead of ##.

Description

Every bug report submitted via the GitHub issue form template is incorrectly flagged with state:triage-needed, even when the reporter has fully filled in the Agent Diagnostic section.

The root cause is a heading-level mismatch:

• bug_report.yml defines type: textarea with label: Agent Diagnostic. GitHub renders this as ### Agent Diagnostic (H3) in the submitted issue body — this is fixed platform behavior that cannot be overridden from the template.
• issue-triage.yml checks for the section using /## Agent Diagnostic\s*\n/ (H2). This regex never matches, so hasSubstantiveDiagnostic is always false, and every bug report is flagged.

The result: compliant reporters are told their investigation is missing, undermining trust in the triage gate and creating unnecessary noise for maintainers.

Reproduction Steps

1. Open a bug report via the GitHub issue template form UI.
2. Fill in all fields including a substantive Agent Diagnostic.
3. Submit the issue with a title starting with bug:.
4. Observe that state:triage-needed is applied and a redirect comment is posted, despite the diagnostic being present.

Environment

• Affects all bug reports submitted via the issue template form
• GitHub always renders textarea labels as ### regardless of template content

Logs

Agent diagnostic section missing or placeholder. Flagging. 

Logged on every submission, even for fully-filled issues.

Agent-First Checklist

• I pointed my agent at the repo and had it investigate this issue
• I loaded relevant skills (e.g., debug-openshell-cluster, debug-inference, openshell-cli)
• My agent could not resolve this — the diagnostic above explains why