GovOPlaN/govoplan
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

[Epic] Adopt the institutional governance target architecture #29

New Issue
Closed
opened 2026-07-31 23:59:05 +02:00 by zemion · 6 comments
zemion commented 2026-07-31 23:59:05 +02:00
Owner
Copy Link
Copy Source

Outcome

Reconcile govoplan_concept_dev.md and software_big_picture.md with the implemented GovOPlaN platform so the product consistently acts as an institutional governance and operations layer for public institutions.

Canonical direction

Accepted reconciliation

The module runtime, versioned capability/interface graph, Workflow Engine/editor split, external-reference maturity contract, action/effect and outbox foundations, ownership recovery, Views, configured Docs, PostgreSQL Search, Datasources/Dataflow, and Encryption boundaries already exist. They are foundations to extend, not greenfield programs to reopen.

The missing semantic work is Mandates, Services, procedure Parties, formal Decisions, consistent provider source-authority declarations, governed data/register metadata, horizontal assurance, and evidence-backed product/sector packaging.

Work packages

Existing issues for Projects, Reporting, Portal, Cases, and the active reference program are amended rather than duplicated.

Acceptance criteria

  • Durable meta, Core, and owning-module documents agree on the target and current implementation state.
  • Existing issues are amended where they already own work; new issues cover only missing contracts or lifecycles.
  • Machine-readable module/provider metadata distinguishes runtime composition, maturity evidence, source authority, and integration capability.
  • One bounded journey proves mandate/authority, party/representation, formal decision, observed effect, and evidence reconstruction.
  • Configuration packages distinguish reference, product, sector, deployment, and integration profiles without gaining cross-module data ownership.
  • Gitea wiki pages mirror the canonical repository documents.
## Outcome Reconcile `govoplan_concept_dev.md` and `software_big_picture.md` with the implemented GovOPlaN platform so the product consistently acts as an institutional governance and operations layer for public institutions. ## Canonical direction - [Institutional Governance Target Architecture](https://git.add-ideas.de/GovOPlaN/govoplan/src/branch/main/docs/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md) - [Connected Governance Platform Roadmap](https://git.add-ideas.de/GovOPlaN/govoplan/src/branch/main/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md) - [Core Module Architecture](https://git.add-ideas.de/GovOPlaN/govoplan-core/src/branch/main/docs/MODULE_ARCHITECTURE.md) ## Accepted reconciliation The module runtime, versioned capability/interface graph, Workflow Engine/editor split, external-reference maturity contract, action/effect and outbox foundations, ownership recovery, Views, configured Docs, PostgreSQL Search, Datasources/Dataflow, and Encryption boundaries already exist. They are foundations to extend, not greenfield programs to reopen. The missing semantic work is Mandates, Services, procedure Parties, formal Decisions, consistent provider source-authority declarations, governed data/register metadata, horizontal assurance, and evidence-backed product/sector packaging. ## Work packages - [x] [Core module/provider metadata](https://git.add-ideas.de/GovOPlaN/govoplan-core/issues/279) - [x] [Core institutional reference primitives](https://git.add-ideas.de/GovOPlaN/govoplan-core/issues/280) - [x] [Mandates semantics](https://git.add-ideas.de/GovOPlaN/govoplan/issues/30) - [x] [Services semantics](https://git.add-ideas.de/GovOPlaN/govoplan/issues/31) - [x] [Parties semantics](https://git.add-ideas.de/GovOPlaN/govoplan/issues/32) - [x] [Decisions semantics](https://git.add-ideas.de/GovOPlaN/govoplan/issues/33) - [x] [Governed data/register catalogue](https://git.add-ideas.de/GovOPlaN/govoplan-datasources/issues/6) - [x] [Horizontal assurance graph](https://git.add-ideas.de/GovOPlaN/govoplan-risk-compliance/issues/7) - [x] [Product/sector package classes](https://git.add-ideas.de/GovOPlaN/govoplan/issues/34) - [x] [Configured architecture documentation](https://git.add-ideas.de/GovOPlaN/govoplan-docs/issues/19) Existing issues for Projects, Reporting, Portal, Cases, and the active reference program are amended rather than duplicated. ## Acceptance criteria - Durable meta, Core, and owning-module documents agree on the target and current implementation state. - Existing issues are amended where they already own work; new issues cover only missing contracts or lifecycles. - Machine-readable module/provider metadata distinguishes runtime composition, maturity evidence, source authority, and integration capability. - One bounded journey proves mandate/authority, party/representation, formal decision, observed effect, and evidence reconstruction. - Configuration packages distinguish reference, product, sector, deployment, and integration profiles without gaining cross-module data ownership. - Gitea wiki pages mirror the canonical repository documents. <!-- codex-institutional-governance-architecture-2026-07-31 -->
zemion commented 2026-08-01 03:34:19 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: progress

Summary

  • Completed Core #279 (validated architecture/provider declarations), Core #280 (institutional context contracts), and Datasources #6 (governed catalogue).
  • Added portable Mandate, Service, Party, and Decision contracts plus a bounded Committee authority-to-decision proof; their persistence/lifecycle issues remain open.
  • Added signed package classes and provider preflight, Docs/Ops projections, staged Risk/Projects architecture declarations, and release-catalog preservation.

Verification

  • Core, Audit, Access, Datasources, Docs, Ops, Committee, Risk, Projects, release synthesis, WebUI build, and 54-manifest workspace checks pass.

Next / Blocked

  • Continue with persistent semantic lifecycles, horizontal assurance, configured provider-health projection, and evidence-backed proof packages; do not close the epic yet.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Completed Core #279 (validated architecture/provider declarations), Core #280 (institutional context contracts), and Datasources #6 (governed catalogue). - Added portable Mandate, Service, Party, and Decision contracts plus a bounded Committee authority-to-decision proof; their persistence/lifecycle issues remain open. - Added signed package classes and provider preflight, Docs/Ops projections, staged Risk/Projects architecture declarations, and release-catalog preservation. ### Verification - `Core, Audit, Access, Datasources, Docs, Ops, Committee, Risk, Projects, release synthesis, WebUI build, and 54-manifest workspace checks pass.` ### Next / Blocked - Continue with persistent semantic lifecycles, horizontal assurance, configured provider-health projection, and evidence-backed proof packages; do not close the epic yet. Suggested status label: `status/in-progress`
zemion added
status
in-progress
 and removed
status
ready
 labels 2026-08-01 03:35:40 +02:00
zemion commented 2026-08-01 08:21:48 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: progress

Summary

  • Closed horizontal assurance (#7), package classes/proof artifacts (#34), and configured architecture documentation (#19); updated the epic checklist.
  • CalDAV now proves tenant-aware runtime binding state through Core, Access package preflight, Docs, and Ops.

Verification

  • Core 120, Calendar 119, Access 53, Docs 19, Ops 1, Risk Compliance 15 tests passed; TypeScript compile passed.

Next / Blocked

  • Mandates #30, Services #31, Parties #32, and the remaining second-domain formal Decision journey #33 remain open.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Closed horizontal assurance (#7), package classes/proof artifacts (#34), and configured architecture documentation (#19); updated the epic checklist. - CalDAV now proves tenant-aware runtime binding state through Core, Access package preflight, Docs, and Ops. ### Verification - `Core 120, Calendar 119, Access 53, Docs 19, Ops 1, Risk Compliance 15 tests passed; TypeScript compile passed.` ### Next / Blocked - Mandates #30, Services #31, Parties #32, and the remaining second-domain formal Decision journey #33 remain open. Suggested status label: `status/in-progress`
zemion commented 2026-08-01 08:52:28 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: progress

Summary

  • All ten architecture work packages are now closed; Mandates, Services, Parties, and Decisions have executable bounded proofs rather than placeholder repositories.
  • Portal and Cases are now installable headless modules, and the meta matrix includes a cross-repository Service-to-Case composition test.

Verification

  • Static contracts: 56 modules, 90 providers, 46 requirements; passed

Next / Blocked

  • Keep the epic open until one reference journey carries service, party, mandate, decision, observed effect, communication/record, and evidence reconstruction end to end.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - All ten architecture work packages are now closed; Mandates, Services, Parties, and Decisions have executable bounded proofs rather than placeholder repositories. - Portal and Cases are now installable headless modules, and the meta matrix includes a cross-repository Service-to-Case composition test. ### Verification - `Static contracts: 56 modules, 90 providers, 46 requirements; passed` ### Next / Blocked - Keep the epic open until one reference journey carries service, party, mandate, decision, observed effect, communication/record, and evidence reconstruction end to end. Suggested status label: `status/in-progress`
zemion commented 2026-08-01 09:01:42 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: done

Summary

  • The institutional-governance reconciliation is implemented as validated Core contracts, truthful provider/module declarations, bounded owner-module consumers, product artifacts, Ops/Docs projections, and an integrated executable journey.
  • The golden journey reconstructs Service, Case, Party/representation, Mandate/jurisdiction, approval, formal Decision, confirmed communication effect, Audit record, remedy/review, and evidence provenance.

Verification

  • Core module system: 120 tests passed
  • Core institutional contract: 13 tests passed
  • Portal: 7; Cases: 7; Committee: 3 tests passed
  • Meta package/service/governance fixtures: 3 tests passed
  • Dependency boundaries and 56-module static contract graph passed
  • Targeted Gitea wiki pages synchronized and verified

Next / Blocked

  • Further product maturity remains in the owning Portal, Cases, Committee, reference-journey, and persistence issues; semantic repository extraction remains threshold-based.
## Codex State: done ### Summary - The institutional-governance reconciliation is implemented as validated Core contracts, truthful provider/module declarations, bounded owner-module consumers, product artifacts, Ops/Docs projections, and an integrated executable journey. - The golden journey reconstructs Service, Case, Party/representation, Mandate/jurisdiction, approval, formal Decision, confirmed communication effect, Audit record, remedy/review, and evidence provenance. ### Verification - `Core module system: 120 tests passed` - `Core institutional contract: 13 tests passed` - `Portal: 7; Cases: 7; Committee: 3 tests passed` - `Meta package/service/governance fixtures: 3 tests passed` - `Dependency boundaries and 56-module static contract graph passed` - `Targeted Gitea wiki pages synchronized and verified` ### Next / Blocked - Further product maturity remains in the owning Portal, Cases, Committee, reference-journey, and persistence issues; semantic repository extraction remains threshold-based.
zemion commented 2026-08-01 10:34:51 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: done

Summary

  • The target architecture is implemented as an enforced vertical_slice/product architecture contract rather than a documentation-only proposal.
  • Mandates, Services, Parties, and Decisions now have independent persistent module owners with tenant isolation, immutable revisions, OCC, lifecycle validation, APIs, permissions, migrations, uninstall guards, recovery documentation, and provider capabilities.
  • Portal, Cases, and Committee consume those providers without cross-module table access. product.service-to-decision proves the complete SQL-backed path through service discovery, case intake, party representation, mandate resolution, formal decision, observed effect, audit/record evidence, and review references.
  • Provider governance, architecture metadata, package preflight, Docs/Ops projection, environment synchronization, and release tooling are machine-enforced across the workspace.
  • The canonical architecture page and all four module domain/recovery pages are synchronized to their Gitea wikis.

Verification

  • tools/checks/check-focused.sh: passed, including 35 WebUI permutations and full-product bundle budgets.
  • Architecture manifest gate: 60/60 declarations; static contract graph: 60 modules, 98 providers, 54 requirements.
  • Release migration audit: valid graph including the four new module heads.
  • SQL-backed institutional golden journey, configuration-package preflight, module tests, Ruff, and startup smoke: passed.

Release Boundary

The four source repositories are initialized locally but have not been pushed or tagged in this work. Their truthful maturity remains vertical_slice, and the package remains product; reference_ready or supported still requires the separately documented target, accessibility, privacy, security, operations, and recovery-drill evidence.

## Codex State: done ### Summary - The target architecture is implemented as an enforced `vertical_slice`/`product` architecture contract rather than a documentation-only proposal. - Mandates, Services, Parties, and Decisions now have independent persistent module owners with tenant isolation, immutable revisions, OCC, lifecycle validation, APIs, permissions, migrations, uninstall guards, recovery documentation, and provider capabilities. - Portal, Cases, and Committee consume those providers without cross-module table access. `product.service-to-decision` proves the complete SQL-backed path through service discovery, case intake, party representation, mandate resolution, formal decision, observed effect, audit/record evidence, and review references. - Provider governance, architecture metadata, package preflight, Docs/Ops projection, environment synchronization, and release tooling are machine-enforced across the workspace. - The canonical architecture page and all four module domain/recovery pages are synchronized to their Gitea wikis. ### Verification - `tools/checks/check-focused.sh`: passed, including 35 WebUI permutations and full-product bundle budgets. - Architecture manifest gate: 60/60 declarations; static contract graph: 60 modules, 98 providers, 54 requirements. - Release migration audit: valid graph including the four new module heads. - SQL-backed institutional golden journey, configuration-package preflight, module tests, Ruff, and startup smoke: passed. ### Release Boundary The four source repositories are initialized locally but have not been pushed or tagged in this work. Their truthful maturity remains `vertical_slice`, and the package remains `product`; `reference_ready` or `supported` still requires the separately documented target, accessibility, privacy, security, operations, and recovery-drill evidence.
zemion commented 2026-08-01 15:13:56 +02:00
Author
Owner
Copy Link
Copy Source

Codex State: done

Summary

  • The architecture depth pass now includes persistent Projects and governed semantic Reporting verticals, Committee workspace WebUI and aggregate-only ballot adapter boundary, case object sharing, and exact replay-safe Portal launches into Cases and Workflow Engine.
  • The canonical architecture and module docs are updated and mirrored to Gitea wikis.

Verification

  • 61/61 source manifests pass the enforced architecture gate; institutional golden journeys pass; Core institutional/module tests pass; all 37 prior WebUI permutations plus isolated Committee/Projects/Reporting and default builds pass; module bundle budgets pass.

Next / Blocked

  • Forms Runtime #1 is the only missing executable owner vertical in this architecture path: GovOPlaN/govoplan-forms-runtime#1
  • Committee #1 tracks selection and assurance of a concrete ballot provider: GovOPlaN/govoplan-committee#1
  • Reference-ready claims still require signed evidence from real target accessibility, privacy, security, operations, provider, backup/restore and recovery runs.
## Codex State: done ### Summary - The architecture depth pass now includes persistent Projects and governed semantic Reporting verticals, Committee workspace WebUI and aggregate-only ballot adapter boundary, case object sharing, and exact replay-safe Portal launches into Cases and Workflow Engine. - The canonical architecture and module docs are updated and mirrored to Gitea wikis. ### Verification - `61/61 source manifests pass the enforced architecture gate; institutional golden journeys pass; Core institutional/module tests pass; all 37 prior WebUI permutations plus isolated Committee/Projects/Reporting and default builds pass; module bundle budgets pass.` ### Next / Blocked - Forms Runtime #1 is the only missing executable owner vertical in this architecture path: https://git.add-ideas.de/GovOPlaN/govoplan-forms-runtime/issues/1 - Committee #1 tracks selection and assurance of a concrete ballot provider: https://git.add-ideas.de/GovOPlaN/govoplan-committee/issues/1 - Reference-ready claims still require signed evidence from real target accessibility, privacy, security, operations, provider, backup/restore and recovery runs.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
HTTP API contracts, routers, schemas, or API smoke behavior.
 area/auth
Authentication, sessions, access bootstrap, or login behavior.
 area/db
Database sessions, models, transactions, or persistence primitives.
 area/devex
Local developer workflow, scripts, tests, tooling, or release helpers.
 area/docs
Durable documentation and project guidance.
 area/governance
Governance policy, audit, privacy, retention, or compliance behavior.
 area/marketing
Public website, product messaging, publication copy, or legal page content.
 area/migrations
Alembic migrations, schema bootstrap, or persistence evolution.
 area/module-system
Module discovery, manifests, capabilities, routing, or optional integrations.
 area/rbac
Permissions, roles, delegation, or authorization policy.
 area/release
Versioning, release locks, tags, packaging, or dependency pins.
 area/security
Security posture, static analysis, supply-chain hardening, or vulnerability remediation.
 area/tenancy
Tenant boundaries, provisioning, or tenant-scoped data behavior.
 area/webui
Shared WebUI shell, frontend components, routing, or frontend tests.
 audit/complexity
Complexity finding from Radon, Xenon, or equivalent maintainability scans.
 audit/duplication
Duplicated-code finding from jscpd or equivalent similarity scans.
 audit/false-positive
Audit finding reviewed as a narrow false positive or acceptable risk.
 audit/needs-design
Audit finding that needs an architectural or product decision before implementation.
 audit/quick-fix
Audit finding that appears narrow and directly fixable.
 audit/structural
Audit finding that needs design, refactoring, or behavior review.
 codex/needs-human
Needs an explicit human decision before Codex should implement.
 codex/ready
Suitable for Codex to pick up with the existing issue context.
 module/access
GovOPlaN access, identity, authentication, RBAC, and administration behavior.
 module/addresses
GovOPlaN Addresses module behavior or integration.
 module/admin
GovOPlaN Admin module behavior or integration.
 module/appointments
GovOPlaN Appointments module behavior or integration.
 module/approvals
GovOPlaN Approvals module behavior or integration.
 module/audit
GovOPlaN Audit module behavior or integration.
 module/calendar
GovOPlaN Calendar module behavior or integration.
 module/campaign
GovOPlaN campaign module behavior or integration.
 module/cases
GovOPlaN Cases module behavior or integration.
 module/committee
GovOPlaN Committee module behavior or integration.
 module/connectors
GovOPlaN Connectors module behavior or integration.
 module/core
GovOPlaN core runner, shared primitives, shell, or extension points.
 module/dashboard
GovOPlaN Dashboard module behavior or integration.
 module/dataflow
GovOPlaN Dataflow module behavior or integration.
 module/datasources
GovOPlaN governed datasource contracts, catalogs, and integrations.
 module/decisions
GovOPlaN formal Decisions module behavior or integration.
 module/dist-lists
GovOPlaN Distribution Lists module behavior or integration.
 module/dms
GovOPlaN Dms module behavior or integration.
 module/docs
GovOPlaN Docs module behavior or integration.
 module/encryption
GovOPlaN Encryption key custody, cryptographic policy, and E2EE integration.
 module/erp
GovOPlaN Erp module behavior or integration.
 module/evaluation
GovOPlaN Evaluation module behavior or integration.
 module/files
GovOPlaN files module behavior or integration.
 module/fit-connect
GovOPlaN Fit Connect module behavior or integration.
 module/forms
GovOPlaN Forms module behavior or integration.
 module/forms-runtime
GovOPlaN Forms Runtime module behavior or integration.
 module/helpdesk
GovOPlaN Helpdesk module behavior or integration.
 module/identity
GovOPlaN Identity module behavior or integration.
 module/identity-trust
GovOPlaN Identity Trust module behavior or integration.
 module/idm
GovOPlaN Idm module behavior or integration.
 module/ledger
GovOPlaN Ledger module behavior or integration.
 module/mail
GovOPlaN mail module behavior or integration.
 module/mandates
GovOPlaN Mandates, jurisdiction, responsibility, and authority behavior or integration.
 module/notifications
GovOPlaN Notifications module behavior or integration.
 module/ops
GovOPlaN Ops module behavior or integration.
 module/organizations
GovOPlaN Organizations module behavior or integration.
 module/parties
GovOPlaN procedure Parties, representation, and delivery-authority behavior or integration.
 module/payments
GovOPlaN Payments module behavior or integration.
 module/permits
GovOPlaN Permits module behavior or integration.
 module/policy
GovOPlaN Policy module behavior or integration.
 module/poll
GovOPlaN Poll module behavior or integration.
 module/portal
GovOPlaN Portal module behavior or integration.
 module/postbox
GovOPlaN Postbox module behavior or integration.
 module/projects
GovOPlaN Projects module behavior or integration.
 module/reporting
GovOPlaN Reporting module behavior or integration.
 module/risk-compliance
GovOPlaN Risk Compliance module behavior or integration.
 module/scheduling
GovOPlaN Scheduling module behavior or integration.
 module/search
GovOPlaN Search module behavior or integration.
 module/services
GovOPlaN versioned institutional Services behavior or integration.
 module/tasks
GovOPlaN Tasks module behavior or integration.
 module/templates
GovOPlaN Templates module behavior or integration.
 module/tenancy
GovOPlaN Tenancy module behavior or integration.
 module/tickets
GovOPlaN Tickets module behavior or integration.
 module/views
GovOPlaN governed task views, interface projections, and workflow view integration.
 module/wiki
GovOPlaN Wiki module behavior or integration.
 module/workflow
GovOPlaN Workflow module behavior or integration.
 module/workflow-engine
GovOPlaN Workflow Engine runtime, persistence, or integration.
 module/xoev
GovOPlaN Xoev module behavior or integration.
 module/xrechnung
GovOPlaN Xrechnung module behavior or integration.
 module/xta-osci
GovOPlaN Xta Osci module behavior or integration.
priority
p0
Immediate stop-the-line priority.
priority
p1
High priority for the next focused work window.
priority
p2
Normal planned priority.
priority
p3
Low priority or opportunistic cleanup.
source/backlog-import
Imported from markdown backlog, roadmap, plan, or TODO files.
 source/security-audit
Created from a structured security or code-quality audit report.
 source/todo-scan
Imported from inline TODO/FIXME/HACK markers by the Gitea TODO importer.
status
blocked
Cannot progress without a decision, dependency, credential, or external change.
status
in-progress
Currently being worked.
status
needs-info
Needs clarifying input before implementation can proceed safely.
status
ready
Ready for implementation.
status
triage
Needs review, ownership, priority, or acceptance criteria.
type
bug
A reproducible defect, regression, or incorrect behavior.
type
debt
Cleanup, refactoring, risk reduction, or deferred engineering work.
type
docs
Documentation, process, or developer workflow work.
type
feature
New user-visible behavior or platform capability.
type
task
Implementation, maintenance, migration, or operational work.
type
user-story
End-to-end user journey or real-world process story used to steer product slices.
No labels area/docs area/governance codex/ready module/core module/decisions module/mandates module/parties module/services
priority
p1
status
in-progress
type
feature
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
zemion
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan#29