--- title: Projects Sidebar — Default "Omniscio" Group --- # Projects Sidebar — Default "Omniscio" Group Fresh Omniscio installs show a collapsible divider labeled **Omniscio** at the top of the projects sidebar. It groups the built-in virtual projects so they don't clutter the top of your real-project list. ## What it is The **Omniscio** divider is a standard, user-editable sidebar group that arrives pre-populated with Omniscio's own built-in virtual projects — the search, automation, insight and configuration panels that ship with the app rather than being folders on your disk. Its job is tidiness: those built-ins would otherwise sit at the very top of your project list, above everything you actually work in. ### Default Omniscio group on a fresh install The sidebar opens with an **Omniscio** divider pinned at the top. Click its chevron to expand or collapse. Inside you'll find these virtual projects: - **Session Search** — Claude-powered natural-language search over past sessions - **Quick Replies** — saved snippet templates for replies - **Automations** — auto-response and trigger rules - **Daily Digest** — once-a-day summary of your inboxes and sessions, shown only if you've enabled it in Settings → Daily Digest. When enabled, lazy-created between Automations and Recipes. - **Recipes** — the recipe library - **Cron Jobs** — scheduled automation jobs - **Skills** — the skills catalog - **CLI Tools** — installed CLI tools (git, gh, claude, etc.) - **Tags** — sidebar virtual project surfacing the curated session-tag library; lists every tag with usage counts, drill into a tag to see every session carrying it grouped by project - **Foundry** — PRD (product requirements document) generator plugin, shown only if you have the Foundry plugin enabled - **AI Coaching** — long-running coaching sessions that grade your replies and suggest improvements - **Suggestions** — Workflow Coach suggestion queue, surfacing the unread `state='new'` count as an amber attention badge - **Stats** — cost, tokens, time, per-project breakdown, feature usage, trends - **Settings** — virtual project surfacing app settings as a project pane Workflow-grouped order — daily-touch items at top, configuration last. Defined by `INTEGRATION_REGISTRY` (`src/shared/integration-registry.ts`) and migration v118 (which superseded v109's earlier ordering). Any real projects you create land below the Omniscio group as normal. ## Where to find it It is the **projects sidebar** — the left rail of the main window, where every project and hub is listed. The **Omniscio** divider sits pinned at the top of that list; click the chevron on its header row to expand or collapse it, and the same click toggles each sub-group row nested inside. The phone view of the Projects list shows the same grouping, the same visibility rules and the same collapse state, so collapsing a group on the desktop collapses it on the phone too. ## How it behaves ### Collapsible sub-groups inside the Omniscio group (2026-06-05) To keep the Omniscio group tidy, several built-ins are nested under collapsible **sub-group** rows (the same chevron pattern as Agent Tools). Click a sub-group's chevron to expand/collapse it; the choice persists: - **Agent Tools** — CLI Tools, Skills, MCP Servers, API Keys (expanded by default). - **Automation** — Cron Jobs, Recipes, Automations, Quick Replies, Scheduled Messages (collapsed by default; the Scheduled Messages row is itself hidden by default — see below). - **Insights** — Stats, Shares (collapsed by default). - **Developer Tools** — Dev Pipeline, Job Monitor, Running Apps, plus a **New Terminal** launcher row (collapsed by default). Marketplace plugins are NOT listed here — they live in the **Plugins** section, because a plugin's sidebar row is its only entry point and a collapsed group hides its rows completely. Each member keeps its own on/off switch, so it appears once enabled; the New Terminal row opens a terminal in the project you're currently working in (greyed out when you're not on a project that has files). See [developer-tools-group.md](developer-tools-group.md). Three rows are **hidden from the sidebar by default** because they are reachable elsewhere — the underlying features keep working: - **Scratchpads** — open it from the toolbar button or its keyboard shortcut. Re-show the row at Settings → Features → "Show Scratchpads in sidebar". - **Job Monitor** — off by default; its process tracking still runs. Re-show the row at Settings → Features → "Show Job Monitor in sidebar". - **Scheduled Messages** — on by default (a fired note still lands in your inbox); only the sidebar row and its compose surface are hidden. Re-show the row at Settings → Features → "Show Scheduled Messages in sidebar". These are render-only changes (`SIDEBAR_PARENT_GROUPS` + `SIDEBAR_RENDER_GATES`) — nothing is deleted and no data moves. See [automation-group.md](automation-group.md), [insights-group.md](insights-group.md), and the `agent-tools contract`. ### Omniscio vs Plugins master groups (2026-06-06) The Omniscio group is split into **two labelled master groups** so it's clear which tools are Omniscio's pre-activated core and which are optional add-ons you turn on: - **Omniscio** — native, pre-activated tools: Ask Omniscio, Agent Tools, Automation, Insights, Developer Tools, Session Search, Scratchpads, Job Monitor, Tags, Settings (plus the sub-groups above). - **Plugins** — activatable tools: Tasks, Tasks, AI Coaching, Alarms, Alerts, Browser, Bug Intake, ContextDock, Daily Digest, Drip, Email Summarizer, FlowVoice, Inbox Pilot, KMS, Marketplace, Marketplace Review, Foundry, PR Merge Queue, Pull Requests, RepoGuard, Screen Recordings, Ollert, Zoom — plus board integrations (Jira, Linear). A tool only appears once you've enabled it; nothing's on/off state changed when the grouping shipped. Click the **Plugins** header's chevron to collapse just the plugin tools (your choice persists). This is a render-only, visual grouping — no data moves. Note: collapsing the whole **Omniscio** divider still hides everything under it, including Plugins. Each built-in declares its group via a `tier: 'native' | 'plugin'` field on its manifest. For agents: the split is a pure transform (`groupPluginIntegrations` in `src/renderer/src/features/dashboard/plugins-group.ts`) keyed off `AMC_PLUGIN_PROJECT_PATHS` (`src/shared/types.ts`); full rules + invariants in the `sidebar plugin-tier contract`. ### Mobile sidebar matches desktop (2026-06-07) The phone view of the Projects list (over Tailscale, or any narrow window) now shows the **same** grouping and visibility as the desktop sidebar. Previously mobile rendered a flat, unfiltered list — rows you'd turned off, or that are hidden by default (Browser, AI Coaching, Marketplace Review, Alerts, Automations, Job Monitor, Scratchpads, …), still showed, and the Agent Tools / Automation / Insights groups, the Plugins split, and the Unused section never appeared. Both surfaces now compute their list from one shared place (`src/renderer/src/features/dashboard/sidebar-grouping.ts` `useSidebarGrouping`), so any grouping or visibility change reaches mobile automatically, and collapse state is shared (collapse a group on desktop and it's collapsed on the phone too). For agents: a build-failing guard pins `src/renderer/src/features/dashboard/MobileProjectsList.tsx` to the shared filter + hook so the two lists can't silently diverge again. **One gap closed later (2026-09-05):** this parity never covered **Presentation Mode**. The phone list applied no presentation filtering and no name masking at all, so while the desktop rail hid your real project names on camera, the phone showed them. It now applies the same hiding and the same blur/placeholder masking, and explains itself the same way when a hide empties the list — see [presentation-mode.md](presentation-mode.md). The coverage guard now names the mobile list explicitly, because its scan keys on a SESSION predicate and so could never have reached a list of projects on its own. ### Upgrading from an older version If you installed Omniscio before this feature shipped, eight database migrations handle the catch-up: - **v91** seeded the Omniscio divider and re-parented the original four Omniscio virtuals (Recipes, Skills, CLI Tools, Cron Jobs). - **v93** re-parents **Session Search** into the same divider (it joined the Omniscio-builtin set later). - **v94** re-parents **Foundry** into the same divider (the plugin joined the Omniscio-builtin set after v93). Naturally a no-op on installs that never enabled the plugin — there are no Foundry rows to update. - **v98** re-parents **Automations** and **Quick Replies** into the same divider (they joined the Omniscio-builtin set after v94). Naturally a no-op on installs that have never created either virtual. - **v99** re-parents **AI Coaching** into the same divider (it joined the Omniscio-builtin set after v98). Naturally a no-op on installs that have never enabled AI Coaching. - **v106** re-parents **Daily Digest** into the same divider (it joined the Omniscio-builtin set after v99). Naturally a no-op on installs that have never enabled Daily Digest. - **v109** seeded the original workflow-grouped order (Daily Digest at top of group, AI Coaching between Cron Jobs and Skills). Superseded by v118. - **v118** reseeds the Omniscio group's `display_order` to the current workflow-grouped default — Daily Digest moves between Automations and Recipes, AI Coaching moves between Foundry and Settings. Anchors on `MIN(display_order)` of just the rows it's reseeding (not the whole divider), so Ask Omniscio at MIN-1 and any user-dragged custom rows keep their positions. Naturally a no-op when the Omniscio divider has been deleted. All eight migrations only touch rows you haven't manually re-organized — v91-v106 re-parent ungrouped virtuals into the Omniscio divider, and v109/v118 reseed positions of rows still inside the Omniscio divider. None of them resurrect the Omniscio divider if you've deleted it. ### Moving a virtual out of the group Drag any virtual project out of the Omniscio divider the same way you'd move any project between dividers. The built-ins behave like every other project in the sidebar — the Omniscio divider is just a standard user-editable group with a default name and default children. ### Status counts on project rows Every project row can show small colored counts next to its name, shown **most-urgent first**: - **Red — interrupted** — sessions sitting in that hub's **Interrupted** list: **ended** (finished, resumable by a message), plus **errored** / **stalled** and other stopped or failed sessions. This surfaces the Interrupted pile on the hub row so you can tell at a glance which hubs have sessions parked there. It is a **passive glance count only** — it never adds an Inbox row, a chime, or a taskbar **Needs You** badge (interrupted sessions stay quiet everywhere else, by design). The count is drawn from the exact same rule as the in-hub Interrupted list, so the hub number equals the **Interrupted (N)** header when you open the hub. A **pinned** or **saved** session is not counted: it shows in its own Pinned or Saved section, not under the Interrupted header. (A rate-limited session does sit under that header but carries the separate orange count below, so the header equals red plus orange.) - **Amber** — sessions **waiting for your input** (a question or an approval to continue). - **Orange** — sessions **rate-limited** (auto-resumes on its own; needs nothing from you). Kept as its own count, separate from interrupted, so its distinct "just waiting on capacity" meaning stays clear. - **Green** — sessions **actively running**. Idle/settled sessions aren't shown as a count, and when everything is zero the row shows no count at all. > **Errored / stalled / ended sessions now show up here as the red "interrupted" count (updated 2026-08-22).** Before this, they were invisible on the hub row. They still stay out of your Inbox, the chime, and the taskbar **Needs You** badge (that quiet behavior, set 2026-08-11, is unchanged) — the interrupted count simply makes the sidebar reflect the sessions sitting in each hub's Interrupted list. A session that genuinely can't recover still surfaces in the Inbox as **"Recovery failed."** > **The interrupted count is now accurate on every hub, including on the phone (fixed 2026-08-24).** The finished-conversation (`ended`) part of the count is now computed on the backend and sent as a plain number, so it's correct on hubs you haven't opened this session **and** on the mobile Hubs list — which never loads past conversations, so those hubs previously showed no interrupted count at all. No past conversations are loaded to produce the number (only a count). At the time, a hub with a very large history showed the **true total** in its badge but only its most-recent slice in the list — that gap was closed on 2026-09-24 (below). > > **The desktop app now loads that number at startup too (fixed 2026-08-25).** The 2026-08-24 fix covered the phone and unopened hubs, but the desktop app fetched its startup data on a different path that skipped this number — so on desktop the badge showed only the still-running part of the count until a session next finished during that run. That's the "the hub shows 50 interrupted but the sidebar shows 1" gap: a hub with 50 finished conversations in its Interrupted list could badge as low as 1. The desktop now pulls the same backend number at startup, so the sidebar badge matches the hub's Interrupted list from the moment the app opens. > > **Busy hubs: the red number and the Interrupted header now always match (fixed 2026-09-24).** Opening a hub loaded only its 300 most recent sessions of every kind, so a busy hub — full of running sessions — loaded only part of its Interrupted pile, and the list came up short of the badge (reported: **311** on the hub row, **Interrupted (175)** in the list). Opening a hub now loads its whole Interrupted pile, whether or not "show ended sessions" is on. Pinned and saved sessions also stopped counting toward the red number, since they appear in their own sections rather than under the Interrupted header. **Email / plugin projects show their unread count in amber.** Rows that surface an unread tally instead of sessions — **Supermail** (the email plugin), **Gmail**, and the channel projects (SMS, Slack, …) — render that count (e.g. 20 unread emails) as an **amber** badge, the same colour used for sessions waiting on you. It is intentionally **not** the green "running" colour, which is reserved for sessions actively doing work. These rows usually have no sessions of their own, so the amber unread is often the only count they show — but it is never the _only_ count they CAN show. A channel project that also has sessions, or has an inbox item folded onto it (a calendar-attributed alert, say), renders those red/amber/green counts **alongside** the amber unread, with a small dot between the two groups so the two counts can't read as one number. Before 2026-09-15 the desktop row suppressed the session/alert counts entirely on a channel project, so such a hub was listed under "show only active" by a count it then refused to draw — a row that appeared to be there for no reason. ### Live status counts on Recipes, Cron Jobs, and Alarms The **Recipes**, **Cron Jobs**, **Alarms**, and **Alerts** rows show the same **green** (running) and **amber** (needs you) count badges that regular session-bearing project rows use, so you can see at a glance whether anything is currently running or needs your attention under any of them. These rows never show a **red** count — red is only for real sessions showing a red dot (errored, stalled, stopped, or a failed sub-state). - **Recipes** shows a **green** count of recipe runs in active states (`running`, `starting`, `paused`, `completing`) and an **amber** count of runs in `awaiting_approval` — pulsing, parallel to the "needs you" treatment on session rows. When all recipe runs are terminal (`idle`, `completed`, `error`) the badges disappear. - **Cron Jobs** shows a **green** count of cron jobs currently executing — both user-clicked "Run Now" jobs and scheduled fires. When no jobs are mid-run the badge disappears. - **Alarms** shows an **amber** count of fired alarms sitting in your inbox — pulsing, parallel to the "needs you" treatment on session rows. When you dismiss / snooze / handle every fired alarm, the badge disappears. - **Alerts** shows an **amber** count of the alerts the Agent Alerts screen is listing — the same list you get when you open the row, so the number and the rows always agree. As with Approvals, an alert raised against a real project also counts on that project's own row, so the same alert can legitimately appear on two rows. Snoozing an alert removes it from both. There is no "needs you" amber count on the Cron Jobs row — cron either runs or doesn't; there is no human-decision pause state in cron run state. There is no "currently running" green count on the Alarms row — alarms don't have a running notion. Other Omniscio-group rows (Daily Digest, Skills, Stats, Settings, Session Search, Quick Replies, Automations, AI Coaching, CLI Tools, Foundry) have no comparable "currently running" or "needs you" notion and don't render these counts. ### Deleting or renaming the Omniscio divider - **Renaming** (e.g., "My Built-ins") is fine — the divider keeps an internal `system_tag` marker, so renaming doesn't break anything. - **Deleting** the Omniscio divider un-groups its children — they become top-level projects. Omniscio will **not** resurrect the divider later. If you then enable a virtual project that wasn't previously created (e.g., turning Skills back on), the new virtual appears ungrouped rather than re-creating an Omniscio divider. ## For agents - The Omniscio divider is identified by `system_tag = 'amc_builtins'` on the `project_dividers` table — not by name — so user renames don't break lookup. - Canonical list of paths auto-grouped on first-run / migration: `AMC_BUILTIN_PROJECT_PATHS` in `src/shared/types.ts`. - Divider seeding + initial re-parenting of the original four virtuals: migration v91 (`src/main/db/database.ts`). - Re-parenting of Session Search into the Omniscio group: migration v93 (same file). It only runs for rows that are still ungrouped and non-deleted; it is a no-op if the user has deleted the Omniscio divider. - Re-parenting of Foundry into the Omniscio group: migration v94 (same file). Same invariants as v91/v93; naturally a no-op on installs that never enabled the Foundry plugin (no rows with `folder_path = '__plugin_prdstack__'` to update). - Re-parenting of Automations + Quick Replies into the Omniscio group: migration v98 (same file). Same invariants; naturally a no-op on installs that have never created either virtual (no rows with `folder_path = '__automations__'` or `'__quick_replies__'` to update). - Re-parenting of AI Coaching into the Omniscio group: migration v99 (same file). Same invariants; naturally a no-op on installs that have never enabled AI Coaching (no rows with `folder_path = '__ai_coaching__'` to update). - Re-parenting of Daily Digest into the Omniscio group: migration v106 (same file). Same invariants; naturally a no-op on installs that have never enabled Daily Digest (no rows with `folder_path = '__daily_digest__'` to update). Daily Digest is special-cased in `AMC_BUILTIN_PROJECT_PATHS` because its `INTEGRATION_REGISTRY` entry intentionally has no `virtualProjectPath` — that field would force unconditional startup creation, but Daily Digest is gated by the `dailyDigestEnabled` setting and lazy-created by `settings-handlers.ts` when the user toggles it on. The Set is therefore the registry-derived list **plus** an explicit `DAILY_DIGEST_PROJECT_ID` extension. - Reseed of Omniscio display order to the current default: migration v167 (same file, supersedes v118/v140/v150 and all earlier reseeds). v167 alphabetizes the 17 registry-derived entries A-Z by `displayName` (INTEGRATION_REGISTRY itself was reordered A-Z on 2026-05-13) and splices `DAILY_DIGEST_PROJECT_ID` at registry index 4 — between Cron Jobs (slot 3) and Email Summarizer (slot 4) — so the canonical Omniscio order becomes `... → Cron Jobs → Daily Digest → Email Summarizer → ...` whenever DD is enabled. Like v118 before it, v167 derives the ordered path list from `INTEGRATION_REGISTRY` (so the doc and DB stay in lockstep) and updates `display_order` only for rows where `folder_path` is in the ordered list AND `divider_id` matches the Omniscio divider AND `is_deleted = 0`. The IN-clause filter (rather than a divider-wide rewrite) means it anchors at `MIN(display_order)` of just the listed rows, leaving Ask Omniscio at MIN-1 (placed there by v110) and any user-dragged custom rows untouched. Does NOT auto-resurrect the Omniscio divider — no-op if the user deleted it. Lazy-create of Daily Digest after migration uses `createProject({ insertAfterFolderPath: })` in `src/main/db/queries-projects/projects.ts`, where `` is resolved by `pickAmcAlphaPrevAnchor(folderPath, dividerId)` from `src/main/services/amc-builtins-order.ts` — it walks the canonical A-Z list backwards from the target's slot and returns the first preceding sibling that exists on the divider, falling back to `ASK_AMC_PROJECT_ID` then `undefined` (bottom-of-divider append). For DD this resolves to `CRON_PROJECT_ID`, landing DD between Cron Jobs and Email Summarizer to match v167's spliced index-4 placement; second-call dedupe (existing folder_path guard in `createProject`) means a user-dragged DD stays where the user put it. - New virtuals created after startup are placed under the existing Omniscio divider by `ensureVirtualProject` in `src/main/index.ts`. Session Search has its own idempotent seeder, `ensureSearchSessionsProject` in `src/main/services/claude-project.ts`, and AI Coaching has `ensureAICoachingProject` in `src/main/services/ai/ai-coaching/session/shared.ts` — both follow the same divider-lookup pattern. If the divider has been deleted, new virtuals are created ungrouped — this is intentional (no auto-resurrect). - **Foundry is the only plugin special-cased this way.** Other enabled plugins still land ungrouped — there is no general "all plugins go in Omniscio" rule. The special-case is carried entirely by the `PRDSTACK_PROJECT_PATH` entry in `AMC_BUILTIN_PROJECT_PATHS`; removing that entry would revert Foundry to ungrouped placement on new installs (existing rows would stay where they are). - **Live status counts on Recipes, Cron Jobs, and Alarms rows** are augmented onto the row's `sessionCounts` object via the same `getProjectCounts` callback pattern that already wires Daily Digest unread, SMS unread, and AI suggestions. The augmentation pattern is codified at `.claude/memory/contracts/projects-sidebar-counts-contract.md` — read that first before touching any of the five augmentation memos. Note the base per-project counts split into `running` (green) / `attention` (amber, `needs_you`) / `error` (red, attention-gated — now ~always 0) / `waiting` (orange) / `interrupted` (red — the Interrupted-section pile: `ended` + failed `needs_you` sub-states + non-reconnecting `error`/`stalled`, via the shared `isInterruptedSectionMember`) / `idle`; the augmentation memos only ever add to `running`/`attention`, so virtual rows can never show a red count (contract I7/I8/I14). - **Recipes** pulls from `useRecipeStore.runs` via two primitive selectors `selectRecipeGreenCount` / `selectRecipeAmberCount` (`src/renderer/src/stores/recipe-store.ts`) — number returns, not object returns, to avoid identity-equality re-render storms. - **Cron Jobs** pulls from `useCronStore.runningJobIds.size`; the Set is updated by `handleRunStarted` / `handleRunCompleted` actions on the cron-store wired to push events `IPC.CRON_RUN_STARTED` / `IPC.CRON_RUN_COMPLETED` via `useIpcListener` in `src/renderer/src/features/dashboard/ProjectsSidebar.tsx`. Both push events fire for ALL cron run kinds (manual, scheduled, retry) — the user-click optimistic add + finally-remove path coexists safely with push-driven add because the Set makes both idempotent. One acknowledged edge case: if Omniscio crashes mid-run between `CRON_RUN_STARTED` and `CRON_RUN_COMPLETED`, an id stays in `runningJobIds` until the next reset (zustand reset on app unmount/restart, or implicit clear when the same job runs again) — accepted because it's rare and self-clearing. - **Alarms** (added 2026-05-25) reuses the existing `approvalCountsByProject` pipe rather than getting a dedicated `*ProjectCounts` memo. Fired alarms reach the renderer as inbox items with `integration === 'alarm-fired'` (the same shape as `cron-approval` / `automation-approval` / `cli-pending-approval`), so the augmentation is just two edits: extend the four-kind filter to also accept `alarm-fired`, and remap items carrying the `ALARMS_PROJECT_ID` sentinel to the Alarms virtual project's UUID. The catch-all fall-through at the bottom of `getProjectCounts` then adds `approvals` to `attention` for the Alarms UUID with no new branch needed. Snooze gating is already handled upstream in `alarmFiredInboxSelectItems` (`src/renderer/src/stores/inbox-sources.ts`) so the sidebar count automatically respects snoozes. - The recipes/cron/alarms project UUID is resolved via `projects.find(p => p.folderPath === RECIPES_PROJECT_ID / CRON_PROJECT_ID / ALARMS_PROJECT_ID)?.id` per the `digest-sidebar-badge postmortem` — never compare raw `id` against the sentinel string. The count memos return `null` when both counts are zero so `ProjectListItem`'s default `React.memo` shallow comparison holds (the row falls back to the original `sessionCountsMap` reference). - Coverage in `tests/unit/components/ProjectsSidebar.test.tsx` — `'recipes/cron virtual project running counts'` and `'alarms virtual project attention count'` describe blocks. - **Adding a new Omniscio-native virtual project** requires four things in lockstep so the structural test in `tests/unit/components/ProjectIcon.test.tsx` (the "Omniscio builtin icon coverage" describe block) stays green: (1) add the sentinel id to `AMC_BUILTIN_PROJECT_PATHS` in `src/shared/types.ts`, (2) add an icon branch to `src/renderer/src/components/ui/ProjectIcon.tsx`, (3) add a manifest entry to `INTEGRATION_REGISTRY` (`src/shared/integration-registry.ts`) at the slot where it should appear in the workflow-grouped order, and (4) ship a new data-only migration mirroring v98 to re-parent any pre-existing rows on upgraded installs. The icon coverage test iterates the Set and fails if any path falls through to the empty wrapper, so step (2) cannot be silently forgotten. Reordering an existing virtual is a one-line registry change plus a new migration that mirrors v167 (derives ordered path list from registry, anchors on MIN of the listed rows). ## Related If you want to understand the three collapsible sub-groups rather than the divider itself, each has its own page: [developer-tools-group.md](developer-tools-group.md), [automation-group.md](automation-group.md) and [insights-group.md](insights-group.md). The mobile-parity gap that mattered most on camera is described in [presentation-mode.md](presentation-mode.md), which is where a reader should go if real project names are showing on a screen you are sharing. For the sessions sitting behind the red interrupted count, see [interrupted-sessions-section.md](interrupted-sessions-section.md); for the "show only active" hiding that interacts with the same counts, see [show-only-active-projects.md](show-only-active-projects.md). Managing the list itself is covered by [add-a-project.md](add-a-project.md), [edit-a-project.md](edit-a-project.md), [reorder-projects.md](reorder-projects.md) and [delete-a-project.md](delete-a-project.md), and moving several at once on a phone is [bulk-select-sidebar.md](bulk-select-sidebar.md).