fix(ci): make claims-ledger always report

[ghost]

Problem

claims-ledger used pull_request.paths and push.paths. When this workflow is configured as a required check, a main-bound candidate that does not touch one of those paths can skip the workflow entirely and never receive a claims-ledger status.

Change

• remove both paths: filters;
• run on every pull request targeting main;
• add merge_group support;
• keep validation on pushes to main;
• add workflow_dispatch for explicit replay.

Authority boundary

This changes only workflow triggering. It does not modify the claims ledger, validation logic, CEREMONY quorum, source code, deployments, credentials, or repository policy settings.

Expected invariant

Every main-bound candidate produces an explicit claims-ledger verdict: pass or fail, never absent because of path filtering.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hook-generator	Ready	Preview	Aug 2, 2026 4:55am
hub	Ready	Preview	Aug 2, 2026 4:55am
platform-picker	Ready	Preview	Aug 2, 2026 4:55am

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	aegisomega	7db1f04	Commit Preview URL Branch Preview URL	Aug 02 2026, 04:55 AM

[qodo-code-review]

PR Summary by Qodo

CI: ensure claims-ledger always reports on main-bound candidates

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Remove path filters so the required claims-ledger check never silently skips.
• Run on every pull request and merge group targeting main.
• Keep push-to-main validation and add workflow_dispatch for manual re-runs.

Diagram

graph TD
  PR["pull_request → main"] --> WF["claims-ledger workflow"] --> ST["Status: pass/fail"]
  MG["merge_group → main"] --> WF
  PS["push → main"] --> WF
  WD["workflow_dispatch"] --> WF

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep paths filters + add lightweight always-run required check

• ➕ Retains reduced CI load by only running full validation on ledger-touching changes
• ➕ Still guarantees a required status exists for every main-bound candidate
• ➖ More workflow complexity (two checks and coordination of required status)
• ➖ Risk of confusing status semantics (stub check vs full validation)

2. Use a single always-triggered workflow with job-level conditional execution

• ➕ Guarantees a status while allowing skipping expensive steps when paths unchanged
• ➕ Centralizes logic in one workflow file
• ➖ Requires reliable path-diff detection in workflow logic
• ➖ More scripting/maintenance than simply running the current cheap validation

Recommendation: Current approach (remove path filters and always run for main-bound events) is the most robust for required-check semantics, and is appropriate given the validation is cheap and the ledger is repository-wide evidence state. Consider job-level conditional execution only if workflow runtime becomes materially expensive.

Files changed (1) +9 / -10

Other (1) +9 / -10

claims-ledger.ymlMake claims-ledger workflow always trigger for main-bound candidates +9/-10

Make claims-ledger workflow always trigger for main-bound candidates

• Removes pull_request/push paths filters to prevent required checks from being skipped. Restricts PR and merge_group triggers to main, keeps push-to-main validation, and adds workflow_dispatch for manual replay.

.github/workflows/claims-ledger.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 11 rules

1. Missing workflow concurrency ✓ Resolved 🐞 Bug ➹ Performance

Description

With paths filters removed, this workflow now runs on every main-bound PR update, merge_group, and
main push, but it has no workflow-level concurrency to cancel superseded runs. Rapid successive PR
updates can leave redundant validations running/queued, wasting runner capacity and slowing feedback
loops.

Code

.github/workflows/claims-ledger.yml[R11-18]

on:
  pull_request:
-    paths:
-      - docs/claims.json
-      - docs/CLAIMS_LEDGER.md
-      - docs/claims.schema.json
-      - scripts/validate-claims.mjs
+    branches: [main]
+  merge_group:
+    branches: [main]
  push:
-    paths:
-      - docs/claims.json
-      - docs/CLAIMS_LEDGER.md
-      - docs/claims.schema.json
-      - scripts/validate-claims.mjs
+    branches: [main]
+  workflow_dispatch:

Relevance

●●● Strong

Repo already uses workflow concurrency (e.g., ci.yml); adding it here avoids redundant runs after
trigger expansion.

PR-#120

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR expands triggers to run on all main-targeting PRs and merge queue candidates, which increases
the chance of overlapping runs; the workflow file contains no concurrency: block to cancel
obsolete runs. Other workflows in this repo use concurrency cancellation to avoid redundant runs on
repeated updates.

.github/workflows/claims-ledger.yml[11-18]
.github/workflows/ci.yml[30-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `claims-ledger` workflow now triggers much more often (all PR updates targeting `main`, merge queue runs, and pushes to `main`), but it does not define `concurrency`. This can cause multiple redundant runs to execute concurrently for the same PR merge ref when commits are pushed quickly.

## Issue Context
A simple, safe concurrency grouping can cancel older runs for the same `github.ref` while preserving distinct `merge_group` attempts (which use unique refs).

## Fix Focus Areas
- .github/workflows/claims-ledger.yml[11-22]

## Suggested change
Add a workflow-level `concurrency` block, e.g.:

```yml
concurrency:
 group: claims-ledger-${{ github.workflow }}-${{ github.ref }}
 cancel-in-progress: true
```

Place it near the top-level keys (typically after `on:`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[ghost]

Exact-head status — paths filter closed; job-level startup failure quantified

Current head: 7db1f04d3ef665cbb8573fd0d612799556afd6b9

Implemented:

• removed pull_request.paths and push.paths from claims-ledger;
• added main-bound pull_request, merge_group, push, and workflow_dispatch triggers;
• added workflow concurrency with cancellation of superseded runs.

Trigger invariant

claims-ledger emitted workflow run 30733202178, proving the workflow is no longer absent because of path filtering.

Job-level scan of all PR-triggered runs returned for this exact head

• workflow runs returned: 11
• workflows with at least one non-skipped zero-step failed job: 10
• intentionally skipped-only workflows: 1 (AEGIS Agent Dispatch)
• zero-step failed jobs: 11
• zero-step skipped jobs: 10
• jobs with recorded executed steps: 0

Affected non-skipped workflows:

1. OSV-Scanner
2. AEGIS Automaton-2
3. Kernel One
4. AEGIS Scale OS Controls
5. claims-ledger
6. AEGIS Automaton-3
7. Integration Ledger
8. AEGIS Experiment Admission
9. Hadolint
10. AEGIS-Ω Constitutional Automaton

Hadolint demonstrates why run-level conclusions are insufficient: its workflow run reported success, while its only job concluded failure with no steps. The workflow-level success is explained by job-level continue-on-error: true.

Temporal discriminator

On PR #225 head 12e2c88473a7017378dab31e078b25f991ece397, the Workflow Write Capability Gate successfully executed both actions/checkout@v4 and actions/setup-python@v5; it failed later in scripts/audit-workflow-write-capabilities.py. Therefore a selected-actions policy did not self-block that historical gate run. A policy change after that run remains possible but is not verified.

Classification

paths_filter_repair              IMPLEMENTED
trigger_emission                 VERIFIED
validator_execution              NOT_REACHED
run_level_conclusion_reliable    FALSE
job_level_scope                  10/10 non-skipped workflows affected
pre_start_rejection              STRONGLY_SUPPORTED
startup_failure_source           UNRESOLVED
selected_actions_hypothesis      PLAUSIBLE, NOT_VERIFIED
historical_gate_self_blocked     FALSE on PR #225 exact run
current_gate_self_blocked        NOT_CHECKED
branch_protection_configuration  NOT_CHECKED
merged                           FALSE

No check is represented as passed, and no merge was forced.