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
• Briefings (formerly Daily Digest) — your once-a-day summary of inboxes and sessions. On by default; turn it off in Settings → Email & Summaries → Briefings. 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.

Every group collapsed once, for installs that already existed (2026-10-02)

All nine parent groups have shipped collapsed by default since 2026-08-19, so a fresh install opens tidy. An install that predates that — or whose user changed anything — carries a stored value, and stored settings are never overwritten by a new default, so those sidebars stayed however they had been left. A one-time migration now writes all nine flags to collapsed once for an existing install, so it matches what a new user sees.

• It runs exactly once, guarded by an internal sentinel. Any group you open afterwards stays open — this resets a default, it does not lock anything.
• Pinned rows are untouched. Pinned individual projects and pinned dividers keep their own state. (A pinned group collapses like any other group — the collapsed state is per group, not per placement.)
• Only the nine groups. The Plugins section still ships expanded, and a group added later gets its own default instead of being swept up by this reset.

Nothing is deleted and no project moves — it is nine booleans in your settings, once.

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, 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, Briefings, 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. 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 ("Recovery failed") waits in that hub's Interrupted list too — it has no Inbox row and does not chime.

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.
• Automation Rules shows an amber count of automation rules waiting for your approval (rules an agent created that you have not approved yet). They count here, on the screen that lists them, and nowhere else in the sidebar — not on the Texts, Gmail, Telegram or Slack row a rule is for, and not on Cron Jobs. With the Automation Rules screen switched off, its row is hidden and a waiting rule shows only in the Inbox badge. Middle-clicking the row offers to reject exactly those rules, behind a confirmation that warns it cannot be undone.
• 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. Those are real alerts only: a card an agent session raised is a message, is not listed on that screen, and is not counted here. 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. Middle-clicking the Alerts row offers to clear exactly the alerts that screen lists — never an agent's message — and with nothing listed it offers nothing.

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: <prev> }) in src/main/db/queries-projects/projects.ts, where <prev> 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, automation-group.md and insights-group.md. The mobile-parity gap that mattered most on camera is described in 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; for the "show only active" hiding that interacts with the same counts, see show-only-active-projects.md. Managing the list itself is covered by add-a-project.md, edit-a-project.md, reorder-projects.md and delete-a-project.md, and moving several at once on a phone is bulk-select-sidebar.md.