Workflow

LifeHub Inbox

Inbox lifecycle and intake-control rules.

Open Markdown View Browse Workspace

Generated from canonical Markdown. Markdown controls.

Section 01

Purpose

The inbox is the intake-control layer for LifeHub.

Section 02

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.

Section 03

Filename Convention

Use this format for new inbox items:

Section 04

Lifecycle

Inbox items move through this simple lifecycle:

new
reviewed
in process
blocked

Section 05

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.

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.

Section 06

Validation Boundary

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

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

Section 07

Boundaries

Inbox items should remain markdown files.

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.

Section 08

Audience and Runtime Boundary

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

Section 09

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.

Section 10

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

Section 11

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.

Section 12

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.

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