# LifeHub Inbox


<!-- lifehub-reader-view-link -->
> **Reader View:** [Open the generated HTML reader view](../07_outputs/reader_site/pages/LifeHub/01_inbox/README.html). Markdown remains the canonical source of truth.

## Purpose

The inbox is the intake-control layer for LifeHub.

## Audience and Runtime Boundary

This is an AI-facing-only inbox lifecycle and source-processing guide. It does not need human-oriented accommodations.

Read `CONTEXT.md` first when executing inbox work; it is the lean route/loading entry surface. After routing, use this `README.md` as the canonical authority for inbox lifecycle, source preservation, movement, completion, and validation rules.

Use it for captured ideas, AI handoffs, research fragments, mobile notes, source material, and other incoming information that has not yet been fully processed or routed.

The inbox is not a replacement for the full LifeHub workflow. Once an item begins producing durable outputs, those outputs should be routed to the proper project, system, asset, spec, app, or output folder. The inbox item remains as a traceable source or handoff record.

## Folder Structure

- `00_templates` stores reusable inbox templates.
- `01_new` stores newly captured material that has not yet been reviewed.
- `02_in_process` stores reviewed items with active processing, routing, extraction, synthesis, or output work underway.
- `03_completed` stores processed inbox items after useful information has been extracted, routed, or converted into outputs.
- `04_archive` stores obsolete, duplicate, intentionally parked, or no-longer-actionable inbox items.

## Filename Convention

Use this format for new inbox items:

`YYYY-MM-DD_short-topic-title.md`

Example:

`2026-04-24_fishflo-distribution-handoff.md`

Keep filenames short, readable, and specific enough to identify the source material.

## Lifecycle

Inbox items move through this simple lifecycle:

`new -> in process -> completed -> archive`

Use these status values:

- `new`
- `reviewed`
- `in process`
- `blocked`
- `completed`
- `archive`

Use these current_stage values:

- `intake`
- `structuring`
- `extraction`
- `deduplication`
- `synthesis`
- `asset creation`
- `spec creation`
- `app development`
- `output review`
- `validation`
- `completed`

## Single-Location Rule

- An inbox item must exist in only one lifecycle folder at a time.
- Do not copy inbox items between folders.
- Movement between lifecycle stages must be done by moving the file, not duplicating it.

## Movement Rules

Move a file from `01_new` to `02_in_process` when it has been reviewed and has a concrete next action.
Before moving an item to `02_in_process`, it must have a defined `next_action` and a basic `related_domain` or `related_project`.
This does not require perfect clarity, but it must not remain undefined.

Initial phased-planning requirement for build-oriented intake:

- If an inbox item is expected to lead to implementation work (apps, specs, SOPs, automation, or systems changes), define an explicit phased plan before deeper execution.
- The phased plan should be lightweight but concrete (for example: intake lock -> extraction -> deduplication -> synthesis -> requirements freeze -> implementation planning).
- Record the phased plan in the controlling inbox item (or directly linked downstream control file) before app/spec implementation begins.
- Treat this phased plan as part of the control record so continuity and handoff remain clear.

HITL gate question-and-answer limits for decision phases:

- Use gate packets to unblock decisions, not to over-model edge cases before operations are live.
- Default packet size: 3-5 decisions. Hard cap: 8 decisions per packet.
- If the operator asks for one-at-a-time mode (for voice/headset workflows), ask one question per turn and include a recommendation before the user answers.
- Keep one-at-a-time packets short: target 5 decisions, hard stop at 8. Then record outcomes and pause for execution or data collection.
- For unresolved details, set provisional defaults with explicit review triggers (for example: after 100 transactions or 30 days), instead of drilling indefinitely.
- Required record update after each packet: decisions made, provisional flags, owners, deadlines/review triggers, and next gate action.
- For simple items, the outline and decisions synthesis may stay embedded in the controlling record or packet notes. For moderate or complex items, create standalone Outline Discovery and Decisions documents so the workflow stays bounded and auditable.

Move a file from `02_in_process` to `03_completed` when:

- requested outputs have been created or routed
- required indexes or navigation files have been updated
- useful information has been extracted and unique insights preserved
- open questions have been answered, deferred, parked, or converted into explicit next actions
- required validation is complete or clearly not required
- a completion record has been added to the bottom of the inbox item
- `INBOX_INDEX.md` matches the final folder, status, current stage, and next action

Move a file from any folder to `04_archive` when it is obsolete, duplicated, irrelevant, intentionally parked, or no longer worth active processing.


## Validation Boundary

Use `current_stage: validation` when implementation outputs already exist but completion still depends on real-world proof.

Typical validation dependencies include:

- phone or mobile-browser testing
- device-specific testing
- account-permission or environment-access checks
- user/operator action outside the repository
- external-environment verification

If these checks remain open, do not mark the item completed. Keep `status: in process`, set `current_stage: validation`, and write the exact validation next action.

## Completion Criteria

An inbox item is complete when:

- requested outputs have been created or routed
- required indexes or navigation files are updated
- useful information has been extracted and unique insights preserved
- open questions are answered, deferred, parked, or converted into explicit next actions
- required validation is complete or clearly not required
- the completion record has been added
- `INBOX_INDEX.md` agrees with final folder, status, current stage, and next action

Completed does not mean forgotten. Completed means processed, routed, and closed for standard action.

## Relationship to Taskmaster and task-state surfaces

Use `LifeHub/08_admin/03_operator/TASK_AUTHORITY_MODEL.md` when Inbox, Taskmaster, active state, backlog, pull requests, GitHub Issues, or future Agent Bus state could be confused.

- Inbox preserves and processes source/control records.
- `INBOX_INDEX.md` is the Inbox lifecycle and pressure index, not the system backlog.
- Taskmaster is a dispatcher and task-intake procedure, not a separate task database.
- Active State is a thin current-focus summary.
- Development Backlog is the system-wide next-work surface when priorities are unclear.
- GitHub Issues are noncanonical unless Yesh explicitly authorizes a narrow external or interim transport use.

## Inbox Drift Validation

`INBOX_INDEX.md` is a source-derived navigation projection. Individual item metadata remains authoritative for status, stage, next action, and update date.

After any lifecycle-file creation, move, status change, stage change, next-action change, or update-date change:

1. Run `python3 LifeHub/04_assets/operator_continuity/sync-inbox-index.py --root . --write`.
2. Run the same command without `--write` to prove exact synchronization.
3. From `LifeHub/01_inbox`, run `powershell -File "check-inbox-consistency.ps1"`.

The PowerShell wrapper forwards to the canonical validator at `LifeHub/04_assets/operator_continuity/check-inbox-consistency.ps1`. Zero missing, duplicate, stale, or mismatched rows is required; there is no accepted drift baseline.

## Boundaries

Inbox items should remain markdown files.

Non-markdown source artifacts (for example `.html`, `.pdf`, `.docx`, media files) may be captured during intake, but they should follow this lifecycle:

- Capture stage: keep them in `05_raw_captures` while intake is still unprocessed.
- Processing stage: reference them from the controlling inbox markdown item.
- Promotion stage: move or copy the canonical source into the owning destination (project/system/spec) once ownership is clear.
- Inbox closeout: remove duplicate copies from inbox staging locations after promotion is complete.

`01_new` should be used for markdown inbox items, not as a resting place for non-markdown source files.

Use `LifeHub/04_assets/operator_continuity/RAW_CAPTURE_PROMOTION_CHECKLIST.md` when promoting non-markdown captures from intake to durable ownership surfaces.

Inbox items should not become the final home for long-term assets, specs, models, or implementation work. Durable outputs belong in the appropriate LifeHub destination folder.