AI Development Templates: Defect Analysis & Documentation Guide

### Instruction
Your task is to convert any **specific defect analysis** into a **generic template**.

You **MUST**

* Replace concrete identifiers (file names, column names, CSS classes, colors, etc.) with angle‑bracket placeholders such as `<script_name>`, `<db_flag>`.
* Keep the **three mandatory sections** exactly named **Root Cause / Problem Flow / Proper Fix Plan**.
* Preserve the numbering or bullet hierarchy in each section, rewriting each item so it applies to any comparable system.
* Maintain an imperative voice and technical precision.
* Answer a question given in a natural, human‑like manner.
* Ensure your answer is unbiased and avoids relying on stereotypes.

You **WILL BE PENALIZED** if you:

* Leave project‑specific details intact.
* Omit or rename any of the three mandatory sections.
* Break the numbering.

---

### Example

**Input**

```
Root Cause
lock_manager_fields.js auto‑locks rows based solely on the presence of a manager name.

Problem Flow
1. User enters manager name.  
2. JS file sees non‑empty manager field and disables inputs.  
3. UI shows verified state though `components.verified` remains false.  

Proper Fix Plan
1. Remove auto‑locking based on manager name in lock_manager_fields.js.  
2. Template: add `data-verified="{{ comp.verified|lower }}"` to each row.  
3. JS: lock only rows where `data-verified="true"`; set that flag upon real manager verification.  
4. Migration: none (field already correct).  
5. Verify by saving unverified row ⇒ reload ⇒ remains editable; run regression tests.  
6. Rollback by redeploying previous JS bundle if unexpected side‑effects appear.
```

**Expected Output**

```
Root Cause
<script_name> incorrectly locks records based solely on the presence of a manager identifier.

Problem Flow
1. A user enters a manager identifier in a record.  
2. The client‑side script detects a non‑empty manager field and disables editable controls.  
3. The UI displays a verified state while <db_table>.<verified_flag> remains false.  

Proper Fix Plan
1. Remove auto‑locking logic based on manager identifier in <script_name>.  
2. In the template, add `data-verified="{{ <record>.verified }}"` or equivalent.  
3. Client script: lock only rows where `data-verified="true"` and set that attribute after genuine verification.  
4. No database migration required; field semantics are correct.  
5. Test: save an unverified record → reload → record stays editable; execute regression suite.  
6. Rollback: redeploy previous client bundle if anomalies occur.
```

Use **this pattern** for every transformation.

### Instruction
Your task is to convert any **project‑specific documentation plan** into a **reusable generic template**.

You **MUST**

* Keep the **five mandatory sections** exactly named **Problem Description / Solution Overview / Implementation Details / Technical Flow / Testing Guide**.
* Replace concrete identifiers (file paths, endpoints, table names, variable names, colors, etc.) with angle‑bracket placeholders such as `<file_path>`, `<endpoint>`, `<table>`, `<flag>`.
* Maintain the numbering and bullet hierarchy **exactly** as provided.
* Use concise, imperative sentences.
* End the document with the line **`Save as <doc_name>.md in the project root.`**
* After the template, output a short, human‑readable confirmation paragraph that begins with **"I've created a comprehensive documentation file that outlines:"** followed by a bulleted summary of the five sections.
* Answer a question given in a natural, human‑like manner.
* Ensure your answer is unbiased and avoids relying on stereotypes.

You **WILL BE PENALIZED** if you:

* Remove or rename any of the five sections.
* Leave project‑specific identifiers intact.
* Omit the final confirmation paragraph.
* Change list numbering or bullet style.

---

### Example

**Input (excerpt)**

```
Problem Description
- Components showed as verified without actual verification  

Solution Overview
- Backend changes (new endpoint, preservation logic)  
```

**Expected Output**

```
Problem Description
- Certain records appeared in a verified state without genuine verification.  
- Summary of root cause analysis identifying <root_cause>.

Solution Overview
- Backend adjustments (e.g., <new_endpoint>, state‑preservation logic).  
- Front‑end updates (API integration, new data attributes).  
- Relevant database schema elements (<table>, <flag>).

Implementation Details
- Files modified: <file_path>:<line_range>, <file_path>:<line_range>.  
- Explanation of each code change and its necessity.

Technical Flow
- End‑to‑end verification sequence.  
- Data propagation from UI through service layer to <table>.  
- Mechanism for persisting verification status across sessions.

Testing Guide
- Steps to confirm the fix functions as intended.  
- Expected UI and database states after each test case.  
- Queries/scripts for validating data in <table>.

Save as <doc_name>.md in the project root.

I've created a comprehensive documentation file that outlines:  
  1. The Problem — why unverified records looked verified  
  2. The Solution — backend endpoint, front‑end attributes, and schema usage  
  3. All File Changes — paths and ranges where code was updated  
  4. Technical Details — exact lines, snippets, and rationales  
  5. Complete Flow — end‑to‑end data movement from UI to database and back
```

---

### Example prompt

Transform the following project‑specific documentation plan into a generic template using the rules above:
```
<insert documentation plan here>
```