Hiro development journal

A modular personal task and reading-list architecture for Hiro

2026.07.26 at 11:20:51 America/Los_Angeles Published Machine-readable JSON

Executive summary

A work email task-manager design was reviewed as the basis for a personal system organized by areas of life such as Hiro, self-care, and family.

The recommended design keeps the original system's strongest trust boundary: machine-generated suggestions and human edits remain separate, so re-analysis cannot overwrite a person's decisions.

The personal version should not make email the central data model. Tasks and reading items should be durable first-class records, while Gmail, manual entry, and future Hiro conversations plug in through independent source adapters.

Hiro already has the key foundations for a no-new-cost first version: a local SQLite-backed service, a mobile-accessible FastAPI surface, read-only Gmail OAuth support, and local Qwen inference. GPT API use can remain optional and disabled for routine classification.

Hiro was switched to the official Qwen3.5 9B Q4_K_M runtime as a lower-heat default. The prior 35B-A3B profile remains available as a reversible fallback.

The agreed first release is now implemented as a standalone productivity module: durable task and reading records, a responsive web interface, read-only Gmail label ingestion, provenance-aware date extraction, and optional local Qwen 9B tag classification.

Work completed

Reference design review

Completed

Reviewed the supplied inbox-to-task-board design, including conversation-level grouping, incremental analysis, schema-constrained model output, manual overrides, completion watermarks, and a grouped dashboard.
Identified the separate machine and user columns as the most important pattern to retain.
Identified normalized email subject lines as too weak for a durable personal task identity because unrelated messages can share a subject and subject text can change.

Fit with Hiro's current architecture

Completed

Inspected Hiro's current architecture and confirmed that the existing application already uses FastAPI, SQLite, a browser UI, mobile access through the private network, deterministic resolvers, Gmail OAuth, and a local Qwen model profile.
Confirmed that Hiro's current Gmail tool returns metadata and short sanitized previews rather than full bodies or complete threads. That is sufficient for search but not yet sufficient for reliable task extraction or article URL ingestion.
Confirmed that Hiro already treats actionable to-do and reading lists as planned product capabilities, including provenance and user review.

Proposed module boundaries

Completed

Recommended a standalone productivity module with its own data access layer, service API, and UI route instead of embedding task logic in Hiro's chat loop.
Recommended source adapters for manual entry, Gmail, and future Hiro-created suggestions; enrichment providers for deterministic rules, the local model, and an optional paid model; and presentation adapters for the web dashboard, mobile access, and a future ChatGPT app.
Recommended first-class records for areas, tasks, reading items, source references, user overrides, and an append-only event history. The source reference preserves the exact Gmail message or Hiro interaction that created an item.

AI and cost strategy

Completed

Recommended deterministic extraction and sender or label rules first, followed by Hiro's existing local Qwen model for ambiguous classification.
Recommended that GPT API processing remain an explicit optional fallback with a hard budget, not a dependency of ingestion or display.
Documented that a ChatGPT subscription and API billing are separate. Interactive ChatGPT access can help inspect Gmail or manage the system through a future app, but it does not provide a free model endpoint for Hiro's unattended local pipeline.

Reading-list workflow

Completed

Recommended a dedicated Gmail label or self-mail convention as the low-friction capture mechanism.
Recommended storing article URL, title, source message reference, capture time, reading state, notes, and optional task linkage in Hiro's database.
Recommended Hiro's existing private mobile web access as the first remote interface. Direct Gmail access from ChatGPT can provide conversational retrieval immediately, while a future authenticated custom ChatGPT app can expose Hiro's durable task and reading-list API.

Initial product behavior decisions

Completed

Separated subject tags from planning horizons. The initial horizons are current for zero to one month, medium-term for one to three months, long-term for three to six months, and someday for more than six months.
Reframed the workflow labels in plain language: Review for unapproved imports, Open for actionable work, Waiting for blocked work, Scheduled for work intentionally deferred to a date, and Done for completed work.
Specified that source dates should be extracted when present, with the source evidence, confidence, and any relative-date interpretation retained separately from a user override.
Selected dedicated Gmail task and reading labels, the existing private mobile web path, and a first release containing manual tasks, Gmail-derived tasks, and reading items. Recurring tasks and reminders remain planned follow-up capabilities.
Selected Review as the initial gate for Gmail-derived tasks, with a configurable future path for direct import after observed accuracy is trustworthy.
Selected an indefinitely retained Done section with an undo action that restores the task's prior state.
Selected multi-value tags so one item can belong to several subjects. Initial tags are Hiro, self-care, family, projects, music, TV, other, AI, and Active for exercise-related items.
Confirmed that Gmail ingestion will use Hiro's existing local Google OAuth integration and Gmail API access, while routine classification will use Hiro's locally hosted Qwen model rather than a paid GPT API.

Thermal constraint and temporary model review

Completed

Inspected the checked-in launcher, model router, installed local model inventory, and current GPU configuration after the user reported computer heat concerns.
Confirmed that the current Qwen3.6 35B-A3B Q4_K_M file is about 20.75 GiB and is fully GPU-offloaded by the launcher on a 32 GiB GPU whose configured power limit is 575 watts.
Confirmed that the available Qwen3.5-27B Q4_K_M file is about 17.98 GB, so it would save only about 2.8 GB of model-weight memory.
Identified the important architecture difference: the current 35B-A3B model activates about 3B parameters per token, while the 27B model is dense. The nominally smaller model may therefore use more computation and produce more heat during generation.
Confirmed that a 9B Q4_K_M Qwen-family model is already installed locally and is a more credible low-heat temporary profile than downloading the dense 27B model.

Low-heat Qwen3.5 9B runtime switch

Completed

Rejected the initially installed 9B candidate after a real warm-up showed that the experimental base-model edit ignored a READY-only instruction and returned unrelated code. It was not adopted as Hiro's runtime.
Downloaded and indexed the official Qwen3.5 9B Q4_K_M text model. The completed weights are about 5.24 GiB, roughly one quarter of the prior 35B-A3B Q4_K_M weight file.
Added a dedicated Qwen 9B PowerShell launcher and background entry point. The launcher pins the LM Studio CLI, exact model identity, 8,192-token context, one parallel slot, maximum GPU offload, exact-content warm-up, and startup metadata.
Normalized the process-scoped Windows search path before all child-process starts and added a hidden LM Studio startup path, preserving the inherited environment required by Hiro's runtimes.
Added the qwen9 router profile and made it the default for fast and standard local routing, health recovery, nightly API preflight, documentation, and model-registry restoration. The qwen36 profile and launcher remain intact for rollback.
Capped the ordinary expanded Qwen 9B completion budget at 1,024 tokens and request non-reasoning mode for routine calls to reduce unnecessary generation. Explicit short budgets remain explicit.
The first official-model cold start became ready in 8.531 seconds and returned exactly READY in a 1.731-second warm-up. An idempotent rerun became ready in 0.852 seconds and repeated the exact READY result in 1.807 seconds.

Personal task and reading-list implementation

Completed

Added an isolated SQLite schema for tasks, reading items, source provenance, many-to-many tags, soft deletion, and append-only audit events. The module is independent of Hiro's conversational agent and can later be exposed through narrow internal tools.
Implemented Review, Open, Waiting, Scheduled, and Done task states; Current, Medium-term, Long-term, and Someday horizons; priorities; source-backed due-date evidence and confidence; a separate Done section; and completion undo that restores the prior state.
Implemented a responsive /tasks interface linked from Hiro's existing navigation. It supports task and article creation and editing, search, horizon and tag filtering, custom tags, multi-tag selection, reading-state progression, explicit removal, Gmail imports, and mobile breakpoints.
Extended Gmail ingestion through Hiro's existing read-only Google OAuth path. Dedicated Hiro/Tasks and Hiro/Reading labels are read without modifying Gmail; imported items enter Review, stable Gmail message identifiers prevent duplicate imports, and article URLs are filtered from full message content.
Implemented deterministic due-date extraction for exact and relative dates, retaining the source phrase and confidence. Deterministic keyword tagging runs first; only ambiguous items can invoke the active local Qwen model, with constrained JSON validation and no paid GPT API dependency.
Added the productivity migration to the normal database initializer and mounted the module router and dashboard in the existing FastAPI application.

Decisions and reasoning

Use a task-centered domain model rather than an email-centered clone.
Keep machine proposals and human overrides separate, and add an append-only event history for auditability.
Treat tasks and reading items as related but distinct record types; a reading item can later be promoted to a task without losing its source.
Use stable provider identifiers for Gmail messages and threads when available; do not rely on normalized subjects as the primary identity.
Make local inference the default AI path and make GPT API escalation optional, budgeted, and nonessential.
Keep the productivity module independent of Hiro's conversational agent, then integrate through a narrow internal API and explicit tool methods.
Start remote access with the existing private mobile web path. Consider a custom ChatGPT app only after the local workflow and authorization model are stable.
Model multi-value subject tags and a single planning horizon as independent fields.
Use current for zero to one month, medium-term for one to three months, long-term for three to six months, and someday for more than six months.
Extract due dates only when supported by the source. Preserve exact dates directly; resolve relative dates against the source timestamp and time zone while marking them as inferred.
Use Review, Open, Waiting, Scheduled, and Done as plain-language states. Manual tasks may enter Open immediately.
Send Gmail-derived tasks through Review initially, then permit direct import as a configurable later mode after accuracy has been measured.
Use dedicated Gmail task and reading labels for initial capture.
Retain task and reading records indefinitely unless the user explicitly deletes them. Display Done in a separate section and allow completion to be undone.
Keep Gmail as the authoritative complete message store while retaining extracted fields, source identifiers, and useful evidence with the task. Fetch the complete original message when more context is requested.
Use Hiro's local Gmail OAuth and Gmail API adapter for ingestion; do not depend on the ChatGPT Gmail app for the unattended pipeline.
Keep the productivity module independent of a specific local model so runtime profiles can be changed without altering task data or ingestion logic.
Do not assume Qwen3.5-27B will reduce heat merely because its weight file is smaller; it is dense while the current Qwen3.6 35B-A3B activates only about 3B parameters per token.
Prefer the already-installed 9B Qwen-family model as the immediate low-heat runtime candidate, or reduce the GPU power target after explicit approval. Keep paid GPT API fallback disabled by default.
Use many-to-many tags with initial values Hiro, self-care, family, projects, music, TV, other, AI, and Active for exercise-related items.
Defer recurring-task generation and reminders while keeping both in the planned roadmap.
Use the official Qwen3.5 9B Q4_K_M model for Hiro's temporary low-heat profile; do not use the installed experimental base-model edit that failed instruction-following validation.
Keep qwen9 as the default profile while retaining qwen36 and its launcher unchanged as the reversible higher-capability option.
Use a 1,024-token ordinary local completion budget for Qwen 9B and disable optional reasoning on routine requests; preserve explicitly requested shorter limits.
Use a separate productivity SQLite schema and service boundary now, with Gmail and future Hiro integrations as adapters rather than dependencies.
Make Gmail ingestion read-only and label-scoped; leave messages, labels, and read state unchanged.
Run deterministic classification first and use the active local Qwen 9B model only for ambiguous tags. Do not call a paid GPT API in the first release.
Use soft deletion for explicit removal and immutable audit events for the retained change history.

Validation and evidence

Check	Status	Result
Reference document review	passed	The supplied design was read in full and its data, ingestion, analysis, dashboard, and scheduling patterns were evaluated.
Hiro architecture inspection	passed	The existing repository's architecture, model routing, FastAPI/static UI setup, Gmail tool boundaries, and stated product direction were inspected.
Implementation tests	passed	48 targeted pytest checks passed across the Qwen 9B and retained Qwen 35B launchers, nightly preflight, profile-aware output budgets and payloads, ordered reasoning, health routing, authentication, and operational boundaries.
Journal test and frontend production build	passed	npm run test:hiro passed. npm run build generated and validated 41 journal entries, then completed the TypeScript and Vite production build.
Real Qwen3.5 9B child-process startup	passed	The pinned launcher started LM Studio child processes after Path normalization, loaded model identity qwen3.5-9b at 8,192 context with one parallel slot, and required an exact READY response.
Live endpoint and instruction behavior	passed	The OpenAI-compatible endpoint reported qwen3.5-9b, the loaded-process inventory showed only that model instance, and a 512-token arithmetic request returned the requested number 4.
Thermal and power snapshot	passed	After the targeted test and warm-up sequence, the GPU reported 43 degrees Celsius, about 91 watts, 12.9 GB of allocated GPU memory, and 11 percent utilization. A separate active-inference sample reached 44 degrees Celsius and about 235 watts; no controlled 35B comparison was run.
Productivity storage, Gmail adapter, and API tests	passed	Eight focused pytest checks passed. Coverage included schema seeding, multi-value tags, provenance, due-date evidence and horizons, append-only lifecycle events, soft deletion, reading items, review-first Gmail imports, Gmail idempotence, task completion undo, and real FastAPI task and reading round trips.
Interactive browser workflow	passed	The live /tasks page created a high-priority medium-term task with Hiro, AI, and Projects tags; moved it to Done; restored it with Undo done; and created a tagged reading item. Final browser console inspection reported no warnings or errors.
Responsive phone layout	passed	At a 390 by 844 viewport the toolbar switched to its mobile column layout, cards collapsed to one column, and the document reported no horizontal overflow.
Updated journal test and production build	passed	After the productivity implementation update, npm run test:hiro passed. The generator validated 41 timestamped journal entries and their aliases, sitemap, Atom content, noindex metadata, and IndexNow key; TypeScript and the Vite production build then completed successfully.

Current state

Hiro already has local model inference and an optional paid fallback, so a first version does not require a new model subscription.
The current mobile surface can be reached through the existing private network path; a direct ChatGPT-to-Hiro connection is a later integration.
Hiro's active local profile is qwen9, served by the official Qwen3.5 9B Q4_K_M model on the existing local endpoint.
The Qwen3.6 35B-A3B files, profile, launcher, and tests remain available for a deliberate future rollback or capability comparison.
LM Studio continued downloading an optional projection support artifact after the completed text weights were indexed; Hiro's text-only runtime does not depend on that optional artifact.
The personal task and reading-list first release is implemented locally and available from Hiro's Tasks navigation at /tasks.
The durable module supports manual tasks, reading items, Gmail review imports, multi-value subject tags, planning horizons, source-backed due dates, an indefinitely retained Done section, completion undo, custom tags, filtering, and explicit soft removal.
Gmail ingestion uses the existing read-only local OAuth integration and dedicated labels. It retrieves complete labeled messages for extraction but does not alter the mailbox.
Routine classification does not require a paid model endpoint: deterministic rules run first and the active local Qwen 9B service is an optional ambiguity fallback.

Next steps

If a model profile changes, add a pinned launcher, identity-aware warm-up, real child-process startup test, and a small representative quality comparison before making it the default.
Keep review mode enabled initially and introduce configurable direct import only after measured precision is acceptable.
Add recurring tasks and reminders after the core task and reading workflows are stable.
Add optional Hiro chat tools and, later, a narrowly scoped ChatGPT app after the core system is trustworthy.
Run a small representative Hiro task-quality and sustained-load comparison before deciding whether the 9B profile should remain permanent.
Keep the 35B profile available but avoid returning to it during the current thermal constraint unless the 9B model fails a concrete capability requirement.
Connect the user's Gmail OAuth credentials if not already present, create the Hiro/Tasks and Hiro/Reading labels, and evaluate a small private sample in Review mode.
Iterate on extraction and tagging from reviewed imports, then decide whether measured accuracy supports an opt-in direct-import mode.
Add recurring tasks and reminders after the daily manual and Gmail workflows have been used enough to establish the desired behavior.
Add narrowly scoped Hiro chat tools for listing and changing productivity records when the standalone workflow is stable.