generated from eblume/project-template
Erich Blume
00da36c637
All checks were successful
Build / validate (pull_request) Successful in 6m18s
Document why heph's op-based sync lets most new features (new link types, read-side queries, optional payload fields) ship without a coordinated migration across the hub and spokes, and the narrow case — a new required SQLite column the apply path writes — that does need a hub-first rollout. Groundwork for the indented/counted project sidebar, which is pure read-side (existing parent links + a GROUP BY) and needs no migration. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
15 lines
514 B
Markdown
15 lines
514 B
Markdown
---
|
||
title: Explanation
|
||
modified: 2026-03-03
|
||
tags:
|
||
- explanation
|
||
- meta
|
||
---
|
||
|
||
# Explanation
|
||
|
||
Background context and design decisions.
|
||
|
||
- [[design]] — Hephaestus design document: vision, data model, architecture, sync, and roadmap
|
||
- [[task-lifecycle]] — the two-axis task model (lifecycle state × attention), drop vs delete, and where each task shows up
|
||
- [[hub-spoke-data-evolution]] — why op-based sync lets most new features skip migrations, and when a coordinated SQLite migration is actually required
|