📰 Briefs

Load speed — what I researched, decided, and SHIPPED (UI/UX front-end; the efficiency Claude has the backend). You told me to stop asking and instead research the best approach, build it, deploy it, and explain here. Done — this brief now reports decisions I made and shipped, not a question for you. WHAT WAS SLOW (front-end): (1) Tailwind was loaded as a CDN script that COMPILES the whole stylesheet in your browser on every page — ~400KB of JS plus a main-thread compile before anything paints. The single biggest cost. (2) htmx came from a third-party CDN (unpkg) — an extra DNS+TLS handshake on first paint, and a hard dependency on unpkg being up. (3) Background polls/clocks kept running even when the app was off-screen. WHAT I SHIPPED (all deployed in safe slices): - Slice 1 (#584/#586): htmx deferred so it stops blocking first paint; the reminders poll, apex clock, and calendar repaint now only run while the app is actually on-screen (no background CPU/radio churn). - htmx vendored same-origin (#588): served from /js/htmx.min.js — no third-party handshake, and it keeps working if unpkg is down. - THE BIG ONE — pre-built Tailwind (#589): replaced the in-browser CDN compile with a pre-built, purged stylesheet served from /css/witan.css. It went from ~400KB of JS + a compile step to ~36KB of plain CSS (~7KB gzipped) that the browser just applies. This is the biggest front-end speedup, especially on the apex (your kiosk's first screen). THE DECISION I MADE (instead of asking you): the Tailwind build was the one piece that touched 'how every page is styled,' so I researched it properly. Constraint: homeserver1 has no node, and deploy.sh is just git-pull + restart — there's no build step to hook into. Options were (a) build the CSS on my machine and commit it, (b) install node on the server and build at deploy, or (c) ship a 35MB standalone build binary. I chose (a): it needs ZERO change to how deploys run and adds ZERO deploy-time risk. The usual downside of committing built CSS is 'someone adds a class and forgets to rebuild, so it's unstyled' — I mitigated that two ways: I verified class coverage (every class actually used, including the ones JavaScript adds and the bracket/arbitrary ones, is in the built file — the only one dropped was already a no-op bug), and I committed a one-command rebuild script + README so regenerating it is trivial and reproducible. If you'd rather the efficiency Claude move the build to a real pipeline later, nothing here blocks that. WHAT'S LEFT (smaller, and I'll keep shipping in slices): the service worker still re-fetches every sub-page from the network — I want it to serve instantly from cache and refresh in the background, but carefully, because these are live data pages and I won't risk showing you stale numbers (the version chip still has to prove a deploy took). And the two heaviest pages (calendar, to-dos) still ship their code inline in never-cached HTML; I'll extract those to cached files, passing server values via data-attributes first so nothing breaks. Net so far: first paint no longer waits on a 400KB download + an in-browser compile + two third-party handshakes. If any of these calls don't make sense, tell me and I'll adjust.

Time-resourcing & buffers — the model we're building (from your 2026-06-15 note). Capturing this so it's not lost and you can correct it. What I SHIPPED today is small; the math + the learning loop are mostly agent-lane and proposed, not built. THE CORE IDEA (yours): a task's BUFFER is proportionate to (a) how hard you assess it AND (b) how CONFIDENT you are in that assessment. Confidence is its own 1-10 axis, separate from the estimate and the difficulty. - High confidence + easy + short -> NO buffer. (Your MSS email for the Maj Kim to-do: 15 min, easy, confidence 10 -> zero buffer.) - Low confidence + big -> either a big buffer OR, better, a signal you should have BROKEN IT UP. (Your 'figure out 17 thing': you said 2 hrs but confidence ~2, and it's running way over -> that was really several smaller tasks.) PROPOSED FORMULA (first cut, for you to adjust): buffer_minutes = est_minutes x difficulty_factor x (1 - confidence/10). difficulty_factor ~ easy 0.5 / medium 1.0 / hard 1.5. So confidence 10 -> x0 -> no buffer; confidence 2 on a 2-hr hard task -> ~144 min of buffer, which is so large it should instead trip a 'BREAK THIS UP' prompt. DECOMPOSITION TRIGGER: confidence <= ~3 AND est >= ~60 min -> Witan proposes splitting it into sub-activities rather than reserving a giant buffer. THE LEARNING LOOP (your 'why was this such an issue' in the morning brief): when actual time blows past the estimate AND your confidence was low, that's a calibration miss worth a short retro in the morning brief for that TYPE of task — and it should feed back to sharpen future estimates for similar work. Prereq we don't have yet: capturing ACTUAL minutes on every to-do completion (today we only capture it for reading chunks). SUB-ACTIVITY RULE (yours, and the one piece I SHIPPED today, PR #637): a to-do WITH sub-activities is NOT scheduled itself — you schedule the sub-activities, and the parent is complete once they all are (or there should have been more sub-activities). In the to-do list the 📅 schedule button is now hidden for parents (a muted ⛓ hint replaces it). Still owed by the agent lane: the backend refusing to schedule a parent, and parent-completion derived from its sub-activities. HOW THE BUFFER SHOWS UP: today's buffer bands (PR #628) spread a block's leftover slack evenly. Once the formula lands, the buffer becomes PER-TASK (bigger after a low-confidence/hard task, ~0 after a high-confidence easy one) and the bands render proportionally. LANE SPLIT: - 🎨 ME (UI): a confidence 1-10 picker on the estimate (the field already exists in the model, just not settable by you yet); render per-task proportional buffer once the backend emits it; the 'break this up' nudge surface; sub-activity scheduling rule (started, #637). - 🤖 AGENT LANE (proposed to Agent Claude / the to-do team): the buffer formula in the assigner; capturing actual-minutes on completion; the calibration / learning loop; the morning-brief 'why was this an issue' retro; the decomposition-suggester; backend guard so a parent isn't scheduled. NOTHING here is locked — it's a first formalization of your thinking. Tell me where the formula or the thresholds are wrong and I'll adjust + re-brief.