[Feature] Implement definition-aware Forms Runtime and Service launcher #1

Closed
opened 2026-08-01 14:53:10 +02:00 by zemion · 2 comments
Owner

Outcome

Implement the definition-aware Forms Runtime vertical required to launch a form-bound institutional Service without weakening validation, tenant isolation, provenance, or recovery guarantees.

Acceptance criteria

  • Resolve one immutable form definition and exact revision through a provider-neutral Forms capability.
  • Persist tenant-bound draft/submission identities, immutable status history, validation results, attachment/signature references, and case/workflow/record/evidence handoffs.
  • Validate schema, policy, and current access on the server before draft persistence and final submission.
  • Make create/retry replay-safe and draft updates optimistic-concurrency guarded.
  • Provide bounded APIs and an accessible runtime WebUI without importing Forms, Files, Cases, Workflow, or Portal tables.
  • Provide forms_runtime.service_launcher using Core ServiceLaunchRequest/ServiceLaunchResult, retaining the exact Service and binding and returning a same-tenant submission target.
  • Add migrations, uninstall guards, permissions, committed events/audit context, recovery documentation, and tests for tenant isolation, stale writes, replay conflicts, invalid definitions, and failed handoffs.
  • Keep Portal form entries explainably unavailable until the launcher and its required definition provider are active.

Boundary

Forms owns immutable definitions and authoring. Forms Runtime owns instances and submissions. Portal owns discovery and launch delegation. Domain modules own adjudication and handoff targets. A placeholder that accepts arbitrary fields without resolving and validating a definition is not acceptable.

Reference: govoplan/docs/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md and govoplan-forms-runtime/docs/FORMS_RUNTIME_DOMAIN_BOUNDARY.md.

## Outcome Implement the definition-aware Forms Runtime vertical required to launch a form-bound institutional Service without weakening validation, tenant isolation, provenance, or recovery guarantees. ## Acceptance criteria - Resolve one immutable form definition and exact revision through a provider-neutral Forms capability. - Persist tenant-bound draft/submission identities, immutable status history, validation results, attachment/signature references, and case/workflow/record/evidence handoffs. - Validate schema, policy, and current access on the server before draft persistence and final submission. - Make create/retry replay-safe and draft updates optimistic-concurrency guarded. - Provide bounded APIs and an accessible runtime WebUI without importing Forms, Files, Cases, Workflow, or Portal tables. - Provide `forms_runtime.service_launcher` using Core `ServiceLaunchRequest`/`ServiceLaunchResult`, retaining the exact Service and binding and returning a same-tenant submission target. - Add migrations, uninstall guards, permissions, committed events/audit context, recovery documentation, and tests for tenant isolation, stale writes, replay conflicts, invalid definitions, and failed handoffs. - Keep Portal form entries explainably unavailable until the launcher and its required definition provider are active. ## Boundary Forms owns immutable definitions and authoring. Forms Runtime owns instances and submissions. Portal owns discovery and launch delegation. Domain modules own adjudication and handoff targets. A placeholder that accepts arbitrary fields without resolving and validating a definition is not acceptable. Reference: `govoplan/docs/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md` and `govoplan-forms-runtime/docs/FORMS_RUNTIME_DOMAIN_BOUNDARY.md`.
Author
Owner

Codex State: progress

Summary

  • Implemented definition-aware drafts/submissions, exact Service/Form provenance, validation, receipts, status history, handoff evidence, APIs, permissions, migrations, and accessible runtime WebUI.
  • Added forms_runtime.service_launcher and an executable Portal to exact Form revision journey.
  • Hardened replay so keys are actor-bound, exact retries survive schema supersession, mismatched providers fail closed, and client IDs cannot replace existing state.

Verification

  • 8 Forms Runtime tests pass, including fresh migrations and security regressions
  • Isolated access+portal+forms+forms_runtime startup smoke passes
  • 42 WebUI module permutations pass

Next / Blocked

  • Push the source changes, then close this issue.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Implemented definition-aware drafts/submissions, exact Service/Form provenance, validation, receipts, status history, handoff evidence, APIs, permissions, migrations, and accessible runtime WebUI. - Added forms_runtime.service_launcher and an executable Portal to exact Form revision journey. - Hardened replay so keys are actor-bound, exact retries survive schema supersession, mismatched providers fail closed, and client IDs cannot replace existing state. ### Verification - `8 Forms Runtime tests pass, including fresh migrations and security regressions` - `Isolated access+portal+forms+forms_runtime startup smoke passes` - `42 WebUI module permutations pass` ### Next / Blocked - Push the source changes, then close this issue. Suggested status label: `status/in-progress`
zemion added
status
in-progress
and removed
status
ready
labels 2026-08-01 16:30:18 +02:00
Author
Owner

Codex State: done

The verified implementation has been committed and pushed on main in 9dc49fe. The issue acceptance scope is complete; follow-on product depth remains tracked separately.

## Codex State: done The verified implementation has been committed and pushed on `main` in `9dc49fe`. The issue acceptance scope is complete; follow-on product depth remains tracked separately.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-forms-runtime#1