# 800-documentation-tracking.md

## PROGRESS TRACKER STANDARDS

Whenever an agent (e.g., bug-fixer, bug-inspector, pr-reviewer, etc.) is required to update a progress tracker document (like `docs/refactoring/code-quality-security/progress-tracker.md`), the following strict formatting rules **MUST** be adhered to:

### 1. Table Consistency
*   Agents must **NEVER** append rows to the end of the markdown file blindly.
*   Agents must locate the existing markdown table inside `3. Progress Log` (or the equivalent table section) and insert the new row at the **bottom of the table**, precisely before the table ends or the next markdown heading begins.

### 2. ID Formatting
*   The `ID` column in the table must be a **sequential 2-digit integer** (e.g., `37`, `38`, `39`). 
*   **NEVER** use arbitary alphanumeric IDs like `SEC-004` or `BUG-123` unless strictly continuing a table that explicitly uses that exact format entirely. Look at the preceding row's ID and increment by 1.

### 3. Column Structure
*   The standard column structure for progress trackers is:
    `| ID | Phase | Task / Bug | Status | Notes |`
*   Ensure the inserted row exactly matches this structure, including correct spacing and pipe `|` characters for markdown table parsing.

### 4. Status Column
*   Always use `✅ Done` for completed items.
*   Always use `⏳ Pending` or `🔄 In Progress` for incomplete items.
*   Do not invent new emoji markers without precedent in the file.

### Example Valid Row Insertion:
```markdown
| 37 | **Fix** | **Missing Work Order Title** | ✅ Done | Included workorder eager loading for manufacturing. |
```

### PROHIBITED BEHAVIORS
*   **PROHIBITED:** Injecting rows using simple string appending (`cat << EOF >> file.md`) without verifying if the insertion point is inside the markdown table.
*   **PROHIBITED:** Breaking markdown table formatting by omitting pipes (`|`) or columns.
*   **PROHIBITED:** Changing the ID pattern established in the existing document.
