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/dotnet/tye 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.

GO — Healthy across all four use cases

• 12 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 76% of recent commits

_{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 dotnet/tye repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet/tye.

What it runs against: a local clone of dotnet/tye — 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 dotnet/tye | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 931 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "docs/reference/schema.md" \\
  && ok "docs/reference/schema.md" \\
  || miss "missing critical file: docs/reference/schema.md"
test -f "azure-pipelines.yml" \\
  && ok "azure-pipelines.yml" \\
  || miss "missing critical file: azure-pipelines.yml"
test -f "eng/Versions.props" \\
  && ok "eng/Versions.props" \\
  || miss "missing critical file: eng/Versions.props"

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

Tye is a .NET developer tool that orchestrates microservices locally and deploys them to Kubernetes automatically. It simplifies running multiple services with one command, auto-discovers service addresses via conventions, containerizes .NET apps, and generates Kubernetes manifests—eliminating boilerplate for distributed .NET applications. Monorepo structure with src/ containing the core orchestrator and CLI, docs/ for guides (docs/getting_started.md, docs/developer_guide.md, docs/recipes/ for patterns like Dapr and distributed tracing), and build scripts (build.cmd, build.sh, activate.ps1/sh). PowerShell, Shell, and CMake scripts orchestrate builds; Directory.Build.props/targets define shared .NET project settings.

.NET developers building microservices who want to run local dev environments with multiple services without manual Docker/Kubernetes setup, and DevOps engineers deploying .NET apps to Kubernetes who need minimal configuration.

Experimental but actively developed. The project is intentionally volatile (per README), released roughly every 4 weeks, with CI/CD via Azure Pipelines and GitHub workflows (.github/workflows/format.yml, azure-pipelines.yml). Large C# codebase (1.3M LOC) but explicitly marked as an open-source experiment, so breaking changes are expected—not yet production-hardened.

High volatility by design: the README explicitly states 'consider every part of the tye experience to be volatile' and 'we will frequently make additions and changes.' .NET tooling ecosystem dependency (requires recent .NET SDK), and as an orchestration tool, it orchestrates other services—misconfiguration could cascade. No visible public security audit mentioned; users must self-evaluate security per docs/security guidance.

No specific PR/milestone data is visible in the file structure, but the project follows a 4-week release cadence with active CI (Azure Pipelines public build defined in azure-pipelines.yml). The CODEOWNERS file (.github/CODEOWNERS) and issue templates (bug.md, discussion.md, feedback.md, idea.md) suggest ongoing community engagement and structured issue triage.

Clone: git clone https://github.com/dotnet/tye.git && cd tye. Activate environment: run ./activate.sh (Linux/Mac) or ./activate.ps1 (Windows). Build: run ./build.sh or build.cmd. Requires .NET SDK (check .config/dotnet-tools.json for exact versions). Install Tye: the built CLI can then be used locally.

Daily commands: After build, run tye run in a directory with a tye.yaml config file (see docs/getting_started.md for examples). Locally, it will spin up services and a dashboard. For testing, the project includes PowerShell/Shell test runners (test scripts referenced implicitly in build.sh/build.cmd).

• Directory.Build.props — Central MSBuild properties file that defines version, signing, and build configuration for the entire .NET solution
• README.md — Entry point explaining Tye's purpose, capabilities, and status as an open-source experiment for microservices orchestration
• docs/reference/schema.md — Defines the tye.yaml configuration schema that all users and services must understand to configure deployments
• azure-pipelines.yml — CI/CD pipeline definition that orchestrates builds, tests, and releases across multiple platforms and .NET versions
• eng/Versions.props — Master version control file coordinating dependency versions across all packages in the Tye monorepo
• CONTRIBUTING.md — Guidelines for contributors on development setup, testing, and pull request process specific to Tye
• .github/CODEOWNERS — Defines code ownership and review requirements by file path to maintain architectural boundaries

• Local Orchestrator (.NET, container APIs) — Parses tye.yaml, manages service lifecycle, provides service discovery, and streams logs
  • Failure mode: If orchestrator crashes, all managed services terminate; data loss for in-memory state
• Service Discovery (DNS, HTTP, gRPC) — Resolves service names to endpoints (IP:port) and exposes them via DNS and HTTP
  • Failure mode: If unavailable, inter-service communication fails; services must fallback to hardcoded addresses
• Container Builder (Docker, MSBuild, .NET SDK) — Inspects .NET projects and generates or invokes Docker builds
  • Failure mode: If builder fails, services cannot be containerized; local orchestrator falls back to direct .NET execution
• Manifest Generator (Kubernetes API, YAML templating) — Converts tye.yaml and local service metadata into Kubernetes YAML
  • Failure mode: If generator fails, deployment cannot proceed; user must manually write Kubernetes manifests
• CLI Command Framework (.NET CLI tooling, System.CommandLine) — Parses arguments, dispatches to command handlers (run, build, deploy, push), and formats output
  • Failure mode: If

Add a new CLI command

1. Create a new command handler class following the existing pattern in the src/tye/Commands directory (docs/reference/commandline/README.md)
2. Register the command in the main CLI dispatcher and wire up argument parsing (azure-pipelines.yml)
3. Document the command's syntax, options, and examples in docs/reference/commandline (docs/reference/commandline/tye-run.md)
4. Add integration tests validating the command's behavior with sample projects (eng/common/build.ps1)

Add a new service discovery protocol integration

1. Review the service discovery abstraction in the core service discovery layer (docs/reference/service_discovery.md)
2. Implement the IServiceDiscovery interface in src/tye/ServiceDiscovery (docs/reference/schema.md)
3. Add configuration support for the new protocol in the tye.yaml parser (docs/reference/schema.md)
4. Document usage patterns and examples for the new integration (docs/recipes/logging_seq.md)

Add support for a new deployment target

1. Study existing deployment logic and Kubernetes manifest generation in docs/reference/deployment.md (docs/reference/deployment.md)
2. Create a new deployment provider implementing the IDeploymentProvider interface (docs/reference/commandline/tye-deploy.md)
3. Add container image building support using existing conventions (docs/reference/commandline/tye-build.md)
4. Write documentation and recipes demonstrating deployment to the new platform (docs/recipes/githubactions_aks.md)

• .NET / C# — Tye is designed to orchestrate and deploy .NET microservices; using .NET for the tool itself provides optimal interoperability and performance for container building and manifest generation
• Kubernetes — Standard cloud-native deployment platform; Tye generates Kubernetes manifests to abstract away boilerplate YAML while maintaining portability
• Docker/Container support — Enables local development parity with production; Tye can containerize .NET applications automatically and use existing container images as dependencies
• MSBuild / dotnet CLI — Deep integration with .NET build ecosystem allows Tye to inspect project files, understand dependencies, and generate appropriate deployment artifacts

• Local orchestrator vs. production Kubernetes

  • Why: Developers need fast local iteration without production infrastructure; conventions bridge the gap
  • Consequence: Tye generates manifests rather than directly managing Kubernetes, requiring explicit deploy step but maintaining consistency

• Convention-based configuration over explicit schema

  • Why: Reduces cognitive load for simple cases and accelerates initial setup
  • Consequence: tye.yaml is optional for simple projects but required for complex microservices; some advanced deployments require manual manifest tweaking

• Open source experiment status

  • Why: Allows rapid iteration on radical ideas without stability commitments
  • Consequence: All APIs and configuration formats are volatile; users accept breaking changes every 4 weeks

• Production cluster orchestration — Tye generates Kubernetes manifests but does not itself manage live clusters
• Language-agnostic microservices — Tye is optimized for .NET; non-.NET services can participate but lack automatic containerization
• Persistent state management — Tye focuses on service discovery and orchestration, not data layer persistence
• Advanced networking policies — Tye uses Kubernetes Ingress and service DNS; does not implement custom mesh or policy engines
• Multi-cloud abstraction — Deployment targets are Kubernetes-first; cloud-specific features are out of scope

tye.yaml configuration schema is implicit in code (not fully documented in file list); contributors may need to reverse-engineer from source. Build scripts (build.sh, build.cmd) use activate.ps1/activate.sh which may require .NET SDK activation—order matters. PowerShell execution policy on Windows (build.ps1) may block; users may need Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser. Kubernetes manifest generation is lossy (simplified) by design—not every K8s feature is supported. No vendored dependencies visible; relies on NuGet; offline builds may fail. Azure Pipelines CI is public (.visualstudio.com URL in README), but local security key (build/key.snk) is in repo—handle carefully.

• Service Discovery via Convention — Tye auto-discovers services without manual DNS/registry config; understanding how services resolve each other's addresses (likely via environment variables or a local DNS server) is core to debugging Tye orchestration.
• Kubernetes Manifest Generation — Tye generates K8s YAML from minimal user config; contributors must understand how Tye's simplified mental model maps to K8s primitives (Deployments, Services, ConfigMaps, Secrets).
• Container Orchestration — Tye orchestrates both local containers (via Docker) and Kubernetes clusters; understanding container lifecycle, networking, and resource constraints is essential for debugging service startup and communication.
• Distributed Application Conventions — Tye uses conventions (e.g., naming, port mapping, environment variable injection) to avoid explicit config; learning these conventions is critical to understanding what Tye does implicitly.
• Sidecar Pattern — Tye's Dapr integration (docs/recipes/dapr.md) uses sidecars; understanding how auxiliary containers enhance service behavior helps with observability, service mesh, and resilience patterns.
• .NET CLI Tool Design — Tye is a global .NET tool; understanding how it's packaged, versioned, and invoked via dotnet CLI (dotnet tool install tye) is needed to contribute CLI features and tooling integration.
• YAML Configuration Schema — tye.yaml is Tye's config format (not visible in file list but central to UX); contributors must understand how services, dependencies, and deployment targets are declared and validated.

• dapr/dapr — Dapr is a distributed application runtime that Tye integrates with (docs/recipes/dapr.md); understanding Dapr's sidecar model helps understand Tye's orchestration approach.
• kubernetes/kubernetes — Tye's primary deployment target; knowledge of K8s manifests, resources, and ingress patterns is essential to contribute to manifest generation.
• dotnet/runtime — Core .NET runtime that Tye depends on; breaking changes in dotnet/runtime can affect Tye's CLI and orchestrator.
• docker/docker — Tye auto-containerizes .NET apps using Docker; understanding Docker images and registries is needed to contribute to containerization logic.
• open-telemetry/opentelemetry-dotnet — Distributed tracing integration (docs/recipes/distributed_tracing.md with zipkin.yaml) relies on OpenTelemetry; complementary for observability patterns.

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 GitHub Actions workflow for Node.js/Angular frontend validation

The repo contains an Angular application (based on package.json with @angular dependencies) but there's no CI workflow for linting, building, or testing the frontend. Currently only .github/workflows/format.yml exists. Adding a Node.js validation workflow would catch frontend regressions early and ensure code quality for the UI components that interact with the Tye orchestrator.

• [ ] Create .github/workflows/nodejs-frontend.yml that runs on pull requests
• [ ] Add steps to run 'npm ci', 'npm run lint', 'npm run build', and 'npm run test' (with coverage)
• [ ] Ensure workflow runs against Node.js 14.x and 16.x LTS versions
• [ ] Configure karma to run in headless mode for CI environment
• [ ] Add workflow status badge to README.md

Document Tye configuration schema with inline examples in docs/reference/schema.md

While docs/reference/schema.md exists in the file structure, there's no visible documentation showing complete tye.yaml configuration examples with all available options. Given that tye.yaml is central to the tool's functionality (evidenced by tutorial files referencing postgres.yaml and redis.yaml), comprehensive schema documentation with real examples would reduce user confusion and support questions.

• [ ] Expand docs/reference/schema.md with a complete tye.yaml schema reference
• [ ] Include examples from docs/tutorials/hello-tye/*.yaml files (postgres.yaml, redis.yaml) in the documentation
• [ ] Document all top-level keys: name, version, services, ingress, networks
• [ ] Add a 'Common Patterns' section showing service discovery, health probes, and environment configuration
• [ ] Cross-reference docs/reference/local_development.md for context-specific examples

Add missing recipe documentation for service-to-service communication patterns

The docs/recipes directory contains specialized topics (dapr.md, azure_functions.md, logging, tracing) but lacks documentation for fundamental microservices patterns that Tye enables. Service discovery and inter-service HTTP/gRPC communication is mentioned in docs/reference/service_discovery.md but has no practical recipe with working code examples, making it harder for new users to understand Tye's core value proposition.

• [ ] Create docs/recipes/service_communication.md documenting HTTP and gRPC communication between Tye services
• [ ] Include a working example showing one service calling another using Tye's service discovery (environment variable endpoints)
• [ ] Add code snippets showing both .NET and Node.js/Angular client implementations
• [ ] Document environment variable naming conventions for discovered services
• [ ] Link this recipe from docs/getting_started.md and docs/README.md as a foundational tutorial

• Add missing CLI help documentation for tye build and tye deploy subcommands in docs/reference/commandline/ (currently sparse; could extract from --help and expand with examples).
• Write integration test or recipe for Tye + gRPC services (gRPC is not in docs/recipes/ but is common in .NET microservices; would validate service discovery over gRPC).
• Document or implement missing tye.yaml validation error messages (ensure failures on malformed config are user-friendly, matching CONTRIBUTING.md standards).

The codebase has critical security concerns, primarily due to significantly outdated dependencies in the Angular/Node.js ecosystem. The package.json contains multiple packages from 2021-2022 that are no longer maintained and have known CVEs. Angular 12 is end-of-life, RxJS 6.5.4 is outdated, Protractor is deprecated, and linting tools (

• High · Outdated Angular Dependencies with Known Vulnerabilities — package.json - dependencies section. The package.json contains Angular 12.2.10 and related packages that are significantly outdated. Angular 12 reached end-of-life and contains multiple known security vulnerabilities. The RxJS version 6.5.4 is also outdated with known CVEs. Fix: Upgrade to the latest stable Angular version (v17+) and update all related packages. Run 'npm audit' and resolve all identified vulnerabilities. Update RxJS to version 7.x or latest.
• High · Protractor with Known Security Issues — package.json - devDependencies (protractor ~7.0.0). Protractor 7.0.0 is an outdated end-to-end testing framework that is no longer maintained and has known security vulnerabilities. This should be replaced with modern alternatives. Fix: Replace Protractor with maintained alternatives like Cypress, Playwright, or WebdriverIO. Remove the deprecated dependency.
• High · Outdated TypeScript with Potential Security Issues — package.json - devDependencies (typescript ~4.3.5). TypeScript 4.3.5 is outdated (released in 2021). Current versions include security fixes and improvements. This version may have unpatched vulnerabilities. Fix: Update TypeScript to the latest stable version (5.x). Run 'npm update typescript' and test thoroughly.
• Medium · TSLint Deprecated and No Longer Maintained — package.json - devDependencies (tslint ~6.1.3). TSLint 6.1.3 is deprecated and no longer receives updates or security patches. The linting tool should be replaced with ESLint which is actively maintained. Fix: Migrate from TSLint to ESLint. Update configuration files and remove TSLint dependency. ESLint provides better security and is actively maintained.
• Medium · Outdated Development Dependencies — package.json - devDependencies section. Multiple devDependencies are outdated: @angular-devkit/build-angular (14.2.3), karma (~6.3.16), ts-node (~8.3.0). These may have unpatched security vulnerabilities or known issues. Fix: Run 'npm audit' to identify specific CVEs. Update all dev dependencies to latest versions compatible with the current Node.js version. Test after updates.
• Medium · Missing npm Package Lock File — Repository root. No package-lock.json or yarn.lock file is visible in the file structure. This makes dependency resolution non-deterministic and could lead to different versions being installed in different environments, potentially with security vulnerabilities. Fix: Ensure package-lock.json (npm) or yarn.lock (yarn) is committed to version control. Run 'npm ci' in CI/CD pipelines instead of 'npm install' to use locked versions.
• Low · Missing Security Configuration Files — Repository root. No .npmrc or npm security configuration is visible. The project should have explicit security-related npm configurations. Fix: Create .npmrc with security settings: 'audit-level=moderate' or 'audit-level=high'. Consider using npm's lockfile-version=3 for enhanced security.
• Low · Codelyzer No Longer Maintained — package.json - devDependencies (codelyzer ^6.0.2). Codelyzer 6.0.2 is an Angular linting tool that is no longer actively maintained. While less critical than other issues, it should be replaced with ESLint plugins for Angular. Fix: Replace with @angular-eslint packages and ESLint for linting. This aligns with Angular's current recommendations.

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.