docs(rees): lead with self-host docker-compose, retire our Railway deployment

[JSONbored]

Summary

• REES self-hosting via docker compose --profile rees (added just before this PR) is now production-validated end-to-end on edge-us-01 (real /v1/enrich call, full analyzer registry ran, HTTP 200). This PR re-frames the docs around it as the recommended default instead of an afterthought under an external-instance-first structure, and cleans up the config for the Railway deployment gittensory itself no longer uses.
• apps/gittensory-ui/src/routes/docs.self-hosting-rees.tsx: merges the previously-separate "Engine configuration" and "Self-hosting REES" sections into one "Run REES" flow that leads with the in-network docker-compose path (no separate service to host), with "point at an external or managed instance instead" demoted to an explicit, clearly-alternative subsection. Removes the duplicate .env blocks the old structure had.
• review-enrichment/README.md: drops the "standalone Railway microservice" opening framing (REES is deployment-target-agnostic), generalizes the /health endpoint description and the stale-build note in "Shared analysis context" (neither is actually Railway-specific), and points at self-hosting as the simplest path ahead of the Railway deploy section.
• Removes review-enrichment/railway.json: this repo's own self-hosted engine (edge-us-01) has been fully cut over to the in-network rees service and no longer depends on the Railway deployment that config pointed at. That Railway project (enrichment-gittensory) has separately been decommissioned via the Railway CLI. The Railway deploy path itself remains documented and supported in the README for anyone who wants to run REES there — only our own no-longer-used project config is removed.
• Explicitly untouched: the top-level railway.json (a separate, still-valid Railway deploy option for the main self-host image, unrelated to REES) and the generic "railway.json" infra-file-pattern entry in src/signals/path-matchers.ts (used to recognize Railway configs in any repo gittensory reviews, unrelated to gittensory's own deployment).

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

All run via npm run test:ci (full local gate, green) plus a standalone npm audit --audit-level=moderate (0 vulnerabilities). This is a docs/config-removal-only change (no src/** logic touched), so there's no new branch coverage obligation — verified via ui:lint/ui:typecheck/ui:build that the doc page still compiles and renders correctly after the restructure.

Beyond the local gate, I did live infrastructure verification (not something CI can check): confirmed on edge-us-01 that the in-network rees container is healthy, the engine's post-cutover /v1/ping handshake succeeded (rees_ping_ok), and a real synthetic /v1/enrich call through the container network returned a full HTTP 200 ReviewBrief with the complete analyzer registry executing (including network-calling analyzers like dependency/license). Separately confirmed via railway link -p enrichment-gittensory that the old Railway project no longer exists in the account.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

Docs-and-config-only change: no auth/CORS/session/API behavior touched. The doc page shows static reference content (no live data to mock), so no UI Evidence table applies — this is prose/config restructuring, not a visual/interactive change.

UI Evidence

N/A — text/prose restructuring on an existing docs page; no visual or interactive change.

Notes

• The actual Railway project decommission (CLI railway delete) and the edge-us-01 cutover to the in-network REES service happened outside this repo/PR — this PR is the documentation and repo-config side of that already-completed operational change.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	gittensory-ui	4f9b5c6	Commit Preview URL Branch Preview URL	Jul 07 2026, 03:18 AM

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-07 03:54:04 UTC}

3 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
Straightforward docs reorganization that promotes the docker-compose in-network REES setup to the primary/default path and demotes the external-instance config to an explicit alternative, deduplicating the previously-repeated .env blocks via a shared 'Common options' section. It also removes review-enrichment/railway.json now that this repo's own instance runs via docker-compose, while leaving the top-level railway.json and the generic Railway deploy instructions for third parties untouched. The restructuring is internally consistent — the split .env blocks (compose path, external path, common options) still union to the same variable set as before — and the README changes correctly generalize Railway-specific wording without removing the still-valid Railway deploy option.

Nits — 5 non-blocking

• docs.self-hosting-rees.tsx:87 hardcodes `REES_URL=http:​//rees:8080` in the compose example — fine for a doc but worth double-checking the service name `rees` matches the actual docker-compose.yml service name so the example doesn't drift if that's ever renamed.
• review-enrichment/README.md's Deploy (Railway) section now asks the reader to hand-author their own `railway.json` (since this PR deletes the repo's copy) but doesn't link to an example/template of that file's expected shape, which the deleted file previously served as.
• Consider keeping a minimal example railway.json snippet inline in the README's Deploy (Railway) section (or a link to Railway's Dockerfile-builder docs with the exact fields previously used) so contributors deploying their own REES to Railway have a concrete starting point now that the repo's copy is gone.
• docs.self-hosting-rees.tsx: since 'Common options (either path)' now sits between the two .env blocks and the FeatureRow describing all vars below, double check the heading order still reads naturally when rendered (h2 'Run REES' -> h3 -> h3 'Common options') rather than feeling like a non-sequitur between the two config paths.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 51 registered-repo PR(s), 43 merged, 348 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 51 PR(s), 348 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 51 PR(s), 348 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review