@troylar/sightline 0.0.0-stage → 1.120.2

package/docs/usability-test.md

@@ -0,0 +1,215 @@
+# Sightline usability check and short role pilot
+
+Use this protocol with 2 or 3 people who have not used Sightline much: a developer, a delivery lead, and an internal
+customer or product stakeholder. Allow about 20–25 minutes each. Test reading the real plan separately from editing
+invented work. These are planned checks; no completed sessions or pilot results are recorded here.
+
+This small sample can show wrong turns and unclear language. Record timings for comparison within the session,
+not as reliable performance or usability statistics.
+
+## Four-quarter AI planning pilot
+
+Use an isolated synthetic plan and approved synthetic requests for the AI writing exercise. Follow the
+[first-session workflow](assistant-workflow.md#first-four-quarter-planning-session). Record the configured endpoint
+and model in the team's private test notes, along with Sightline version, browser and plan size; omit credentials.
+Measure assistant waiting time separately from time spent navigating, reviewing and applying.
+
+- First launch: the welcome choices appear without another navigation click. Empty Today explains that there is
+  no work to assess. Jira-linked work without status data offers a connection action.
+- Choose four exact quarters, including a year boundary. Find an outcome outside the range and recover it through
+  Long range. Confirm that changing the range did not change the plan file.
+- Keep a question draft, run Test reply, and confirm the draft remains. Simulate an unavailable companion and
+  check that the person can find recovery instructions without losing the draft.
+- Type an unsubmitted roadmap idea, open Plan with AI, visit another workspace, and return. Confirm the idea
+  remains. Switch to another plan, then back, and check that drafts stay with their own plan.
+- Open Ask assistant about this for two outcomes without typing. Working on must follow the second outcome.
+  Type a question, then choose another outcome. The existing text and context must stay until Switch context is
+  chosen. Confirm that a single Send carries the actual notes or change request with the intended selection.
+- Organize one small roadmap excerpt, review item matches and unresolved fields, apply an agreed change, confirm
+  the local save, then Undo. Repeat the request and inspect for duplicate proposals before applying anything.
+- During another request, change the plan, then inspect the stale reply. The user must understand why a new request
+  is needed; this pilot does not validate automatic rebasing or scenario branching.
+
+Proposed targets are a useful first roadmap slice within 30 minutes and a common multi-item revision within one
+minute including review. Record actual times and failure reasons. These are adoption targets, not measured
+performance claims. Human AI sessions and live endpoint timing have not been run here. The normal build, regression,
+real-browser CSP, and two-device checks remain separate.
+
+## Before each session
+
+1. Follow the [launch instructions](../README.md) to check the prepared build before the participant arrives:
+   **dist/sightline.html**, not **src/sightline.template.html**. Confirm the version beside **What's new** (in the menu at
+   the right of the header, under your initials or **Choose yourself**) and its release entries. Give the participant the normal **index.html** start page or distributed app and synthetic plan
+   file for Task 0; do not open the app for them or explain the source/build folders. Record the expected version,
+   browser, operating system, window size, and entry point.
+2. Use a separate browser profile for the session. Do not clear a person's existing site data or recovery drafts.
+   After Task 0, have the facilitator load the real plan with **File → Open a copy…** for the reading tasks. Confirm
+   the file chip says **This browser only**, with no linked shared filename. This reads the original without granting Sightline a
+   write handle to it. Do not edit or submit anything in this phase; the browser copy itself remains editable.
+3. For the reading phase after Task 0, if needed, connect the approved, existing Jira output folder through
+   **Settings → Jira connection**. Reading the files does not run a sync or contact Jira. Check their timestamp and
+   record stale or partial data rather than
+   treating it as current. Do not run the helper or change its search for this session.
+4. Choose the reading answers in advance: an open decision with its decider and due date, a person with current
+   sprint stories, and a story with a **Serves** line. If the plan lacks one, record that task as unavailable; do not
+   invent an answer or add real-plan data to make the test pass.
+5. Prepare a separate synthetic plan for each participant. Copy **test/fixtures/sample-plan.json** to an isolated
+   local test folder, or generate current synthetic demo files with the README instructions. Keep an untouched
+   baseline. Do not make a copy of the real plan for editing exercises. Pick an unfinished **Added here** task or
+   leaf initiative with no Jira key and no existing blocker; write down its name and workstream for the prompt.
+6. Have a timer and the observation table below ready. Keep real-plan observations in the team's approved location;
+   do not put real plan contents or screenshots in repository fixtures or example results.
+
+Not taking an edit lock does **not** make a linked real plan safe for this test: quick updates can save immediately.
+The detached reading phase and synthetic writing phase are intentional boundaries. Views, author stamps and the
+edit lock are not access controls.
+
+## What to say at the start
+
+> "We're testing Sightline, not you. Please think out loud: what you're looking for and what you expect to happen.
+> I won't help until you're stuck. First you'll open an invented plan, then we'll look at a reading copy of the
+> team plan. We'll use invented work for anything that saves. Tell me if you aren't sure which file you're looking
+> at or whether something is saved."
+
+Read one task at a time and start the timer after the prompt. Observe without naming the next button. After about
+90 seconds without progress, ask what they expected; give one hint only if needed and record it. A task completed
+with a hint is useful evidence, but is not an unassisted success. Stop any attempt to submit real-plan changes.
+
+## Task 0: launch and identify the app and plan
+
+> "Open Sightline and this invented plan for reading, without linking changes back to its file. Which app version
+> are you using, and how can you tell you opened the intended plan?"
+
+- **Unassisted success:** from the supplied start page or distributed app, they open the built application, read
+  the expected version beside **What's new** (in the header's menu at the right), use **File → Open a copy…** for the supplied synthetic file, and
+  identify its plan title and **This browser only** state. They finish in the built app, with no linked write handle
+  or submitted edit. Normal supplied instructions are allowed; a facilitator pointing to a file or control counts as a hint.
+- **Observe:** entry point chosen, help used, source-template confusion, version discoverability, wrong-file choices,
+  and whether the participant can distinguish the app from the plan. Record launch time and assistance separately
+  from the reading tasks. Only after recording this outcome should the facilitator prepare the real-plan reading copy.
+
+## Reading tasks: detached real plan
+
+### Task 1: what needs a decision
+
+> "Something needs a decision soon. What is it, who makes the call, and by when?"
+
+- **Done when:** they identify an open decision, its decider and needed-by date. If no decider is recorded, they
+  explicitly identify that gap rather than name an owner as the decider.
+- **Where the answer is:** Work → Today, **Decisions due**; or Delivery → Decisions.
+- **Watch for:** whether they distinguish **Decider** from **Owners**, and where they look first.
+
+### Task 2: one person's sprint work, and what it's for
+
+> "What is [person] working on this sprint, and which customer-facing deliverable does that work serve?"
+
+- **Done when:** they list that person's current stories and explain at least one **Serves** line. Record missing
+  links as a data gap, not as participant failure.
+- **Where the answer is:** Work → Sprint, with cards by person and **Serves …**. Today → Mine is another route for
+  the selected person; the menu at the right of the header (**Choose yourself**, or your initials for **You: [name]**) identifies the viewer in this browser.
+- **Watch for:** whether they find Sprint, understand the deliverable relationship, or assume author identity is verified.
+
+### Task 3: how current and complete is this
+
+> "How up to date is this? When did it last hear from Jira, and what might be left out of this view?"
+
+- **Done when:** they identify the Jira sync time, describe any partial coverage, and find at least one applicable
+  hidden-work indicator or establish that none is active. They distinguish Jira freshness from the plan's recorded
+  save time, and do not claim that either proves another computer has received the file.
+- **Where the answer is:** **Data checked** on Today and Sprint; Timeline's hidden-work information and filters.
+  A linked file's edit strip shows its locally confirmed save/revision; that strip is absent from this detached copy.
+- **Watch for:** trust without checking, confusion between a sync and a save, and mistaking hidden work for deletion.
+
+## Writing tasks: synthetic shared file only
+
+Close the real-plan reading tab before this phase. In the session profile, open the built app and choose
+**File → Open shared plan…** for the participant's synthetic file. Confirm its test filename in the chip. Choose an
+invented person with **Choose yourself**; do not add real people. Keep **Save as you go** off so the explicit
+Start editing / Save / Done editing path can be observed. Explain that Jira facts remain read-only, including in
+these exercises. If synthetic Jira files are used, connect only their matching demo folder.
+
+### Task 4: draft, navigate, then submit a blocker
+
+> "On [invented item], explain that you're blocked waiting for a test environment and who you're waiting on.
+> Before submitting it, visit another work item, then return and finish the update. How do you know it was saved?"
+
+- **Done when:** the participant opens **Mark blocked**, enters a reason and waiting-on value, visits another item,
+  and returns to the original item with both draft values intact. They submit once with **Mark blocked**, see the
+  saved blocker on that item, and confirm the test file's save/revision feedback. A second independent reader must
+  see one blocker and its corresponding update after opening or refreshing that same local test file.
+- **Observe:** navigation route, lost text or focus, duplicate submissions, mistaken edits to another item, and
+  whether they distinguish an unsent browser-session draft from a saved plan change. Drafts survive navigation in
+  this session; this task does not establish survival after closing the page.
+- **Facilitator check:** leaving an unsent draft must not change the file. Submitting a quick update can save
+  immediately without **Start editing**. If saving is refused, retained text and a clear next action are required;
+  do not count a visible draft alone as a saved result.
+
+### Task 5: edit, save, and hand off
+
+> "Change [invented item's] plan label to include 'handoff check', save it, and finish editing so the next person
+> can continue. Ask the next person to show you the label and blocker. What have you actually verified?"
+
+- **Done when:** the participant uses **Start editing**, makes the label change on the **Added here** item, uses
+  **Save**, then **Done editing**, and recognizes the local save and released editing state. No unsaved changes
+  remain. In a second independent browser profile on the same computer, the facilitator opens the same synthetic
+  file, verifies the exact label and blocker, and can start and finish an edit session without taking over a lock.
+- **Observe:** whether Save is mistaken for releasing the lock, whether the file identity and revision are checked,
+  and whether the participant understands which changes were submitted immediately versus held in an edit session.
+- **Limit:** this is a local-file handoff. It does not prove OneDrive upload, delivery to a teammate's device, or
+  concurrent editing safety. The [two-device check](onedrive.md#two-device-check-before-a-team-rollout) remains a
+  separate, **not-run** rollout requirement until someone records those results on the actual sync environment.
+
+### Optional task 6: sorting, for the plan maintainer
+
+> "Some invented stories aren't on this plan yet. Put one epic's work on the right workstream."
+
+Use the synthetic demo plan and its matching Jira files for this task.
+
+- **Done when:** the epic's work has one intended placement, without recreating its Jira facts as manual plan tasks.
+- **Where the answer is:** Work → **Sort Jira work** → **Sort them in bulk**. The Settings route also works.
+- **Watch for:** story-by-story duplication, confusion about **Not ours**, and attempts to change Jira-owned fields.
+
+## Record each session
+
+Use one row per task. Keep participant labels anonymous in any shared summary.
+
+| Task | Time | Unassisted / hint / not completed / unavailable | First routes tried | Wrong turns or lost work | How they checked correctness and saving | Confidence 1–5 |
+|---|---|---|---|---|---|---|
+| Launch 0, reading 1–3 and writing 4–5, separately | | | | | | |
+
+Record brief quotes, hints given, and the exact build and test filename. Afterward ask what was hardest to find,
+what felt unsafe or confusing, and what they would open each morning. Separate product problems from missing plan
+relationships or stale sync data; both can affect whether the workflow is useful.
+
+## Short role pilot: 3–5 working days
+
+After the sessions, invite the same three roles to try their normal reading questions each day. Read the real plan
+through the detached route above; keep any practice writes in the synthetic plan. Observe existing Jira and plan
+maintenance without changing it for this test. This can reveal reading value and likely maintenance costs; it does
+not establish the cost of sustained live collaborative editing.
+
+| Role | Daily question or action | Evidence to record |
+|---|---|---|
+| Developer | Find current work, its purpose, and a blocker or next action | Whether Sightline answers a question faster or requires another search; where status or notes would need entering twice |
+| Delivery lead | Explain attention, ownership, and the next handoff | Minutes spent checking freshness, sorting work, maintaining plan-only relationships, or correcting duplication |
+| Internal customer / product stakeholder | Understand deliverables, dates, and approved wording | Whether the answer is understandable without a guide, useful for a decision, and traceable to the relevant work |
+
+Keep one small daily log: role, question, answer found, help needed, time spent reading, time spent maintaining the
+plan, and any duplicated entry. Name the fields involved and their intended owner: Jira facts stay in Jira; plan
+placement, dependencies and notes stay in Sightline. Record repeated requests to copy a Jira title, status, assignee
+or date into a manual item as a workflow problem, not as a recommended workaround. Count one-off setup separately
+from recurring maintenance; count time spent by the maintainer as well as time saved by readers. Mark estimates or
+practice observations as such rather than presenting them as live-use measurements.
+
+At the end, review these concrete criteria together:
+
+- Each role can answer its daily question without a facilitator on the final two days; unavailable data is recorded.
+- Every attempted synthetic draft and save remains on its intended item, with no lost text or duplicate submission.
+- The local handoff ends with the intended file values and a released lock; cloud validation is still reported separately.
+- Before the pilot, agree an acceptable recurring maintenance budget in minutes per day; report actual or estimated
+  time against it and identify who would own that work. No hidden setup effort is counted as zero maintenance.
+- Identify each recurring duplicated entry, its frequency and cause. Do not expand rollout until the team accepts
+  the remaining burden or removes the duplicated step.
+
+Report **proceed**, **revise**, or **insufficient evidence**, with task results, pilot notes and unrun checks. A small
+pilot is a decision aid, not a claim that the product or OneDrive behavior has been broadly validated.

package/docs/workspace-validation.md

@@ -0,0 +1,152 @@
+# Workspace and assistant validation
+
+The version 1.86.0 changes preserve the offline HTML application and plan schema. Synthetic plans are used throughout validation.
+
+## Automated checks
+
+Version 1.86.0 passed **2,322 checks across 102 suites** on October 8, 2026. Run `./build.sh` and `./test/run.sh` to repeat the checks. The runner includes all browser-model harnesses, build validation and the Python Jira-sync tests. New checks cover saved source layers, contextual controls, group navigation, keyboard access, Settings memory, structural-field disclosures, release-note routing, timing labels, automatic assistant context/results, edit-safe refresh, permission loss and plan switches.
+
+The saved-layer checks fail on the original build. The unchanged-export and closed-editor checks fail before their fixes. The Roadmap empty-section regression also fails on the original build. Existing report checks use a fixed fixture date so passing does not depend on today's calendar date; their status, frozen-copy and export assertions remain.
+
+## Real browsers
+
+Firefox smoke checks confirmed the primary destinations, Status update's whole-plan scope, Product updates' release list, final navigation labels and a visible explanatory failure when altered JavaScript is blocked by CSP.
+
+Chrome Incognito completed a real browser File System Access round trip:
+
+1. Connected a new empty synthetic assistant folder and allowed access only to it.
+2. Confirmed Sightline created context and results, leaving the proposal file absent.
+3. Wrote a synthetic amendments file atomically using the exported plan ID and revision.
+4. Observed automatic detection while navigating to Work, without a manual refresh.
+5. Reviewed and applied the capability in Sightline.
+6. Confirmed it appeared in Product updates and in the refreshed context; results recorded `applied`.
+7. Confirmed ordinary navigation and polling left context/results modification times unchanged.
+
+The Chrome smoke used a browser-local synthetic plan. Confirmed shared-file sourcing, dirty shared edits, reconnection and race cases are covered by API mocks; this smoke does not prove every operating-system or sync-service permission behavior. Audience usability still needs the short [human check](usability-test.md).
+
+## Performance
+
+The [benchmark](performance-workspaces.md) records synthetic JavaScript/DOM costs. It does not measure real-browser layout or input latency. The new navigation caches stable controls, and unchanged assistant context is neither reconstructed nor written. Existing large-Jira checks remain in the full suite. Further large-plan optimization should use real-browser profiles, particularly for hidden chart rendering and shared DOM decoration.
+
+
+## OneDrive follow-up: version 1.87.0
+
+Version 1.87.0 passed **2,372/2,372 checks across 104 suites** on October 8, 2026, after a fresh build. The original checkout remains unchanged. This change touches shared-plan file operations and viewer preferences; it adds no plan schema fields or Jira write access.
+
+`harness102` passed **43/43**: default and opted-out checking, foreground checks, typing begun during a pending read, invalid or moved files, read-only recovery previews, plan identity and calendar validation, stale reviews, permission and dialog cancellation, guarded lock cleanup, crossing saves, deliberate Save, and failed new-file creation. The preceding build fails the new behavior checks. `harness103` passed **7/7**: unchanged shared-file checks update freshness with zero full renders, assistant reconstructions or output writes; an arriving revision refreshes the plan and each output once. Existing `harness4` passed **404/404**, build checks **19/19**, and Jira-sync checks **206/206**.
+
+Firefox executed the final build and showed the explanatory startup failure for an altered-script copy blocked by CSP. Chrome displayed the final release, but native automation did not complete the file picker, so this release's recovery flow has not been verified through a live browser file round trip. API mock checks do not establish operating-system file-provider or cloud synchronization behavior.
+
+No OneDrive installation or second-device test environment was available. The [OneDrive setup and two-device checklist](onedrive.md) records seven live cases as **Not run**, including actual sync delays, offline reconnection, file replacement and conflict copies. A local save remains distinct from OneDrive upload completion.
+
+<details>
+<summary>Version 1.87.0 per-suite results</summary>
+
+```text
+harness2   25/25 passed
+  harness3   15/15 passed
+  harness4   404/404 passed
+  harness5   10/10 passed
+  harness6   95/95 passed
+  harness7   46/46 passed
+  harness8   50/50 passed
+  harness9   44/44 passed
+  harness10  38/38 passed
+  harness11  56/56 passed
+  harness12  37/37 passed
+  harness13  27/27 passed
+  harness14  20/20 passed
+  harness15  35/35 passed
+  harness16  36/36 passed
+  harness17  35/35 passed
+  harness18  16/16 passed
+  harness19  44/44 passed
+  harness20  9/9 passed
+  harness21  16/16 passed
+  harness22  11/11 passed
+  harness23  12/12 passed
+  harness24  16/16 passed
+  harness25  17/17 passed
+  harness26  23/23 passed
+  harness27  7/7 passed
+  harness28  13/13 passed
+  harness29  20/20 passed
+  harness30  16/16 passed
+  harness31  14/14 passed
+  harness32  10/10 passed
+  harness33  14/14 passed
+  harness34  8/8 passed
+  harness35  14/14 passed
+  harness36  22/22 passed
+  harness37  16/16 passed
+  harness38  15/15 passed
+  harness39  25/25 passed
+  harness40  21/21 passed
+  harness41  15/15 passed
+  harness42  9/9 passed
+  harness43  12/12 passed
+  harness44  14/14 passed
+  harness45  5/5 passed
+  harness46  7/7 passed
+  harness47  9/9 passed
+  harness48  9/9 passed
+  harness49  8/8 passed
+  harness50  8/8 passed
+  harness51  8/8 passed
+  harness52  11/11 passed
+  harness53  17/17 passed
+  harness54  10/10 passed
+  harness55  8/8 passed
+  harness56  21/21 passed
+  harness57  15/15 passed
+  harness58  18/18 passed
+  harness59  12/12 passed
+  harness60  10/10 passed
+  harness61  11/11 passed
+  harness62  23/23 passed
+  harness63  6/6 passed
+  harness64  12/12 passed
+  harness65  4/4 passed
+  harness66  7/7 passed
+  harness67  20/20 passed
+  harness68  18/18 passed
+  harness69  5/5 passed
+  harness70  10/10 passed
+  harness71  17/17 passed
+  harness72  21/21 passed
+  harness73  9/9 passed
+  harness74  3/3 passed
+  harness75  8/8 passed
+  harness76  8/8 passed
+  harness77  16/16 passed
+  harness78  12/12 passed
+  harness79  12/12 passed
+  harness80  11/11 passed
+  harness81  12/12 passed
+  harness82  10/10 passed
+  harness83  10/10 passed
+  harness84  9/9 passed
+  harness85  6/6 passed
+  harness86  9/9 passed
+  harness87  8/8 passed
+  harness88  7/7 passed
+  harness89  15/15 passed
+  harness90  4/4 passed
+  harness91  7/7 passed
+  harness92  9/9 passed
+  harness93  6/6 passed
+  harness94  11/11 passed
+  harness95  7/7 passed
+  harness96  12/12 passed
+  harness97  17/17 passed
+  harness98  12/12 passed
+  harness99  61/61 passed
+  harness100 36/36 passed
+  harness101 18/18 passed
+  harness102 43/43 passed
+  harness103 7/7 passed
+  build      19/19 passed
+  jira-sync  206/206 passed
+```
+
+</details>

package/docs/workspaces.md

@@ -0,0 +1,105 @@
+# Find your work in Sightline
+
+Start with the [launch instructions](../README.md#try-it-with-an-invented-team-plan): open **dist/sightline.html** in Chrome or Edge, then open the separate
+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:
+
+- **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.
+- **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
+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.
+
+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.
+
+## Declutter: hide what you don't need
+
+**Show** (in the Timeline toolbar, or press H) has an eye for each kind of item: Gates, Releases, Deliverables, Meetings, Process blocks, Milestones and Done work. Click one, or press its letter while the menu is open, to hide or show it. Hiding works on Timeline, List and Capacity's People page. Today and Sprint always show everything.
+
+- **Keys:** G hides or shows gates and M meetings, on those pages. Shift+H shows everything.
+- **Focus** hides meetings, process blocks and done work in one click.
+- **Hide all meetings** (or gates, process blocks, releases, milestones) is in the details of any one of them.
+- **Pin the top rows** keeps the Gates, Releases, Deliverables, Team meetings and Process rows in view under the dates while you scroll the workstreams, up to half the chart's height.
+- Under the toolbar, "3 hidden: meetings, process blocks, done work" names what's hidden, with **Show everything**. The Show button says how many.
+- In **Filters**, each kind cycles: Show only, Hide, off. Hide wins over Show only. Clear filters also shows everything.
+- What you hide is yours: it stays in this browser for each plan, and a saved view keeps its own choice. Find brings a hidden kind back when the result is one of them. Nothing is changed in the plan file.
+
+## 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.
+
+- **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.
+- **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.
+- **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.
+- **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.
+
+Roadmap starts with **Four quarters**. Choose the starting calendar quarter (including its year); this is a target
+window, not a commitment. The choice stays in your browser. **Long range** restores the broader quarters, halves,
+years, and Later view. Work outside the four-quarter window is counted; **Show in long range** reveals it without
+moving or deleting it. Done and dropped counts still have their own show controls. Broad targets span the quarters
+they overlap. Fiscal calendars are not configured by this view.
+
+Choose **Plan with AI** to select the displayed quarters, or open an outcome and choose **Ask assistant about this**.
+The **Planning assistant** shows **Working on** above the composer. Paste notes or describe a change, then **Send**
+once. These actions do not send or apply anything on their own. An untouched generated starter follows a new
+selection. A question you have written keeps its original selection; **Switch context** deliberately changes that
+selection while keeping your text. **Test reply** checks for a response, and **Connection and setup**, under **Setup and files** at the end of the panel, holds detailed
+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
+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.
+
+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.
+
+**Text size** makes the page's text larger or smaller without browser zoom: **A+** and **A−** move in 10% steps from 90% to 150%, and **Reset** goes back to 100%. Text never goes below 9 pixels. The setting stays in this browser and never goes in the plan. There's no keyboard shortcut, so Ctrl or Cmd with + and − still zoom the whole browser.
+
+**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.
+
+**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.
+
+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.
+
+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.
+
+**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
+context. Unsaved editor drafts stay in this tab's session and are excluded from exports. See the
+[planning guide instructions](assistant-workflow.md#give-the-assistant-project-context) for source and compatibility details.
+
+Use the [usability check and 3–5 day role pilot](usability-test.md) with a developer, a delivery lead and an internal
+customer before treating the navigation as validated for your team. Read a detached copy of the real plan; use only
+invented data for draft, save and handoff exercises. Record the maintainer's recurring effort and any duplicated
+entry as well as whether readers find answers. The protocol and pilot have not been run here.
+
+Quick updates can save immediately without **Start editing**. For reading-only evaluation of a real plan, use
+**File → Open a copy…**, confirm **This browser only**, and do not edit or submit changes. The browser copy remains
+editable, but this route does not link writes to the original file. Use **Open shared plan…** for the separate
+synthetic save/handoff exercise. A local save or handoff does not verify cloud delivery; the
+[OneDrive two-device check](onedrive.md#two-device-check-before-a-team-rollout) remains separate and not run.
+
+For the meeting workflow, use [team planning](team-planning.md). To work through a large backlog with your external assistant, use [large roadmaps](large-roadmaps.md).

package/examples/northstar/blank-plan.json

@@ -0,0 +1,21 @@
+{
+  "meta": {
+    "title": "My team plan",
+    "start": "2026-10-19",
+    "weeks": 52,
+    "sprintWeeks": 2,
+    "firstSprint": 0
+  },
+  "lanes": [
+    {
+      "id": "team",
+      "name": "Team work",
+      "who": "",
+      "color": "#2c6fbb"
+    }
+  ],
+  "people": [],
+  "bars": [],
+  "deliverables": [],
+  "notes": []
+}

package/examples/northstar/brain-dump.txt

@@ -0,0 +1 @@
+Bring customer context forward to Q1 2027. Explore offline search too, but keep it as an idea with no owner or date. Leave the rest of the roadmap as it is.