# 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`