You are working on a migration from RTI Connext 6 to RTI 7.7.

IMPORTANT:
Work in two strictly separated phases:
1. Analysis
2. Patching

Do not modify files before you have completed the analysis and written down a migration classification.

Your task is to compare:
- step-1 Copilot-created fallback/reconstructed RTI-related files created while `BUILD_RTI=OFF`
with
- real RTI 7.7 generated DDS/RTI artifacts created while `BUILD_RTI=ON`

Then update only the manually maintained / Copilot-created files so they correctly reflect the RTI 7.7 generated output.

## Main Goal
Make the codebase cleanly support the real RTI 7.7 generation in the `BUILD_RTI=ON` path, while preserving `BUILD_RTI=OFF` fallbacks only where truly necessary.

## Hard Rules
- Treat RTI 7.7 generated files as source of truth for `BUILD_RTI=ON`.
- Do not edit generated RTI files unless absolutely unavoidable and explicitly justified.
- Prefer adapting manual files, wrappers, compatibility headers, includes, and guards.
- Remove or isolate reconstructed definitions if they duplicate RTI 7.7 generated types.
- Keep fallback logic only for `BUILD_RTI=OFF`.
- Do not perform unrelated refactoring.
- Do not guess generated API shapes; inspect actual generated files.

## Required Workflow

# Phase 1 — Analysis only

## A. Identify migration-related files
Find:
- reconstructed RTI headers
- compiler guards added in step 1
- fallback DDS/RTI type definitions
- wrappers/adapters around DDS/RTI types
- include indirection layers
- files conditionally compiled for `BUILD_RTI`

Use repository inspection commands such as:
- `git status`
- `git diff --name-only`
- `git log --stat`
- `rg -n "BUILD_RTI|RTI|DDS|Connext|ifdef|ifndef|pragma once" .`
- `rg -n "#if.*BUILD_RTI|#ifdef.*BUILD_RTI|#ifndef.*BUILD_RTI" .`
- `find . -iname "*dds*" -o -iname "*rti*"`

If available, inspect step-1-related changes via:
- `git diff <baseline>...HEAD`
- `git log --grep="RTI\|DDS\|BUILD_RTI"`
- targeted diffs for migration commits

## B. Identify real RTI 7.7 generated artifacts
Locate the generated files produced with `BUILD_RTI=ON`.

Inspect:
- build directories
- generated include folders
- CMake-generated outputs
- RTI codegen output directories
- custom generation scripts

Use commands such as:
- `find build -type f | rg "dds|rti|idl|type|Support|Plugin"`
- `find . -type f | rg "Support\.h$|Plugin\.h$|Plugin\.cxx$|\.idl|\.xml"`
- `rg -n "rtiddsgen|connext|idl" CMakeLists.txt cmake/ .`
- `rg -n "GENERATED|AUTO_GENERATED|DO NOT EDIT" .`

## C. Compare reconstructed vs generated artifacts
For each reconstructed/manual RTI-related file, compare against the generated RTI 7.7 counterpart.

Check:
- file names
- include paths
- header guards / `#pragma once`
- macros
- namespaces
- class / struct / enum / typedef / alias definitions
- forward declarations
- helper APIs / traits / adapters
- symbol names
- expected include order
- conditional compilation behavior under `BUILD_RTI=ON` vs `BUILD_RTI=OFF`

Use comparison commands where helpful:
- `diff -u <manual-file> <generated-file>`
- `git diff --no-index <manual-file> <generated-file>`
- `rg -n "<TypeName>" .`
- `rg -n "#include <...>|#include \"...\"" <relevant paths>`

## D. Trace usage
Find all places that still reference the reconstructed step-1 artifacts.

Use:
- `rg -n "<header-name>|<type-name>|<guard-name>" .`
- `rg -n "#include .*<reconstructed-header>|#include .*\"<reconstructed-header>\"" .`

Determine:
- which files still depend on old reconstructed headers
- which guards still activate old fallback definitions
- which paths could conflict with generated RTI 7.7 types

## E. Build-path analysis
Inspect build logic and conditional compilation paths.

Check:
- `CMakeLists.txt`
- `*.cmake`
- generation scripts
- target include directories
- compile definitions
- `compile_commands.json` if present

Use:
- `rg -n "BUILD_RTI|target_include_directories|target_compile_definitions|add_definitions|include_directories" .`
- `find build -name compile_commands.json`
- inspect compile commands for affected targets

Goal:
Determine exactly how `BUILD_RTI=ON` and `BUILD_RTI=OFF` select different headers and definitions.

## F. Produce migration classification
Before patching, classify findings into:
- **REMOVE** = obsolete step-1 artifact replaced by RTI 7.7 generation
- **KEEP_OFF_ONLY** = still needed only when `BUILD_RTI=OFF`
- **PATCH** = manual file must be changed
- **VERIFY** = uncertain; validate before touching

Do not patch before this list is explicit.

# Phase 2 — Patching only after analysis

## Allowed patch types
- replace old includes with RTI 7.7 generated includes
- restrict fallback type definitions to `BUILD_RTI=OFF`
- tighten or invert guards so `BUILD_RTI=ON` always prefers generated output
- remove duplicate type declarations
- update wrappers/adapters to use actual RTI 7.7 generated types
- isolate obsolete reconstructed headers so they no longer affect `BUILD_RTI=ON`
- adjust build include paths only if necessary to stop wrong header selection

## Patch objectives
- `BUILD_RTI=ON` uses actual RTI 7.7 generated headers/types
- no old fallback header shadows generated output
- no duplicate definitions remain
- no stale RTI Connext 6 assumptions remain where RTI 7.7 differs
- `BUILD_RTI=OFF` stays supported only where explicitly needed

## Explicitly avoid
- editing generated files first
- broad renames
- non-migration-related cleanup
- speculative API rewrites
- silently dropping `BUILD_RTI=OFF` support

# Verification after patching

Run or propose the most relevant checks:
- `rg -n "<obsolete-header-or-type>" .`
- `rg -n "redefinition|redeclaration" <build logs if available>`
- project build with `BUILD_RTI=ON`
- if supported, project build with `BUILD_RTI=OFF`
- inspect compiler errors for include-order or duplicate-type issues

If build commands are available, use them. Typical examples:
- `cmake -S . -B build -DBUILD_RTI=ON`
- `cmake --build build -j`
- `cmake -S . -B build-off -DBUILD_RTI=OFF`
- `cmake --build build-off -j`

If tests exist and are relevant, run targeted tests only after the migration patches are in place.

## Output Format
First output:

1. **Analysis summary**
2. **Migration classification**
   - REMOVE
   - KEEP_OFF_ONLY
   - PATCH
   - VERIFY

Then patch files only after the analysis is complete.

For every changed file, report and write to ./RTI_MIGRATION_STATUS.md:
1. file path
2. category
3. problem found
4. exact change made
5. rationale
6. follow-up validation / residual risk

When uncertain, prefer minimal safe changes and document the uncertainty.

Start now with Phase 1 only.
Do not patch anything until the analysis and classification are complete.