User story: permit-to-payment guided public administration process #9

New Issue

2026-07-14T14:06:34+02:00

zemion commented

2026-07-14 14:06:34 +02:00

User Story

As a resident or applicant, I want to apply for a permit through a public portal, upload the required evidence, follow the status of my application, attend any required appointment, receive the generated permit or decision, and complete payment where required, so that the whole administrative process is understandable and reliable.

As an internal case worker, I want GovOPlaN to create the right case, workflow, tasks, evidence links, appointments, generated documents, communications, payment evidence, and audit trail automatically or semi-automatically, so that I can focus on review and decisions instead of manually coordinating every system step.

Reference Journey

This is the previously documented permit-to-payment story. It is the Wave 1 reference process in govoplan-core/docs/GOVOPLAN_MASTER_ROADMAP.md and is also tracked by GovOPlaN/govoplan-core#214 as the configuration-package implementation target.

A person applies for a permit through the public portal.
Forms runtime receives the submission, validation result, attachments, and submission evidence.
Workflow starts a process instance and asks cases to create a durable case record.
Files/DMS links uploaded evidence to the case.
Tasks assigns intake/review work to the responsible role or function.
Workflow moves the case through intake, review, appointment/booking, decision, document generation, communication, payment, and closure.
Templates/DMS generates the permit or rejection/decision document.
Postbox, mail, and notifications inform the applicant and internal actors.
Calendar, appointments, or booking handle appointment handoff where needed.
Payments, ledger, and XRechnung record payment and accounting evidence.
Audit and records retain the trace of decisions, generated artifacts, communications, and retention state.

Product Shape

The story should become an installable demo/configuration package that wires existing modules into one complete public-administration process. The package should configure the involved forms, case type, workflow definition, task queues, document templates, appointment/payment handoffs, notifications, and user-facing documentation.

The operator experience should be guided: users should see where they are in the process, which action is pending, what evidence exists, what the next module handoff will do, and how to return to the process after leaving it.

Module Touchpoints

Likely participating modules:

module/portal: public entry point and applicant-facing status surface.
module/forms: application form, validation, drafts, submission evidence.
module/files: uploaded evidence and generated artifact links.
module/cases: durable administrative case record.
module/workflow: state machine, handoffs, waits, retries, and progress.
module/tasks: internal review and follow-up tasks.
module/templates: permit/decision document generation.
module/permits: permit/license domain records and lifecycle semantics.
module/postbox, module/mail, module/notifications: applicant and internal communication.
module/calendar, module/appointments: appointment/booking handoff.
module/payments, module/ledger, module/xrechnung: payment and accounting evidence.
module/audit, module/records: traceability and retention.

Acceptance Criteria

A permit-to-payment configuration package can be installed in a local demo environment.
The package creates or references the needed form, case type, workflow definition, task queues, templates, notification rules, and handoff settings.
An applicant can submit a permit application with evidence through the portal/forms path.
The submission creates a case, workflow instance, evidence links, and an internal task.
A case worker can review the application from a guided workflow/case surface.
A workflow step can hand off to appointments/calendar/booking when an appointment is required.
A workflow step can generate a permit or decision document through templates/DMS.
A workflow step can trigger applicant communication through postbox/mail/notifications.
A payment handoff can capture payment evidence and link it to the case/workflow.
Every cross-module action is represented as a capability call, event, DTO, or configuration-package contract, not a direct module import.
Every major step produces audit evidence and user-facing documentation reflects the configured process.

Decisions and remaining composition questions (2026-09-08)

Confirmed flagship: resident parking permit / Anwohnerparkausweis, without replacing the more precise backlog stories.
Applicant status is owned by Forms Runtime and exposed through a bounded Core capability; authenticated access, short-lived email links/resend, and permanent links are configurable policies, not a single product-mandated access mode.
The executable configuration-package foundation, bindings, preflight and guided apply/export/recovery are implemented under Core #214.
Payment request/reconciliation evidence is implemented; concrete target-provider integration and its acceptance remain separate work. No live payment-provider policy is selected by this reconciliation.
Remaining composition-specific questions concern permit-domain extensions and appointment/payment/provider handoffs beyond the published fixture; decide them against the precise owning stories rather than reopening the confirmed flagship/status choices.

First Vertical Slice Candidate

A pragmatic first slice:

Simple public permit application form with one uploaded evidence file.
Case creation and workflow start.
One internal review task.
Manual approve/reject transition.
Generated decision document.
Applicant notification.
Audit timeline and configured-process documentation.

Payment and appointment handoff can follow once the basic cross-module chain is proven.

## User Story As a resident or applicant, I want to apply for a permit through a public portal, upload the required evidence, follow the status of my application, attend any required appointment, receive the generated permit or decision, and complete payment where required, so that the whole administrative process is understandable and reliable. As an internal case worker, I want GovOPlaN to create the right case, workflow, tasks, evidence links, appointments, generated documents, communications, payment evidence, and audit trail automatically or semi-automatically, so that I can focus on review and decisions instead of manually coordinating every system step. ## Reference Journey This is the previously documented permit-to-payment story. It is the Wave 1 reference process in `govoplan-core/docs/GOVOPLAN_MASTER_ROADMAP.md` and is also tracked by `GovOPlaN/govoplan-core#214` as the configuration-package implementation target. 1. A person applies for a permit through the public portal. 2. Forms runtime receives the submission, validation result, attachments, and submission evidence. 3. Workflow starts a process instance and asks cases to create a durable case record. 4. Files/DMS links uploaded evidence to the case. 5. Tasks assigns intake/review work to the responsible role or function. 6. Workflow moves the case through intake, review, appointment/booking, decision, document generation, communication, payment, and closure. 7. Templates/DMS generates the permit or rejection/decision document. 8. Postbox, mail, and notifications inform the applicant and internal actors. 9. Calendar, appointments, or booking handle appointment handoff where needed. 10. Payments, ledger, and XRechnung record payment and accounting evidence. 11. Audit and records retain the trace of decisions, generated artifacts, communications, and retention state. ## Product Shape The story should become an installable demo/configuration package that wires existing modules into one complete public-administration process. The package should configure the involved forms, case type, workflow definition, task queues, document templates, appointment/payment handoffs, notifications, and user-facing documentation. The operator experience should be guided: users should see where they are in the process, which action is pending, what evidence exists, what the next module handoff will do, and how to return to the process after leaving it. ## Module Touchpoints Likely participating modules: - `module/portal`: public entry point and applicant-facing status surface. - `module/forms`: application form, validation, drafts, submission evidence. - `module/files`: uploaded evidence and generated artifact links. - `module/cases`: durable administrative case record. - `module/workflow`: state machine, handoffs, waits, retries, and progress. - `module/tasks`: internal review and follow-up tasks. - `module/templates`: permit/decision document generation. - `module/permits`: permit/license domain records and lifecycle semantics. - `module/postbox`, `module/mail`, `module/notifications`: applicant and internal communication. - `module/calendar`, `module/appointments`: appointment/booking handoff. - `module/payments`, `module/ledger`, `module/xrechnung`: payment and accounting evidence. - `module/audit`, `module/records`: traceability and retention. ## Acceptance Criteria - A permit-to-payment configuration package can be installed in a local demo environment. - The package creates or references the needed form, case type, workflow definition, task queues, templates, notification rules, and handoff settings. - An applicant can submit a permit application with evidence through the portal/forms path. - The submission creates a case, workflow instance, evidence links, and an internal task. - A case worker can review the application from a guided workflow/case surface. - A workflow step can hand off to appointments/calendar/booking when an appointment is required. - A workflow step can generate a permit or decision document through templates/DMS. - A workflow step can trigger applicant communication through postbox/mail/notifications. - A payment handoff can capture payment evidence and link it to the case/workflow. - Every cross-module action is represented as a capability call, event, DTO, or configuration-package contract, not a direct module import. - Every major step produces audit evidence and user-facing documentation reflects the configured process. ## Decisions and remaining composition questions (2026-09-08) - Confirmed flagship: resident parking permit / `Anwohnerparkausweis`, without replacing the more precise backlog stories. - Applicant status is owned by Forms Runtime and exposed through a bounded Core capability; authenticated access, short-lived email links/resend, and permanent links are configurable policies, not a single product-mandated access mode. - The executable configuration-package foundation, bindings, preflight and guided apply/export/recovery are implemented under [Core #214](https://git.add-ideas.de/GovOPlaN/govoplan-core/issues/214). - Payment request/reconciliation evidence is implemented; concrete target-provider integration and its acceptance remain separate work. No live payment-provider policy is selected by this reconciliation. - Remaining composition-specific questions concern permit-domain extensions and appointment/payment/provider handoffs beyond the published fixture; decide them against the precise owning stories rather than reopening the confirmed flagship/status choices. ## First Vertical Slice Candidate A pragmatic first slice: 1. Simple public permit application form with one uploaded evidence file. 2. Case creation and workflow start. 3. One internal review task. 4. Manual approve/reject transition. 5. Generated decision document. 6. Applicant notification. 7. Audit timeline and configured-process documentation. Payment and appointment handoff can follow once the basic cross-module chain is proven.

zemion added the area/governance codex/ready module/appointments module/files module/forms module/payments module/permits module/portal module/workflow

labels 2026-07-29 14:15:06 +02:00

zemion commented

2026-08-19 02:47:15 +02:00

Codex State: progress

Summary

Kept Anwohnerparkausweis as the flagship and added digital/assisted parity for the exact resident-parking Form revision (govoplan 69519a9; Forms Runtime d83bb92).
The executable journey now proves an authenticated assisted session survives a database-session restart, cannot submit without current payload-bound read-back evidence, and submits under the same Form validation contract as digital intake.
This advances intake-to-decision without collapsing the more precise backlog stories into the flagship fixture.

Changed Files

tests/fixtures/resident_parking_permit_journey.json
tests/test_institutional_service_journey.py
packages/product/service-to-decision/README.md

Verification

tests/test_institutional_service_journey.py — 5 passed
tools/checks/check-manifest-shapes.py — passed for 67 manifests
tools/checks/check-focused.sh — passed

Next / Blocked

Implement the applicant-facing status projection and notification timeline as the next independently testable slice.
Then add the governed payment request/reconciliation slice; keep appointment booking optional and composition-driven.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Kept Anwohnerparkausweis as the flagship and added digital/assisted parity for the exact resident-parking Form revision (govoplan 69519a9; Forms Runtime d83bb92). - The executable journey now proves an authenticated assisted session survives a database-session restart, cannot submit without current payload-bound read-back evidence, and submits under the same Form validation contract as digital intake. - This advances intake-to-decision without collapsing the more precise backlog stories into the flagship fixture. ### Changed Files - `tests/fixtures/resident_parking_permit_journey.json` - `tests/test_institutional_service_journey.py` - `packages/product/service-to-decision/README.md` ### Verification - `tests/test_institutional_service_journey.py — 5 passed` - `tools/checks/check-manifest-shapes.py — passed for 67 manifests` - `tools/checks/check-focused.sh — passed` ### Next / Blocked - Implement the applicant-facing status projection and notification timeline as the next independently testable slice. - Then add the governed payment request/reconciliation slice; keep appointment booking optional and composition-driven. Suggested status label: `status/in-progress`

zemion referenced this issue from GovOPlaN/govoplan-payments

2026-08-19 12:18:26 +02:00

Add guided payment request and manual reconciliation WebUI #1

zemion commented

2026-08-19 12:31:25 +02:00

Codex State: progress

Summary

Implemented configurable resident application-status access with authenticated, short-lived email-link/resend, and permanent-link policies owned by Forms Runtime and projected through a bounded Core capability.
Extended the resident parking permit reference journey to verify tenant-safe email recovery, token revocation on resend, bounded status projection, and payment request/reconciliation.
Promoted Payments from a seed repository to a replay-safe vertical backend slice and opened GovOPlaN/govoplan-payments#1 for its guided shared-layout WebUI.

Verification

68/68 manifest shape checks pass
Dependency-boundary, strict endpoint inventory, package-workflow sync, developer-meta sync, and version-alignment checks pass
Module tests, Core contracts, flagship journey tests, Ruff, TypeScript, shared layout/primitive/foundation checks pass

Next / Blocked

The full focused gate requires the newly introduced govoplan-payments v0.1.19 package tag. Tagging triggers external package publication, so this is waiting for explicit publication approval.
After publication, rerun tools/checks/check-focused.sh and push the cohesive cross-repository change set.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Implemented configurable resident application-status access with authenticated, short-lived email-link/resend, and permanent-link policies owned by Forms Runtime and projected through a bounded Core capability. - Extended the resident parking permit reference journey to verify tenant-safe email recovery, token revocation on resend, bounded status projection, and payment request/reconciliation. - Promoted Payments from a seed repository to a replay-safe vertical backend slice and opened GovOPlaN/govoplan-payments#1 for its guided shared-layout WebUI. ### Verification - `68/68 manifest shape checks pass` - `Dependency-boundary, strict endpoint inventory, package-workflow sync, developer-meta sync, and version-alignment checks pass` - `Module tests, Core contracts, flagship journey tests, Ruff, TypeScript, shared layout/primitive/foundation checks pass` ### Next / Blocked - The full focused gate requires the newly introduced govoplan-payments v0.1.19 package tag. Tagging triggers external package publication, so this is waiting for explicit publication approval. - After publication, rerun tools/checks/check-focused.sh and push the cohesive cross-repository change set. Suggested status label: `status/in-progress`

zemion commented

2026-08-19 12:49:22 +02:00

Codex State: ready

Summary

All five scoped changes are committed locally: Core 5a2e99f, Forms Runtime 87d1251, Portal 89a142e, Payments 630a7d3, workspace f8b0688.
A local-only Payments v0.1.19 release tag was created to validate the exact package artifact; the remote has no v0.1.19 tag.

Verification

tools/checks/check-focused.sh passed end-to-end, including 56 WebUI permutations, full-product bundle budgets, and 4 Playwright conformance scenarios

Next / Blocked

Explicit approval is needed to push the five commits and Payments v0.1.19 tag, because pushing the tag triggers external package publication.
After publication, the next UI work should formalize page archetypes and semantic action-bar rules, then enforce and migrate them across modules.

Suggested status label: status/ready

## Codex State: ready ### Summary - All five scoped changes are committed locally: Core 5a2e99f, Forms Runtime 87d1251, Portal 89a142e, Payments 630a7d3, workspace f8b0688. - A local-only Payments v0.1.19 release tag was created to validate the exact package artifact; the remote has no v0.1.19 tag. ### Verification - `tools/checks/check-focused.sh passed end-to-end, including 56 WebUI permutations, full-product bundle budgets, and 4 Playwright conformance scenarios` ### Next / Blocked - Explicit approval is needed to push the five commits and Payments v0.1.19 tag, because pushing the tag triggers external package publication. - After publication, the next UI work should formalize page archetypes and semantic action-bar rules, then enforce and migrate them across modules. Suggested status label: `status/ready`

zemion referenced this issue

2026-08-20 23:53:47 +02:00

[Privacy] Complete DSAR provider coverage across data-owning modules #47

zemion referenced this issue

2026-08-21 03:49:35 +02:00

[Privacy] Complete DSAR provider coverage across data-owning modules #47

zemion commented

2026-09-08 05:27:53 +02:00

Status reconciliation — 2026-09-08

The publication wait in comment 19169 is resolved. All five named commits are ancestors of the published source trees, and the formerly local-only Payments v0.1.19 tag is remote: annotated object 9c8fdba7f5b0c2d48b19c2668d213b2980a85c68, peeled commit 630a7d39f776d18ae2d6c337c7420de4e8d7629e. Current composition includes Payments v0.1.22 and Core/Meta v0.1.45; see verified publication.

The bounded configuration-package implementation is complete under Core #214. Configurable authenticated, expiring email-link/resend and permanent-link status access, request/reconciliation payment evidence, and the Anwohnerparkausweis fixture are published. The completed release focused check includes 63 module combinations and 213 browser cases. The later digital/assisted browser and provenance work is tracked in Meta #42.

This broader journey stays in progress: full composition-specific handoffs, physical screen-reader checks, named archive/recovery evidence and target-provider acceptance must be verified, not inferred from source publication. Runtime and public-site deployment remain separately held under #52 and website #9. No live settings, booking, payment or provider effect was performed. The original decision list has been reconciled below so already-approved flagship/status choices are not asked again.

## Status reconciliation — 2026-09-08 The publication wait in comment 19169 is resolved. All five named commits are ancestors of the published source trees, and the formerly local-only Payments v0.1.19 tag is remote: annotated object `9c8fdba7f5b0c2d48b19c2668d213b2980a85c68`, peeled commit `630a7d39f776d18ae2d6c337c7420de4e8d7629e`. Current composition includes Payments v0.1.22 and Core/Meta v0.1.45; see [verified publication](https://git.add-ideas.de/GovOPlaN/govoplan/issues/51#issuecomment-19949). The bounded configuration-package implementation is complete under [Core #214](https://git.add-ideas.de/GovOPlaN/govoplan-core/issues/214). Configurable authenticated, expiring email-link/resend and permanent-link status access, request/reconciliation payment evidence, and the Anwohnerparkausweis fixture are published. The completed release focused check includes 63 module combinations and 213 browser cases. The later digital/assisted browser and provenance work is tracked in [Meta #42](https://git.add-ideas.de/GovOPlaN/govoplan/issues/42). This broader journey stays in progress: full composition-specific handoffs, physical screen-reader checks, named archive/recovery evidence and target-provider acceptance must be verified, not inferred from source publication. Runtime and public-site deployment remain separately held under #52 and website #9. No live settings, booking, payment or provider effect was performed. The original decision list has been reconciled below so already-approved flagship/status choices are not asked again.

zemion added

and removed

labels 2026-09-08 05:27:53 +02:00

Sign in to join this conversation.