Governing policy · POL-06

Secure Development & Change Management Policy

Version 1.0 · effective 13 July 2026 · owner: Jonny Allum

OwnerJonny Allum (Engineering Lead)
Version1.0 · Effective 13/07/2026 · Review annually (July)
Applies toAll code in biz-os and related product repos

1. The rule of gates

No change reaches production without passing all four gates: pnpm turbo run typecheck test build green across the graph, plus audit.mts PASS (repo invariants: total signal coverage, doc counts, registry consistency). For a sole operator these automated gates are the peer review — they are never skipped, weakened or worked around to ship faster.

2. Change classes

ClassExamplesRequirements
RoutineModule work following the house template, copy, UI polishFour gates; commit + push after every meaningful change
SchemaAny migrationSOP-04: numbered, idempotent, RLS + touch triggers, counter updated in BUILD_PLAN.md
SensitiveAuth, RLS, billing, public write paths, AI action registry, cronFour gates plus a cooling-off self-review (re-read the diff after a break) and a production smoke test after deploy (SOP-03)
EmergencyHotfix during an incidentFix forward with the smallest diff; gates still run; retrospective note in the incident record

3. Standing engineering rules (bound here as policy)

These live in BUILD_PLAN.md/CLAUDE.md and have governance force:

  • The per-module template is followed strictly: migration → db helpers → pure engine → pluggable store → board → registration → signals/digest/ import/AI wiring → round-trip test → gates. New module ⇒ its signal provider ships in the same PR (audit enforces 100% coverage).
  • Pure engines have no Node builtins and no clock reads — deterministic, testable, client-safe.
  • Public write paths trust nothing: server-side price resolution, caps, rate limits, possession-based tokens; GETs never mutate.
  • Empty/loading/error states are acceptance criteria, not polish.
  • Secrets never enter the repo; remotes stay clean (POL-01, SOP-09).

4. Dependencies and supply chain

  • Dependencies are added deliberately: prefer the existing stack (Next.js, shadcn/Tailwind, Supabase, Stripe SDKs) over new packages.
  • Lockfile (pnpm-lock.yaml) is committed; unexpected lockfile churn in a diff is investigated before merge.
  • GitHub Dependabot/security alerts on the repo are triaged weekly: critical/high advisories on production dependencies are patched within 7 days, others batched monthly.

5. Source control

  • Work lands as focused commits with descriptive messages; files staged by name. BUILD_PLAN.md (the kanban) is updated as commits land so the plan never lies about state.
  • The default branch is deployable; long-lived divergence between the VM and main is treated as a defect (SOP-03 keeps deploys fast-forward only).
← All documents & policiesQuestions? hello@jonnyai.co.uk