SonarCloud never reports on standards PRs; removed from ruleset 23787415 until it does

[hyperpolymath]

Problem

Ruleset 23787415 ("main gate: append-only + required checks + signatures + scanning") required the SonarCloud Code Analysis context (integration 12526). It never reported. It was absent on #1060, #1061, #1062, #1063, #1064, #1067 and #1078.

Because one required context never arrived, every merge to main was a bypass. The owner account holds pull_requests_only bypass on this ruleset, so merges went through silently. The other 21 required checks were enforced only by convention, not by the platform.

Action already taken (2026-09-30, owner ruling)

SonarCloud Code Analysis was removed from 23787415's required_status_checks (22 → 21 contexts; enforcement stays active). The next merge, #1067, recorded rule suite 4296932589 with result: pass, not bypass. So the gate now genuinely enforces its 21 contexts.

What remains: why is SonarCloud silent?

Not yet diagnosed. Candidates to rule in or out:

• whether the SonarCloud GitHub App installation covers hyperpolymath/standards
• automatic analysis vs a CI-driven scan: is anything actually triggering an analysis on PRs?
• the project binding / organisation key on the SonarCloud side
• whether any workflow runs a Sonar scan with SONAR_TOKEN (a nonexistent secret resolves EMPTY silently)

Related: campaign #443 (parked).

Acceptance criteria

1. The root cause of the silence is stated with evidence (app installation, binding, or trigger).
2. SonarCloud Code Analysis posts a check-run on at least one PR against main, as a positive control.
3. Only after (2), the context is re-added to 23787415. A PR is then merged with rule-suite result: pass (not bypass), which shows re-adding it did not reintroduce a vacuous gate.
4. Alternatively, if SonarCloud is dropped for good, that decision is recorded here and this issue is closed as not-planned.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WPSJ7fBhVAMcpSffCBWUDo

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Ruleset 23787415 requires 'SonarCloud Code Analysis', which no PR ever receives (SonarCloud parked, #443) #1081

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Diagnose first with read-only evidence. The repository contains no Sonar trigger, but historical Sonar ratings exist. Focus the investigation on the SonarCloud side (app coverage, binding, automatic analysis) and on a possible deleted scan.
• Add one small read-only diagnostic that correlates required pairs, PR-head check runs, and rule-suite results. The same tool produces the evidence for every acceptance criterion.
• Treat restore or drop as an owner policy decision. If the owner restores SonarCloud, fix only the identified prerequisite. Require a positive-control check run before any ruleset change.
• Re-add the context through the existing fresh-backup, dry-run, and readback protocol. Remove the stale-backup and applier-drift risks. Prove non-vacuous enforcement with a rule-suite pass merge.

Design Choices

Design Choice 1: Restore SonarCloud as a required context, or drop it permanently?

Options Considered:

1. Diagnose first, then let the owner choose between restore and drop, based on the recorded root cause.
2. Assume restoration and start the repair immediately.
3. Assume a permanent drop because of the advisory policy, and close the issue as not-planned.

Chosen Option: 1

Rationale: The ticket allows both outcomes. Estate policy already classifies Sonar review as advisory, and campaign #443 is parked with status:needs-owner.

Option 1: acceptance criterion 1 needs the diagnosis in both outcomes, and the choice between restore and drop is a policy act that belongs to the owner.

Design Choice 2: Which analysis mode restores the check if the owner chooses restoration?

Options Considered:

1. Restore automatic analysis. This means fixing the app coverage, the project binding, or the automatic-analysis setting on the SonarCloud side, with no change in the repository.
2. Add a CI-based scan workflow that uses SonarSource/sonarqube-scan-action and a SONAR_TOKEN secret.

Chosen Option: 1

Rationale: SonarCloud can analyse through automatic analysis or through a CI-based scanner. The repository contains no scanner, but historical PRs received a Sonar rating.

Option 1 by default: the historical evidence shows that analysis once worked with no tracked scanner. This option needs no new secret and does not conflict with the "never required" workflow policy. Option 2 applies only if the diagnosis shows that automatic analysis is ineligible and the owner approves the new secret and workflow.

Design Choice 3: How to re-add the context to the live ruleset?

Options Considered:

1. Run an owner-approved single-entry update. Follow the fresh-backup, dry-run diff, PUT, and readback procedure from arena-session-787/RULESET-B-PROTOCOL.md and config/rulesets/README.adoc.
2. Extend apply-branch-gates.sh so that it supports app-owned contexts.
3. Restore the 2026-09-27 backup snapshot.

Chosen Option: 1

Rationale: apply-branch-gates.sh produces only Actions-bound contexts and replaces the whole rule. The repair planner removes rules and does not add them.

Option 1: this is a one-off addition of one entry, and existing documented safeguards cover it. Option 2 is new abstraction that the ticket does not need. Option 3 is unsafe because the snapshot is stale.

Design Choice 4: How to produce reproducible evidence for "check-run posted" and "rule-suite pass"?

Options Considered:

1. Run ad hoc API queries and paste the output into the issue.
2. Add a read-only script that correlates the effective required pairs with the PR-head check runs and the rule-suite result, with a mocked-API test.

Chosen Option: 2

Rationale: The team can use ad hoc gh api calls or add a small committed read-only diagnostic.

Option 2: the exploration identified this gap, and acceptance criteria 2 and 3 need the same evidence. The script follows the existing scripts/ and scripts/tests/ patterns and makes no writes.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Read-only diagnosis of the silent publisher

This phase finds the root cause. It collects repository-side evidence and authenticated external evidence. It adds one read-only diagnostic. This phase does not change live GitHub or SonarCloud state. External queries need explicit owner approval or owner execution, as .machine_readable/TRUST.contractile requires.

Task 1: Record repository-side trigger evidence

Establish from the checkout and git history whether anything in the repository ever triggered a Sonar analysis.

• Record the existing search result. No tracked workflow, script, sonar-project.properties, scanner invocation, project or organisation key, or SONAR_TOKEN reference exists. The allowlist entries in config/settings/actions-allowlist.json:116–117 are permissions, not invocations.
• Search git history locally and read-only for deleted Sonar files. The targets are a deleted sonarqube.yml, a Sonar step, or a properties file, for example removed during the 2026-09-02 CI/CD regularisation. A deleted CI scan while automatic analysis stays off is a strong candidate cause.
• Resolve the pinned remote reusable workflows that local call sites reference. Confirm that none of them runs a Sonar scan. The exploration did not fetch these workflows.
• Result: if no workflow ever referenced the secret, rule out the "SONAR_TOKEN resolves empty silently" candidate. If history shows a scanner step, rule in the candidate.

Task 2: Add a read-only PR gate evidence diagnostic

Provide a reproducible way to show, for one PR, which required pairs were satisfied and whether a merge was pass or bypass.

• Create a new script in scripts/, for example scripts/check-pr-gate-evidence.sh. Follow the style and gh api usage of scripts/check-required-contexts.sh.
• Input: repository, PR number, and an optional ruleset ID.
• Read the required (context, integration_id) pairs from the active rulesets that target the PR base branch.
• Read the check runs on the PR head SHA with their app.id, and handle pagination.
• Report each pair as present, missing, or wrong-integration.
• For a merged PR, read the rule suite for the merge ref. Report result (pass or bypass) and the evaluated ruleset.
• Fail closed on any API read failure. An API failure must never be reported as absence. This rule prevents the swallowed-failure behaviour that check-required-contexts.sh shows.
• Make the script strictly read-only. It must contain no write verbs.
• Add scripts/tests/check-pr-gate-evidence-test.sh. Use the mocked-gh pattern from scripts/tests/apply-branch-gates-test.sh.
• Add these fixtures: missing SonarCloud check; same-name check from the wrong integration; paginated check runs; API read failure; rule suite pass compared with bypass.

Task 3: Collect authenticated external evidence (owner-run or owner-approved)

Rule each candidate cause in or out with authenticated readings. Use the order from the SonarQube Cloud documentation.

• Check-run history: Run the Task 1.2 diagnostic on #1060–fix(ci,rulesets,triage): execute ULTRAPLAN-2026-09-29 Phase 0–2 fixes and verifications #1064, #1067, and #1078 to confirm that no check run came from app 12526. Find the most recent PR that has a SonarCloud Code Analysis check run, for example the PR in the tag-ruleset-canon history. This fixes the time window in which the silence started.
• App installation coverage: In the organisation settings, read the repository-access list of the SonarQube Cloud GitHub App installation. Record whether hyperpolymath/standards is included.
• Project binding and organisation key: In SonarQube Cloud, read Administration → General Settings → Repository binding for the project. Record the project key, the organisation key, and the bound repository.
• Analysis mode: Record whether automatic analysis is on or off. Record the date of the last analysis. Record whether automatic analysis is eligible for this repository (supported languages, no monorepo limits).
• Store screenshots or API output as evidence. Do not change any settings in this task.

Task 4: State the root cause in an audit record

Satisfy acceptance criterion 1 with a single, evidence-backed statement.

• Create docs/audits/audit-sonarcloud-silence-<date>.adoc. Follow the structure of docs/audits/audit-ci-context-producibility-2026-09-20.adoc.
• Classify the cause as one of these: app installation coverage, project binding or organisation key, or trigger (automatic analysis off with no CI scan, or missing secret). Cite the evidence from Tasks 1.1 and 1.3 for each candidate that is ruled in or out.
• Record that the silence made every merge to main a pull_requests_only bypass. Record that rule suite 4296932589 on #1067 shows pass after the removal on 2026-09-30.
• Mark clearly which statements come from live readings and which come from repository evidence only.
• Post a summary on the issue.

🤖 Prompt for AI agents

Implement a read-only diagnosis and a reproducible PR gate evidence diagnostic.
Record an evidence-backed root cause without changing live GitHub or SonarCloud
state.

- Obtain explicit owner approval or owner execution for external queries, as
`.machine_readable/TRUST.contractile` requires.
- Record the checkout search results and distinguish allowlist permissions from
invocations. Search local git history for deleted `sonarqube.yml`, Sonar steps,
properties files, and references to `SONAR_TOKEN`, including possible removal
during the 2026-09-02 CI/CD regularisation.
- Resolve pinned remote reusable workflows referenced by local call sites. Check
whether they run Sonar scans. Use the workflow and history evidence to rule the
empty-secret candidate in or out.

Diagnostic and tests:
- Create `scripts/check-pr-gate-evidence.sh` following
`scripts/check-required-contexts.sh` style and `gh api` usage. Accept
repository, PR number, and optional ruleset ID.
- Read active rulesets targeting the PR base branch. Correlate required
`(context, integration_id)` pairs with head-SHA check runs and `app.id`. Handle
pagination. Report `present`, `missing`, or `wrong-integration`.
- For merged PRs, read the merge-ref rule suite. Report `result` (`pass` or
`bypass`) and the evaluated ruleset.
- Fail closed and exit non-zero on any API read failure. Never report an API
failure as absence. Include no write verbs or write endpoints.
- Add `scripts/tests/check-pr-gate-evidence-test.sh` using the mocked-`gh`
pattern from `scripts/tests/apply-branch-gates-test.sh`. Cover missing
SonarCloud checks, same-name checks from the wrong integration, pagination, API
failures, and `pass` compared with `bypass`.

Evidence and audit:
- Run the diagnostic on #1060–#1064, #1067, and #1078. Find the latest PR with
`SonarCloud Code Analysis` from app `12526` to establish the start window for
the silence.
- Read App repository coverage, project repository binding, project and
organisation keys, automatic-analysis state, last-analysis date, and
automatic-analysis eligibility. Follow the SonarQube Cloud documentation order.
Store screenshots or API output. Do not change settings.
- Create `docs/audits/audit-sonarcloud-silence-<date>.adoc` following
`docs/audits/audit-ci-context-producibility-2026-09-20.adoc`. Classify the cause
as app coverage, binding or organisation key, or trigger. Cite evidence for each
candidate ruled in or out. Separate live readings from repository-only evidence.
- Record the `pull_requests_only` bypass effect and rule suite `4296932589` on
#1067 showing `pass` after removal on 2026-09-30. Post the audit summary on the
issue.

Phase 2: Owner decision and publisher repair

This phase applies the owner decision. If the owner chooses restoration, repair the publisher. Prove that the check posts before any ruleset change.

Task 1: Record the owner decision

Make the choice between restore and drop explicit and traceable.

• Present the root cause, the estate policy (Sonar review is advisory in docs/CICD-SIGNAL-DISCIPLINE.adoc:390), and the status of campaign #443 to the owner.
• If the owner drops SonarCloud, go to Task 3.4. Skip the other tasks in Phase 2 and Phase 3.
• If the owner restores SonarCloud, record the decision and continue to Task 2.2.

Task 2: Repair the identified cause

Fix only the prerequisite that Task 1.4 identified.

• App coverage: The owner adds hyperpolymath/standards to the repository selection of the SonarQube Cloud App installation.
• Binding or organisation key: The owner corrects the repository binding of the SonarCloud project, or imports the repository so that SonarCloud creates a bound project.
• Trigger: The owner enables automatic analysis. This is the default path.
• CI-based fallback: Use this only if automatic analysis is ineligible. Add a workflow in .github/workflows/. Use the allowlisted SonarSource/sonarqube-scan-action with a SHA pin. Trigger the workflow on pull_request to main. Add a guard step that fails when SONAR_TOKEN is empty. A missing secret must not resolve empty without an error. The owner must approve the new secret, because a secret is a security-policy change. The workflow itself stays out of the required contexts, as config/rulesets/gates.json requires. Only the app-published context is a candidate for the ruleset.

Task 3: Positive control on a PR against `main`

Satisfy acceptance criterion 2.

• Open a small PR against main, or re-run analysis on an open PR.
• Run the Task 1.2 diagnostic. Confirm that a check run named exactly SonarCloud Code Analysis with app.id 12526 exists on the head SHA.
• Record in the audit document that the historical "E Security Rating on New Code" failure (tests/test_tag_ruleset_canon.sh:235–243) is evidence that the detector can fail. This satisfies the positive-control rule in docs/CICD-SIGNAL-DISCIPLINE.adoc:138–143.
• If no check run appears, return to Task 1.3. Do not continue to Phase 3.

🤖 Prompt for AI agents

Record the owner decision and, if restoration is approved, repair only the
diagnosed prerequisite. Prove that the exact app-published check exists before
changing the ruleset.

- Present the root cause, advisory policy in
`docs/CICD-SIGNAL-DISCIPLINE.adoc:390`, and campaign #443 status to the owner.
- If the owner drops SonarCloud, proceed to Task 3.4. Skip the remaining
restoration tasks in Phases 2 and 3.
- If the owner restores SonarCloud, record the decision. Apply only the repair
identified in Task 1.4, with owner authorisation for live changes.
- For app coverage, the owner adds `hyperpolymath/standards` to the SonarQube
Cloud App repository selection. For binding or organisation-key problems, the
owner corrects the binding or imports the repository to create a bound project.
For trigger problems, the owner enables automatic analysis by default.
- Only if automatic analysis is ineligible and the owner approves the new secret
and workflow, add `.github/workflows/<sonar-scan>.yml`. Use the allowlisted
`SonarSource/sonarqube-scan-action` with a SHA pin. Trigger on `pull_request` to
`main`. Add a guard step that fails when `SONAR_TOKEN` is empty.
- Keep the fallback workflow out of required contexts, as
`config/rulesets/gates.json` requires. Only the app-published context is a
candidate for the ruleset.
- Open a small PR against `main`, or re-run analysis on an open PR. Run the
Phase 1 diagnostic. Confirm the exact name `SonarCloud Code Analysis` and
`app.id` `12526` on the PR head SHA.
- Record the historical "E Security Rating on New Code" failure from
`tests/test_tag_ruleset_canon.sh:235–243` in the audit. Use it as evidence that
the detector can fail under `docs/CICD-SIGNAL-DISCIPLINE.adoc:138–143`.
- If the check does not appear, return to Task 1.3. Do not proceed to Phase 3.

Phase 3: Re-add the requirement and prove non-vacuous enforcement

This phase starts only after Task 2.3 succeeds. Alternatively, this phase closes the issue if the owner dropped SonarCloud.

Task 1: Remove stale-restoration and reconciliation risks

Prevent the old vacuous gate from returning. Prevent a later applier run from dropping the context without notice.

• Update arena-session-787/RULESET-B-PROTOCOL.md. Add a note that ruleset-23787415-backup-2026-09-27.json predates the removal on 2026-09-30 and must not be restored. Do not edit the historical JSON snapshot.
• Find out whether scripts/apply-branch-gates.sh or another applier reconciles ruleset 23787415. The branch-gate derivation replaces the whole required-check rule with Actions-bound contexts. If an applier reconciles 23787415, record the app-owned requirement in the canonical source for this ruleset, with owner approval. Otherwise, record in the audit document that no applier reconciles 23787415.

Task 2: Owner-approved single-entry ruleset update

Re-add SonarCloud Code Analysis (integration 12526) to 23787415 without other drift.

• Take a fresh backup of the live ruleset. Compare the backup with the expected 21-context state.
• Build the payload from the live object. Add only the pair {"context":"SonarCloud Code Analysis","integration_id":12526}. Show a dry-run diff to the owner.
• After the owner approves, apply the update. Do not delete and recreate the ruleset, as config/rulesets/README.adoc:108–121 requires.
• Read back the ruleset. Verify all 22 (context, integration_id) pairs, enforcement: active, and unchanged bypass_actors. Treat any difference as a failure. An HTTP success alone is not sufficient evidence.

Task 3: Prove a non-bypass merge

Satisfy acceptance criterion 3.

• Merge a PR against main on which all 22 contexts are present and green.
• Run the Task 1.2 diagnostic on the merge. Confirm rule-suite result: pass for 23787415, not bypass.
• If the result is bypass, remove the SonarCloud requirement again with the same Task 3.2 procedure. Return to Phase 1.
• Record the rule-suite ID in the audit document and on the issue. Then close the issue as completed. Update campaign #443 with the result.

Task 4: Drop path (alternative to Tasks 2.2–3.3)

Satisfy acceptance criterion 4.

• Record the owner decision and the root cause in the audit document and on the issue.
• Keep the stale-backup note from Task 3.1 in arena-session-787/RULESET-B-PROTOCOL.md.
• Do not change the bypass actor 12526 in config/rulesets/base.json. This ticket does not need that change.
• Cross-reference campaign #443. Close the issue as not-planned.

🤖 Prompt for AI agents

After the positive control succeeds, re-add the single SonarCloud requirement
with owner approval and prove a non-bypass merge. If the owner chooses to drop
SonarCloud, record that decision and complete only the drop path.

Restoration safeguards:
- Update `arena-session-787/RULESET-B-PROTOCOL.md` to state that
`ruleset-23787415-backup-2026-09-27.json` predates removal on 2026-09-30 and
must not be restored. Do not edit the historical JSON snapshot.
- Determine whether `scripts/apply-branch-gates.sh` or another applier
reconciles `23787415`. The branch-gate derivation replaces the whole
required-check rule with Actions-bound contexts. If an applier reconciles this
ruleset, record the app-owned requirement in its canonical source with owner
approval. Otherwise, record the absence of an applier in the audit.

Single-entry live update:
- Follow the fresh-backup, dry-run diff, PUT, and readback procedure in
`arena-session-787/RULESET-B-PROTOCOL.md` and `config/rulesets/README.adoc`.
- Take a fresh backup of the live ruleset and compare it with the expected
21-context state. Build the payload from the live object. Add only
`{"context":"SonarCloud Code Analysis","integration_id":12526}`.
- Show the dry-run diff to the owner. Only after approval, apply the update. Do
not delete and recreate the ruleset, as `config/rulesets/README.adoc:108–121`
requires.
- Read back and verify all 22 `(context, integration_id)` pairs, `enforcement:
active`, and unchanged `bypass_actors`. Treat any difference as failure. Do not
treat HTTP success alone as sufficient evidence.

Merge proof:
- Merge a PR against `main` with all 22 contexts present and green. Run the
Phase 1 diagnostic on the merge. Require rule-suite `result: pass` for
`23787415`, not `bypass`.
- If the result is `bypass`, remove the SonarCloud requirement using the same
Task 3.2 procedure. Return to Phase 1.
- Record the rule-suite ID in the audit and on the issue. Close the issue as
completed and update campaign #443.

Alternative drop path:
- Record the owner decision and root cause in the audit and on the issue. Keep
the stale-backup note in `arena-session-787/RULESET-B-PROTOCOL.md`.
- Do not change bypass actor `12526` in `config/rulesets/base.json`.
- Cross-reference campaign #443 and close the issue as not-planned.

Research

Ticket Summary

Diagnose with evidence why the SonarCloud Code Analysis check (integration 12526) never reports on hyperpolymath/standards PRs against main. Prove the check with a positive-control PR. Only then re-add the check to ruleset 23787415 and show a rule-suite result: pass merge. Alternatively, the owner can drop SonarCloud permanently. Record that decision.

Codebase Summary

The repository separates authorised policy (constitution and normative documents), canonical configuration (config/rulesets/*.json, config/settings/repo.json), live GitHub enforcement, and observed evidence. The repository treats a live ruleset change as a policy act that needs owner authorisation.

The exploration found no tracked file that triggers a Sonar analysis. It found no Sonar action in uses:, no sonar-project.properties, no scanner invocation, no project or organisation key, and no SONAR_TOKEN reference. The allowlists permit Sonar actions, but no workflow calls them. Two files record that SonarCloud once analysed PRs and failed one PR with "E Security Rating on New Code": tests/test_tag_ruleset_canon.sh:235–243 and .github/workflows/tag-ruleset-canon.yml:120–130. This is a historical positive control for the detector.

Estate policy in docs/superpowers/specs/2026-09-02-cicd-regularisation-design.adoc:120 and config/rulesets/gates.json:96–105 classifies a sonarqube.yml workflow as "ADVISORY opt-in" and "never required". The repository contains no such workflow.

Existing tools cover only parts of the diagnosis:

• scripts/check-required-contexts.sh classifies non-Actions integration IDs as app-owned without verification. It also swallows API read failures.
• scripts/apply-branch-gates.sh derives Actions-bound (15368) contexts and replaces the whole required-check rule. A later run can therefore drop an app-owned context that an operator added by hand.
• scripts/plan-ruleset-constraint-repair.rb preserves required checks but does not add them.

No tool correlates the required (context, integration_id) pairs with the check runs on a PR head SHA and with rule-suite results. arena-session-787/ruleset-23787415-backup-2026-09-27.json still contains the SonarCloud requirement. If an operator restores that snapshot, the vacuous gate returns. Tests follow a mocked-gh/write-log pattern in scripts/tests/.

File-Level Change Summary

File	Change	Rationale
scripts/check-pr-gate-evidence.sh (new)	Read-only correlation of required pairs, PR-head check runs, and rule-suite result. Fails closed on API errors.	Produces evidence for acceptance criteria 1–3 and fills the gap that the exploration found.
scripts/tests/check-pr-gate-evidence-test.sh (new)	Mocked-gh fixtures: missing check, wrong integration, pagination, API failure, pass compared with bypass.	Follows the existing test pattern and protects the fail-closed behaviour.
docs/audits/audit-sonarcloud-silence-<date>.adoc (new)	Root cause, evidence, owner decision, positive control, rule-suite IDs.	Acceptance criterion 1 and the traceable record.
arena-session-787/RULESET-B-PROTOCOL.md	Note that the 2026-09-27 snapshot is stale and must not be restored.	Prevents the vacuous gate from returning through the restore procedure.
.github/workflows/<sonar-scan>.yml (conditional, new)	CI-based scan with a SHA pin, triggered on pull_request to main, with an empty-SONAR_TOKEN guard.	Only if automatic analysis is ineligible and the owner approves.
Canonical source for 23787415 (conditional)	Record the app-owned requirement.	Only if an applier reconciles this ruleset. Needs owner approval.

Live changes need owner authorisation and have no file in the repository. These changes are: App repository selection, SonarCloud binding and automatic-analysis setting, SONAR_TOKEN secret, and the ruleset 23787415 update.

Follow-Up Agent Prompts

• Diagnostic agent: "Implement scripts/check-pr-gate-evidence.sh as a strictly read-only tool. For a given repository and PR number, read the active rulesets that target the base branch. List the required (context, integration_id) pairs. List the head-SHA check runs with app.id, with pagination. Report present, missing, or wrong-integration for each pair. For merged PRs, report the rule-suite result. Exit non-zero on any API failure. Add scripts/tests/check-pr-gate-evidence-test.sh with the mocked-gh pattern from scripts/tests/apply-branch-gates-test.sh. Do not call any write endpoint."
• Evidence agent: "Without changing anything, search git history for deleted Sonar workflows, scanner steps, or sonar-project.properties. Resolve the pinned remote reusable workflows and check them for Sonar steps. Find the last PR with a SonarCloud Code Analysis check run from app 12526. Write the findings into docs/audits/audit-sonarcloud-silence-<date>.adoc, and separate live readings from repository evidence. Ask the owner to supply the App installation list, the SonarCloud binding, the organisation key, and the automatic-analysis state."
• Ruleset agent (only after the positive control and owner approval): "Take a fresh backup of ruleset 23787415. Show a dry-run diff that adds only SonarCloud Code Analysis/12526. After approval, apply the update to the live object. Read back and verify all 22 pairs and bypass_actors. Never restore ruleset-23787415-backup-2026-09-27.json."

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement a read-only diagnosis and a reproducible PR gate evidence diagnostic.
Record an evidence-backed root cause without changing live GitHub or SonarCloud
state.

- Obtain explicit owner approval or owner execution for external queries, as
`.machine_readable/TRUST.contractile` requires.
- Record the checkout search results and distinguish allowlist permissions from
invocations. Search local git history for deleted `sonarqube.yml`, Sonar steps,
properties files, and references to `SONAR_TOKEN`, including possible removal
during the 2026-09-02 CI/CD regularisation.
- Resolve pinned remote reusable workflows referenced by local call sites. Check
whether they run Sonar scans. Use the workflow and history evidence to rule the
empty-secret candidate in or out.

Diagnostic and tests:
- Create `scripts/check-pr-gate-evidence.sh` following
`scripts/check-required-contexts.sh` style and `gh api` usage. Accept
repository, PR number, and optional ruleset ID.
- Read active rulesets targeting the PR base branch. Correlate required
`(context, integration_id)` pairs with head-SHA check runs and `app.id`. Handle
pagination. Report `present`, `missing`, or `wrong-integration`.
- For merged PRs, read the merge-ref rule suite. Report `result` (`pass` or
`bypass`) and the evaluated ruleset.
- Fail closed and exit non-zero on any API read failure. Never report an API
failure as absence. Include no write verbs or write endpoints.
- Add `scripts/tests/check-pr-gate-evidence-test.sh` using the mocked-`gh`
pattern from `scripts/tests/apply-branch-gates-test.sh`. Cover missing
SonarCloud checks, same-name checks from the wrong integration, pagination, API
failures, and `pass` compared with `bypass`.

Evidence and audit:
- Run the diagnostic on #1060–#1064, #1067, and #1078. Find the latest PR with
`SonarCloud Code Analysis` from app `12526` to establish the start window for
the silence.
- Read App repository coverage, project repository binding, project and
organisation keys, automatic-analysis state, last-analysis date, and
automatic-analysis eligibility. Follow the SonarQube Cloud documentation order.
Store screenshots or API output. Do not change settings.
- Create `docs/audits/audit-sonarcloud-silence-<date>.adoc` following
`docs/audits/audit-ci-context-producibility-2026-09-20.adoc`. Classify the cause
as app coverage, binding or organisation key, or trigger. Cite evidence for each
candidate ruled in or out. Separate live readings from repository-only evidence.
- Record the `pull_requests_only` bypass effect and rule suite `4296932589` on
#1067 showing `pass` after removal on 2026-09-30. Post the audit summary on the
issue.
===============================================================================

Task: 2

Record the owner decision and, if restoration is approved, repair only the
diagnosed prerequisite. Prove that the exact app-published check exists before
changing the ruleset.

- Present the root cause, advisory policy in
`docs/CICD-SIGNAL-DISCIPLINE.adoc:390`, and campaign #443 status to the owner.
- If the owner drops SonarCloud, proceed to Task 3.4. Skip the remaining
restoration tasks in Phases 2 and 3.
- If the owner restores SonarCloud, record the decision. Apply only the repair
identified in Task 1.4, with owner authorisation for live changes.
- For app coverage, the owner adds `hyperpolymath/standards` to the SonarQube
Cloud App repository selection. For binding or organisation-key problems, the
owner corrects the binding or imports the repository to create a bound project.
For trigger problems, the owner enables automatic analysis by default.
- Only if automatic analysis is ineligible and the owner approves the new secret
and workflow, add `.github/workflows/<sonar-scan>.yml`. Use the allowlisted
`SonarSource/sonarqube-scan-action` with a SHA pin. Trigger on `pull_request` to
`main`. Add a guard step that fails when `SONAR_TOKEN` is empty.
- Keep the fallback workflow out of required contexts, as
`config/rulesets/gates.json` requires. Only the app-published context is a
candidate for the ruleset.
- Open a small PR against `main`, or re-run analysis on an open PR. Run the
Phase 1 diagnostic. Confirm the exact name `SonarCloud Code Analysis` and
`app.id` `12526` on the PR head SHA.
- Record the historical "E Security Rating on New Code" failure from
`tests/test_tag_ruleset_canon.sh:235–243` in the audit. Use it as evidence that
the detector can fail under `docs/CICD-SIGNAL-DISCIPLINE.adoc:138–143`.
- If the check does not appear, return to Task 1.3. Do not proceed to Phase 3.
===============================================================================

Task: 3

After the positive control succeeds, re-add the single SonarCloud requirement
with owner approval and prove a non-bypass merge. If the owner chooses to drop
SonarCloud, record that decision and complete only the drop path.

Restoration safeguards:
- Update `arena-session-787/RULESET-B-PROTOCOL.md` to state that
`ruleset-23787415-backup-2026-09-27.json` predates removal on 2026-09-30 and
must not be restored. Do not edit the historical JSON snapshot.
- Determine whether `scripts/apply-branch-gates.sh` or another applier
reconciles `23787415`. The branch-gate derivation replaces the whole
required-check rule with Actions-bound contexts. If an applier reconciles this
ruleset, record the app-owned requirement in its canonical source with owner
approval. Otherwise, record the absence of an applier in the audit.

Single-entry live update:
- Follow the fresh-backup, dry-run diff, PUT, and readback procedure in
`arena-session-787/RULESET-B-PROTOCOL.md` and `config/rulesets/README.adoc`.
- Take a fresh backup of the live ruleset and compare it with the expected
21-context state. Build the payload from the live object. Add only
`{"context":"SonarCloud Code Analysis","integration_id":12526}`.
- Show the dry-run diff to the owner. Only after approval, apply the update. Do
not delete and recreate the ruleset, as `config/rulesets/README.adoc:108–121`
requires.
- Read back and verify all 22 `(context, integration_id)` pairs, `enforcement:
active`, and unchanged `bypass_actors`. Treat any difference as failure. Do not
treat HTTP success alone as sufficient evidence.

Merge proof:
- Merge a PR against `main` with all 22 contexts present and green. Run the
Phase 1 diagnostic on the merge. Require rule-suite `result: pass` for
`23787415`, not `bypass`.
- If the result is `bypass`, remove the SonarCloud requirement using the same
Task 3.2 procedure. Return to Phase 1.
- Record the rule-suite ID in the audit and on the issue. Close the issue as
completed and update campaign #443.

Alternative drop path:
- Record the owner decision and root cause in the audit and on the issue. Keep
the stale-backup note in `arena-session-787/RULESET-B-PROTOCOL.md`.
- Do not change bypass actor `12526` in `config/rulesets/base.json`.
- Cross-reference campaign #443 and close the issue as not-planned.

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For design choice 1 go ahead with option 3 and replan.

---

Start Coding →