Apply Revised fd Review Corrections.prompt

# 53 - Apply Revised FD Review Corrections

## Purpose

Apply a second and final targeted correction pass to the revised customer-facing Functional Design based on the revised FD review report.

This step exists to fix remaining issues after step 52 without starting an infinite AI revision loop.

This task must not generate DD, code design, implementation design, or new source behavior.

## Operating rules

- Use only the source artifacts listed in this prompt.
- Treat this as a targeted patch task, not a full FD regeneration task.
- Do not regenerate the full FD from scratch unless `output/52_FD_REVISED_REVIEW_REPORT.md` explicitly says the entire FD structure is unusable.
- Keep the patched FD customer-facing.
- Do not expose internal artifact names in the customer-facing FD.
- Do not expose internal IDs such as `REQ-xxx`, `BR-xxx`, `TERM-xxx`, `OQ-xxx`, `FIG-xxx`, `TRACE-xxx`, or `RTRACE-xxx` in the customer-facing FD.
- Do not mention requirement inventory, business rule catalog, glossary, image analysis, translation review, internal traceability, intermediate artifact, prompt, AI, or pipeline in the customer-facing FD.
- Do not add new requirements.
- Do not invent source evidence.
- Do not introduce implementation architecture unless the source explicitly supports it.
- Preserve source-supported conditions, exceptions, notes, footnotes, negative statements, unsupported behavior, and visual evidence.
- Preserve customer-facing Markdown image references and Mermaid diagrams only when they are source-supported and traceable.
- Remove, simplify, or mark as `Requires confirmation` any visual content that is weakly traced, figure-only, ambiguous, or overstated.
- If a review issue cannot be safely fixed as confirmed FD behavior, move it to the Open Questions section.
- If a statement is untraced and not needed, remove it.
- If a statement is editorial, generic, or marketing-like, remove it or rewrite it as a source-supported technical statement.
- Respect strikethrough/deprecated evidence rules: strikethrough-only evidence must not be used as active FD behavior unless the source explicitly says otherwise.
- Keep output in English.

## Tasks

### Precondition

Use `output/52_FD_REVISED_REVIEW_REPORT.md` as the controlling review gate.

Continue only when the step 52 recommendation is one of:

- `No-Go`
- `Go with minor corrections`

If the step 52 recommendation is `Go`, stop and report that no second correction pass is required.

This step patches:

- `output/50_FD_DRAFT_REVISED.md`

This step creates:

- `output/53_FD_DRAFT_REVISED_PATCHED.md`
- `output/53_FD_PATCH_LOG.md`

### Correction priorities

Apply corrections in this order:

1. Fix Critical issues from `output/52_FD_REVISED_REVIEW_REPORT.md`.
2. Fix Major issues from `output/52_FD_REVISED_REVIEW_REPORT.md`.
3. Fix customer-facing cleanliness issues.
4. Fix untraced or partially traced FD statements.
5. Fix potential overstatements.
6. Add missing source-supported requirement/rule coverage.
7. Move uncertain source-supported items to Open Questions.
8. Fix visual traceability issues.
9. Fix minor wording and formatting issues.

### Instructions

Create a complete patched FD at:

- `output/53_FD_DRAFT_REVISED_PATCHED.md`

The patched FD must be a full document, not a diff.

Also create a separate internal patch log at:

- `output/53_FD_PATCH_LOG.md`

Do not append the internal patch log to the customer-facing FD.

## Inputs

### Primary inputs

- `output/50_FD_DRAFT_REVISED.md`
- `output/50_FD_REVISION_LOG.md`
- `output/51_FD_REVISED_INTERNAL_TRACEABILITY.md`
- `output/52_FD_REVISED_REVIEW_REPORT.md`

### Source-of-truth inputs for correction validation

- `output/30_requirement_inventory.md`
- `output/31_business_rule_catalog.md`
- `output/32_open_questions.md`
- `output/21_glossary.md`
- `output/20_image_analysis.md`
- `output/12_normalized_evidence.md`

### Supporting inputs, open only when needed

- `output/40_FD_DRAFT.md`, if comparison with the first FD draft is needed
- `output/41_FD_INTERNAL_TRACEABILITY.md`, if comparison with the first traceability report is needed
- `output/42_FD_REVIEW_REPORT.md`, if previous issue history is needed
- `output/11_translation_policy.md`, if terminology verification is needed
- `output/10_document_inventory.md`, if source navigation is needed
- `working/extracted/document_text.md`, only for targeted verification
- `working/extracted/tables.md`, only for targeted verification
- `working/extracted/image_inventory_raw.md`, only for targeted visual path verification

## Outputs

### Output files to create or update

- `output/53_FD_DRAFT_REVISED_PATCHED.md`
- `output/53_FD_PATCH_LOG.md`

## Required output quality

### Customer-facing patched FD rules

The file `output/53_FD_DRAFT_REVISED_PATCHED.md` must:

- be a complete customer-facing Functional Design document;
- use professional English;
- preserve the FD structure unless the review report explicitly requires restructuring;
- contain only source-supported behavior;
- preserve source-supported unsupported cases, negative statements, constraints, exceptions, notes, and footnotes;
- mark uncertain items as `TBD`, `Requires confirmation`, or Open Questions;
- include only relevant, source-supported, traceable visual content;
- avoid internal IDs and internal artifact names;
- avoid internal review notes and patch summaries.

### Internal patch log rules

The file `output/53_FD_PATCH_LOG.md` may include internal IDs and internal review issue references.

Write the patch log using this structure: