GO — Healthy across the board

• Last commit today
• 5 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 53% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

CUE is a declarative language and toolchain for validating, defining, and executing configurations. It unifies schemas, validation rules, and data in a single language, working natively with Go, JSON, YAML, TOML, XML, OpenAPI, Protobuf, and JSON Schema. The core capability is reducing configuration boilerplate while ensuring type safety and policy compliance across infrastructure and application configs. Monorepo organized as: cmd/cue/ contains the CLI and subcommands (add.go, eval.go, export.go, fmt.go, get.go, import.go, etc.), cmd/cue/cmd/integration/ houses end-to-end tests for workspace, diagnostics, and LSP features, and the core language evaluator in the root cuelang.org/go package. The codebase is primarily Go with CUE configuration examples, and includes a Dockerfile for container distribution.

DevOps engineers, platform teams, and Go developers who manage multi-format configurations (Kubernetes YAML, Terraform, CloudFormation) and need schema validation, policy enforcement, and configuration generation without maintaining separate schema languages (OpenAPI, JSON Schema). Also targets teams building internal developer platforms that need unified configuration validation.

Production-ready and actively maintained. The project requires Go 1.25+, has comprehensive CI/CD (GitHub workflows: trybot.yaml, release.yaml, tip_triggers.yaml), and extensive test coverage across cmd/cue/cmd/ and cmd/cue/cmd/integration/. The monorepo structure with 5.8M+ lines of Go and active Docker releases indicate a mature ecosystem, though the 2025 Go requirement shows aggressive modernization.

Low-to-moderate production risk. The single-command entry point (cmd/cue) and modular package structure under cuelang.org/go minimize breaking changes, but the aggressive Go version requirement (1.25) may constrain adoption in legacy environments. No obvious single-maintainer bottleneck visible in CODEOWNERS, though the complexity of the type system and evaluation engine (implied by 5.8M LOC) creates expertise concentration risk.

Active work on LSP/IDE integration (cmd/cue/cmd/integration/workspace/ contains codeaction_test.go, diagnostics_test.go, hover_test.go, formatting_test.go suggesting recent IDE feature development). Experimentation API under cmd/cue/cmd/exp.go and gen_experiments_help.go. Release automation is robust (release.yaml workflow), indicating regular cadence. The .claude/settings.json and CLAUDE.md suggest recent onboarding/documentation improvements.

Clone and build: git clone https://github.com/cue-lang/cue.git && cd cue && go install ./cmd/cue@latest. Alternatively, download pre-built binaries from the latest GitHub release. Verify: cue version. No external services required; Go 1.25+ is the sole dependency.

Daily commands: Development: go build ./cmd/cue or go run ./cmd/cue <command>. Test suite: go test ./... from repo root. The project uses standard Go tooling; no Makefile or npm scripts visible. For Docker: docker build -f cmd/cue/Dockerfile . or pull from cuelang/cue on Docker Hub.

• cmd/cue/cmd/root.go — Entry point for the CUE CLI; all command routing and global initialization flows through here
• cmd/cue/cmd/cmd.go — Core command framework defining how all subcommands (eval, export, fmt, etc.) are structured and executed
• cmd/cue/cmd/common.go — Shared utilities and common patterns used across all CLI commands; understanding this is essential for modifying any command
• cmd/cue/cmd/lsp.go — Language Server Protocol implementation; critical for IDE integration and understanding the architectural approach to language tooling
• cmd/cue/cmd/mod.go — Module system entry point; handles dependency management and is foundational for understanding CUE's package architecture
• cmd/cue/cmd/eval.go — Core evaluation command; demonstrates how CUE expressions are parsed, validated, and executed
• .github/workflows/trybot.yaml — Primary CI/CD pipeline; defines test and release processes that all contributors must respect

Add a new CLI subcommand

1. Create a new command file following pattern: cmd/cue/cmd/mycommand.go implementing the Command interface from cmd.go (cmd/cue/cmd/mycommand.go)
2. Register the command in the root command tree in root.go by calling newMyCommand() and adding it to the command group (cmd/cue/cmd/root.go)
3. Add flag definitions using the pattern from flags.go; implement Run() and flag.String()/flag.Bool() calls in your command (cmd/cue/cmd/flags.go)
4. Add script-based integration tests in testdata/script/ as .txtar files and reference them in script_test.go (cmd/cue/cmd/testdata/script/cmd_mycommand.txtar)
5. Leverage common.go utilities for path resolution, package loading, and error handling patterns (cmd/cue/cmd/common.go)

Add module system functionality

1. Create a new module subcommand file: cmd/cue/cmd/modmyfeature.go following the pattern of modinit.go, modget.go, or modtidy.go (cmd/cue/cmd/modmyfeature.go)
2. Register the subcommand in mod.go as a child of the 'mod' command using NewCommand() (cmd/cue/cmd/mod.go)
3. Use module resolution utilities from common.go and follow modedit.go patterns for manipulating cue.mod files (cmd/cue/cmd/modedit.go)
4. Add integration tests in cmd/cue/cmd/testdata/script/ testing module creation and dependency scenarios (cmd/cue/cmd/testdata/script/mod_myfeature.txtar)

Extend the Language Server Protocol (LSP)

1. Study the existing LSP implementation in lsp.go to understand message routing and workspace handling (cmd/cue/cmd/lsp.go)
2. Add new LSP method handlers in lsp.go following the pattern of existing handlers (e.g., definition, hover, completion) (cmd/cue/cmd/lsp.go)
3. Add corresponding workspace integration tests in cmd/cue/cmd/integration/workspace/ named after the feature (e.g., newfeature_test.go) (cmd/cue/cmd/integration/workspace/newfeature_test.go)
4. Test with a CUE IDE extension using LSP client; verify message protocol compliance with spec at https://microsoft.github.io/language-server-protocol/ (cmd/cue/cmd/lsp.go)

• Go — Static typing, fast compilation, excellent CLI tooling support; CUE's interpreter is written in Go
• Cobra — Standard Go CLI framework; enables consistent command structure, automatic help generation, and completion support
• Language Server Protocol (LSP) — IDE-agnostic; allows single implementation to support VS Code, Vim, Emacs, JetBrains, etc.
• txtar (text archive) — Human-readable test format for integration testing; mixes shell commands, expected outputs, and file definitions in single files

• Single monolithic cmd/ package instead of separate modules

  • Why: Simplifies shared state management and flag handling across all commands
  • Consequence: cmd/ directory is large (~80+ files); commands are tightly coupled to common.go utilities

• Script-based (txtar) integration tests instead of unit tests for CLI

  • Why: Tests exercise full end-to-end behavior including file I/O, error handling, and output formatting
  • Consequence: Slower test execution; harder to isolate individual failures; easier to add regression tests

• LSP embedded in main CLI rather than separate process

  • Why: Single binary distribution; shares CUE evaluation engine; simpler deployment
  • Consequence: CLI bloat; if LSP crashes, CLI process affected; harder to update LSP independently

• Module system using local cue.mod files (Go modules-inspired)

  • Why: Familiar to Go developers; enables local-first dependency resolution; versioning support
  • Consequence: Requires registry infrastructure (modregistry.go, modpublish.go) for public modules; added complexity

• Runtime execution of CUE as a system-level service or daemon (not a server framework)
• GUI/web-based IDE (LSP is text protocol only; IDE support is through language extensions)
• Direct integration with runtime package managers (npm, pip, etc.) — only Go and Kubernetes ecosystems
• Backward compatibility with CUE v0.1.x (breaking changes allowed per semver v0.x)

No external service dependencies discovered, but be aware: (1) Go 1.25+ is hard-required per README—older toolchains will fail silently. (2) cmd/cue/cmd/experiments_help_gen.go and gen_experiments_help.go suggest hidden feature flags; check --help and docs for experimental features that may be unstable. (3) LSP/IDE features (workspace integration tests) are under active development and may have breaking changes. (4) The monorepo includes both CLI and library usage; imported code from cuelang.org/go may diverge from cmd/cue CLI behavior. (5) No visible CONTRIBUTING.md specifics on branch strategy or PR process in the file list—check CONTRIBUTING.md directly.

• Constraint Solving — CUE's core evaluation engine is a constraint solver, not a traditional expression evaluator; understanding unification and constraint propagation is critical for debugging type errors and performance.
• Unification (Logic Programming) — CUE borrowed unification from Prolog/logic languages; fields and types are unified bidirectionally, allowing implicit schema inference that confuses users from imperative languages.
• Ordered Maps / Field Ordering — CUE preserves field declaration order (unlike Go JSON marshaling), critical for deterministic output and YAML/TOML round-tripping; eval.go likely uses ordered map structures internally.
• Multi-Format Marshaling (Interop) — export.go handles JSON, YAML, TOML, Go code, Protobuf, and OpenAPI; understanding format-specific quirks (e.g., YAML anchors, Protobuf oneof) is essential for cross-format workflows.
• LSP (Language Server Protocol) — cmd/cue/cmd/integration/workspace/ tests LSP features (hover, diagnostics, code actions); CUE is actively building IDE support via LSP, a modern alternative to language-specific plugins.
• Gradual Typing — CUE allows mixing typed and untyped values in schemas; understanding gradual typing helps reason about validation strictness and inference behavior.
• Code Generation from Schemas (OpenAPI → Go → CUE) — cmd/cue/cmd/get_go.go and get_crd.go reverse-engineer Go structs and K8s CRDs into CUE schemas; this bidirectional transformation is unique and requires understanding AST manipulation and reflection.

• open-policy-agent/opa — Policy-as-code language competing in configuration validation space; OPA uses Rego while CUE unifies schemas and data in a single language.
• jsonnet/jsonnet — Templating language for JSON/YAML generation; CUE offers stricter types and validation where Jsonnet prioritizes flexibility.
• cue-sh/cue-lang-tools — VSCode extension and IDE tooling for CUE; consumers of the LSP implementation in cmd/cue/cmd/integration/workspace/.
• kubernetes/kubernetes — Major use case for CUE (Kubernetes YAML validation and generation); cue get crd (cmd/cue/cmd/get_crd.go) directly targets K8s schemas.
• helm/helm — Package manager for Kubernetes; CUE is often used as an alternative templating layer for Helm chart validation.

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 integration tests for LSP workspace folder operations

The workspace integration tests in cmd/cue/cmd/integration/workspace/ cover many LSP scenarios (diagnostics, formatting, rename, symbols, etc.), but workspace_folders_test.go appears to be one of the thinnest test files. Multi-root workspace support is critical for IDE integration and deserves comprehensive test coverage for edge cases like switching between folders, cross-folder references, and module resolution across workspace boundaries.

• [ ] Review cmd/cue/cmd/integration/workspace/workspace_folders_test.go for coverage gaps
• [ ] Add test cases for: multi-root module resolution, cross-folder imports, folder switching scenarios
• [ ] Add test fixtures in cmd/cue/cmd/integration/workspace/ for multi-folder test scenarios
• [ ] Verify tests run in the trybot CI pipeline via .github/workflows/trybot.yaml

Add GitHub Actions workflow for module registry functionality testing

The codebase has extensive module management commands (cmd/cue/cmd/mod*.go files including modregistry.go, modrename.go, modpublish.go, modmirror.go) but there's no dedicated CI workflow visible in .github/workflows/ that specifically tests module registry operations. Current workflows (trybot.yaml, release.yaml) likely cover basic testing, but registry operations need isolated end-to-end testing to prevent regression in critical package management features.

• [ ] Create .github/workflows/mod-registry-test.yaml for dedicated module registry testing
• [ ] Add test targets for: modregistry, modpublish, modmirror, modresolve commands
• [ ] Include tests for version resolution, publishing workflows, and mirror functionality
• [ ] Ensure workflow is triggered on push to master and in PR validation

Add unit tests for cmd/cue/cmd/modedit.go and modfix.go

The module editing commands (modedit.go, modfix.go) handle CUE module manifest manipulation and are critical for dependency management. Unlike other cmd/ files which have corresponding integration tests in cmd/cue/cmd/integration/, these module editing commands appear to lack dedicated test coverage. Adding tests would prevent regressions in module file transformations.

• [ ] Create cmd/cue/cmd/modedit_test.go with tests for module manifest editing scenarios
• [ ] Create cmd/cue/cmd/modfix_test.go with tests for automated module fixes/migrations
• [ ] Test cases should cover: adding/removing/updating dependencies, version constraints, schema changes
• [ ] Verify tests integrate with existing test infrastructure and pass in trybot.yaml

• Add integration tests for the cue import command (cmd/cue/cmd/import.go): Create cmd/cue/cmd/integration/imports_test.go with test cases for circular imports, versioning, and ambiguity handling to match the patterns in imports_canonical_test.go and imports_old_modules_test.go.
• Improve error messages for the cue add command (cmd/cue/cmd/add.go): Currently minimal docs visible; audit error paths and add human-friendly suggestions (e.g., 'Did you mean --project?' when flags are missing), similar to the diagnostics system in hover_test.go.
• Extend format interop tests: cmd/cue/cmd/get_crd.go exists but no visible test file; create cmd/cue/cmd/get_crd_test.go with fixtures for Kubernetes CRD conversion (OpenAPI → CUE), a high-value feature that likely has untested edge cases.

The CUE language repository shows generally good security practices with organized code structure and comprehensive testing. Primary concerns are: (1) potential input validation issues in configuration parsing and LSP server implementation, (2) module resolution security during external package downloads, and (3) need for explicit security documentation around configuration evaluation. No critical vulnerabilities were identified from file structure analysis alone, but code-level review of parsing/deserialization logic and network operations is recommended. The project appears to follow Go best practices and includes proper test coverage, which aids security.

• Medium · Potential Insecure Deserialization in CUE Language Parser — cmd/cue/cmd/eval.go, cmd/cue/cmd/export.go, cmd/cue/cmd/import.go. CUE is a configuration language that parses and evaluates user-supplied configuration files. The cmd/cue/cmd directory contains multiple command handlers (eval.go, export.go, import.go, etc.) that process external input. Without explicit code review, there's a risk of deserialization vulnerabilities when parsing untrusted CUE configuration files. Fix: Implement strict input validation and sanitization for all CUE file parsing operations. Use sandboxing or resource limits when evaluating untrusted configurations. Add security tests for malformed/malicious input.
• Medium · Module Resolution Security Risk — cmd/cue/cmd/mod.go, cmd/cue/cmd/modget.go, cmd/cue/cmd/modresolve.go, cmd/cue/cmd/modregistry.go. The module system (cmd/cue/cmd/mod.go, modget.go, modresolve.go) handles external module dependencies and registry interactions. Potential risks include: insecure HTTP downloads, missing certificate pinning, or Man-in-the-Middle (MITM) attacks during module resolution. Fix: Enforce HTTPS-only for all registry communications. Implement certificate pinning for known registries. Validate checksums/signatures of downloaded modules. Consider implementing a lock file mechanism.
• Medium · LSP Server Potential Input Handling Vulnerability — cmd/cue/cmd/lsp.go. The cmd/cue/cmd/lsp.go file implements a Language Server Protocol interface. LSP servers can be vulnerable to denial-of-service or code execution attacks through malicious file paths, workspace configurations, or malformed requests. Fix: Implement strict input validation for all LSP messages. Add rate limiting and resource constraints. Sanitize file paths to prevent directory traversal attacks. Set maximum file size limits for processing.
• Low · Missing Security-Relevant Configuration Defaults — .claude/settings.json, cmd/cue/cmd/flags.go. The .claude/settings.json file and various configuration files may contain settings that affect security behavior. Without visibility into content, unclear if secure defaults are enforced. Fix: Ensure all security-related flags default to secure values. Document security-relevant configuration options clearly.
• Low · Test Data with Broken Modules — cmd/cue/cmd/testdata/module_broken/. The testdata directory contains cmd/cue/cmd/testdata/module_broken/ which by design contains broken module configurations. While intended for testing, these should not be included in production artifacts. Fix: Ensure testdata is excluded from production builds and releases. Verify test data is not shipped with binaries or published packages.
• Low · Incomplete Go Version Information — README.md. The README indicates Go 1.25+ requirement, but the full version constraint is truncated in the provided snippet. This could indicate unclear dependency management documentation. Fix: Ensure complete and clear Go version requirements are documented. Consider using go.mod for enforcing minimum Go versions.

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

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

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/cue-lang/cue 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.

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

What it runs against: a local clone of cue-lang/cue — 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 cue-lang/cue | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of cue-lang/cue. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/cue-lang/cue.git
#   cd cue
#
# 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 cue-lang/cue and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "cmd/cue/cmd/root.go" \\
  && ok "cmd/cue/cmd/root.go" \\
  || miss "missing critical file: cmd/cue/cmd/root.go"
test -f "cmd/cue/cmd/cmd.go" \\
  && ok "cmd/cue/cmd/cmd.go" \\
  || miss "missing critical file: cmd/cue/cmd/cmd.go"
test -f "cmd/cue/cmd/common.go" \\
  && ok "cmd/cue/cmd/common.go" \\
  || miss "missing critical file: cmd/cue/cmd/common.go"
test -f "cmd/cue/cmd/lsp.go" \\
  && ok "cmd/cue/cmd/lsp.go" \\
  || miss "missing critical file: cmd/cue/cmd/lsp.go"
test -f "cmd/cue/cmd/mod.go" \\
  && ok "cmd/cue/cmd/mod.go" \\
  || miss "missing critical file: cmd/cue/cmd/mod.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
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/cue-lang/cue"
  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).

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