chore(gate-115): record the SourceMapper lookup as answered

[rubenvdlinde]

What

Nine lines of comment. No code changes.

ExternalIntegrationRouter::loadSource() asks the container for OCA\OpenConnector\Db\SourceMapper. Gate-115 (stale-fleet-app-id, shipped today in hydra-gates v1.17.0) reports it as a cross-app lookup naming a retired namespace. The comment beside the line already said why it is not repointed. This adds the machine-readable half, so the gate stops re-raising a question that has an answer.

What was read

Re-verified 2026-09-10 against a clean development clone of integriq:

• integriq has no lib/Db/ directory at all.
• ac47457f ("delete 14 mapper + entity shim files, chain-C cutover complete") removed SourceMapper, following 7df241bc which deleted 15 entities and 15 mappers in the OpenRegister cutover.
• No OCA\Integriq\Db\SourceMapper was ever added in its place. The only remaining mention in that repo is a docblock in SynchronizationService recording that it reimplements the legacy SourceMapper::findOrCreateByLocation() over object storage.

Why record rather than repoint

Renaming the namespace swaps one missing class for another, on a diff that reads to the next person as a fix already applied.

This is the least bad of the fleet's ten answered findings, because it is the only one that fails visibly: the get() throws into the catch below, which raises openconnector-source-missing, and the UI shows "Reconfigure connector" rather than a generic 500. It still needs a real replacement seam rather than a rename, and the marker records that so the next reader starts from what was already checked.

How it is recorded

@stale-fleet-app-id exclude <reason>, the exclusion convention the rest of the hydra-gates suite already uses, with the reason graded by the shared exclusion_reason.is_reason_bearing(). Gate-115 learns to read it in ConductionNL/.github#738, which must merge first: CI resolves hydra-gates at @main.

Excluded findings are not hidden. The gate prints them under "recorded with a reason-bearing marker" on every run.

Not in this PR

The two register-slug findings in lib/AppHost/Scheduling/ScheduleReconciler.php (OC_REGISTER_SLUG = 'openconnector', OB_REGISTER_SLUG = 'openbuild'). Both slugs are live across the fleet depending on whether a given instance has run the rename repair, so those need a probe for the slug the register actually answers to, not a literal swap.

Verification

Gate-115 on this branch: 0 cross-app lookup(s), 1 finding(s) recorded with a reason-bearing @stale-fleet-app-id exclude marker, and the 2 slug findings unchanged. php -l clean.

🤖 Generated with Claude Code

[github-actions]

Quality Report — ConductionNL/openregister @ fc0352f

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-specs		✅
test-l10n		✅
test-l10n-parity		✅
format		✅
check-schema-l10n		✅
check-l10n-js		✅
composer			✅	✅ 174/174
npm			✅	✅ 551/551
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					❌
Newman					✅
Playwright					✅
Hydra gates					❌

---

Quality workflow — 2026-09-10 06:34 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

The red on this PR is not from this PR

quality / Hydra Gates fails on gate-46 spec-anchor-existence: 15 unresolved findings (8 @SPEC, 7 @e2e). None of them is in a file this branch touches, and all 15 are present on pristine development at f54613c, which is this branch's base. Reproduced locally by running check_spec_anchors.py over a clean development clone: 15 findings, byte-identical to the CI list.

quality / Quality Report is the aggregator of that failure. quality / PHPUnit (PHP 8.3, NC stable34, pgsql) did not fail a test: its log ends in The operation was canceled, with no test tally and no named failure.

Where the 15 came from

They arrived today, from the gate rather than from this repo. openregister's last development push run (2026-09-09 12:33) was green.

• feat(gate-46): open appinfo/ and scripts/ as well .github#734 widened gate-46's file enumerator from lib src tests to lib src tests appinfo scripts. Its own commit message says the anchors are in appinfo/routes.php and that 8 of the 9 dangle, so the 8 @spec findings were known before the widening merged. It shipped blocking.
• feat(gate-46): resolve @e2e anchors too, report-only .github#733 added @e2e anchor resolution, report-only. That is the other 7, five of which are the literal template placeholder #<scenario-slug> that was never filled in.

CI resolves hydra-gates at @main, so this reds every openregister PR from the moment #734 merged, not only this one. Checked the other five repos carrying gate-115 findings (pipelinq, learniq, buildiq, launchpad, hermiq): 0 gate-46 findings in each, so openregister is the repo the widening lands on.

Deliberately not fixed here. Repointing 8 stale @spec targets and filling 7 @e2e anchors is real work with its own blast radius, and folding it into a comment-only PR whose entire subject is one recorded lookup would make both halves harder to review. It wants its own change, and the prior question is whether a scope widening on a blocking gate should have shipped report-only first, the way #733 did.

[github-actions]

Quality Report — ConductionNL/openregister @ 6516364

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-specs		✅
test-l10n		✅
test-l10n-parity		✅
format		✅
check-schema-l10n		✅
check-l10n-js		✅
composer			✅	✅ 174/174
npm			✅	✅ 551/551
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					❌
Newman					✅
Playwright					✅
Hydra gates					✅

---

Quality workflow — 2026-09-10 10:18 UTC

Download the full PDF report from the workflow artifacts.