v1 reached Todoist feature-parity, so remaining/future work is now tracked
in heph itself — tasks in the Hephaestus project (heph view ondeck) — not in
a doc. Renamed docs/reference/tech-spec.md -> v1-prototype-tech-spec.md and
rewrote all 27 [[tech-spec]] wiki-links + README/changelog path refs (docs
checks green). Retitled + bannered the spec as a historical v1 build record
and froze its §14 tracker. AGENTS.md gains a "Planning future work" section
(capture via `heph task --project Hephaestus`, triage in heph-tui On Deck);
README status reflects parity + the three daily-driver surfaces. The design
doc remains the living rationale.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- tech-spec §8.2 (new): filter-views slice — extend `list` to a data-expressed
predicate (attention set, project-subtree/multi scope, exclude-projects,
actionable toggle), five built-in views (`heph view <name>`) seeded from the
owner's verbatim Todoist queries; the TUI's filter pane reuses them
- tech-spec §8.1: TUI filter pane = the §8.2 views; depends on that slice
- tech-spec §14: filter-views is the next slice (before heph-tui); CLI +
daemon-service marked done
- design §6.2.1: record the verbatim filter queries + the reference-context →
wiki reclassification, and note future direction: chores as a first-class
feature (own do-date/recurrence; retire Chores/Camano-Chores projects) and
dropping the Schedule filter (time-of-day not modeled)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A surface-owned, auto-spawned daemon can't be shared once the CLI is also a
first-class client — so drop auto-spawn and manage the daemon as an OS service.
- design §4: daemon lifecycle = explicit OS service; surfaces connect-only
- heph-nvim.md: rewrite the daemon-lifecycle section (connect-only) + history
- new how-to/run-the-daemon.md (heph daemon start/stop/restart/status); indexed
- install-heph.md: post-install is `heph daemon start`; plugin no longer spawns
- tech-spec §14: mark the managed-daemon entry superseded
- changelog fragment
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Study of the owner's live Todoist (387 tasks, 34 hierarchical projects)
grounds a surface-strategy revision: structured task fields suit CLI flags,
large-set triage suits an interactive TUI, and context/KB suits nvim — so v1
adopts three surfaces, each to its strength. Supersedes the earlier
"heph.nvim is the primary surface" framing.
- design.md: new §6.2.1 (Todoist study) + revised §4 (three-surface model)
- tech-spec §1/§8: reframe surface roles; new §8.1 (planned heph-tui agenda)
- tech-spec §14: reorder remaining work (CLI-complete task surface in progress,
heph-tui next, nvim navigation polish, tags/hierarchy deferred)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Record what's built and the resume order for the next context session:
heph-core + hephd local mode + CLI/export + local query surface + the
sync engine (HLC, op-log, converging merge/conflict-queue) are done;
resume at yrs body-CRDT → network sync → OIDC auth → heph.nvim.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Resolve the open tensions surfaced in the pre-Phase-1 second pass over
design.md and tech-spec.md:
- Context items: Fork A index model — body markdown is the source of
truth; context items are a locally-derived, non-synced index;
identity is pinned at promotion. Dissolves the body-CRDT vs.
extraction convergence problem.
- Recurrence: roll-forward in place; drop task_occurrences and
is_template; advance to next RRULE instance after now (skip misses).
- Identity: deterministic ids for journal/tag (offline-convergent);
ULID for content nodes and project.
- Mode/sync: orthogonal hub_url spoke capability; everyday device is
local + hub_url, not server.
- Auth/owner: nullable oidc_sub, friction-free local user, hub-
authoritative identity, one-time pre-first-sync adoption rewrite.
- Ranking: do_date is a boolean candidacy filter only; late_on is the
sole urgency signal (global tier); FIFO tiebreak; order expressed as
a reorderable named-dimension list.
- Modes are plugin-side compositions; add list() and log.tail().
- Frame v1 as a single deliberate C1; misc cleanups (export, health,
CI nvim runner, README license).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace "distributed from day one" with a targetable Store backend that
supports the full spectrum from local-only to distributed by configuration:
- Store trait with LocalStore (direct SQLite, exclusive lock) and
RemoteStore (RPC to a server)
- three hephd runtime modes: local / server / client
- exclusive-lock handoff so the same SQLite file can pass between local and
server mode; client mode is thin and online-only
- offline remains a property of local-backed replicas syncing via the hub
Local-only is now a first-class configuration. Build order starts at local
mode. Updates docs/reference/tech-spec.md (§1, §3.1, §11) and
docs/explanation/design.md (§9, §11) to match.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Customize the generated repo (rename Dagger module to hephaestus_ci /
HephaestusCi, set docs baseUrl, add All-Rights-Reserved LICENSE, update
README/AGENTS), and add the project's foundational design documentation:
- docs/explanation/design.md — rationale + decision-history record
- docs/reference/tech-spec.md — implementation-ready technical spec
These define hephaestus as a self-hosted, client/server + offline-first
system unifying a markdown knowledge base with task management: typed node
graph, the lived priority discipline ("what is next?"), recurrence with
fresh-per-occurrence checklists, op-log/CRDT sync with conflict resolution,
OIDC/Authentik auth, the heph.nvim surface, and a TDD strategy.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
