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/cake-build/cake 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

• Last commit 4w ago
• 7 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 83% 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 cake-build/cake repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/cake-build/cake.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "cake-build/cake(\\.git)?\\b" \\
  && ok "origin remote is cake-build/cake" \\
  || miss "origin remote is not cake-build/cake (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 develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "build.cake" \\
  && ok "build.cake" \\
  || miss "missing critical file: build.cake"
test -f "src/Cake.Cli/Hosts/BuildScriptHost.cs" \\
  && ok "src/Cake.Cli/Hosts/BuildScriptHost.cs" \\
  || miss "missing critical file: src/Cake.Cli/Hosts/BuildScriptHost.cs"
test -f "src/Cake.Cli/Infrastructure/CakeSpectreReportPrinter.cs" \\
  && ok "src/Cake.Cli/Infrastructure/CakeSpectreReportPrinter.cs" \\
  || miss "missing critical file: src/Cake.Cli/Infrastructure/CakeSpectreReportPrinter.cs"
test -f "src/Cake.Cli/Features/VersionResolver.cs" \\
  && ok "src/Cake.Cli/Features/VersionResolver.cs" \\
  || miss "missing critical file: src/Cake.Cli/Features/VersionResolver.cs"
test -f "global.json" \\
  && ok "global.json" \\
  || miss "missing critical file: global.json"

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

Cake is a cross-platform C# DSL-based build automation system that lets developers write build scripts in C# instead of shell/batch. It handles compilation, file operations, testing, NuGet packaging, and CI/CD orchestration on Windows, macOS, and Linux via a single codebase. Modular runner architecture: src/Cake.Cli.Tests and broader src/ structure suggest separate CLI and core abstractions. Build system is self-hosted (build.cake orchestrates the build using Cake itself), with credential/signing pipelines in build/ (signclient.filter, signtool.cake, credentials.cake). Deployment targets NuGet via nuspec/. Configuration-driven: GitVersion.yml, global.json, and .editorconfig centralize settings.

.NET/C# developers and DevOps engineers who want to replace PowerShell/Bash build scripts with type-safe, intellisense-enabled C# code; teams managing complex multi-platform builds and deployments.

Highly mature and actively maintained—Cake is a long-standing project with three distribution channels (Cake .NET Tool, Cake Frosting, Cake SDK), comprehensive CI/CD setup across Azure Pipelines/GitHub Actions/GitLab/Woodpecker, and structured release management (GitReleaseManager.yaml, GitVersion.yml). Currently in active development with multiple test suites (Cake.Cli.Tests visible in file structure).

Low risk overall for production use; no obvious single-maintainer bottleneck evident in the structure. Primary risks: the monolithic C# codebase (~8MB) could be complex to navigate for new contributors; PowerShell/Shell build tooling (~7KB combined) suggests Windows-first development history; ensure you're targeting the correct runner variant (Tool vs. Frosting vs. SDK) for your use case, as breaking changes between versions are possible.

Active development on CLI reporting/output (CakeSpectreReportPrinterTests with verbosity levels: Diagnostic, Minimal, Normal, Quiet, Verbose). GitHub workflow automation (build.yml, codeql-analysis.yml, release.yml) indicates continuous integration and security scanning. Multiple CI platform support (Azure Pipelines, GitHub Actions, GitLab CI, Woodpecker) suggests ongoing cross-platform maturation.

Clone the repo with git clone https://github.com/cake-build/cake.git && cd cake, then run the platform-specific build: ./build.sh (Linux/macOS) or ./build.ps1 (Windows). Restore dependencies and build with dotnet build (global.json pins .NET version). Run tests via dotnet test src/Cake.Cli.Tests/Cake.Cli.Tests.csproj.

Daily commands: After cloning and restoring (dotnet restore): On Windows, run ./build.ps1 (or powershell -ExecutionPolicy Bypass -File ./build.ps1 if restricted). On Linux/macOS, run ./build.sh. Both scripts delegate to Cake (build.cake), which orchestrates compilation, testing, and packaging. Examine build/parameters.cake for configurable targets (e.g., --target=Build, --target=Test, --target=Pack).

• build.cake — Main build automation script that orchestrates the entire Cake build process including compilation, testing, and packaging.
• src/Cake.Cli/Hosts/BuildScriptHost.cs — Entry point for executing Cake build scripts; responsible for parsing, compiling, and running user-defined build tasks.
• src/Cake.Cli/Infrastructure/CakeSpectreReportPrinter.cs — Core reporting and output formatting system that renders build task execution status and diagnostics to the user.
• src/Cake.Cli/Features/VersionResolver.cs — Manages version detection and resolution for the Cake runner, critical for compatibility and release management.
• global.json — Specifies the .NET SDK version used for building Cake itself, ensuring consistent build environment across all contributors.
• GitVersion.yml — Semantic versioning configuration that automates version numbering based on git history and branch strategy.
• CONTRIBUTING.md — Defines contribution guidelines, code standards, and development workflow that all contributors must follow.

Add a new CLI feature or command

1. Create a new feature class in src/Cake.Cli/Features/ implementing the feature logic (src/Cake.Cli/Features/VersionFeature.cs)
2. Register the feature in the DI container and CLI argument parser (typically in a Program.cs or similar entry point) (src/Cake.Cli/Hosts/BuildScriptHost.cs)
3. Add corresponding unit tests in src/Cake.Cli.Tests/Unit/ (src/Cake.Cli.Tests/Unit/CakeSpectreReportPrinterTests.cs)
4. Update README and documentation to describe the new feature (README.md)

Improve task output and reporting

1. Modify the report printer to add new formatting, colors, or information levels (src/Cake.Cli/Infrastructure/CakeSpectreReportPrinter.cs)
2. Add or update verbosity level handling (Quiet, Minimal, Normal, Verbose, Diagnostic) (src/Cake.Cli/Infrastructure/VerbosityConverter.cs)
3. Add snapshot tests for each verbosity level in the Expectations folder (src/Cake.Cli.Tests/Expectations)
4. Run verification tests to update baseline expectations (src/Cake.Cli.Tests/VerifyConfig.cs)

Add support for a new build system or CI/CD platform

1. Create fixture and fixture info classes in src/Cake.Common.Tests/Fixtures/Build/ (src/Cake.Common.Tests/Fixtures/Build/AppVeyorFixture.cs)
2. Implement the build system provider in the Common package (typically in a BuildSystem namespace) (src/Cake.Common.Tests/Fixtures/Build/AppVeyorInfoFixture.cs)
3. Add comprehensive unit tests for the new provider (src/Cake.Common.Tests)
4. Update CI/CD workflow files to include builds on the new platform (.github/workflows/build.yml)

Modify the main build process or add a new build step

1. Edit the main build cake script to add or modify tasks (build.cake)
2. If adding parameters, update the parameters file (build/parameters.cake)
3. For version-dependent logic, update the version resolver (build/version.cake)
4. If adding signing or code signing steps, update the signtool configuration (build/signtool.cake)

• C# DSL for build scripts — Allows .NET developers to write build logic in familiar C# language with IntelliSense support, type safety, and full language features rather than shell scripts or XML.
• Spectre.Console for output formatting — Provides rich terminal output with colors, tables, and progress indicators across Windows, macOS, and Linux platforms, improving user experience and readability.
• Multi-platform support (.NET Tool, Frosting, SDK) — Enables Cake to run on any system with .NET installed, supporting diverse development environments and CI/CD pipelines without platform-specific recompilation.
• Snapshot testing (Verify library) — Validates output formatting changes across all verbosity levels by comparing against approved baselines, preventing unintended regressions in user-facing output.
• GitVersion for semantic versioning — Automates version numbering based on git history and branching strategy (e.g., SemVer), reducing manual version management and ensuring consistent release versioning.

• Cake scripts are dynamically compiled at runtime rather than pre-compiled

  • Why: Provides flexibility and dynamic task definition, allowing users to write task logic inline without separate compilation steps.
  • Consequence: First-time build execution has startup overhead for script compilation; subsequent runs benefit from caching.

• Support multiple runner flavors (Tool, Frosting, SDK) with slightly different APIs

  • Why: Accommodates different use cases: simple scripts (Tool), strongly-typed builds (Frosting), and embedded SDK scenarios.
  • Consequence: Increased maintenance burden with three code paths; potential inconsistencies between flavors.

• Dependency resolution and task ordering handled by user-defined task dependencies

  • Why: Gives users full control over task execution order and parallelization patterns.
  • Consequence: User errors in dependency declaration can cause incorrect execution order or deadlocks; requires clear documentation.

• undefined

  • Why: undefined
  • Consequence: undefined

1. Self-hosting paradox: build.cake is written in Cake syntax, so you need a bootstrapped Cake to build Cake—build.sh and build.ps1 handle this, but don't bypass them. 2. Multi-runner complexity: Cake.Tool, Cake.Frosting, and Cake.SDK have different execution models; ensure you understand which target your code/docs address. 3. NuGet signing: build/signclient.filter and build/signtool.cake require SignClient credentials in CI—local builds may skip signing but release builds will fail without proper setup. 4. Platform-specific paths: PowerShell vs. Shell scripts diverge; test cross-platform changes on both. 5. Verbosity levels in tests: CakeSpectreReportPrinterTests uses verified snapshots (Diagnostic/Minimal/Normal/Quiet/Verbose)—changes to output formatting must update all 5 variants.

• DSL (Domain-Specific Language) — Cake's entire value proposition is a C# DSL for build tasks—understanding DSL design patterns helps you write idiomatic Cake scripts and contribute DSL enhancements
• Self-hosting / Bootstrap problem — Cake's build system is written in Cake (build.cake), creating a circular dependency; resolving this requires understanding how build.sh/build.ps1 bootstrap the initial toolchain
• Multi-target / Cross-platform build matrices — Cake's CI spans Azure Pipelines, GitHub Actions, GitLab CI, Woodpecker with platform-specific shell scripts—core concept for contributors adding new runners or fixing platform bugs
• Semantic Versioning (SemVer) & GitVersion — GitVersion.yml governs how Cake itself is versioned—understanding SemVer and GitFlow integration is essential for releases and understanding breaking change policies
• Addin/Plugin architecture — Cake's extensibility model (referenced in build structure) allows third-party addins for additional task types—understanding the plugin contract helps when integrating new tools
• Code signing & certificate management (SignClient) — Production Cake releases are signed via SignClient (build/signclient.filter)—understanding code signing, certificate stores, and CI credential injection is required for release workflows
• Snapshot testing / Approved.txt pattern — CakeSpectreReportPrinterTests uses verified.txt snapshots to validate output across verbosity levels—this pattern catches subtle output regressions and is used throughout the test suite

• psake/psake — PowerShell-based build automation for .NET—direct competitor; Cake offers type-safe C# over dynamic PowerShell
• nuke-build/nuke — Modern C# build automation using strongly-typed targets—similar DSL philosophy to Cake but more recent design; both compete in the .NET build-as-code space
• microsoft/msbuild — The standard .NET/C# build system (XML-based)—Cake abstracts and extends this for complex orchestration scenarios
• cake-build/cake-docker — Official Cake Docker images—companion repo for containerized Cake builds across platforms
• cake-build/cake-docs — Official documentation repository—essential for understanding Cake syntax, addins, and best practices alongside source code

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 unit tests for CakeSpectreReportPrinter infrastructure component

The src/Cake.Cli/Infrastructure/CakeSpectreReportPrinter.cs file has verified expectation files for various verbosity levels (Diagnostic, Minimal, Normal, Quiet, Verbose) in src/Cake.Cli.Tests/Expectations/, but the corresponding test file src/Cake.Cli.Tests/Unit/CakeSpectreReportPrinterTests.cs appears minimal. This is a high-value area since report printing is critical to user experience and already has test infrastructure in place (verified snapshots). A contributor could expand test coverage for edge cases like null inputs, special characters in step names, and different terminal widths.

• [ ] Review existing src/Cake.Cli.Tests/Unit/CakeSpectreReportPrinterTests.cs to identify coverage gaps
• [ ] Add unit tests for null/empty step names and descriptions in src/Cake.Cli.Tests/Unit/CakeSpectreReportPrinterTests.cs
• [ ] Add unit tests for multi-line step output and ANSI color handling in different verbosity modes
• [ ] Update verified expectations in src/Cake.Cli.Tests/Expectations/ if new test scenarios require them
• [ ] Verify all 5 verbosity levels (Diagnostic, Minimal, Normal, Quiet, Verbose) are covered

Add unit tests for BuildScriptHost and alternative script hosts in src/Cake.Cli/Hosts/

The src/Cake.Cli/Hosts/ directory contains several host implementations (BuildScriptHost.cs, DescriptionScriptHost.cs, DryRunScriptHost.cs, DryRunExecutionStrategy.cs, TreeScriptHost.cs), but there is no corresponding Hosts test folder visible in src/Cake.Cli.Tests/. These hosts are critical execution paths for different Cake runtime modes. Adding unit tests for host behavior (script initialization, execution strategies, tree generation) would significantly improve reliability and prevent regressions.

• [ ] Create src/Cake.Cli.Tests/Unit/Hosts/ directory
• [ ] Add BuildScriptHostTests.cs with tests for script compilation and execution lifecycle
• [ ] Add DryRunScriptHostTests.cs testing DryRunExecutionStrategy behavior
• [ ] Add TreeScriptHostTests.cs testing task tree generation for the --tree feature
• [ ] Add tests for DescriptionScriptHost.cs for --description-only mode
• [ ] Ensure mocking of dependencies (ICakeContext, IExecutionStrategy, etc.)

Expand Features unit test coverage for VersionResolver and VersionFeature

The src/Cake.Cli/Features/ directory contains VersionFeature.cs, VersionResolver.cs, and InfoFeature.cs, but there is no visible test file for these critical features. Version resolution and feature flags are important for CLI stability and user-facing functionality. Adding comprehensive tests would ensure proper handling of version schemes (from GitVersion.yml visible in repo root), fallbacks, and info output across different environments.

• [ ] Create src/Cake.Cli.Tests/Unit/Features/ directory
• [ ] Add VersionResolverTests.cs testing semantic version parsing, GitVersion integration, and fallback logic
• [ ] Add VersionFeatureTests.cs testing CLI --version output formatting and correctness
• [ ] Add InfoFeatureTests.cs testing the info command output structure and completeness
• [ ] Add tests for version resolver behavior when GitVersion.yml configuration is present vs absent
• [ ] Verify version output matches GitVersion.yml and global.json configurations

• Add missing snapshot tests for Spectre report printer edge cases—the verified.txt files only cover happy paths for 5 verbosity levels; add tests for error conditions, multi-line outputs, and special characters.: src/Cake.Cli.Tests/ and add new verified.*.txt expectations
• Enhance the CONTRIBUTING.md with a 'Local Setup Troubleshooting' section—document common issues with SignClient setup, PowerShell execution policies on Windows, and .NET version mismatches based on global.json constraints.: CONTRIBUTING.md
• Create a migration guide in docs/ for users upgrading from Cake v0.x to v3.x—compare build.cake syntax differences, addin/plugin API changes, and runner selection (Tool vs. Frosting).: New file in docs/ or ReleaseNotes.md expansion

The Cake build automation system demonstrates a reasonable security posture with established security reporting procedures and multiple deployment platforms. However, there are notable concerns regarding credential management in build scripts (credentials.cake file), potential input validation risks in build automation, and inconsistent CI/CD configurations across multiple platforms. The project maintains active security communication channels and enforces responsible disclosure. Primary recommendations include implementing secure credential storage practices, standardizing CI/CD security controls, and conducting regular dependency audits. The security score reflects moderate-to-good practices with room for improvement in credential handling and configuration consistency.

• Medium · Credentials File in Build Configuration — build/credentials.cake. The file 'build/credentials.cake' suggests that credentials or sensitive configuration may be stored in the build scripts directory. This could lead to accidental exposure of secrets through version control or build artifacts. Fix: Store credentials in environment variables, secure vaults (e.g., Azure Key Vault), or CI/CD secrets management. Remove 'build/credentials.cake' from version control and use .gitignore to exclude credential files. Use dependency injection or configuration providers to load secrets at runtime.
• Medium · Build Script Execution Without Input Validation — build.cake, build.ps1, build.sh. The presence of 'build.cake', 'build.ps1', and 'build.sh' scripts suggests execution of build automation. Without explicit code review visibility, these could be vulnerable to injection attacks if they process user-supplied input or command-line arguments without proper validation. Fix: Implement strict input validation for all command-line arguments and environment variables used in build scripts. Use parameterized/escaped commands when invoking external tools. Apply the principle of least privilege for script execution.
• Low · Multiple CI/CD Configuration Files — .github/workflows/, .gitlab-ci.yml, .woodpecker.yml, appveyor.yml, bitbucket-pipelines.yml. The repository contains multiple CI/CD pipeline configurations (.github/workflows, .gitlab-ci.yml, .woodpecker.yml, appveyor.yml, bitbucket-pipelines.yml) which increases the surface area for misconfigurations and inconsistent security policies across different CI/CD platforms. Fix: Maintain consistency across all CI/CD configurations. Ensure all pipelines implement the same security controls (e.g., secret masking, artifact retention policies, dependency verification). Consider consolidating to a single primary CI/CD platform where feasible.
• Low · Sign Tool Configuration File Present — build/signtool.cake, build/signclient.filter. The file 'build/signtool.cake' and 'build/signclient.filter' indicate code signing operations. If certificate paths or signing credentials are hardcoded or improperly configured, this could expose the signing infrastructure. Fix: Ensure signing certificates and credentials are stored securely (not in the repository). Use CI/CD secret management for certificate passwords. Verify that 'signclient.filter' doesn't contain sensitive information. Implement certificate pinning and validation.
• Low · Missing HTTPS Enforcement in Documentation — SECURITY.md. While the SECURITY.md file mentions Keybase for reporting vulnerabilities, there is no explicit mention of HTTPS-only communication requirements for reporting security issues through other channels. Fix: Update SECURITY.md to explicitly state that all security reports must be submitted over HTTPS. Provide clear guidelines for secure communication channels. Consider implementing PGP encryption support for critical vulnerability reports.
• Low · Incomplete Dependency Information — .config/dotnet-tools.json, .csproj files. The provided dependency file content is empty or not shown. Cannot verify if the project uses outdated, vulnerable, or unvetted NuGet packages. This is critical for a build tool that users install globally. Fix: Perform regular dependency audits using tools like 'dotnet list package --vulnerable' or Snyk. Implement SBOM (Software Bill of Materials) generation. Use package signing verification. Maintain a dependency policy document.

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.