# Sundial User Manual

*A practical guide to shared project editing, task tracking, sprint planning, delivery forecasting, and diagram-based reporting. Updated against the source, specifications, and running application on 18 October 2026; sign-in and privacy guidance updated on 22 October 2026.*

<div class="wp-block-buttons"><div class="wp-block-button"><a class="wp-block-button__link wp-element-button" href="https://tommesani.com/sundial/">Try Sundial</a></div></div>

Open Sundial in a large desktop window and click **Example** to explore the demonstration project, team, and active sprint. If the active snapshot store is empty, Example also creates the demonstration reporting snapshots.

## 1. What Sundial does

Sundial is a project management application for organizing work, managing a team, running sprints, and forecasting delivery. The shared workspace and delivery simulator use the same work and staffing data. It helps project managers, technical leads, and contributors answer:

- What work belongs to the project, who owns it, and what is blocked or complete?
- What work belongs in the next sprint, and how does its remaining effort compare with available capacity?
- When can each initiative, epic, story, or task finish under the declared assumptions?
- How have scope, status, and forecast dates changed since an earlier checkpoint?
- What happens to delivery if a team member leaves or an additional person joins?

In the browser, you can edit **Project** and **Team** through forms, track work in **Kanban**, and plan **Sprints**. You can define workflow states and allowed transitions, write descriptions and acceptance criteria, add comments, set inherited priorities, record effort, and choose the order of work. For planning and review, you can use ten diagram views, capture reporting snapshots, import existing work, and export images. Project and Team are kept together in one native .sundial folder. Committed edits save automatically and can synchronize with other users opening that folder.

Sundial takes a privacy-first approach: it processes project data in your browser and keeps it in a project folder you choose, with browser storage for recovery. Your team can collaborate through a shared folder without uploading project information to an external collaboration service. Your organization's filesystem permissions control who can access that folder. Loading the application and looking up public holidays can still require network requests. The section on working together through a shared project folder explains storage, access, and backups in more detail.

The simulator uses estimates, recorded effort, dependencies, start constraints, deadlines, assignees, skills, working hours, availability overrides, weekends, and holidays. Kanban and Sprints update this model and share its task list.

You can create and manage a project entirely in Sundial. No external tracker is required. Sprint planning includes capacity, scope, completion, carryover, and historical boards. Sprint burndown, velocity, and cumulative-flow reports are not currently provided.

### What a forecast means

Each ordinary forecast uses one set of declared assumptions. With the same model, calendars, and effective forecast start, Sundial produces the same schedule. The Monte Carlo tab repeatedly samples effort estimates to show completion-date distributions. Both use the same scheduling priorities and resource constraints; neither searches for an optimal plan. Their dates depend on credible inputs.

**Disclaimer:** Project timelines and delivery dates estimated by Sundial are indicative only and are not guarantees. The author accepts no responsibility for errors, omissions, delays, losses, or other consequences arising from these estimates or reliance on them, whether caused by software defects, inaccurate or incomplete data, planning assumptions, or any other cause. Review the estimates independently before using them to make commitments or decisions.

The approach follows the workflow-simulation method described in Stefano Tommesani's article on [day-by-day project forecasting](https://tommesani.com/day-by-day-forecasting-project-completion-through-work-flow-simulation/).

## 2. Quick start: explore the example

1. Open [Sundial](https://tommesani.com/sundial/). For a local development build, use `http://localhost:5173/`.
2. Maximize the browser window. Detailed forms and diagrams need a large desktop workspace.
3. Click **Example**. Resolve any pending draft or replacement confirmation first. This loads the supplied Apollo project and team, plus an active example sprint and a planned next sprint. In an empty active reporting snapshot store, it also creates the demonstration July and August checkpoints.
4. Wait for **Ready**. Open **Project** to explore the hierarchy; click a work-item name to inspect its fields.
5. Open **Team** and choose a developer to review hours, skills, access, and calendars. Cancel any experimental draft you do not want to apply.
6. Open **Kanban** to see status columns, or **Sprints** to see the example sprint and developer capacity.
7. Open **Diagrams**. Charts use the full workspace. Close any work-item editor before reviewing the whole drawing. Review **Delivery outlook**, then **WBS**, **GANTT**, **Sunburst**, and **Work tracker**.
8. Choose a saved baseline in **WBS over time** or **GANTT over time**, leaving **with** at **Now** for a live comparison.
9. In **Sunburst over time**, select the July and August snapshots to compare them with Current. Review **Scope** and both **Timeline** and **Scope** presentations in **Milestones**, then try **Team what-if**. Use **Reset** to restore a staffing scenario after experimenting.

The example includes a work hierarchy, estimates, dependencies, team calendars, sprint membership, and comparison history. Live forecasts start from today unless the project has a later configured start. Example deadlines, the Public beta milestone, and sprint dates move with the date the example loads; historical checkpoints keep their saved dates. Your results can differ from the screenshots. An untouched demo is regenerated fresh on a later visit; use New or Open for your own project.

![Current Sundial Project workspace showing the native project folder toolbar, hierarchy, search, and task totals](screenshots/30-project.jpg)

*Figure 1. Project and Team are views of the same native project. The toolbar shows New, Open, Workflow settings, the project folder name, and Undo/Redo; the table includes inherited priority and navigation links.*

## 3. Work together through a shared project folder

Several people can edit the same Sundial project through a shared folder. Work items, the team roster, calendars, and sprint plans stay in a native .sundial folder on your filesystem. Each person opens that folder in their own browser. Sundial saves committed edits automatically and exchanges them through the folder, so your team can work together without uploading critical project information to an external collaboration service.

Choose a mounted network share where everyone has read/write access. Your organization's filesystem permissions control access to the project. Sundial needs no central collaboration server or account database, and users can edit without taking an exclusive lock.

### Start a shared project

1. Open Sundial in **Chrome or Edge** at the application's secure address; the local development address is `http://localhost:5173/`.
2. In **Project**, choose **New**, enter the project name and key, and select an empty parent folder where the new project should live. Grant the browser access to that folder when prompted. Sundial rejects folders that already contain files or subfolders.
3. Sundial creates a **Project Name.sundial** subfolder using your project name, without a UUID. This is the folder your colleagues must open.
4. Build the work hierarchy in **Project** and maintain the roster in **Team**. Use **Apply** or **Apply changes** to commit form drafts. Committed edits save automatically.
5. Make the folder available through your organization's shared filesystem, with read/write access for each collaborator.
6. Each colleague opens Sundial, chooses **Project → Open** or **Team → Open**, and selects that **same .sundial folder**. Opening it loads both Project and Team.
7. Check the displayed folder name and review any save or collaboration notices before starting work.

Separate copies on different machines will not exchange edits on their own. Each instance needs access to the same shared container, or a filesystem mechanism that delivers the complete folder contents between machines.

### What happens when two people edit

Applied changes to different tasks or different fields normally merge automatically. For example, one person can revise Billing engine's estimate while another updates Bruno's availability. Sundial records each edit in its native history and picks up changes from the shared folder, normally checking every two seconds. The network share may take longer to deliver them.

Unapplied form drafts remain local. If another committed change makes a draft stale, **Reload draft** brings in the current document before you edit again. Review your intended changes and re-enter them against that version.

If two people independently change the same field, Sundial keeps both values and reports a collaboration issue. Their browsers can agree on the shared document while the team still needs to decide which value to use. This behavior is based on [Automerge's handling of concurrent values](https://automerge.org/docs/reference/documents/conflicts/).

### Review a conflict

1. Open **Diagrams**, choose **Show details** in Delivery outlook, and expand warnings when diagnostics are present.
2. Read the entity, field, and alternative values. A **ConcurrentFieldWrite** means multiple values were written concurrently; **ModifiedAfterDelete** or **ConcurrentDeleteRestore** requires a decision about the item's deletion or restoration.
3. Find the affected task in **Project**, or developer/calendar in **Team**. Review the current committed value with the people involved.
4. After the remote changes have arrived, intentionally apply the agreed value. A subsequent write based on the observed alternatives resolves a field conflict; do not repeatedly alternate values without coordinating.
5. Recheck the reported issues and the forecast. Also correct dependency cycles, missing references, or other validation problems exposed by the merged edits.

Deleted tasks remain recoverable. If the team decides to restore one, use **Deleted tasks → Restore** in Project. Restoration keeps the original identity, so later edits and history continue to refer to the same item.

### Privacy, backups, and interruptions

Sundial processes project data in the browser and stores it in your chosen project folder and browser recovery storage. Collaboration does not send it to a Sundial project backend. Network requests can still occur: you need to load the application, public-holiday lookups can contact a holiday service, and sign-in contacts Firebase Authentication and Google.

You can view projects without signing in. To make changes, choose **Login** at the top-right and then **Continue with Google**. Firebase Authentication manages the sign-in session; Google identifies the current editor. Project contents, filenames, work items, and estimates are not sent to either service. Signing in does not upload your project or grant access to shared files: your organization's filesystem permissions still control access.

Leave **Remember me on this device** unchecked for a browser-session sign-in, or check it to stay signed in on that device. Signing out keeps your open project and drafts. After signing in again, submit a pending change yourself; Sundial does not replay it automatically. Sundial normally refreshes your session automatically. If it cannot refresh before expiry, editing pauses while viewing remains available. Editing resumes after a successful refresh or sign-in; submit any rejected change again yourself. If browser storage is blocked, sign-in uses memory only and does not survive reload.

![Unlock editing dialog with Continue with Google and the Remember me persistence choice.](screenshots/68-login-2026-10-22.jpg)

*Figure 2. Unlock editing dialog with Continue with Google and the Remember me persistence choice.*

Back up the entire .sundial folder, including its manifest, changes, snapshots, and readiness markers. Keep the internal files intact and retain the change history; copying a single file is not enough. Native startup snapshots help Sundial reopen efficiently. The dated checkpoints created with **Snapshot** are for reporting.

If a save fails, keep the browser session open, restore access to the share, and use the save notice's **Retry** action. Browser recovery restores the working native document after a crash or tab reopen. Sundial remembers its folder and resumes saving when browser permission allows. If the folder is not connected, a visible notice says that changes are not being saved to disk. Use **Reconnect project folder** and select the original **.sundial** folder. Sundial verifies its identity and merges recovered edits with the current disk history. Review Issues after reconnecting. A project using a newer unsupported format requires a compatible application version; do not try to repair it by editing internal files.

## 4. Find your way around the workspace

### Main workspaces

| Tab | Purpose |
| --- | --- |
| Project | Build the work hierarchy; edit descriptions, acceptance criteria, comments, priorities, dependencies, effort, assignees, dates, milestones, sprint membership, and workflow settings. |
| Team | Maintain developers, capacity, skills, access, locations, and calendars. |
| Kanban | Review actionable work by status, developer, or epic; move cards and open their task forms. |
| Sprints | Plan scope, review developer capacity, start a sprint, and complete it with a checkpoint. |
| Diagrams | Review the eleven current, comparison, history, and staffing views, including Sunburst over time. |

The Project and Team toolbars have **New**, **Open**, the native project folder name, **Undo**, and **Redo**. Use the forms to edit and apply changes. Sundial saves them automatically; there are no separate Save buttons.

### Application header

| Control | Purpose |
| --- | --- |
| Login / account | Identify yourself to unlock editing; after sign-in, your avatar and name open the account menu with Sign out. Read-only means viewing is available but changes require sign-in. |
| Example | Load demonstration work, team, an active sprint, and a planned next sprint; seed reporting history only when the active store is empty. |
| Snapshot | Capture the committed Project and Team as a dated reporting checkpoint after resolving pending drafts. |
| History | Browse reporting checkpoints, load one, select a comparison baseline, or manage snapshot storage. |
| Import | Bring existing work into the project from a supported offline export. |
| Export | Download the committed current project as a YAML inspection file, without reporting snapshots or native history. |
| Export SVG / Export PNG | Save available diagrams together in a ZIP archive. |
| Ready / Simulating… / error state | Check whether the current model has been processed successfully. |

The header also links to the main website, this user manual, and the contact page. Contextual help icons beside workspaces and diagram controls open the relevant manual section in a new tab.

### Diagrams, Delivery outlook, and Issues

![Redesigned WBS using the expanded Example hierarchy, assignee labels, and Goal and Late goal borders.](screenshots/45-wbs-2026-10-22.jpg)

*Figure 3. Redesigned WBS using the expanded Example hierarchy, assignee labels, and Goal and Late goal borders.*

Choose **Diagrams**, then the required diagram tab. Use a large window for viewing and captures. **Hide details** in Delivery outlook reduces the summary's height when more chart space is needed.

Delivery outlook puts the most delayed initiatives first and shows predicted delivery, declared deadline, and slip in calendar days. Its compact summary reports the largest forecast delay. **On time** means an initiative has a forecast finish on or before its deadline. **Forecast through …** shows the last day simulated; it does not mark tasks Done. An **Unfinished** label or a count of work items without a forecast means some work still has no delivery date. A missing estimate, blocked prerequisite, or unavailable capacity needs investigation even if other initiatives have dates.

Sundial refreshes the forecast when you apply a valid edit, so there is no Run button. While you enter a draft, the forecast still uses the committed model. Choose **Show details** in Delivery outlook to read errors, expand its warnings list, and resolve the reported issues before using the result. After a failed update, some diagrams keep the last successful result and show an error or stale-state indicator.

## 5. Open, create, and preserve a native project

### One container for Project and Team

A .sundial project folder holds the native collaboration document and history for work items, developers, calendars, sprints, and related model data. Project and Team have separate editing screens, but their data and collaboration history are stored together. There is no pair of editable YAML files to maintain.

Use Chrome or Edge with directory access on a secure application origin or localhost. **Open** asks for a directory: select the actual .sundial container, not its parent, an individual change file, or a reporting snapshot. Opening through either Project or Team loads both halves.

Sundial cannot open or migrate legacy Project/Team YAML files through native Open. Reporting snapshots and optional import mappings are separate files with their own uses; neither is a native project folder.

### Create a project

1. In **Project**, choose **New** and resolve any pending draft or replacement notice.
2. Enter **Project name** and **Project key** in **Create project**. The key uses 2 to 10 letters or digits and starts with a letter; Sundial normalizes it to uppercase. Choose it carefully because it locks once the first work item is allocated.
3. Choose **Create**, select an empty parent directory, and allow the browser to write there. The directory must contain no files or subfolders.
4. Sundial creates a **Project Name.sundial** subfolder with a new Project root and a reporting period beginning today. The currently available Team is used for the new project; review it before estimating capacity.
5. Click the root's name to edit it, then use the hierarchy controls to add work.
6. Open Team, review developers and calendars, and apply needed changes.
7. Verify save notices and a successful forecast. Retain the actual folder path for reopening or sharing.

![Current Create project dialog with Project name and Project key fields.](screenshots/64-create-project-2026-10-22.jpg)

*Figure 4. Current Create project dialog with Project name and Project key fields.*

Choosing **New** in Team replaces the current project's roster and calendars. It does not create a separately saved Team file.

### Automatic saving and recovery

Applying Project or Team forms, changing Kanban status, editing sprint plans, and Undo/Redo commit native changes and trigger saving. There is no separate disk-save step for each tab. Plain **Ctrl+S** does not apply a draft or create a reporting checkpoint; use Apply to commit and **Snapshot** for a reporting baseline.

If a new, disconnected model first needs saving, Sundial may ask for a parent directory. A recovered project instead needs its original folder: use **Reconnect project folder** and select the matching .sundial container. Sundial checks its identity before merging browser edits with disk history. It tries to restore a remembered folder connection automatically when permission allows. Check save notices; the displayed folder name alone does not confirm that the latest edit reached disk.

Browser recovery restores the working native document after a crash or tab reopen. Sundial remembers its folder and resumes saving when browser permission allows. If it is disconnected, use **Reconnect project folder** and select the original **.sundial** folder. Recovery and connection to the shared folder remain separate; check the save notice before relying on disk persistence.

Synchronization health is separate from local recovery. A share can be temporarily unavailable while edits remain in the browser. Sundial retries transient synchronization failures; use **Retry synchronization** after restoring access and review the remaining notices. Successful recovery does not prove that other users have received the edits.

Browser recovery belongs to the current browser profile and application origin. Clearing site data can remove it. Back up the complete native folder for a durable copy you can move between machines. Reporting snapshots are additional checkpoints and do not preserve the native collaboration history.

## 6. Edit Project work with structured forms

### Browse the hierarchy

Open **Project** to see the work-item table. Use **Search work items**, **Tasks only**, **Expand all**, **Collapse all**, and individual disclosure arrows to find the relevant work. The table shows status, effective priority, assignee, estimated and spent hours, deadlines, completion dates, dependencies, sprint links, and color-coded skill labels. An inherited priority has a small arrow beside it. Parent effort and status roll up from descendants.

Work items also have project issue keys, such as **APL-13**. Keys appear in editors, Kanban cards, sprint lists, and developer assignments; search can use them to find work. They are separate from hierarchy positions and imported source references. Renaming or moving an item preserves its native identity. Concurrent issue creation can trigger a visible renumbering notice when number collisions are reconciled; use the updated key after synchronization.

For a quick estimate change, edit a leaf's **Most likely effort (hours)** cell directly in the Project table. Press **Enter** or leave the field to validate and save; **Escape** cancels the edit. An empty field removes the estimate. Invalid input stays available for correction. Parent totals are derived and cannot be edited this way. Close the work-item editor before editing a table estimate, resolving any pending draft first.

The usual hierarchy is **Project → Initiative → Epic → Story → Task**. Some diagram specifications call initiatives Releases. A story without children can carry its own estimate. Once an item has children, it rolls up their work and has no separate estimate.

### Edit a task

![Schedule tab with optimistic, most likely, and pessimistic effort inputs and the PERT expected total.](screenshots/33-work-item-schedule-2026-10-22.jpg)

*Figure 5. Schedule tab with optimistic, most likely, and pessimistic effort inputs and the PERT expected total.*

1. Click the task's name in the table or open its card from Kanban.
2. Edit **Name**, **Status**, and **Priority** above the tabs. Status choices include the current state and its allowed next states; priority can be explicit or inherited. Container status is derived from children.
3. Open the **Description** tab to write **Description** and **Acceptance criteria**. Use the description for context, requirements, and implementation notes. Use acceptance criteria to describe the observable conditions for calling the work complete. Both accept Markdown. Use **Preview** to check the formatted result and **Edit** to return to the text. Raw HTML shows as plain text and never runs.
4. Open the **Schedule** tab for the planning fields: **Deadline**, start and completion dates, **Sprint**, **Issue link**, **Assignee**, **Most likely effort (hours)**, recorded effort, dependencies, skills, and **Parent work item**. Set **Most likely effort (hours)** to the total estimate. With no separate bounds, a 24-hour task with 16 hours spent has eight hours remaining.
5. Click **Apply**. If validation fails, correct the highlighted errors and apply again. A failed Apply opens the tab containing the first error. Wait for the forecast to refresh.

**Cancel** discards the current draft. Switching tabs never discards it. Undo reverses a committed edit; cancelling a form after an earlier Apply does not undo it. If Project or Team changed underneath the draft, use **Reload draft** and review the newer model before entering changes again.

The **Audit** tab, after **Schedule**, shows committed changes to this work item, most recent first. Each action shows who made it, the editor's local date and time with its UTC offset, and the previous and new field values. Search the history by person, field, or value. Unsaved drafts and rejected edits do not appear. Undo and redo add new actions while preserving the earlier history. Existing projects start collecting history when auditing is enabled; older changes are not reconstructed.

![Work-item Audit tab with search and an empty-history notice on the fresh Example.](screenshots/66-work-item-audit-2026-10-22.jpg)

*Figure 6. Work-item Audit tab with search and an empty-history notice on the fresh Example.*

Descriptions and acceptance criteria are available for every work item type, including initiatives, epics, and the project itself. These fields are stored with the work item in the native project and are shared with people who open that folder. Acceptance criteria provide written guidance. Marking Done does not run tests or ask you to confirm an acceptance checklist.

![Login page Description and Acceptance criteria in the current work-item inspector.](screenshots/31-work-item-description-2026-10-22.jpg)

*Figure 7. Login page Description and Acceptance criteria in the current work-item inspector.*

Use the **Comments** tab to keep findings and decisions with the work item:

1. Enter Markdown in **New comment**. Use **Preview** to check the result.
2. Choose **Add comment** to append it to the current draft and clear the input.
3. Repeat for further comments, then choose **Apply** to persist them. Text left in New comment must be added or cleared before Apply succeeds.
4. Choose **Cancel** to discard unapplied additions.

Comments appear oldest first with their creation time. Sundial stores a UTC timestamp and displays an explicit local date and time. Comments are append-only; there are no author fields, mentions, edit controls, or delete controls. They do not change status, scheduling, or acceptance criteria. Concurrent additions merge without replacing each other. Undo can reverse an addition, and Redo restores it. Comments are retained in native storage, recovery, reporting snapshots, and current-project exports.

![An unapplied Markdown comment in the work-item Comments tab; the demonstration draft was discarded.](screenshots/60-comments-2026-10-22.jpg)

*Figure 8. An unapplied Markdown comment in the work-item Comments tab; the demonstration draft was discarded.*

### Record effort and status

**Spent effort (hours)** is an aggregate display. **Recorded effort** can show an existing starting balance as well as dated entries. To record new work, choose **Spent by**, set **Spent date**, enter **Add spent effort (hours)**, choose **Add spent entry**, then Apply the form. The date and developer identify the entry for later review. These entries are separate from Work tracker's simulated allocations.

Moving an item into a state in the **Done** category sets its completion date automatically. Leaving the Backlog category can set a missing start date automatically. Handoffs between detailed states in the same category preserve lifecycle dates. Done is terminal: normal editing cannot reopen completed work. Use **Undo** to reverse a mistaken completion while that edit remains in undo history. Review the dates when updating historical work. If a completion requires moving the reporting start forward, review the proposed reporting-date adjustment before applying. Completion and Undo retain recorded effort history.

Parent status summarizes the descendants. An ordinary Blocked state leaves the work unfinished and prevents future allocation to that item. A canceled state has a separate terminal outcome; its consequences are described in the workflow guide. Check dependencies before relying on downstream delivery dates.

### Dependencies, dates, and constraints

Under **Assignment and effort**, enter **Optimistic**, **Most likely**, and **Pessimistic** total effort in hours. Missing bounds default to the most likely estimate. The ordinary forecast uses PERT expected effort: (optimistic + 4 × most likely + pessimistic) / 6. For the new Example's Login page, 15, 20, and 24 hours give 19.83 expected hours; after 8 hours spent, the expected remainder is 11.83 hours. Monte Carlo samples the same declared bounds rather than treating the ordinary expected date as a percentile.

| Control or concept | Meaning |
| --- | --- |
| Depends on | Prerequisites that must finish before this work can start. Use **+ Add dependency** and the picker; remove an incorrect prerequisite before applying. Ancestor prerequisites can constrain descendant work. |
| Start date | Earliest pickup date for unfinished work, or historical start for completed work. |
| Completion date | Historical completion, set automatically when marking Done. It is different from a forecast finish. |
| Deadline | Need-by date. Parent deadlines also constrain descendants; the earliest applicable deadline wins. |
| Required skills | Task requirements plus inherited parent requirements. Team skills determine scheduling eligibility. |
| Sprint | Membership independent of status. Choose a planned or active sprint for eligible work; canceled work cannot be newly assigned. |

The dependency picker excludes the item itself, its ancestors and descendants, and choices that would create a cycle. This includes deadlocks involving parent prerequisites and child completion. Apply checks dependencies again against the current project, so a stale picker cannot bypass validation.

An assignee pins work to a particular developer: only that developer contributes to the item during simulation. Unassigned leaf items that fit within two weeks of an average team member's working hours also stay with one developer, chosen at their first simulated pickup. The size threshold is the team's average baseline hours per day multiplied by ten working days; for an eight-hour team, that is 80 hours. It uses the full expected estimate and ignores speed, holidays, availability overrides, and assigned sprint dates. This simulated ownership does not change the saved assignee. Larger unassigned items can receive contributions from multiple eligible developers on the same day, even when their remaining effort falls below the threshold. Each developer uses their own available capacity and speed to reduce the item's shared remaining effort; the estimate remains total person-hours. Eligibility and allocation depend on skills, project access, dependencies, calendars, and each developer's concurrent-work limit.

For a large story that has not yet been refined, leave it unassigned if the forecast should allow several developers to contribute. The simulator assumes their contributions can be combined without a coordination penalty. If some work must happen sequentially, refine the story into child items with dependencies to represent those constraints. A missing estimate leaves the work unknown: it receives no invented finish date and cannot satisfy downstream dependencies. Parent delivery remains incomplete until every required child has a finish. Other estimated branches can still be forecast. Missing references, dependency cycles, and incompatible dates can prevent a valid run. Check that enough capacity is available before relying on the forecast.

The live forecast starts from the later of today's local date and the model's configured **reporting start**. A later authored start is respected, including one advanced when completing work. The effective reporting end is never earlier than that start. This live adjustment leaves the authored project unchanged. Reporting snapshots preserve the effective window used when captured, while older snapshots replay their saved windows. Standalone milestones are dated commitments that consume no work; simulation can continue beyond the reporting end to completion or its configured limit.

To maintain dated commitments, expand **Project milestones** above the table:

1. Choose **Add milestone**, or **Edit** beside an existing milestone.
2. Enter **Milestone name** and **Milestone date**. Names must be unique across the project's work, developers, and milestones.
3. Choose **Apply** to commit and refresh the forecast, or **Cancel** to discard the draft.
4. To remove a commitment, choose its **Delete** action and review the confirmation.
5. Check its date reference in GANTT and the history views.

Milestones provide reference dates; they do not create effort, dependencies, or a scheduled task. Milestone edits use the same draft safeguards, automatic saving, and Undo/Redo as other project edits.

![Public beta milestone name and date draft above the current Project table.](screenshots/61-project-milestones-2026-10-22.jpg)

*Figure 9. Public beta milestone name and date draft above the current Project table.*

### Follow links between work, people, and sprints

In the Project table, click an assignee to open that developer in Team, a dependency name to inspect the prerequisite, or a sprint name to open its planning screen. Each link opens the relevant record. Resolve any pending draft before leaving an editor.

Container editors list their **Child work items**. Search that list and click a child to inspect it, or use the available **Add** control to create the next level. Use this list to work through a branch without searching the full table.

### Add, move, or delete work

1. Hover a parent row and use its **+** control to add a child. Review the child type and enter its details.
2. If adding a child converts an actionable leaf into a container, review the proposed transfer of its work and sprint assignment before confirming.
3. To move an item, open its form, choose a different **Parent work item**, and Apply. The subtree moves together. The picker prevents selecting the item itself or one of its descendants.
4. To delete, use the row's delete control or **Delete item** in the form and review the confirmation. Check the effect on descendants and dependencies.
5. For a deleted task, expand **Deleted tasks** in Project and choose **Restore** beside its name. Review restored references and Issues before using the forecast.

Each native work item keeps its identity when you rename it or move it to another parent. Concurrent changes and history continue to refer to that identity. The displayed hierarchy path numbers help you navigate but are not permanent identifiers. Deleted tasks remain recoverable in native history; ordinary editing does not purge them.

## 7. Define the project workflow

Workflows give your project its own named states and Kanban columns. Each state has a name, color, position, and **Simulation category**. The category tells Sundial how the state affects scheduling; the name describes your team's process. The default workflow contains Backlog, In progress, Review, Blocked, and Done. Review uses the In progress simulation category. Existing projects with explicit workflows keep their configured states.

![Workflow settings with Review, allowed Next states, and the directed transition diagram.](screenshots/34-workflow-2026-10-22.jpg)

*Figure 10. Workflow settings with Review, allowed Next states, and the directed transition diagram.*

### Add or revise states

1. Open **Project → Workflow settings**.
2. Select a state to rename it or change its color. Use **Move up** or **Move down** to change column order.
3. Choose **Add state** to create another step, then enter a meaningful name such as Ready, Testing, or In review.
4. Choose its **Simulation category** using the table below. A review or testing step normally belongs to In progress if it should continue to count as active work.
5. For a Backlog-category state, select **Default for new work** if newly created items should begin there.
6. Under **Next states**, check the destinations users may choose from this state. Review the directed diagram and its transition list. Click a state in the diagram to edit it; check warnings for states unreachable from the default. A new state also needs an incoming transition if users should be able to reach it.
7. Leave all Next states unchecked to make a state terminal. Done-category states always have no outgoing transitions.
8. Choose **Preview changes**. Review affected tasks, old and new states, categories, and cancellation outcomes.
9. Choose **Apply workflow changes** to commit the configuration and affected work together, or **Cancel** to return to the draft. Cancel the settings dialog to discard it.
10. Open **Kanban** and check the columns and permitted moves. Review Delivery outlook and GANTT after category changes.

| Simulation category | Scheduling meaning |
| --- | --- |
| Backlog | Work waiting for pickup, subject to dependencies, dates, skills, and capacity. |
| In progress | Active work that can receive future allocation. Moving between detailed states in this category preserves lifecycle dates. |
| Blocked | Unfinished work that receives no future capacity while blocked. |
| Done | Successful delivery. Completion dates and dependency satisfaction follow the completed state. |

![Workflow impact preview before applying changes. This unchanged preview affects no tasks.](screenshots/35-workflow-preview-2026-10-22.jpg)

*Figure 11. Workflow impact preview before applying changes. This unchanged preview affects no tasks.*

Keep at least one ordinary state in every simulation category. The default for new work must belong to Backlog. State identity is stable: a rename or reorder preserves references and does not itself change the forecast. Several detailed states may share a category. Board labels and colors follow the configured states; simulation summaries and status-based diagrams still use the four scheduling categories and their own legends.

The default routes are Backlog → In progress; In progress → Backlog, Review, or Blocked; Blocked → In progress; Review → In progress or Done. To finish work through this default process, move it to Review, then Done. These routes can be changed for unfinished states. Legacy custom workflows without explicit routes allow moves between unfinished states until routes are configured.

Task editors, Kanban menus, drag-and-drop, and native edits enforce the same transitions. A column can remain visible even when a selected card is not allowed to enter it. Done cannot be reopened by an ordinary move or tracker refresh; Undo can reverse a mistaken completion. Moving between detailed states retains a transition history, even when their scheduling category stays the same. Acceptance criteria remain written guidance and do not add a completion prompt.

To remove a state, select it and choose **Remove state…**. Choose the replacement state for work that references it, review the impact, and apply the change. Resolve references used by defaults or import mappings too. Configuration can remap unfinished work across categories independently of ordinary transition routes, so read the preview carefully. Work already Done may only be reassigned to another Done-category state; removing its state cannot reopen it.

Workflow edits save automatically and support Undo/Redo. If the project changes while settings are open, close and reopen the dialog before applying. The current workflow applies to the whole project; there are no separate team workflows, transition scripts, or automatic transition rules.

### Cancel work without deleting its history

![Canceled workflow-state draft with Blocked category and terminal outcome; the draft was discarded.](screenshots/59-canceled-state-2026-10-22.jpg)

*Figure 12. Canceled workflow-state draft with Blocked category and terminal outcome; the draft was discarded.*

1. In Workflow settings, add a state and give it a clear name such as Canceled.
2. Enable **Canceled terminal outcome**. Sundial sets its simulation category to Blocked and prevents changing that category while cancellation is enabled.
3. Select the unfinished states from which cancellation should be allowed and check Canceled under their **Next states**. If canceled work may be resumed later, explicitly allow an outgoing transition from Canceled to the intended unfinished state; leaving it empty makes it terminal.
4. Preview and apply the workflow configuration.
5. Open an eligible work item's form and choose the canceled state, then Apply; alternatively, use an allowed Kanban move into its column.
6. Review the forecast and dependent work. To resume work, use a configured outgoing route, deliberately revise the workflow, or Undo the cancellation while that edit remains available.

Canceled work keeps its identity, description, acceptance criteria, original estimate, dependencies, and recorded effort history. It consumes no future capacity and contributes no effort to simulation scope or completion totals. It is never successful delivery and never satisfies a prerequisite. Cancellation clears successful completion and forecast finish; it does not delete the item or remove dependency links.

If a canceled item is a prerequisite, downstream work can remain unscheduled. Review the dependency and decide whether to reopen the item or revise the relationship. A parent with a canceled descendant stays incomplete. Canceling a container removes its unfinished descendants from future scheduling while retaining completed child history. Reopening the container restores scheduling according to the descendants' retained authored states.

Canceled work cannot be added to a new sprint. If it was already a member, completion records it as Canceled and does not carry it forward as unfinished work.

## 8. Set priorities and the order of work

Use **Urgent**, **High**, **Normal**, or **Low** to express preference across the project. An item's **Inherit** option uses its nearest ancestor with an explicit priority, or Normal if none exists. A container's explicit priority guides descendants that inherit. An explicit Normal overrides an inherited Urgent or High.

### Set an inherited or explicit priority

1. Open a work item from Project, Kanban, Sprints, or a supported diagram.
2. Choose a value in **Priority**, or choose **Inherit** and review the effective value shown beside it.
3. Choose **Apply** to commit the edit.
4. Check the Project Priority column, Kanban cards, or sprint planning lists. A small arrow identifies inherited values.

In **Example**, Login flow is Urgent and Login page and Session tokens inherit it. Normalization is Low. You can inspect these examples to see how inheritance works.

### Order unfinished tasks within a priority

![Login page with inherited Urgent priority, ordering controls, and formatted Description preview.](screenshots/32-priority-preview-2026-10-22.jpg)

*Figure 13. Login page with inherited Urgent priority, ordering controls, and formatted Description preview.*

1. Open an unfinished actionable leaf and expand **Order within … priority**.
2. Review its position and the preceding and following task names.
3. Use **Move first**, **Move earlier**, **Move later**, or **Move last** to change its preference within that priority.
4. Apply the form to commit order, priority, and other draft fields together. Cancel discards them.
5. Review the updated forecast and dependencies.

The ordering pool spans eligible unfinished leaf work across the project, even when a board, sprint, or branch filter hides some tasks. Ordering does not rearrange the hierarchy or change sprint membership. Completed and canceled work do not participate in the active ordering pool. A container passes priority to inheriting descendants, but does not pass its manual position to them.

The scheduler considers deadline urgency before priority and manual order. A task must still meet its dependencies, start constraints, calendar, skill, access, and capacity requirements before pickup. Assignments already started continue. An Urgent priority expresses a preference within those constraints.

Applied preferences support Undo/Redo, shared editing, native recovery, and reporting snapshots. Resolve a stale draft before applying. To view preferences while planning a sprint, use its Priority filter and the labels beside work-item names.

## 9. Edit the team with structured forms

Use **Team** to add or edit developers, set their capacity and skills, restrict project access, and maintain working calendars. Apply the forms to save these settings within the current native project. No configuration code or separate Team file is needed.

### Open the Team workspace

1. Open your native project, or click **Example** to explore the supplied demonstration and its snapshots.
2. Select **Team** in the main workspace tabs.
3. Choose a developer from the roster on the left. Their details appear on the right.

![Team workspace with the current developer directory, calendars, skills, access, and assignment links.](screenshots/36-team-2026-10-22.jpg)

*Figure 14. Team workspace with the current developer directory, calendars, skills, access, and assignment links.*

The roster lists committed developers in source order, with their locations, default daily capacity, and scheduled override count. For example, "8 h/day + 1 overrides" means an eight-hour default and one override period. It does not show today's capacity or add the override hours to the default. A new developer appears in the roster count after you apply the draft.

### Edit an existing developer

1. Select the developer in the roster.
2. Under **Profile**, edit **Name** or choose a **Location**. Choose **No location** to remove a specific location assignment.
3. Under **Availability**, set **Default hours / day** and any **Scheduled overrides** needed for leave or temporary capacity changes.
4. Review **Skills** and **Project access** using the instructions below.
5. Expand **Advanced settings** if you need to change speed or concurrent work.
6. Click **Apply changes**. Correct any highlighted errors and apply again if necessary.
7. Wait for the forecast to refresh, choose **Diagrams**, and review **GANTT** and **Work tracker**.
8. Check save notices; Project assignment changes caused by a rename save with Team in the same container.

Form edits remain a **Draft** until you choose **Apply changes**, which validates the inputs, commits them to Team, and refreshes the forecast. Until then, the document and roster keep their committed values. **Cancel** reloads those values and discards the unapplied draft. To reverse an earlier Apply, use **Undo**.

### Open a developer's assigned work

The **Work items** section in developer details lists their current open assignments, with type, hierarchy context, status, and sprint link where available. Completed and canceled work are excluded from this workload list.

1. Select a developer in Team and scroll to **Work items** if necessary.
2. Click a work-item name to open its Project editor.
3. Click its sprint name to open that sprint's planning screen.
4. Resolve any unapplied Team draft before following either link.

The list uses the developer's committed name while a rename is still a draft. An empty list means the developer has no open assignments. Their capacity and completed history are separate from this list. Follow a link to edit the task in Project.

### Add a developer or create a team

![New developer draft with default capacity and profile controls; the draft was discarded.](screenshots/40-new-developer-2026-10-22.jpg)

*Figure 15. New developer draft with default capacity and profile controls; the draft was discarded.*

1. Click **+ Add developer** above the roster. With an empty Team document, use **Create team** to begin with the first developer.
2. Enter a unique **Name** and choose a location, if appropriate.
3. Set realistic default daily hours. A new developer starts at eight hours per day, speed one, and one concurrent work item; review these defaults for your plan.
4. Add skills and choose project access. For someone joining later, use the zero-default approach described below.
5. Click **Apply changes**. The developer is appended to the roster after validation succeeds.
6. Review the resulting forecast and check that automatic saving succeeded.

Use **Cancel** if you decide against adding the developer. Names must be nonempty and unique; when Project is loaded, a developer name must also avoid conflicting with work-item or milestone names.

### Set skills and project access

The **Skills** section is a table with **Skill** and **Has skill** columns. Click **+ Add skill**, enter the skill name, and choose **Yes**, **No**, or **Unspecified**. Color helps distinguish the values, while their text remains visible. Existing names from the project and team are suggested, and you may enter a new name. Use the row's × button to remove a declared skill.

| Skill state | Scheduling meaning |
| --- | --- |
| Yes | The developer is capable of work requiring this skill. Fully matched developers are preferred. |
| No | Excludes the developer from work requiring this skill. |
| Unspecified | Leaves the skill undecided; it does not exclude the developer. |

Required skills can be inherited from parent work items. Use consistent skill names, avoid duplicate rows, and apply the draft after editing. Removing a row removes the declared skill entry; it is distinct from retaining a row as Unspecified.

For **Project access**, leave **Access** at **All projects** for scheduling eligibility across the model. This setting controls work assignment eligibility, not permission to open the shared folder; filesystem permissions control that access. To restrict eligibility:

1. Choose **Selected projects**.
2. Enter a project or initiative name using the suggestions where possible.
3. Click **+ Add project** to create a chip for that name.
4. Repeat for other allowed names, then click **Apply changes**.

Keep at least one chip when using Selected projects. To remove all restrictions, choose **All projects**. If the roster includes a project name absent from the loaded project, the form preserves it and marks it **Not in this project**. Access does not define separate daily hour budgets for each initiative.

### Model default capacity, leave, and temporary hours

![Bruno's default capacity and dated zero-hour override in the Team editor.](screenshots/38-team-overrides-2026-10-22.jpg)

*Figure 16. Bruno's default capacity and dated zero-hour override in the Team editor.*

**Default hours / day** is the developer's capacity on working days outside override periods. A scheduled override replaces that value during its interval. Eight default hours and a four-hour override produce four hours on covered working days. Overrides do not add hours to the default. Weekends and location holidays remain non-working days even when an override has positive hours.

To record leave or a temporary allocation:

1. Select the developer and review **Default hours / day**.
2. Under **Scheduled overrides**, click **+ Add override**.
3. Set **From**, **Until**, and **Hours / day** for the new period. A new row copies the current default hours and leaves its dates blank, so fill the intended bounds deliberately.
4. Use zero hours for time off, or a positive value for temporary part-time or increased capacity.
5. Add further periods if needed, keeping their dates separate.
6. Click **Apply changes**, review the forecast, and check automatic saving.

Hours must be from zero through 24, with at most two decimal places. Both dates are inclusive. A one-day override is valid when From and Until are the same date. From must not be later than Until. Overrides cannot overlap: one ending on the next one's start date overlaps on that day.

A blank From means no lower date bound; a blank Until means no upper bound. Leaving both blank covers every date and conflicts with any other override. Do not leave bounds blank unintentionally. **Remove** deletes a period from the draft; after Apply, the default resumes over that period.

For a developer who should contribute nothing before joining, set the default to zero and add an override starting on their joining date with the intended daily hours. Leave Until blank for an ongoing allocation. For capacity available only during specific periods, keep the default at zero and give each period its own bounds. Review the default explicitly: an override list alone does not imply zero capacity outside its dates.

### Adjust advanced settings

Expand **Advanced settings** to edit:

| Control | Meaning |
| --- | --- |
| Speed multiplier | Productivity relative to the standard rate; defaults to one. Must be positive, with at most two decimal places. It does not change available hours. |
| Maximum concurrent work | Maximum simultaneous items; defaults to one. Must be a whole number of at least one. More concurrency does not create more daily hours. |

Set daily hours to the time available for this plan. Change speed only when you have a credible reason to adjust the productivity assumption. Apply and inspect the resulting schedule before accepting new assumptions.

Below **Advanced settings**, expand **Audit** to review changes to this developer profile. It starts collapsed. Actions show the signed-in user, local date and time, and previous and new values, most recent first. Use its search box to find a person, field, or value. Renaming a developer keeps their profile history together.

![Developer Audit section below Advanced settings; the fresh Example has no committed profile edits.](screenshots/67-developer-audit-2026-10-22.jpg)

*Figure 17. Developer Audit section below Advanced settings; the fresh Example has no committed profile edits.*

### Manage locations and working calendars

![Germany working calendar with country and region fields, weekend controls, and extra non-working dates.](screenshots/39-locations-2026-10-22.jpg)

*Figure 18. Germany working calendar with country and region fields, weekend controls, and extra non-working dates.*

1. In Team, find **Locations** below **Developers** in the left sidebar.
2. Select an existing location, or click **+ Add location**.
3. Enter a unique **Location name**.
4. Enter an optional **Country code** to use public holidays. Add an optional **Region code** when regional holidays are relevant; the region must belong to the chosen country.
5. Select the non-working **Weekend days**. New calendars start with Saturday and Sunday selected.
6. Under **Extra non-working dates**, click **+ Add date** for each company closure or additional holiday. Use **Remove** to remove a draft date; duplicate extra dates are rejected.
7. Click **Apply changes**.
8. Select the appropriate members directly under **Developers** in the same sidebar and assign their Location. Apply each changed developer draft.
9. Check automatic saving and review the forecast.

Public holidays come from the holiday service; the extra-date list contains the closures you enter. Fetched holidays are not copied into that list. If a fetch fails and no cached data is available, read the warning. A forecast using only weekends and extra dates may finish too early.

Renaming a location updates matching developer location references in the Team document as one change. To delete an unused location, use its **Delete** button and confirm. If developers still reference it, first choose another location or No location for each affected developer and apply those edits; deletion is blocked until the references are removed.

### Rename or delete a developer safely

To rename a developer, select them, edit **Name**, and click **Apply changes**. Sundial renames the Team member and updates matching task assignees in the loaded Project as one committed change. The form shows how many assignments it will update. All changes save in the same native project.

If Project references cannot be updated safely, the rename is blocked. Correct the reported Project issues and retry. The rename affects the current native project; it does not rewrite other project folders.

To delete a developer, open the row's **•••** menu, choose **Delete developer**, and confirm. Sundial blocks deletion of the last developer and of a developer still named in task assignments. Update or remove those assignments in Project first. For a temporary staffing experiment, uncheck the person in **Team what-if** instead of deleting them from the reference team.

### Drafts, automatic saving, snapshots, and undo

![Unapplied-changes dialog offering Apply changes, Discard changes, and Keep editing.](screenshots/41-draft-guard-2026-10-22.jpg)

*Figure 19. Unapplied-changes dialog offering Apply changes, Discard changes, and Keep editing.*

| Action | Result |
| --- | --- |
| Edit a form control | Creates an unapplied Draft; the committed document and forecast stay at their previous values. |
| Apply changes | Validates and commits the draft, refreshes the forecast, and triggers native project saving. |
| Cancel | Abandons the unapplied draft and reloads the committed values. |
| Snapshot / Ctrl+Shift+S | Captures committed Project and Team together after resolving any pending form draft. |
| Undo / Redo | Reverses or reapplies committed model edits, including assignment updates from a rename, and saves the resulting native changes. |

When changing developer, leaving Team, opening another project, or capturing a snapshot with a pending draft, resolve the dialog: **Apply changes** commits valid edits, **Discard changes** continues with the previous committed document, and **Keep editing** returns to the draft.

If automatic saving fails, restore folder access and use **Retry**. Browser recovery does not prove the shared folder is current. Closing a notification leaves the draft unchanged; it does not save or discard it.

### Resolve form errors and return to the diagrams

If validation fails, the form keeps your entries and shows **Changes were not applied**, with errors beside the affected fields where available. Correct duplicate names or skills, missing access chips, invalid numbers, conflicting periods, or calendar codes, then apply again. The first invalid control receives focus when Apply fails.

If the underlying Project or Team changes while you have a draft, use **Reload draft** to work from the newer document; stale edits cannot overwrite it. Review collaboration and validation issues before applying again.

After accepting a valid edit, choose **Diagrams**, wait for **Ready**, and inspect GANTT, Work tracker, and Delivery outlook. Applying the reference team also refreshes staffing comparisons; scenario-only additions and exclusions stay separate. Blocked work, dependency chains, skills, project access, pinned assignees, future availability, weekends, and holidays still constrain the forecast.


## 10. Track work in Kanban

Kanban displays actionable leaves in columns for the project's configured workflow states. The default workflow has Backlog, In progress, Review, Blocked, and Done. Containers provide hierarchy context; only actionable leaves appear as cards.

![New Example Kanban board with Review, issue keys, assignees, priorities, effort, and filters.](screenshots/42-kanban-2026-10-22.jpg)

*Figure 20. New Example Kanban board with Review, issue keys, assignees, priorities, effort, and filters.*

Cards show the project issue key, work name, sprint, effective priority, type, assignee, and spent/estimated effort. Inherited priority carries an arrow. Use Workflow settings in Project to add or rename process steps and choose their scheduling categories.

### Review and update work

1. Open **Kanban**.
2. Choose **Scope → All project issues**, **No sprint**, or a named sprint.
3. Choose **Developer** to show all developers, a member, or unassigned work.
4. Choose **Group by → Status only**, **Developer**, or **Epic**. Developer and Epic create swimlanes across status columns.
5. Use **Columns** to hide or show status columns. Hiding a column does not change task status.
6. Open a card to inspect and edit its work-item form. Review assignment, estimate, recorded effort, dependencies, and sprint membership, then Apply. The card's **Description** and **Acceptance criteria** stay off the board for compactness; opening the card shows the full formatted text with the same Preview toggle as the Project form.
7. Drag a card into an allowed next-state column, or use the card's menu and **Change status**. The menu lists permitted destinations; a disallowed drop cannot change the task. With the default workflow, move active work through Review before Done. The change commits and saves automatically and refreshes the model. Same-category handoffs preserve lifecycle dates; category changes use the scheduling and completion rules described in the workflow guide.

To change an assignee, open the issue inspector, even when the board is grouped by developer. Dragging changes status only. Dropping a card into its current status or outside a valid target leaves it unchanged. Resolve any unapplied inspector draft before navigating away or continuing an action that prompts you to review it.

Each column shows up to 30 cards per page. Check the totals and pagination to see whether more work is available. The page size does not impose a work-in-progress or capacity limit. A missing assignee reference can appear separately from unassigned work; correct the reference in Project/Team.

Kanban filters affect the board only. Forecasts still use the full dependency graph and Team. Sprint scope is remembered for the project. A completed sprint's historical board is read-only; use **Open live issue** to edit the corresponding current task.

## 11. Plan, run, and complete sprints

Sprints group actionable work into a named period with inclusive start and end dates. Membership is independent of task status and does not replace dependencies or forecast constraints. The Sprints workspace lists **Planned**, **Active**, and **Completed** sprints.

![New Example active sprint with current scope, unscheduled work, and per-developer capacity.](screenshots/43-sprint-planning-2026-10-22.jpg)

*Figure 21. New Example active sprint with current scope, unscheduled work, and per-developer capacity.*

### Create and populate a sprint

1. Open **Sprints** and choose **+ Create sprint**.
2. Enter a useful name and inclusive start/end dates, then choose **Create**. New sprints use the browser's local timezone; the form does not offer a timezone picker. Use **Edit sprint → Save** for subsequent changes.
3. Select the planned sprint in the list.
4. Search work, filter by developer, or expand **Priority** and select the priorities to include. In **Unscheduled work**, use **Add** for one item or select several and choose **Add selected to sprint**.
5. Expand **Assign other work or a parent subtree** when you need to bring in other work or all eligible leaf descendants of a parent. Review affected issues and any assignments that will be replaced.
6. Under **Sprint scope**, use **Remove** or select several and choose **Remove selected** to leave them unscheduled.
7. Review remaining effort, unestimated work, unassigned work, and developer capacity. Adjust assignments, scope, or dates before starting.

You can also choose a sprint in the Project task form. Assigning a subtree adds its eligible actionable leaves; the parent contributes no extra estimated work. Committed sprint planning actions save automatically.

### Review priorities and inspect planning items

![Sprint planning with the Priority filter expanded and the new Example scope.](screenshots/58-sprint-priority-2026-10-22.jpg)

*Figure 22. Sprint planning with the Priority filter expanded and the new Example scope.*

Unscheduled work is presented by effective priority, then by scheduling status, with active and blocked work ahead of waiting work. Manual order expresses a forecast pickup preference; it does not determine this list's status grouping. The current Sprint scope remains a membership list; moving a task's priority does not remove it from the sprint.

Click a work-item name in either planning list to open its editor and review Description, Acceptance criteria, Comments, and Schedule. Apply changes to the same project record, then return to planning. You can also drag eligible work between the two planning lists to add or remove membership; the explicit Add/Remove buttons provide the same actions.

Filters hide rows for review; they do not exclude those members from total scope or capacity. Canceled work is not offered for new assignment and contributes no remaining capacity demand.

### Interpret Sprint capacity

The capacity panel compares **Estimated work / calendar hours** for all developers and for each member. The workload is remaining estimated effort; Done and canceled work contribute no remaining demand. Calendar hours use Team defaults, overrides, weekends, holidays, and extra non-working dates. Planned sprints use their full period. Active sprints start at the later of today and their start date, through the inclusive end. Date edits refresh the preview; invalid dates or ranges beyond ten years cannot produce a capacity preview.

The total includes unassigned work and identifies it separately; each developer's row includes only their assigned work. A percentage above 100% means estimated demand exceeds calendar hours. Missing estimates make demand incomplete. This comparison does not adjust hours for developer speed, account for scheduling constraints, or deduct work outside the sprint. It does not predict a delivery date or enforce a Kanban WIP limit. Use GANTT and Work tracker for the forecast, especially when speed differs from one or work has dependencies.

### Start and review the sprint

1. Select a Planned sprint and choose **Start sprint**.
2. Review the issue counts and warnings. Starting requires unfinished work; only one sprint can be Active in a project.
3. Confirm the start. It creates no reporting snapshot or commitment baseline automatically.
4. Choose **Open board** to review the sprint in Kanban. Update statuses and recorded work there or in Project.
5. Return to Sprints to review scope and remaining capacity. Dates do not automatically start or complete a sprint.

### Complete and carry unfinished work forward

![Sprint completion review with a destination for unfinished work; the dialog was canceled.](screenshots/44-sprint-completion-2026-10-22.jpg)

*Figure 23. Sprint completion review with a destination for unfinished work; the dialog was canceled.*

1. Select the Active sprint and choose **Complete sprint**.
2. Review all member issues, including filtered or hidden work, the Done count, unfinished items, and canceled members. Canceled work has its own final disposition and is not carried forward.
3. Choose whether unfinished work should **Leave unscheduled**, move to a Planned sprint, or go into a newly created next sprint. Review the destination before confirming.
4. Confirm completion. Task statuses remain unchanged; the destination sprint remains Planned.
5. Verify the completed sprint in the list and its completion checkpoint in **History**.
6. Open its historical board to see the captured end state before carryover. Use **Open live issue** when you want the current item rather than the historical record.

Completing a sprint saves its final board and a full Project-and-Team reporting snapshot. Completed boards are read-only and can be archived. They retain the workflow state names, colors, order, scheduling categories, cancellation outcomes, and configuration captured at completion, so later workflow edits do not rewrite the historical board. If snapshot storage fails, completion remains applied and **Retry snapshot** retains the original completion payload. Restore or reconnect the snapshot store before retrying. A native project-save failure has a separate retry action.

Undo reverses completion and carryover but retains the already saved checkpoint. Redo reuses that completion checkpoint.

## 12. Import Jira data

Use this optional import path when you want to bring existing Jira work into Sundial. Imports use saved files; Sundial does not continuously synchronize with Jira or write local edits back to it. After import, manage the project through Sundial's own work, team, workflow, and sprint screens.

![Import panel with tracker-dump selection, optional mapping, forecast window, and replacement options.](screenshots/57-import-2026-10-22.jpg)

*Figure 24. Import panel with tracker-dump selection, optional mapping, forecast window, and replacement options.*

### Prepare a CSV export

1. In Jira's issue navigator, filter for the complete work set you want Sundial to model. Include parent levels and completed work relevant to the project.
2. Export CSV with the required fields. Choose fields that include keys, summaries, hierarchy, status, estimates, assignees, and dates. **All fields** can supply them but produces a larger, slower export; a configured current-fields export can be smaller.
3. Include **Issue key** and **Summary**. Include parent/epic references, estimates, due dates, assignees, Created, and Resolved wherever relevant.
4. Confirm that the exported issue set matches the result set you intended. Permissions and export limits can omit work without making Sundial's import fail.
5. Keep the export as UTF-8 CSV and retain a source copy.

Atlassian currently documents asynchronous Jira Cloud CSV exports of up to 10,000 work items. Other Jira deployments and export paths can have different limits. For larger result sets, follow your deployment's export process and verify completeness. See [Atlassian's CSV export guidance](https://support.atlassian.com/jira/kb/export-over-10-000-work-items-in-jira-cloud/).

Sundial accepts one CSV file per import. It rejects multiple CSV files and selections that mix CSV with JSON. Prefer one complete, consistent export. Native refresh reconciles known issues; fresh import replaces the model. Check the complete work set rather than assuming successive filtered exports cover the project. Consolidate compatible CSV exports correctly, or select a complete set of JSON dump files.

### Import into Sundial

1. Back up the whole native project folder. Capture a reporting snapshot if you want a before-import baseline.
2. Click **Import** in the header.
3. Under **Dump file**, select one CSV, or one or more supported JSON dump files.
4. Select a **Mapping** YAML file if your workflow, estimate field, date format, or column names need overrides.
5. Set **Reporting window start** to the date represented by your planning model. Its default is the current UTC date.
6. Choose whether to **Seed a fresh project**. Enable it to replace the open document and seed developers from dump assignees. Disable it when refreshing an existing project whose team and settings should remain.
7. Click the dialog's **Import** button.
8. Read the imported item/project counts and all warnings. On failure, the current document remains untouched.
9. Close the dialog, review the result in **Project** and **Team**, and wait for a successful simulation.
10. Correct seeded staffing assumptions, verify automatic saving, and capture a reporting snapshot explicitly. A first import can create a native project and request a folder location.

A fresh seed requires at least one assignee in the dump. Review each generated developer's skills, daily allocation, concurrency, location, and availability before relying on forecast dates.

### Refresh versus fresh import

A native refresh reconciles tracker work with existing items. Matching prioritizes the immutable Jira issue ID, then the Jira instance and issue key, then an existing explicit mapping. Matched items keep their Sundial identity and creation time. Sundial also keeps issues missing from a filtered export, because the export does not establish that they were deleted.

Tracker-owned field updates can replace your local edits to those fields. Review the source data, import warnings, and resulting changes. Preserve existing team/calendar and planning assumptions when using refresh rather than a fresh seed.

Refresh is blocked when the project has local sprint metadata because those assignments cannot yet be reliably preserved by this workflow. **Seed a fresh project** deliberately replaces the Project model, including its sprint plans and completion history. Back up the complete native history before choosing it. Keep a reporting checkpoint too if you need a comparison baseline.

Refresh also preserves recorded effort dates and the developer names attached to entries. If the tracker total is higher, the difference is added to the undated starting balance; Sundial does not invent dates or attribution. A lower tracker total stops refresh for reconciliation rather than removing recorded hours. A leaf with an effort audit cannot become a container through refresh until its recorded work has been moved to a leaf. Refresh can skip intermediate unfinished states, but it cannot reopen Done work.

By default, supplied issues update the existing model while other projects, omitted issues, and existing milestones remain. An optional mapping can request complete snapshot replacement through `importMode`; review that choice separately from the dialog's fresh-project option.

Import does not automatically create a reporting checkpoint. Automatic native persistence and **Snapshot** are separate operations.

### CSV fidelity: understand what is missing

| CSV input limitation | Consequence |
| --- | --- |
| No issue-link dependency data in the ordinary adapter | The resulting schedule cannot include those blocking links. Review any manually supplied dependency information after a tracker refresh. |
| No status changelog | A done item's start is approximated from Created; finish uses Resolved. |
| Done item lacks required historical dates | Import fails rather than inventing completion history. |
| Status names without categories | Built-in or explicit mapping determines the category for a default workflow. With a configured project workflow, every imported status name needs an exact mapping to a project state; an unmapped name stops refresh. |
| Fix version names without release dates | They do not become dated milestones. |
| Assignee display names | Team member identity needs checking against the committed Team. |
| Ordinary CSV lacks a source issue URL | Supported charts omit source links for those items. |

When reviewing dependency cascades or historical schedules, check these limitations alongside the import result. An import can succeed even when the export is incomplete.

### JSON and NDJSON dumps

The browser accepts saved Jira search response objects, arrays of issue objects, and NDJSON containing one issue object per line. Multiple JSON dump files can be selected in one run. Duplicate issue keys favor the newest `updated` value; ties or missing timestamps retain the first occurrence.

A JSON dump can include issue links for dependencies and changelog data for more accurate historical transitions. Check that those details are present in your files. Sundial does not retrieve missing pages or enrich the dump from Jira. Make sure your saved files cover all pages and contain the fields you need.

### Configure a mapping file

Use the optional mapping file to select your Jira profile, date order, estimate field, points-to-hours conversion, status mapping, duration units, and policy for missing estimates. Use a points-to-hours conversion justified by your team; the Fibonacci option selects Sundial's fixed mapping instead. The mapping's duration scale describes Jira's duration notation, not a developer's calendar capacity.

The default unestimated policy is **error**. Alternatives are `skip` or an explicit fallback such as `hours:8`; both change the model and should be disclosed in reports. Column overrides can map canonical fields to localized headers, such as a localized Summary column. Supported profiles are `cloud`, `server`, and `apache`. Unknown mapping keys are errors.

### Map imported statuses to the project workflow

Before refreshing a project with a configured workflow, open **Project → Workflow settings** and expand **Tracker status mappings**. Enter each exact Jira status name and choose its Sundial state. Include spelling and case as exported, then preview and apply the configuration. Several source statuses can map to one state.

An unmapped source status stops a configured-workflow refresh rather than silently putting that issue into Backlog. Review the import error, add the missing mapping, and retry. Choosing a mapped canceled state applies Sundial's cancellation rules; choosing a Done-category state uses successful completion rules and valid imported completion dates.

Matched refreshes preserve Sundial-authored descriptions, acceptance criteria, comments, priorities, manual ordering, and detailed-state audit history. Jira priority does not set Sundial priority. Tracker-owned fields can still change during refresh, so inspect the result and warnings. Fresh import is a replacement operation and is covered separately above.

## 13. Choose the right diagram

| Tab | Use it to answer | Data basis |
| --- | --- | --- |
| WBS | What is in the project, and how is it organized? | Current work hierarchy and effective status. |
| GANTT | When can the work start and finish? | Current simulated schedule and historical done dates. |
| Sunburst | Where is the effort, and what is its status? | Current hierarchy, total estimated effort, and status. |
| Work tracker | Who is forecast to work on what and when? | Simulated developer allocations. |
| Monte Carlo | How often does each work item finish on each date? | Repeated PERT samples using the current scheduler and staffing constraints. |
| WBS over time | Which work or status changed between checkpoints? | Baseline versus current model or a later snapshot. |
| GANTT over time | How did delivery dates change? | Two simulated endpoint schedules. |
| Sunburst over time | How did effort and status change across checkpoints? | Up to two saved models beside Current, on a shared angular effort scale. |
| Scope | How has estimated project scope changed? | Saved checkpoints plus a live Current column. |
| Milestones | How have delivery forecasts moved, and how does scope relate to them? | Timeline or Scope presentation of saved forecasts plus Current. |
| Team what-if | What delivery difference does this roster change make? | Same project simulated with reference and alternative teams. |

### Common diagram controls

1. Choose **Diagrams** in a large desktop window. Close any work-item editor to give the chart the full workspace.
2. Use **Hide details** in Delivery outlook if you need more chart height.
3. Start with the fitted overview. Use **Zoom in**, **Zoom out**, and **Fit** to move between detail and the whole diagram.
4. Use **Ctrl+wheel** to zoom around the cursor. Scroll to explore content larger than the pane; horizontal scrolling or Shift+wheel helps wide schedules.
5. Hover marks for details. Chart labels can be shortened to fit; tooltips supply fuller context.
6. Use **Show title** when capturing or exporting a self-contained report image.
7. Use the diagram toolbar's **SVG** or **PNG** control to export that diagram.

### Edit work directly from a diagram

In the current **WBS**, **GANTT**, and **Sunburst** views, click a work item to open its editor beside the chart. Use the same Name, Status, Priority, Description, Acceptance criteria, Comments, and Schedule controls described in the Project guide. Apply commits to the shared project and refreshes its forecast; Cancel discards the draft. Close the editor to return to the full diagram. Disclosure markers expand branches rather than opening the editor.

You can review a branch and update its planning data beside the chart, then check the resulting dates without returning to the main table. Comparisons and historical views remain reporting views; use the current workspaces to edit live work.

The canvas grows to fit its content. Use Fit for an overview, then zoom and scroll to inspect details at their natural size. Exports use the whole chart canvas, regardless of the current viewport zoom.

## 14. WBS: inspect scope and status

A work breakdown structure is a hierarchy of deliverables and their component work. It helps establish scope before reviewing dates. PMI discusses the value of deliverable-oriented decomposition in [Scheduling 101](https://www.pmi.org/learning/library/schedule-101-basic-best-practices-6701/).

![Redesigned WBS using the expanded Example hierarchy, assignee labels, and Goal and Late goal borders.](screenshots/45-wbs-2026-10-22.jpg)

*Figure 25. Redesigned WBS using the expanded Example hierarchy, assignee labels, and Goal and Late goal borders.*

### Step by step

1. Click **WBS**.
2. Follow the hierarchy from the project root through initiatives and epics to leaf work.
3. Use a node's disclosure control to expand or collapse a branch. **Expand all** reveals branches; **Collapse all** produces an overview.
4. Enable **Count done** or **Count backlog** to group those sibling items into counters. Disable the options when individual names are needed.
5. Toggle **Assignees** to show or hide ownership in captions.
6. Hover an item for details. Click its box to open the work-item editor when you need to revise description, status, priority, or planning fields.
7. Export the configured view for a scope or status review.

### Read the colors

Use the WBS legend: done is green, in progress is yellow, backlog is pale blue-gray, and blocked/problem states are red. An incomplete item with a deadline retains its status fill and gains a thick goal border: red when its deadline has expired at the view date or its forecast finish is later than the deadline, green otherwise. Blocked work keeps a red border. The deadline appears in the caption. Use each chart's own legend; Sunburst uses amber for in-progress work.

A container's effective status summarizes its subtree. Counters are presentation aids and do not create or remove source work. A hidden branch still contributes to the model and to rolled-up dates and effort.

## 15. GANTT: review the delivery schedule

A Gantt chart places work on a calendar so durations, sequencing, and overlaps are visible. [Asana's Gantt overview](https://asana.com/resources/gantt-chart-basics) provides background on this chart family. Sundial calculates unfinished work's schedule from the model; manually entered dates alone do not determine it.

Use **Start date** to choose the visible GANTT window; clear it to include all history. **Show hi-low ranges** overlays the optimistic and pessimistic scenario finishes around the PERT expected schedule. These are coherent scheduling scenarios, not Monte Carlo percentiles. **Show dependencies** toggles dependency connectors. The new Example includes varied effort bounds so these differences are visible.

![Current GANTT with PERT hi-low ranges, dependencies, start-date control, deadlines, and the Public beta milestone.](screenshots/46-gantt-2026-10-22.jpg)

*Figure 26. Current GANTT with PERT hi-low ranges, dependencies, start-date control, deadlines, and the Public beta milestone.*

### Step by step

1. Click **GANTT**.
2. Use **Root** to choose the whole project or a particular container, then locate the initiative or epic of interest in the row labels.
3. Expand its disclosure marker to reveal the next level. Use **Expand all** for more detail or **Collapse all** to return to the configured depth.
4. Read the start and finish against the time axis. Hover the bar or caption for precise dates and details. Click a work item to open its editor; close it for the full schedule.
5. Follow visible dependency connectors to understand sequencing constraints.
6. Compare the forecast finish with the deadline marker. Standalone milestones such as Public beta appear as separate vertical reference lines.
7. Zoom into the relevant interval and scroll as needed. Enable **Show title** before exporting.

The **now** line marks the effective forecast start: normally today, or a later configured start. Container spans include historical completed children as well as future work. Long breaks can split a summary bar; a continuous stretch does not imply work on the parent every day. Missing child forecasts prevent a complete parent delivery date. Completed work retains recorded ownership in reports. Gaps and short allocations reflect calendars and sequencing; use Work tracker to inspect simulated person-hours.

## 16. Sunburst: see effort and health at a glance

A sunburst displays a hierarchy as concentric rings. Descendants sit outside their parents; segment widths encode relative values. See [Plotly's sunburst explanation](https://plotly.com/python/sunburst-charts/) for the general structure and Tommesani's article on [project health with sunburst diagrams](https://tommesani.com/visualizing-project-health-at-a-glance-with-sunburst-diagrams/) for its project-reporting use.

![Current Sunburst showing the new Example hierarchy and status-colored PERT expected effort.](screenshots/47-sunburst-2026-10-22.jpg)

*Figure 27. Current Sunburst showing the new Example hierarchy and status-colored PERT expected effort.*

### Step by step

1. Click **Sunburst**.
2. Leave **Root** set to **Project** for a whole-project picture.
3. Read outward from the center to follow initiative, epic, story, and task relationships.
4. Compare widths within a ring to find effort-heavy areas. Parent totals derive from children, avoiding double counting.
5. Read the legend: green is done, amber is in progress, red is blocked, and pale blue-gray is backlog.
6. Hover a segment for its name, status, effort, and share.
7. Select an initiative in **Root** to focus the chart on that branch, then return to Project for the overall picture.
8. Click a segment to open the live work item when you need to inspect or edit it. Close the editor, then export the view for a project-health overview.

Arc width shows total estimated effort. It does not measure remaining hours, duration, or percentage complete. The selected root is named in the center; segment captions follow their arcs where space permits. Narrow labels may be hidden, so hover to read them. Container status summarizes the subtree and does not imply every descendant shares that status. The **Sunburst** tab shows the current state. Use **Sunburst over time** to compare checkpoints.

**Sunburst over time** places up to two saved snapshots beside **Current**, ordered by capture time. Every chart has the same radius. The largest valid total effort fills a circle; earlier or smaller totals occupy a proportionally smaller angular span, leaving a gap. The shared scale makes scope growth visible across periods. Colors retain the status meanings from Sunburst.

1. Open **Sunburst over time** and choose a saved checkpoint in **Historical snapshot 1**.
2. Optionally choose a different checkpoint in **Historical snapshot 2**. Choose **No snapshot** to remove a saved period; Current remains visible.
3. Leave **Root** at **Project**, or choose an initiative to use the same focus in every chart.
4. Compare the occupied angle, status segments, total estimated hours, and percentage complete beneath each chart. The completion percentage compares worked effort, including completed work, with total estimated effort.
5. Use **Zoom in**, **Zoom out**, and **Fit** for inspection. A root or snapshot change resets zoom.
6. Enable **Show title**, then use this tab's **SVG** or **PNG** button to export the comparison as one image.

The saved charts use each snapshot's own work, effort, and status. They do not forecast its history again. Missing or invalid effort, an absent selected root, or an unreadable snapshot produces a notice for that period. Zero effort has no angular span. These gaps do not mean completion. Without snapshots, Current still appears; capture a checkpoint or load Example into an empty reporting store to add comparison periods. These snapshot choices are independent of the two Delta views.

![July, August, and Current Sunbursts sharing an effort scale with the expanded Example.](screenshots/62-sunburst-over-time-2026-10-22.jpg)

*Figure 28. July, August, and Current Sunbursts sharing an effort scale with the expanded Example.*

## 17. Work tracker: inspect resource allocation

The Work tracker is a heatmap: rows represent developers, columns represent time, and cell intensity represents allocated work. Heatmaps encode numeric magnitude by color; [Plotly's heatmap documentation](https://plotly.com/python/heatmaps/) illustrates the chart family.

Use **Day** or **Week** under Resolution, and **Hours** or **Capacity** under Values. Capacity compares allocation with the developer's available hours. The current drawing distinguishes weekends, holidays, and available but unallocated time, and adds Goal deadline and milestone references. Developer labels summarize allocations; hover cells and markers for their details.

![Redesigned daily Work tracker with developer allocations, availability, Goal deadlines, and milestone references.](screenshots/48-work-tracker-2026-10-22.jpg)

*Figure 29. Redesigned daily Work tracker with developer allocations, availability, Goal deadlines, and milestone references.*

### Step by step

1. Click **Work tracker**.
2. Use **Day** to inspect daily allocation for each developer.
3. Hover a cell to read the allocated hours and contributing tasks.
4. Inspect non-working-day details when available. A weekend, holiday, zero-capacity override, or zero default can explain an empty cell; on a working day, there may simply be no allocated work.
5. Select **Week** for a long interval. Each weekly cell shows average hours per visible calendar day; the tooltip supplies the week's total and task contributions.
6. Switch **Values → Capacity** when you need to compare utilization with available capacity rather than raw hours.
7. Look for persistent empty working periods or long stretches of high allocation, then check dependencies, skills, and capacity assumptions.
8. Export the chosen daily or weekly presentation.

For an empty cell, check whether the person is unavailable, waiting on dependencies, ineligible for the remaining work, or has finished the work in the model. The heatmap shows Sundial's simulated allocations and does not import real-world timesheets. Weekly averages include visible non-working days, so they need not equal a person's nominal working-day hours.

![Work tracker Capacity mode showing allocation relative to each developer's available hours.](screenshots/69-work-tracker-capacity-2026-10-22.jpg)

*Figure 30. Work tracker Capacity mode showing allocation relative to each developer's available hours.*


## 18. Monte Carlo simulation

Open **Diagrams → Monte Carlo** and press **Start**. Sundial samples each unfinished leaf's total effort from a Beta-PERT distribution using its optimistic, most likely and pessimistic estimates (lambda 4). Missing bounds default to the most likely estimate. Equal bounds produce fixed effort. Spent effort is subtracted by the ordinary scheduler, completed history remains fixed, and parent completion dates roll up through Epics, Initiatives and the Project.

![Stopped Monte Carlo run with Project and Initiative distributions and the P50, P85, and P95 table.](screenshots/70-monte-carlo-2026-10-22.jpg)

*Figure 31. Stopped Monte Carlo run with Project and Initiative distributions and the P50, P85, and P95 table.*

The computation runs in a background worker. As soon as the first iteration completes, the diagram and percentile table appear with that single sample. They then refresh together at most once every five seconds. The green calculator-style counter shows completed iterations and refreshes at most once per second after the first result. The counter may therefore be ahead of the displayed diagram; cell percentages and percentiles always use the iteration count printed on that diagram.

The heatmap follows the GANTT hierarchy and its initial root/depth settings. Expand or collapse rows using their disclosure controls. The timeline extends from Now to the latest simulated completion date. Dark blue means no completion on that day; bright red marks the most frequent day **within that row**. Each row is normalized independently, so colors do not compare raw counts between work items. Hover a day to see the date, occurrence count and percentage of completed iterations. Historical completions before Now remain in the percentile statistics but lie outside the heatmap window.

Violet vertical bars mark milestones; red row ticks mark Goal deadlines, using the GANTT conventions. Inherited deadlines continue through descendant rows, with the label shown only where that deadline begins. Hover a marker to read its name and date. The timeline extends far enough to show future milestones and Goals even when they fall after the latest simulated completion; exports include these markers.

Expand **Completion date percentiles** to see Project and Initiative P50, P85 and P95 dates. For example, P85 is the earliest date by which at least 85% of completed iterations finished that item. Percentiles use the empirical nearest-rank rule. Iterations without a completion date count toward the denominator; if too few iterations finish the item, the corresponding percentile is unavailable.

**Stop** finishes and counts the current iteration, then immediately refreshes all results. **Leaving the Monte Carlo tab also stops computation after the current iteration.** Returning shows the existing results without resuming. Pressing Start again clears them and starts a fresh run.

Each run uses a temporary in-memory copy of the inputs captured at Start, including resolved holidays. Edits do not change an ongoing run. This copy creates no saved Snapshot and adds no entry to History. Monte Carlo results are not saved with the project and disappear on reload or project replacement. Use **Export SVG** or **Export PNG** to preserve them; the export includes the heatmap, represented iteration count and the percentile table, even when the table is collapsed on screen.

## 19. Capture and manage snapshots

A snapshot stores the combined Project and Team model with a UTC capture timestamp. It is the checkpoint used by Delta comparisons and history charts. Automatic native saving does not add a reporting checkpoint. Native startup snapshots belong to the collaboration container and serve a different purpose.

![History panel with the Example July and August checkpoints and storage controls.](screenshots/49-history-2026-10-22.jpg)

*Figure 32. History panel with the Example July and August checkpoints and storage controls.*

### Capture a checkpoint

1. Finish the update and resolve model errors.
2. Wait for a successful current run.
3. Click **Snapshot**, or press **Ctrl+Shift+S**.
4. If the browser requests a folder on first capture, choose a dedicated snapshot location. Cancelling that initial picker can use browser storage instead.
5. Open **History** and verify the new checkpoint is listed. Check the storage indicator and any capture notice.

New checkpoints freeze the effective live forecast window as well as the committed work and Team. Historical replay can therefore reproduce the captured dates even after the current date changes. Older checkpoints keep the window saved in them.

Dated files use a name such as `2026-09-30-093005Z.yaml`. The timestamp is UTC, so a capture near midnight can have a different calendar day from your local date.

### Browser storage and folder storage

Browser storage belongs to one browser profile and application origin. Clearing site data can remove the stored buffers and history. Use a separate backup when you need a copy you can move between machines.

Where supported, **Choose snapshots folder…** selects the active file-based store. Sundial writes dated snapshot files directly into the folder you choose. Select a dedicated `snapshots` folder for the project, then confirm its contents and the History indicator. Maintain a separate series for each project. When you switch storage targets, Sundial copies the current project's readable reporting history before changing the active target. Conflicting filenames are preserved under distinct names. If copying fails or the old folder cannot be read, the switch is blocked and the previous target remains active. Reconnect a lapsed folder first, then check History after a successful switch.

If permissions lapse after a browser restart, choose **Reconnect snapshots folder…** and grant access again. If you see a permission error, restore access before checking whether snapshots are missing. **Use browser storage** first copies the project's readable history into browser storage, then changes the active target. It leaves the old folder files intact. Browser quota or read failures block the switch.

### Use History actions

- **Load** replaces the current model with the saved checkpoint after a replacement confirmation. Back up the native project first and review the warning; use a comparison baseline when you only want to compare dates. Existing append-only comments are retained when loading an older checkpoint. Loading changes the model; it does not simply open a chart or reconnect a native folder.
- **Δ WBS** or **Δ GANTT** selects the snapshot as a baseline and opens the corresponding comparison against the current model.
- **Refresh the series** rereads available checkpoints, useful when files have changed outside the browser.
- **Delete** removes a checkpoint. Back up file-based history before deleting; do not rely on an application undo or trash facility.

Example adds demonstration checkpoints only when the active store is empty. If you already have history, check the list to see which project and checkpoints you are comparing.

## 20. WBS over time: explain what changed

Delta WBS shows changed work in its hierarchy. It retains ancestors for context and omits unrelated siblings. This kind of filtered status report is described in Tommesani's article [Changes, or what did we do last month?](https://tommesani.com/changes-or-what-did-we-do-last-month/).

![WBS over time comparing the August checkpoint with the expanded current Example.](screenshots/50-delta-wbs-2026-10-22.jpg)

*Figure 33. WBS over time comparing the August checkpoint with the expanded current Example.*

### Compare a checkpoint with the current model

1. Click **WBS over time**.
2. Under **Compare**, select the baseline snapshot.
3. Leave **with** set to **Now**.
4. Read the diagram title to confirm the endpoints, and check for any stale-current warning.
5. Follow changed branches. Enable **Assignees** if ownership is relevant.
6. Hover changed nodes to inspect before-and-after status, assignee, and other reported field changes.
7. Export the view for a change review.

Colored nodes represent qualifying changes, including additions, status changes, completion, ownership or hierarchy changes, and removals. Gray ancestors locate those changes. Removed nodes use a distinct light-red/struck treatment and have no current-state reading. A gray ancestor can still have a meaningful unchanged status in its tooltip.

### Compare two saved checkpoints

1. Select an older snapshot under **Compare**.
2. Under **with**, select a later saved snapshot.
3. Confirm the period shown in the title.
4. Switch to **GANTT over time** to inspect schedule movement for exactly the same pair.

![WBS over time comparing the saved 13 July and 17 August checkpoints.](screenshots/51-saved-period-2026-10-22.jpg)

*Figure 34. WBS over time comparing the saved 13 July and 17 August checkpoints.*

Only snapshots strictly newer than the baseline are offered as saved endpoints. If no later capture exists, the end control may offer only Now and be disabled. Changing the baseline can reset an invalid end choice to Now. The comparison pair is shared by both Delta tabs.

An empty result may show **No qualifying changes** even when the source work is present. WBS over time compares the hierarchy and status fields used for reporting; it does not audit every edit.

## 21. GANTT over time: explain delivery movement

![GANTT over time comparing the August checkpoint with the current Example schedule.](screenshots/52-delta-gantt-2026-10-22.jpg)

*Figure 35. GANTT over time comparing the August checkpoint with the current Example schedule.*

### Step by step

1. Click **GANTT over time**.
2. Select the baseline and comparison end. The pair is shared with WBS over time.
3. Keep **Show dates** enabled when exact movement needs to be visible in the report.
4. Read each moving row's baseline and comparison delivery dates.
5. Use the legend to distinguish earlier finishes, later finishes, changed rows, delivery movement from re-anchoring, new work, and removals.
6. Expand a container to reveal changed descendants. Unchanged siblings do not become a full schedule just because you expand.
7. Follow hierarchy and highlighted dependency relationships to investigate a possible cascade.
8. Compare moved finishes with deadline and milestone references, then export the configured report.

Use **Root** to focus on a container without changing the comparison endpoints. The view focuses on meaningful schedule differences. An effort change appears in this view when it moves dates. A revised estimate alone is not reported as a duration change. Changes that finish entirely before the comparison window's historical cap can be omitted. The window starts seven days before the older endpoint's date so old completed history does not dominate the report.

Changing `reportingPeriod.from` can carry delivery dates forward even when work's position relative to the planning start stays similar. Sundial distinguishes this re-anchoring from a conventional delivery slip. Live Now also advances with the current local date unless a later start is configured. Read the calendar dates and legend before attributing a rightward movement to a delay in the team's work.

Dependency connectors show the relationships in the model. Links missing from a CSV export remain missing from the chart, so check the source data before attributing a date change to a dependency.

## 22. Scope: track estimate growth and reduction

Scope is a stacked-column history chart. Canceled effort is excluded from its simulation-based totals even though the original estimate remains stored on the work item. Each column shows the known total estimate at an observation; its colored segments show the selected root's constituent groups.

![Scope history with July and August checkpoints and the larger current Example; totals use PERT expected effort.](screenshots/53-scope-2026-10-22.jpg)

*Figure 36. Scope history with July and August checkpoints and the larger current Example; totals use PERT expected effort.*

### Step by step

1. Make sure the active history contains a saved snapshot.
2. Click **Scope**.
3. Leave **Root** set to **Project** to compare initiative/Release totals.
4. Read the observation labels horizontally and **Estimated effort (hours)** vertically.
5. Compare column totals, then identify the segments responsible for growth or reduction.
6. Hover a segment for the group, checkpoint, effort, and completeness details.
7. Choose an initiative/Release under **Root** to compare its direct epics instead.
8. Switch to **Milestones** to inspect delivery drift for the same selected root.

Scope counts the full declared estimate, including completed work still present. Spent work is not subtracted. A rising column can reflect added work or revised estimates; a falling column can reflect descoping, removal, or reduced estimates. Completion alone does not shrink the scope total.

Saved observations are grouped by UTC calendar day, using the latest capture on that day. **Current** is a separate live column from the latest successful current model, placed last. It is not another saved checkpoint. No columns are invented for days without snapshots. Missing estimates make the known subtotal partial; do not interpret omitted estimates as zero work.

Series colors identify groups and remain consistent within the history views. Native work has persistent identities across rename and reparent operations. Older reporting snapshots without stable identities can still fall back to a path, shown as `(path id)`; review continuity when comparing older exports.

## 23. Milestones: track delivery forecast drift

The Milestones tab is a history of delivery estimates. It differs from a list of standalone milestones: colored series show forecast or actual completion dates for initiatives/ Releases, or for epics beneath a selected initiative. Commitment dates appear as reference lines.

![Milestones Timeline with historical delivery observations, current forecasts, and commitment dates.](screenshots/54-milestones-2026-10-22.jpg)

*Figure 37. Milestones Timeline with historical delivery observations, current forecasts, and commitment dates.*

### Step by step

1. Click **Milestones** with a saved history series available.
2. Leave **Root** at **Project** for initiative/Release forecasts, or choose one initiative for its direct epics.
3. Read rows as saved observations, followed by **Current**.
4. On each row, locate the observation marker and the colored delivery marks for the series in the legend.
5. Read the delivery date from the horizontal calendar axis.
6. Follow a series' trend line across consecutive observations to see how its forecast moves.
7. Compare marks with the vertical goal/deadline references.
8. Hover marks for observation date, estimate date, delivery date, and actual-versus-forecast details. Export for a delivery-trend review.

A mark moving right across checkpoints indicates a later delivery estimate. As delivery approaches, check whether the forecast is stabilizing and how far it remains from the observation date. If the date keeps moving, review Scope and the Delta views to investigate the changes.

Colored marks show delivery dates. Lines connect the recorded forecasts; neither the marks nor the lines represent work duration. There are no readings for days without saved checkpoints. Missing work or missing forecasts can create gaps. A completed item's actual date differs in meaning from an unfinished item's forecast date.

Saved history uses the latest capture per UTC day, while Current remains separate. The Current observation uses the effective live forecast start. If a new edit fails, the view can retain the last successful Current point with a stale-state indication; correct the edit before reporting it as fresh. Root selection is shared with Scope.

To relate scope changes to delivery movement, choose **Scope** in the Milestones toolbar's **View** group:

1. Keep the same **Root** used in Timeline, or select an initiative to inspect its epics.
2. Read absolute delivery dates on the horizontal axis and total estimated scope in hours on the vertical axis. Each initiative or epic has its own colored path.
3. Follow the arrows in checkpoint order. Labels identify saved observations; an outlined diamond identifies **Current**.
4. Hover for the observation date, delivery date, scope, and any missing-estimate disclosures.
5. Switch back to **Timeline** to compare dates against snapshot rows, or export the selected presentation with **SVG** or **PNG**.

A move up and right means scope grew while delivery moved later. A horizontal move right means delay without net scope growth; additions and removals can still offset each other. Scope includes completed effort and excludes canceled effort, so completing work alone does not shrink it. Missing delivery or wholly unknown scope breaks a path. A partial estimate uses its known subtotal with a disclosure. Identical coordinates share a labeled point. These patterns show association and do not establish which change caused a delay. The presentation choice survives switching diagram tabs during the session.

![Milestones Scope presentation relating expected effort to delivery across the Example checkpoints.](screenshots/63-milestones-scope-2026-10-22.jpg)

*Figure 38. Milestones Scope presentation relating expected effort to delivery across the Example checkpoints.*

## 24. Team what-if: compare staffing choices

Team what-if runs the same project inputs with **Current team** and an alternative roster. Compare the results to see how the staffing choice affects forecast delivery.

![Current team compared with Without Noa using the expanded Example and current forecast date.](screenshots/55-team-what-if-2026-10-22.jpg)

*Figure 39. Current team compared with Without Noa using the expanded Example and current forecast date.*

### Remove a member temporarily

1. Click **Team what-if**.
2. Enter a useful **What-if team name**, such as "Without Noa".
3. Uncheck the member under **Use**. All current members begin checked.
4. Wait for the alternative forecast to update.
5. Read the project-finish comparison, deadlines met, and earlier/later/unchanged deliverable counts.
6. Inspect individual rows: reference and alternative finish dates, direction of change, and deadline status.
7. Enable **Show all deliverables** if unchanged results are also needed; the default focuses on shifts and deadline-bearing work.
8. Use **Reset** to restore current members and clear additions. Check the scenario name separately and change it back if necessary.

Unchecking a member changes only the alternative roster. The committed Team remains the reference. Work pinned to an excluded person is released for reassignment in the alternative; review whether another eligible member can actually take it. If work cannot be scheduled, its result is missing. Do not read that as a zero-day shift.

### Add a hypothetical member

1. Click **Edit added members**.
2. Replace the placeholder name with a unique name for the hypothetical member.
3. Replace the placeholder joining date with an explicit intended start date. Set skills, default daily allocation and any dated overrides, concurrency, speed, and an appropriate location.
4. Wait for validation and the alternative run to update.
5. Use **+ Add another member** for further additions, giving each a unique name.
6. Close the additions editor to give the comparison more space.
7. Review the delivery impact and export the result with **Show title** enabled.

Every scenario-only added member needs an explicit joining date, including an immediate joiner. Replace both the placeholder name and the placeholder date in the supplied additions template. The what-if simulation gives that person no capacity before the declared start. From that date, it uses their default hours and applicable overrides. This joining-date gate is specific to scenario additions; in the reference Team form, use a zero default and a positive override from the joining date for the same effect.

Existing locations can be referenced. A new scenario-only location can be declared in the additions fragment; it cannot override an existing location's calendar. The untouched placeholder template does not add a person. The structured Team form edits the reference team; the separate what-if additions editor remains a text editor. Correct invalid additions before using the alternative forecast. If you exclude every member and add no capacity, Sundial reports a no-capacity state.

Read calendar warnings before interpreting shifts. If holiday data is incomplete, the comparison marks the dates provisional instead of presenting a staffing improvement as confirmed. Missing or partial delivery on one side is disclosed separately from a zero-day change; resolve the inputs before making a commitment.

Roster search filters visible names without changing the included team. Hover member details to review skills and capacity. Sundial keeps scenario inputs for the session and has no saved named-scenario file format. To keep a record of the comparison, write down the roster assumptions and export an image.

## 25. Export diagrams and build a report

For an inspection copy of the current project, use **Export** in the main header:

1. Apply any form drafts whose changes should be included.
2. Choose **Export** and locate the downloaded project-named YAML file. A connected folder is not required.
3. Keep that file for inspection or sharing a current-state report. It includes work, comments, workflow configuration, Team, sprint records and membership, and Kanban settings.

This export omits native collaboration history, structured project audit history, reporting snapshots, detailed workflow and effort audits, and frozen sprint completion-board payloads. It is not a full backup or a native Open target. Back up the complete .sundial folder for those purposes. No configuration code needs to be copied from this manual.

### Export one diagram

1. Open the required tab and wait for its data to be ready.
2. Set root, comparison endpoints, depth/disclosure, counters, assignee display, resolution, or scenario controls as appropriate.
3. Enable **Show title**. For Delta GANTT, keep **Show dates** when exact movement is important.
4. Click **SVG** or **PNG** in the diagram toolbar.
5. Save the file, or locate the browser download.
6. Open the saved image and check its title, legend, filters, and readability.

SVG preserves vector quality and supported source links. PNG is convenient for a blog, slide, or document. Static exports do not include hover popups or interactive disclosure controls. Exported images include a Sundial caption with the tool's web address; SVG retains the caption's link. Exports include the chart content with its filters applied, regardless of scroll position or viewport zoom. Very large PNG canvases may be uniformly downscaled; SVG retains natural dimensions.

### Export a bundle

1. Build a successful current forecast.
2. Select the intended Delta period and history root; prepare the staffing scenario if needed.
3. Use the header's **Export SVG** or **Export PNG**.
4. Save the ZIP and confirm the exported diagram count.
5. Extract and review its files before sharing.

The archive includes available current, Delta, history, and scenario charts. Charts lacking their required inputs may not be present; do not assume every archive contains a fixed count. A Team what-if result is included when its chart has been built. Export **Sunburst over time** separately from its own toolbar to preserve the selected side-by-side comparison. Individual files are named by chart kind, such as `wbsTree`, `gantt`, `sunburst`, `workTracker`, `deltaWbs`, `deltaGantt`, `scopeOverTime`, `milestoneOverTime`, and `teamScenarioGantt`.

### A useful review sequence

1. Update the work items, recorded effort, workflow states, priorities, and sprint plan.
2. Review the reference team's calendars and availability.
3. Check Delivery outlook and GANTT for commitments at risk.
4. Compare with the prior checkpoint using both Delta tabs.
5. Inspect Scope alongside Milestones to relate estimate changes to delivery movement.
6. Use Work tracker to investigate capacity or sequencing.
7. Test staffing options if the dates call for a decision.
8. Verify automatic saving, capture the accepted reporting checkpoint, and export the review images.

In the written report, give the reporting start and comparison endpoints. Explain the assumptions and any missing or approximate source data that affect the results. A screenshot of the interface is useful for teaching controls; Sundial's own PNG export is usually better for a chart-only publication.

## 26. Troubleshooting

| Symptom or diagnostic | What to check and do |
| --- | --- |
| Nothing to render yet | Open a valid native project or load Example, inspect Issues, and wait for a successful run. |
| Unknown field | The schema is strict. Remove the unsupported key or use its documented spelling. |
| Duplicate name / unknown reference | Give identities unique names and make dependencies, assignees, and locations reference existing entries exactly. |
| Effort on a container | Move estimates to leaves; let parents roll up totals. |
| Invalid spent effort | Review the estimate, recorded balance, and dated entries. Add positive hours with at most two decimal places and a valid developer/date. Mark completed work Done; do not erase its recorded effort history. |
| Missing or invalid done dates | Supply valid historical start and finish dates strictly before reporting start; correct the source/export date evidence. |
| Dependency cycle | Follow the listed cycle and remove or correct the circular prerequisites. |
| ImpossibleTask / Unreachable | Check explicit skill exclusions and the dependency chain. Correct team or work assumptions before claiming deliverability. |
| Canceled prerequisite leaves dependents unscheduled | Reopen the prerequisite or deliberately revise the dependency. Cancellation is not successful delivery. |
| Workflow changes cannot be applied | Keep an ordinary state in each category, a Backlog default, and valid references. Check terminal Done states, replacement mappings, and allowed routes. Close/reopen stale settings and preview again. |
| Status or Kanban drop is unavailable | Check Next states in Workflow settings. Use the allowed route, such as In progress → Review → Done. Done is terminal; Undo can reverse a mistaken completion. |
| Apply asks to add or clear a comment | Choose Add comment for pending New comment text, or clear it before applying. |
| Sunburst history period is blank | Check snapshot readability, selected-root presence, and missing estimates. A zero-effort period has no angular span. |
| Urgent task still starts later | Deadline urgency, dependencies, dates, eligibility, capacity, and already started work can precede the preference. |
| Completed sprint shows old column names | Its historical board preserves the workflow captured at completion. Open the live project for current states. |
| SimulationExceeded or unfinished work | Check blocked tasks, availability gaps, future starts, project access, pinned assignments, and the simulation limit. Extending the limit alone does not resolve a constraint. |
| Forecast seems too early | Check missing dependencies, underestimation, omitted work, overstated allocation/speed, and missing holiday data. |
| No saved history | Capture a checkpoint, verify the active store, and refresh History. A lone unsaved Current model does not provide saved history. |
| Empty Delta report | Verify the endpoints and filters. Identical or non-qualifying changes legitimately give an empty comparison. |
| Desired comparison end missing | Saved end must be strictly later than baseline. Select an older baseline; verify the checkpoint is in the active store. |
| Path identity warning or split series | Review renamed/moved items and source identity continuity; do not read a split as automatic scope creation. |
| Stale Current result | Correct the failing current edit and wait for a successful run. Saved checkpoints are separate from that failed edit. |
| MissingColumn | Include Issue key and Summary or configure valid column aliases. |
| TooManyFiles | Select one CSV alone, or a set of JSON dump files. |
| Unmapped imported status | In Workflow settings, add an exact Tracker status mapping and retry import. Default-workflow fallback warnings may instead require an import mapping. |
| OrphanParent / ExternalDependency | Check export completeness, parent levels, permissions, and missing linked work. |
| AmbiguousDateOrder | Specify `dateOrder: dmy` or `mdy` to match numeric slash dates. |
| UnestimatedItem / MissingEstimate / missing delivery date | Add an estimate to unknown work. It cannot receive an invented finish or satisfy a dependent task. Import policies can reject, skip, or supply a disclosed fallback; current native forecasts show missing work separately. |
| CsvStartApproximated / UndatedVersion | Review CSV's historical-date and milestone limitations; use richer data where necessary. |
| EncodingUnsupported or garbled text | Re-export as UTF-8 CSV. Some BOM-marked UTF-16 dumps can be decoded, but unsupported forms need conversion. |
| SeedNoAssignees | Include assignees for a fresh seed, or import into a valid model with an existing team. |
| Added member has no effect | Replace both placeholder name and joining date, check skills and valid inputs, and verify the person is included. |
| What-if has no alternative forecast | Restore at least one valid member or addition; fix additions errors and inspect unscheduled constraints. |
| Team form shows Draft but forecast is unchanged | Click Apply changes to commit valid form inputs; entering a draft does not alter the forecast. |
| Changes were not applied | Correct highlighted names, skill duplicates, access chips, numbers, dates, overlap, or calendar codes, then apply again. |
| Reload draft notice | The Team document changed underneath the draft. Reload from the current document before editing again. |
| Developer rename blocked | Correct the loaded Project so task assignee references can be checked and updated safely. |
| Developer deletion blocked | Keep at least one developer and remove or change the member's Project assignments first. |
| Location deletion blocked | Apply new location assignments for all developers still referencing it. |
| Unexpected capacity between override periods | Outside override periods, the default applies, normally eight hours if omitted. Use an explicit zero default for interval-only participation. |
| Snapshot capture failed | Inspect folder permissions, browser storage quota, and the capture notice; verify the new entry exists. |
| Snapshot storage cannot be switched | Reconnect the old folder and resolve copy or quota errors. Sundial copies the existing history before activating a new target. |
| Folder permission expired | Use Reconnect snapshots folder and grant access again. |
| Export failed | Wait for valid chart data, check the selected output location, and retry. Inspect large-image readability after saving. |
| Text too small in diagrams | Maximize the window, choose Diagrams, hide Delivery outlook details, zoom for inspection, or export SVG. |

### Shared editing and planning problems

| Symptom | What to check and do |
| --- | --- |
| Colleague does not see an edit | Confirm both opened the same native folder, the draft was applied, saving succeeded, and the share is propagating complete files. Allow for polling and filesystem delay. |
| Native save failed | Restore folder access or browser permission and use Retry. Keep the working session open until persisted. |
| Recovery restored but not saved to disk | Choose Reconnect project folder and select the original .sundial folder. Recovery and disk connection are separate. |
| Synchronization unavailable | Restore access to the share, use Retry synchronization, and inspect remaining notices. Local recovery does not prove remote users received the edit. |
| Browser recovery write failed | Keep the session open, restore browser storage access or space, and use the recovery notice's Retry. |
| ConcurrentFieldWrite | Review the listed alternatives with collaborators, then apply the agreed field value after receiving their edits. |
| ModifiedAfterDelete / ConcurrentDeleteRestore | Decide explicitly whether to keep the deletion or restore the original task; then review dependencies. |
| UnsupportedSchema | Use a compatible newer Sundial version. Editing is disabled when an unsupported remote upgrade arrives. |
| Draft cannot overwrite the current document | Reload draft and re-enter intended changes against the new committed Project/Team. |
| Sprint refresh import blocked | Back up and retain the project, or deliberately choose a fresh import understanding that it replaces sprint metadata. |
| Cannot start sprint | Check for an existing Active sprint and whether the selected sprint has unfinished work. |
| Capacity seems too generous | Check calendars, unestimated/unassigned work, speed assumptions, and other commitments. The panel compares effort with calendar hours without speed adjustment; outside-sprint work is not deducted. |
| Sprint snapshot retry needed | Reconnect or repair the reporting snapshot store, then Retry snapshot; native-save Retry is separate. |

## 27. Keyboard and control reference

| Action | Shortcut or control |
| --- | --- |
| Commit Project / Team form | Apply / Apply changes; committed changes save automatically |
| Capture Project-and-Team reporting checkpoint | Ctrl+Shift+S; resolve pending form drafts first |
| Undo / Redo committed model changes | Toolbar buttons; Ctrl+Z / Ctrl+Y or Ctrl+Shift+Z when focus is outside editing fields and dialogs |
| Zoom at cursor | Ctrl+wheel |
| Return to whole-diagram overview | Fit |
| Close Import or History panel | Escape or outside click |
| Clear supported chart selection | Escape or chart background click |
| Recover diagram space | Diagrams workspace, large window, Delivery outlook → Hide details |
| Save a leaf estimate inline | Enter or leave the Project estimate field; Escape cancels |
| Add a comment | Comments → New comment → Add comment → Apply |
| Export current project data | Header → Export |

Sundial intercepts plain Ctrl+S without performing a save. Use Apply to commit a draft and Snapshot to capture a reporting checkpoint.

## 28. Glossary

| Term | Meaning in Sundial |
| --- | --- |
| Baseline | Saved snapshot used as the starting endpoint of a Delta comparison. |
| Current / Now | Latest successfully processed current model; distinct from a saved checkpoint. |
| Delta | Difference between a baseline and current model or later saved snapshot. |
| Effort | Total declared work estimate, normalized to hours for presentation. |
| Spent | Recorded effort already performed; the task form aggregates its baseline and entries. |
| Remaining effort | Total effort minus spent effort, used for scheduling. |
| Forecast | Deterministic simulated delivery under declared assumptions. |
| Initiative / Release | Project-level grouping; history specifications use Release terminology. |
| Milestone | Standalone commitment date with no work or dependency of its own. |
| Deadline / Goal | Deliverable need-by date, shown as a reference or emphasized goal where applicable. |
| Reporting snapshot | Dated Project-and-Team checkpoint for Delta/history charts, distinct from native startup snapshots. |
| Reporting start | Date from which remaining work is simulated. |
| Draft | Project, Team, or planning inputs not yet committed with Apply or the relevant confirmation. |
| Default capacity | Daily available hours used on working days outside overrides. |
| Scheduled override | Inclusive period whose daily hours replace the default; calendars still apply. |
| Work tracker | Heatmap of simulated developer allocation, not a timesheet system. |
| What-if roster | Alternative team assembled without editing the reference Team. |
| Native container | The .sundial folder holding authoritative collaboration state and history. |
| Concurrent edit | Independent changes made by separate browser instances before receiving each other's work. |
| Conflict | Retained competing field values or edit/delete intentions requiring a decision. |
| Tombstone | Recoverable native record of a deleted task, retaining its identity and history. |
| Workflow state | Named, colored step in the project process, mapped to one simulation category. |
| Simulation category | Backlog, In progress, Blocked, or Done scheduling behavior behind a detailed state. |
| Canceled outcome | Terminal non-delivery retaining history, using no future capacity, and satisfying no dependencies. |
| Effective priority | Explicit priority, nearest explicit ancestor priority, or Normal by default. |
| Manual order | Preference among eligible unfinished leaves at the same effective priority. |
| Acceptance criteria | Markdown description of observable completion conditions; not an executable completion gate. |
| Sprint scope | Actionable work assigned to a sprint, independent of task status. |
| Sprint capacity | Remaining estimated sprint effort compared with calendar hours, without developer speed or outside-sprint work. |
| Issue key | Project prefix and allocated issue number, separate from native identity and hierarchy position. |
| Next states | Allowed outgoing workflow destinations; an empty list is terminal. |
| Comment | Append-only Markdown note with a stored UTC timestamp, persisted when the task draft is applied. |
| Sunburst over time | Up to two historical Sunbursts beside Current, using one angular effort scale. |
| Milestones Scope mode | Delivery date versus total estimated effort for each observation. |

## 29. Further reading

For the project-reporting approach, read Stefano Tommesani's articles on [workflow simulation](https://tommesani.com/day-by-day-forecasting-project-completion-through-work-flow-simulation/), [change reporting](https://tommesani.com/changes-or-what-did-we-do-last-month/), and [sunburst project health](https://tommesani.com/visualizing-project-health-at-a-glance-with-sunburst-diagrams/).

For diagram background, see [PMI on work breakdown and scheduling](https://www.pmi.org/learning/library/schedule-101-basic-best-practices-6701/), [Asana on Gantt charts](https://asana.com/resources/gantt-chart-basics), [Plotly on sunburst charts](https://plotly.com/python/sunburst-charts/), and [Plotly on heatmaps](https://plotly.com/python/heatmaps/).

For collaboration background, see [Automerge's local-first overview](https://automerge.org/docs/hello/) and [concurrent field conflicts](https://automerge.org/docs/reference/documents/conflicts/). For board context, see [Atlassian's Kanban guide](https://www.atlassian.com/agile/kanban/boards).

Screenshots from section 3 onward were refreshed on 22 October 2026 at 1920 × 1080 using the current **Example** data. The opening and its screenshot are preserved. New captures cover all eleven diagram tabs, Work tracker Capacity mode, PERT estimates, login, and the two Audit panels. Demonstration drafts were discarded; the fresh Example has no committed audit edits.