Skip to content

fix(hydra-gates): vendor manifest schema 2.138.0 and name schema drift in gates 22 and 53 - #861

Merged
rubenvdlinde merged 2 commits into
mainfrom
fix/hydra-gates-vendor-manifest-schema-2.138.0
Oct 21, 2026
Merged

rubenvdlinde merged 2 commits into
mainfrom
fix/hydra-gates-vendor-manifest-schema-2.138.0

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

What

Gates 22 (manifest-validation) and 53 (effective-manifest-crossref) were validating against a vendored app-manifest-v2 schema at 2.96.0. @conduction/nextcloud-vue 2.118.0 (npm latest) ships 2.138.0. So valid manifests failed on keys the library already accepts: entitySource: "endpoint", rowIndicators[].after and statusPill.values.

  1. Re-vendored hydra-gates/scripts/schemas/app-manifest-v2.schema.json from the published 2.118.0 tarball. The schema is byte-identical to the one in the package.
  2. Drift is now named, not silent:
    • New scripts/lib/vendored_schema_freshness.js compares the vendored copy with npm latest (default), a schema file (--published), or an app's installed library (--app-dir). It warns by default. --strict exits 1 when the copy is behind, and it exits 2 when it cannot compare. Tests are in test_vendored_schema_freshness.js.
    • check_manifest.js logs VENDORED SCHEMA BEHIND: … when the app running the gate has a newer library installed. Gates 22 and 53 then add that line to their failure reason.
    • hydra-gates-schema-sync.yml now runs daily instead of weekly. It also closes the older sync PRs that its new PR supersedes. The copy fell behind because chore(hydra-gates): vendor manifest schema 2.85.0 #842 (2.85.0) and chore(hydra-gates): vendor manifest schema 2.126.0 #859 (2.126.0) were left open.

Stricter constraints (diff_schema_strictness 2.96.0 → 2.138.0)

/$defs/page/allOf[10]/then/properties/config/required: newly required ["register","schema"]
/$defs/page/allOf[11]/then/required: newly required ["config"]
/$defs/page/allOf[6]/if/required: newly required ["type"]
/$defs/widgetEntry/allOf[11]/if/properties/widgetKey/const: new const constraint "nc-widget"
/$defs/widgetEntry/allOf[12]/if/properties/widgetKey/enum→const: "decision-list"

To check these, every fleet app's development src/manifest.json was validated against both schemas. No app went red. Three went from red to green:

app errors with 2.96.0 errors with 2.138.0
dossiq 6 0
shillinq 2 0
portaliq 2 0
the other 16 with a manifest 0 0

Verified locally

  • Gates 22 and 53 (validator, effective-manifest builder, validator, crossref, chained the same way the runner chains them) against current development checkouts:
    • dossiq: 2.96.0 failed on entitySource, rowIndicators/1 and statusPill. 2.138.0 gives rc 0 on all four steps.
    • portaliq: 2.96.0 failed on entitySource. 2.138.0 gives rc 0 on all four steps.
  • These suites are green: test_check_manifest.sh, test_check_manifest_crossref.js, test_build_effective_manifest.js, test_check_manifest_ajv_collapse.js, test_diff_schema_strictness.js, test_lib_commonjs_scope.sh, test_manifest_scope_filter.js, test_vendored_schema_freshness.js.
  • Full run-helper-suites.sh: 132 suites pass and 1 is quarantined (as on main). One suite was red on the first run: test_gate_45_to_55_acceptance.sh. Its anti-widening checks for gates 22 and 53 grep for additionalProperties, and 2.138.0 refuses the planted unknown key with unevaluatedProperties instead. The defect is still caught, so the second commit accepts either keyword. That suite now passes.
  • The full run-hydra-gates.sh --full on portaliq development reports [gate-22] manifest-validation: PASS and [gate-53] effective-manifest-crossref: PASS (33 non-blocking WARNs).

The require is not defined in ES module scope crash

This was already fixed on main by scripts/lib/package.json ("type": "commonjs", #815, in hydra-gates/v2026.41 and later). test_lib_commonjs_scope.sh runs all three gate-53 helpers under a "type": "module" parent, and it passes. The crash still shows up for apps that run the composer-installed copy: dossiq locks conduction/hydra-gates v1.16.1 and portaliq locks v1.18.0, and both tags predate that file. They also carry an older schema. No v1.x tag has been cut since the fix, so a new composer release (or moving apps to the hydra-gates/v2026.* line) is needed for local composer runs to pick up both fixes. That is out of scope here. I did not rename to .cjs, because the package.json already makes both module modes work.

AI disclosure: prepared with Claude Code (claude-opus-5-5) and reviewed by the contributor before submission.

🤖 Generated with Claude Code

…t in gates 22 and 53

The vendored app-manifest-v2 schema was at 2.96.0 while
@conduction/nextcloud-vue 2.118.0 (npm latest) ships 2.138.0. dossiq,
portaliq and shillinq failed gates 22 and 53 on keys the library accepts:
entitySource "endpoint", rowIndicators[].after and statusPill.values.

- Re-vendor the schema from the published 2.118.0 tarball.
- Add scripts/lib/vendored_schema_freshness.js: compares the vendored copy
  with npm latest, a schema file, or an app's installed library.
- check_manifest.js logs VENDORED SCHEMA BEHIND when the app's installed
  library ships a newer schema; gates 22 and 53 append it to their reason.
- The sync workflow runs daily and closes older sync PRs it supersedes.

Assisted-by: ClaudeCode:claude-opus-5-5
…refusal

Schema 2.138.0 closes header actions and store pages with
unevaluatedProperties rather than additionalProperties. The planted
unknown key is still refused, so the anti-widening checks for gates 22
and 53 now accept either keyword.

Assisted-by: ClaudeCode:claude-opus-5-5
@rubenvdlinde
rubenvdlinde merged commit e39aded into main Oct 21, 2026
48 of 49 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant