Add contributing guide with LLM quick start instructions#302
Add contributing guide with LLM quick start instructions#302leofelix077 wants to merge 5 commits intomainfrom
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds contributor-facing setup documentation (including an LLM-oriented quick start) to make local development setup more reliable and to clarify dev (in-memory) vs production (Redis) run modes.
Changes:
- Added
CONTRIBUTING.mdwith prerequisites, manual setup steps, env var guidance, and key commands. - Added
LLM-QUICK-START.mdto guide an LLM assistant through prerequisite checks, env setup, run, and verification.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| LLM-QUICK-START.md | Step-by-step LLM-oriented local setup guide, including prerequisites, .env creation, and dev/prod run commands. |
| CONTRIBUTING.md | New contributing guide consolidating prerequisites, setup instructions, env var overview, conventions, and PR expectations. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
LLM-QUICK-START.md
Outdated
| For local development with `yarn start`, most values can stay as `not-set` — the | ||
| app uses an in-memory store. Set these for basic operation: | ||
|
|
||
| | Variable | Value for local dev | | ||
| | --------------------- | ------------------------- | | ||
| | `MODE` | `development` | | ||
| | `HOSTNAME` | `localhost` | | ||
| | `REDIS_PORT` | `6379` | | ||
| | `REDIS_CONNECTION_NAME` | `freighter-dev` | |
There was a problem hiding this comment.
The setup flow implies cp .env-EXAMPLE .env is sufficient, but the app currently hard-requires additional env keys that are not present in .env-EXAMPLE (notably FREIGHTER_RPC_PUBNET_URL and FREIGHTER_TRUST_PROXY_RANGE via src/config.ts’s ENV_KEYS check). Following these instructions will fail with an invalid/missing env error unless those keys are added. Please either (a) update this guide to explicitly add/set those missing variables, or (b) update .env-EXAMPLE (ideally in this PR) so copy/paste setup works as documented.
| For local development with `yarn start`, most values can stay as `not-set` — the | |
| app uses an in-memory store. Set these for basic operation: | |
| | Variable | Value for local dev | | |
| | --------------------- | ------------------------- | | |
| | `MODE` | `development` | | |
| | `HOSTNAME` | `localhost` | | |
| | `REDIS_PORT` | `6379` | | |
| | `REDIS_CONNECTION_NAME` | `freighter-dev` | | |
| Copying `.env-EXAMPLE` is only the starting point. Before the app will boot, | |
| make sure all required environment variables are set in `.env`. | |
| For local development with `yarn start`, most values can stay as `not-set` — the | |
| app uses an in-memory store. Set these for basic operation: | |
| | Variable | Value for local dev | | |
| | ------------------------------ | ------------------------------------ | | |
| | `MODE` | `development` | | |
| | `HOSTNAME` | `localhost` | | |
| | `REDIS_PORT` | `6379` | | |
| | `REDIS_CONNECTION_NAME` | `freighter-dev` | | |
| | `FREIGHTER_RPC_PUBNET_URL` | Your pubnet RPC URL | | |
| | `FREIGHTER_TRUST_PROXY_RANGE` | `127.0.0.1/32` | |
| ```bash | ||
| git clone https://github.com/stellar/freighter-backend.git | ||
| cd freighter-backend | ||
| cp .env-EXAMPLE .env # Then fill in values (see below) | ||
| yarn install | ||
| yarn start # Dev mode (uses in-memory store, no Redis needed) | ||
| ``` |
There was a problem hiding this comment.
docker compose up -d + cp .env-EXAMPLE .env is described as a working starting point, but the runtime env validation currently requires additional keys that are not present in .env-EXAMPLE (e.g. FREIGHTER_RPC_PUBNET_URL and FREIGHTER_TRUST_PROXY_RANGE in src/config.ts). As written, a fresh clone will error on startup unless the contributor adds those variables. Please document the missing required variables here (or update .env-EXAMPLE in the same PR) so the manual setup is actually runnable.
CONTRIBUTING.md
Outdated
| | Variable | Purpose | How to obtain | | ||
| | ------------------- | ---------------------------------------------- | ----------------------------------- | | ||
| | `MODE` | `development` or `production` | Set to `development` for local dev | | ||
| | `HOSTNAME` | Server hostname | `localhost` | |
There was a problem hiding this comment.
HOSTNAME is described as the server hostname, but in the current code it’s used as the Redis host (and passed into Redis-backed workers). Consider renaming the description to something like “Redis hostname”/“Redis host” to avoid contributors setting this incorrectly.
| | `HOSTNAME` | Server hostname | `localhost` | | |
| | `HOSTNAME` | Redis hostname | `localhost` | |
CONTRIBUTING.md
Outdated
| | `AUTH_EMAIL` / `AUTH_PASS` | Mercury indexer auth | Only needed if `USE_MERCURY=true` | | ||
| | `SENTRY_KEY` | Error tracking | Leave as `not-set` for local dev | | ||
| | `BLOCKAID_KEY` | Transaction scanning | Leave as `not-set` for local dev | | ||
| | `COINBASE_API_KEY/SECRET` | Pricing data | Leave as `not-set` for local dev | |
There was a problem hiding this comment.
COINBASE_API_KEY/SECRET doesn’t match the actual env var names in .env-EXAMPLE / config (COINBASE_API_KEY and COINBASE_API_SECRET). Please update the docs to list the exact variable names so contributors can copy/paste them correctly.
| | `COINBASE_API_KEY/SECRET` | Pricing data | Leave as `not-set` for local dev | | |
| | `COINBASE_API_KEY` / `COINBASE_API_SECRET` | Pricing data | Leave as `not-set` for local dev | |
Node v25.3.0 exists (released Oct 2025). The earlier change to >=18.0.0 was incorrect.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
.env-EXAMPLE
Outdated
| COINBASE_API_KEY=not-set | ||
| COINBASE_API_SECRET=not-set | ||
| FREIGHTER_HORIZON_URL=not-set | ||
| FREIGHTER_TRUST_PROXY_RANGE=not-set |
There was a problem hiding this comment.
FREIGHTER_TRUST_PROXY_RANGE=not-set will be treated as a non-empty value and passed into proxy-addr.compile(...) via initApiServer, which will throw on an invalid range string and prevent the server from starting. Use an empty value (so trustProxy is unset) or a valid CIDR/range such as 127.0.0.1/32 as the default in .env-EXAMPLE.
| FREIGHTER_TRUST_PROXY_RANGE=not-set | |
| FREIGHTER_TRUST_PROXY_RANGE= |
| Copying `.env-EXAMPLE` is only the starting point. Before the app will boot, | ||
| make sure all required environment variables are set in `.env`. | ||
|
|
||
| For local development with `yarn start`, most values can stay as `not-set` — the | ||
| app uses an in-memory store. Set these for basic operation: |
There was a problem hiding this comment.
This section says the app won't boot until all required env vars are set, but the code only requires keys to exist; with .env-EXAMPLE the service can start even with placeholder values. More importantly, FREIGHTER_TRUST_PROXY_RANGE cannot be left as not-set because it will be compiled into trustProxy and can crash startup—call out the valid/empty value requirement explicitly here.
| Copying `.env-EXAMPLE` is only the starting point. Before the app will boot, | |
| make sure all required environment variables are set in `.env`. | |
| For local development with `yarn start`, most values can stay as `not-set` — the | |
| app uses an in-memory store. Set these for basic operation: | |
| Copying `.env-EXAMPLE` is only the starting point. It ensures the expected keys | |
| exist in `.env`, but it does **not** guarantee every value is valid for startup. | |
| With placeholder values from `.env-EXAMPLE`, the service may still start in some | |
| cases. | |
| For local development with `yarn start`, most values can stay as `not-set` — the | |
| app uses an in-memory store. However, `FREIGHTER_TRUST_PROXY_RANGE` must **not** | |
| be left as `not-set`: set it to a valid proxy/CIDR value for local development | |
| (for example `127.0.0.1/32`), or leave it empty if you do not want to trust a | |
| proxy. Set these for basic operation: |
LLM-QUICK-START.md
Outdated
| docker --version 2>&1 || which docker | ||
|
|
||
| # Docker Compose | ||
| docker compose version 2>&1 || which docker-compose |
There was a problem hiding this comment.
The Docker Compose prerequisite check falls back to which docker-compose, which only prints a path (not a version) and doesn't verify Compose is usable. Consider falling back to docker-compose --version when docker compose version fails.
| docker compose version 2>&1 || which docker-compose | |
| docker compose version 2>&1 || docker-compose --version 2>&1 |
| ### Environment Variables | ||
|
|
||
| Copy `.env-EXAMPLE` to `.env`. For local development with `yarn start`, most | ||
| variables can be left as `not-set` — the app uses an in-memory store by default. |
There was a problem hiding this comment.
This implies most variables can remain not-set for yarn start, but at least FREIGHTER_TRUST_PROXY_RANGE must be empty or a valid proxy-addr range (a literal not-set will be treated as configured and can crash startup). It would help to list any exceptions explicitly so a straight copy of .env-EXAMPLE leads to a bootable dev setup.
| variables can be left as `not-set` — the app uses an in-memory store by default. | |
| variables can remain `not-set` because the app uses an in-memory store by | |
| default. **Exception:** `FREIGHTER_TRUST_PROXY_RANGE` must be left empty or set | |
| to a valid proxy-addr range such as `127.0.0.1/32` for local dev; do not leave | |
| it as the literal string `not-set`. |
Skill Eval:
freighter-backend-dev-setup— Benchmark ReportDate: 2026-04-08
Iterations: 4
Repo: stellar/freighter-backend
Model: Claude Opus 4.6
Prompt: "I just cloned freighter-backend and want to run it locally."
Summary
The skill provides consistent, structured output with correct env var guidance.
The baseline often misses the in-memory dev mode and Redis requirement details.
Assertion Results (aggregated across 4 iterations)
Analysis
The skill's main value is documenting the two run modes (dev with in-memory
store vs production with Redis) — this distinction is not obvious from
package.jsonalone. The baseline frequently missed the in-memory dev mode.