feat(schemas): x-openregister-lifecycle on 7 schemas (re-do of #306)

[rubenvdlinde]

Summary

Re-applies the ADR-031 declarative-state-machine annotations from PR #306 onto the current post-manifest-migration lib/Settings/procest_register.json. PR #306's branch (feature/declarative-annotation-pilot) accumulated 40+ conflicts with development (which has since landed the json-manifest migration that deleted/restructured files the branch modified) and could not be rebased — this is a clean re-do off current development.

Adds configuration.x-openregister-lifecycle blocks (state machine: field, initial, final, transitions) to 7 schemas, with version bumps:

Schema	Version	Transitions
task	1.0.0 → 1.1.0	activate, complete, terminate, disable
document	1.0.0 → 1.1.0	submit, adopt, archive, sendBack
voorstel	1.0.0 → 1.1.0	startParafering, paraferingDone, accord, submit, decide, archive, sendBack, revise
hearingSession	1.1.0 → 1.2.0	invite, execute, cancel, waive (incl. the dossier_beschikbaar status that development added)
adviesAanvraag	1.0.0 → 1.1.0	receive, expire
handhavingsactie	1.0.0 → 1.1.0	forfeit, execute, withdraw
inspectieChecklist	1.0.0 → 1.1.0	activate, archive

Register version bumped 0.7.0 → 0.8.0.

Notes / scope

• PR feat: adopt x-openregister-lifecycle on 7 procest schemas #306 itself contained no guard classes (lib/Lifecycle/), no x-openregister-calculations/-aggregations/-notifications, and no STATUS_* constant removal — those were never part of that PR — so this re-do mirrors it: register-JSON-only. No PHP changes.
• The unrelated noise in feat: adopt x-openregister-lifecycle on 7 procest schemas #306's diff (docs/development.md, l10n/*, src/utils/taskLifecycle.js) was branch drift, not part of the lifecycle deliverable, and is intentionally not carried over.
• Companion OpenRegister tracking issue: feat: declarative annotation platform — lifecycle / aggregations / calculations / notifications openregister#1357.
• python3 -m json.tool lib/Settings/procest_register.json validates.

Supersedes #306, which is on an un-rebaseable branch.

Test plan

• python3 -m json.tool lib/Settings/procest_register.json is valid (done)
• OpenRegister picks up the lifecycle blocks; POST /api/objects/{id}/transition honours the new transition tables
• Register re-import / upgrade applies the version bumps without errors

[github-actions]

Quality Report — ConductionNL/procest @ 7a1e205

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	❌
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		❌
stylelint		❌
composer			✅	✅ 100/100
npm			✅	✅ 419/419
PHPUnit					⏭️
Newman					⏭️
Playwright					❌

Spec coverage: 5% (21 tests / 456 specs)

---

Quality workflow — 2026-05-12 05:38 UTC

Download the full PDF report from the workflow artifacts.

[WilcoLouwerse]

[CONCERN] hearingSession: dossier_beschikbaar has no incoming transition

The hearingSession lifecycle uses dossier_beschikbaar as a from state in three transitions (execute, cancel, waive), but there is no transition whose to is dossier_beschikbaar. Starting from gepland, the lifecycle machine can reach uitgenodigd, uitgevoerd, geannuleerd, and afgezien — but dossier_beschikbaar is unreachable via any defined transition.

If dossier availability is set by an external/automatic process (not a user-triggered transition), this may be intentional and should be documented. If it is meant to be triggered manually, a makeDossierAvailable (or similar) transition from uitgenodigd to dossier_beschikbaar is missing.

Suggested fix: either add a transition makeDossierAvailable: { from: ["uitgenodigd"], to: "dossier_beschikbaar" }, or add a comment/description in the schema explaining that this state is set programmatically outside the lifecycle machine.

[WilcoLouwerse]

Review

🟡 Concerns (1)

• hearingSession: dossier_beschikbaar has no incoming transition — lib/Settings/procest_register.json:249

Reviewed by WilcoLouwerse via automated batch review.