qt6-migration-pipeline/prompts/migrate-module-TetraIF.prompt.md

# Strict Qt6 Migration Prompt: CMake targets under folder ./TetraIF

This prompt is binding task context. Keep changes minimal, scoped, and reproducible.

## Required base prompt

Before making changes, read and apply:

- ./prompts/combined-migration-subfolder-rti-compact.prompt.md

If that prompt is stricter, follow it. This prompt overrides it only for build variants: use ON variants only. Do not pursue OFF variants.

## Module in scope

Migrate only:

- cmake targets under folder  ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF

From:

- ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/TetraIF

To:

- ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF


Do not migrate sibling services or unrelated modules.

## Mandatory build variants

Only these variants are valid:

- BUILD_RTI=ON
- BUILD_GRANTLEE=ON
- BUILD_ARCGIS=OFF

Forbidden:

- BUILD_RTI=OFF
- BUILD_GRANTLEE=OFF
- BUILD_ARCGIS=ON

Rules:

- Do not implement, fix, preserve, test, or validate OFF variants.
- Do not add CMake logic, tests, stubs, or fallbacks for OFF variants.
- Do not report OFF variants as supported or partially supported.
- Validation must use BUILD_RTI=ON and BUILD_GRANTLEE=ON.

## Branches and trees

Qt6 target branch:

- feature/migrate-module-tetraif-only

Qt5 legacy branch, if comparison is needed:

- story/qt6-migration

Legacy source tree:

- ./qt-migration-legatus/qt5-before/qt5-legatus-legacy

Qt6 target tree:

- ./qt-migration-legatus/qt6-after/qt6-migrated-legatus

Work in the Qt6 target tree only. Do not modify the Qt5 legacy tree.

## Scope rules

Touch files outside the two target service directories only when directly required to configure, generate, build, link, test, or validate these services.

Allowed outside-scope changes:

- parent CMakeLists.txt entries for these services
- central CMake helper fixes required by these services
- shared include path fixes required by these services
- RTI, codegen, ndsgen, KTextTemplate, or Grantlee integration fixes required by these services
- test infrastructure needed by tests for these services
- new_docker_build.sh changes needed to run those tests
- minimal Jenkins CI discovery or policy updates needed for those tests
- relocation of required stubs or forward declarations to allowed directories

Not allowed:

- restoring removed modules
- reintroducing stale dependencies on removed modules
- removing or disabling active modules to hide failures
- disabling targets instead of fixing root causes
- broad refactoring, cleanup, renaming, or modernization
- warning suppression instead of fixing causes
- committing generated files
- consuming generated outputs from the source tree
- fake success, dummy files, handwritten generated replacements, mocks, placeholders, or generated-output stubs

## CMake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF:

- Discover real CMake targets defined under folder ./TetraIF when folder ./TetraIF exists.
- Add every required CMake target under folder ./TetraIF to ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh so the validation container builds or validates it.
- Add every required CMake target under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF to ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh so the validation container builds or validates it.
- Add new --groupN (with number N) option for required CMake ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF targets
- Add required apt packages to new_docker_build.sh
- Do not invent CMake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF
- Do not invent CMake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF.
- Do not add targets that do not exist.
- If folder ./TetraIF does not exist, has no CMake targets, or a target is intentionally out of scope, report that fact and the reason.
- Do not weaken validation to make CMake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF pass.

## Preservation rules

Preserve module removals from commit:

- 92ad7d468, "remove all unneeded module listed from Niklas"

Do not restore removed modules, files, targets, directories, or dependencies.

Preserve LogViewer reinsert from commit:

- 1fa789767, "Added LogViewer again"

Do not remove, disable, or break LogViewer integration.

Preserve prior IDL warning fixes from commit:

- be912de9d, "Removes .IDL warnings: multiple enum definitons and builtin-type collisions"

Do not blindly replay that commit. Use it only as reference. Do not reintroduce removed modules.

IDL regressions to avoid:

- multiple enum definitions
- duplicate enumerators
- builtin type or keyword collisions

Check first for duplicate inputs, stale paths, removed-module references, source-tree generated outputs, source/build-tree confusion, and repeated IDL definitions before treating an issue as semantic IDL conflict.

## Stubs and forward declarations

Any required existing stub, compatibility declaration, or forward declaration must live only under:

- ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations/
- ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/.forward-declarations/include/

Rules:

- Do not leave such files in source directories unless they are real source files.
- Do not create or keep stubs for forbidden OFF variants.
- Do not use stubs or forward declarations as replacements for real RTI, ndsgen, KTextTemplate, or Grantlee outputs in ON builds.
- Report every moved, removed, or newly referenced stub/forward declaration.

## Migration checks

For each cmake target, inspect and migrate only as needed:

- source and header files
- CMakeLists.txt and parent CMake registration
- ui, qrc, resource, plugin, and service metadata
- RTI IDL, ndsgen, KTextTemplate, and Grantlee inputs/templates
- tests directly tied to these services

Fix only real Qt6/C++17 build issues, such as:

- Qt module imports and target links
- moc, uic, and rcc handling
- QRegExp to QRegularExpression when required
- QTextCodec replacement when required
- QDesktopWidget or QApplication::desktop() replacement when required
- QString, QVariant, QMetaType, QDateTime, QAction, QMenu, signal/slot, enum, plugin, or metadata compatibility issues when required

No opportunistic refactoring or style cleanup.

## Qt link rules

No active target in the Qt6 tree may link Qt5 imported targets.

Search for and fix active uses of:

- Qt5::
- find_package(Qt5
- QT5_
- Qt5Core
- Qt5Widgets
- Qt5Network

Use Qt6 equivalents. Prefer central CMake helper fixes when the issue is central.

## Code generation rules

If generated files are required:

- reconstruct the real legacy generation flow
- generate into the build tree
- consume from the build tree
- list complete OUTPUT and BYPRODUCTS
- set correct DEPENDS and MAIN_DEPENDENCY where useful
- use deterministic WORKING_DIRECTORY
- use VERBATIM
- wire generated sources with target_sources
- wire generated include dirs with target_include_directories
- ensure compilation depends on generation
- ensure incremental rebuilds trigger on input/template changes

Never commit generated .idl, .h, .hpp, or .cpp outputs. Never consume generated outputs from the source tree. Never fabricate generated outputs.

## Tests

For every C++ code change, add three meaningful CTest tests where feasible.

The tests must:

- validate changed behavior, not only compilation
- be registered with CTest
- run with BUILD_RTI=ON and BUILD_GRANTLEE=ON
- not add OFF-variant tests
- be deterministic
- avoid host-local paths
- run reproducibly on Linux/Docker
- use Qt6-compatible APIs
- not introduce new Qt5-only APIs
- preferably live under:

  ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests

If three meaningful tests are not possible, add the maximum meaningful set and briefly explain in the final result why three tests were not feasible.

Test types:

1. Unit Tests

   Add targeted unit tests for isolated changed C++/Qt components.

   Examples:
   - changed QString/QByteArray/QVariant conversions
   - signal/slot behavior after Qt6 adjustments
   - model/delegate/proxy-model logic
   - parsing, mapping, or validation logic
   - Qt6 API migration behavior, such as enum class changes, QStringView, QRegularExpression, QDateTime, or QTextCodec replacements

2. Functional Tests

   Add functional tests that validate visible or user-relevant behavior.

   Functional tests should verify that a TetraIF feature works correctly from the user’s perspective, for example:

   - loading or initializing a TetraIF module
   - correctly creating, updating, or filtering data handled by TetraIF
   - expected signal emission after user-like or API-triggered actions
   - correct behavior of commands, actions, interfaces, adapters, or service-facing components
   - correct rendering or preparation of Grantlee-based templates, where relevant
   - expected handling of valid and invalid input

   Functional tests may use Qt test frameworks such as QTest, but they must not require real host-system user interaction, non-deterministic timing, or external resources.

3. Integration Tests

   Add integration tests that validate interaction between multiple migrated components.

   Integration tests should specifically check:

   - interaction between TetraIF components and shared project components
   - CMake target linkage with BUILD_RTI=ON and BUILD_GRANTLEE=ON
   - integration of Grantlee-dependent components
   - integration of RTI-dependent components, where meaningful without external infrastructure
   - initialization paths that may behave differently under Qt6
   - signal/slot communication across multiple objects
   - object lifetime, parent/child relationships, and QObject ownership after the Qt6 migration

   Integration tests must be reproducible in the Docker build and must not require external services, host-local files, or manual setup.

CTest/CMake requirements:

- All new tests must be registered with CTest.
- Add or update the necessary CMakeLists.txt files.
- Ensure test targets are built when BUILD_RTI=ON and BUILD_GRANTLEE=ON are enabled.
- Use policy-compatible test file names, for example:

  test_<name>.cpp
  <name>_test.cpp
  <name>test.cpp
  <name>_gtest.cpp

- Do not use file names that violate existing project or CMake policies.
- Do not add tests that only verify a target compiles.
- Every test must contain concrete assertions about behavior.
- Use stable, descriptive test names, for example:

  TetraIFModelMigratesQt6Behavior
  TetraIFTemplateRenderingUsesGrantlee
  TetraIFSignalsRemainCompatibleWithQt6

Docker build requirements:

Update the following script if needed:

./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

The script must be able to build and run the new or modified tests.

Required:

- BUILD_RTI=ON
- BUILD_GRANTLEE=ON
- CMake configuration for the relevant targets under:

  ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF

- execution of the relevant CTest tests
- output clearly showing which tests were built and executed
- no OFF variants
- no host-local absolute paths
- no assumptions about local developer environments

If the script already has a suitable build/CTest path, extend it minimally.
If the script does not run tests yet, add robust CTest execution for the newly relevant targets.

Preferred workflow:

1. Analyze the existing CMake structure under TetraIF and tests.
2. Identify the changed or still-to-be-migrated Qt5 components.
3. Add Qt6-compatible unit, functional, and integration tests.
4. Register all tests with CTest.
5. Ensure the tests build with BUILD_RTI=ON and BUILD_GRANTLEE=ON.
6. Update new_docker_build.sh so it builds or validates the relevant TetraIF CMake targets and runs the tests.
7. Run the build and tests where possible.
8. Document in the final result:
   - which tests were added
   - which behavior they validate
   - which CMake files were changed
   - what changed in new_docker_build.sh
   - whether three tests per C++ change were feasible
   - if not, why fewer tests were meaningful

Acceptance criteria:

- New or changed C++ logic is covered by meaningful tests.
- Functional tests validate actual TetraIF behavior.
- Integration tests validate interaction between multiple components.
- Tests are registered with CTest.
- Tests run with BUILD_RTI=ON and BUILD_GRANTLEE=ON.
- No OFF-variant tests are added.
- Tests are deterministic and independent of host-local paths.
- new_docker_build.sh builds or validates the required CMake targets under TetraIF.
- new_docker_build.sh runs the relevant CTest tests.
- The solution remains minimally invasive and compatible with the ongoing Qt5-to-Qt6 migration.

## Docker and CI

Authoritative migration Dockerfile:

- ./app/Dockerfile

Authoritative validation script:

- ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

Do not use other Dockerfiles as task authority.

Validation container expectations:

- repository root at /repo, or the script's documented mount path
- external dependencies under /repo/external, or the script's documented equivalent
- RTI 7.7 at /repo/external/rti_connext_dds-7.7.0, or documented equivalent
- ./rti_license.dat mounted read-only if RTI requires it
- no developer-local paths

Jenkins CI must be able to discover and run the new tests, or verify that new_docker_build.sh runs them. Inspect and minimally update only if needed:

- ./qt-migration-legatus/ci/Dockerfile.*
- ./qt-migration-legatus/ci/check_pr_policies.py

## Required procedure

1. Inspect repository state, branch, working tree, submodules, required prompts, service paths, and forward-declaration directories.
2. Compare Qt5 source services with Qt6 targets. Classify files as already migrated, missing, stale, generated, intentionally removed, build-only, or needing Qt6 adaptation.
3. Identify dependencies, generated inputs, Qt modules, parent CMake entries, removed-module references, LogViewer interactions, and required stub/forward-declaration relocations.
4. Apply the smallest valid migration changes.
5. Add required CTest tests for C++ changes.
6. Review RTI, ndsgen, KTextTemplate, and Grantlee generation paths.
7. Check regressions: Qt5 links, removed modules, LogViewer, IDL warnings, source-tree generated consumption, stale artifacts, and misplaced stubs.
8. Validate in Docker with BUILD_RTI=ON and BUILD_GRANTLEE=ON.
9. Run CTest in the validated build directory.
10. Check Jenkins/policy compatibility.
11. Report factual status.

Do not overwrite uncommitted user changes. If they block safe work, report the blocker.

## Required validation

From:

- ./qt-migration-legatus/qt6-after/qt6-migrated-legatus

Run:

```bash
BUILD_RTI=ON BUILD_GRANTLEE=ON ./new_docker_build.sh
```

CTest must run as part of validation. If a direct clean build is useful, use:

```bash
cmake -S /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus -B /repo/build-rti-on-grantlee-on -G Ninja -DCMAKE_BUILD_TYPE=Debug -DBUILD_RTI=ON -DBUILD_GRANTLEE=ON
cmake --build /repo/build-rti-on-grantlee-on --parallel
ctest --test-dir /repo/build-rti-on-grantlee-on --output-on-failure
```

Also check whether this file exists and run it only if present:

```bash
./new_docker-build.h
```

If it is absent or a typo, report that. Do not invent a replacement.

Do not run or validate OFF variants.

## Success criteria

Success requires:

- cmake targets migrated or confirmed already correct
- cmake targets included in the Qt6 build
- configure, build, and CTest pass with BUILD_RTI=ON and BUILD_GRANTLEE=ON
- new_docker_build.sh runs the relevant tests and fails on test failure
- Jenkins/policy discovery accepts the new tests and validation changes
- no active Qt5 imported target links remain for these services
- generated outputs are build-tree only and freshly produced when required
- no generated outputs are committed or consumed from the source tree
- no fake generated files, dummy files, mocks, placeholders, or stubbed generated outputs exist
- required stubs/forward declarations are only in allowed directories
- removed modules remain removed
- LogViewer remains preserved
- RoutingServiceNG prompt rules are followed
- RTI/codegen and Grantlee/KTextTemplate success is real, not stale or faked

## If blocked

Do not fake success. Report:

- failing command
- key error output
- affected service
- category: project, path, merge, CMake, Qt API, codegen, Docker, RTI/license, Grantlee/KTextTemplate, test, CTest, Jenkins CI, stub relocation, or environment
- what was fixed safely
- what remains blocked
- whether stale artifacts were ruled out
- whether generated files were involved
- exact missing files, targets, or generator step
- whether tests and CTest integration succeeded
- whether Docker validation and Jenkins discovery succeeded

## Final report

Keep it short. Include:

- status: validated, partially validated, or blocked
- cmake targets under folder ./TetraIF migrated or already correct
- files changed
- C++ files changed
- tests added per C++ change
- CTest registration changes
- CMake and generator changes
- stub/forward-declaration moves or removals
- Docker and Jenkins CI changes
- Qt5 references removed or remaining
- confirmation that removed modules were not restored
- confirmation that LogViewer was preserved
- exact validation commands and results
- result of new_docker-build.h if present
- remaining blockers or risks