daily-focus 1.2.0-dev.9 → 2.0.0-dev.15

package/dist/{service-ZUHI3VKH.js → service-LQ46YRCZ.js}

@@ -1,6 +1,7 @@
 import {
+  LAUNCH_SETTINGS,
   loadConfig
-} from "./chunk-KZNY45XW.js";
+} from "./chunk-72NUDSOV.js";
 import {
   IN_NPX_CACHE,
   PACKAGED,
@@ -30,9 +31,9 @@ function servicePath(path, nodeDir) {
 }
 function serviceEnvironment(env, nodeDir) {
   const kept2 = { PATH: servicePath(env.PATH ?? "", nodeDir) };
-  for (const key of Object.keys(env).sort()) {
-    const value = env[key];
-    if (key.startsWith("DAILY_FOCUS_") && value !== void 0) kept2[key] = value;
+  for (const key of LAUNCH_SETTINGS) {
+    const value = env[key]?.trim();
+    if (value) kept2[key] = value;
   }
   return kept2;
 }
@@ -180,9 +181,9 @@ async function main(args) {
     if (found.dataDir === config.dataDir) {
       bad(`this dashboard is already running at ${url}${by}`, "stop the one started by hand, then run this again");
     } else if (found.dataDir) {
-      bad(`port ${config.port} is taken by the dashboard for ${tilde(found.dataDir)}${by}`, "give one of them its own DAILY_FOCUS_PORT");
+      bad(`port ${config.port} is taken by the dashboard for ${tilde(found.dataDir)}${by}`, "give one of them its own --port");
     } else {
-      bad(`port ${config.port} is taken by something else${by}`, "set DAILY_FOCUS_PORT to a free one");
+      bad(`port ${config.port} is taken by something else${by}`, "give it a free one with --port");
     }
     console.log();
     return 1;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "daily-focus",
-  "version": "1.2.0-dev.9",
+  "version": "2.0.0-dev.15",
   "description": "An interactive dashboard of what you should focus on today at work",
   "keywords": [
     "dashboard",
@@ -28,6 +28,7 @@
     "public/index.html",
     "public/style.css",
     "public/app.js",
+    "public/fonts/",
     "prompts/",
     "schema/",
     "tools/dfcal/build.sh",
@@ -40,7 +41,7 @@
   },
   "daily-focus": {
     "appInterface": 1,
-    "appSource": "288797ddc9f77355cc5ec176f1f21452d49fd3ae"
+    "appSource": "a55e34e63517a3bb93c1352c48df2c6417f021d8"
   },
   "scripts": {
     "start": "node src/server.ts",
@@ -66,5 +67,8 @@
     "happy-dom": "20.14.5",
     "preact": "10.29.8",
     "typescript": "7.0.2"
+  },
+  "allowScripts": {
+    "esbuild": true
   }
 }

package/prompts/README.md

@@ -5,12 +5,13 @@
 | [`morning-brief-work.md`](./morning-brief-work.md) | The prompt for the work briefing agent, run once every workday morning. |
 | [`morning-brief-personal.md`](./morning-brief-personal.md) | The prompt for the personal briefing agent: email, family calendars, Apple Reminders, Apple Messages, e-Boks and the user's own GitHub projects. |
 | [`assistant.md`](./assistant.md) | The instructions for the on-demand assistant, which the server runs headless when the user presses Ask on a row. One file for both profiles. Linked into the store as `assistant.md`. |
+| [`onboarding.md`](./onboarding.md) | The instructions for the setup screen's CLI sessions, one per question, which propose the answer a new user most likely wants. Not linked into the store: the server reads it from the running copy and inlines it, as it does the assistant's. |
 
-All three are **nothing but prompt** — each is read verbatim by its agent, so anything
+All four are **nothing but prompt** — each is read verbatim by its agent, so anything
 else in there is either noise the agent has to skip or, worse, an instruction it
 might try to act on. Notes about the prompts belong in this file instead.
 
-The assistant's file differs from the other two in one way: the server does read it.
+The assistant's file differs from the briefing prompts in one way: the server does read it.
 It is the server that starts the assistant, so it is the server that inlines these
 instructions ahead of the row and the request on the first turn of a session. The
 quick actions the panel offers are sentences in `src/assistant.ts`, not in the
@@ -32,14 +33,16 @@ alongside `items.schema.json`, so a run only ever names a path inside the store:
 ~/.daily-focus/
   prompt.md           → prompts/morning-brief-work.md   (symlink, made by the dashboard at start)
   items.schema.json   → schema/items.schema.json   (symlink, made by the dashboard at start)
-  focus.md            you write it, in the dashboard or by hand
-  sources.md          you write it, in the dashboard or by hand
+  focus.md            you write it, on the setup screen, in the dashboard or by hand
+  sources.md          you write it, on the setup screen, in the dashboard or by hand
   settings.json       the dashboard writes: what you set on its settings page
+  agent-settings.json the dashboard writes before every run: the settings the agent reads
   items.json          the agent writes it
   actions.jsonl       the dashboard appends
   agent.jsonl         the dashboard appends: every run, its report, and the questions asked of it
   archive/            the dashboard writes
   prs.json            the dashboard writes: its last fetch of the user's open pull requests
+  onboarding.json     the dashboard writes: the setup screen's answers, and what was proposed for them
 ```
 
 That boundary is the point, and it is worth being strict about. A prompt that reaches
@@ -69,6 +72,19 @@ it. Nothing else is handed over: no extra instructions, no checkout, no copy of
 prompt. Everything that evolves lives in the prompt, in git, where a change to it is
 reviewable, and the wrapper should never need editing.
 
+A setting that changes how the agent gathers, such as searching deleted mail, reaches
+it the same way everything else does: through the store. Before each run the dashboard
+writes `agent-settings.json` with the values it is running with, as saved on the
+settings page, and both prompts say what each key means.
+The wrapper stays the same whatever the settings are.
+
+The prompt has the agent hand the reading of its sources to subagents, which share
+its working directory and what its CLI allows it, so the prompt also tells it to
+tell them that they only read. The judging and the writing stay with the agent. The
+run's panel shows each subagent under the step that started it: Claude Code reports
+them in its output, and for Codex the dashboard reads Codex's own session files
+(`src/codexsessions.ts`).
+
 Which days it runs is `DAILY_FOCUS_AGENT_DAYS` — cron-numbered, so `1-5` is Mon–Fri
 and `0-4` is the Sun–Thu week — and Mon–Fri when unset. The same schedule drives the
 staleness banner, which turns red once the brief is more than 24 *working* hours old,

package/prompts/assistant.md

@@ -42,7 +42,13 @@ status comment on a ticket, a message. The user posts it, not you.
 ## How to answer
 
 Lead with the answer. If the question was "is this review right", the first line says
-whether it is. Then the evidence, as short as it can be. Use Markdown: short
+whether it is. Then the evidence, as short as it can be.
+
+Make the first line the verdict, on a line of its own, in under fifteen words: "Two
+of Alice's three comments are right; the cap is a judgment call." or "Flaky, not
+yours: the Safari job timed out on a step this change doesn't touch." The dashboard
+may ask you a quick action on its own, before the user has looked, and shows that
+line alone on the item's row. The rest is read only by someone who opens the panel. Use Markdown: short
 paragraphs, a list where there are parallel points, a code block for anything meant
 to be pasted. No headings; the panel is narrow.
 

package/prompts/morning-brief-personal.md

@@ -24,6 +24,10 @@ not for you.
   gather and how to judge it; that file says *who* and *where*.
 - `items.schema.json` — **you only ever read this.** The machine-readable shape of
   `items.json`. Validate against it in step 5 if you can.
+- `agent-settings.json` — **you only ever read this.** The choices the user made on
+  the dashboard's settings page about how you gather, rewritten by the dashboard
+  before every run. Each key is explained where it applies below; a missing file or
+  key means that key's default.
 - `prs.json` — **you only ever read this.** The dashboard's own cache of the pull
   requests the user has open, refreshed while the dashboard is in use. Facts only —
   reviews, checks, who last acted — with no judgement attached; use it if it helps,
@@ -100,6 +104,33 @@ Otherwise, each source's window starts three days before the previous brief's
 
 ### Step 2 — Gather
 
+#### Hand the reading to subagents
+
+Read the sources in parallel rather than one after another: hand each source to a
+subagent of its own, or a few small ones to one subagent, so the slowest source sets
+the pace rather than the sum of them. Run up to three at a time, starting the next as
+one finishes. The reading is all you hand out. Step 1, the judging in step 3, the
+writing in step 4 and the checks in step 5 stay with you, because they need
+everything in one place.
+
+A subagent may not see this file, so give it what it needs in its task: its source's
+section of this step in full, with the value of any setting from `agent-settings.json`
+that the section names; the rules under "Across every source" below; the window from
+step 1; and the ids from the previous brief that came from its source and are still
+open, so it looks at each again. Name each after its source — `calendar`, `email`, `eboks` — since
+the dashboard shows the user which is which while you work.
+
+Ask for evidence, not decisions. For each thing that might be an item: its upstream id
+or key, its link, who and what it is about, its dates, and what the source shows about
+whether it is still open. Then what it could not read, why, and the link. Merging
+duplicates, ranking and wording are yours. When an answer is missing something its
+source should have had, ask again or read it yourself.
+
+A subagent only reads, and tell it so: it writes no file, `items.json` least of all,
+and changes nothing in any source.
+
+If you cannot start subagents, read the sources yourself, one after another.
+
 #### Across every source
 
 **Use a connector, API, MCP server or CLI as the evidence source.** `sources.md` says
@@ -148,6 +179,12 @@ and anything filters moved out of the inbox, included. Mail the user filed is no
 mail they finished with. **Do not limit the search to unread mail**: the things that
 rot are the ones the user opened, meant to deal with, and didn't.
 
+Mail the user deleted is mail they finished with, so leave Trash out unless
+`searchTrash` in `agent-settings.json` is `true` (default `false`). A search with no
+`in:` operator already covers archived mail and skips Trash and Spam; when the
+setting is off, don't widen it with `in:anywhere` or a trash option. When it is on,
+search Trash as well, and still never Spam.
+
 **On a first run, search the last 90 days.** The point of that run is to find what
 fell through the cracks: a reply the user owes, a bill, a form, a booking to confirm,
 a promise they made in a thread. Afterwards, use the normal window from step 1.

package/prompts/morning-brief-work.md

@@ -22,6 +22,10 @@ not for you.
   how to judge it; that file says *who* and *where*.
 - `items.schema.json` — **you only ever read this.** The machine-readable shape of
   `items.json`. Validate against it in step 5 if you can.
+- `agent-settings.json` — **you only ever read this.** The choices the user made on
+  the dashboard's settings page about how you gather, rewritten by the dashboard
+  before every run. Each key is explained where it applies below; a missing file or
+  key means that key's default.
 
 There is also an `archive/` directory of dated past briefs. The dashboard maintains
 it; you never write to it. Read it if you want history — it is how the dashboard
@@ -107,6 +111,33 @@ a recent query alone make unfinished work disappear.
 
 ### Step 2 — Gather
 
+#### Hand the reading to subagents
+
+Read the sources in parallel rather than one after another: hand each source to a
+subagent of its own, or a few small ones to one subagent, so the slowest source sets
+the pace rather than the sum of them. Run up to three at a time, starting the next as
+one finishes. The reading is all you hand out. Step 1, the judging in step 3, the
+writing in step 4 and the checks in step 5 stay with you, because they need
+everything in one place.
+
+A subagent may not see this file, so give it what it needs in its task: its source's
+section of this step in full, with the value of any setting from `agent-settings.json`
+that the section names; the rules under "Across every source" below; the window from
+step 1; and the ids from the previous brief that came from its source and are still
+open, so it looks at each again. Name each after its source — `calendar`, `gmail`, `github` — since
+the dashboard shows the user which is which while you work.
+
+Ask for evidence, not decisions. For each thing that might be an item: its upstream id
+or key, its link, who and what it is about, its dates, and what the source shows about
+whether it is still open. Then what it could not read, why, and the link. Merging
+duplicates, ranking and wording are yours. When an answer is missing something its
+source should have had, ask again or read it yourself.
+
+A subagent only reads, and tell it so: it writes no file, `items.json` least of all,
+and changes nothing in any source.
+
+If you cannot start subagents, read the sources yourself, one after another.
+
 #### Across every source
 
 **Use a connector, API or CLI as the evidence source.** A browser may only help you
@@ -167,6 +198,12 @@ the user's filters moved out of the inbox, included. Mail they filed is not mail
 finished with, and a label records how they sorted something, not whether they dealt
 with it.
 
+Mail the user deleted is mail they finished with, so leave Trash out unless
+`searchTrash` in `agent-settings.json` is `true` (default `false`). A search with no
+`in:` operator already covers archived mail and skips Trash and Spam; when the
+setting is off, don't widen it with `in:anywhere` or a trash option. When it is on,
+search Trash as well, and still never Spam.
+
 Prioritise direct requests, deadlines, decisions, travel and logistics,
 finance/legal/security, and anyone plausibly waiting on a reply. **Do not limit
 continuity-sensitive searches to unread mail** — the things that rot are usually the

package/prompts/onboarding.md

@@ -0,0 +1,41 @@
+# Setting up Daily Focus
+
+You are helping someone set up Daily Focus, a dashboard that has a coding-agent CLI
+write them a short brief each morning: what needs to get done today, from their
+mail, calendar, pull requests, tickets and documents.
+
+They are on the setup screen now. It asks them one question at a time, and each
+question comes with the answer they most likely want already ticked, so most of
+the time all they do is confirm. Your job in this session is that one question,
+named below: find out enough to propose the answer, and say why in a sentence.
+
+## How to work
+
+- **Only read.** Never send, post, create, edit, move or delete anything,
+  anywhere: no mail, no drafts, no calendar changes, no comments, no files.
+- **Be quick.** Someone is waiting on this. A few well-chosen lookups, then
+  answer. If something would take long to find out, make the likely guess and
+  say it is a guess.
+- **Nobody can answer you mid-turn.** Never ask a question; the screen does the
+  asking. If a tool or account isn't reachable, work with what is and say what
+  you couldn't check.
+- **Guess well.** A question for the *work* profile wants work accounts,
+  calendars and projects; for *personal*, everything else. Lean towards what the
+  morning brief needs and away from noise.
+- **Say why in one or two short sentences**, under 40 words, in the first
+  person and plain text, no Markdown: "These are on your northwind.dev account,
+  where most of this week's meetings are." Cite what you saw, never invent it.
+  Say what you guessed, but not every lookup that failed. Never quote private
+  content such as mail subjects or meeting titles; counts and account names are
+  fine.
+- **Answer with the JSON the schema asks for**, and nothing else. Use an empty
+  string, not null, for anything unknown.
+- **Your why describes the answer you give, and nothing more.** The screen
+  shows the two side by side. Never say you included something the answer
+  doesn't hold; if the user asks for something it has no place for, say so.
+
+## When the user writes back
+
+They may tell you what to change ("also the on-call rota", "that's my old
+address"). Do what they ask, check what you need to, and answer with the whole
+proposal again, in the same JSON.