feat: Home Tab

[k11kirky]

Home tab

Adds a new Home sidebar tab — an inbox-zero surface for the work around your agent tasks (PRs, CI, review requests, stale branches, cleanup), as opposed to the task list which shows what the agents themselves are doing.

The same workstream data renders three ways:

List (default) — severity-first triage: Needs attention / In progress, with a Watching counter pill.
Board — workflow-first kanban (No PR yet → In review → Needs me → Ready to merge → Cleanup).
Config — a drag-and-drop canvas where the user models the workflow that List and Board project over.
Per the architecture rules, the renderer is a thin client: all aggregation, PR polling, situation classification, and workflow-config persistence run server-side in PostHog (products/tasks/). The Electron app reads the finished HomeSnapshot / WorkflowConfig over the REST API and renders it — no gh polling or classification in the app.

The tab is gated behind the posthog-code-home-tab feature flag (sidebar entry + route are hidden when off).

Design docs: home-tab.md, workflow-architecture.md.

How to test

1. Backend branch. The server side lives in the posthog repo. Check out:

06-03-feat_posthog_code_home_tab_backend
(commit feat: Posthog code home tab backend). This adds products/tasks/backend/code_workstreams/ (classify/group/validate), the CodeWorkflowConfig / CodePrSnapshot / CodeWorkstream models + migrations, the /code_home/ + /code_workflow/ REST API, and the Temporal worker.

2. Enable the flag. Turn on posthog-code-home-tab for your user so the Home tab shows in the sidebar.

3. Manually drive an evaluation (instead of waiting for the 3-min Temporal schedule). From the posthog repo root, using the management command in products/tasks:

# List teams with recent code activity (then pick one)
python manage.py evaluate_code_workstreams

# Run one full evaluation cycle for a team: load PR URLs → poll GitHub → group + classify + upsert workstreams
python manage.py evaluate_code_workstreams --team-id <id>

# Grouping/classification only, skip the GitHub PR poll
python manage.py evaluate_code_workstreams --team-id <id> --skip-poll

#Probe a single PR — prints exactly what get_pull_request_snapshot returns (handy for debugging blank CI/review data)
python manage.py evaluate_code_workstreams --team-id <id> --pr-url <pr-url>
The command prints the CodePrSnapshot and CodeWorkstream rows it wrote, and explains common empty-result causes (no PR URL on tasks, GitHub App missing Checks: read / Pull requests: read, no task runs in the last 30 days).

4. Run the backend tests for the new logic. From products/tasks:

pnpm backend:test
(covers code_workstreams/ classify, grouping, and validation, plus the services/stream tests).

5. In the app, open Home and verify: the active-agents strip reflects running tasks, workstreams appear in List/Board after an evaluation, the view toggle (v) cycles List → Board → Config, and the Config canvas renders the default workflow.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
apps/code/src/renderer/features/home/config/ConfigMap.tsx:95-117
**Silent failure on network error during save/reset**

`onSave` and `onReset` both `await mutateAsync(…)` without a `try/catch`. When the tRPC call fails (network outage, server error, unexpected JSON shape from 409/422 triggering a Zod parse throw), `mutateAsync` rethrows the error: `onSave` then rejects, and because the keyboard handler calls `void onSave()` (discarding the promise) and the button `onClick={onSave}` doesn't catch rejections either, the user gets absolutely no feedback — no toast, no error state. The same issue applies to `onReset`.

### Issue 2 of 3
apps/code/src/main/services/home/service.ts:49-60
**First background poll always emits regardless of change**

`getSnapshot()` (called by the TRPC query on initial render) fetches the snapshot without updating `lastSerialized`. When the background poll fires 120 seconds later, `lastSerialized` is still `null`, so `serialized !== null` is always true and `SnapshotUpdated` is emitted — pushing a full snapshot update to every subscriber even when nothing has changed. The poll's change-detection only kicks in from the second poll onward. A simple fix is to update `lastSerialized` in `getSnapshot()` after a successful fetch.

### Issue 3 of 3
apps/code/src/main/services/workflow/default-workflow.ts:1-59
**Default workflow violates its own schema**

`buildDefaultWorkflow()` is typed as `WorkflowConfig` (inferred from the Zod schema) but every action has `skillId: ""`, which fails the `workflowAction` constraint `z.string().min(1)`. The object would not survive `workflowConfig.parse()`. TypeScript doesn't flag this because Zod's `min` is a runtime-only constraint. The intent is clearly that users must pick skills before saving (the validator correctly flags empty `skillId` as an error), but there's no indication that this object is intentionally non-compliant, and future readers may trust the typed return value. Annotating the return type as `Omit<WorkflowConfig, 'bindings'> & { bindings: ... }` or using a separate `WorkflowTemplate` type would make the intent explicit.

_{Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile}

[github-actions]

React Doctor found 5 issues in 3 files · 5 warnings.

5 warnings

src/renderer/features/home/config/SituationStation.tsx

• ⚠️ src/renderer/features/home/config/SituationStation.tsx:97 Nested interactive elements html-no-nested-interactive
• ⚠️ src/renderer/features/home/config/SituationStation.tsx:119 Nested interactive elements html-no-nested-interactive

src/renderer/features/sidebar/components/SidebarMenu.tsx

• ⚠️ src/renderer/features/sidebar/components/SidebarMenu.tsx:131 Pure function rebuilt every render prefer-module-scope-pure-function

src/renderer/routes/__root.tsx

• ⚠️ src/renderer/routes/__root.tsx:175 State only used in handlers rerender-state-only-in-handlers
• ⚠️ src/renderer/routes/__root.tsx:178 Event logic handled in an effect no-event-handler

_{Reviewed by React Doctor for commit 1b07d12.}

[charlesvien]

I added a few commits. Generally looks good to me, esp. for being an experiment that we plan to iterate on we don't have to be super critical of every little thing. Going to stamp as to not block, we'll follow up with bug fixes and whatever in later commits!