If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sourcegraph/sourcegraph-public-snapshot shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 29+ active contributors
• Distributed ownership (top contributor 18% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sourcegraph/sourcegraph-public-snapshot repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sourcegraph/sourcegraph-public-snapshot.

What it runs against: a local clone of sourcegraph/sourcegraph-public-snapshot — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sourcegraph/sourcegraph-public-snapshot | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 642 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sourcegraph/sourcegraph-public-snapshot. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sourcegraph/sourcegraph-public-snapshot.git
#   cd sourcegraph-public-snapshot
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sourcegraph/sourcegraph-public-snapshot and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sourcegraph/sourcegraph-public-snapshot(\\.git)?\\b" \\
  && ok "origin remote is sourcegraph/sourcegraph-public-snapshot" \\
  || miss "origin remote is not sourcegraph/sourcegraph-public-snapshot (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f ".bazelrc" \\
  && ok ".bazelrc" \\
  || miss "missing critical file: .bazelrc"
test -f "BUILD.bazel" \\
  && ok "BUILD.bazel" \\
  || miss "missing critical file: BUILD.bazel"
test -f ".github/workflows/bazel-test-ownership-check.yml" \\
  && ok ".github/workflows/bazel-test-ownership-check.yml" \\
  || miss "missing critical file: .github/workflows/bazel-test-ownership-check.yml"
test -f ".bazelversion" \\
  && ok ".bazelversion" \\
  || miss "missing critical file: .bazelversion"
test -f ".npmrc" \\
  && ok ".npmrc" \\
  || miss "missing critical file: .npmrc"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 642 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~612d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sourcegraph/sourcegraph-public-snapshot"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Sourcegraph is a Code AI platform providing unified code search, intelligent code navigation, and large-scale refactoring capabilities across repositories. It combines full-text search with semantic code intelligence (via language servers) and AI-powered code comprehension (Cody) to enable developers to read, write, and fix code at scale in complex monorepos. The codebase is a polyglot monorepo (~29.7M LOC Go, ~16.9M LOC TypeScript) built with Bazel, hosting the backend infrastructure, web UI, CLI tools, and language integrations. Bazel-based monorepo with layered architecture: backend services (Go, ~cmd/ and ~internal/ packages), frontend SPA (TypeScript/Svelte in ~client/, configured in ~BUILD.bazel and tsconfig files), shared packages (@sourcegraph/common, @sourcegraph/shared, @sourcegraph/wildcard in workspace dependencies), and infrastructure-as-code (Starlark in .apko/, Nix configs). Builds output Docker images (.dockerignore, Dockerfile present), deployed via Buildkite CI with multi-config bazel rc files (.aspect/bazelrc/*) for CI, macOS, and performance optimization.

Enterprise and open-source developers who work in large, complex codebases and need to search across multiple repositories, understand code dependencies, track migrations, and leverage AI to understand unfamiliar code. Platform engineers building code infrastructure and DevOps teams standardizing on a unified code intelligence platform.

Production-ready and actively maintained. This is a public snapshot of the private sourcegraph/sourcegraph monorepo (Apache-licensed until commit 1cd36d2). The presence of comprehensive Bazel build configuration (.aspect/rules/, .bazelrc variants for CI/macOS/performance), Buildkite CI pipelines (.buildkite/pipeline.yml), and multi-language support indicates a mature, enterprise-grade codebase. However, note this is a historical snapshot—active development has moved to the private repo.

Snapshot risk: This is a public archive, not the active development branch, so it will not receive security patches or updates. The monorepo's scale (46M+ LOC across 30+ languages) creates complexity; Bazel dependency management is powerful but has a steep learning curve. No recent commit info in provided data, but the migration to a private repo signals this specific repo is no longer maintained—treat it as reference/historical code only.

Cannot determine from provided data—this is a static snapshot. The CODEOWNERS file and multiple GitHub issue templates suggest active community governance before the migration. Current activity is in the private sourcegraph/sourcegraph repo.

Clone the snapshot (read-only, historical): git clone https://github.com/sourcegraph/sourcegraph-public-snapshot.git && cd sourcegraph-public-snapshot. Install Bazel (version in .bazelversion, likely ~7.x based on .aspect/bazelrc/bazel7.bazelrc). Install Node.js dependencies: pnpm install (pnpm is the monorepo package manager). For active development, refer to https://docs-legacy.sourcegraph.com/dev—this snapshot is archived.

Daily commands: Verify Bazel setup: bazel version. Run the development server (inferred from Bazel + web UI pattern): bazel run //client/web:dev or pnpm dev in client/web. Run tests: pnpm test (per package.json vitest config) or bazel test //... for full suite. Run linters: pnpm lint:js && pnpm lint:css (eslint + stylelint per package.json). Start Storybook: pnpm storybook (configured for @sourcegraph/branded stories). Note: Full local build likely requires significant resources; Buildkite CI config (.buildkite/pipeline.yml) shows distributed build strategy.

• .bazelrc — Root Bazel configuration file that controls build and test behavior across the entire monorepo; essential for understanding the build system.
• BUILD.bazel — Root Bazel build target that defines the overall project structure and workspace dependencies.
• .github/workflows/bazel-test-ownership-check.yml — CI/CD workflow that enforces test ownership rules; contributors must understand test requirements before submission.
• .bazelversion — Specifies the Bazel version used across the monorepo; critical for reproducible builds.
• .npmrc — NPM registry and package configuration; essential for managing workspace dependencies in the monorepo.
• CONTRIBUTING.md — Developer guide outlining contribution workflow, code standards, and project conventions.
• .github/CODEOWNERS — Defines code ownership and review requirements for different parts of the repository.

Add a new Bazel build target

1. Create a BUILD.bazel file in your new package directory with ts_library or ts_project target (BUILD.bazel)
2. Reference dependencies using workspace labels (e.g., //path:target) and add to BUILD.bazel (.bazelrc)
3. Run 'bazel build //your/package:target' to verify; configuration uses .aspect/bazelrc/javascript.bazelrc for TypeScript (.aspect/bazelrc/javascript.bazelrc)

Add a new GitHub Actions workflow

1. Create a new .yml file in .github/workflows/ following the pattern of existing workflows (.github/workflows/bazel-test-ownership-check.yml)
2. Define triggers (push, pull_request) and job steps using Bazel or standard shell commands (.github/workflows/buf-breaking-check.yml)
3. If gating PRs, register the workflow in relevant branch protection rules (.github/workflows/licenses-check.yml)

Add a new linting rule

1. For JavaScript/TypeScript, add rules to .eslintrc.js following ESLint plugin conventions (.eslintrc.js)
2. For SCSS, add rules to .stylelintrc.json; for CSS in HTML, configure in .stylelintrc.json (.stylelintrc.json)
3. Run 'pnpm lint:js' and 'pnpm lint:css' locally (defined in dependencies' package.json) before committing (.prettierignore)

Add a new team or code owner

1. Define the team in .github/teams.yml with members and metadata (.github/teams.yml)
2. Add code ownership rules in .github/CODEOWNERS mapping file patterns to teams (.github/CODEOWNERS)
3. Verify rules take effect on next PR; consider syncing with .github/test.CODEOWNERS for testing (.github/test.CODEOWNERS)

• Bazel — Provides hermetic, reproducible builds with fine-grained caching; essential for a 600-file polyglot monorepo with TypeScript, Go, and Protobuf components.
• Buildkite + GitHub Actions — Dual CI/CD: Buildkite for heavy build/test workloads (parallel scaling), GitHub Actions for lightweight checks (breaking changes, licenses, code ownership).
• TypeScript + SWC — Type safety and rapid compilation; SWC replaces Babel for 10-100x faster transpilation in monorepo workflows.
• ESLint + Stylelint — Multi-language linting enforcement (JS/TS + SCSS); critical for consistency across 600 files and multiple teams.
• npm workspace + pnpm — Monorepo package management with shared dependencies; .npmrc controls registry and dedupplication.
• Protobuf (buf) — API contract definition; breaking-change detection (.github/workflows/buf-breaking-check.yml) ensures backward compatibility.

• Bazel + Buildkite instead of npm scripts alone

  • Why: Monorepo of 600 files with mixed languages (Go, TypeScript, Protobuf) requires language-agnostic, distributed builds.
  • Consequence: Steeper learning curve for contributors; requires .bazelrc, BUILD.bazel files, and Bazelisk setup. Mitigated by .aspect/bazelrc/ helpers.

• Code ownership gating via CODEOWNERS + bazel-test-ownership-check.yml

  • Why: Ensures domain expertise reviews critical code without manual process overhead.
  • Consequence: PR merging blocked until team review; requires team definitions in teams.yml and mapping in CODEOWNERS.

• Distributed CI (Buildkite + GitHub Actions)

  • Why: GitHub Actions is free for public repos; Buildkite scales for heavy parallelization.
  • Consequence: Operators manage two CI systems; requires duplication of some pipeline logic across .buildkite/ and .github/workflows/.

• Strict linting with ESLint, Stylelint, and SWC pre-checks

  • Why: Enforces code quality across 600 files and multiple teams without review bottleneck.
  • Consequence: Contributors must pass lint checks before CI proceeds; requires setup of IDE integration (.vscode/settings.json) to catch issues early.

• This repository does not serve as a runtime platform; it is a snapshot of source code and build configuration.
• Does not handle production deployment (only CI/CD orchestration; actual deployment is external).
• Not a package registry; it publishes packages but does not host package management infrastructure.
• Does not provide real-time collaboration features; GitHub + Buildkite are coordination layer.
• Not a developer IDE; configuration files (VS Code,

Bazel complexity: First-time Bazel setup is non-trivial; missing .bazelversion or .bazelrc config will cause cryptic build errors. Workspace dependencies: pnpm workspace structure with workspace:* protocol means you must run pnpm install from repo root; installing in subdirectories will fail. Multi-config CI: .aspect/bazelrc/* includes environment-specific configs (ci.macos.bazelrc, ci.sourcegraph.bazelrc); local builds may behave differently than CI without correct --config flags. Snapshot stability: This repo is archived—dependencies (Go, Node, Bazel versions) may be stale and cause vulnerabilities; do not use for production. Large monorepo scale: Full build can require >50GB disk and significant RAM; incremental builds via Bazel help, but clean builds are slow. Language diversity: No single build command; Go code requires Go toolchain, TypeScript requires Node/pnpm, Rust requires Rust toolchain—all must be installed.

• Bazel incremental builds — Bazel's content-addressed caching and DAG-based builds enable fast rebuilds of only changed targets; essential for scaling this 46M LOC monorepo to reasonable local build times
• pnpm workspaces & workspace protocol — pnpm workspace:* deps allow local packages to reference each other without publishing; enables rapid iteration on shared @sourcegraph/* packages
• Language servers & LSP (Language Server Protocol) — Sourcegraph integrates LSP-based code intelligence; understanding LSP is key to understanding how code navigation, hover, and goto-definition work across 30+ languages
• Code search indexing (inverted index / ngram sharding) — Core feature of Sourcegraph; search performance across 100M+ LOC repos depends on efficient indexing strategies and query optimization
• Semantic diff & code refactoring (large-scale changes) — Sourcegraph's 'Fix and refactor' capability relies on understanding code structure to perform cross-repo migrations; AST-based transformations are likely used
• gRPC & Protocol Buffers — Backend services likely use gRPC for performance; understanding proto definitions and service contracts is important for backend contributions
• Docker multi-stage builds & Apko image building — Sourcegraph is deployed as OCI containers; .apko/ config and Dockerfile define image layers; understanding cold-start and caching is important for deployment

• github/codeql — Alternative code intelligence platform using semantic analysis and query language; competes on deep static analysis for security scanning
• gitpod/gitpod — Cloud-based development environment; complementary to Sourcegraph for workspace-level code exploration and IDE integration
• bazelbuild/bazel — Build system used throughout this monorepo; understanding Bazel fundamentals is essential for modifying build configuration
• pnpm/pnpm — Package manager for this monorepo; workspace protocol and lock file management are critical to dependency resolution
• sourcegraph/cody — AI code assistant powered by Sourcegraph; likely a separate repo or submodule providing the LLM-powered code understanding features

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive Bazel test coverage for TypeScript packages in client/branded

The repo uses Bazel extensively (evidenced by .bazelrc, .bazelversion, and .aspect/bazelrc configs), but the @sourcegraph/branded package only defines npm scripts (storybook, lint:js, lint:css, test via vitest) without corresponding Bazel BUILD rules. This creates a gap where Bazel CI cannot properly orchestrate TypeScript tests across the monorepo. Adding BUILD.bazel files with ts_project and vitest_test rules would enable consistent hermetic testing and dependency management.

• [ ] Create BUILD.bazel in client/branded/ with ts_project rule for src/ directory
• [ ] Add vitest_test rule to execute test script defined in package.json
• [ ] Add ts_library rules for ESLint and stylelint checks as custom rules or lint targets
• [ ] Reference .aspect/bazelrc/javascript.bazelrc and rules_ts.bazelrc for TypeScript configuration
• [ ] Update .bazelignore if needed to exclude node_modules
• [ ] Verify BUILD file integrates with existing Buildkite pipeline in .buildkite/pipeline.yml

Add GitHub Actions workflow for automated dependency updates and workspace:* resolution validation

The package.json uses many workspace:* dependencies across @sourcegraph packages (common, shared, wildcard, http-client, observability-client, etc.). There's no visible CI workflow (beyond .buildkite) to validate that workspace references remain consistent when internal packages are updated. Adding a GitHub Action would catch broken workspace dependencies early, similar to the existing .github/workflows/licenses-check.yml and buf-breaking-check.yml.

• [ ] Create .github/workflows/workspace-deps-check.yml workflow
• [ ] Add pnpm install verification step to ensure workspace:* resolution succeeds
• [ ] Add step to validate all @sourcegraph/* imports exist in node_modules during build
• [ ] Reference existing workflow patterns in .github/workflows/buildchecker.yml for structure
• [ ] Trigger on pull_request changes to any package.json containing workspace:* deps
• [ ] Consider integrating with existing CODEOWNERS validation in .github/CODEOWNERS

Add missing test coverage for @sourcegraph/branded Storybook stories and CSS module exports

The package defines storybook and lint:css scripts but there's no evidence of a .test.tsx or .test.ts file pattern for story-level snapshot/component tests. Given the visual nature of a branded component library and the existence of @sourcegraph/testing as a dev dependency, adding story tests would prevent visual regressions. Additionally, SCSS exports and wildcard component integrations lack unit test coverage.

• [ ] Create client/branded/src/tests/ directory structure
• [ ] Add vitest snapshot tests for 3-5 core exported components (reference existing .story.tsx files pattern)
• [ ] Add unit tests for CSS module exports using @sourcegraph/testing utilities
• [ ] Create test fixtures that verify @sourcegraph/wildcard and @sourcegraph/shared integration
• [ ] Update vitest config in package.json or create vitest.config.ts with appropriate setup
• [ ] Add test coverage threshold to prevent regressions in future PRs

• Add missing test coverage for @sourcegraph/branded package. The package.json shows "test": "vitest" but no test files are visible in the file listing; create a test suite for core exports in client/branded/src/ (start with index.ts) following the Vitest + TypeScript pattern.: medium: Improves test coverage, familiarizes contributor with Vitest + Bazel test config, directly addresses a gap in the snapshot.
• Document the Bazel + TypeScript (rules_ts) build process. The .aspect/rules/ and .aspect/bazelrc/rules_ts.bazelrc indicate a complex setup; create a guide in doc/ or CONTRIBUTING.md explaining how to add a new TypeScript package, how Bazel builds ts_project targets, and when to use --config flags.: low-to-medium: Lowers barrier to entry for new contributors; the Bazel + ts_project setup is non-obvious and undocumented in provided files.
• Audit and pin @sourcegraph/wildcard, @sourcegraph/common, and @sourcegraph/shared dependencies in client/branded/package.json. These workspace:* deps are vague; verify they have no circular dependencies, properly export TypeScript types, and document which are required vs. optional.: low: Reduces risk of implicit coupling, improves code quality, and helps understand monorepo dependency graph.

The codebase demonstrates reasonable security posture with Apache 2.0 licensing, structured security policy, and use of workspace management. However, the reliance on 'workspace:*' dependencies without explicit version pinning, complex build infrastructure, and lack of visible lock files present moderate concerns. No critical vulnerabilities were identified in the provided snapshot, but the private monorepo transition means historical vulnerability information may be lost. Recommendations focus on tightening dependency management, ensuring reproducible builds, and maintaining clear security documentation.

• Medium · Workspace Dependencies Without Version Pinning — package.json - devDependencies and dependencies sections. The package.json uses 'workspace:*' for all internal dependencies (@sourcegraph/extension-api-types, @sourcegraph/testing, @sourcegraph/common, etc.). While this is common in monorepos, it means dependency versions are not explicitly pinned and could change unexpectedly during builds, potentially introducing vulnerabilities. Fix: Consider documenting the workspace dependency resolution strategy and ensure that workspace packages themselves follow strict version management and security practices. Implement lock files (pnpm-lock.yaml) to ensure reproducible builds.
• Low · Missing Package Lock File Visibility — Repository root. While pnpm is being used (evident from scripts), the lock file (pnpm-lock.yaml) is not visible in the provided file structure, making it impossible to verify that dependencies are pinned and reproducible. Fix: Ensure pnpm-lock.yaml is committed and maintained in version control. Verify lock file integrity in CI/CD pipelines.
• Low · No Explicit Security Policy in Repository Root — SECURITY.md. While SECURITY.md exists referencing an external security policy, there are no inline security guidelines, vulnerability disclosure procedures, or security contact information visible in the provided structure. Fix: Maintain clear security contact information and vulnerability disclosure procedures in SECURITY.md. Consider adding security.txt file at /.well-known/security.txt
• Low · Development Dependencies Exposed in Production — package.json - devDependencies section. Testing and extension-api-types are listed as devDependencies, but without visibility into the build system, there's a risk these could be accidentally bundled into production code. Fix: Verify that build configurations (Bazel rules visible in structure) properly exclude devDependencies from production bundles. Add bundle size checks in CI/CD.
• Low · Complex Build System with Multiple Configuration Files — .aspect/bazelrc/*, .bazelrc, .buildkite/hooks/*. The presence of multiple Bazel configuration files (.bazelrc, .aspect/bazelrc/, etc.) and build hooks (.buildkite/hooks/) creates a complex build system that could be difficult to audit for security issues. Fix: Document the build system architecture and security controls. Regularly audit build scripts for injection vulnerabilities or unsafe practices.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.