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

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

@@ -1,6 +1,6 @@
 import {
   loadConfig
-} from "./chunk-NWYOCDUU.js";
+} from "./chunk-J7ZYVUG6.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.10",
   "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

@@ -37,7 +37,6 @@ alongside `items.schema.json`, so a run only ever names a path inside the store:
   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
@@ -93,8 +92,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