> For the complete documentation index, see [llms.txt](https://sandgarden.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sandgarden.gitbook.io/docs/work-history.md). # Work History ### Overview Work History lists each request as a record for the work item it tracks. Each row shows the publication, the kind of work, and the status. Opening an entry shows a sheet with tabs for **Details**, **Files**, **Messages**, and reasoning. For request triggers and entry points, see [Interacting with Doc Holiday](/docs/interactions.md). For publication trigger settings, see [Publications](/docs/publications.md). ### Details The **Details** tab shows a short summary of the request and the result it reached. Work History can show clearer status labels while work remains in progress. A staged item now appears as **In Progress**. If Doc Holiday's latest bot comment asks for follow up, Work History shows **Needs Attention** instead, and the status options can show those items directly. If an administrator cancels a running item, Work History shows **Cancelled** instead of leaving the run looking incomplete or failed. #### Merged conversations When a pull request or merge request has already merged, Work History shows who merged it and, when available, the merge time. #### Open a pull request or merge request After the run finishes, people with publication write access can open a pull request or merge request from a staged work item. 1. Open a Work History entry. 2. Select **Open PR** or **Open MR**. ### Files The **Files** tab lists the files modified during the run and shows file changes for each file. #### Preview a Markdown file Markdown files support a preview toggle that renders the full file content instead of only the file changes. #### Download a file 1. Open a Work History entry. 2. Select **Files**. 3. Select the download icon for a file. Note: Use **Download All** to download a single ZIP archive that contains every file listed in the **Files** view for the selected work item. #### Upload a file The **Files** tab uses a per-file upload action. People without publication write access can still review files and comments, but only people with write access can upload files or edit file contents. 1. Open a Work History entry. 2. Select **Files**. 3. Select the upload icon for a file. 4. Select a local file. Note: Upload is disabled while Doc Holiday is still making changes. #### Exclude a file from a pull or merge request The **Files** tab supports excluding specific files before opening a pull request (GitHub) or merge request (GitLab). 1. Open a Work History entry. 2. Select **Files**. 3. Discard the file that is unnecessary. To restore an excluded file, select the restore action for the file. Excluded files are tracked on the work state and are reflected in the **Files** tab. #### Add a file Files can be added directly from the **Files** tab on a draft work item by selecting a file and specifying a destination path. 1. Open a Work History entry. 2. Select **Files**. 3. Select the add file icon. 4. Enter the destination file path. 5. Select a local file. Note: Only people with publication write access can add files. #### Review file comments The **Files** tab supports inline file comments during review. It lets teams add comments on specific lines or ranges, reply in anchored threads, and review quoted file context beside the affected content. Work History keeps draft comments separate from comments already sent to Doc Holiday. Draft comments support multiline input, selected ranges can preview while drafting, and **Ctrl+Enter** or **Cmd+Enter** sends the comment. Comment controls and visibility can vary with the conversation state, publication access, and comment authorship. Reviewers can continue reading and discussing content, but only people with write access can send requests to Doc Holiday from file comments. Each comment also supports its own **Send to Doc** action from the comment menu, which makes it possible to forward a single comment without building a larger batch. Work History shows comment ranges and quoted file context in clear, human readable labels. It also links file comment threads with related conversation context. Comment filters can hide user comments, hide bot comments, hide outdated comments, or hide comments already sent to Doc Holiday. ### Messages The **Messages** view supports continued collaboration with Doc Holiday from the Work History entry. When a Work History entry has an open pull request or merge request, users can continue sending messages whenever the run status allows it. Some file comment threads include navigation back to related **Messages** context after the comment has already been sent to Doc Holiday. When the Work History entry is running, the **Messages** view instructs users to wait until Doc Holiday finishes before sending more messages. Users can still review message history from this view. When the Work History entry is ready for review and not running, users can open the send message form. ### Background tasks Background tasks can keep a work item in progress after the main request stays open. Background tasks generate simplified messages that hide the raw task payload. If someone stops the request, Doc Holiday also stops any background task that is still running. If a running background task becomes stale, Doc Holiday can restart it automatically up to a capped retry count. While the work item is running, the **Messages** view still requires publication write access for sending. ### Notifications When a publication has a notifier configured and the work item reaches **Ready for Review**, Work History shows a **Notify** action. If a background task finishes without opening a pull request or merge request, the completion comment links back to the Work History details page. Work History does not show **Notify** while the work item is still running.