fix(register): drop the unresolvable $ref on the cross-app decisions relation (gate-54 1 → PASS) - #473
Merged
Conversation
…relation gate-54 relation-dialect 1 -> PASS, measured with hydra-gates 365fa31 at the CI scope (--scope-to-diff --base origin/beta). `contract.decisions` references decidesk Decision objects (ADR-066). It carried BOTH `x-external-register: "decidesk"` AND `$ref: "Decision"`. OpenRegister resolves `$ref` inside ONE register set and can never reach another app's schema, so that $ref is dead weight — it names a target nothing will ever look up. Earlier today I measured this same finding against package 651e5c5, concluded it was an unclosable gate gap, and left it red with that reasoning — .github #305 says exactly that, and I added my instance to it. That conclusion is now WRONG: .github#286 landed hours later and gave the cross-app case a dialect. The gate is right and the register was wrong. The sanctioned form is `x-external-register: <app>` on the property carrying the bare identifier (`type: string` + `format: uuid`), with no `$ref`. The annotation moves to the PROPERTY as well as the item, because `_is_external_ref()` reads it on the property; on `items` alone it is invisible to the gate, which is why the old generic "does not resolve" message fired instead of the new cross-app one. Can-fail: restoring the $ref puts gate-54 back to 1. gate-51 stays PASS; the register still parses.
Contributor
Quality Report — ConductionNL/softwarecatalog @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-manifest | ✅ | ||||
| check-vue-demi | ✅ | ||||
| test-l10n | ✅ | ||||
| composer | ✅ | ✅ 128/128 | |||
| npm | ✅ | ✅ 718/718 | |||
| PHPUnit | ✅ | ||||
| Newman | ⏭️ | ||||
| Playwright | ✅ | ||||
| Hydra gates | ✅ |
Quality workflow — 2026-08-09 21:13 UTC
Download the full PDF report from the workflow artifacts.
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
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.
gate-54 relation-dialect: 1 → PASS. hydra-gates
365fa31d09a26f980e6dc76cb0800575ef005a4e, measured at the CI scope (--scope-to-diff --base origin/beta).The defect
contract.decisionsreferences decideskDecisionobjects (ADR-066). It carried bothx-external-register: "decidesk"and$ref: "Decision".OpenRegister resolves
$refinside one register set and can never reach another app's schema, so that$refis dead weight — it names a target nothing will ever look up.I had this wrong earlier today, and I am correcting it
Measuring the same finding against package
651e5c5, I concluded it was an unclosable gate gap and left it red on that basis — and I added my instance to .github#305 arguing the gate could not express a sanctioned ADR-066 relation.That conclusion is now wrong. .github#286 landed hours later and gave the cross-app case a dialect. The gate is right; the register was wrong. I have followed up on #305 rather than leaving my earlier comment as the last word there.
The sanctioned form, and why the old message fired
_is_external_ref()readsx-external-registeron the property. This register had it onitemsonly — invisible to the gate — which is why the generic "$ref 'Decision' does not resolve to a schema key" fired instead of the new, actionable cross-app message."decisions": { "type": "array", + "x-external-register": "decidesk", "items": { "type": "string", "format": "uuid", - "$ref": "Decision", "x-external-register": "decidesk" },The annotation is kept on
itemstoo — it documents the item, and the exemption is what the property carries.Can-fail proof
Restoring the
$refputs gate-54 straight back to 1 finding.Other measurements
json.load).