[AZ-172] Update documentation for distributed architecture, add Update Docs step to workflow

- Update module docs: main, inference, ai_config, loader_http_client
- Add new module doc: media_hash
- Update component docs: inference_pipeline, api
- Update system-flows (F2, F3) and data_parameters
- Add Task Mode to document skill for incremental doc updates
- Insert Step 11 (Update Docs) in existing-code flow, renumber 11-13 to 12-14

Made-with: Cursor

.cursor/skills/document/SKILL.md

@@ -51,9 +51,12 @@ Determine the execution mode before any other logic:
 | **Full** | No input file, no existing state | Entire codebase |
 | **Focus Area** | User provides a directory path (e.g., `@src/api/`) | Only the specified subtree + transitive dependencies |
 | **Resume** | `state.json` exists in DOCUMENT_DIR | Continue from last checkpoint |
+| **Task** | User provides a task spec file (e.g., `@_docs/02_tasks/done/AZ-173_*.md`) AND `_docs/02_document/` has existing docs | Targeted update of docs affected by the task |
 
 Focus Area mode produces module + component docs for the targeted area only. It can be run repeatedly for different areas — each run appends to the existing module and component docs without overwriting other areas.
 
+Task mode is a lightweight, incremental update — it reads the task spec to identify which files changed, then updates only the affected module docs, component docs, system flows, and data parameters. It does NOT redo discovery, verification, or problem extraction. See **Task Mode Workflow** below.
+
 ## Prerequisite Checks
 
 1. If `_docs/` already exists and contains files AND mode is **Full**, ASK user: **overwrite, merge, or write to `_docs_generated/` instead?**
@@ -387,6 +390,88 @@ Using `.cursor/skills/plan/templates/final-report.md` as structure:
 
 ---
 
+## Task Mode Workflow
+
+Triggered when a task spec file is provided as input AND `_docs/02_document/` already contains module/component docs.
+
+**Accepts**: one or more task spec files (from `_docs/02_tasks/todo/` or `_docs/02_tasks/done/`).
+
+### Task Step 0: Scope Analysis
+
+1. Read each task spec — extract the "Files Modified" or "Scope / Included" section to identify which source files were changed
+2. Map changed source files to existing module docs in `DOCUMENT_DIR/modules/`
+3. Map affected modules to their parent components in `DOCUMENT_DIR/components/`
+4. Identify which higher-level docs might be affected (system-flows, data_model, data_parameters)
+
+**Output**: a list of docs to update, organized by level:
+- Module docs (direct matches)
+- Component docs (parents of affected modules)
+- System-level docs (only if the task changed API endpoints, data models, or external integrations)
+- Problem-level docs (only if the task changed input parameters, acceptance criteria, or restrictions)
+
+### Task Step 1: Module Doc Updates
+
+For each affected module:
+
+1. Read the current source file
+2. Read the existing module doc
+3. Diff the module doc against current code — identify:
+   - New functions/methods/classes not in the doc
+   - Removed functions/methods/classes still in the doc
+   - Changed signatures or behavior
+   - New/removed dependencies
+   - New/removed external integrations
+4. Update the module doc in-place, preserving the existing structure and style
+5. If a module is entirely new (no existing doc), create a new module doc following the standard template
+
+### Task Step 2: Component Doc Updates
+
+For each affected component:
+
+1. Read all module docs belonging to this component (including freshly updated ones)
+2. Read the existing component doc
+3. Update internal interfaces, dependency graphs, implementation details, and caveats sections
+4. Do NOT change the component's purpose, pattern, or high-level overview unless the task fundamentally changed it
+
+### Task Step 3: System-Level Doc Updates (conditional)
+
+Only if the task changed API endpoints, system flows, data models, or external integrations:
+
+1. Update `system-flows.md` — modify affected flow diagrams and data flow tables
+2. Update `data_model.md` — if entities changed
+3. Update `architecture.md` — only if new external integrations or architectural patterns were added
+
+### Task Step 4: Problem-Level Doc Updates (conditional)
+
+Only if the task changed API input parameters, configuration, or acceptance criteria:
+
+1. Update `_docs/00_problem/input_data/data_parameters.md`
+2. Update `_docs/00_problem/acceptance_criteria.md` — if new testable criteria emerged
+
+### Task Step 5: Summary
+
+Present a summary of all docs updated:
+
+```
+══════════════════════════════════════
+ DOCUMENTATION UPDATE COMPLETE
+══════════════════════════════════════
+ Task(s): [task IDs]
+ Module docs updated: [count]
+ Component docs updated: [count]
+ System-level docs updated: [list or "none"]
+ Problem-level docs updated: [list or "none"]
+══════════════════════════════════════
+```
+
+### Task Mode Principles
+
+- **Minimal changes**: only update what the task actually changed. Do not rewrite unaffected sections.
+- **Preserve style**: match the existing doc's structure, tone, and level of detail.
+- **Verify against code**: for every entity added or changed in a doc, confirm it exists in the current source.
+- **New modules**: if the task introduced an entirely new source file, create a new module doc from the standard template.
+- **Dead references**: if the task removed code, remove the corresponding doc entries. Do not keep stale references.
+
 ## Artifact Management
 
 ### Directory Structure