Module gha 

GitHub Actions workflow-command output emitter.

Emits findings as ::warning file=...,line=...,title=...::message workflow commands directly to stdout. When run inside a GitHub Actions job, the runner intercepts these and surfaces each finding as an inline annotation on the pull-request diff — same surface Code Scanning uses, but without uploading SARIF (no permissions, no API call, no upload step).

Spec: https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions

Three severity levels map to three commands:

• HIGH → ::error::
• MEDIUM → ::warning::
• LOW → ::notice::

Mapping is deliberately tight — hotspot scores in (7, 10] are error-level (top-decile churn × complexity), (4, 7] are warning, everything else is notice. Threshold tuning happens behind the --workflow-command-floor flag if user pull demands it.

Escaping

GitHub’s parser is brittle around :, ,, \r, \n, and % in property values + messages. The official escape sequences are:

Char	Escape
%	%25
\r	%0D
\n	%0A
:	%3A (in property values only)
,	%2C (in property values only)

Property values get the full set; the trailing message body only needs % / \r / \n escaped (colons + commas pass through, which is why the bare message is the last field).

Why not gate this on GITHUB_ACTIONS=true?

Users can pipe a non-GHA shell into tee + redirect to a runner — defensively gating would surprise them. The emitter prints workflow commands unconditionally; runners outside Actions see them as plain text lines, which is the expected fallback.

Functions

write_gate_violations_gha

Emit quality-gate violations (codelore check) as GitHub Actions error annotations, so a failing gate shows up inline on the PR rather than only as a red check. File-anchored violations annotate that file; the gate evaluators wrap synthetic, non-file scopes in parens ((repo-wide), (diff-summary)) — those get a file-less ::error that still surfaces in the run’s annotation summary.

write_hotspots_gha

Emit hotspot rows as GitHub Actions workflow commands.