bash, npm install, node) renders bold and runner scaffolding (systemd, hosted-compute-agent, Runner.Listener, Runner.Worker) renders italic. All job folds start collapsed — the tree above is shown expanded for illustration.
The headline
The first content line is invariant — See what ran — every outbound connection and its process lineage. — byte-identical on every PR comment. It is the one full-contrast line; everything that follows is the record.The provenance line
Quoted under the headline: Runtime behavior for jobs triggered by commitsha · recorded at the kernel · 2026-07-13 23:54:23 UTC. The sha names the commit that triggered the recorded jobs and links to it; recorded at the kernel names the vantage point (the eBPF sensor, not log-scraping); the timestamp is the recorded profile’s own timestamp — always absolute UTC (YYYY-MM-DD HH:MM:SS UTC), never the renderer’s clock. When more than one profile is recorded it reads recorded at the kernel through <latest profile timestamp>. The word recorded appears exactly once on this line.
The explainer
The 💡 Reading this review fold teaches the notation with a mini process-to-destination example: each job fold connects recorded process lineage to recorded outbound destinations; bold lineage is attributed to a GitHub step belowRunner.Worker, italic lineage is runner scaffolding. Typography only shows attribution context — it is never a security claim. The explainer is open on the first recorded result and collapsed on later updates.
The jobs-count line
One thin line between the quoted preamble and the first fold: N jobs recorded on this commit. It counts what is recorded and nothing else — it never reads k of n and never carries a denominator. The job list speaks for itself.Job folds
Each recorded job is one fold, headed by its provenance and its counts:- The
workflow / jobbreadcrumb follows GitHub’s own containment model and always names both — even when only one workflow is recorded. - The job name carries the link: it points to the job’s GitHub Actions run, the page holding its log and Step Summary. There is no separate run number in the heading — the run’s identity lives in the link.
- The counts are countable from the tree inside:
Nis the distinct recorded process identities (lineage + PID + process),Mis the destination lines visible in the fold — resolver rows included; notes never subtract. The heading is a caption for the tree and never contradicts it. - All data-bearing folds start collapsed, ordered by workflow then job name.
The process tree
The expanded tree is the recorded lineage, unfiltered. The record is egress-centric: processes without recorded egress do not appear.
The comment is domain-first: no ports, protocols, address annotations, or
[pid · process] suffixes render here — that fidelity lives on the Garnet Runtime Summary.
Factual notes
A destination carries an italic parenthetical only for structural facts the record proves. The set is closed:
Everything else renders exactly as recorded, untagged. Notes never filter, subtract, or alter counts.
Zero-egress jobs
A job whose record carries no outbound destinations renders as one quiet line instead of a tree:The per-fold permalink
Each fold closes with exactly one Garnet link, pinned right: View Run Profile in Garnet ↗. It opens the job’s full record on the public run report —app.garnet.ai/public/runs/<run-id>?profile=<profile-id> — selected on the job’s own Garnet Profile ID. It is the only Garnet link in the comment: no top run-index link, no bottom footer, no “Powered by Garnet”. The GitHub Actions link lives on the job name in the heading.
Report visibility follows the repository’s visibility on GitHub: public repository ⇒ public report; private repository ⇒ the link requires signing in to the project. The ?profile= selector is exact — a wrong or missing profile ID returns a 404, never a silent fallback.