Week 2 — Ship your first change

Week 1 was “read”. Week 2 is “write”. The milestones below are a small, linked sequence — each one builds on the previous — so if you pick them in order you finish the week with one coherent PR that touches the schema, a migration, a test, an API, and (optionally) a Go worker. If your team has a different first-feature ticket, swap the domain but keep the pattern.

Before you start, re-read Tech Stack for .NET devs — especially the “Read these three files first” section.

By the end of Week 2, you can:

Add a field to a Prisma model and migrate it.File to open: hivecfm-core/packages/database/schema.prismaAdding one optional scalar is the simplest schema change. Add the field, run pnpm --filter @hivecfm/database db:migrate:dev, commit both the schema change and the generated SQL migration file under hivecfm-core/packages/database/migrations/.
Update the shared type.File to open: hivecfm-core/packages/types/ — find the file named for your entity (for example responses.ts)The TypeScript types in packages/types/ are hand-maintained and shared with the SDK. If you added a DB field, add the TS field too.
Write a unit test for the new field.File to open: any existing *.test.ts near your code. For a service helper: hivecfm-core/apps/web/modules/organization/lib/utils.test.ts is a good pattern referenceVitest is the default. One test that asserts "the field round-trips through Prisma" is enough to unblock review.
Extend an API route to read/write the new field.File to open: the matching route handler under hivecfm-core/apps/web/app/api/v2/Match the existing handler — extend the zod input schema, add the field to the Prisma call, return it in the response. Keep the diff narrow.
Regenerate and sanity-check the OpenAPI spec.File to open: hivecfm-core/openapi.ymlHiveCFM's OpenAPI is handwritten. Update the schema block for the entity you changed and re-run any generation script (pnpm --filter @hivecfm/web generate-and-merge-api-specs). Visual-diff the YAML.
Add a Playwright or integration test if your change is user-visible.File to open: hivecfm-core/apps/web/playwright/ for the E2E sideAnything a user clicks deserves a Playwright assertion. Copy the nearest existing spec and rename.
Add a Go worker (optional).File to open: hivecfm-hub/internal/workers/webhook_dispatch.go as the templateIf your feature needs async work (e.g. fan-out, a callout to an external service, a heavy score), a new River worker is the right shape. Copy the file, rename the args type, add the worker to main.go, and write a matching _test.go.
Author a runbook entry.File to open: hivecfm-dev-hub/pages/runbooks/ — add a new MDX fileIf your change can fail in production in a new way (retry loop, webhook 4xx, stale cache), the runbook tells future-you what to check. Even a five-line file counts.
Open the PR, iterate, merge.File to open: your branch in git. Open the PR against mainYou have shipped before on the throwaway Week 1 PR, so the loop is familiar. The difference this time is that the review will focus on correctness, not plumbing. Address feedback in new commits (no force-pushes).

What “done” looks like

The PR closes a ticket, CI is green, and a teammate has merged it. If you can also point a new hire at your diff and say “this is a canonical small feature change” — you have graduated onboarding.

From here, Architecture and the domain-specific sections (Backend, Database, Hub) are where you live day to day.

Week 1 — Explore & run Overview

Was this page helpful?

Week 2 — Ship your first change

By the end of Week 2, you can:

Week 2 progress

What “done” looks like