daily-focus 1.2.0-dev.10 → 1.2.0-dev.12

package/dist/{service-PUJ3YDH5.js → service-RRHZ7BJN.js}

@@ -1,6 +1,6 @@
 import {
   loadConfig
-} from "./chunk-J7ZYVUG6.js";
+} from "./chunk-DPMHC72S.js";
 import {
   IN_NPX_CACHE,
   PACKAGED,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "daily-focus",
-  "version": "1.2.0-dev.10",
+  "version": "1.2.0-dev.12",
   "description": "An interactive dashboard of what you should focus on today at work",
   "keywords": [
     "dashboard",

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,12 @@ 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, whether they were
+saved on the settings page or set in `.env`, and both prompts say what each key means.
+The wrapper stays the same whatever the settings are.
+
 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/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,
@@ -148,6 +152,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
@@ -167,6 +171,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.