Welcome. Let's get you shipping by the end of the week.

1 · Get the code and verify

Download the zip from the top of this page, then unzip, enter the folder, and verify integrity — all in one line. Once your GitHub access lands you can switch to cloning; same repo, either way.

unzip standard-industries-onboarding.zip && cd standard-industries-onboarding && git fsck --full

# …or, once you're in the GitHub org:
# git clone git@github.com:standard-industries/onboarding.git

2 · Install the toolchain

setup.sh installs Homebrew or refreshes apt, then nvm / pyenv / goenv with the pinned versions, Docker, the internal gi CLI, and the pre-commit hooks. It's safe to re-run — every step is idempotent.

./scripts/setup.sh

3 · Verify with doctor

Checks versions, Docker health, SSO login, and VPN reachability to staging. Here's what a healthy-enough local machine looks like — remote checks (SSO, VPN) can be red until your access clears:

4 · Configure your environment

The variable names in .env.example are safe to read; the values are secrets your lead sends you. .env is gitignored — never commit it.

cp .env.example .env

5 · Bring up the local stack

We run a trimmed slice of production locally via Docker Compose.

si up            # Loom, Spindle, Selvage, Postgres, Redis, Kafka
si seed          # load demo tenants and sample device data
si open tapestry # opens the local customer app at http://localhost:3000

si up only starts the core path. Data-heavy services (Dye) and edge simulators (Weft, Bobbin) start on demand with si up --profile edge or --profile analytics.

6 · Run something end to end

The smoke flow creates a demo tenant, registers a fake device through Bobbin, pushes a reading through Weft → Warp → Selvage, and asserts a workflow fires.

si smoke

If si smoke passes, you have a working dev environment. Congrats.

7 · Make your first change

A good first task is a "docs or tests" PR — small, low-risk, and it walks you through the whole flow. Your onboarding buddy will suggest a starter issue tagged good-first-issue. Read How we ship before you open it.

Branching & commits

Cut branches from main, named <type>/GI-<ticket>-<short-slug>. Types: feat, fix, docs, chore, refactor, test, perf.

git switch -c feat/GI-1421-selvage-retry-backoff

We like Conventional Commits — keep the subject under ~72 chars and explain the why in the body.

feat(selvage): add exponential backoff to action retries

Workflows that call flaky external webhooks were hammering them on
failure. Backoff caps at 5 attempts. Closes GI-1421.

Pull requests

Keep them small

A tight, single-purpose PR is a "snip." A 2,000-line PR is a saga, and sagas sit unreviewed for days — split them.

Fill the template

Link the Jira thread. Add screenshots for UI changes.

Draft = WIP

Use a WIP: prefix or GitHub's draft state; mark ready when CI is green.

CI must pass

The lint gate blocks merge — run pre-commit run --all-files locally first.

pre-commit run --all-files

Review norms

• One approval required — two for changes to Spindle (auth), Warp (event schemas), or anything touching tenant isolation.
• Reviewers aim to respond within one business day. Blocked? A polite PTAL in the team channel.
• Reviews are about the code, not the coder. Approve with LGTM; the author squash-merges after approval.
• "Disagree and commit" is fine once a decision is made.

What needs an RFC

Write a short RFC in The Spool (Notion) before the code for: new services, new Warp event schemas, cross-team API changes, data-model changes, or anything that alters tenant isolation. Small stuff doesn't — use judgment, and ask your lead when unsure.

How a reading flows

• A device on the factory floor emits a reading.
• The Bobbin agent (running on-prem) batches and ships it over mTLS.
• Weft validates and normalizes it into a canonical Fabric event.
• The event lands on a Warp topic (fabric.<domain>.<event>).
• Selvage evaluates the tenant's workflows and may emit actions.
• Actions fan out — Shuttle notifies humans, Dye records for analytics, results surface in Tapestry.

Guardrails worth internalizing early

• Service boundaries are sacred. Talk to other services through their API or Warp events — never their database.
• Everything is multi-tenant. When in doubt, scope by tenant_id.
• Warp is the spine. New events go through the schema registry — no ad-hoc topics.
• Prod is boring on purpose. Big changes ship behind flags via Heddle.

• Anything blocking you on day one — ping your onboarding buddy (assigned in your offer packet) or #new-threads.
• "Who owns X?" — check Who to ask, then #eng-help.
• Setup script broke — paste the output of ./scripts/doctor.sh into #dev-env.
• An approval is stuck >1 business day — nudge in #it-help and CC your lead. Don't sit blocked silently — that's the one thing we ask you not to do.