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

[Task] Produce an evidence-based GovOPlaN capability and IT-infrastructure fit assessment #10

New Issue
Open
opened 2026-07-20 14:40:35 +02:00 by zemion · 3 comments
zemion commented 2026-07-20 14:40:35 +02:00
Owner
Copy Link

User Story

As a product owner, solution architect, or public-sector IT operator, I want a repeatable assessment of whether a versioned GovOPlaN composition fits an organization's functional and infrastructure needs, so that adoption, pilot, gap, cost, and risk decisions use verified evidence rather than repository names or roadmap assumptions.

Acceptance Criteria

  • The assessment captures outcomes, users, tenant/organization shape, reference journeys, data classes, privacy/security, retention, integrations, identity, protocols, workloads, growth, availability, RTO/RPO, hosting/network constraints, operations capability, and procurement constraints.
  • Every assessment pins GovOPlaN release/composition, module versions, configuration packages, deployment profile, and assessment-schema version.
  • Capability status uses a controlled vocabulary: verified, available_unconfigured, partial, scaffold, external_system, planned, not_fit, and not_assessed.
  • Repository or manifest existence alone never counts as an implemented capability.
  • Every conclusion links to evidence such as tests, routes/contracts, operational drills, docs, configured examples, open issues, or an explicit absence of evidence.
  • A functional matrix records required/optional modules, external systems/connectors, missing contracts, policy decisions, manual workarounds, and blockers.
  • An infrastructure matrix covers WebUI/API, workers/scheduler, PostgreSQL, Redis/queues, file/object storage, proxy/TLS, identity, secrets, connectors/mail, monitoring/logging/audit, backup/restore, and disaster recovery.
  • Data flows, trust boundaries, network requirements, external disclosures, and scaling constraints are explicit.
  • Workload assumptions include tenants/users/concurrency, Campaign volume, files/jobs/audit growth, retention, connector traffic, and peaks/batches.
  • Output separates facts, assumptions, unresolved decisions, risks, residual risks, recommendations, and proof-of-concept checks.
  • Pilot and production scenarios produce a recommended composition/topology rather than one unsupported hardware number.
  • Human-readable and machine-readable reports come from the same inputs and contain no secrets or unnecessary personal data.
  • Re-running against a new release highlights evidence and conclusions needing review.
  • The first reference assessment covers the current Campaign-centric composition and marks Workflow as planned/postponed.

First Delivery

  1. Define the questionnaire, status vocabulary, and evidence schema.
  2. Inventory the current release from manifests, release metadata, tests, repository docs, and live issues.
  3. Produce a Campaign-focused pilot/small-production fit report.
  4. Cross-link infrastructure evidence and gaps to Core #28/#29/#217/#219 and Ops.
  5. Add a generator only after the hand-authored first report proves the schema.

Ownership

The meta repository owns the cross-repository schema, evidence collection, and report. Ops owns topology/workload/operational evidence; Core supplies release/runtime metadata; feature modules supply truthful capability evidence; Docs may later render configured-system assessments.

## User Story As a product owner, solution architect, or public-sector IT operator, I want a repeatable assessment of whether a versioned GovOPlaN composition fits an organization's functional and infrastructure needs, so that adoption, pilot, gap, cost, and risk decisions use verified evidence rather than repository names or roadmap assumptions. ## Acceptance Criteria - [ ] The assessment captures outcomes, users, tenant/organization shape, reference journeys, data classes, privacy/security, retention, integrations, identity, protocols, workloads, growth, availability, RTO/RPO, hosting/network constraints, operations capability, and procurement constraints. - [ ] Every assessment pins GovOPlaN release/composition, module versions, configuration packages, deployment profile, and assessment-schema version. - [ ] Capability status uses a controlled vocabulary: `verified`, `available_unconfigured`, `partial`, `scaffold`, `external_system`, `planned`, `not_fit`, and `not_assessed`. - [ ] Repository or manifest existence alone never counts as an implemented capability. - [ ] Every conclusion links to evidence such as tests, routes/contracts, operational drills, docs, configured examples, open issues, or an explicit absence of evidence. - [ ] A functional matrix records required/optional modules, external systems/connectors, missing contracts, policy decisions, manual workarounds, and blockers. - [ ] An infrastructure matrix covers WebUI/API, workers/scheduler, PostgreSQL, Redis/queues, file/object storage, proxy/TLS, identity, secrets, connectors/mail, monitoring/logging/audit, backup/restore, and disaster recovery. - [ ] Data flows, trust boundaries, network requirements, external disclosures, and scaling constraints are explicit. - [ ] Workload assumptions include tenants/users/concurrency, Campaign volume, files/jobs/audit growth, retention, connector traffic, and peaks/batches. - [ ] Output separates facts, assumptions, unresolved decisions, risks, residual risks, recommendations, and proof-of-concept checks. - [ ] Pilot and production scenarios produce a recommended composition/topology rather than one unsupported hardware number. - [ ] Human-readable and machine-readable reports come from the same inputs and contain no secrets or unnecessary personal data. - [ ] Re-running against a new release highlights evidence and conclusions needing review. - [ ] The first reference assessment covers the current Campaign-centric composition and marks Workflow as planned/postponed. ## First Delivery 1. Define the questionnaire, status vocabulary, and evidence schema. 2. Inventory the current release from manifests, release metadata, tests, repository docs, and live issues. 3. Produce a Campaign-focused pilot/small-production fit report. 4. Cross-link infrastructure evidence and gaps to Core #28/#29/#217/#219 and Ops. 5. Add a generator only after the hand-authored first report proves the schema. ## Ownership The meta repository owns the cross-repository schema, evidence collection, and report. Ops owns topology/workload/operational evidence; Core supplies release/runtime metadata; feature modules supply truthful capability evidence; Docs may later render configured-system assessments.
zemion commented 2026-07-20 15:29:46 +02:00
Author
Owner
Copy Link

The first evidence-based assessment slice now exists locally:

  • docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md
  • docs/capability-fit-current.json
  • docs/capability-fit.schema.json

It pins the current composition, separates verified/partial/planned capability, treats the production-like profile as development validation rather than a production claim, maps infrastructure and trust boundaries, and provides proof checks plus a reusable questionnaire. Workflow is explicitly postponed.

Validation: JSON Schema passed; relative documentation links and git diff --check passed; static contracts reported 43 contracts / 29 providers with no issues; selected Core, Campaign, Files, Mail, Audit, and Addresses evidence suites passed. The issue remains open because these artifacts are local/unintegrated and the target-environment proof checks are deliberately outstanding.

<!-- codex-progress-capability-fit-2026-07-20 --> The first evidence-based assessment slice now exists locally: - `docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md` - `docs/capability-fit-current.json` - `docs/capability-fit.schema.json` It pins the current composition, separates verified/partial/planned capability, treats the production-like profile as development validation rather than a production claim, maps infrastructure and trust boundaries, and provides proof checks plus a reusable questionnaire. Workflow is explicitly postponed. Validation: JSON Schema passed; relative documentation links and `git diff --check` passed; static contracts reported 43 contracts / 29 providers with no issues; selected Core, Campaign, Files, Mail, Audit, and Addresses evidence suites passed. The issue remains open because these artifacts are local/unintegrated and the target-environment proof checks are deliberately outstanding.
zemion commented 2026-07-22 15:38:55 +02:00
Author
Owner
Copy Link

Codex State: progress

Summary

  • Refreshed the human and machine-readable capability assessment to signed stable catalog sequence 202607220843 (Core v0.1.13, Campaign v0.1.10).
  • Removed obsolete dirty/local-WIP claims and separated package integration from target testing, configuration reproducibility, and production approval.

Changed Files

  • docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md
  • docs/capability-fit-current.json

Verification

  • Assessment JSON Schema passed; 43-module/33-provider contract scan passed; signed catalog/tag refs verified.

Next / Blocked

  • Keep open for a pinned configuration package and the target provider, backup/restore, and installed-artifact proof checks.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Refreshed the human and machine-readable capability assessment to signed stable catalog sequence 202607220843 (Core v0.1.13, Campaign v0.1.10). - Removed obsolete dirty/local-WIP claims and separated package integration from target testing, configuration reproducibility, and production approval. ### Changed Files - `docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md` - `docs/capability-fit-current.json` ### Verification - `Assessment JSON Schema passed; 43-module/33-provider contract scan passed; signed catalog/tag refs verified.` ### Next / Blocked - Keep open for a pinned configuration package and the target provider, backup/restore, and installed-artifact proof checks. Suggested status label: `status/in-progress`
zemion commented 2026-07-22 17:19:09 +02:00
Author
Owner
Copy Link

Codex State: progress

Summary

  • Added a release-aware capability reassessment with an independently pinned local signature trust root, catalog-pinned published-keyring integrity, selected-unit commit/tag-object provenance, and deterministic review targets.
  • Public catalog/keyring responses are bounded at 16 MiB; malformed, duplicate, or ambiguous trust-key entries fail closed.

Changed Files

  • tools/assessments/capability-fit.py
  • tools/assessments/govoplan_assessment/capability_fit.py
  • docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md

Verification

  • 103 meta tests passed; live signed stable rerun is current with 16/16 local tag checks valid

Next / Blocked

  • Generator output plus installed-artifact, target-environment, external-provider, and production proof remain open.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Added a release-aware capability reassessment with an independently pinned local signature trust root, catalog-pinned published-keyring integrity, selected-unit commit/tag-object provenance, and deterministic review targets. - Public catalog/keyring responses are bounded at 16 MiB; malformed, duplicate, or ambiguous trust-key entries fail closed. ### Changed Files - `tools/assessments/capability-fit.py` - `tools/assessments/govoplan_assessment/capability_fit.py` - `docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md` ### Verification - `103 meta tests passed; live signed stable rerun is current with 16/16 local tag checks valid` ### Next / Blocked - Generator output plus installed-artifact, target-environment, external-provider, and production proof remain open. Suggested status label: `status/in-progress`
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/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/connectors
GovOPlaN Connectors module behavior or integration.
module/core
GovOPlaN core runner, shared primitives, shell, or extension points.
module/dataflow
GovOPlaN Dataflow module behavior or integration.
module/datasources
GovOPlaN governed datasource contracts, catalogs, and integrations.
module/dist-lists
GovOPlaN Distribution Lists module behavior or integration.
module/dms
GovOPlaN Dms module behavior or 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/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/notifications
GovOPlaN Notifications module behavior or integration.
module/ops
GovOPlaN Ops module behavior or integration.
module/organizations
GovOPlaN Organizations module 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/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/tasks
GovOPlaN Tasks module behavior or integration.
module/templates
GovOPlaN Templates module behavior or integration.
module/tenancy
GovOPlaN Tenancy module behavior or integration.
module/views
GovOPlaN governed task views, interface projections, and workflow view integration.
module/workflow
GovOPlaN Workflow module behavior 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 Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
zemion
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan#10
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?