# Copilot Prompt: Qt 6 Release 2 — AP3, AP4, and AP9

Deliver Release 2 from the already Qt 6-migrated codebase. This is not a Qt 5-to-Qt 6 migration. Work autonomously, minimally, reproducibly, and only within this release scope. Change code only when directly required for its configuration, build, tests, installation, delivery, or documented operation. Before editing, read `./prompts/commit-policy.prompt.md` if it exists; follow any stricter repository rules. Do not rewrite unrelated or unauthorized repository history.

## Release scope

Cover these application packages (APs), using only modules, targets, and packages that actually exist:

- **AP3 — Shared libraries:** `LtsUtils`, `Widgets`, `Session`, `Krypto`, `PluginManager`, and required core libraries.
- **AP4 — DDS middleware:** `Core`, `DDSConnector`, `Routing`, `QosProfile`, and the RTI DDS compatibility layer.
- **AP9 — Tools and translations:** `DdsView`, `LogViewer`, `SqlBrowser`, generators, and the `lupdate` toolchain.

Release 2 must also include every module in the first-release scope from branch `story/release-validation-scope`. At execution time, locate the repository that owns this branch (expected under the `qt-migration-legatus` submodule in folder `./qt-migration-legatus/qt6-after/qt6-migrated-legatus`), inspect the branch’s actual tree and release-scope evidence, and derive the complete module list from that evidence. Treat every such module as mandatory in Release 2, not as an optional dependency. Do not substitute a module list from another prompt or assume this branch is present in the current checkout; if it is unavailable or its scope cannot be established on the target host, stop and report the precise blocker. Preserve the Release 1 delivery structure and test expectations described below while integrating those modules with AP3, AP4, and AP9.

Deliver a reproducible build, test, installation, and packaging process, plus customer instructions that explain contents, prerequisites, installation, startup, and verification.

## Repository and branch safety

Use target branch `story/create-release-two-delivery-25_11_2026`. Before editing, inspect repository/submodule boundaries, remotes, branches, working trees, and target-branch status; assign every planned file to its owning repository.

- Never work accidentally on `main`, Release 1, or another migration branch.
- If the target branch is absent, create it only from an unambiguous migrated base; otherwise stop and report the blocker.
- Preserve existing user changes. If they conflict with the scope, stop and report the conflict.
- Before cleanup, record the file inventory and Git status. Make every removal traceable.

## Workspace layout

Use this supplied workspace layout when locating files and documenting repository ownership. Verify it against the checked-out tree before making changes; report material differences instead of assuming paths exist.

```text
.
├── app
│   ├── __pycache__
│   └── patches
├── build_test
├── ci
├── external
│   ├── AVS
│   ├── ArcGIS
│   ├── BuildingModels
│   ├── GeographicLib
│   ├── Schusstafel
│   ├── dtEntity
│   ├── rti_connext_dds-7.7.0
│   └── tmsif
├── external-dependencies
│   ├── arcgis
│   ├── avs
│   ├── buildingmodels
│   ├── deb-packages
│   ├── dtentity
│   ├── geographiclib
│   ├── googletest
│   ├── grantlee
│   ├── kdreports
│   ├── log4qt
│   ├── offline-cache
│   ├── postgresql
│   ├── qt6-framework
│   ├── rti-connext-dds
│   ├── schusstafel
│   ├── scripts
│   ├── tmsif
│   └── ubuntu-26.04-build-container
├── files
├── jenkins
├── jenkins-ci-rme
├── offline-cache
├── prompts
├── qt-migration-legatus
│   ├── ci
│   ├── docs
│   ├── qt5-before
│   ├── qt6-after
│   └── scripts
├── rpmbuild
│   └── packages-out
├── rpms
│   └── guez
└── scripts

```

The application build script is `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh`. Inspect and use that exact script and its implemented CLI (use --help option); do not assume there is a root-level `new_docker_build.sh`.

For every external dependency actually required by `S`, provide a separately reproducible Docker build definition and Jenkins pipeline definition as given in folder `./external-dependencies/` so the customer can rebuild and evolve that dependency in his air-gapped CI environment. Keep these definitions separate per dependency, identify their source/version, inputs, licenses/access requirements, outputs, and verification steps, and document their locations. Do not copy, redistribute, or attempt to build vendor software without confirming the applicable license and customer access. If a dependency cannot legally or technically be reproduced from available inputs, state the precise blocker rather than claiming reproducibility.

## Determine and audit the real scope

Derive from repository evidence:

- `R`: all existing candidate modules, libraries, tools, generators, and build/packaging components.
- `M`: existing components belonging to AP3, AP4, or AP9, plus every module in the first-release scope derived from the actual tree of branch `story/release-validation-scope`.
- `S`: `M` plus the smallest set of proven direct/transitive dependencies.
- `R \ S`: components outside this release.

Use actual CMake files/targets, links, includes, Qt modules, RTI integration, generator inputs, resources, tests, install/packaging rules, and release metadata. For every dependency in `S \ M`, record its real name, dependent AP/module, technical reason, and exact file/line or equivalent location. Verify the actual RTI version/runtime files, generator flows and output locations, whether `lupdate` is needed at build or translation-maintenance time, and which tests belong to this scope. Never infer dependencies from names or prompt wording. Resolve any build, runtime, or customer-operation dependency from evidence; otherwise stop with a precise blocker.

## Release-branch cleanup

This branch must contain only `S` and files proven necessary for its build, tests, installation, release documentation, or packaging. Physically remove other files; excluding them from packages alone is insufficient.

Before each deletion, check dependencies, includes, CMake, tests, generator inputs, runtime resources, install rules, and packaging references; confirm the files are unused and list each planned removal with its reason in the scope audit. Do not make broad directory deletions or delete by name similarity. Preserve shared build helpers, generators, tests, legal notices, Docker/build files, and customer documentation when required. For partially used modules, remove only proven-unused parts. Never commit generated build output, logs, local configuration, secrets, host paths, stubs, or fake output. After cleanup, recheck references and build from a clean build directory.

## Build, tests, CI, and generators

Inspect `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh`, its real CLI (`--help` or implementation), Dockerfiles, CMake options, and existing Jenkins/CI calls before changing them. This is the release build entry point: make the smallest pipeline changes needed so it reproducibly configures, builds, tests, installs, and packages only `S`; provides required system, Qt 6, and RTI dependencies; runs the project’s actual generators and AP9 translation tools; validates the compatibility layer against the supported RTI installation; and propagates configuration, build, link, generation, test, or packaging failures. Retain the Release 1 expectation that relevant tests are part of the release, rather than disabling or omitting them.

Maintain the per-dependency Docker and Jenkins definitions required above independently of the application build pipeline. Verify that each definition can reproduce the documented dependency artifact from permitted, versioned inputs, and ensure the CI pipeline reports failures rather than silently using an existing host installation.

Keep generated sources and translation artifacts in the build tree unless the established release process explicitly requires shipping them. Do not replace generator output with handwritten code or disable/ignore relevant tests. Do not rely on host paths, locally installed developer packages, or undocumented manual steps.

Run the real release command through `new_docker_build.sh`; report the exact command, exit code, and meaningful build/CTest results. If Docker, RTI licensing/access, or the environment blocks validation, state that as a blocker—not a success. Change CI/Jenkins only as needed to match the verified release scope and pipeline. Run Jenkins only if access is available; otherwise report why it was not run.

## Artifacts and packaging

Follow the Release 1 delivery structure: produce five separate DEB packages with explicit per-package allowlists and manifests, using the established Release 1 names and versioning conventions where the repository confirms them:

1. `qt6-release-runtime-<version>.deb` — runtime binaries, libraries, data, and resources from `S`; no C++ sources or CTest sources.
2. `qt6-release-sources-<version>.deb` — Qt6 module sources and required headers from `S`; no generated build-tree files.
3. `qt6-release-ctest-runtime-<version>.deb` — executable release-relevant CTest programs, required runtime files, and test data for `M` and proven dependencies in `S \ M`.
4. `qt6-release-ctest-sources-<version>.deb` — C++ sources, headers, and test configuration for the included CTests.
5. `qt6-release-build-pipeline-<version>.deb` — required Dockerfiles, `new_docker_build.sh`, CMake/CTest/Jenkins/DEB-packaging scripts, configuration, and manifests.

Before implementation, verify the actual Release 1 package names, version source, allowlists, output path, and customer release contract from repository evidence. Preserve those conventions; do not mix formats or invent package contents. If the required five-DEB structure cannot be reproduced from the available code or inputs, stop with the precise blocker rather than silently changing the structure.

Ship required runtime binaries, libraries, data, and resources from `S`, plus traceable version/manifest and reproducible-build/support materials. As in Release 1, ship the release-relevant CTest executables and their C++ sources in their dedicated packages; build and run those tests, and do not disable, remove, or omit them to obtain a passing release.

For every artifact, inspect metadata, file list, dependencies, and installation with the format’s tools. Use explicit allowlists/manifests to exclude `R \ S`, incidental build output, and host paths. Verify AP3/AP4/AP9 contents and Qt 6/RTI runtime dependencies. Document each artifact’s name, version, purpose, contents, and verification result.

## Customer guide and release notes

Write a self-contained, step-by-step customer README, consistent with the Release 1 customer documentation structure. Put it in the established customer-facing README location; if none exists, add `README-RELEASE-2.md`. Describe the real `new_docker_build.sh` workflow. First determine whether it builds/packages, runs the application, or both. Document only implemented options; add and test a minimal feature only if the required customer workflow cannot otherwise be completed. Separate **building the release** from **running it at the customer site**. Do not assume Docker is needed at runtime; prove it from the project if required.

Give numbered, copy/paste-ready steps with purpose, prerequisites, expected result, and troubleshooting. Cover:

1. Evidence-backed hardware/OS, Docker, Qt 6, and RTI DDS versions and licensing/access requirements.
2. Release checkout and configuration, without secrets or fixed host-specific paths.
3. Supported script options and their meanings.
4. Image setup and actual build/test/package commands.
5. Artifact and manifest locations and checks.
6. Customer installation/upgrade, dependencies, and ordering.
7. AP3/AP4/AP9 setup and repository-backed startup/example commands.
8. Smoke checks for libraries, DDS compatibility/connectivity, tools, and translations.
9. Logs, common failures, diagnostics, uninstall/rollback, and known limitations.

Every command and claimed output must be supported by the implemented CLI or repository files. Do not invent flags, paths, package names, environment variables, versions, ports, test results, or outputs. Mark customer-specific values as explained placeholders; label unverified facts “to be confirmed” or report them as blockers.

Create customer-facing Release 2 release notes, following the Release 1 release-notes structure, at the established documentation location or as `RELEASE-2.md` if none exists. Include only evidence-backed facts: release name/version/tag/date/status (only when set/known); purpose, audience, and difference from Release 1; AP contents and the carried-forward modules identified from `story/release-validation-scope`; confirmed platform, Qt 6, RTI, ABI, and package requirements; artifact details; installation/upgrade/startup/uninstall steps or a README reference; smoke tests and expected results; limitations and dependencies; generator/translation workflows and whether customers need `lupdate`; compatibility/configuration impacts; changelog and repository sources. Clearly separate verified facts, known limitations, and open items. Do not claim completeness, compatibility, test success, performance, security, or support without evidence.

## Completion audit and report

Before changes, record repository/branch/tree ownership, `R`, `M`, `S`, `R \ S`, dependency evidence, planned edits/deletions, package/version contracts, script options, and customer entry points.

Before completion, audit the cleaned branch and deletions against dependencies, build, tests, runtime, generators, installation, and packaging; run the clean Docker build, generators, relevant CTests, and artifact-content checks; reconcile the customer guide with the actual CLI/artifacts; and verify the release notes against versions, compatibility, and test results.

Report concisely and factually:

- Status: `validated`, `partially validated`, or `blocked`. Use `validated` only if scope, relevant tests, artifacts, and customer instructions were fully verified.
- Branch and repository/submodule ownership; working-tree status.
- Complete `M`, `S`, and `R \ S` lists, with evidence for dependencies.
- Removed/changed files, reasons, and required shared-file exceptions.
- Build, CTest, generator, CI, and packaging commands/results.
- Artifacts, versions, manifests, and content checks.
- Customer workflow and documentation paths.
- Evidence-backed release facts, open technical questions, unrun checks, and precise blockers.
- Do not provide a separate risk analysis or risk rating.