# Mission — the platform's operational toolkit (Tier-3 add-ons)

## Who this is for
A strong backend/Go engineer on the Manabie platform who owns **spike**, **notification**, and
**conversationmgmt**, and has already worked through the core courses (Go, Postgres, gRPC, Auth,
Testing, Kafka, NATS, CDC, the v2 architecture). This course covers the **operational "add-on"
modules** — the cross-cutting machinery every service leans on but that isn't domain logic.

## Why learn this
One course, seven topics, one theme: **the stuff between your code and production working correctly.**

1. **Catch up on the platform.** Migrations, linting/githooks, secrets, and the build/Skaffold system
   are how code *ships*; reliability patterns (idempotency, retries, outbox) are how it *stays
   correct* under at-least-once delivery; notification/email delivery and the cron framework are how
   your own services actually *run*. You touch all of these weekly, often without a mental model of
   how they fit. This course builds that model.
2. **Interview readiness.** "How do you run schema migrations safely?" "What's the transactional
   outbox pattern, and when would you use it?" "How do you make a consumer idempotent?" "How do you
   manage secrets?" These are staple senior-backend questions — and you'll answer them from the canon
   (golang-migrate, Chris Richardson, SOPS, Skaffold) *and* from real code you ship.

## The seven topics (one course)
- **Part 1 · Ship it:** Migrations (golang-migrate) · Linting & githooks (.golangci.yaml + the bespoke
  sqlclosecheck analyzer + gitleaks) · Secrets/SOPS/KMS · Build system/Skaffold.
- **Part 2 · Keep it correct:** at-least-once & idempotency · retries/redelivery · the transactional
  outbox · putting reliability together.
- **Part 3 · Run the domain:** email delivery (spike/SendGrid) · push delivery (notification/FCM) ·
  cron/scheduled-jobs framework · the whole picture.

## What success looks like
By the end you can:
- **Add and run a migration** the repo's way — `NNNN_migrate.up.sql`, RLS boilerplate, `gen-db-schema`
  — and explain why there are *no down migrations*.
- **Read the lint/hook setup**: what `.golangci.yaml` enforces, what the **custom pgx `sqlclosecheck`**
  does (and why it isn't actually enforced), what the githooks require (Jira `LT-`/`RMP-`), what
  gitleaks catches.
- **Explain the secret flow**: SOPS-per-value + GCP KMS, decrypted *in-process* at boot; and the
  separate app-level AES layer for DB-stored keys.
- **Explain the build model**: one binary, all services, selected by a cobra subcommand; cross-compiled;
  dev vs prod Dockerfiles; Skaffold+kind vs docker-compose.
- **Explain the reliability trio** — idempotency, retries, transactional outbox — from the canon *and*
  say honestly what this repo does (outbox is eureka-only + Debezium-relayed; your services dual-write
  with status compensation).
- **Trace a real delivery**: an email through spike+SendGrid (the status state machine) and a push
  through notification+FCM (device tokens, swallowed failures).
- **Name the three runtime shapes**: in-gRPC-pod consumers, the KEDA-scaled gjob pod, and k8s CronJobs.

## The through-line
This is *pragmatic* platform engineering, and the honest bits are the lessons: **no rollback
migrations**, a **security linter that's configured but not enforced**, secrets decrypted **in the
process** not by a sidecar, an **outbox used in only one service** while yours knowingly dual-write,
and **one binary wearing many hats**. Learn the canonical pattern, then learn what this team actually
chose — and why. Every lesson lands on a real `file:line`.

## Anchor & emphasis (applied from established preference)
- **Emphasis:** *balanced* — canonical concept → this repo's take → (where it fits) your own service.
- **Anchor:** the repo's real config/code, leaning on **spike & notification** for the delivery and
  reliability parts (their idempotency, their email/push pipelines, their cronjobs).