daily-focus 1.2.0-dev.5 → 1.2.0-dev.8

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

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

package/package.json

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

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/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