Project: doctolib-doctolib · Branch: .invalid · Mode: default · Model: claude-sonnet-4-6
Stats: 4 user messages, 3 tool calls, tools used: Glob, Read.
Conversation
Turn 1 — User
explain each option
bin/dev billeo bin/dev ci:build bin/dev docker bin/dev server bin/dev server:cluster bin/dev rspack bin/dev vite (beta) bin/dev worker bin/dev mock-mdp bin/dev mock-keystorage bin/dev kafka_consumer
Turn 1 — Assistant
Tools used:
Glob:bin/dev
Tools used:
Glob:Procfile*
Tool results:
→ result (ok): No files found
Tool results:
→ result (ok): bin/dev
Tools used:
Read:/Users/USER/workspace/doctolib/doctolib/bin/dev
Tool results:
→ result (ok): 1 #!/usr/bin/env bash
2
3 _billeo() {
4 . dev-tools/local/staging-connection.sh && ./docker/scripts/run_billeo.sh
5 }
6
7 _ci_build() {
8 echo "Use the dctl command instead: dctl ci start-build"
9 exit 126
10 }
11
12 _docker() {
13 if [[ -z "$COMPOSE_PROFILES" ]]; then
14 export COMPOSE_PROFILES="monolith_keymock"
15 fi
16 if [[ "$OSTYPE" == "darwin"* ]] || [[ -n "$WSL_DISTRO_NAME" ]]; then
17 set -m ; colima status || colima start ; set +m
18 docker compose up --remov
…(truncated, 1846 more chars)
Here's what each bin/dev option does:
bin/dev billeo
Sources the staging connection config (dev-tools/local/staging-connection.sh) then runs the Billeo service via Docker (docker/scripts/run_billeo.sh). Billeo is the billing/invoicing engine — this lets you connect it against a staging backend locally.
bin/dev ci:build
No-op. It just prints a message redirecting you to dctl ci start-build and exits with code 126. CI builds must be triggered via the dctl CLI tool, not locally.
bin/dev docker
Starts the full local dev environment via Docker Compose. Key behaviors:
- Defaults to the monolith_keymock compose profile if COMPOSE_PROFILES is not set
- On macOS/WSL: ensures Colima (the Docker daemon alternative) is running, then calls docker compose up --remove-orphans --build
- On Linux: uses both docker-compose.yml and docker-compose.linux.yml overrides
bin/dev server
Runs bin/rails server — the standard single-threaded Puma Rails web server for local development.
bin/dev server:cluster
Same as server, but sets RAILS_MAX_THREADS=3 to run Puma in multi-threaded mode. The comment in the code notes this is not officially supported by the platform team — use at your own risk.
bin/dev rspack
Runs npm run dev — starts the Rspack bundler in dev/watch mode with lazy compilation. Rspack is the default JS bundler (a Rust-based webpack-compatible alternative). You need this running alongside server for frontend assets.
bin/dev vite (beta)
Starts the Vite dev server as an alternative bundler with bin/vite dev. Sets NODE_OPTIONS=--max-old-space-size=8192 to give Node 8 GB of heap — Vite is still experimental here, hence the beta label.
bin/dev worker
Starts the Solid Queue background job processor using bin/jobs. Points it at config/solid_queue/development.yml and enables stdout logging (RAILS_LOG_TO_STDOUT=1). Required to process async jobs locally.
bin/dev mock-mdp
Starts a Specmatic mock server for the Medical Data Platform (MDP) API. It locates the OpenAPI specs from the medical-data-platform-client gem (bundle show) and spins up a Docker container (docker-compose.specmatic.yml) that simulates the MDP service. Useful for testing MDP integrations without a real backend.
bin/dev mock-keystorage
Same Specmatic Docker setup, but targets the keystorage-mock service specifically. Mocks the key storage service (likely used for encryption key management in the FHIR/e2e-encryption flows).
bin/dev kafka_consumer
Starts the Karafka Kafka consumer with bundle exec karafka server. This processes messages from Kafka topics — needed when working on event-driven features that consume Kafka events.
★ Insight ─────────────────────────────────────
- The separation between server (Rails), rspack/vite (asset bundling), and worker (jobs) reflects a common monolith pattern where you run 3+ processes locally — this is why tools like foreman/overmind exist, but here each is an explicit subcommand.
- The mock-mdp and mock-keystorage commands use Specmatic, a contract-testing tool that generates mock servers from OpenAPI specs — so the mock behavior is automatically kept in sync with the real API spec.
- billeo is the only command that opens a staging tunnel, meaning it's the only service not fully runnable in pure local mode — it depends on real staging infrastructure.
─────────────────────────────────────────────────
Turn 2 — User
<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>
Turn 3 — User
<command-name>/exit</command-name> <command-message>exit</command-message> <command-args></command-args>
Turn 4 — User
<local-command-stdout>Goodbye!</local-command-stdout>