docs: sync workflow progress and weekend handoff

docs/README.md

@@ -0,0 +1,166 @@
+# Documentation Index
+
+This repository now uses a simple documentation taxonomy so you can quickly tell:
+
+- what is current and actionable
+- what is product-facing vs. technical
+- what is historical and should not be treated as source of truth
+
+---
+
+## Folder Structure
+
+### `docs/product/`
+
+Current product documents. These are the best starting point when you want to understand:
+
+- product positioning
+- MVP scope
+- feature requirements
+- portfolio/presentation story
+
+Files:
+
+- `job-search-relaunch-prd.md`
+  Status: Active
+  Type: Product strategy / reboot PRD
+  Use when: you want the current product direction and prioritization.
+
+- `unified-generation-workflow-prd.md`
+  Status: Active
+  Type: Feature-level PRD
+  Use when: you want the target design for the core generation workflow.
+
+### `docs/planning/`
+
+Execution-oriented documents. These are for sprint planning, backlog breakdown, and short-term delivery.
+
+Files:
+
+- `document-status-inventory.md`
+  Status: Active
+  Type: Documentation audit / implementation mapping
+  Use when: you want to know which docs are current, which capabilities are really implemented, and where coding should restart.
+
+- `week-1-execution-backlog.md`
+  Status: Active
+  Type: Sprint / execution planning
+  Use when: you want to know what to do first and how to break work into tasks.
+
+- `weekend-handoff-2026-04-17.md`
+  Status: Active
+  Type: Progress handoff / execution snapshot
+  Use when: you want to continue work from another machine without reconstructing the latest checkpoint from chat history.
+
+### `docs/technical/`
+
+Technical reference documents. These are implementation-oriented and may include design guidance or development notes.
+
+Files:
+
+- `memory-system-dev.md`
+  Status: Reference
+  Type: Technical design / development guide
+  Use when: you work on the memory system or want to study one style of technical design note.
+  Note: parts of this document are forward-looking and should be validated against the current codebase before implementation.
+
+### `docs/operations/`
+
+Runbooks and environment/operations documentation.
+
+Files:
+
+- `ha-runbook.md`
+  Status: Reference
+  Type: Operations runbook
+  Use when: you work on Docker-based HA deployment, Redis Sentinel, PostgreSQL replication, or backup verification.
+
+### `docs/archive/`
+
+Historical documents. Keep these for learning or project history, but do not treat them as the current source of truth.
+
+Files:
+
+- `provider-system-legacy.md`
+  Status: Archived
+  Type: Historical technical plan
+  Why archived: partially outdated; references earlier provider architecture and older app entry naming.
+
+- `refactoring-plan-legacy.md`
+  Status: Archived
+  Type: Historical implementation plan
+  Why archived: reflects an earlier refactor phase; some items are completed, some are no longer current priorities.
+
+- `stories-split-analysis-legacy.md`
+  Status: Archived
+  Type: Historical code analysis
+  Why archived: tied to a past `stories.py` split effort and no longer represents the current structure.
+
+---
+
+## Deleted Document
+
+The following document was removed instead of archived:
+
+- `backend/docs/code_review_report.md`
+  Reason: it was a one-off review artifact, not a durable project document, and its main issue was already resolved by the later `0002_add_api_key_to_providers.py` migration.
+
+---
+
+## Recommended Reading Order
+
+If you want to understand the project as a product manager:
+
+1. `docs/product/job-search-relaunch-prd.md`
+2. `docs/product/unified-generation-workflow-prd.md`
+3. `docs/planning/document-status-inventory.md`
+4. `docs/planning/week-1-execution-backlog.md`
+5. `docs/planning/weekend-handoff-2026-04-17.md`
+6. `docs/technical/memory-system-dev.md`
+7. `docs/operations/ha-runbook.md`
+
+If you want to understand the project as an engineer:
+
+1. `docs/planning/document-status-inventory.md`
+2. `docs/product/unified-generation-workflow-prd.md`
+3. `docs/technical/memory-system-dev.md`
+4. `docs/operations/ha-runbook.md`
+5. `docs/archive/*` only when you need historical context
+
+---
+
+## Documentation Rules Going Forward
+
+When adding a new document, place it using these rules:
+
+- Put it in `docs/product/` if it explains what should be built and why.
+- Put it in `docs/planning/` if it explains when or in what order work should happen.
+- Put it in `docs/technical/` if it explains how something works or should be implemented.
+- Put it in `docs/operations/` if it is about deployment, environments, runbooks, or maintenance.
+- Put it in `docs/archive/` if it is historically useful but no longer current.
+
+Delete a document only when all three are true:
+
+- it is a one-off artifact
+- it is not a reusable reference
+- its key information is either obsolete or already captured elsewhere
+
+Archive instead of deleting when:
+
+- the document shows project history
+- the document may still help future debugging or learning
+- you are not fully sure whether it is still valuable
+
+---
+
+## PM Learning Note
+
+A good documentation system helps you think clearly:
+
+- `product` tells you what problem you are solving
+- `planning` tells you what to do next
+- `technical` tells you how the system works
+- `operations` tells you how to run it
+- `archive` tells you what used to be true
+
+That separation is useful not only for this repo, but also as a general PM habit. Many product documents become confusing because they mix all five at once.