chore(tasks): remove code home, workstream grouping, and auto runs

[k11kirky]

Problem

The PostHog Code Home Tab — with its workstream grouping and auto-run workflow actions — is being removed from the product. This PR removes its server side; the client side is removed in PostHog/code#3692.

Changes

• Delete the code_home / code_workflow viewsets and their project-router registrations.
• Delete the logic/code_workstreams/ package (grouping, situation classification, binding validation, default workflow) and the temporal/code_workstreams/ package (the evaluate-code-workstreams parent/child workflows, their five activities, the 3-minute schedule, and the on-demand trigger client), plus the evaluate_code_workstreams management command.
• Remove the CodeWorkflowConfig, CodePrSnapshot, and CodeWorkstream models with a state-only migration (SeparateDatabaseAndState); the tables stay in place for a follow-up RunSQL drop after a deploy cycle, per the safe-migrations handbook.
• Remove the home_quick_action run-bootstrap serializer field, its RunState field, and its handling in bootstrap_task_run; regenerate the OpenAPI-derived types (api.schemas.ts, api.zod.ts, MCP generated.ts).
• Remove the three models from the IDOR semgrep allowlist and the schedule registration from posthog/temporal/schedule.py.

Deploy notes: the evaluate-code-workstreams-schedule Temporal schedule stops being (re)created by bootstrap but the existing schedule object should be deleted manually in Temporal; any in-flight evaluate-code-workstreams executions will fail replay once workers deploy without the workflow registered (they are 3-minutely, short-lived scans, so this is acceptable).

How did you test this code?

Automated checks run by the agent (no manual testing):

• manage.py makemigrations --check --dry-run — no drift; sqlmigrate tasks 0069 renders as a state-only no-op.
• Import checks of every touched module (facade, routes, serializers, temporal registry, schedule) under django.setup().
• ruff check/ruff format, tach check --dependencies --interfaces, and hogli ci:preflight --fix — all green, 0 failures.
• hogli build:openapi — regenerated types; diff is exactly the removed field.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

No docs under docs/ reference the removed endpoints or models.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

• Authored with PostHog Code (Claude). Skills invoked: /django-migrations (state-only model deletion pattern) and the repo's temporal-workflow-versioning and product-isolation rules.
• Mapped the feature surface with a repo-wide search before deleting; left the historical 0037/0039 migrations and cross-app migration dependencies untouched, and left products/review_hog/DECISIONS.md (an append-only design-history record) as-is.
• Chose a state-only DeleteModel migration over a table drop so the removal is deploy-safe; the drop is deferred to a follow-up.

---

Created with PostHog Code

[github-actions]

Hey @k11kirky! 👋

It looks like your git author email on this PR isn't your @posthog.com address (k11kirky@gmail.com). Since you're on the PostHog team, it's worth pointing your local git author email at your @posthog.com address. Why it matters:

• Consistent work identity in git history — internal tooling that attributes commits to team members keys off your @posthog.com address.
• Keeps team contributions easy to tell apart from external community ones when scanning history.

You can fix it for this repo with:

git config user.email "you@posthog.com"

Or set it globally with git config --global user.email "you@posthog.com". No need to redo this PR — just a nudge for next time. 🙂

[github-actions]

🤖 CI report

✅ Bundle size — no change

Uncompressed size of every built .js bundle, compared against the base branch.

Total: 64.59 MiB · no change

No file changed by more than 1000 B.

_{Posted automatically by build-bundle-size-report · uncompressed bytes from dist-report}

✅ Eager graph — within budget

How much code each root ships on the eager path — downloaded and parsed before the surface is interactive. Measured from the esbuild output chunks (post-tree-shake, static imports only); lazy import() / React.lazy chunks are not counted.

Root	Eager (shipped)	Δ vs base	Budget
entry (logged-out pages, app bootstrap) src/index.tsx	1.24 MiB · 22 files	no change	███░░░░░░░ 27.5% of 4.51 MiB
authenticated shell (every logged-in page) src/scenes/AuthenticatedShell.tsx	8.20 MiB · 3,001 files	no change	████████░░ 84.4% of 9.71 MiB

🟢 node_modules/monaco-editor/ stays out of src/index.tsx
🟢 src/lib/components/ActivityLog/describers stays out of src/index.tsx
🟢 [object Object] stays out of src/index.tsx
🟢 [object Object] stays out of src/index.tsx
🟢 node_modules/monaco-editor/ stays out of src/scenes/AuthenticatedShell.tsx
🟢 src/lib/components/ActivityLog/describers stays out of src/scenes/AuthenticatedShell.tsx
🟢 [object Object] stays out of src/scenes/AuthenticatedShell.tsx
🟢 [object Object] stays out of src/scenes/AuthenticatedShell.tsx

Largest files eagerly shipped from src/index.tsx

Size	File
126.8 KiB	../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js
24.6 KiB	../node_modules/.pnpm/buffer@6.0.3/node_modules/buffer/index.js
6.3 KiB	../node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react.production.min.js
4.5 KiB	../node_modules/.pnpm/@jspm+core@2.1.0/node_modules/@jspm/core/nodelibs/browser/process.js
3.9 KiB	../node_modules/.pnpm/scheduler@0.23.2/node_modules/scheduler/cjs/scheduler.production.min.js
1.4 KiB	../node_modules/.pnpm/base64-js@1.5.1/node_modules/base64-js/index.js
1.3 KiB	src/RootErrorBoundary.tsx
912 B	../node_modules/.pnpm/ieee754@1.2.1/node_modules/ieee754/index.js
789 B	src/scenes/ChunkLoadErrorBoundary.tsx
762 B	src/index.tsx

Largest files eagerly shipped from src/scenes/AuthenticatedShell.tsx

Size	File
281.3 KiB	../node_modules/.pnpm/posthog-js@1.405.2/node_modules/posthog-js/dist/rrweb.js
267.7 KiB	../node_modules/.pnpm/@posthog+icons@0.38.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js
236.0 KiB	src/taxonomy/core-filter-definitions-by-group.json
224.4 KiB	../node_modules/.pnpm/posthog-js@1.405.2/node_modules/posthog-js/dist/module.js
167.1 KiB	src/queries/validators.js
154.3 KiB	../node_modules/.pnpm/re2js@0.4.1/node_modules/re2js/build/index.esm.js
126.8 KiB	../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js
106.2 KiB	src/lib/api.ts
94.0 KiB	../packages/quill/packages/quill/dist/index.js
93.3 KiB	../node_modules/.pnpm/prosemirror-view@1.40.1/node_modules/prosemirror-view/dist/index.js

_{Posted automatically by check-eager-graph · sizes are eager output bytes (shipped, post-tree-shake) from the esbuild metafile · part of #32479}

✅ Toolbar bundle — eager 2.18 MiB within budget

What the toolbar ships to customer pages, measured from the esbuild output (minified, post-tree-shake). The eager set is the entry plus everything statically imported from it — fetched before any feature runs; deferred chunks load lazily. The eager guardrail is 5.72 MiB. Each output file must also stay below 10 MB, where CloudFront stops compressing it. The module boundary is enforced separately by check-toolbar-graph.

Metric	Size	Δ vs base	Budget
Eager (shipped) entry + static imports	2.18 MiB · 17 files	no change	████░░░░░░ 38.1% of 5.72 MiB
Deferred (lazy)	2.07 MiB · 33 files	no change	n/a — loads on demand
Loader dist/toolbar.js	1.1 KiB	no change	█░░░░░░░░░ 5.8% of 19.5 KiB

Largest eagerly-shipped chunks

Size	File
713.2 KiB	dist/toolbar/toolbar-app-DW4OA6K5.css
543.1 KiB	dist/toolbar/chunk-chunk-ENG57SBM.js
484.2 KiB	dist/toolbar/chunk-chunk-L423YPH4.js
133.7 KiB	dist/toolbar/chunk-chunk-FZEUL63W.js
131.8 KiB	dist/toolbar/chunk-chunk-T5KY5WYR.js
71.0 KiB	dist/toolbar/toolbar-app-B3ILDDZB.js
69.0 KiB	dist/toolbar/chunk-chunk-27JL52RE.js
35.6 KiB	dist/toolbar/chunk-chunk-KAXCIORH.js
20.9 KiB	dist/toolbar/chunk-chunk-UOJKKCU2.js
12.2 KiB	dist/toolbar/chunk-chunk-PIK3PADE.js

_{Posted automatically by check-toolbar-size · sizes are toolbar output bytes (shipped, post-tree-shake) from the esbuild metafile}

✅ Dist folder size — 🟢 -549 B (-0.0%)

Total size of the built frontend/dist folder (all assets), compared against the base branch.

Total: 1356.68 MiB · 🟢 -549 B (-0.0%)

⚠️ Django migration SQL — 1 new migration to review

We've detected new migrations on this PR. Review the SQL output for each migration:

products/tasks/backend/migrations/0069_remove_code_home_models.py

BEGIN;
--
-- Custom state/database change combination
--
-- (no-op)
COMMIT;

Last updated: 2026-07-22 13:59 UTC (99392b8)

✅ Django migration risk — migration analysis complete

We've analyzed your migrations for potential risks.

Summary: 1 Safe | 0 Needs Review | 0 Blocked

✅ Safe

Brief or no lock, backwards compatible

tasks.0069_remove_code_home_models
  └─ #1 ✅ SeparateDatabaseAndState: Only state operations (no database changes)

Last updated: 2026-07-22 14:00 UTC (99392b8)

[github-actions]

🦔 Hogbox preview · ❌ build failed

The preview didn't come up for commit 99392b8. See the build log for the failing step. It'll retry on the next push.

_{Previews are optional and never block merging. A failure here is often a hogland or tailnet hiccup rather than anything in your PR, so the check stays green and this comment is the status.}

[greptile-apps]

_{Reviews (1): Last reviewed commit: "chore(tasks): remove code home, workstre..." | Re-trigger Greptile}

[parameterai]

Warning

Finding on products/data_warehouse/backend/presentation/views/table.py:509 — could not attach an inline comment (line is not part of the diff), so reporting it here.

Reject uploads without a bounded Content-Length

A caller can send this multipart request with chunked transfer encoding (or no Content-Length), which this code converts to size 0 and then parses at line 521. Django's DATA_UPLOAD_MAX_MEMORY_SIZE does not count file parts, so the multipart parser can spool an arbitrarily large file to the web pod before the later file.size check rejects it. Any user with warehouse_table:write can exhaust temporary disk or worker capacity despite the 50 MB limit.

Prompt To Fix With AI

Require a valid positive Content-Length at or below MAX_UPLOAD_REQUEST_BODY_BYTES before accessing request.FILES, returning 413 when it is missing, malformed, or too large. If supporting chunked uploads is required, install a custom upload handler/parser that tracks cumulative bytes while streaming and aborts before spooling past the limit; retain a test for a request with no Content-Length.

---

_{Severity: medium | Confidence: 92% | React with 👍 if useful or 👎 if not}

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-07-22 14:54 UTC	Run
prod-us	✅ Deployed	2026-07-22 15:12 UTC	Run
prod-eu	✅ Deployed	2026-07-22 15:13 UTC	Run