Features
StableBetaComing soon
Admin SettingsThe admin settings page provides a Nextcloud admin panel for configuring Procest. Administrators manage case types and all their related type definitions: statuses, results, roles, properties, documents, and decisions. The case type system is the behavioral engine of Procest -- every aspect of how a case behaves (allowed statuses, deadlines, required fields, archival rules) is defined here. The admin settings UI follows a list-detail pattern: a case type list on the main page, and a tabbed detail/edit view per case type.advice-managementAdvice management lets behandelaars request, track, and process internal and external advice (adviezen) on a case, with deadline tracking, reminders, and a workflow guard that blocks case completion while advice is still pending.AI Assistance@e2e exclude AI assistance is a V1 backend feature; no dedicated Playwright-testable UI surface in the current build.Appointment Booking@e2e exclude Appointment booking is V1; public token pages + backend integrations are not Playwright-testable in the current build.archief-edepot-handoverAutomates the lawful transfer of closed cases to an e-Depot, from retention-rule detection through MDTO/TMLO metadata bundling, PDF/A document export, BagIt packaging, submission, and proof-of-transfer capture. Runs a nightly job that assigns each closed case its statutory retention period, blocks or suspends transfer when rules are missing or a legal procedure is active, and lets DIV staff manage retention rules, run concurrent batch transfers, monitor a dashboard, and retry failed handovers. Records every archival milestone to an append-only audit log and produces audit-grade annual inspection exports.automatic-actions@e2e exclude Automatic actions is V1; action execution is backend logic (n8n webhooks, email triggers) not testable via Playwright.Berichtenbox Integration@e2e exclude Pure backend REST API integration; no Playwright UI surface.beroep-escalationProvides a pre-seeded "Beroep" (appeal) case type and the workflow to escalate a completed bezwaar case to the administrative court (bestuursrechter, Awb hoofdstuk 8), including court-proceedings status types, document tracking, and hoger-beroep awareness.beschikking-generatieComposes a conceptbeschikking from a template + current zaakdata, drives the verleend/geweigerd outcome with prefilled motivation, renders a PDF, attaches it as a `bijlage`, and routes it to the addressee. Procest owns composition + workflow; PDF rendering, archival, and Berichtenbox delivery are integrated via adapter interfaces backed by docudesk/openregister/openconnector.besluitvorming-workflowProvides end-to-end decision-making workflows for municipal College-besluit, Raadsbesluit, and Mandaatbesluit cases, shipping pre-configured case-type and workflow templates that run from drafting through parafering, agenda compilation, decision recording, publication, and archival. Drives a sequential signing (parafering) chain, auto-transitions cases to agenda-ready status once all signatures are collected, records formal decisions with voting results and attending members, validates mandate authority, and dispatches publication payloads to DROP/LVBB before archiving the complete dossier.bezwaar-advisory-committeeRecords advisory reports from the bezwaarschriftencommissie (objection advisory committee, AWB art. 7:13) on bezwaar cases, and tracks committee composition to safeguard independence and surface conflicts of interest.bezwaar-beroep-workflowManages the full objection (bezwaar) and appeal (beroep) lifecycle for municipal decisions in line with the Dutch General Administrative Law Act (AWB), driven entirely by configurable workflow templates rather than bespoke services. Seeds AWB-compliant case types, enforces the mandated status order with admissibility, hearing, and committee-advice gates, tracks the statutory 6-week deadline with extension (verdaging) and suspension (opschorting) support, schedules hearings via Nextcloud Calendar, links each case to the contested primary decision, and compiles a court-ready dossier across the primary-decision, objection, and appeal cases.bezwaar-decisionRecords the beslissing op bezwaar (decision on objection) as a formal decision object linked to the bezwaar case, enforcing the AWB heroverweging, motivering, and rechtsmiddelenclausule obligations (art. 7:11, 7:12) and notifying the bezwaarmaker.bezwaar-hearingSchedules and manages hoorzittingen (hearings) within the bezwaar process per the AWB hoorrecht (art. 7:2 e.v.), including invitations, minutes, hearing waiver (afzien van hoorrecht), and participant access rights.bezwaar-lifecycleDefines the end-to-end bezwaar (objection) lifecycle: the pre-seeded Bezwaar case type, status/role types, AWB-compliant deadline calculation, the objection object schema, the Bezwaren index UI surface, and the lifecycle listener and seed repair steps that drive bezwaar and beroep workflows.bezwaar-rest-apiHandles objections (bezwaar) against a dwangsom decision and exposes the authorization-checked REST API for the termijn, ingebrekestelling, dwangsom, and reporting operations. Filing a bezwaar freezes dwangsom accrual and suspends payment, and resolving it adjusts the amount and resumes payment, notifying the burger at each step. Every endpoint declares an explicit auth posture, enforces per-object/role checks, and validates input with appropriate HTTP error codes.burger-notificationsSends proactive, Dutch-language notifications to the burger at key lifecycle moments of a case: receipt confirmation with the statutory deadline, ingebrekestelling receipt explaining the dwangsom tariff, and payment confirmation. Each notification is rendered from a template and delivered via the procest notification-router (Nextcloud, email, and portal), queued asynchronously so an SMTP failure never blocks the underlying lifecycle operation.Case Dashboard ViewThe Case Dashboard View is the primary working screen for behandelaars. It combines all relevant information for a single case into one integrated view: timeline, documents, status, tasks, contactmomenten, besluiten, and linked objects. While the Case Management spec (`../case-management/spec.md`) defines the data model and individual panels (REQ-CM-06 through REQ-CM-13), this spec defines how those panels are composed into a cohesive working screen with interactions between them.case-email-integrationLink every relevant email to its case and surface it on the case detail page (consuming the OpenRegister `email` integration leaf for display/compose/link per ADR-022), archive linked mail as a PDF `caseDocument` for Archiefwet/ZGW compliance, and add the only genuinely case-specific extensions the leaf cannot provide: per-zaaktype email templating, a documented shared-mailbox ingest poller, and shared-mailbox admin settings.Case Location@e2e exclude Case location map is V1; Leaflet map picker and PDOK geocoder require external tile services not available in CI.Case ManagementCase management is the core capability of Procest. A case represents a coherent body of work with a defined lifecycle, initiation, and result. Cases are governed by configurable **case types** that control behavior: allowed statuses, required fields, processing deadlines, retention rules, and more. Cases follow CMMN 1.1 concepts (CasePlanModel) and are semantically typed as `schema:Project`.Case Map OverviewProvide an overview map showing all cases (or filtered subsets) plotted on a map with marker clustering, status-based coloring, and filtering. This enables case handlers and managers to get a geographic overview of their workload and identify spatial patterns (e.g., clusters of meldingen in a neighborhood, VTH cases near a construction site).case-type-publish-validationEnforces case-type publish and deletion prerequisites on the backend so the API cannot bypass frontend-only checks. Publishing a case type is blocked (HTTP 422) unless it has at least one status type, a final status type, and a validFrom date, with all validation errors returned together; deleting a case type with active cases is blocked (HTTP 409), and deletion of a type with only closed cases requires confirmation. The publish and deletion guards are pinned by unit tests covering both happy and error paths.case-type-seed-dataRegisters Pinia object stores for the five case-type sub-entities (resultType, roleType, propertyDefinition, documentType, decisionType) and ships seed data in `procest_register.json`, so the case-type admin tabs can query each entity by `caseType`.Case Type SystemCase types are configurable definitions that control the behavior of cases. A case type determines which statuses are allowed, what roles can be assigned, which custom fields are required, processing deadlines, confidentiality defaults, and archival rules. This is the international equivalent of ZGW's `ZaakType`, modeled after CMMN 1.1 `CaseDefinition` concepts.complaint-managementManages citizen complaints as first-class entities with their own schema, sequential numbering, and the Awb chapter 9 lifecycle with enforced deadlines and extension (verdaging). Supports multi-channel intake, hearings (hoorgesprek) including calendar and video integration, escalation to formal cases, disposition tracking, complainant communication, and configurable per-tenant categories. Provides list, detail, and dashboard views plus frequency analysis that flags recurring patterns and systemic issues for management attention.Consultation Management@e2e exclude Consultation management is V1; consultation lifecycle endpoints are backend-only in the current build.DashboardThe dashboard is the landing page of the Procest app. It provides an at-a-glance overview of case management activity: KPI cards with headline metrics, status and type distribution charts, an overdue cases panel, a personal workload preview, a recent activity feed, and quick actions. The dashboard aggregates data across all cases visible to the current user (respecting RBAC via OpenRegister).deelzaak-supportProvide deelzaak (sub-case) support in Procest: creating sub-cases from a parent case, listing them on the parent detail, parent breadcrumb navigation, progress roll-up, case-list count badges, and deletion protection. Maps to the ZGW `hoofdzaak` / `deelzaken` relations on the Zaak resource.docs-product-pages@e2e exclude Documentation site folder structure; not a Nextcloud app feature, no Playwright UI surface.document-zaakdossierManages the document dossier of a zaak using ZGW-compliant informatieobject and zaakinformatieobject records, so a document can be linked to multiple cases without duplication and follows a forward-only concept → definitief → gearchiveerd lifecycle. Access to every document is gated by its vertrouwelijkheidaanduiding at the service layer, and the dossier view groups documents by type with upload (metadata dialog), version history, full-text search, bulk ZIP export with manifest, and a range-capable ZGW DRC download endpoint. A repair step back-fills ZGW metadata for pre-existing linked files.Doorlooptijd DashboardThe doorlooptijd (processing time) dashboard provides SLA adherence analytics for case management. It enables team leads and case managers to monitor processing time compliance by case type, identify at-risk cases, and track compliance trends over time. All data is derived from existing case and case type fields in OpenRegister.dso-omgevingsloketIntegrates Procest with the DSO/Omgevingsloket: ingests vergunningaanvragen from OpenConnector into Procest zaken with statutory working-day deadlines, drives the omgevingsvergunning status lifecycle (dual-write + event dispatch), supports samenwerkverzoek and doorstuur flows, generates beschikkingen, and surfaces a VTH dashboard.DSO Omgevingsloket Client@e2e exclude Backend intake adapter invoked by openconnector; no Playwright UI surface.dwangsom-calculationCalculates the statutory dwangsom (AWB 4:17) due when a decision is not taken in time, applying the daily staffel (€23/€35/€45 per tier) after a 14-day grace period and capping the cumulative amount at the €1.442 plafond without retroactive recalculation. When a beschikking is registered, accrual stops, the final amount is locked, the termijn is marked voltooid, and a payment preparation is triggered.enforcement-lhsProvide VTH enforcement (handhaving) support in Procest based on the Landelijke Handhavingsstrategie (LHS): a configurable ernst x gedrag interventie matrix, an enforcement-action schema with dwangsom tracking and status lifecycle, a guided enforcement wizard, and a case-dashboard enforcement panel.financial-integrationPrepares an ERP-ready dwangsom payment signal once an amount is locked and processes the financial system's payment-confirmation callback via openconnector. The payment signal carries the full metadata (bedrag, rekeninghouder, IBAN, referentie, legal basis, payment deadline) and is blocked when the IBAN is missing or malformed; the signed callback is validated, looked up by referentie, updates the payment status to betaald, and triggers a burger notification, rejecting unknown references with HTTP 404.gis-integrationGIS / geo capability for cases: a backend `GeoService` (RFC 7946 GeoJSON validation + JSON-encoded (de)serialisation + clustered case-geo assembly), an OGC WFS 2.0.0 endpoint (`/wfs/cases`, reusing `WfsExportService`), a clustered cases-on-map data endpoint (`/api/cases/geo`, with a per-object access guard), and a Leaflet-based frontend (read-only `GeoViewer` single-case map + full-screen `CasesOnMapView` dashboard with filters + GeoJSON export). PDOK base layers / geocoding are reached via OpenConnector and degrade gracefully when OpenConnector or PDOK is unavailable — the map never hard-fails.handler-vervanging-waarnemingWorkload continuity when a case handler is absent (vervanging/waarneming) and when a handler permanently leaves (bulk reassignment). A waarnemer sees and works the absent handler's cases, tasks, and deadline signals for a bounded period; every action taken in that capacity is audit-trailed as "namens"; and a coordinator can transfer all open work of a departing handler in one previewed, audited batch. Substitution is domain logic on top of OpenRegister RBAC and grants no permissions of its own. Decision/besluit authority during absence stays with the mandaat-matrix (waarnemer on the decision date) and is out of scope here.ingebrekestellingRegisters and validates a formal ingebrekestelling (AWB 4:17), accepting it only when the termijn is genuinely overschreden and rejecting premature notices. A valid registration auto-creates the grace-period DwangsomBerekening starting 14 days after receipt; only the first valid notice forms the dwangsom basis, so later notices are recorded for the audit trail without spawning a second berekening.inspection-checklistsProvide VTH inspection (toezicht) checklist support in Procest: a versioned inspection-checklist schema linked to case types, an admin UI for managing checklists, completion of checklists into inspection rapporten stored as case documents, and a case-dashboard inspection panel showing progress and rapport history.kcc-klantcontact-integratieProvides a customer-contact-centre (KCC) integration that surfaces caller context within one second of an inbound call (CTI popup with BRP identity, open cases, and contact history) and records every interaction as a structured ContactMoment. Omnichannel intake (phone, email, web form, chat, social media) feeds a routing engine that assigns each contact to the right team and suggests the best agent by workload, skill, and history, with callback scheduling and SLA tracking, status feedback to the originating agent, a volume/SLA reporting dashboard, an admin UI for routing rules, and NEN 7510/AVG-compliant data protection.kcc-werkplek-zaaksysteem-bridgeBridge the KCC-werkplek (contact-center workplek) to the Procest zaaksysteem so KCC-medewerkers get real-time case context on every inbound contact: automatic case-voorblad, contactmoment capture with audit trail, one-click quick-actions (status terugkoppelen, nieuwe zaak, klacht registreren, warm doorverbinden), datagedreven belplan-routering, and real-time sentiment detection. Burger is a Nextcloud contact entity (opaque pseudonymous reference, no PII schema, per ADR-022). Procest exposes the read/write API; the KCC-werkplek agent UI is rendered by pipelinq.Leges Fees@e2e exclude Leges fee calculation is V1; calculation engine and export are backend services not testable via Playwright.leges-heffingenAutomates municipal leges (administrative fees) from verordening to invoice: it imports an annual legesverordening from a decidesk raadsbesluit, calculates the correct tariff automatically on case creation (fixed, staffel, and variant tariffs fixed at the case start date), and applies adopted discounts and exemptions. Calculated leges create an invoice in shillinq accounts-receivable with payment synchronisation, support phase-based refunds on withdrawn applications and income-verified minima exemptions, and keep a full audit trail per calculation plus a concept-to-vastgesteld verordening review workflow.mandaat-matrixProvides a mandate matrix that decides, in real time, whether a user is authorized to take a given case decision, resolving their current role, evaluating the applicable mandate's conditions (including spending plafonds, waarnemer substitution, subdelegation rules, and conflict of interest) via an ABAC policy engine. Insufficient authority is blocked and escalated to the next-higher mandaathouder for approval or rejection, every authorized decision is captured in an immutable write-once MandaatGebruik audit log against the effective-dated mandate version, and the capability includes decidesk import of mandate besluiten, an admin panel, and a user-facing bevoegdheden view.Map Component@e2e exclude Map component is V1; Leaflet rendering and GIS proxy scenarios require geospatial test data not available in CI.MCP Integration@e2e exclude Backend MCP tool provider; invoked by AI orchestrator, not via browser UI.Milestone Tracking@e2e exclude Milestone tracking is V1; milestone API endpoints are covered by PHPUnit, not Playwright.mobiel-inspectie-offlineLets field inspectors work fully offline: they synchronize the day's cases, checklists, historical documents, and map tiles to local storage, then complete checklists, capture GPS-tagged photos (client-side compressed with EXIF), record voice memos for later transcription, and draw map annotations without network connectivity. Changes are queued locally and automatically replayed in order with exponential backoff on reconnection, concurrent edits and lost permissions are surfaced as conflicts the inspector resolves, and all resolution decisions are recorded in an immutable, AVG-compliant audit trail.Multi-Tenancy@e2e exclude Tenant provisioning is a backend REST API; UI renders via manifest, not custom Playwright-testable views.My Work (Werkvoorraad)My Work is the personal productivity hub for case handlers. It aggregates all work items assigned to the current user -- cases where they are the handler and tasks assigned to them -- into a single prioritized view. Items are grouped by urgency (Overdue, Due This Week, Upcoming, No Deadline) and sorted by priority then deadline within each group. This view answers the daily question: "What do I need to work on next?"nav-dedup-and-groupingCleans up the procest left navigation so no group and its child share the same label, relabelling the duplicate "Cases" and "Analytics" leaves and retiring the duplicate substitution entry while keeping every page routable. It introduces a "Work" group for the operational work-queue surfaces and completes the Cases and Analytics groups with their dossier and reporting surfaces, implemented purely through src/manifest.json and src/menu-layout.json with no backend, schema, or engine changes.objections-appeals-nav-groupPresents the objections-and-appeals (bezwaar & beroep) domain as a single top-level navigation group instead of six scattered flat entries, with its five transactional surfaces rendered as children in a coherent workflow order. Every grouped page stays routable at its existing route, and the change is a pure information-architecture edit limited to src/menu-layout.json and src/manifest.json ordering, touching no schema, controller, route, or decision flow.open-raadsinformatieProvides a pre-configured "Open Raadsinformatie" (ORI) register that publishes Dutch municipal council information — meetings, agenda items, documents, votes, council members, and factions — as publicly accessible, searchable open data. It models the full ORI entity set with validation and relationships, ships realistic demo data, and supports importing council data from source systems such as iBabs and NotuBiz via OpenConnector to meet Wet open overheid transparency requirements.OpenRegister Integration@e2e exclude Pure data-layer plumbing spec; store/register/schema setup is covered by PHPUnit repair-step tests.Ops Observability@e2e exclude Pure health-check endpoint covered by integration tests; no Playwright UI surface.parafering-audit-via-orRoutes every parafering (sign-off route) transition through OpenRegister's immutable audit trail instead of a dedicated procest audit schema. Each transition emits an OR audit entry tagged `procest.parafering.{transition}` carrying full route, actor, state-change, and delegation context, so the complete approval history is discoverable and hash-chain-verifiable via the OR audit API. Existing legacy records remain readable, and OR's native immutability removes the need for an app-specific append-only validator.parafering-dashboardThe parafering dashboard provides the secretariaat and case handlers with an overview of active voorstellen and their parafering status, a personal parafering inbox, reminder actions for overdue steps, and sidebar navigation to the dashboard at `/voorstellen`.parafering-via-or-approvalDefine the procest-side contract for routing parafering (signing-route) chains through OpenRegister's `approval-workflow` capability (ADR-022). Procest's consumer-facing API surface is preserved; chain-state, role enforcement, advance-on-approval and decision history are delegated to OpenRegister's `ApprovalChain` / `ApprovalStep` entities via the `ParaferingApprovalBridge` seam. The deprecated `Parafeerroute` schema remains read-only until sunset.pdok-consumerDefines the procest-side contract for routing all PDOK Locatieserver access through the openconnector PDOK adapter (`/index.php/apps/openconnector/api/pdok/*`) instead of calling `api.pdok.nl` directly from the browser. procest's `src/services/pdokService.js` is a thin shim that preserves the six existing exports (`suggest`, `lookup`, `free`, `reverse`, `extractCoordinates`, `formatAddress`) so no caller changes, delegates the four network functions to openconnector, and degrades gracefully on HTTP 503 (PDOK unavailable) and HTTP 404 (openconnector absent). Per ADR-022 (apps consume OR/openconnector abstractions).PDOK Integration@e2e exclude Backend geodata service integration; tile/geocoder calls are covered by service-level tests, not browser E2E.process-step-configuration@e2e exclude Process step configuration is V1; drag-and-drop step reorder in the workflow editor is not testable in the current build.procest-app-scaffold@e2e exclude App scaffold plumbing (PHP classes, build system, repair step); covered by PHPUnit and smoke tests.procest-canonical-store-apiDefines the canonical OpenRegister object-store API contract for all procest Pinia stores: collections via `fetchCollection(type, {_filters[field]: value})`, single loads via `fetchObject`, create/update via `saveObject`, deletes via `deleteObject`, and file attachments via `uploadFiles`. Replaces the phantom `create/update/delete` methods and the wrong `filters:{}` shape.procest-case-management@e2e exclude Superseded by canonical case-management and task-management specs; data model tests covered by PHPUnit.procest-config-to-settingsGroups all of procest's configuration and admin navigation leaves under a single Settings menu node so they no longer clutter the top level of the primary navigation. Operational surfaces such as live fee calculations and the Termijnbewaking KPI dashboard stay in the working navigation, and the relocation touches only the menu structure — every relocated page remains reachable by its existing route, with no new pages, schemas, or business logic introduced.procest-object-store@e2e exclude Pinia store factory plumbing; store API compliance is covered by unit tests, not browser E2E.procest-procurement-complianceDefine procurement compliance for procest: drempelbedragen as a `ProcurementThreshold` register, declarative procedure-type recommendation, UEA/EML as registers (not PDF blobs), declarative compliance KPI widgets + notifications — anchored in Aw 2012 / EU threshold regulations, all data-driven per ADR-031.procest-procurement-contract-lifecycleDefine contract lifecycle management for procest: contracts as an OpenRegister `Contract` register governed by a `contract-lifecycle` caseType, with declarative lifecycle, e-signature via OpenConnector, docudesk-owned documents, declarative notifications + analytics — reusing procest's workflow-engine + parafering abstractions (ADR-022/031).procest-procurement-evaluation-awardDefine bid evaluation + award for procest: scoring as an `Evaluation` register (one per bid per evaluator), awards as additive fields on procest's existing `decision` register, data-driven scoring formulas, calibration as child cases, declarative standstill enforcement, and docudesk-generated award documents — anchored in Aw 2012 motiveringsplicht.procest-procurement-publication-platformDefine TED/OJEU + national notice publication for procest: notices as a `PublicationNotice` register, eForms standard-form codes as a `PublicationTemplate` register, declarative notice lifecycle, declarative material-change (wezenlijke-wijziging) detection with re-publication recommendation, publication via PSI slots — anchored in EU 2014/24 + Verordening 2019/1780 (eForms) + Aw 2012.procest-procurement-spend-analytics-integrationDefine the cross-app spend-analytics contract: procest emits procurement CloudEvents and exposes its registers via OR GraphQL; mydash consumes them at runtime to render spend analytics. Commitment side from procest, posting side from [future] financeq. RBAC stays OR-canonical; procest ships no analytics manifest entry (mydash owns the surface).procest-procurement-supplier-managementDefine the supplier (vendor) management surface for procest as case management: suppliers as an OpenRegister `Supplier` register, onboarding as a `supplier-onboarding` caseType, with declarative qualification, lifecycle, performance, portal-RBAC, and notifications reusing procest's existing case-management machinery and OR abstractions (ADR-022/031).procest-procurement-system-integrationDefine procest's external-procurement integration posture: procest declares logical connector slots (TenderNed, Mercell, Negometrix, Peppol, KvK, e-signature, ...) while OpenConnector owns transport (ADR-019). Inbound via OR's integration registry, slot mappings as schema metadata, failures surfaced as procest tasks — zero transport code in procest lib/.procest-procurement-tender-managementDefine tender (aanbesteding) management for procest: tenders as procest cases (`schema:Project`) with a complementary `Tender` register, multi-lot support via deelzaak, declarative lifecycle + termijnen/standstill calculations, Bids and TenderQuestions as registers, publication via PSI slots — anchored in Aw 2012 / ARW 2016 (ADR-022/031).procest-sociaal-domein-avg-consentEnforces AVG/GDPR-compliant handling of special-category personal data in sociaal-domein cases (WMO, Jeugdwet, Participatiewet). Every case must declare its data-category classification at creation, access is restricted to the case's wijkteam with data-driven guards, exports without recorded consent are automatically anonymized, and all reads are immutably audit-logged. It also tracks revocable citizen consent, statutory retention with archivaris-reviewed destruction, subject-access-requests, and data-breach incident reporting.procest-sociaal-domein-jeugdwetProvides the Jeugdwet (`jeugdwet-melding`) zaaktype for municipal youth-care casework, with a family-centered status lifecycle, gezinsplan drafting and consent workflow, and Multi-Disciplinary Overleg coordination. Because every case concerns minors, it enforces mandatory AVG classification, jeugdteam-scoped access with logged child-safety overrides, automatic anonymization of unconsented minutes, 20-year statutory retention, comprehensive audit logging, and subject-access-request support for both the child and parents.procest-sociaal-domein-participatiewetProvides the Participatiewet (`bijstandsaanvraag`) zaaktype for municipal social-assistance casework, enforcing a mandatory vermogens- and inkomenstoets before any benefit decision and auto-creating a re-integration trajectory when an applicant qualifies. It manages an income-focused status lifecycle, work-and-income-team access control, mandatory AVG financial classification, anonymized financial exports, audit logging, counter-services (tegenprestatie) decisions with periodic exemption review, and 10-year statutory retention with destruction proposals.procest-sociaal-domein-wmoProvides the WMO (`wmo-melding`) zaaktype for municipal social-support casework, driving the onderzoek → indicatiestelling → beschikking assessment flow with statutory deadline tracking and auto-generated beschikking letters. It enforces mandatory AVG classification, wijkteam-only access control, wettelijke termijn monitoring, re-evaluation scheduling, anonymized exports to external providers, 15-year statutory retention, and comprehensive audit logging of access to medical data.procest-store-migration@e2e exclude Pinia store migration spec; store API compliance is covered by unit tests, not browser E2E.procest-tenant-migrationMigrate procest's parallel `TenantService`, `TenantMiddleware`, and `TenantController` to consume OpenRegister's Organisation entity + tenant-lifecycle API, preserving all existing API endpoints and response shapes, plus a one-time idempotent data migration (`occ procest:migrate-tenants`) from procest's deprecated private `tenant` schema to OR Organisations. References `consume-or-tenant-fleet-wide` as the authoritative fleet policy.Prometheus Metrics Endpoint@e2e exclude Pure metrics endpoint covered by health/integration tests; no Playwright UI surface.property-definition-managementProvides admin tabs for managing the property definitions, document types, and decision types attached to a case type, completing the seven-tab case-type detail view. Property definitions declare domain-specific required fields with format validation, document types define a required-document checklist with direction and confidentiality classification, and decision types define the formal decision categories that can be recorded on cases.quality-gatesDefines the unified strict quality gate for procest: a single `composer check:strict` command that runs lint, PHPCS, PHPMD, Psalm, and PHPStan in sequence and fails on any violation, run on every pull request to `development`, `main`, or `beta`. It requires PHPMD to run with no baseline, keeps any PHPStan baseline minimal and documented, and pins the CI workflow to a served Codeberg runner so the gate is actually scheduled.related-case-linkingTyped peer relations between cases (RGBZ/ZRC `relevanteAndereZaken`): link a bezwaar to the originating besluit-zaak (`onderwerp`), a WOO request to its bronzaken, a toezicht case to the vergunning it follows (`vervolg`), an advies-deelproces contributing to a hoofdbehandeling (`bijdrage`). Relations are stored on the existing `case.relatedCases` field as `{caseId, aardRelatie, toelichting?}`, written symmetrically by `CaseRelationService`, guarded against self/duplicate/hierarchy-overlap with OR-RBAC read access to both cases, rendered on the case detail with RBAC-safe masking, and mapped bidirectionally to the ZRC Zaak `relevanteAndereZaken` field. Hierarchy (hoofdzaak/deelzaak) stays `deelzaak-support`'s concern and is explicitly not duplicated as a peer relation.remaining-decision-delegationDelegates procest's remaining decision and advice flows — beslissing-op-bezwaar, BAC/advies/consultatie, and voorstel-besluit registration — to decidesk Decisions via the OpenRegister integration registry, so decidesk makes the decision while procest stops running local decision state machines. Delegation fails closed when decidesk is unavailable, the resulting ZGW Besluit is materialized as a projection of the decidesk outcome, and procest retains its Awb and IDOR domain validation, ZGW case management, and an idempotent repair step that links in-flight cases forward without data loss.result-type-managementProvides admin tabs for managing the result types and role types attached to a case type. Result types define the allowed case outcomes with Archiefwet/Selectielijst-compliant archival rules, while role types restrict which participant roles are available when assigning case participants; both render in the case type detail view scoped to the current case type.role-based-step-routing@e2e exclude Role-based step routing is V1; role-filtered task generation is backend logic covered by PHPUnit.Roles & DecisionsRoles define the relationship between participants (Nextcloud users or external contacts) and cases -- who is involved and in what capacity. Results record the formal outcome of a completed case, linking to a predefined result type that controls archival rules. Decisions are formal administrative choices made on cases, with legal validity periods and publication requirements.Signalering WidgetsThe signalering (alerting) widgets provide proactive deadline awareness on the Procest dashboard. They surface time-sensitive alerts so case handlers can act before deadlines pass: cases approaching their processing deadline, tasks approaching their due date, and cases that have gone stagnant with no recent activity.status-transition-engine@e2e exclude Status transition guard engine is V1; guard evaluation logic is covered by unit tests, not browser E2E.StUF Integration@e2e exclude Pure SOAP/backend integration spec covered by PHPUnit; no Playwright UI surface.subsidieverlening-ketenProvides the end-to-end subsidy grant chain: multi-year beschikkingen with conditional voorschot schedules, AWB deadline (termijn) binding per lifecycle phase, verplichtingen tracking with evidence linking, interim reports (tussenrapportage) as typed sub-cases, and final settlement (vaststelling) with automatic terugvordering on overpayment. It also covers the open-data subsidieregister feed, bewijsstukken management with retention and archival handover, cofinanciering and EU state-aid checks, amendment (wijzigingsbeschikking) workflows, and management reporting.supplier-portalProvides a self-service portal where suppliers authenticate via eHerkenning and view their own tenders, contracts, invoices, KPIs, and case messages, scoped strictly to their organisation. It registers the supplier OpenRegister schemas and case types, enforces supplier-scoped access with audit logging and PII masking, and supports sensitive mutations such as IBAN changes through re-authentication and 4-eyes Procest workflows. It also surfaces expected payment dates, invoice age analysis, contract expiry warnings, renewal requests, and nightly-aggregated supplier KPIs with municipal benchmarks.Task ManagementTasks represent work items within a case. They follow CMMN 1.1 HumanTask concepts and are semantically typed as `schema:Action`. Tasks can be assigned to Nextcloud users, have due dates and priorities, and follow an independent lifecycle within the parent case. Tasks are the primary mechanism for distributing and tracking work across case handlers, advisors, and other participants.Template Library@e2e exclude Template library scenarios cover backend REST endpoints and file loading; activation is a backend service test, not Playwright.tenant-authInjects the tenant context into a signed JWT at login, including via eHerkenning SAML, and validates the token signature and tenant claim before any claim is trusted. It rejects forged or cross-tenant tokens with HTTP 401/403, logs the attempts, and alerts the security team after repeated cross-tenant failures, ensuring each request is bound to its own tenant for downstream isolation.tenant-billingEmits immutable billing events across the case lifecycle, including refunds that net prior charges, and exports pending events to Shillinq daily grouped by tenant and month with retry and deferral on failure. It keeps exports idempotent by only touching events without an invoiceRef and presents a tenant billing dashboard with current-month, year-to-date, forecast, invoice history, and quota status.tenant-complianceVerifies and documents multi-tenant correctness through a mandatory CI suite that proves no cross-tenant data leakage across overlapping IDs, cross-tenant queries, injected tenant filters, and JWT token swaps. It includes an end-to-end onboarding test and a consolidated OpenAPI 3.0 specification for all tenant endpoints, and maintains tenant-stamped audit trails, BIO 2.0 enterprise context, and AVG deletion confirmation for regulatory compliance.tenant-configurationPer-tenant configuration and branding for the multi-tenant SaaS: persists branding/locale/timezone/feature-flags, validates logo uploads (MIME + size), emits NL Design System CSS theming tokens, and sanitises enterprise custom CSS against an XSS-safe property whitelist.tenant-crud-lifecycleManages tenant records with an auto-generated unique slug, an initial onboarding status, and an isolation mode derived from the tier, rejecting duplicate slugs. It exposes admin-only CRUD and status-filterable list endpoints and enforces a lifecycle state machine on tenant status so only legal transitions are persisted.tenant-isolationProvides request-scoped tenant isolation for the multi-tenant SaaS deployment: a `TenantContext` singleton resolved from the `X-Tenant-Id` header, and middleware that sets the PostgreSQL `search_path` to the tenant's schema so every query is scoped to a single tenant regardless of injected filters.tenant-lifecycleSuspends, reactivates, and terminates tenants while gating access and synchronising billing with Shillinq. Suspension blocks new cases and pauses billing events while keeping existing cases visible; reactivation restores service and resumes billing; termination finalises billing, revokes API access, and archives tenant data for a retention period before deletion with an immutable deletion-confirmation log entry.tenant-mandateChecks a user's tenant role against the tenant's mandaat-matrix for each mandate-requiring action, allowing authorised actions and blocking unauthorised ones with HTTP 403 and a reason. Every decision is recorded in the audit trail, and the check fails closed by denying the action when the matrix cannot be resolved or the mandate service errors.tenant-onboardingInitialises a 7-step onboarding checklist for each new tenant and renders a progress dashboard showing per-step status and the next recommended step. It integrates Decidesk for contract e-signature via a signature-verified webhook and validates mandatory prerequisites before activating a tenant, transitioning it from onboarding to active and triggering quota initialisation on go-live.tenant-provisioningProvisions a dedicated PostgreSQL schema per tenant, cloning the application tables into it while leaving shared tables in the public schema, then seeds default zaaktype and mandaat-matrix templates and roles and emails the tenant admin a welcome link. Provisioning rolls back cleanly on failure, dropping any partial schema, and supports a database-per-tenant isolation mode for enterprise tenants with vault-stored credentials and per-tenant data-residency rules.tenant-quotasInitialises per-tenant quotas from tier templates and applies tier changes within one minute. It enforces quotas atomically per request with warn, throttle, and block modes, emitting soft-limit warnings at 80% and returning HTTP 429 with a quota-exceeded billing event and upgrade prompt at the limit, and resets monthly usage on a daily background job for quotas whose reset time has passed.tenant-schemasDeclares the seven OpenRegister schemas that model multi-tenant zaaksysteem data — Tenant, TenantConfiguration, TenantQuota, TenantUser, TenantMandate, TenantBillingEvent, and TenantOnboardingTask — with their documented properties, enums, and relations registered through the procest register template. It seeds tier quota-limit templates and a default-tenant onboarding template via the register repair step and ensures OpenRegister queries are tenant-scoped at materialisation so a query carrying a tenant context returns only that tenant's rows.termijn-bindingBinds every zaak to a matching TermijnDefinitie and auto-creates its TermijnInstance on case creation, calculating the legal deadline from the configured duration and recording a start event. Case creation is blocked when no definition exists for the zaaktype, and definition versioning never retroactively changes deadlines on existing instances.termijn-escalationRuns a daily termijn-scan that sends escalating notifications as deadlines approach at the 14-, 7-, and 2-day thresholds, widening the audience from handler to teamleader to afdelingsmanager. It marks passed deadlines as overschreden and detects expired hersteltermijnen, advising the handler on the AWB 4:5 next step without auto-continuing the termijn.termijn-pause-extensionManages hersteltermijn pauses and statutory extensions on a running TermijnInstance, pausing the deadline when an aanvraag is incomplete (AWB 4:5/4:15) and adding back only the unconsumed pause days on resume. It allows exactly one motivated extension (AWB 4:14), blocking a second unless an exceptional grond is supplied with supervisor approval, and records each change as a termijn event.termijn-reportingProduces termijn and dwangsom reporting for management and audit, including a quarterly KPI report per zaaktype and an annual dwangsom audit report for the jaarrekening, both exportable as CSV/JSON. It also exposes an aggregated dashboard KPI endpoint returning within-termijn percentage, average duration, overrun count, and dwangsom totals, cached and refreshed at least hourly.termijn-verification-adminVerifies the full termijn/dwangsom lifecycle end-to-end across the five canonical case paths and provides an admin UI to view, create, edit, and version TermijnDefinities so that changes affect only new cases. It also ships Dutch administrator and user documentation covering configuration, the daily-scan cronjob, AWB deadlines, pause and extension handling, and reporting.termijnbewaking-schemasDeclares the six OpenRegister schemas for the termijn/dwangsom engine — TermijnDefinitie, TermijnInstance, TermijnGebeurtenis, Ingebrekestelling, DwangsomBerekening, and DwangsomUitbetaling — with their documented properties, enums, and relations so every consumer reads the same canonical shape. It also seeds three demo TermijnDefinities (Omgevingsvergunning-regulier, Wmo-aanvraag, and Woo-verzoek) via the register repair step so the engine has working configuration out of the box.unit-test-coverageEnsures the Procest backend is covered by automated tests: every PHP service and controller class has a matching PHPUnit test exercising construction, main methods, and error handling, and a Newman/Postman collection validates the end-to-end ZGW API workflow. A coverage threshold of at least 75% of source files having a corresponding test guards against untested code reaching production.visual-workflow-editor@e2e exclude Visual workflow editor is V1; drag-and-drop canvas interactions require a built workflow editor component not yet integrated into the admin settings.vth-admin-settingsProvides administrators a single VTH configuration page with tabs for Workflows, Leges Rules, Beschikking Templates, Inspection Checklists, and DSO Settings. Administrators can manage the three VTH workflows, build versioned inspection checklists with reorderable typed items and a mobile preview, and configure validated DSO integration settings persisted via the SettingsService.vth-beschikking-generationGenerates a beschikking (permit decision) document from a versioned template by substituting case merge fields such as applicant, location, activities, and conditions, rendering a PDF, and attaching it to the case. Generation is blocked when required fields are missing and always uses the current template version, and an admin UI lets staff create, edit, and test-generate templates with a merge-field picker and validity dates.vth-case-type-seed@e2e exclude Seed data imported via repair step; data presence is covered by PHPUnit repair-step tests.vth-config-foundationEstablishes the foundational VTH configuration data through idempotent repair steps: declarative workflow templates for the three VTH case kinds (Omgevingsvergunning, Toezichtzaak, Handhavingszaak), the complete 16-cell LHSO intervention matrix, and nine realistic Dutch seed cases. A master repair step loads workflow templates, leges rule sets, beschikking templates, inspection checklists, the LHSO matrix, and seed cases in dependency order without creating duplicates on repeated runs.vth-dso-integrationIntegrates DSO (Digitaal Stelsel Omgevingswet) permit requests with VTH case handling by auto-creating cases from a DSO verzoek, mapping STAM 2.0 fields, and flagging cases for manual initiator linking when a BRP lookup fails. Dispatches status-change events on case transitions so OpenConnector can push status back to DSO-LV, and tracks DSO case deadlines daily with warnings before flagging overdue cases.vth-leges-config-uiProvides an administrator UI to view and edit leges rule sets — base fee, modifiers, exemptions, verrekening, and teruggaaf — with input validation that rejects negative amounts and duplicate modifiers. Versions rule sets on save so existing cases keep their original rule version, with new rules taking effect for new cases from the next day.vth-leges-engineCalculates leges fees for a case from the active seeded rule set, returning the base fee, applied modifiers, and total. Supports offsetting prior fees (verrekening), refunds (teruggaaf), and additional billing (navordering), and exposes authenticated leges endpoints that log every transaction in an audit trail.vth-lhso-classificationProvides an LHSO lookup service and endpoints that return the full 16-cell matrix and a single intervention suggestion for a validated gedrag×gevolgen pair, rejecting out-of-range inputs. Surfaces a classification panel in the Handhavingszaak detail that shows the suggested intervention and requires an override reason when the handler chooses a different intervention.vth-mobile-inspectionEnables field inspectors to carry out inspections on mobile devices through a service that returns a mobile-formatted checklist, uploads photos to Nextcloud, captures GPS with a manual fallback, and submits a validated inspection result. Provides a responsive single-column UI with type-specific inputs, a progress indicator, navigation, and offline draft support that syncs when connectivity returns.vth-moduleProvides the VTH (Vergunningen, Toezicht en Handhaving) capability for permit, supervision, and enforcement processes, including DSO/Omgevingsloket intake, completeness checks (ontvankelijkheidstoets), inspection checklists, enforcement strategies (LHS), supervision planning, advice management, and Omgevingswet procedure deadlines. Ships pre-configured VTH case type templates and supports decision publication (bekendmaking), mobile inspection workflows, and configurable DSO intake field mapping.vth-quality-docsVerifies that the VTH services do not duplicate existing functionality and documents all reused components in a "Reuse Analysis". Requires VTH classes and public methods to carry `@spec` traceability tags and follow the 3-layer architecture with no custom mappers for domain data, and documents the VTH configuration architecture — workflow template structure, leges calculation, DSO integration, and mobile inspection — for future developers.vth-testingProvides test coverage for the VTH capability, including unit tests for leges calculation, beschikking handling, LHSO lookups, DSO mapping, and mobile photo/GPS/validation logic. Adds integration tests for the three VTH workflow transition paths with guard validation and notifications, plus an end-to-end test of the DSO verzoek → case creation → status-pushback flow.vth-workflow-templates@e2e exclude Workflow template is a JSON data file imported via backend; no dedicated Playwright UI test surface.WMS/WFS Layer Support@e2e exclude WMS/WFS layer configuration is V1; GIS proxy and map layer scenarios require external OGC services not available in CI.woo-case-typeProvides a pre-configured WOO-verzoek zaaktype template that municipalities activate from a template library and customize, defining the eight statutory processing stages, a WOO-specific intake form, and 28-day deadline tracking with statutory extension. It supports document collection and inventory, per-document disclosure assessment with mandatory weigeringsgronden, Docudesk redaction, formal besluit recording, publication to a reading room and PLOOI, bezwaar-period tracking, and WOO reporting.workflow-definition-engineProvides a configurable workflow engine where functional administrators define case lifecycles as OpenRegister objects, with process steps, guarded status transitions (checklist, required field, required document, role), and automatic actions (email, task, sub-case, webhook, set-field, notify). It supports workflow versioning that pins running cases to their bound version, workflow inheritance, JSON export/import, REST endpoints for CRUD and transition execution, and visual editing without developer involvement.workflow-definition-model@e2e exclude Workflow definition model is V1; data model and step validation are backend concerns covered by PHPUnit.workflow-import-export@e2e exclude Workflow import/export is V1; file download/upload flows require OS-level file dialogs, not testable in headless Playwright.zaakportaal-mijngemeenteZaakportaal ("Mijn gemeente") is a citizen-facing portal, delivered inside the host procest app, that grants authenticated burgers and bedrijven real-time access to their cases, ACL-filtered documents, status timelines, handler messaging, and objection (bezwaar) / complaint (klacht) filing — all IDOR-safe and audit-logged. Authentication (DigiD/eHerkenning, minimum trust level "substantieel", Machtigen/Ketenmachtiging) is established at the OpenConnector edge and surfaced as a pseudonymous subject reference; the host app never accepts or returns a raw BSN/KvK.zaaktype-versioning@e2e exclude Workflow template versioning is V1; immutable version management is backend logic covered by PHPUnit.ZGW API Mapping@e2e exclude Pure REST API spec covered by Newman/PHPUnit; no Playwright UI surface.ZGW Autorisaties (AC) API@e2e exclude Pure REST API spec covered by Newman/PHPUnit; no Playwright UI surface.ZGW Business Rules Compliance -- Delta Spec@e2e exclude Pure API delta spec covered by Newman test suite; no Playwright UI surface.