govoplan/docs/META_REPOSITORY_MIGRATION_AUDIT.md

Meta Repository Migration Audit

This audit records which existing GovOPlaN files should move toward the govoplan meta repository and which should remain with their current runtime owner.

Website Repository Rename

The former govoplan-web repository has been renamed to addideas-govoplan-website. It is a public website and catalog publication target, not an installable GovOPlaN runtime module.

Resolved target name:

• addideas-govoplan-website

The rename happened server-side in Gitea first. Local checkout paths, remotes, docs, and release/catalog defaults should use the new name.

The renamed repository should remain categorized as website, not module.

Move To govoplan

These are whole-product/operator concerns and should be owned by the meta repository.

Release Orchestration

Former location:

• core-local release and catalog helper scripts

Target shape:

• command entry points live in govoplan/tools
• repository lists come from govoplan/repositories.json
• generated catalogs are written to the renamed public site repository
• core keeps only runtime catalog validation/signing primitives used by the installer

Cross-Repository Gitea Workflow Tooling

Former location:

• core-local Gitea helper scripts
• source issue templates copied into each repo under .gitea/
• the shared label taxonomy JSON file

Target shape:

• source templates and label taxonomy live in govoplan
• sync/import/migration helpers live in govoplan/tools
• generated/copy-installed .gitea/ files may remain in each repository because Gitea reads them repository-locally
• repo-specific AGENTS or issue guidance can remain repo-local when it contains module-specific instructions

Whole-Product CI

Former location:

• core-local whole-product workflow definitions

Target shape:

• whole-product workflows live in govoplan/.gitea/workflows
• workflows bootstrap or use sibling checkouts based on repositories.json
• core keeps core-only workflows if needed later

Notes:

• Gitea workflows are repository-local, so moving them changes which repository triggers the job.
• The workflow scripts must stop assuming the checked-out repository is govoplan-core.

Security Audit Toolbox

Former location:

• core-local security audit toolbox files
• core-local audit dependency and Gitleaks configuration files

Reason to move:

• the tool already supports --scope govoplan
• the govoplan scan mounts the parent directory and scans sibling repos
• this is an operator/security workspace function, not runtime core behavior

Target shape:

• govoplan/tools/checks/security-audit/
• govoplan/tools/checks/check-security-audit.sh
• govoplan/requirements-audit.txt
• govoplan/.gitleaks.toml

Whole-Product Docker

Former locations:

• core-local shared development Docker profiles
• website-local public-site Compose profile

Target shape:

• shared development and production-like composition move under govoplan/dev
• deploy/public-site composition can live under govoplan/docker
• module-specific testbeds stay module-local:
  • govoplan-campaign/dev/mail-testbed/docker-compose.yml
  • govoplan-files/dev/connectors/docker-compose.yml

Keep In Core

These are runtime/kernel concerns and should stay in govoplan-core.

• installer/runtime code under govoplan_core.core.module_installer
• module discovery, registry, route aggregation, and lifecycle contracts
• catalog validation primitives used by the runtime installer
• configuration package validation and safety contracts
• database/session primitives and migration orchestration APIs
• core WebUI shell and module contribution contracts

Canonical operator entry points should be in govoplan.

Keep In Public Site Repository

After the rename, the website repository should keep:

• Vite/React public website source
• screenshots/content source notes
• static catalog assets under public/catalogs/...
• website-specific catalog asset validator if it validates static publication contents
• website Dockerfile and simple site-serving compose, unless a whole-product deployment compose takes over in govoplan

It should not own:

• release version bumping
• cross-repository tagging
• catalog generation/signing keys
• installer logic
• module orchestration

Rename Follow-Up References

Known references reviewed after the server-side rename:

• govoplan/repositories.json
• govoplan/docs/REPOSITORY_STRUCTURE.md
• govoplan/docker/README.md
• govoplan-core/docs/RELEASE_DEPENDENCIES.md
• govoplan-core/docs/MODULE_ARCHITECTURE.md
• moved release helper references
• moved Gitea helper references
• public site README.md, package.json, package-lock.json, docker-compose.yml, and catalog key rotation runbook

Suggested Migration Order

1. Update local checkout path, remote, repository manifest, and docs.
2. Move Gitea helper scripts and source templates from core to meta.
3. Move release/catalog command entry points from core to meta and convert repository discovery to repositories.json.
4. Move whole-product Gitea Actions workflows to meta.
5. Move security audit toolbox to meta.
6. Move/wrap whole-product Docker composition in meta.
7. Remove core compatibility wrappers once docs and workflows use govoplan.

Current State

Completed in the meta repository:

• canonical tools live in govoplan/tools
• release/catalog/Gitea/security-audit tools have been moved from core to meta
• whole-product Gitea workflows have been moved to govoplan/.gitea/workflows
• shared PostgreSQL and production-like Docker profiles live under govoplan/dev
• core-local wrappers for moved commands have been removed
• the meta scripts compatibility layer has been removed; use govoplan/tools