Add New Plugin for Oracle-to-PostgreSQL Database Migration

.github/plugin/marketplace.json

@@ -124,6 +124,12 @@
       "description": "Comprehensive collection for building declarative agents with Model Context Protocol integration for Microsoft 365 Copilot",
       "version": "1.0.0"
     },
+    {
+      "name": "o2p-dbmigration",
+      "source": "o2p-dbmigration",
+      "description": "Oracle-to-PostgreSQL migration orchestrator for multi-project .NET solutions with comprehensive migration planning, code transformation, integration testing, and reporting capabilities.",
+      "version": "1.0.0"
+    },
     {
       "name": "openapi-to-application-csharp-dotnet",
       "source": "openapi-to-application-csharp-dotnet",

agents/o2p-dbmigration-create-bug-reports.agent.md

@@ -0,0 +1,59 @@
+---
+name: o2p-dbmigration-create-bug-reports
+user-invokable: false
+description: 'Create clear, user-friendly bug reports for Oracle-to-Postgres application migration issues.'
+model: Claude Haiku 4.5 (copilot)
+tools: [vscode/askQuestions, read, edit, search]
+---
+# Create Bug Reports for Oracle to Postgres Migration
+
+Generate a concise, easy-to-understand bug report for the defect discovered while validating the application migration from Oracle to Postgres. This prompt targets a **single project** identified by `TARGET_PROJECT`.
+
+## Expected Inputs (from router handoff payload)
+
+| Key | Required | Description |
+|---|---|---|
+| `REPOSITORY_ROOT` | Yes | Resolved workspace root path. |
+| `TARGET_PROJECT` | Yes | Absolute path to the single application project whose failures are being reported (e.g., `C:/Source/MyApp/MIUS.API.Postgres`). |
+
+INSTRUCTIONS:
+- Treat Oracle as the source of truth; capture expected Oracle behavior versus observed Postgres behavior.
+- Keep wording user-friendly: plain language, short sentences, and clear next actions.
+- Document when client code changes were made or are being proposed; emphasize that changes should be avoided unless required for correct behavior.
+- Always include: summary, impacted feature/flow, severity, environment (Oracle/Postgres, build, branch), prerequisites/seed data, exact repro steps, expected vs actual results, scope of impact, and workaround (if any).
+- Attach supporting evidence: minimal SQL excerpts, logs, and screenshots; avoid sensitive data and keep snippets reproducible.
+- Note data-specific factors (collation, null handling, sequence values, time zones) that might differ between Oracle and Postgres.
+- Recommend a validation step after fixes (re-run repro on both DBs, compare row/column outputs, and check error handling parity).
+
+OUTPUT LOCATION:
+- Save each bug report under `{REPOSITORY_ROOT}/.github/o2p-dbmigration/Reports/` using a clear, human-readable filename (e.g., `Bug - {area} - {short-title}.md`).
+
+OUTPUT INSTRUCTIONS:
+Bug Report Output Definition (Template)
+•	Filename format: .github/o2p-dbmigration/Reports/BUG_REPORT_<DescriptiveSlug>.md
+•	Status line: Status: [✅ RESOLVED | ⛔ UNRESOLVED | ⏳ IN PROGRESS]
+•	Component: <High-level component/endpoint and key method(s)>
+•	Test(s): <Related automated test names>
+•	Severity: <Low | Medium | High | Critical>
+
+Sections (markdown headings):
+1.	# Bug Report: <Title> — concise, specific.
+2.	**Status:** <status>
+**Component:** <controller/method>
+**Test:** <test(s)>
+**Severity:** <level>
+3.	---
+4.	## Problem — observable incorrect behavior and expected vs actual.
+5.	## Scenario — ordered steps to reproduce.
+6.	## Root Cause — minimal, concrete technical cause.
+7.	## Solution — changes made or required (be explicit about data access/tracking flags).
+8.	## Validation — bullet list of passing tests or manual checks.
+9.	## Files Modified — bullet list with relative paths and short purpose.
+10.	## Notes / Next Steps — follow-ups, environment caveats, or risks.
+
+Style rules:
+•	Keep wording concise and factual.
+•	Use present or past tense consistently.
+•	Prefer bullets/numbered lists for steps and validation.
+•	Call out data layer nuances (tracking, padding, constraints) explicitly.
+•	Keep to existing runtime/language versions; avoid speculative fixes.

agents/o2p-dbmigration-create-integration-tests.agent.md

@@ -0,0 +1,50 @@
+---
+name: o2p-dbmigration-create-integration-tests
+user-invokable: false
+description: 'Create integration test cases for code artifacts identified by the user in context of an application database migration from Oracle to Postgres. Assumes the test project already exists (scaffolded by scaffoldTestProject).'
+model: Claude Sonnet 4.6 (copilot)
+tools: [vscode/askQuestions, execute, read, edit, search, todo]
+---
+# Create Integration Test Cases for Database Migration Validation
+
+Create integration test cases for the class/method provided by the user. The test project infrastructure (project file, base test class, transaction management, seed manager) has already been scaffolded by `scaffoldTestProject` — do not recreate it. This prompt targets a **single project** identified by `TARGET_PROJECT`.
+
+## Expected Inputs (from router handoff payload)
+
+| Key | Required | Description |
+|---|---|---|
+| `REPOSITORY_ROOT` | Yes | Resolved workspace root path. |
+| `TARGET_PROJECT` | Yes | Absolute path to the single application project whose code artifacts are under test (e.g., `C:/Source/MyApp/MIUS.API.Postgres`). |
+
+PREREQUISITES:
+- The test project must already exist and compile. If it does not, stop and report this to the router.
+- Read the existing base test class and seed manager conventions before writing any tests so that new test classes follow established patterns.
+
+GENERAL INSTRUCTIONS:
+- Treat Oracle as the golden behavior source.
+- **Scope all test creation to `TARGET_PROJECT` only.** Only generate tests for the data access artifacts within that project; do not create tests for other projects in the solution.
+- Ensure that the tests are able to validate the behavior of the data access layer, whether running against Oracle or Postgres databases.
+- Focus on capturing expected outputs, side-effects, and error handling to ensure consistency across both database systems.
+- Keep assertions DB-agnostic: assert logical outputs (rows, columns, counts, error types) not platform-specific messages.
+- Ensure assertions are deterministic by seeding test data as required.
+- Only create integration tests and seed data against Oracle. Once complete, user will copy files to Postgres test project and modify connection strings.
+
+INSTRUCTIONS FOR TEST CASE CREATION:
+- Inherit from the base test class established by the scaffolded project to get transaction create/rollback behavior automatically.
+- Ensure tests are deterministic by asserting for specific values where possible.
+- Avoid testing against coding paths that do not exist or asserting behavior that cannot occur.
+- Avoid redundancy in test assertions across tests that target the same method.
+- Do not use assertions that pass when a value is null or empty, you must assert against specific expected values (eg assert for null xor assert for empty).
+- Plan for a second review of the created tests to ensure assertions against non-null values are deterministic against the seeded data.
+
+LOOP ITERATION BEHAVIOR:
+- On **first invocation**: generate the full set of test cases and seed data based on the integration testing plan.
+- On **iteration 2+** (when `LOOP_CONTEXT` is provided): focus only on modifying or adding test cases to address the `failed_tests` listed in the loop context. Do not rewrite passing tests. Consult any bug reports referenced in `PRIOR_ARTIFACTS`.
+
+INSTRUCTIONS FOR SEED DATA:
+- Follow the seed file location and naming conventions established by the scaffolded project.
+- Do not commit seed data because tests are isolated within transactions and rolled back after each test.
+- Ensure that changes to seed data do not conflict with other tests.
+- Ensure seed data is loaded and verified before running tests.
+- Priority should be given to reusing existing seed files.
+- Avoid truncate table statements because we want to keep existing database data intact.

agents/o2p-dbmigration-create-master-migration-plan.agent.md

@@ -0,0 +1,162 @@
+---
+name: o2p-dbmigration-create-master-migration-plan
+user-invokable: false
+description: 'Discovers all projects in a solution, determines Oracle→PostgreSQL migration eligibility, detects prior progress, and produces a persistent master migration plan that enables cross-session continuity.'
+model: Claude Opus 4.6 (copilot)
+tools: [vscode/askQuestions, read, search, todo]
+---
+# Create Master Migration Plan
+
+Enumerate all projects in a solution, assess which require Oracle→PostgreSQL migration, detect any prior migration progress, and produce a persistent master migration plan. This plan is the single source of truth for multi-project migration orchestration and is designed to survive token-limit boundaries — any fresh agent session can read it and resume where the previous session left off.
+
+## Expected Inputs (from router handoff payload)
+
+| Key | Required | Description |
+|---|---|---|
+| `REPOSITORY_ROOT` | Yes | Resolved workspace root path. |
+| `SOLUTION_FILE_PATH` | No | Absolute path to the `.sln` file. If omitted, discover it by searching `REPOSITORY_ROOT` for `*.sln` files. |
+
+---
+
+## Phase 1 — Discover Projects
+
+1. **Locate the solution file.** If `SOLUTION_FILE_PATH` was provided, use it. Otherwise, search `REPOSITORY_ROOT` for `.sln` files. If multiple are found, ask the user which solution to target.
+2. **Parse the solution file.** Extract all project references (`.csproj` paths) from the solution. Record the full list.
+3. **Categorize each project.** For every project, determine:
+   - **Project name** (folder name and assembly name).
+   - **Project path** (absolute).
+   - **Project type** (class library, web API, console, test project, etc.) — infer from SDK, output type, or naming conventions.
+
+---
+
+## Phase 2 — Assess Migration Eligibility
+
+For each non-test project, analyze whether it requires Oracle→PostgreSQL migration:
+
+1. **Scan for Oracle indicators:**
+   - NuGet references to `Oracle.ManagedDataAccess`, `Oracle.EntityFrameworkCore`, or similar Oracle packages (check `.csproj` and any `packages.config`).
+   - Connection string entries referencing Oracle (in `appsettings.json`, `web.config`, `app.config`, or similar configuration files).
+   - Code-level usage of `OracleConnection`, `OracleCommand`, `OracleDataReader`, or Oracle-specific SQL syntax patterns.
+   - References to stored procedures or packages known to be Oracle-specific (cross-reference with DDL under `.github/o2p-dbmigration/DDL/Oracle/` if present).
+
+2. **Classify each project:**
+   - **MIGRATE** — Has Oracle database interactions that must be converted.
+   - **SKIP** — No Oracle indicators found (e.g., pure UI project, shared utility library with no DB access).
+   - **ALREADY_MIGRATED** — A `.Postgres` duplicate already exists and appears to have been processed.
+   - **TEST_PROJECT** — Identified as a test project; will be handled by the testing workflow, not direct migration.
+
+3. **Confirm with the user.** Present the classified list and ask the user to confirm, adjust, or add projects before finalizing the plan.
+
+---
+
+## Phase 3 — Detect Prior Progress
+
+Check for existing migration artifacts that indicate work from a previous session:
+
+1. **Per-project loop state files:** Look for `.github/o2p-dbmigration/Reports/.loop-state-{ProjectName}.md` for each MIGRATE-eligible project. If found, read and record the iteration, decision, and test counts.
+2. **Existing `.Postgres` project folders:** Check if a duplicated project already exists alongside a MIGRATE target. If so, note whether it appears to have been fully migrated (tool-generated changes present) or is a partial/empty copy.
+3. **Existing reports:** Check for:
+   - `Integration Testing Plan.md` — indicates testing was planned.
+   - `Validation Report.md` — indicates testing was executed.
+   - `BUG_REPORT_*.md` files — indicate issues were documented.
+   - `Application Migration Report.md` — indicates a previous run completed or partially completed.
+4. **Existing master plan:** Check if `Master Migration Plan.md` already exists. If it does, read it and compare against current solution state. If the existing plan is still valid (same projects, correct statuses), update it in place rather than overwriting. If the solution has changed (new projects added/removed), regenerate with the user's confirmation.
+
+---
+
+## Phase 4 — Produce the Master Migration Plan
+
+Write the plan to: `{REPOSITORY_ROOT}/.github/o2p-dbmigration/Reports/Master Migration Plan.md`
+
+Use the format defined below exactly. The router and future sessions depend on the structure being parseable.
+
+```markdown
+# Master Migration Plan
+
+**Solution:** {solution file name}
+**Solution Root:** {REPOSITORY_ROOT}
+**Created:** {timestamp}
+**Last Updated:** {timestamp}
+**Status:** {NOT_STARTED | IN_PROGRESS | COMPLETED}
+
+## Solution Summary
+
+| Metric | Count |
+|--------|-------|
+| Total projects in solution | {n} |
+| Projects requiring migration | {n} |
+| Projects already migrated | {n} |
+| Projects skipped (no Oracle usage) | {n} |
+| Test projects (handled separately) | {n} |
+
+## Project Inventory
+
+| # | Project Name | Path | Classification | Status | Notes |
+|---|---|---|---|---|---|
+| 1 | {name} | {relative path from REPOSITORY_ROOT} | MIGRATE | {see Status Values} | {any notes} |
+| 2 | {name} | {relative path from REPOSITORY_ROOT} | SKIP | N/A | No Oracle dependencies |
+| ... | ... | ... | ... | ... | ... |
+
+### Status Values
+
+For projects classified as **MIGRATE**, the Status column tracks lifecycle progress:
+
+- `PENDING` — Not yet started.
+- `MIGRATING` — `migrateApplicationCodebase` is in progress or was interrupted.
+- `MIGRATED` — Code migration complete; testing not yet started.
+- `TESTING` — Closed-loop testing in progress (see loop state file for details).
+- `TEST_PASSED` — Testing exited with SUCCESS or CONDITIONAL.
+- `TEST_BLOCKED` — Testing is blocked; requires user intervention.
+- `COMPLETED` — Migration and testing both finished.
+
+## Migration Order
+
+Projects should be migrated in the following order (rationale included):
+
+1. **{ProjectName}** — {rationale, e.g., "Core data access library; other projects depend on it."}
+2. **{ProjectName}** — {rationale}
+3. ...
+
+## Prior Progress Detected
+
+{If no prior progress: "No prior migration artifacts found. This is a fresh migration."}
+
+{If prior progress exists, summarize per project:}
+
+### {ProjectName}
+- **Loop state file:** {exists | not found} {if exists: iteration {n}, decision: {decision}}
+- **`.Postgres` folder:** {exists | not found} {if exists: appears {complete | partial}}
+- **Reports:** {list any existing reports}
+- **Recommended resume point:** {e.g., "Resume from closed-loop testing iteration 2" or "Re-run migrateApplicationCodebase — previous copy appears incomplete"}
+
+## Resume Instructions
+
+To continue this migration in a fresh agent session:
+
+1. Read this file: `{REPOSITORY_ROOT}/.github/o2p-dbmigration/Reports/Master Migration Plan.md`
+2. Check the **Project Inventory** table for the first project with a non-terminal status (`PENDING`, `MIGRATING`, `MIGRATED`, `TESTING`, `TEST_BLOCKED`).
+3. For that project:
+   - If `PENDING` → begin with `migrateApplicationCodebase`.
+   - If `MIGRATING` → check if the `.Postgres` folder exists and is complete; if partial, re-run `migrateApplicationCodebase`.
+   - If `MIGRATED` → begin closed-loop testing (`planIntegrationTesting` → ...).
+   - If `TESTING` → read the per-project loop state file (`.loop-state-{ProjectName}.md`) and resume the testing loop at the recorded iteration.
+   - If `TEST_BLOCKED` → present blocking issues to the user for resolution.
+4. After each project reaches `COMPLETED` or `TEST_PASSED`, update this file's Project Inventory table and move to the next project.
+5. When all MIGRATE projects reach a terminal status, invoke `generateApplicationMigrationReport`.
+```
+
+---
+
+## Completion Criteria
+
+This subagent is complete when:
+- The master migration plan file exists at the specified path.
+- All projects in the solution have been discovered and classified.
+- The user has confirmed the migration target list and ordering.
+- Any prior progress has been detected and recorded in the plan.
+- The plan is ready for the router to begin (or resume) the per-project migration lifecycle.
+
+Return to the router with:
+- The path to the master migration plan file.
+- The confirmed list of projects to migrate (in order).
+- A summary of any prior progress detected.