[Fleet incident] Detect and disable orphaned one-shot GitHub workflows

[seonghobae]

Live fleet finding

The GitHub Actions workflow registry currently reports 42 active workflows for ContextualWisdomLab/appguardrail, including multiple temporary one-shot identities such as:

• apply-dashboard-pluralization-once.yml;
• finalize-opencode-commercial-loop-once.yml;
• harden-opencode-commercial-loop-once.yml through harden-opencode-commercial-loop-v6-once.yml;
• apply-pinned-https-integration-once.yml;
• harden-pinned-https-cli-once.yml.

Fresh contents-API reads against the current default branch develop return 404 Not Found for sampled paths including finalize-opencode-commercial-loop-once.yml, apply-dashboard-pluralization-once.yml, and harden-opencode-commercial-loop-v6-once.yml. The source files were removed, but their GitHub Actions registry entries still report state: active.

The current scheduled Commercial Readiness Loop itself is healthy: protected-default-branch run 31586926814 completed and correctly stopped with action=wait-prs for the live PR queue. This issue is therefore not a request to change that production loop.

Root cause

Temporary writer workflows were removed from Git history after use, but workflow lifecycle cleanup treated source deletion as sufficient. GitHub retains workflow registry identities independently; source removal did not disable the registered workflow records. Existing repository tests focus on file contents and cannot detect an orphan identity whose file is no longer present.

This creates:

• misleading active automation inventory;
• audit and incident-response ambiguity about which writers remain enabled;
• unnecessary attack-surface and policy noise;
• failure of the fleet invariant that no temporary write-capable/self-modifying repair workflow remains;
• a detection gap in AppGuardrail itself: the repository currently cannot report this same-class issue from live GitHub workflow metadata.

Realistic remediation

Do not recreate or self-delete the old workflow files merely to clean them up. Use the GitHub Actions workflow lifecycle API from an authorized operator/normal governance path to disable each orphaned registry identity after proving its file is absent from the current protected default branch.

Because AppGuardrail's own policy says its repository issues must be detectable by AppGuardrail, add a read-only scanner/control-plane rule that:

1. paginates the live Actions workflow inventory;
2. resolves the current protected default-branch tree;
3. classifies every workflow record as present, orphaned-deleted, disabled, or unresolved;
4. flags active orphan records, especially names/paths indicating once, apply, finalize, repair, bootstrap, or branch-writing behavior;
5. never treats a missing contents response, pagination failure, or permission failure as a clean result;
6. emits exact workflow ID, path, state, current default-branch SHA, and evidence timestamp;
7. proposes disablement but does not mutate workflow state from an untrusted scan job.

Acceptance criteria

• complete paginated inventory, not a sampled list;
• all active registry paths absent from the current protected default branch are reviewed and either disabled or explicitly justified;
• no production scheduled/reusable workflow is disabled merely because a historical commit contained a different path;
• no temporary write-capable/self-modifying workflow source is reintroduced;
• AppGuardrail gains executable detection coverage for active-orphan workflow identities;
• adversarial tests cover truncated pagination, transient 404/403/5xx, default-branch movement, path case differences, a disabled orphan, and a live file whose name contains once but has an explicit supported contract;
• exact-head CI/security/review gates succeed;
• normal protected-default-branch integration;
• a post-integration live inventory shows every former orphan identity disabled and the production Commercial Readiness Loop still scheduled and operational.

This is part of the organization-wide GitHub Actions fleet incident. The AppGuardrail dedicated writer loop owns implementation; the fleet audit remains read-only and tracks the live registry to closure.

[seonghobae]

Confirmed organization-wide detector corpus

The active-orphan workflow class is now confirmed with live Actions-registry and exact-default-branch evidence across the following owner issues:

• .github#945 — central control plane, 256 workflow records;
• appguardrail#929 — 42;
• bandscope#847 — 44;
• clearfolio#423 — 23;
• codec-carver#401 — 19;
• contextual-orchestrator#122 — 28;
• DiagramWeave#27 — 31;
• disksage#191 — 54;
• EgressWeave#202 — 23;
• fast-mlsirm#809 — 102;
• four-pillars#33 — 23;
• inkspan#278 — 48;
• keyverse#99 — 42;
• life-os#202 — 109;
• naruon#1324 — 99;
• newsdom-api#604 — 22;
• noema#226 — 34;
• OriginWeave#123 — 37;
• pg-erd-cloud#865 — 52;
• pg-llm-batch#158 — 61;
• RankWeave#38 — 30;
• saju-caldav#33;
• scopeweave#478 — 32;
• semantic-data-portal#60 — 14;
• TEPP#20 — 14;
• ThreadWeave#31 — 27;
• xtrmLLMBatchPython owner issue;
• ContextualWisdomLab.github.io#163;
• EmbedRelay#2/#3 — a live protected-main materializer whose retirement is now in a normal PR.

Each sampled finding was based on an Actions workflow record still reporting state: active while the exact current default-branch contents API returned 404 for that repository path. Repositories with small/clean registries were also observed, so detection must report clean evidence rather than assume universal failure.

Product requirement refinement

AppGuardrail must detect this class from the control plane itself, not from workflow filenames alone. Required classification:

• supported active source present;
• active orphan to retire;
• active orphan pending intended protected-branch integration;
• present temporary workflow still owned by active work;
• disabled historical workflow;
• GitHub-owned dynamic workflow;
• unresolved due to pagination, permission, API ambiguity, or branch movement.

The detector must paginate beyond 100 records, support non-main default branches, bind to exact branch SHA, distinguish 404 from 403/5xx, refetch if the branch moves, and emit workflow ID/path/state/SHA/time plus pagination receipts. A read-only scan must not possess disable or branch-write authority. Remediation belongs to a separate reviewed owner/control-plane step.

Use this issue corpus as realistic regression fixtures. An AppGuardrail implementation that cannot discover these live issues does not satisfy the repository policy that AppGuardrail issues represent conditions the product itself can detect.