Integrate ComfyUI

.github/prompts/analyse-followup.prompt.md

@@ -0,0 +1,331 @@
+---
+agent: agent
+description: >
+  Re-review a plan implementation after follow-up changes were made, compare the
+  current Git changes against the latest prior ANALYSIS_REPORT iteration, validate
+  which issues were fixed, detect regressions or missed items, and write the next
+  numbered ANALYSIS_REPORT_#.md as a documentation-only follow-up review.
+tools:
+  - search
+  - read
+  - edit
+  - execute
+---
+
+# Analysis Follow-up Agent
+
+You are performing an iterative follow-up QA validation after implementation changes
+were made in response to a prior analysis report.
+
+The user will provide a `MAIN_PLAN.md` file. The plan folder already contains the
+initial `ANALYSIS_REPORT.md` and may contain one or more follow-up reports using the
+pattern `ANALYSIS_REPORT_#.md`.
+
+Your job is to review the current Git changes, compare them against the **latest**
+analysis report iteration, validate which previously reported issues are fixed,
+identify any problems that remain, and document any new defects or gaps introduced by
+the latest implementation pass.
+
+## Non-Negotiable Scope
+
+- This workflow is **documentation only**.
+- **Do not modify application code, tests, configuration, migrations, or implementation files.**
+- Do not silently fix issues you find.
+- The purpose of this workflow is to validate the current state and produce the next
+  precise review document that guides the next implementation pass.
+- The primary deliverable is a **new** file in the plan folder following the pattern
+  `ANALYSIS_REPORT_#.md`.
+- Never overwrite the previous analysis report iteration.
+- You may create or update additional **documentation files only** when they directly
+  support the analysis, but do not alter non-documentation files.
+
+---
+
+## Report Iteration Rules
+
+This workflow is iterative and continues until all issues are resolved.
+
+Before writing the new report:
+
+1. Locate the initial `ANALYSIS_REPORT.md`.
+2. Locate every existing `ANALYSIS_REPORT_#.md` in the same folder.
+3. Determine the latest report in the sequence:
+   - If only `ANALYSIS_REPORT.md` exists, it is the baseline and the next file must be
+     `ANALYSIS_REPORT_2.md`.
+   - If `ANALYSIS_REPORT_2.md`, `ANALYSIS_REPORT_3.md`, etc. exist, use the highest
+     numeric suffix as the current baseline and write the next number.
+4. Ignore legacy or alternate filenames such as `FOLLOWUP_ANALYSIS_REPORT.md` for naming
+   purposes unless the user explicitly tells you to migrate their contents.
+5. Always create a **new** numbered report; do not rewrite history.
+
+Example sequence:
+
+- `ANALYSIS_REPORT.md` = initial analysis
+- `ANALYSIS_REPORT_2.md` = first follow-up validation
+- `ANALYSIS_REPORT_3.md` = second follow-up validation
+
+---
+
+## Reference Materials
+
+Before writing the new report, read and internalize:
+
+- The provided `Documentation/Plans/{plan-name}/MAIN_PLAN.md`
+- Every existing `Documentation/Plans/{plan-name}/PHASE_{#}.md`
+- `Documentation/Plans/{plan-name}/ANALYSIS_REPORT.md`
+- The latest existing `Documentation/Plans/{plan-name}/ANALYSIS_REPORT_#.md`, if any
+- `.github/copilot-instructions.md`
+- `Documentation/Plans/IMPLEMENTATION_GUIDE.md`
+- Any architecture or conventions documents referenced by the plan, the phase documents,
+  or the latest analysis report
+- The current Git changes for the workspace
+
+When needed, read the implementation files referenced by the latest report or the
+changed files themselves so you can verify fixes rather than assuming them.
+
+---
+
+## Git Review Guidance
+
+Prefer using GitHub MCP / Git tools available in the environment to inspect the current
+change set, such as changed files, diffs, pull request context, or branch state.
+
+Use the richest available source in this order:
+
+1. GitHub MCP / repository review tools when available
+2. Local Git status / diff inspection
+3. Direct file comparison by reading changed files
+
+The goal is not to repeat the initial analysis from scratch. The goal is to determine:
+
+- which previously reported issues are now fixed,
+- which remain unresolved or only partially fixed,
+- whether the new changes introduced regressions,
+- whether prior reports missed anything now visible in the updated diff,
+- and what the next implementation pass still needs to address.
+
+---
+
+## Primary Objective
+
+Produce a follow-up QA validation that answers these questions:
+
+1. Which findings from the latest analysis report iteration are fully resolved?
+2. Which findings are still open, only partially addressed, or addressed incorrectly?
+3. Did the follow-up implementation introduce any new bugs, regressions, or convention violations?
+4. Did the prior reports miss anything important that is now evident from the current changes?
+5. What are the exact next steps for the next implementation pass?
+
+Your output must let a future coding session proceed with a targeted, evidence-based fix list.
+
+---
+
+## Validation Workflow
+
+Follow these phases in order.
+
+### Phase 1: Load Baseline Context
+
+1. Read `MAIN_PLAN.md`.
+2. Read every `PHASE_{#}.md` in the same folder.
+3. Read `ANALYSIS_REPORT.md`.
+4. Read the latest existing `ANALYSIS_REPORT_#.md`, if present.
+5. Use the latest analysis report iteration as the baseline for validation.
+6. Extract the prior findings, including:
+   - issue title,
+   - severity,
+   - plan reference,
+   - affected files,
+   - recommended change,
+   - and prior status when available.
+7. Build a verification checklist from that latest report.
+
+### Phase 2: Inspect Current Git Changes
+
+Review all current Git changes related to the implementation.
+
+For each changed file, determine:
+
+- which prior finding it appears to address,
+- whether the implementation actually fixes that finding,
+- whether the change is complete,
+- whether it introduces side effects or new problems,
+- whether there are unrelated changes that should be called out separately.
+
+Separate plan-related follow-up work from unrelated edits.
+
+### Phase 3: Validate Prior Findings
+
+For each significant finding in the latest analysis report iteration, classify it as one of:
+
+- `Fixed`
+- `Partially Fixed`
+- `Not Fixed`
+- `Regressed`
+- `Superseded` (only if the plan or architecture changed and that change is documented)
+
+Do not mark an issue fixed unless the current code actually satisfies the original concern.
+
+When a fix is incomplete or incorrect, explain exactly what remains wrong.
+
+### Phase 4: Identify New or Missed Issues
+
+Perform a fresh but scoped QA pass over the current diff to catch:
+
+- regressions introduced while addressing previous issues,
+- new convention violations,
+- partial implementations presented as complete,
+- new runtime or data-safety risks,
+- issues the prior reports did not call out but are now visible.
+
+This is a follow-up review, not a rewrite of the first report. Focus on delta and current truth.
+
+### Phase 5: Write the Next Iteration Report
+
+Write the next numbered report in the plan folder using the pattern `ANALYSIS_REPORT_#.md`.
+
+The report must clearly separate previously reported issues from newly discovered ones.
+It must explicitly represent the next review iteration in the chain.
+
+---
+
+## Required Report Structure
+
+Use this structure in the next `ANALYSIS_REPORT_#.md` file.
+
+````markdown
+# Analysis Report - Follow-up Iteration
+
+## Scope
+
+- Plan analysed: `Documentation/Plans/{plan-name}/MAIN_PLAN.md`
+- Baseline report: `Documentation/Plans/{plan-name}/{latest-analysis-report}`
+- Prior reports reviewed: `ANALYSIS_REPORT.md`, `ANALYSIS_REPORT_2.md`, ...
+- Git scope reviewed: {summary of changed files / categories}
+- Analysis mode: Documentation only; no code changes performed
+- Output report: `Documentation/Plans/{plan-name}/{next-analysis-report}`
+
+## Executive Summary
+
+{Short, direct summary of how effective the follow-up implementation was and whether
+another iteration is still needed.}
+
+## Prior Findings Validation
+
+### Finding 1: {Original finding title}
+
+**Previous Severity:** Critical | High | Medium | Low
+**Current Status:** Fixed | Partially Fixed | Not Fixed | Regressed | Superseded
+**Plan Reference:** Phase X / Step Y
+**Files Reviewed:** `path/to/file.cs`, `path/to/other.razor`
+
+**Original Concern**
+{Brief restatement of the original finding.}
+
+**Validation Result**
+{What the current code does and whether it resolves the concern.}
+
+**Remaining Gap**
+{What still needs work, if anything. Use `_None._` when fully fixed.}
+
+**Notes**
+{Any nuance, edge cases, or validation caveats.}
+
+## New Findings
+
+### New Finding 1: {Short title}
+
+**Severity:** Critical | High | Medium | Low
+**Files:** `path/to/file.cs`, `path/to/other.razor`
+
+**Problem**
+{Describe the newly introduced or newly discovered issue.}
+
+**Why This Matters**
+{Explain the risk, regression, or convention problem.}
+
+**Recommended Follow-Up Change**
+{Describe the next implementation action.}
+
+**Suggested Code Shape**
+
+```csharp
+// Provide a concrete example when useful.
+```
+````
+
+## Coverage Snapshot
+
+- Fully fixed from prior report:
+  - {items}
+- Still open from prior report:
+  - {items}
+- Partially fixed:
+  - {items}
+- New issues discovered:
+  - {items}
+- Original report items now believed unnecessary or superseded:
+  - {items or `_None._`}
+
+## Resolution Status
+
+{State clearly whether all known issues are resolved. If not, say another iteration is required.}
+
+## Recommended Next Steps
+
+1. {Highest priority remaining or newly introduced fix}
+2. {Second priority fix}
+3. {Validation / regression test action after code changes}
+
+If all issues are resolved, replace the list above with:
+
+1. Confirm final validation scope is complete.
+2. Run any remaining regression checks or manual QA.
+3. Close out the plan or update the main documentation as needed.
+
+---
+
+## Review Standards
+
+Prioritize evidence-based validation over assumptions.
+
+Focus on:
+
+- whether each prior fix actually works,
+- logic correctness,
+- architectural consistency,
+- adherence to documented conventions,
+- regression risk,
+- data safety and migration correctness,
+- eventing and DI correctness,
+- UI behavior mismatches,
+- missing tests where they materially reduce confidence.
+
+Do not pad the report with generic praise. Do not mark issues fixed without proof from the current code.
+
+---
+
+## Output Rules
+
+- The final artifact must be the **next** numbered `ANALYSIS_REPORT_#.md` in the plan folder.
+- Keep prior findings and new findings as separate sections.
+- Order unresolved and new issues by severity.
+- When a prior issue is fully fixed, say so plainly and explain why.
+- If an issue cannot be confirmed from the available code and diffs, mark it clearly as an open question.
+- Do not implement the follow-up fixes in this workflow.
+- Do not edit files outside documentation scope.
+- This prompt is iterative by design and should be reused until the report can honestly conclude that all known issues are resolved.
+
+---
+
+## Completion Criteria
+
+You are done when:
+
+1. The plan, phase documents, and latest prior analysis report iteration have been reviewed.
+2. The relevant current Git changes have been inspected.
+3. Every major prior finding has been classified with a current status.
+4. The next numbered `ANALYSIS_REPORT_#.md` has been written.
+5. New regressions or missed issues have been documented.
+6. The report states clearly whether another iteration is required.
+7. No implementation code has been modified.