WIP: docs: propose Actions check diagnostics and guarded reruns #122

Draft
ClaudiuSchuster wants to merge 1 commit from oss-oo/actions-check-diagnostics-20261011 into main
Owner

Request for MAMA Astra

A successful manual publication can leave the same commit's earlier failed push check unchanged. The Tisabur incident made that distinction difficult to understand: manual Publish Pages run 5 succeeded, but the original push run 2 still represented its pre-publication configuration failure. Repeating the original native job as attempt 2 completed successfully and updated the actual push check.

This draft proposes a clear explanation of those execution contexts and a carefully bounded recovery action. The incident is resolved. The feature remains a design request, and the evidence does not establish a cache defect or that the affected publication check was configured as a required merge gate.

Proposed behavior

  • Explain the authoritative repository, commit, workflow, job, trigger and attempt behind each check, with current policy and source/environment limits stated separately.
  • Show relevant later executions without promoting a manual success into a push or required check.
  • Ship read-only diagnosis first. Add a guarded rerun only after the server-side identity, permission, CSRF, expected-attempt and outcome contracts are implemented.
  • Before a rerun, disclose whole-job execution, affected dependents, possible cancellation and run-wide artifact invalidation. Never repeat a publication automatically to refresh a status display.
  • Preserve historical attempts and observe the actual resulting job, commit status and policy evaluation separately.

Included documentation

The self-contained handoff lives in docs/handoffs/2026-10-11-actions-check-diagnostics/:

  • README and complete technical specification.
  • Acceptance matrix for classification, evidence binding, permissions, races and native integration.
  • Sanitized incident evidence and immutable references to the observed native source contracts.

Implementation belongs in the Laboratory's own reviewed application lineage, pinned to the selected migration source. Any upstream submission requires a separate owner decision. No application code, workflow, deployment, branch protection or commit-status mutation is included in this PR.

Review and validation

  • Read the current repository instructions and the account-switcher lineage policy against main eec894206eb5c6c8f8d1bbca20d5b805b4173302.
  • Reconciled the specification with the saved native source, observed API contract and completed Tisabur attempts; incorporated an independent source review of trigger separation and rerun effects.
  • Checked companion-file links, JSON validity, local document consistency and the sanitized evidence boundary.
  • No feature implementation or runtime tests are claimed. The acceptance matrix defines the required future tests; existing runtime gates apply when implementation changes arrive.

Decisions before implementation

MAMA Astra: please assess these three points against the exact migration target before moving this request out of draft:

  1. Which trusted native association identifies the job and attempt that produced a status, including ambiguous legacy records?
  2. Which native metadata or reviewed workflow profile establishes source and environment identity without exposing secret configuration?
  3. Where should the atomic expected-attempt transition and recoverable operation receipt integrate with the native rerun transaction and existing authorization paths?

The read-only explanation can be delivered independently of the guarded action. Separate security findings and private assessment material are outside this draft.

## Request for MAMA Astra A successful manual publication can leave the same commit's earlier failed push check unchanged. The Tisabur incident made that distinction difficult to understand: manual Publish Pages run 5 succeeded, but the original push run 2 still represented its pre-publication configuration failure. Repeating the original native job as attempt 2 completed successfully and updated the actual push check. This draft proposes a clear explanation of those execution contexts and a carefully bounded recovery action. The incident is resolved. The feature remains a design request, and the evidence does not establish a cache defect or that the affected publication check was configured as a required merge gate. ## Proposed behavior - Explain the authoritative repository, commit, workflow, job, trigger and attempt behind each check, with current policy and source/environment limits stated separately. - Show relevant later executions without promoting a manual success into a push or required check. - Ship read-only diagnosis first. Add a guarded rerun only after the server-side identity, permission, CSRF, expected-attempt and outcome contracts are implemented. - Before a rerun, disclose whole-job execution, affected dependents, possible cancellation and run-wide artifact invalidation. Never repeat a publication automatically to refresh a status display. - Preserve historical attempts and observe the actual resulting job, commit status and policy evaluation separately. ## Included documentation The self-contained handoff lives in `docs/handoffs/2026-10-11-actions-check-diagnostics/`: - README and complete technical specification. - Acceptance matrix for classification, evidence binding, permissions, races and native integration. - Sanitized incident evidence and immutable references to the observed native source contracts. Implementation belongs in the Laboratory's own reviewed application lineage, pinned to the selected migration source. Any upstream submission requires a separate owner decision. No application code, workflow, deployment, branch protection or commit-status mutation is included in this PR. ## Review and validation - Read the current repository instructions and the account-switcher lineage policy against main `eec894206eb5c6c8f8d1bbca20d5b805b4173302`. - Reconciled the specification with the saved native source, observed API contract and completed Tisabur attempts; incorporated an independent source review of trigger separation and rerun effects. - Checked companion-file links, JSON validity, local document consistency and the sanitized evidence boundary. - No feature implementation or runtime tests are claimed. The acceptance matrix defines the required future tests; existing runtime gates apply when implementation changes arrive. ## Decisions before implementation MAMA Astra: please assess these three points against the exact migration target before moving this request out of draft: 1. Which trusted native association identifies the job and attempt that produced a status, including ambiguous legacy records? 2. Which native metadata or reviewed workflow profile establishes source and environment identity without exposing secret configuration? 3. Where should the atomic expected-attempt transition and recoverable operation receipt integrate with the native rerun transaction and existing authorization paths? The read-only explanation can be delivered independently of the guarded action. Separate security findings and private assessment material are outside this draft.
docs: propose Actions check diagnostics and guarded reruns
All checks were successful
ci / ci (pull_request) Successful in 1m29s
e50762a47e
Prepared by Codex for MAMA Astra from reviewed local commit 473fad0e76304a8ea5d80961af740cfec010c918. Documentation-only feature handoff; four files; no runtime or deployment changes.
All checks were successful
ci / ci (pull_request) Successful in 1m29s
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin oss-oo/actions-check-diagnostics-20261011:oss-oo/actions-check-diagnostics-20261011
git switch oss-oo/actions-check-diagnostics-20261011
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
OSS-OO/laboratory!122
No description provided.