daily-focus 1.1.1-dev.3 → 1.2.0-dev.11

package/dist/{service-63U4WBUH.js → service-XPFMYIHR.js}

@@ -1,6 +1,6 @@
 import {
   loadConfig
-} from "./chunk-NWYOCDUU.js";
+} from "./chunk-4DZEBUPU.js";
 import {
   IN_NPX_CACHE,
   PACKAGED,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "daily-focus",
-  "version": "1.1.1-dev.3",
+  "version": "1.2.0-dev.11",
   "description": "An interactive dashboard of what you should focus on today at work",
   "keywords": [
     "dashboard",
@@ -40,7 +40,7 @@
   },
   "daily-focus": {
     "appInterface": 1,
-    "appSource": "0f59ad2ffabffbfd1054778996c4ee337199c92c"
+    "appSource": "288797ddc9f77355cc5ec176f1f21452d49fd3ae"
   },
   "scripts": {
     "start": "node src/server.ts",

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,15 +33,15 @@ 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
   items.json          the agent writes it
   actions.jsonl       the dashboard appends
-  sessions.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
@@ -93,8 +94,8 @@ works inside the store. Coding agents can read the implementation and tests, so
 | `~/.daily-focus/sources.md` | Which calendars, account and recurring documents are yours. Not in this repo, for the same reason: it's the half of the brief that names real things. |
 
 When code changes what the briefing agent must produce or understand, update the
-prompt too. The tests check field names, required fields, enum values, and session
-end reasons. Review changes to judgement rules directly.
+prompt too. The tests check field names, required fields and enum values. Review
+changes to judgement rules directly.
 
 ## Why the personal specifics live outside the repo
 

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.
 
@@ -51,7 +57,12 @@ thread the Gmail tool did not find — say so plainly at the top, and answer as
 the rest allows. A confident answer built on half the material is worse than a
 shorter one that says what it is missing.
 
-Give the URL of anything you created, so it can be opened from the panel.
+End with one line for each thing you created, in exactly this form, so the panel
+can offer it as a button:
+
+```
+Created: [Gmail draft](https://mail.google.com/mail/u/0/#drafts?compose=…)
+```
 
 ## Stay in this chat
 
@@ -59,4 +70,4 @@ This conversation is the whole record of what you did. Do not leave notes on the
 item, do not write to the dashboard's files, and do not try to mark the item done,
 snoozed or handled: the user does that from the dashboard once they have read your
 reply. If you created or changed something — a draft, most often — say so in the
-reply, with its URL, and stop there.
+reply, end with its `Created:` line, and stop there.

package/prompts/morning-brief-personal.md

@@ -16,8 +16,6 @@ not for you.
 - `focus.md` — **you only ever read this.** The standing personal objective, written
   by hand. It decides what "important" means. It may be missing or have a blank
   `objective`; both are normal.
-- `sessions.jsonl` — **you only ever read this.** One line per focus session: what
-  they actually spent time on, as opposed to what they finished.
 - `sources.md` — **you only ever read this.** The personal specifics this prompt
   deliberately doesn't carry: who the user is, which calendars to query, which email
   account, which reminder lists, how to reach Messages and e-Boks, which GitHub login
@@ -73,6 +71,7 @@ by `id` and take the **last** entry for each id:
 | `snooze` | Not today | Leave it out until `until` (a `YYYY-MM-DD`) has arrived. If `until` is absent, use your judgement about when it's worth resurfacing. |
 | `reopen` | They undid a previous action | Treat as though nothing had been recorded — it is live again. |
 | `note` | Free text for you; **does not** change status | Read it. It usually explains *why*, and often tells you something the sources can't. |
+| `nudge` | The user asked a pull request's reviewers for a review, somewhere you can't see (Slack, in person); **does not** change status | Treat the review as asked for at `at`. Don't suggest asking again until a day after it. |
 
 **This is the most important instruction in this prompt.** A `done` in the log
 outranks everything you can observe upstream. If the log says the user handled an
@@ -81,29 +80,6 @@ unread, even if the sender is still sending reminders. They may have replied by
 phone, in person, or in another channel. Absence of upstream evidence is not evidence
 of inaction. Never re-derive a completed item from source state.
 
-**Read `sessions.jsonl`.** It records what the user worked on, which `actions.jsonl`
-cannot tell you. Use it:
-
-- Time spent on something unfinished is progress. Don't re-raise it tomorrow in
-  identical words as though the day never happened; acknowledge it in `detail`.
-- The same item across several days with no completion means stuck. Say so plainly,
-  and consider whether the item is too big or the real blocker is elsewhere.
-- An item the user has never once started, while finishing things around it, is being
-  avoided. Name it gently, once — not every day.
-
-`actualMinutes` is real elapsed time rather than the plan, and `endedBy` says how far
-to trust it:
-
-| `endedBy` | How it ended | What the number is worth |
-|---|---|---|
-| `user` | They pressed Stop. | Exact. |
-| `away` | The machine sat untouched, so the dashboard closed the session back at the last keypress. | Honest to within a minute. The break is already excluded — don't subtract for it twice. |
-| `limit` | It outran a two-hour ceiling on a machine that couldn't say whether anyone was there. | An upper bound, not a measurement. **Never cite it as a long focused stretch.** |
-
-A session that ended `away` was interrupted, not abandoned. `endedBy` is absent on
-sessions recorded before it was tracked — treat those as `user`, but don't lean on the
-duration.
-
 **Read the previous `items.json`** and keep each surviving item's `firstSeen`. If an
 item you are raising today also appeared yesterday under the same `id`, carry its
 original `firstSeen` across verbatim. Only assign `firstSeen` = today to genuinely

package/prompts/morning-brief-work.md

@@ -15,8 +15,6 @@ not for you.
 - `focus.md` — **you only ever read this.** The standing objective, written by hand.
   It decides what "important" means. It may be missing or have a blank `objective`;
   both are normal.
-- `sessions.jsonl` — **you only ever read this.** One line per focus session: what
-  they actually spent time on, as opposed to what they finished.
 - `sources.md` — **you only ever read this.** The personal specifics this prompt
   deliberately doesn't carry: who the user is, which calendars to query, which
   accounts to judge review requests and authorship against, which recurring documents
@@ -36,11 +34,13 @@ knows how long it has been since the objective moved.
 - `tickets.json` — **you only ever read this.** The dashboard's own cache of the Jira
   tickets whose status doesn't match their pull requests, refreshed while the
   dashboard is in use. Facts only: each entry's `workflowStatus`, its
-  `statusCategory`, and whether Jira has any pull request for it (`hasAnyPr`) and any
-  still open (`hasOpenPr`). The dashboard shows this list on a tab of its own and the
-  user fixes the statuses there, **so do not copy it into the brief** — see the Jira
-  section of step 2. Use it if it helps, never write it, and never treat its absence
-  as meaning anything.
+  `statusCategory`, and whether it has any pull request (`hasAnyPr`) and any still
+  open (`hasOpenPr`). Those come from Jira, or from GitHub where Jira hasn't caught
+  up yet (`fromGitHub`, with the pull requests in `pulls`), so trust them over
+  Jira's own development panel. The dashboard shows this list on a tab of its own
+  and the user fixes the statuses there, **so do not copy it into the brief** — see
+  the Jira section of step 2. Use it if it helps, never write it, and never treat
+  its absence as meaning anything.
 
 Work through the five steps below in order. Do not start gathering before step 1 is
 done — what you find in step 1 changes what counts as worth raising.
@@ -84,6 +84,7 @@ by `id` and take the **last** entry for each id:
 | `snooze` | Not today | Leave it out until `until` (a `YYYY-MM-DD`) has arrived. If `until` is absent, use your judgement about when it's worth resurfacing. |
 | `reopen` | They undid a previous action | Treat as though nothing had been recorded — it is live again. |
 | `note` | Free text for you; **does not** change status | Read it. It usually explains *why*, and often tells you something the sources can't. |
+| `nudge` | The user asked a pull request's reviewers for a review, somewhere you can't see (Slack, in person); **does not** change status | Treat the review as asked for at `at`. Don't suggest asking again until a day after it. |
 
 **This is the most important instruction in this prompt.** A `done` in the log
 outranks everything you can observe upstream. If the log says the user handled a Gmail
@@ -92,32 +93,6 @@ unread, even if Workday is still sending reminders about it. They may have repli
 phone, in person, or in another channel. Absence of upstream evidence is not evidence
 of inaction. Never re-derive a completed item from source state.
 
-**Read `sessions.jsonl`.** It records what the user worked on, which `actions.jsonl`
-cannot tell you — a hard blocker can absorb days with nothing to mark done. Use it:
-
-- Time spent on something unfinished is progress. Don't re-raise it tomorrow in
-  identical words as though the day never happened; acknowledge it in `detail`.
-- The same item across several days with no completion means stuck. Say so plainly,
-  and consider whether the item is too big or the real blocker is elsewhere.
-- No sessions against the objective for days running is the loudest thing in the
-  store. Lead with it.
-- An item the user has never once started, while finishing things around it, is being
-  avoided. Name it gently, once — not every day.
-
-`actualMinutes` is real elapsed time rather than the plan, and `endedBy` says how far
-to trust it:
-
-| `endedBy` | How it ended | What the number is worth |
-|---|---|---|
-| `user` | They pressed Stop. | Exact. |
-| `away` | The machine sat untouched, so the dashboard closed the session back at the last keypress. | Honest to within a minute. The break is already excluded — don't subtract for it twice. |
-| `limit` | It outran a two-hour ceiling on a machine that couldn't say whether anyone was there. | An upper bound, not a measurement. **Never cite it as a long focused stretch.** |
-
-A session that ended `away` was interrupted, not abandoned: they left the desk, they
-didn't give up on the item. Don't read it as a false start. `endedBy` is absent on
-sessions recorded before it was tracked — treat those as `user`, but don't lean on the
-duration.
-
 **Read the previous `items.json`** and keep each surviving item's `firstSeen`. If an
 item you are raising today also appeared yesterday under the same `id`, carry its
 original `firstSeen` across verbatim. Only assign `firstSeen` = today to genuinely

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.