SPDX-License-Identifier: AGPL-3.0-or-later¶
Commercial license available¶
© Concepts 1996–2026 Miroslav Šotek. All rights reserved.¶
© Code 2020–2026 Miroslav Šotek. All rights reserved.¶
ORCID: 0009-0009-3560-0851¶
Contact: www.anulum.li | protoscience@anulum.li¶
SCPN Quantum Control — Actions History Dashboard¶
Actions History Dashboard¶
This page documents the read-only workflow-history audit layer used to keep GitHub Actions history interpretable without deleting evidence for unresolved defects.
The audit helpers classify workflow runs only. They never cancel runs, delete runs, close issues, edit branches, or mutate GitHub state.
Dashboard commands¶
Run the full Actions history classifier:
Write the same report as JSON:
python tools/audit_github_actions_history.py \
--repo anulum/scpn-quantum-control \
--limit 500 \
--json > actions-history-audit.json
Run the Link Check history classifier:
Use a captured gh run list fixture instead of querying GitHub:
gh run list \
--repo anulum/scpn-quantum-control \
--limit 500 \
--json databaseId,conclusion,status,workflowName,headSha,headBranch,createdAt,event \
> actions-history.json
python tools/audit_github_actions_history.py --input actions-history.json
python tools/audit_link_check_history.py --input actions-history.json
Scheduled artefacts¶
The Actions History Audit workflow runs weekly and can also be triggered
manually. It uploads:
| Artefact | Meaning |
|---|---|
actions-history.json |
Raw gh run list output for the sampled history window. |
actions-history-audit.json |
Classified run history with buckets, reasons, and safe-delete candidates. |
The workflow is intentionally read-only. It uses actions: read and
contents: read permissions and uploads audit artefacts even when unresolved
history is detected.
Classification buckets¶
| Bucket | Meaning | Safe to delete? |
|---|---|---|
clean_success |
Completed successfully and retained as current evidence. | No |
in_progress |
Still running or not completed. | No |
resolved_failure |
Failed run with a later successful run for the same workflow and branch. | Candidate |
unresolved_failure |
Failed run without later successful evidence. | No |
superseded_cancelled |
Cancelled run with later successful evidence for the same workflow and branch. | Candidate |
unresolved_cancelled |
Cancelled run without later successful evidence. | No |
other_completed |
Completed with a non-standard conclusion. | No |
The Link Check helper uses the same principle, with link-specific buckets:
| Bucket | Meaning | Safe to delete? |
|---|---|---|
clean_success |
Successful Link Check evidence. | No |
resolved_link_failure |
Link Check failure followed by a later successful Link Check on the same branch. | Candidate |
live_link_failure |
Link Check failure with no later successful evidence. | No |
accepted_external_transient |
Explicitly accepted external-service failure such as rate-limit or HEAD-request blocking. | No |
superseded_cancelled |
Cancelled Link Check followed by later successful evidence. | Candidate |
unresolved_cancelled |
Cancelled Link Check without later successful evidence. | No |
Safe-delete rule¶
A failed or cancelled workflow run is only a deletion candidate when all of these are true:
- The run is completed.
- The run is classified as
resolved_failure,resolved_link_failure, orsuperseded_cancelled. - A later successful run exists for the same workflow and branch.
- The run is not the only available evidence for an unresolved defect.
- The deletion is performed manually after reviewing the audit report.
The helpers deliberately do not execute gh run delete.
Accepted external-transient Link Check failures¶
Accepted transient failures should be explicit and narrow. Use JSON like:
[
{
"databaseId": 123456789,
"reason": "External journal returned HTTP 503 to anonymous HEAD requests."
}
]
Then run:
python tools/audit_link_check_history.py \
--input actions-history.json \
--accepted accepted-link-failures.json
This keeps a visible distinction between real live link failures and external services that intermittently reject automated checks.
Release-safety boundary¶
The dashboard is a release-safety aid, not a replacement for engineering judgement. A clean dashboard means the sampled history window has no unresolved buckets under the classifier rules. It does not prove that every possible historical defect has been fixed unless the sampled window covers the entire relevant history and the latest CI/security/link-check runs are green.