development red since the nc-vue 2.31.1 bump: gate-53 reports 1 structural violation with no way to see it

[rubenvdlinde]

development has been red since 70ba77f (Takes nextcloud-vue 2.31.1 so a hovered KPI tile stops…, 19:08). One gate fails:

[gate-53] effective-manifest-crossref: FAIL — 1 structural violation(s) in the
ASSEMBLED manifest (base+fragments+menu-layout)

It is real, not flaky. I re-ran the failed jobs on the same SHA and it failed identically.

What I could not do, and what I ruled out

I could not reproduce it locally, having eliminated the three things that usually explain that:

• Gate version. CI runs .github at hydra-gates-ref: main. My local .github was on a feature branch four commits behind, so my first "passes locally" was measured with the wrong gate. I re-ran with a fresh clone of main (4226ee2) from GitHub. Still passes.
• The dependency in the failing commit. My node_modules had nc-vue 2.27.2 while package.json wants ^2.31.1 — so that run was against the old library too. After npm ci (2.31.1 installed), it still passes.
• The assembly step. The gate names the ASSEMBLED manifest, so I also ran build_effective_manifest.js --app-dir . and fed the result via --manifest. Passes: {"status":"passed","checked":1,"failed":0}.

Locally the checker reports only WARNs — five removals-invariant warnings about report routes losing their nav entry, and seven src/registry.js exports … but no manifest entry names it. None is an error, and the gate's own exit is failed:0.

Where the detail actually is

The job log does not inline the violation; it points at /tmp/hydra-gates.<rand>/hydra-gate-*.log on the runner, which does not survive. I checked the run's artifacts too — quality-report.md / .pdf and result-hydra-gates (154 bytes) — and none carries the finding.

So the finding exists only inside a job whose output is discarded. That is worth fixing independently of this failure: a gate that fails with "1 structural violation" and no way to see which one costs everybody who hits it an afternoon. Uploading the gate's own log alongside result-hydra-gates would be enough.

Raising rather than guessing at a fix — I have no way to see the violation, and shillinq is not mine to change on a hunch.

[github-actions]

Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

What happens next:

1. A maintainer will review this issue and determine the appropriate action
2. If accepted, it may be converted into an OpenSpec change for structured development
3. You will be notified of any status changes

Triage labels:

• triage:accept-feature — accepted as a new feature
• triage:accept-bugfix — accepted as a bug fix
• triage:needs-info — more information needed
• triage:wontfix — will not be addressed
• triage:duplicate — duplicate of another issue

[rubenvdlinde]

Found it. I could not reproduce this earlier because I ran the checker library directly; running the full run-hydra-gates.sh reproduces it, and unlike CI the runner's temp file survives locally.

{"path": "/pages/432/config/bulkActions/0",
 "message": "must NOT have additional properties (keyword=additionalProperties)"}

Page: BudgetToProgrammeLinker (/bbv-provincie/budget-to-programme), declared in src/manifest.d/bookkeeping-provincies-bbv-variant.json.

The two offending keys are requiresSelection and dialog. Of that bulk action's keys, only id, label and icon are in the schema's action definition, which is additionalProperties: false.

It is not a stale vendored schema

That was my first guess, since the failure appeared on the nc-vue 2.31.1 bump while .github last synced its copy at 2.28.0 (9d1ae9a). It does not hold: nc-vue 2.31.1's own src/schemas/app-manifest-v2.schema.json rejects both keys too, with the same additionalProperties: false on action.

Nothing reads them

• no match for requiresSelection anywhere in node_modules/@conduction/nextcloud-vue
• no match in shillinq's src/, beyond a docblock in BbvLinkerFilterBar.vue that mentions config.bulkActions[] in prose
• nothing reads action.dialog

So the declared dialog — target programme select, effective date, submit/cancel labels — renders nowhere today. The bulk action also has no type, which the schema's supported shape needs.

Why it went red on a dependency-only commit

70ba77f changed package.json and the lockfile and nothing else. The manifest violation is older than the commit that surfaced it; the bump simply moved the gate onto a code path that validates this page.

Two ways forward, and it is your call

1. Drop the two keys. Smallest change, turns the branch green, and removes a promise nothing keeps. But it silently discards the declared intent of REQ-BBL-001's linking dialog.
2. Move to the supported shape. The schema's bulkActions description says type: "open-modal" merges the selection into the modal's props as selectedIds / count, so a manifest-declared modal can act on a selection without the page hand-writing it. That is what this action appears to want, and it needs the modal component to exist.

I have not applied either — (1) deletes feature intent and (2) is feature work, both yours to decide.

Separately, and worth more than this bug: the finding is only visible because I happened to run the gate on a machine where /tmp survives. In CI it is written to /tmp/hydra-gates.<rand>/ and discarded, and neither quality-report.md nor the 154-byte result-hydra-gates artifact carries it. Uploading that log would have turned this from an afternoon into a minute.