Daeseon Yoo
Back to project
·Decision·3 min

Decision — drop activity heatmap from v1 scope

Activity heatmap (calendar grid colored by entry kind) was in the v1 plan but dropped after evaluation. Status header carries the bulk of the portfolio signal; heatmap is self-reflection tooling that does not need to be public-surface.

Context

v1 plan included a 13th criterion: an activity heatmap on /projects/<slug> showing calendar-style density colored by entry kind. After completing the status header and judgment-kind counts, the user asked specifically why the heatmap is needed.

Options considered

A. Public heatmap on /projects/<slug> (original v1 plan)

B. Admin-only heatmap on /admin/heatmap

C. Skip entirely (chosen)

D. Different temporal view (timeline strip with kind markers)

Chosen + Why

C — skip entirely.

The recruiter-facing portfolio signal is judgment artifact density, not commit frequency. Status header already shows N decisions · M discussions · K learning-gaps which is the actual differentiator. A heatmap adds visual chrome but no new signal.

For self-reflection (when did I crank, when did I burn out), the user said it was not a primary use case. Heatmap as admin-only tool (option B) is defensible but mid-priority compared to forming the .human.mdx annotation habit and writing first real Tier-1 decision entries.

Trade-off accepted

Reversibility

two-way. The underlying log data already supports the visualization. Adding a heatmap later is a pure UI task with no schema or data-layer dependencies.

Verified by

Decision criteria to flip (when to add it back)

Commit

This entry is the artifact. The decision is content, not code — no implementation change accompanies it.