Release: merge development into beta

.github/workflows/code-quality.yml

@@ -161,34 +161,35 @@ jobs:
       # need the matching runtime or `vendor/composer/platform_check.php` aborts
       # with `Composer dependencies require a PHP version ">= 8.3.0"`.
       php-version: "8.3"
-      # Set explicitly, because the shared workflow defaults to
-      # `["stable31", "stable32"]` and stable31 CANNOT WORK here. integriq
-      # declares <app>openregister</app> as a hard dependency, and openregister
-      # declares min-version="32". On NC31 the E2E job logs
-      #   App "Open Register" cannot be installed because it is not compatible
-      #   with this version of the server.
-      # then continues with a WARNING, so the run proceeds without its central
-      # dependency and fails ~70s later on missing tables — which reads like a
-      # migration fault rather than a missing app. Testing a version the app
-      # cannot support produces red that says nothing. See issue #1172.
-      #
-      # WHY THIS IS NOW stable34 AND NOT `["stable32", "stable33"]`. This PR
-      # moves the dev requirement to `nextcloud/ocp ^34`, so the stubs every
-      # static-analysis leg resolves against are NC34's. Running the suite
-      # against an older server would check the app under one set of API
-      # signatures and analyse it under another, and the two disagreeing is
-      # exactly the class of defect the analysers exist to find.
-      #
-      # ✅ THE NARROWING IS CLOSED, THE FIRST WAY. The previous revision of this
-      # comment recorded a deliberate trade: info.xml declared three server
-      # versions while the suite exercised one, leaving NC32 and NC33 unmeasured
-      # rather than known-broken. It named its own closure condition — "restoring
-      # the older refs alongside stable34 once ocp ^34 stubs are proven compatible
-      # with them" — and that condition is now met: portaliq runs stable32,
-      # stable33 and stable34 against `nextcloud/ocp ^34` and all six PHPUnit
-      # legs pass (run 31599055849). So the refs come back rather than info.xml's
-      # floor going up, and the two numbers agree again.
-      nextcloud-test-refs: '["stable34", "stable32", "stable33"]'
+      # NO `nextcloud-test-refs` HERE, DELIBERATELY. Unset, the shared workflow
+      # derives the PHPUnit matrix from appinfo/info.xml, so the tested range and
+      # the declared range cannot disagree.
+      #
+      # THIS BUMP IS WHY IT HAD TO GO. The list read
+      # `["stable34", "stable32", "stable33"]` while info.xml now declares NC
+      # 32-35 — gate-65 rule 11, NC 35 advertised to the App Store and exercised
+      # by nothing. Appending "stable35" would clear the gate for this PR and
+      # re-arm the same trap for NC 36; worse, it would arm it on `development`
+      # rather than here, because the gate fires on the manifest/matrix
+      # disagreement for EVERY later PR, not just the one that introduced it.
+      # openregister#3777 took the same decision for the same reason.
+      #
+      # WHAT THE OLD LIST WAS PROTECTING, AND WHY IT NO LONGER HAS TO. Its first
+      # entry mattered: E2E, newman and journeydoc-capture ran against
+      # `fromJSON(nextcloud-test-refs)[0]`, so stable34 had to lead to keep them
+      # off a server openregister cannot load — openregister declares
+      # min-version="32", and on NC31 the E2E job logged `App "Open Register"
+      # cannot be installed…`, continued with a WARNING, and failed ~70s later on
+      # missing tables (issue #1172). Those jobs now consume the workflow's
+      # `single-server` output — the numerically highest branch in the resolved
+      # set — so list order is inert and the floor is carried by info.xml's
+      # min-version="32" instead of by a hand-written array.
+      #
+      # THE stable35 LEG DEPENDS ON openregister. `additional-apps` below installs
+      # openregister from `development`, and the shared workflow aborts a job whose
+      # `occ app:enable` fails for an additional app. openregister#3777 (max-version
+      # 34 -> 35) is merged, so that leg can enable it; if openregister's declared
+      # ceiling ever lags this one again, this leg is where it will show.
       # `hydra-gates-require-full-coverage: false` is REMOVED here, exactly as
       # the comment it replaced instructed: "Remove this line in the change
       # that wires those producers up, so the coverage requirement arrives with

appinfo/info.xml

@@ -23,7 +23,7 @@
 - 📋 Pas bedrijfsregels toe op endpoint-verkeer en houd een audit trail per object bij
 
     ]]></description>
-	<version>0.4.6-unstable.20260912101736</version>
+	<version>0.4.8-unstable.20260919141023</version>
 	<licence>EUPL-1.2</licence>
 	<author mail="info@conduction.nl" homepage="https://www.conduction.nl/">Conduction</author>
 	<namespace>Integriq</namespace>
@@ -59,13 +59,45 @@
         object — so the app cannot function there. Declaring 28 advertised a range
         this app cannot deliver. See issue #1172.
 
-        max-version is 34, NOT 35, for the same "do not advertise a range you
-        cannot deliver" reason in the other direction: NC 35 does not exist —
-        there is no tag, no branch, and this app's own CI matrix has no leg past
-        stable33. The rest of the fleet declares 34; integriq was the only
-        repo claiming 35, so the claim was untested everywhere it mattered.
+        max-version is 35. The previous 34 was recorded here because "NC 35 does
+        not exist — there is no tag, no branch"; nextcloud/server now carries
+        stable35 and nextcloud/ocp has shipped v35.0.0, so that reason has
+        expired. This app's own surface was checked against the change rather
+        than assumed: of the eleven OCP classes removed in 35 (the OCP\Remote\*
+        family, AutoCompleteEvent, CacheInsertEvent, CacheUpdateEvent) integriq
+        references none, and the migration-signature break that NC 35 introduced
+        — ISchemaWrapper handing out OCP\DB\Schema\ITable where Doctrine's
+        Schema\Table used to be — cannot reach this app: it ships ONE migration
+        and that migration type-hints no table at all. The two symfony packages
+        NC 35 core ships and an app can collide with, console and
+        http-foundation, are already required at ^7.4 here, which is what
+        stable35's 3rdparty declares (^7.4.15).
+
+        THE CLAIM STILL DEPENDS ON openregister. min-version above is 32 because
+        openregister is a HARD dependency and declares 32; the same sentence
+        governs this end of the range. openregister declares max-version="34"
+        today, so on NC 35 it refuses to install and every integriq entity —
+        each one an OpenRegister object — has nowhere to live. This bump is
+        therefore correct about integriq and premature about the stack until
+        ConductionNL/openregister#3777 (max-version 34 -> 35) merges. Landing it
+        first would re-advertise a range this app cannot deliver, which is the
+        exact mistake the deleted paragraph above was written to record.
+
+        SEQUENCING, decided rather than assumed (integriq#1983 review
+        5278999788, @rjzondervan 2026-09-22): openregister#3777 has merged and
+        is on OpenRegister's `beta` and `development`, while its `main` is still
+        at 34. So an instance taking OpenRegister from the app store's stable
+        channel gets a combination that has not shipped together.
+
+        That is accepted because the channels are paired: integriq `beta` runs
+        against OpenRegister `beta`, and the promotion into `main` waits on
+        OpenRegister's. A beta channel is where an unshipped combination is
+        meant to be exercised. If that pairing ever changes — beta expected to
+        run against OpenRegister `main` — this bump becomes a blocker rather
+        than a sequencing note, so the assumption is written here rather than
+        held in someone's head.
         -->
-        <nextcloud min-version="32" max-version="34"/>
+        <nextcloud min-version="32" max-version="35"/>
 	</dependencies>
 
 	<background-jobs>
@@ -90,6 +122,31 @@
 		<job>OCA\Integriq\BackgroundJob\ApprovalTimeoutSweepJob</job>
 		<job>OCA\Integriq\BackgroundJob\IwmoIjwRetryJob</job>
 		<job>OCA\Integriq\BackgroundJob\StufZknRetryJob</job>
+		<!-- document-generation-vendor-adapter: every five minutes, ask the
+		     vendor again about a render it has not settled. This is what keeps
+		     `unreachable` a state rather than a dead end: a render nobody could
+		     ask about is unfinished business, not a failure. -->
+		<job>OCA\Integriq\BackgroundJob\DocumentGenerationStatusJob</job>
+		<!-- directory-and-group-sync: hourly. A membership that ended in the
+		     directory has to end here without anyone acting, which is the whole
+		     difference between synchronising membership and authenticating
+		     against a directory. -->
+		<job>OCA\Integriq\BackgroundJob\DirectorySyncJob</job>
+		<!-- connection-registry D7: hourly. Syncs declarations whose app
+		     version moved, probes at most 25 linked sources, oldest first,
+		     then resolves every connection row without an outbound call. -->
+		<job>OCA\Integriq\BackgroundJob\ConnectionHealthJob</job>
+		<!-- registry-subscription-connector: every fifteen minutes. Asks each
+		     registry binding what changed about the identities it follows and
+		     posts that to OpenRegister. Nothing about the changed record is
+		     written here. -->
+		<job>OCA\Integriq\BackgroundJob\RegistrySubscriptionPollJob</job>
+		<!-- berichtenbox-digital-post-adapter: the status job asks the providers
+		     what became of the letters they took, every ten minutes, and only
+		     about letters still on their way. The inbound job offers what
+		     arrived to the document intake inbox. -->
+		<job>OCA\Integriq\BackgroundJob\DigitalPostStatusJob</job>
+		<job>OCA\Integriq\BackgroundJob\DigitalPostInboundJob</job>
 	</background-jobs>
 
 	<!-- ⚠️ CHILD ORDER IS FIXED BY THE APP STORE SCHEMA, and it is NOT the order
@@ -209,6 +266,11 @@
 			     keeps all five fields on purpose (see the step's docblock). -->
 			<step>OCA\Integriq\Repair\RemoveMigratedSourceSecretFields</step>
 			<step>OCA\Integriq\Repair\MaterializeCatalogItems</step>
+			<!-- connection-registry D5: every enabled app's
+			     lib/Settings/connections.json becomes connection rows. After
+			     InitializeRegister, so the app_connection schema exists. Idempotent
+			     and never throws. -->
+			<step>OCA\Integriq\Repair\SyncConnectionDeclarations</step>
 			<!-- WRITTEN BUT NEVER REGISTERED until now, which meant it never
 			     ran anywhere. gate-98 (repair-step-registration) found it.
 
@@ -262,15 +324,14 @@
 			     same migration on demand. -->
 			<step>OCA\Integriq\Repair\MigrateFlowStepsToGraph</step>
 			<step>OCA\Integriq\Repair\RemoveRetiredCronJobs</step>
-			<!-- Written but never registered, so it had never run once: a class
-			     that exists is not a class that runs. It moves openconnector
-			     data out of the Dutch columns into the English ones, so every
-			     instance that predates the column rename still holds its data
-			     where nothing reads it.
-
-			     post-migration only: a fresh install has no Dutch columns to
-			     move, and the step is idempotent either way. -->
-			<step>OCA\Integriq\Repair\RenameDutchColumns</step>
+			<!-- RenameDutchColumns is NOT repeated here. It was registered twice
+			     — once above, after InitializeRegister and MagicMapper where its
+			     own comment reasons the placement out, and once here under a note
+			     saying it had "never been registered", which the earlier entry
+			     disproves. The duplicate ran the step twice per upgrade; it is
+			     idempotent, so nothing broke, but the second registration's
+			     stated reason was false and the placement above is the
+			     deliberate one (integriq#1983 review 5278999788). -->
 		</post-migration>
 		<!-- ocon#1180. A FIRST install runs neither `postSchemaChange` nor the
 		     `post-migration` steps above: `Installer::installAppLastSteps()` passes
@@ -369,6 +430,11 @@
 			<step>OCA\Integriq\Repair\InitializeActions</step>
 			<step>OCA\Integriq\Repair\MigrateLegacyStorage</step>
 			<step>OCA\Integriq\Repair\MaterializeCatalogItems</step>
+			<!-- connection-registry D5: every enabled app's
+			     lib/Settings/connections.json becomes connection rows. After
+			     InitializeRegister, so the app_connection schema exists. Idempotent
+			     and never throws. -->
+			<step>OCA\Integriq\Repair\SyncConnectionDeclarations</step>
 			<!-- The three inline-secret steps are deliberately NOT here. A first
 			     install has no sources, so they would have nothing to migrate,
 			     and RemoveMigratedSourceSecretFields is IRREVERSIBLE: it would