Nodeger

Planning multi-day work forces you across three apps and re-entering the same data in each. A calendar tracks dates, a task tracker tracks ownership, a timer tracks effort — and none of them talk. Standard tools also lock every task into an identical box, so scope, dependencies, and who-owns-what never show on one screen.

One screen shows the entire status of a multi-day project — scope, progress, owner, and dependencies — with no app-switching. Each task is a node you drag, resize, and connect on a 30-day grid. Nodes span multiple days, carry live timers, and link with bezier lines; color tags assign owners at a glance. Node height signals scope, timer state signals progress, lines signal dependencies.

An event bus keeps every feature fully decoupled, so any part can be replaced or tested in isolation. The calendar and node systems never import each other — they talk only through typed events like canvas:click and node:move, with state in per-feature Zustand stores. A virtual renderer draws only on-screen nodes (plus a 20% buffer), built to hold 200+ nodes at a 60fps target. Four performance modes trade visual effects for speed on demand; work auto-saves to the browser on a short debounce.

Adding a new node type means writing a config object, not a new component. Task, Description, and Backdrop nodes all render from a single master component driven by a type definition. Consolidating to this pattern removed 1,200+ lines of duplicate code and cut duplication from ~20% to under 5%.

Every tradeoff and known weakness is documented in the repo — written by Danylo, not a reviewer. The README names the exact gaps: a large node store to split, console logs to strip, and 0% test coverage, alongside a dated refactoring roadmap. Each feature folder ships an AI modification guide marking what is safe to change. This is a prototype built for fast iteration, with the debt accounted for rather than hidden.