dreamweaver/docs

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.