feat(ori): dossiq stops owning the ORI register, safely

[rubenvdlinde]

What

dossiq stops owning the ORI (Open Raadsinformatie) register.

Raadsinformatie is decidiq's domain (ADR-019/ADR-022) — meetings, agenda items,
votes, council members and political groups are its core Popolo model, and
dossiq's ori register was a parallel, Dutch-named duplicate of it. Its schemas
(vergadering, agendapunt, stemming, raadslid, fractie) also break the
English-identifier fleet contract structurally.

Implements openspec/changes/ori-removal T2 and T3.

Removed outright — the declaration and both consumers

• lib/Settings/ori_register.json, lib/Repair/RegisterOriRegister.php
• lib/Cron/OriDataQualityCheck.php + its <job> entry
• lib/Controller/RaadsinformatieFeedController.php + the three
  /feed/ori/*.rss routes
• their tests

The feeds move to /apps/decidiq/feed/ori/*. Deliberately no proxy and no
redirect: a feed that silently answers from a different app is worse than one
that stops, because a subscriber cannot tell it has moved.

NOT removed outright — the register itself

This is the part worth reading, and it is a deliberate departure from "delete
it".

Dropping the declaration stops the register being re-created. It does nothing
about the register already on an existing install — and that register holds real
objects: 115 on the reference instance, across all six schemas.

Deleting them without a migration destroys the record, and the paired decidiq
importer is not shipped: decidiq:import-ori does not exist in that repo
today (checked, not assumed). The change's own T0 gate says removal must not
outrun migration, and it is right.

So RetireOriRegister replaces RegisterOriRegister and retires the register
only once it is empty, warning and keeping it otherwise — naming the object
count and what to run. Idempotent, so it simply retires on the first upgrade
after the migration finally happens. Declared in post-migration only: a fresh
install never had an ORI register to retire.

branch	behaviour
OpenRegister absent / register absent	no-op, says which
register present with objects	warn and keep, upgrade still succeeds
register present, empty	retire
object count unreadable	keep

Two failure directions are deliberate, and tested

An unreadable object count KEEPS the register. An unreadable count must never
be able to authorise a deletion.

The shard-table scan matches on the openregister_table_ MARKER, not on a
computed table prefix. The Nextcloud prefix is configurable per install, and a
guess that misses returns zero tables — which would read as "empty" and
authorise exactly the deletion this step exists to prevent.

6 tests, including the one that matters most: seed a single unmigrated object
and assert the register survives. A guard that cannot say no is not a guard.

Verification

Full suite 2396 passed. PHPCS 0 errors · PHPMD clean · Psalm 0 errors ·
PHPStan 0 errors · gate-16 count=0.

Follow-up, not in this PR

T4/T5 of the change — the additive case.meetingRef property and repointing
VergaderingDetailView at decidiq's meeting — are product changes rather than
removal, and are left for their own PR.

[github-actions]

Quality Report — ConductionNL/dossiq @ ab05310

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

---

Quality workflow — 2026-08-24 09:27 UTC

Download the full PDF report from the workflow artifacts.