Repository navigation
Fix Docker builds and add Railway root config - #2
Merged
Merged
Conversation
Closes the gap where the approval queue was fully built but nothing fed it. A bare GitHub handle now walks the whole pipeline to a queued card: enrich -> resolve identities -> collect signals -> score -> recommend GitHub first because it is free and its profiles carry links the person published themselves. Verified live against a real account: three linked identities (github 1.00, x 0.956 via cross_linked_profile + same_employer, website 0.918 via same_personal_domain), signals extracted, scored, and a recommendation produced. The recommendation engine cannot invent capabilities — candidate actions are filtered through allowedActions before anything is chosen, so on GitHub it can only ever propose passive actions, never the disabled comment or DM. It also cannot invent a reason: every recommendation names its trigger signal, and only signals carrying verbatim evidence enter groundedSignalIds. Signal classification is rule-based, not model-based, so it is reproducible. 265 tests, typecheck clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…onfig The Dockerfiles listed every package.json by hand, so adding packages/recommend broke all three builds: error: Workspace dependency "@outreachgraph/recommend" not found The enumeration was the bug, not the missing line. The dependency stage now copies the workspace wholesale, which costs some layer caching and buys a Dockerfile that cannot drift out of sync with the repository. Also adds .dockerignore (node_modules, .next, *.db were all being sent as build context) and a root railway.json. Railway reads config from the repo root; with the per-service files only under apps/*, it found nothing and fell back to railpack, which cannot find a start command in a Bun workspace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copying only the root node_modules into a fresh builder stage loses the per-package node_modules/.bin that Bun's workspace linking creates, so the build failed with `next: command not found`. The builder now extends deps, which already carries the full workspace layout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ralyodio
added a commit
that referenced
this pull request
Sep 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two deploy blockers, both surfaced by real infrastructure rather than by tests.
1. All three Docker builds failed
The Dockerfiles enumerated every
package.jsonby hand to get a cacheable dependency layer. Addingpackages/recommendbroke all three images, because the workspace member was missing from the copy list while being present inbun.lock.The enumeration was the bug, not the missing line. The dependency stage now copies the workspace wholesale. That costs some layer caching and buys a Dockerfile that cannot drift out of sync with the repository — this class of failure is now impossible rather than merely fixed.
Also adds
.dockerignore, which was missing entirely:node_modules,.nextand*.dbwere all being sent as build context.2. Railway ran railpack instead of the Dockerfiles
Railway reads config-as-code from the repository root. The per-service
railway.jsonfiles lived only underapps/*, so Railway found nothing, fell back to railpack auto-detection, and could not infer a start command for a Bun workspace.Adds a root
railway.jsonconfiguring the default service as the API, and documents the multi-service setup in the README:/railway.json/apps/web/railway.json/apps/worker/railway.jsonRoot Directory must stay unset — these Dockerfiles expect the repository root as their build context.
Note on verification
Docker is not installed on the machine these images were authored on, so the Dockerfiles were never built locally before being committed. CI is the first thing that ever ran them, and it caught this immediately. The
dockerjob in CI is the guard going forward.265 tests pass, typecheck clean.
🤖 Generated with Claude Code