Canonical Markdown Copy
LifeHub Workflow
WORKFLOW.md
This is an in-site display copy generated from the repository Markdown so the reader site can show both sides of the pair. The repository Markdown file remains canonical.
Display CopyThis page is generated for reading and comparison.
Canonical FileThe repository Markdown file still controls meaning.
Reader PairUse the polished reader page for comfortable review.
# LifeHub Workflow
<!-- lifehub-reader-view-link -->
> **Reader View:** [Open the generated HTML reader view](LifeHub/07_outputs/reader_site/pages/WORKFLOW.html). Markdown remains the canonical source of truth.
LifeHub uses a staged workflow so work becomes clearer, more structured, and more actionable over time.
## Core Rule
Files are the source of truth, not chat.
Important logic, decisions, and outputs should be written into the workspace so they remain reviewable, editable, and portable.
The operational workspace folders referenced below live under `LifeHub/` at repository root.
## Stage Progression
Work should generally move through this sequence:
`raw -> structuring -> extraction -> deduplication -> synthesis -> assets -> specs -> app -> outputs`
This is a preferred progression, not a rigid one-way pipeline.
- Iteration between stages is expected.
- Later stages may reveal the need to revisit earlier ones.
- Active project containers may hold partially developed work across multiple stage files at the same time.
## Stage Meaning
### 1. Raw
Capture source material such as ideas, notes, chats, research, references, and observations.
### 2. Structuring
Organize the material so it is labeled, grouped, and easier to work with.
### 3. Extraction
Pull out the non-trivial insights, useful facts, and meaningful observations from the structured material.
### 4. Deduplication
Merge repeated ideas, preserve unique insight, and flag contradictions or conflicts.
### 5. Synthesis
Turn the clarified material into coherent models, frameworks, or structured understanding.
### 6. Assets
Convert the models into practical tools such as SOPs, checklists, policies, templates, and operating documents.
### 7. Specs
Define workflows, data structures, dashboard requirements, interfaces, and software behavior before implementation.
### 8. App
Build software only after the relevant structure and specification are clear enough to implement.
For project-owned implementation, create the full `05_apps/` scaffold at project setup time when the project already has, or is expected to have, an app, software, automation, dashboard, or script stage.
### 9. Outputs
Collect final reports, exports, deliverables, reviews, and other artifacts intended for use, handoff, or evaluation.
## Reviewability Rule
- Intermediate outputs must remain reviewable.
- Intermediate outputs must remain editable.
- Stage transitions should not hide, flatten, or compress important information that may need to be checked later.
## Placement Rule
- Put raw and early material in `LifeHub/01_inbox` or the early stages of a project.
- Put reusable system methods in `LifeHub/03_systems`.
- Put reusable operational tools in `LifeHub/04_assets`.
- Put requirements and definitions in `LifeHub/05_specs`.
- Put shared or cross-project implementation work in `LifeHub/06_apps`.
- Put project-owned implementation work in the project's structured `05_apps/` workspace, not in a flat catch-all folder.
- Put reviewed final artifacts in `LifeHub/07_outputs`.
## Project App Workspace Rule
- `04_specs/` defines the intended system.
- `05_apps/` implements the system.
- `06_outputs/` stores shipped, reviewable, or exported results.
- If a project is expected to include app, software, automation, script, or dashboard work, initialize `05_apps/` from `LifeHub/03_systems/App_Development_Template/` immediately.
## Practical Aim
The purpose of the workflow is not bureaucracy. The purpose is clarity, continuity, and staged refinement so valuable work is easier to understand, improve, reuse, and implement.