fix(sonar): point at this repo's own SonarCloud project - #20
Merged
Conversation
sonar.projectKey was hyperpolymath_rsr-template-repo, copied verbatim from the template repo this one was derived from. The correct project for this repo already exists on SonarCloud. The workflow currently fails at authentication (no SONAR_TOKEN secret), so nothing is being mis-submitted today -- but once the token is added this repo would start reporting into the template's project. Fix the key first. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
This was referenced Jul 21, 2026
Merged
hyperpolymath
added a commit
that referenced
this pull request
Jul 21, 2026
…h (PR-6, closes the sequence) (#21) Final PR of the completion sequence (#11 → #12 → #13 → #15 → #16 → #17 → this). - **STATE.a2ml** — completion 15→32 with per-phase justification comments; blockers echo #18/#19 + the anytype audit trail (anytype #13–#19, PR #20). - **AFFIRMATION.adoc** — anchor filled (main @ `a11c9877`, 2026-07-21T14:43Z, Lean 4.32.0/elan 4.2.3) in the same session that re-ran every check listed; every "affirmed-ran" row corresponds to a command actually executed. NOT-claims list keeps ET-2 closure, ET-6..9, ET-10..13, ET-14 explicitly open. - **Justfile** — `test`/`lint`/`fmt-check` were template echo-stubs (fake green). Now: `test` = proof gate + drift gate; `lint` = dangerous-construct scan, md-in-docs, root-shape, template validation; `fmt-check` honestly reports that nothing is checked. `check-no-vlang.sh` deferred to #19 (tracked, not silently skipped). `.machine_readable/root-allow.txt` updated for root entries landed by #14/#17. - **README** — badge `theory_(no_proofs_yet)` → `theory_(L2_proven, L1_core_proven, rest_OPEN)`; Status section states precisely what is machine-checked vs open. Verification (all run in this session at the anchor SHA): `./scripts/check-proofs.sh lean4` PASS (audit 12/12); `./scripts/scan-dangerous.sh` PASS; `./scripts/check-proof-status.sh` PASS; `./scripts/validate-template.sh` PASS (4 warnings); `just test && just quality` PASS end-to-end. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
hyperpolymath
marked this pull request as ready for review
July 21, 2026 14:52
|
This was referenced Jul 27, 2026
hyperpolymath
added a commit
to hyperpolymath/anytype
that referenced
this pull request
Jul 27, 2026
## Summary
`sonar.projectKey` was `hyperpolymath_rsr-template-repo` — the template
repo's own key, copied verbatim when this repo was derived from it.
Points it at its own project instead. **`sonar.organization` is
unchanged.**
## Why now, and why keys before tokens
This repo has no `SONAR_TOKEN` secret, so the scan currently aborts at
authentication and submits nothing:
```
##[warning]Running this GitHub Action without SONAR_TOKEN is not recommended
ERROR Not authorized or project not found. Please check the 'SONAR_TOKEN' environment
variable, the 'sonar.projectKey' and 'sonar.organization' properties, ...
```
So the wrong key is **latent, not actively corrupting anything**. But
the moment `SONAR_TOKEN` is added, this repo would start reporting its
analysis into `hyperpolymath_rsr-template-repo`, mixed in with every
other repo carrying the copied key. Fixing the key first means that
never happens.
Found in an estate-wide sweep of `sonar-project.properties` files
against the SonarCloud API. Same fix already merged in
hyperpolymath/systemet#20 and
hyperpolymath/rsr-julia-library-template-repo#16.
## Organisation
`hyperpolymath` is correct and unchanged here. The estate consolidates
SonarCloud under the single `hyperpolymath` organisation regardless of
GitHub org — settled in metadatastician/IDApTIK#42.
## Test plan
- [x] Only `sonar.projectKey` and the project URL in the header comment
change
- [x] `sonar.organization` untouched
- [ ] Owner to provision the project and add `SONAR_TOKEN` — the
workflow cannot pass without both, independent of this change
🤖 Generated with [Claude Code](https://claude.com/claude-code)
hyperpolymath
added a commit
to hyperpolymath/vocarium
that referenced
this pull request
Jul 27, 2026
## Summary
`sonar.projectKey` was `hyperpolymath_rsr-template-repo` — the template
repo's own key, copied verbatim when this repo was derived from it.
Points it at its own project instead. **`sonar.organization` is
unchanged.**
## Why now, and why keys before tokens
This repo has no `SONAR_TOKEN` secret, so the scan currently aborts at
authentication and submits nothing:
```
##[warning]Running this GitHub Action without SONAR_TOKEN is not recommended
ERROR Not authorized or project not found. Please check the 'SONAR_TOKEN' environment
variable, the 'sonar.projectKey' and 'sonar.organization' properties, ...
```
So the wrong key is **latent, not actively corrupting anything**. But
the moment `SONAR_TOKEN` is added, this repo would start reporting its
analysis into `hyperpolymath_rsr-template-repo`, mixed in with every
other repo carrying the copied key. Fixing the key first means that
never happens.
Found in an estate-wide sweep of `sonar-project.properties` files
against the SonarCloud API. Same fix already merged in
hyperpolymath/systemet#20 and
hyperpolymath/rsr-julia-library-template-repo#16.
## Organisation
`hyperpolymath` is correct and unchanged here. The estate consolidates
SonarCloud under the single `hyperpolymath` organisation regardless of
GitHub org — settled in metadatastician/IDApTIK#42.
## Test plan
- [x] Only `sonar.projectKey` and the project URL in the header comment
change
- [x] `sonar.organization` untouched
- [ ] Owner to provision the project and add `SONAR_TOKEN` — the
workflow cannot pass without both, independent of this change
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
sonar-project.propertiesdeclaressonar.projectKey=hyperpolymath_rsr-template-repo— the key belonging to a different repository, copied verbatim when this repo was derived fromrsr-template-repo. This points it at this repo's own SonarCloud project, which already exists.Why this matters now (and why it's worth doing before the token is added)
The SonarQube workflow here currently fails on every run — but not because of the key.
SONAR_TOKENis not set on this repo, so the scanner aborts at authentication:Because auth fails first, nothing is currently being submitted anywhere — the wrong key is latent, not actively corrupting data. But the moment
SONAR_TOKENis added, this repo would start pushing its analysis intohyperpolymath_rsr-template-repo, commingling with every other repo carrying the same copied key. Fixing the key first avoids polluting that project.Verified
hyperpolymath_rsr-template-repoalso exists — display name-REPO-— which is why the misdirected scans would land somewhere real rather than erroring out.sonar.organizationis unchanged and was already correct.Found during an estate-wide sweep of
sonar-project.propertiesfiles; several other repos carry the same copied key and need the same one-line fix.Test plan
sonar.projectKeyand the project URL in the header comment changeSONAR_TOKENrepository secret — the workflow cannot pass without it regardless of this change🤖 Generated with Claude Code