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/bchavez/Bogus 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 — Slowing — last commit 5mo ago

• Last commit 5mo ago
• 18 active contributors
• Other licensed
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected

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

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

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

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

# 4. Critical files exist
test -f "Source/Bogus/Faker.cs" \\
  && ok "Source/Bogus/Faker.cs" \\
  || miss "missing critical file: Source/Bogus/Faker.cs"
test -f "Source/Bogus/DataSets/DataSet.cs" \\
  && ok "Source/Bogus/DataSets/DataSet.cs" \\
  || miss "missing critical file: Source/Bogus/DataSets/DataSet.cs"
test -f "Source/Bogus/Randomizer.cs" \\
  && ok "Source/Bogus/Randomizer.cs" \\
  || miss "missing critical file: Source/Bogus/Randomizer.cs"
test -f "Source/Bogus.Tests/FluentTests.cs" \\
  && ok "Source/Bogus.Tests/FluentTests.cs" \\
  || miss "missing critical file: Source/Bogus.Tests/FluentTests.cs"
test -f "Examples/ExtendingBogus/Program.cs" \\
  && ok "Examples/ExtendingBogus/Program.cs" \\
  || miss "missing critical file: Examples/ExtendingBogus/Program.cs"

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

Bogus is a .NET fake data generator library that ports faker.js to C#, F#, and VB.NET. It generates realistic dummy data for databases, UIs, and test suites through a fluent API inspired by FluentValidation, supporting .NET Standard 1.3+ and .NET Framework 4.0+. Monorepo structure: Source/Bogus contains the core library (706KB C#), Source/Bogus.Tests houses the test suite, Source/Benchmark contains performance benchmarks, and Examples/ provides runnable sample projects (GettingStarted, ExtendingBogus, EFCoreSeedDb) demonstrating integration patterns.

.NET developers writing integration tests, seeding test databases, and populating UIs with realistic fake data without manually crafting test fixtures. Used by teams at Bitwarden, Elasticsearch, FluentValidation, and Microsoft learning content.

Production-ready and actively maintained. The project has substantial adoption (evidenced by use in major projects like Bitwarden and Elasticsearch), a comprehensive test suite (Source/Bogus.Tests), CI/CD via AppVeyor, and extensive examples in Examples/. Last activity and version numbering suggest active development with stable releases.

Low risk overall—single maintainer (bchavez) is a moderate concern for continuity, but the library is stable and widely relied upon. Dependencies are minimal and well-established (gulp, lodash, bson for tooling). No evidence of breaking changes in recent history; long-term API stability is a strength.

The codebase includes recent benchmark additions (Source/Benchmark/PR300_* files) suggesting performance optimization work. The HISTORY.md and semantic versioning indicate regular releases. Premium extensions (Bogus Premium) are being offered alongside the open-source core.

git clone https://github.com/bchavez/Bogus.git && cd Bogus && dotnet restore && dotnet build Source/Bogus/Bogus.csproj

Daily commands: dotnet build Source/Bogus/Bogus.csproj to compile the library; dotnet test Source/Bogus.Tests to run the test suite; cd Examples/GettingStarted && dotnet run to execute example projects.

• Source/Bogus/Faker.cs — Core entry point for the Bogus API; every contributor must understand the Faker<T> generic class and fluent API design pattern
• Source/Bogus/DataSets/DataSet.cs — Abstract base for all data generators (Address, Name, Internet, etc.); essential to understand inheritance model for extending Bogus
• Source/Bogus/Randomizer.cs — RNG wrapper and utility methods; critical for reproducibility via seeding and random number generation performance
• Source/Bogus.Tests/FluentTests.cs — Demonstrates fluent API usage patterns and RuleFor conventions that all contributors must follow
• Examples/ExtendingBogus/Program.cs — Shows canonical pattern for extending Bogus with custom data sets and extensions
• Source/Bogus/Bogus.csproj — NuGet package definition, target frameworks (.NET Standard, .NET 6+, etc.), and build configuration
• CONTRIBUTING.md — Contribution guidelines, coding standards, and pull request expectations for all contributors

Add a New DataSet for Custom Domain

1. Create a new class inheriting from DataSet in Source/Bogus/DataSets/ (Source/Bogus/DataSets/DataSet.cs)
2. Implement generator methods returning fake data (e.g., public string FakeItem() => Random.ArrayElement(_items)) (Examples/ExtendingBogus/FoodDataSet.cs)
3. Register the DataSet in FakerHub to expose it via Faker.YourDataSet (Source/Bogus/FakerHub.cs)
4. Add locale-specific data files to Source/Bogus/Localisation/ if needed (Source/Bogus/Localisation)
5. Write unit tests in Source/Bogus.Tests/DataSetTests/YourDataSetTest.cs (Source/Bogus.Tests/DataSetTests/AddressTest.cs)

Extend Existing DataSet with Custom Methods

1. Create an extension class with public static methods accepting the DataSet type (Examples/ExtendingBogus/ExtensionsForAddress.cs)
2. Use the DataSet's Random property for consistent seeding: this.Random.Next(...) (Source/Bogus/DataSets/DataSet.cs)
3. Add unit tests for your extensions in Source/Bogus.Tests/ExtensionTests/ (Source/Bogus.Tests/ExtensionTests/ExtensionTest.cs)

Add Support for New Locale

1. Create locale YAML files in Source/Bogus/Localisation/ following existing pattern (e.g., Source/Bogus/Localisation/de.yml) (Source/Bogus/Localisation)
2. Register locale in LocalizationProvider and Database if using SQL-based data (Source/Bogus/DataSets/Database.cs)
3. Write locale-specific tests in Source/Bogus.Tests/ExtensionTests/ (e.g., SwedishExtensionTest.cs) (Source/Bogus.Tests/ExtensionTests/SwedishExtensionTest.cs)

Generate Fake Objects with Fluent API

1. Create a Faker<T> instance and define RuleFor rules for each property (Examples/GettingStarted/Program.cs)
2. Use built-in DataSets via Hub: f => f.Internet.Email(), f => f.Name.FullName() (Source/Bogus/FakerHub.cs)
3. Call Generate() or GenerateBetween() to produce fake instances (Source/Bogus.Tests/FluentTests.cs)
4. Optionally set seed for reproducible tests: faker.UseSeed(12345) (Source/Bogus/Faker.cs)

• .NET Standard + Multi-targeting — Enables single codebase to support C#, F#, VB.NET across .NET Framework, .NET Core, .NET 5+; maximizes audience and backwards compatibility
• Fluent API (Method Chaining) — Inspired by FluentValidation; provides intuitive, readable DSL for defining fake data rules without complex constructors
• YAML/JSON Locale Data Files — Separates data from code; enables crowdsourced community translations without recompilation; reduces binary size
• Generic Faker<T> with Reflection — Allows type-safe property mapping (RuleFor) while supporting any POCO; minimal boilerplate for end users
• Seeded RNG (Randomizer) — Critical for test reproducibility; same seed produces identical fake data across test runs

• Ported from faker.js (JavaScript) rather than original design

  • Why: Leverages proven API design and feature parity with popular JS library; reduces design risk
  • Consequence: Some idioms feel non-idiomatic in C# (e.g., method names, data structure choices); but familiar to JavaScript developers

• Synchronous-only API (no async/await)

  • Why: Fake data generation is CPU-bound and rarely I/O-dependent; simpler API surface, faster method calls
  • Consequence: Cannot support async data sources (e.g., external APIs for geo data); users must fetch data upfront if needed

• Locale data embedded in NuGet package (not downloaded)

  • Why: Zero external dependencies at runtime; offline-friendly; predictable binary size and licensing
  • Consequence: Large package size (~1-2MB); cannot hot-swap locales; users must upgrade package for new locales

• Single-threaded RNG (not thread-safe by default)

  • Why: Better performance for single-threaded test scenarios (most common); simpler code
  • Consequence: Users generating fake data concurrently must manage RNG

Locale data must be explicitly loaded or selected (not automatic detection). Faker<T> instances are thread-safe by default due to Random wrapping, but custom extensions must respect this. Seeding for reproducibility requires explicit Seed() calls on the Faker instance. BSON support (BsonTests.cs) is optional and requires separate handling for MongoDB scenarios.

• Fluent Builder Pattern — Bogus's entire API is built on this pattern (Faker<T>.RuleFor() chains)—understanding it is essential for using the library effectively
• Locale-Aware Data Generation — Bogus supports multiple locales with translated data (addresses, names, phone numbers)—understanding how locale selection works prevents generating implausible data
• Seeding for Reproducibility — Tests requiring deterministic fake data use Faker.Seed() to ensure consistent output across runs—critical for reliable test suites
• Thread-Safe Random Number Generation — Bogus wraps System.Random to provide thread-safe instances—important when generating large datasets in parallel scenarios
• Property-Based Testing with Fake Data — Bogus enables generating large datasets for property-based tests, allowing discovery of edge cases in data processing logic
• ORM Integration (EF Core Seeding) — Examples/EFCoreSeedDb shows how to use Bogus with Entity Framework Core for database seeding—a common real-world pattern

• faker-js/faker — The original JavaScript library that Bogus is ported from; reference for feature parity and API design
• JeremySkinner/FluentValidation — Inspired Bogus's fluent builder syntax; understanding FluentValidation helps with API philosophy
• nsubstitute/NSubstitute — Common companion library for .NET testing—often used with Bogus for mocking while Bogus generates test data
• xunit/xunit — Popular .NET test framework used with Bogus for writing unit and integration tests
• AutoFixture/AutoFixture — Alternative .NET fake data generator with different API philosophy; direct competitor for test data generation

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 DataSet locale variants

The repo has extensive DataSet tests (AddressTest.cs, NameTests.cs, etc.) but lacks coverage for locale-specific data generation. Bogus supports multiple locales (evident from the faker.js port), but there are no tests in Source/Bogus.Tests/DataSetTests/ verifying that different locales (e.g., de_DE, fr_FR, ja_JP) generate appropriately localized fake data. This is critical for a localization-heavy library.

• [ ] Create Source/Bogus.Tests/DataSetTests/LocaleTests.cs to test locale-specific data generation
• [ ] Add tests for at least 3-5 different locales (German, French, Japanese) across Address, Name, and Company datasets
• [ ] Verify that locale switching produces different outputs and doesn't fall back to en_US unexpectedly
• [ ] Reference existing DataSetTests pattern in AddressTest.cs and NameTests.cs for consistency

Add GitHub Actions CI workflow for multi-targeted framework testing

The repo targets C#, F#, and VB.NET across multiple .NET versions (evident from DateTest.net60.cs), but no CI workflow file exists in .github/workflows/. AppVeyor is referenced in README but a GitHub Actions workflow would enable faster feedback and better integration. This should test .NET Framework 4.7.2, .NET 6, .NET 7+ across all three languages.

• [ ] Create .github/workflows/ci.yml with matrix strategy for .NET versions (net472, net6.0, net8.0)
• [ ] Configure test matrix to run Source/Bogus.Tests/Bogus.Tests.csproj and example projects
• [ ] Add benchmark validation step using Source/Benchmark/Benchmark.csproj to catch performance regressions
• [ ] Ensure both Windows and Linux runners are tested due to cross-platform .NET support

Add XML documentation and generate API reference docs for public DataSet classes

The repo has minimal inline code documentation. Public DataSet classes in Source/Bogus (Address, Name, Company, Finance, etc.) lack XML doc comments that would enable IntelliSense and automated documentation generation. This impacts developer experience and discoverability, especially for new contributors learning the library structure.

• [ ] Add XML doc comments (///) to all public methods in Source/Bogus DataSet classes (minimum: Address.cs, Name.cs, Company.cs, Internet.cs, Finance.cs)
• [ ] Include examples in doc comments showing common usage patterns (e.g., faker.Address.City())
• [ ] Update .csproj GenerateDocumentationFile setting if not already enabled
• [ ] Consider adding DocFX configuration to auto-generate and host API docs (referenced in CONTRIBUTING.md if present)

• Add missing locale data files for underrepresented countries—check Source/Bogus for gaps in available locales and contribute missing translation files following the existing pattern
• Expand Examples/ExtendingBogus with a new domain-specific example (e.g., e-commerce, healthcare, finance)—each demonstrates a different extension pattern and would help new users
• Add benchmark comparisons in Source/Benchmark for common generation scenarios (e.g., generating 10k Person objects vs. raw Random)—would help users understand performance characteristics

The Bogus codebase has moderate security concerns primarily centered on outdated and vulnerable dependencies. The most critical issues are outdated versions of lodash (4.17.20) with known prototype pollution vulnerabilities, event-stream, and the use of Node.js 12.18.1 which is past end-of-life. While the project itself appears to be a well-maintained fake data generator with no obvious code-level vulnerabilities visible, the development environment and build dependencies need immediate attention. Implement automated dependency scanning (npm audit, Snyk, or similar) and establish a policy for regular dependency updates. The lack of a visible lock file also introduces reproducibility and security risks.

• High · Outdated Lodash Dependency with Known Vulnerabilities — package.json - devDependencies.lodash. The package.json specifies lodash version 4.17.20, which contains multiple known security vulnerabilities including prototype pollution (CVE-2021-23337) and other denial-of-service issues. This version was released in 2020 and has been superseded by patched versions. Fix: Update lodash to version 4.17.21 or later. Run 'npm audit' and 'npm update' to identify and patch all vulnerable dependencies.
• High · Outdated Event-Stream Dependency — package.json - devDependencies.event-stream. The package.json specifies event-stream version 4.0.1, which is an old version that may contain known vulnerabilities. This is a foundational streaming library and should be kept current. Fix: Update event-stream to the latest stable version. Review the changelog for any breaking changes before updating.
• Medium · Outdated Node.js Version in Volta Configuration — .volta configuration in package.json. The volta.json configuration specifies Node.js 12.18.1, which reached end-of-life on April 30, 2022. Using outdated Node.js versions exposes the development environment to known security vulnerabilities and lack of security patches. Fix: Upgrade Node.js to an LTS version (18.x, 20.x, or later). Update volta.node to a supported LTS release and ensure all developers and CI/CD pipelines use the updated version.
• Medium · Multiple Outdated Development Dependencies — package.json - devDependencies. Several devDependencies are significantly outdated: gulp (4.0.2), gulp-load-plugins (2.0.5), and underscore (1.11.0). Outdated dependencies may contain known vulnerabilities or lack security patches. Fix: Run 'npm audit' to identify all vulnerable packages. Update all devDependencies to their latest compatible versions. Implement automated dependency scanning in CI/CD.
• Low · No Package Lock File Specified — Repository root. The repository does not appear to have a package-lock.json or yarn.lock file visible in the provided structure. Without a lock file, dependency versions may vary between installations, leading to inconsistent security postures. Fix: Ensure package-lock.json is committed to version control and kept up-to-date. Use 'npm ci' instead of 'npm install' in CI/CD pipelines for consistent dependency resolution.
• Low · Potential Prototype Pollution in Underscore Library — package.json - devDependencies.underscore. The underscore library (version 1.11.0) is outdated and underscore has had historical security issues related to unsafe operations. Using both underscore and lodash is redundant and increases attack surface. Fix: Remove underscore if lodash is already in use, or update both to latest versions. Conduct a code review to ensure neither library is being used unsafely.

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.