# 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.