@troylar/sightline 1.120.3 → 1.171.0

package/docs/assistant-workflow.md

@@ -9,9 +9,27 @@ or use Sightline's Send button for this route.
 The optional [company endpoint companion](#talk-to-your-company-endpoint) is an advanced alternative below.
 Check [build availability](availability.md) before using version-specific instructions.
 
+## Analyze with any assistant
+
+To ask questions about the plan, without changing it, any assistant will do: GitHub Copilot, ChatGPT, Claude,
+Gemini or your company's own. Open **Connect assistant** (in the menu under your name, top right, until an assistant is connected; then the assistant button in the toolbar), then **Analyze with any assistant** (since 1.130.0):
+
+- **Copy analysis instructions** copies read-only instructions that name each Sightline file, what it holds, who owns
+  which facts (Jira owns its issues, the team owns what it added) and how to read dates, estimates and coverage.
+  Paste them, then ask your question. Use this when the assistant can read your files.
+- **Copy instructions with data** adds the plan's data to the same paste: the file **Export for your assistant**
+  writes, with notes left out. Use this when the assistant can't read files, such as a chat window. It puts team
+  information on your clipboard, so paste it only into an assistant your team is allowed to use.
+- **Download AGENTS.md** saves the same instructions as a file. Put it in the folder with your plan and exported
+  files. Copilot in VS Code, Codex and other coding assistants read `AGENTS.md` from the folder you open, so you can
+  just ask. The file holds the plan's title and the rules, never the plan itself, so it's safe in a shared folder.
+
+For example: *"What's late or at risk, and why? Cite the ids."* or *"Who has the most work in the next sprint?"*
+The instructions are read-only. To have an assistant propose changes, use the private folder below.
+
 ## Use an external assistant
 
-Choose **Connect assistant** in the toolbar (or **Changes** when proposals are waiting), then choose **Connect your assistant**. In Edge or Chrome, select a private folder that your local assistant can read and write. Keep the team plan in OneDrive if needed. Use a separate private assistant folder for each person, device and plan, with one active Sightline tab writing to it. Sightline remembers the connection in this browser; a later visit may require **Reconnect**.
+Open the menu under your name (top right) and choose **Connect assistant**. Once an assistant is connected, the toolbar shows its state instead (**Assistant connected**, or **Changes** when proposals are waiting). Then choose **Connect your assistant**. In Edge or Chrome, select a private folder that your local assistant can read and write. Keep the team plan in OneDrive if needed. Use a separate private assistant folder for each person, device and plan, with one active Sightline tab writing to it. Sightline remembers the connection in this browser; a later visit may require **Reconnect**.
 
 Choose **Copy instructions for your assistant**, then paste them into your assistant with the folder location and your request:
 
@@ -100,6 +118,8 @@ connects your company endpoint for conversations. Neither feature captures meeti
 
 For a shared plan, context comes from the last confirmed read or save of the local plan file, with the latest successful Jira sync applied for display. Sightline cannot confirm whether OneDrive has uploaded or downloaded that version. `snapshot.source` is `saved-shared-file`; `snapshot.unsavedChangesInBrowser` explicitly reports local edits that have not been published. Those local edits are excluded from shared context. Save them before asking the assistant to work from them. A disconnected plan uses `snapshot.source: "this-browser"` and `snapshot.shared: false`; it makes no claim to be a shared source of truth.
 
+The context's `actions` list every change an assistant may propose: each with its `args`, its scope and risk, and a one-line `desc` of what it does (since 1.129.0), so an assistant can pick the right one without guessing from its name.
+
 Both outputs include the plan revision and Jira sync timestamp. Dates and status derived from children or Jira are identified by ownership rules and item flags; an assistant must propose Jira changes instead of rewriting those facts. Names and other free text remain untrusted data, not assistant instructions. Notes are excluded from exported context. Outputs contain team information: keep the folder private using your operating system or sync-service permissions. A browser picker cannot enforce who else can access a folder.
 
 Results describe the current proposal batch against the plan as it is in this browser (since 1.110.0; earlier
@@ -169,7 +189,8 @@ state and can include unsaved applied edits. Neither path establishes cloud fres
 
 **Requires Sightline 1.109.0 or later.** An initiative or task can carry a story: a markdown description of why
 the work exists, what it delivers and when it's done. Hover an item to see the first lines; click it to read the
-whole story in the details panel, or Edit to write one with a live preview. A new story starts from the plan's
+whole story at the top of the details panel, or Edit to write one with a live preview (an item with no story yet
+folds it under **Story**). A new story starts from the plan's
 template for that kind of item (**Settings → Planning guide**, Story templates). An initiative's panel also lists its tasks and
 whether each has a story, so you can walk the breakdown; Up and Down move to the next item while the panel is open.
 
@@ -193,6 +214,75 @@ HTML, shows as plain text.
 set with `template.set`), and gates have a description. Propose them with `milestone.set` field `story` and
 `gate.set` field `description`. A meeting's note is shown as Markdown and set with `meeting.set` field `note`.
 
+## What a change moves, and what Apply did
+
+The review lists each date a change moves, like "Wire it moves 2 days later (Oct 14 to Oct 16), waits for "Adapter"".
+It says what the item waits for, not that it moved because of it: holidays, time off and gates move dates too. After
+Apply, the status line counts what changed, like "Applied changes 1 to 30 (30 tasks added, 29 links added, 12 dates
+moved)". Your assistant reads the same summary in its results file.
+
+## Order before dates
+
+When you know the order of the work but not its dates, don't give every task the same placeholder start. Add each task
+with `after`, the tasks it starts after, and leave out `start`:
+
+```json
+{"op": "action", "action": "task.add", "args": {"id": "task-r02", "bar": "init-rollout", "after": ["task-r01"], "days": 3, "rough": true, "label": "R-02"}}
+```
+
+- The task starts the working day after the last of those finishes, skipping weekends, holidays and its owners' time off.
+- Add tasks in order, so each one's `after` is already placed. The review says what each starts after.
+- Give both `start` and `after`, and the later of the two wins.
+- `rough: true` marks a length as a guess. The task is hatched and labeled "guess" on the Days view, its card says
+  "Length is a guess", and the initiative counts how many lengths are guesses. Guessed lengths don't change the capacity
+  forecast, which uses effort.
+- When what it waits for runs late, Sightline pushes the task later on its own, unless automatic moving is off or a Jira
+  sprint dates the task. Then the task is flagged on its card, tagged **too early** on the Days view, and counted in
+  the warning bar's "starts before what it waits for finishes" list and Present's "starts too early" count. A done task
+  is never moved and never counted: it keeps the dates it ran on.
+- When what it waits for finishes sooner, the task's card offers the day it could start. Sightline never moves work
+  earlier on its own.
+
+For a task already in the plan, move it with `"start": "after"` instead of a date. It starts the working day after the
+last task it waits for finishes, the same day its card offers, and keeps its id and links. It needs at least one task
+to wait for; link it first with `task.link` in the same change. When a task it waits for is late and not done, `after`
+is refused, for adding and for moving: there's no day after a finish that has passed, so give a start instead. `prev` can be the task's current start alone. To mark
+an existing length as a guess, set `rough` with `prev: false` when the task isn't marked yet:
+
+```json
+{"op": "action", "action": "task.move", "args": {"id": "task-r02", "start": "after", "prev": "2026-11-03"}}
+{"op": "action", "action": "task.set", "args": {"id": "task-r02", "field": "rough", "value": true, "prev": false}}
+```
+
+There's no undated task: every task has a start. A task added or moved with `after` gets a real date, which Sightline
+pushes later when what it waits for slips.
+
+To wait for an approval, use a gate and have the initiative wait for it.
+
+## Dates in words
+
+Any date in a proposed change can be written the way people say it, not only as YYYY-MM-DD: a task's start, a
+milestone's day, time off, when a capture was raised, a due date. Sightline reads it against today when you review
+the change:
+
+| Say | Means (on Wednesday, Oct 7) |
+|-----|-----------------------------|
+| today, tomorrow, yesterday | Oct 7, Oct 8, Oct 6 |
+| +3d, in 2 weeks, 3 days ago, -2w | Oct 10, Oct 21, Oct 4, Sep 23 |
+| Friday | the next Friday: Oct 9 |
+| this Friday, next Friday | that day this week or next week (weeks start Monday): Oct 9, Oct 16 |
+| last Friday | the latest Friday before today: Oct 2 |
+| next week, last week | that week's Monday: Oct 12, Sep 28 |
+| next month, last month | the 1st: Nov 1, Sep 1 |
+| this sprint, next sprint | the sprint's first day |
+
+The review says which date each one became ("next Friday" is Friday, Oct 16, 2026), and Apply uses that date. A
+task's start that lands on a weekend or holiday moves to the next working day, as a typed date does, and the review
+says so ("+3d" is Saturday, Oct 10, 2026, so the task starts Monday, Oct 12). A day that turns out to be before today is
+flagged "(that's in the past)", unless the words mean the past on purpose (yesterday, last Friday, 3 days ago, -2d).
+Anything else is refused with the forms that work, never guessed. Because words are read on the day you review, review a change on the
+day it was written if the exact day matters.
+
 ## Skills, needs and hints
 
 **Requires Sightline 1.117.0 or later.** The plan keeps a skills catalog (**Settings → Team**, up to 500, each label
@@ -216,6 +306,15 @@ action, field `aiHint`.
 workstream. `workstream.del` {id} removes one only when it's empty (no work, splits, own reserve, deliverables or
 block types) and always waits for a person, at every review level. Its guidance goes with it.
 
+`workstream.reid` {lane, id, prev} changes a workstream's id, so the id says what the workstream is now: `lane` is its id
+now and `id` the new one. Everything that names it changes in the same update, with one Undo: initiatives, milestones,
+notes, meetings, process types and blocks, deliverables, people's time splits, its guidance, saved views, the baseline,
+snapshots and the last status update. The old id stays on the workstream (`was`, exported with it), so a file written
+before the change still finds it; review says when a change used an old id, and what it applies names the new one. The
+new id follows the rules for a new workstream's (1 to 60 letters, digits, dots, dashes or underscores, starting with a
+letter or digit) and is never one in use, or one another workstream had before. It always waits for a person. A plan
+with a former id needs this version or later: older copies open it read-only.
+
 ### What's missing
 
 `coverage.context` lists, counted from the whole plan before anything is trimmed: workstreams without guidance,
@@ -311,7 +410,9 @@ Placements are actions, and they use the same rules as the bulk sort, so a place
 - `jira.toWorkstream {keys, lane, epic?}` puts issues in a workstream. Stories of an epic whose stories are all known go on one initiative for the epic, with the stories nobody picked switched off; otherwise each becomes its own Jira-linked initiative. With `epic`, the stories move together or not at all.
 - `jira.toInitiative {keys, id}` adds them as Jira-linked tasks on an initiative that takes Jira work, or switches a story its epic already counts back on.
 - `jira.notOurs {keys}` hides them from Sort Jira work. Undo, or **Show them again** in Sort Jira work, brings them back.
-- `jira.epicLink {epic, id}` and `jira.epicNew {epic, lane, id?}` place a whole epic, like the epic's **On** menu.
+- `jira.hide {keys, why?}` keeps Jira items off the plan's views, the plan's own way for each: a story is switched off in its epic's initiative, an epic is parked, and an issue the plan doesn't show is marked not ours. The review says which, and says so when hiding parks an epic. `jira.unhide {keys}` brings them back. `cards.hidden` in the context lists what's hidden and why. Plan work (a Jira task, or an initiative that is one Jira issue) can't be hidden.
+- `cards.set {field, value, prev}` changes the team's card layout on the Cards page: `fields` (an ordered list from `cards.fields`), `density` (`compact`, `normal`, `detailed`) or `width` (`fixed`, `points`).
+- `jira.epicLink {epic, id}` and `jira.epicNew {epic, lane, id?}` place a whole epic, like the epic's **On** menu. An epic counts on one initiative: `jira.epicLink` refuses one another initiative holds and a 51st, and moves one that's parked elsewhere.
 
 Each is checked again when it applies, against both Jira files: an issue already where the change puts it counts as done; one placed somewhere else, a target that can't take work any more (parked, waiting, with sub-initiatives), or an epic's stories that changed in Jira make the change wait as changed since, and nothing in it is applied. New initiatives and tasks get ids made from the Jira key (`bar-abc-101`, `task-abc-106`), so a retry can't add them twice.
 

package/docs/bundled-skills.md

@@ -8,7 +8,7 @@ without the repository, Node.js, npm or Python. Keep this HTML file; the skills
 
 ## Open the collection
 
-In the toolbar, choose **Connect assistant** (or **Changes**), then **Setup and files → Planning skills and team guidance → Planning skills**. You can also open
+Choose **Connect assistant** in the menu under your name (or, once an assistant is connected, the assistant button in the toolbar), then **Setup and files → Planning skills and team guidance → Planning skills**. You can also open
 **Settings → Planning guide → Get planning skills**. The dialog shows the bundled Sightline version and each
 skill's purpose. You don't need to connect a plan or an AI endpoint to get the files.
 

package/docs/getting-started.md

@@ -48,7 +48,7 @@ outcome's ID, leaves the new idea unassigned, and does not turn this into a whol
 The repository contains [roadmap-session-amendments.json](../examples/northstar/roadmap-session-amendments.json),
 a **prepared example**, not a live model response. With the Northstar plan open:
 
-1. Choose **Connect assistant** in the toolbar and expand **Use individual files instead**.
+1. Choose **Connect assistant**: it's in the menu under your name (top right), or type "assistant" in Find (/ or Ctrl+K, ⌘K on a Mac). Then expand **Use individual files instead**.
 2. Choose **Connect that file**, then select **examples/northstar/roadmap-session-amendments.json**.
 3. Inspect the two proposals: move **Bring customer context into everyday work** from **Q2 2027** to **Q1 2027**;
    add **Explore offline search** as an unscheduled idea with no owner.
@@ -78,7 +78,7 @@ Do not connect both batches at once.
 Preserve any example edits you want first. Choose **File → Open a copy…** and select
 **examples/northstar/blank-plan.json**. This opens an empty, detached plan rather than linking writes to the
 example file. In Settings, set your plan title and calendar before scheduling work. On Roadmap, add an outcome
-in **New idea**, such as “New teams can create their first shared plan.” Keep unknown timing and owners unknown.
+in **New roadmap idea**, such as “New teams can create their first shared plan.” Keep unknown timing and owners unknown.
 
 Choose **File → Save as a new shared plan…** and save a separate JSON file. Confirm that the toolbar identifies
 it as a shared plan. Close and reopen the app, choose **File → Open shared plan…**, and select that file.
@@ -87,7 +87,7 @@ copied separately.
 
 ## Bring your own assistant
 
-1. Open your own plan and connect a private folder using **Connect assistant → Connect your assistant**.
+1. Open your own plan and connect a private folder using **Connect assistant → Connect your assistant** (in the menu under your name).
 2. Choose **Copy instructions for your assistant**. Paste them into your external coding tool with that folder's location.
 3. Point it at the source checkout's **skills/** folder, or install the individual skill folders where it discovers them.
 4. Start with a small real request. The assistant reads fresh context and writes proposals; you review and apply them here.

package/docs/jira.md

@@ -52,8 +52,16 @@ that computer. The default output is a **jira** folder beside the plan.
    Your assistant can propose where each issue goes (the **Sort Jira work** skill); you review every placement in
    **Changes** before anything joins the plan, and nothing is written to Jira. See
    [Sorting Jira work](assistant-workflow.md#sorting-jira-work).
+   On the Timeline, a bar with no Jira key was added here and isn't tracked in Jira (hover it to see). Once the plan
+   has Jira work, the List and the Days view label such work **Added here**. An initiative counts as tracked when it,
+   or anything inside it, links to Jira.
 5. An initiative or task linked to an issue shows the issue's description as its story, marked **From Jira**
    (Sightline 1.109.0 or later, with the matching sync). The sync reads descriptions only for issues the plan links.
+6. Every Jira item shows who owns it as a small circle with their initials. You'll see it on story and Jira-linked
+   bars, sprint shelf tiles, cards, List rows, and the hover card and details. A dashed empty circle means unassigned.
+   An outlined circle is an owner outside the team. Hover it, or use a screen reader, for the full name. Spotlight
+   rings that person's circles. The initials come from the plan's people and Jira's display names. No pictures are
+   fetched. If two people share initials, each gets a third letter.
 
 For repeated syncs, run `python3 /trusted/helpers/sightline-jira-sync.py watch`. Read `install --help` before
 configuring startup behavior. Run trusted helper code from your own computer, never a mutable shared folder.

package/docs/onedrive.md

@@ -9,6 +9,7 @@ Sightline opens the plan file on your computer. OneDrive carries that file betwe
 3. Wait for OneDrive to finish downloading the folder, then open Sightline in Edge or Chrome. Choose **File → Open shared plan** and select the local file. Connect the local Jira folder if your team uses it.
 4. Leave **File → Check for teammates' saves every 15 s** on to pick up local changes; this is enabled by default unless you previously turned it off. Use **Refresh** before starting work. Check OneDrive's own status before handing the plan to a teammate.
 5. Edit one at a time: **Start editing**, **Save**, then **Done editing**. Agree who is editing when a computer is offline or sync is paused.
+   The file only changes when the plan does: **Save** with nothing changed writes nothing, and **Done editing** with nothing changed puts the file back exactly as it was before **Start editing**, with the same revision.
 
 OneDrive and your organization control folder access. Sightline's views, author stamps and edit lock are not access controls.
 
@@ -18,7 +19,7 @@ The page shows its last confirmed local read or save. Automatic checks can notic
 
 The edit lock is stored in the same shared file, so it also travels through OneDrive. Two offline computers can each believe editing is available. Sightline checks local content before saving, keeps backups for detected clashes, and preserves unsaved drafts, but it cannot guarantee that an unseen cloud update will never cross a save. Keep both versions if OneDrive produces a conflict copy.
 
-If another person starts editing while you have unsaved changes, Sightline keeps your browser copy, undo history and recovery draft. Review the conflict choices before replacing either version. After a file-read failure, **Try again** reconnects from your current browser contents, including edits made since the failure. An unchanged file preserves your edits; a changed file is merged or presented for conflict review. A newer unsupported file format keeps your edits available for download and requires updating Sightline before saving.
+If another person starts editing while you have unsaved changes, Sightline keeps your browser copy, undo history and recovery draft. Review the conflict choices before replacing either version. After a file-read failure, **Try again** reconnects from your current browser contents, including edits made since the failure. An unchanged file preserves your edits; a changed file is merged or presented for conflict review. When you and a teammate both change what the same task or initiative waits for, both sets of links are kept, and a link one of you removed stays removed. A link that would make work wait for itself through the other person's links isn't merged: their version wins, yours is backed up, and Sightline says which link wasn't kept and why. A newer unsupported file format keeps your edits available for download and requires updating Sightline before saving.
 
 ## Keep assistant folders personal
 

package/docs/performance-workspaces.md

@@ -37,3 +37,80 @@ The deferred update is cancelled when a full render supersedes it. Regression ch
 undo, cursor retention and the deferred screen update without depending on a machine-specific time threshold.
 
 The connected-assistant regression harness (`harness100`) counts payload builds and file writes. View changes and unchanged foreground checks must add neither; real saved-source, Jira, proposal and receipt changes must still refresh outputs. A Chrome Incognito smoke test also verified that ordinary navigation left context/results modification times unchanged after a proposal was reviewed and applied.
+
+## Browser harness
+
+`test/perf/` measures the built page in Chromium on synthetic plans. It's the harness to use before claiming a change is
+faster or slower. It needs Playwright (a dev dependency) and its Chromium:
+
+```bash
+npm ci && npx playwright install chromium
+./build.sh
+npm run perf -- --sizes S,M --cpu 1,4                          # results.json and report.html in test/perf/
+npm run perf -- --sizes L --cpu 4 --compare test/perf/baseline.json
+node test/perf/profile.js M tl.two 4                           # where one scenario's time goes, by function
+```
+
+**Plans.** `test/perf/gen.js` makes a plan file and a Jira status file from a fixed seed, in four sizes. The names, keys
+and text are invented.
+
+| Size | Workstreams | Initiatives | Plan tasks | Jira stories | Time span |
+|---|---|---|---|---|---|
+| S | 5 | 30 | 150 | 300 | 6 months |
+| M | 12 | 120 | 800 | 2,000 | 1 year |
+| L | 25 | 400 | 3,000 | 8,000 | 2 years |
+| XL | 40 | 1,000 | 8,000 | 25,000 | 3 years asked, 2 drawn |
+
+Each plan mixes in the hard shapes:
+- long labels and overlapping bars;
+- eight milestones on one day;
+- dependency chains 20 deep;
+- epics across several sprints, stories not estimated, with no sprint or abandoned;
+- a stale future sprint, parked initiatives and stories turned off;
+- notes, decisions and risks.
+
+A plan covers at most 104 weeks, so XL is drawn over two years. XL's Jira file is past the page's read limits (5 MB and
+9,000 issues), so the harness loads it in memory to measure the drawing only. The report says so.
+
+**Scenarios.** Plans are built around today's date, so the page runs on its real clock: a stand-in `Date` costs
+measurable time in every draw. The same size, seed and day give the same plan (`PERF_TODAY` rebuilds another day's).
+Each run opens a fresh page at 1440 by 900 and opens the plan
+the way a person does: a file handle through `adopt`, then the Jira folder through `readJiraDir`. Then it runs:
+
+- **Load:** opening the plan and Jira folder, to the first drawn Timeline.
+- **Jira:** a new sync arriving.
+- **Timeline:**
+  - Weeks at Fit, This sprint, This + next and Next 3;
+  - zooming in and out;
+  - scrolling sideways and down;
+  - turning sprint shelves off and on, where the version has them.
+- **Days:** switching to it, and scrolling across a quarter.
+- **Interactions:**
+  - opening and closing a panel;
+  - dragging a bar and dropping it;
+  - typing in Find;
+  - a filter;
+  - switching views;
+  - Undo;
+  - saving.
+- **Pages:** Today, Sprint, Cards (where present), List, Roadmap and Capacity.
+
+**Measures.**
+- **Responses:** from the change to the next painted frame, as the median and 95th percentile over the runs (5 at S
+  and M, 3 at L and XL). For real clicks and keys, it is the time from the input event's own time stamp to the second
+  frame after it, plus any long task the drop sets off.
+- **Long tasks:** count, and the longest over 50 ms.
+- **Layouts and style recalcs:** from the DevTools protocol.
+- **Page state:** DOM nodes and JS heap after each scenario.
+- **Motion:** frames per second, dropped frames (over 25 ms) and the worst frame. Scrolling sets the scroll position once per frame, so scroll handlers run on the
+  main thread: this is the worst case, not compositor-only scrolling.
+
+`--cpu 4` throttles the CPU four times, as a stand-in for a slower work machine.
+
+**Budgets and the baseline.**
+- `budgets.json` holds the proposed budgets at M and L with 4x throttling.
+- A scenario already over budget is listed under `known` with today's measured value, so the check still fails if it
+  gets worse, and the entry is removed when a fix brings it under budget.
+- `--compare baseline.json` flags any scenario more than 20% slower than the baseline. Compare only runs from the same
+  machine.
+- CI runs S and M on every change against `budgets-ci.json`, which is calibrated for the CI runner. L and XL run by hand.

package/docs/team-planning.md

@@ -47,6 +47,40 @@ For leadership, ask:
 Use **Delivery → Status update** for the shared delivery conversation and **Product updates → Customer release notes**
 for customer wording. A proposed or planned outcome is not something that shipped.
 
+## Capture what comes up
+
+Meetings raise things that aren't work yet: "the support team wants to hear when the release process changes", "we
+have no way to send release notes to the teams that use them". Keep them in the plan as captures (since 1.131.0):
+
+- Paste your notes into your assistant with the meeting-to-plan skill. It proposes one capture per item: a request,
+  idea, process gap or question, with who asked (a person or a group already in the plan), the meeting and its date,
+  and the workstream when it's clear. A team that isn't in the plan yet comes as a new group, which always waits for
+  your review.
+- Or capture one by hand, live in the meeting: **Add** (or press A, then C) → **Capture a request or idea**, or
+  **+ Capture a request or idea** in To triage. Only what was raised is needed; who asked and the workstream stay
+  unknown unless you pick them, and the meeting and its date carry over to the next capture. **Capture and add
+  another** keeps the form open.
+- Raised again? As you type what was raised, the form lists captures with a similar name. **Same thing: record it
+  there** adds this meeting, who asked and the date to that one instead of capturing it twice; **Capture** keeps it
+  separate. Nothing is ever merged on its own. A capture's card lists every time it was raised again, with
+  **Record it** to add one by hand and **Remove** to take one out, and its row in To triage says how many times it's
+  come up. Your assistant does the same with the meeting-to-plan skill (since 1.133.0).
+- **To triage**, on the Roadmap, lists open captures by workstream, oldest first, with **Unassigned** last. Open one
+  to **Hand off** (to an initiative or a Jira issue) or **Decline** with a reason; **Reopen** puts it back.
+- A capture still open after 30 days also shows on **Today**, in the **Team** view, under **Waiting in triage** (oldest
+  first, with a count in Needs attention), so none quietly rots. **Triage** on a row opens it in To triage to hand it off or decline it.
+
+**By asker**, in To triage, lists everything each person or group raised, open ones first, then what became of the
+rest. **Copy a note for them** copies a short plain-text note to send back: each thing they raised and where it stands,
+naming no one else. **Meeting recap** says what's new, raised again, closed and reopened since your last meeting (pick
+another day if you like), with how many are still open. It leaves out who asked unless you tick **Say who asked**, since
+a recap is often pasted where others read it. Closed and reopened come from the plan's change log, which keeps 30 days.
+Neither saves anything to the plan (since 1.134.0).
+
+A date doesn't commit a capture, and handing it off doesn't mark anything done: those stay roadmap decisions. A Jira
+issue it became stays Jira's; the plan keeps only its key. Captures sit in the shared plan file, so write them as you'd
+say them in the room.
+
 ## Between meetings
 
 - Start in **Work → Today** for attention, blockers and due decisions.

package/docs/workspaces.md

@@ -4,21 +4,57 @@ Start with the [launch instructions](../README.md#try-it-with-an-invented-team-p
 plan file from Sightline's **File** menu. The source template is not the runnable release, and a plan link alone does
 not grant access to its file.
 
-The menu runs down the left side. Every page has one home:
+The menu runs down the left side. At the top are your pinned pages: Today, Sprint, Timeline and Capacity until you
+change them. Below them, every page has one home in a group:
 
-- **Work**: Today shows attention and next actions. Sprint shows the current sprint by person, workstream or epic. Sort Jira work places synced issues on the plan, and Jira change proposals reviews what the sync suggests.
-- **Delivery**: Timeline shows planned work. List shows the same work as rows. Capacity shows the forecast, people and time off. Status update, Decisions and Risks support delivery reviews. Milestones, Gates, Snapshots and Activity hold the supporting lists.
+- **Work**: Today shows attention and next actions. Sprint shows the current sprint by person, workstream or epic. Sort Jira work places synced issues on the plan. Cards shows the plan's Jira work as cards by workstream. Jira change proposals reviews what the sync suggests.
+- **Delivery**, in three parts. Plan: Timeline shows planned work. List shows the same work as rows. Capacity shows the forecast, people and time off. Review: Status update, Milestones, Gates, Decisions and Risks support delivery reviews. History: Snapshots and Activity.
 - **Product updates**: Roadmap explains what the team plans to ship. Customer release notes opens the customer wording approved for each Jira release.
-- **Settings**: Plan (Tags, Planning guide), Team (Team, Work calendar, Meetings, Timeboxes and ceremonies) and Connections (Jira connection).
-
-Counts and warnings sit on the page they belong to, such as open risks on Risks. Click a group's heading to fold it;
-the group you're in stays open. The button at the top of the menu, or the `\` key, collapses the menu to a rail of
+- **Settings**: Plan (Tags, Cards, Planning guide), Team (Team, Work calendar, Meetings, Timeboxes and ceremonies) and Connections (Jira connection).
+
+Groups start closed. Click a group's heading to open or fold it; the group you're in opens unless its page is pinned.
+A number shows only when something needs you, such as high risks on Risks or what needs attention on Today, and a
+closed group shows a dot when something inside it does. To pin a page, point at it in its group and click the pin, or
+focus it in the menu and press P (the arrow keys move through the menu). A filled pin means it's pinned. Unpin it the
+same way, from its group or from the top. You can pin up to five pages; pins stay in this browser and
+never change the plan. The button at the top of the menu, or the `\` key, collapses the menu to a rail of
 icons, and hovering or focusing an icon opens that group beside it. Sightline remembers the choice in this browser.
 On a narrow window the menu starts as a rail.
 
-Each group remembers your last page. Existing saved startup choices and links still open their original destinations. Views express audience preferences; file permissions control access.
+Each group remembers your last page. Existing saved startup choices and links still open their original destinations. The browser's Back and Forward buttons step through the pages and items you opened, and bring each back as you left it: the same item open, and the page, chart and details panel scrolled where they were. Where you'd scrolled stays in this browser's history, so a copied link opens clean. Views express audience preferences; file permissions control access.
+
+Saved views and filters apply to Timeline, List and Capacity. To look at one initiative or one person's work, select it and click **Show only this initiative** or **Show Avery's work** on its card, or press **Z** (double-clicking an initiative does the same). It shows as a chip above the chart, such as **Initiative: Search** or **Person: Avery**; show an initiative and a person together to see that person's work in it. Click a chip to take it off, or **Show all work** to clear every filter. The browser's Back button undoes each of these. A person's work is the tasks and Jira stories assigned to them, plus initiatives they lead. Showing a person takes the place of any people you picked in Filters, and showing an initiative takes the place of any initiatives you picked; your other filters still apply, and the zoom stays as it was. If none of what's shown is in the dates on screen, a line under the chips says when it is, and **Go to it** scrolls there; if nothing matches at all, it says so. Chips are your own view in this browser and never go in the plan; links carry them. To look at several initiatives at once, pick them under **Filters > Initiatives**. Each shows with everything inside it and the initiatives that hold it, plus the milestones done when a shown initiative is. Gates are hidden while you're picking. Roadmap and Status update use the whole plan and say so. Your filters remain available when you return to Timeline.
+
+To see one item with everything tied to it, select an initiative, task, milestone or gate and click **Show linked work** on its card, or choose **Show only what's linked to the selection** in Find. It shows the item, everything it waits for all the way back and everything that waits on it all the way on, but not work that only shares a prerequisite with it. An initiative brings what's inside it, and a task brings the initiatives that hold it. The Timeline switches to **Fit** so all of it is on screen, and the late count says it covers the whole plan. A **Linked to** chip above the chart says what it's linked to; take it off, or press Back, to see everything again at the zoom you had. It changes nothing in the plan, and the List shows the same work. While linked work is shown, select another item and click **Add to linked work** (or use Find) to see what's linked to it too, up to 5 picks; each has its own chip, and **Remove from linked work** on a pick's card takes just that one off. To keep everything on screen instead, click **Highlight instead** next to the chips: what isn't linked is dimmed, and still works when you hover, click or tab to it. **Hide the rest** switches back, Back undoes either, and taking the last chip off ends it. With an item selected, a dashed outline marks what it's directly linked to; the Key says so. On a narrow window with the details panel open, a long span can be wider than the chart even at **Fit**, because weeks keep a minimum width; scroll sideways, or close the panel, to see the rest.
+
+To see what a milestone is waiting on, select it: **What leads here** on its card lists the work it waits for, all the way back, but nothing that waits on it. It names what finishes last and when, then the rest, latest finish first, with each item's date, status and owner. Work finishing after the milestone's date is marked, and so are dates that come from Jira's sprints. A milestone that's done when its initiatives finish takes its date from them, and the card says so. Click an item to open it; nothing in the list changes the plan. To see all of it on the Timeline, click **Show on the Timeline**: it shows the milestone and only what leads to it, with a **Leading to** chip above the chart.
+
+Any linked work can be shown one way. While linked work is showing, open **Linked work** beside the chips and choose **Leads here only** (or press **>**) to keep what the picks wait for, all the way back, and hide what waits on them; with several picks, it's what leads to any of them. **Both ways** switches back, and Back undoes either. Taking the last chip off ends it. The status line counts the linked items that are on screen; when your other filters (a person, a workstream, hidden done work, a tag) hide some of them, it says how many, and in the List it says how many linked milestones and gates are on the Timeline. To see sideways too, choose **Work that waits for the same things** in the same menu: it adds the work that waits for something the picks wait for (directly, not further back), and what's in it, and the status line counts those items on their own. It shows linked work both ways, so choosing it from Leads here only switches back to both ways; choose it again to take those items off. It's yours alone: a saved view never keeps linked work, so a view always opens with nothing picked.
+
+## Cards
 
-Saved views and filters apply to Timeline, List and Capacity. Roadmap and Status update use the whole plan and say so. Your filters remain available when you return to Timeline.
+**Work > Cards** shows every Jira story, Jira task and one-issue initiative on the plan as a card. Rows are workstreams in
+plan order. Inside a workstream, cards sit under their initiative, and the ones that aren't on an initiative come last.
+Rows can also be people or epics. Columns are status (to do, in progress, done, and canceled when you tick it) or sprint
+(earlier sprints, the active one, the next ones, no sprint). Filter by sprint, person, status, epic or text, or click
+**Mine**. Each total says what it leaves out: cards not estimated, cards you hid, and cards the filters hide, each counted
+on its own.
+
+- **Drag a card to another workstream or onto an initiative** to place it there. It's the same change Sort Jira work
+  makes: a story leaves its epic's initiative (switched off there), and a Jira task leaves its initiative. One save, with
+  Undo. A one-issue initiative moves between workstreams; to put it inside another initiative, change its parent in its panel.
+- **Drag a card to another status or sprint** to propose that change for Jira. Jira doesn't change. When a status column
+  covers several of your workflow's statuses, Sightline asks which one and remembers your choice in this browser.
+- **Without a mouse**: focus a card and press **M**, choose a place with the arrow keys, then press **Enter** (or **Esc** to cancel).
+- **Hide** keeps a Jira item off the plan's views (cards, the timeline and List), with an optional reason, using the plan's
+  own ways: a story is switched off in its initiative, an epic is parked, and an issue the plan doesn't show is marked not
+  ours. **Hidden** lists each one, how it's hidden and why, with **Bring back**. Work that's on the plan as its own task or
+  initiative can't be hidden; take it off the plan instead.
+
+**Settings > Cards** sets what a card shows: the fields and their order, the density (compact, normal or detailed) and
+whether cards get wider for more points. The plan holds the team's layout (change it while editing). **Mine** is your own
+layout in this browser, with **Reset to the team's layout**. A plan with a team layout or hide reasons opens read-only in
+an older copy of Sightline.
 
 ## Declutter: hide what you don't need
 
@@ -35,15 +71,16 @@ Saved views and filters apply to Timeline, List and Capacity. Roadmap and Status
 
 ## List
 
-**List** (Delivery, next to Timeline, or press L) reads the plan top to bottom, like a checklist. It shows the work Timeline draws for the same filters: initiatives with their tasks, and Jira stories placed on the plan or counted under an epic. Each row has Start, End, Item, Owner, Waits on and Status.
+**List** (Delivery, next to Timeline, or press L) reads the plan top to bottom, like a checklist. It shows the work Timeline draws for the same filters: initiatives with their tasks, and Jira stories placed on the plan or counted under an epic. Each row has Start, End, Item, Workstream, Owner, Waits on and Status.
 
-- **Layouts:** By initiative (initiatives are group headers with their own dates, owner and item count), By person (a task with two owners appears under each, marked shared), and Everything by start date. Ties keep initiative order, then plan order. The layout stays in your browser for each plan; it isn't part of a saved view.
+- **Layouts:** By workstream, the default (each workstream in its order, with its color, its initiatives and their tasks under it; the Workstream column is left out, since each group names it), By initiative (initiatives are group headers with their own dates, owner and item count), By person (a task with two owners appears under each, marked shared), By start date (everything in one list), and By connection (each chain of linked work as its own group, named for where it starts (every starting point, when it has more than one), in the order it has to happen: what a row waits for comes before it; chains go by when they start, a chain holding linked work you picked comes first, a chain with a loop says so, and work with no links is last; filters hide rows but never move one to another group), By order (steps from what waits for what: step 1 waits for nothing, each later step waits only on earlier ones, waiting for an initiative means waiting for everything in it, and work in a loop is set apart; filters hide rows but never change a step; waiting and unstaffed rows are listed apart, last). Steps show order, not what's ready: a done item still counts, so a step 2 item whose step 1 work is done can start now. Ties keep initiative order, then plan order. The layout stays in your browser for each plan; it isn't part of a saved view.
 - **Dates** are Timeline's own: weekends, holidays and owners' time off are already skipped.
 - **Owner** shows the plan's owners; for a Jira item, its Jira assignee and, separately, any plan lead. People outside the team or inactive are marked.
-- **Waits on** lists what an item waits for: a task's links, and an initiative's waits on other initiatives, gates and process steps. In the flat layouts a task's row also shows its initiative's waits. Jira dependencies link to Jira, with a warning when one ends after the item starts. Click a name to open it.
+- **Waits for** lists what an item waits for: a task's links, and an initiative's waits on other initiatives, gates and process steps. In the flat layouts a task's row also shows its initiative's waits. Jira dependencies link to Jira, with a warning when one ends after the item starts. Click a name to open it.
 - **Status** is the status Timeline shows. For a Jira item, Jira's own status and when it was synced.
 - Work Timeline doesn't draw (parked, switched off, abandoned in Jira, or without sprint dates) is in **Not on the timeline** at the end, with the reason, so nothing goes missing.
 - Hover or focus a row for its card; click it or press Enter for its details. Escape closes them and returns you to the row; Up and Down move between rows. A selection carries between Timeline and List, and the page, layout and selection are in the link.
+- **Columns:** drag the edge of a column's heading to make it wider or narrower, or focus the edge (Tab) and use Left and Right (Shift for bigger steps). Double-click an edge for that column's default width. The first resize sets every column to the width it shows, so nothing else moves, and a wide table scrolls sideways. **Columns** in the toolbar sets each column to wrap or keep one line; a one-line column is cut short with the full text on hover. Out of the box only the dates keep one line. **Reset columns** goes back to that. These settings are yours, kept in this browser for every plan; they aren't in the plan or a saved view, and printing always shows every column in full.
 - **Copy as table** copies the rows as shown as a markdown table. If the browser doesn't allow copying, the table appears selected so you can copy it yourself. **Print** prints every row, with the header repeated on each page.
 
 Edits stay in the details panel; List has no editable cells.
@@ -62,12 +99,13 @@ selection while keeping your text. **Test reply** checks for a response, and **C
 instructions. Read the [first planning session](assistant-workflow.md#first-four-quarter-planning-session)
 for the in-app route. External tools use the [private-folder session](assistant-workflow.md#your-first-external-planning-session) and their own conversation.
 
-Unsubmitted **New idea** text stays with its plan during navigation and redraws in this tab's session. It is not
+Unsubmitted **New roadmap idea** text stays with its plan during navigation and redraws in this tab's session. It is not
 included in the saved plan or assistant context until added. Successful submission clears only the submitted text;
 an idea you start typing while the save finishes is retained. Copy or submit drafts before closing the app.
 
 Today distinguishes no work loaded, missing Jira status data, and incomplete connected data. Its attention flags
 describe the available plan and sync; a quiet summary does not establish delivery feasibility.
+In the Team view it also lists captures that have waited in To triage for over 30 days.
 
 Open the menu at the right of the header (**Choose yourself**, or your initials once you have) and choose **Choose yourself** or **You: [name]** to identify yourself for Mine and author stamps. This is a browser preference, not a verified identity. The same menu has text size, theme, **What's new** and help.
 
@@ -75,17 +113,59 @@ Open the menu at the right of the header (**Choose yourself**, or your initials
 
 **File** holds only what you do with the plan file: the shared file, importing a copy and exporting one. The plan's start date, default sprint length, whether linked items move automatically and where Jira links go are in **Settings → Plan details**. **Set baseline** is on **Delivery → Snapshots**, and the page Sightline opens on is under **Start Sightline with…** in the menu at the right of the header. Each Settings page is titled with its name in the menu.
 
+**The Time button.** On the Timeline, the time controls (Weeks and Days, the sprint picker, **‹** **›**, the presets and **+** **−**) sit behind one **Time** button that says what's on screen, for example **Time: Weeks · S2 (Oct 19 – Oct 30)**. It starts closed; click it to open the controls in place, where the button shrinks to its arrow so the toolbar stays one row, and this browser remembers whether you left it open. The shortcuts and Find work either way, and the button keeps up with them. Warnings about the plan, like the late count, never go inside it.
+
+**What's hidden.** When the Timeline leaves things out, a line under the toolbar says why: kinds you hid, the Added by filter, parked initiatives, workstreams outside the dates on screen. With two or more reasons it folds into one line that counts each, with what you chose to hide first, and **Details** opens the full notes and their buttons (**Show everything**, **Review parked**, **Clear it**). It starts closed, and this browser remembers whether you left it open. One reason shows in full. Warnings, like the late count, are never folded into it.
+
+**One sprint, edge to edge.** Open **Time**, then beside Weeks and Days pick a sprint (its tooltip shows the dates on screen). The view fits it exactly, its first day at the left edge and its last at the right, in Weeks and Days, whatever its length and the window's width. **‹** and **›** (or **[** and **]**) step to the previous and next sprint; **.** goes to the sprint we're in, or the next one between sprints. With **+** and **−** you can show two or more sprints from the chosen one. **Fit** lets the view scroll freely again. The choice stays in this browser, and a link to the Timeline carries it. Beside the picker, **1** (This sprint), **2** (This + next), **3** (Next 3) and **Fit** get there in one click, always from the sprint we're in (or the next one, between sprints); Shift+1, Shift+2, Shift+3 and Shift+0 do the same. A plan with sprints opens on This + next the first time, and after that on your last choice, moved along to the current sprint. A link with a sprint wins over both.
+
+**Sprint shelves.** In Weeks, with rows by workstream, each workstream's Jira stories sit on a shelf per sprint instead of a bar each. Tiles are grouped under their initiative, with stories not on one last. A tile's width follows its points, one scale for the whole chart (a minimum so small stories stay readable; past 13 points the width stops growing and the tile is marked ▸). Each tile shows its points, a status symbol (○ not started, ◐ in progress, ● done) and the assignee's initials; hover or focus a tile for the full facts, and click it, or press Enter, to open its panel. A red corner and ⛔ mean blocked in the plan. Stories with no estimate sit in a Not estimated strip, and stories with no sprint in this plan are counted as Unscheduled, beside the shelves. Canceled stories are left out. Where a tile sits inside a sprint says nothing about when. The summaries count estimated points and done points, next to the story counts; they aren't effort or a forecast, and capacity isn't compared yet. At Fit or several sprints the shelves show summaries only; pick one or two sprints for the tiles, or use Show the stories beside a workstream's shelves. Tab reaches each shelf once; the arrow keys, Home and End move along it. Spotlight lights up one person's tiles. Show, then On sprint shelves, turns them off. Shelves are display only: a one-story initiative is still in the plan, and List shows every story as a row.
+
 **Where we are.** The sprint we're in is a soft band behind the bars, and its header reads, for example, **Sprint 42 · now**. Today is a red line with a **Today** tab in the time header; in Weeks it sits at today inside the week. Between sprints there's no band, and the next sprint's header says when it starts. Before or after the plan's dates the tab waits at that edge with the date. Capacity's load grid marks the sprint's weeks and this week, and Roadmap marks the quarter we're in. Press **.** to jump to today in either zoom. All of it prints.
 
 On the Timeline, **View** holds the rows (by workstream, person or epic) and, when the plan has Jira work, which sources to show. The button says what's chosen, for example **View: By person · Jira only**, so a filtered review is never a surprise. R still switches rows.
 
+The sources are **All sources**, **Jira only**, **Jira + mine** and **Added here**. **Added here** shows only work that nothing in Jira tracks: tasks and initiatives with no Jira key, and any initiative that holds such work. Jira-linked items and Jira's stories are hidden; milestones, gates and notes stay. It works on the Timeline and the List. Sprint shows Jira's sprint, so it isn't offered there. While it's on, a banner above the chart says so, in Present too, with **Show everything** to turn it off, and the late count says it covers the whole plan. It's your own choice for this plan in this browser, and saved views never record it.
+
 Today names each due decision's decider; its owners may be different people.
 
-Find reveals a matching milestone, gate or note through the Timeline's filters, folded rows and hidden layers. **Restore previous view** returns to the view you had before opening the result. Filter controls retain keyboard focus when the view updates, and status messages remain visible on narrow screens.
+**Find** (/ or Ctrl+K) also runs actions by name: type "days", "start editing", "rows by person" or "show only" and press Enter. Each action shows its shortcut, and only actions that apply right now are offered, so what's selected and whether you're editing decide what you see. Press **?** for every shortcut. Find reveals a matching milestone, gate or note through the Timeline's filters, folded rows and hidden layers. **Restore previous view** returns to the view you had before opening the result. Filter controls retain keyboard focus when the view updates, and status messages remain visible on narrow screens.
+
+**J** and **K** move to the next or previous item in the view you're in. On the Timeline and the List they select it, so its details open beside it; on Today, Sprint, Capacity and the Roadmap they move keyboard focus, and **Enter** opens it. Once you're on a row there, the **Up** and **Down** arrows do the same. In People load, **Enter** on a person opens their card. On the Plan pages with a table (Milestones, Gates, Decisions and Risks) they step through its rows, and **Enter** puts the cursor in the row's first field; on Cards they step through the cards (press **M** on one to move it). At either end they stay put and say so. On a Mac, the keyboard help, Find and the toolbar's tooltips show ⌘, ⇧ and ⌥ where other computers show Ctrl, Shift and Alt.
+
+With a task or initiative selected on the Timeline or the List, **O** puts the cursor in its owner picker: type a name and press **Enter** to add them, or **Backspace** to take off the last one. It's a plan edit, so it works while you're editing. On a Jira item it sets the plan's lead, never Jira's assignee. An initiative whose owners come from its tasks says so instead. Find also moves the selection while you're editing: type "week later", "week earlier" or "next sprint". Each move is one Undo (Ctrl+Z, or ⌘Z on a Mac), the status line says where it now starts and what moved with it, and focus stays on the item so J, K and another move carry on. To link a Jira epic to the selected initiative, type "link epic": the cursor lands in its epic box. An epic counts on one initiative, so a key that's already on another one is refused with its name. Work whose dates come from Jira isn't offered a move.
+
+**More keys.** With something selected on the Timeline or the List:
+
+- **C** shows only what's linked to it; **C** again shows everything. **Shift+C** adds the selection to the linked work and **Shift+X** takes it off. **Shift+Z** switches between highlighting the linked work and hiding the rest.
+- **Shift+N** moves it to the next sprint, and **{** and **}** move it a week earlier or later. Each move is one change that **Undo** reverses. Work whose dates come from Jira's sprint says so instead of moving, as dragging does, and nothing moves while you present.
+- **Shift+J** opens the Jira epic link on an initiative, while you're editing.
+- On a milestone, **Shift+L** or **<** goes to **What leads here**.
+- **>** shows what leads to the selection on the Timeline. While linked work is showing, **>** switches between only what leads there and both ways.
+
+Anywhere on the Timeline, the List or People, **0** shows all work. **Back** puts your filters back.
+
+On the Timeline:
+
+- **Shift+T** or **;** opens and closes the time controls.
+- **Shift+D** opens the Details of what's hidden.
+- **Shift+W**, **Shift+O** and **Shift+E** show rows by workstream, person or epic.
+
+**Shift+A** opens the assistant and **Shift+U** shows what's new.
+
+Shift and a letter is read from the Shift key, so with Caps Lock on a letter still does what it does without Shift.
+
+To switch off every single-key shortcut (letters, digits and symbols), clear **Single-key shortcuts** at the top of the **?** shortcuts page. This helps with screen readers and speech input. Find and keys with Ctrl (⌘ on a Mac) keep working, and this browser remembers the choice.
 
 Unsent notes, quick updates and blocker explanations stay with their plan and item during this session when details redraw. They clear after successful submission. They are temporary browser-session drafts; submit the text before closing the page. Saving other plan edits does not submit a composer draft.
 
-Use **Connect assistant** in the toolbar to set up the [private assistant folder](assistant-workflow.md). Proposed changes wait for your review. Common initiative and task updates remain visible; open **Organize this initiative** or **Move this task** for structural changes.
+Use **Connect assistant**, in the menu under your name, to set up the [private assistant folder](assistant-workflow.md). Once an assistant is connected, the toolbar shows its state, and proposed changes wait there for your review. Common initiative and task updates remain visible; open **Organize this initiative** or **Move this task** for structural changes.
+
+The details panel shows what you need first: warnings, quick status, updates, notes, the title, status, owner,
+dates and an initiative's first three tasks (**Show all** lists the rest). The rest folds into **Story** (when none is
+written yet), **Schedule**, **Waits for**, **Organize** and **More**, and each fold's line says what's inside, such as
+"2 weeks" or "1 item". Warnings never fold. Sightline remembers which folds you open for initiatives and for tasks,
+in this browser only.
 
 **Settings → Planning guide** describes project scope, workstream purposes, work breakdown, vocabulary, rules,
 and examples for your assistant. Save the guide, then save the shared plan to include it in automatic assistant

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@troylar/sightline",
-  "version": "1.120.3",
+  "version": "1.171.0",
   "description": "Your team's work, in plain sight. One HTML delivery planner, Jira context, and human-reviewed AI planning.",
   "license": "MIT",
   "keywords": [
@@ -39,7 +39,8 @@
     "build": "bash ./build.sh",
     "test": "bash ./test/run.sh",
     "check": "bash ./build.sh && bash ./test/run.sh",
-    "prepack": "bash ./build.sh"
+    "prepack": "bash ./build.sh",
+    "perf": "node test/perf/run.js"
   },
   "repository": {
     "type": "git",
@@ -50,6 +51,7 @@
     "url": "https://github.com/troylar/sightline-planner/issues"
   },
   "devDependencies": {
-    "jsdom": "^24.1.3"
+    "jsdom": "^24.1.3",
+    "playwright": "1.57.0"
   }
 }

package/skills/sightline-edit-plan/SKILL.md

@@ -21,14 +21,15 @@ Make the smallest coherent change that satisfies the request.
 - For each set operation, copy the exact current value into prev, using null only when empty according to the context guide. Use the current choices for people, workstreams, stages and targets.
 - Check jiraLinked and datesFromTasks before proposing dates or status. Jira facts need a permitted Jira proposal; derived dates cannot be independently edited.
 - Keep logically dependent operations in one atomic change. Separate unrelated changes so the person can accept one without another.
-- For starts-after links, deletions, workstreams, people (role, allocation, workstream), milestones and what they're done after, gates, risks and decisions, holidays and time off, effort estimates (only numbers the person gives you) and what an initiative delivers, when people join and leave, how someone's time splits across workstreams, the support reserve, a workstream's note, color, dates and order (`workstream.set`, `workstream.move`; `workstream.del` only for an empty workstream, and it always waits for review), the skills catalog (`skill.add`, `skill.rename`, `skill.remove`, refused while a skill is in use), people's `skills` and work's `needs`, milestone stories, gate descriptions, meeting notes and `aiHint`, use the guide's action ops (`{op:"action", action, args}`) with the arguments listed under `actions`. Give every new item your own unique id, and put ops that depend on each other in one change, in order.
+- For starts-after links, deletions, workstreams, people (role, allocation, workstream), milestones and what they're done after, gates, risks and decisions, holidays and time off, effort estimates (only numbers the person gives you) and what an initiative delivers, when people join and leave, how someone's time splits across workstreams, the support reserve, a workstream's note, color, dates and order (`workstream.set`, `workstream.move`; `workstream.del` only for an empty workstream, and it always waits for review; `workstream.reid {lane, id}` when a workstream's id no longer matches what it is, which also always waits for review: use the ids under `planning.workstreams`, and treat `was` as former ids, never as new ones), the skills catalog (`skill.add`, `skill.rename`, `skill.remove`, refused while a skill is in use), people's `skills` and work's `needs`, milestone stories, gate descriptions, meeting notes and `aiHint`, use the guide's action ops (`{op:"action", action, args}`) with the arguments listed under `actions`. Give every new item your own unique id, and put ops that depend on each other in one change, in order.
+- When the order of work is known but not its dates, add tasks with `after` (the tasks each starts after) and no `start`, and mark lengths you estimated with `rough: true`. To line up a task already in the plan, use `task.move` with `start: "after"`, never a delete and re-add: it keeps the task's ID and links. A task with `rough: false` in the context is set with `prev: false`.
 - For broad requests such as “move everything back,” show scope and affected IDs before generating changes. If something is in neither the guide's operations nor its actions, describe the manual UI path.
 
 Report before and after values, what remains unchanged by the requested scope, and any decision still needed. Writing proposals is not applying or saving the shared plan.
 
 ## Write proposals only when requested
 
-Use only the operations and fields in the fresh context's `guide`, current choices and stable target IDs. Use its version 1 envelope, current plan ID, fresh batch ID, creation timestamp and `basedOn.planRevision`. Keep change IDs stable when revising the same proposal. Each change must apply entirely or leave the plan unchanged; include exact current `prev` values. Never invent a new operation or a Jira edit.
+Use only the operations and fields in the fresh context's `guide`, current choices and stable target IDs. Choose each action by its one-line `desc` in `actions`, and use its `args` exactly. Use its version 1 envelope, current plan ID, fresh batch ID, creation timestamp and `basedOn.planRevision`. Keep change IDs stable when revising the same proposal. Each change must apply entirely or leave the plan unchanged; include exact current `prev` values. Never invent a new operation or a Jira edit.
 
 Only the assistant-owned `sightline-amendments.json` may be replaced. Serialize the complete JSON, check it fits within 512 KiB in UTF-8, with at most 100 changes and 25 operations per change, write a sibling temporary file, parse it, then atomically replace the destination where the writer supports it. If atomic replacement is unavailable, provide the complete file for deliberate manual connection; do not use a truncating write over the live file. Never overwrite context, results, chat mailboxes, the shared plan or Jira output.