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/LuckyPennySoftware/AutoMapper 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 — Single-maintainer risk — review before adopting

• Last commit 2w ago
• 2 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 92% of recent commits
• ⚠ Non-standard license (Other) — review terms

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

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

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

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

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

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

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

# 4. Critical files exist
test -f "src/AutoMapper/Configuration/MapperConfiguration.cs" \\
  && ok "src/AutoMapper/Configuration/MapperConfiguration.cs" \\
  || miss "missing critical file: src/AutoMapper/Configuration/MapperConfiguration.cs"
test -f "src/AutoMapper/Configuration/MappingExpression.cs" \\
  && ok "src/AutoMapper/Configuration/MappingExpression.cs" \\
  || miss "missing critical file: src/AutoMapper/Configuration/MappingExpression.cs"
test -f "src/AutoMapper/AutoMapperMappingException.cs" \\
  && ok "src/AutoMapper/AutoMapperMappingException.cs" \\
  || miss "missing critical file: src/AutoMapper/AutoMapperMappingException.cs"
test -f "src/AutoMapper/Configuration/IMappingExpression.cs" \\
  && ok "src/AutoMapper/Configuration/IMappingExpression.cs" \\
  || miss "missing critical file: src/AutoMapper/Configuration/IMappingExpression.cs"
test -f "src/AutoMapper/Configuration/Conventions.cs" \\
  && ok "src/AutoMapper/Configuration/Conventions.cs" \\
  || miss "missing critical file: src/AutoMapper/Configuration/Conventions.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 47 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~17d)"
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/LuckyPennySoftware/AutoMapper"
  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).

AutoMapper is a convention-based object-to-object mapper for .NET that eliminates boilerplate code for transforming objects between different types (e.g., domain models to DTOs). It uses reflection and IL generation to automatically map properties by name convention, with support for nested objects, collections, flattening/unflattening, custom type converters, and LINQ-to-SQL query translation via IQueryable extensions. Monolithic .NET solution (AutoMapper.slnx) with core mapping logic at the root, test projects alongside (implied by top 60 files), PowerShell build scripts (Build.ps1, Setup.ps1, Push.ps1) for local development and releases, and extensive Sphinx-based documentation in /docs/ (Makefile, make.bat, source/ with feature guides and upgrade paths). No visible /src or /tests directory split, suggesting flat structure with tests as separate project files in the solution.

.NET developers building multi-layered applications (ASP.NET Core APIs, Enterprise services) who need to map domain models to data transfer objects (DTOs) without writing manual property-by-property translation code. Also used by maintainers of libraries that depend on AutoMapper (Collection extensions, EF6 bindings, enum mapping).

Highly mature and production-ready. The repo shows multiple major version upgrades (5.0 through 15.0 documented in /docs/source/), comprehensive CI/CD setup via GitHub Actions workflows, and established best practices (signed assemblies with AutoMapper.snk, strong documentation via Sphinx/ReadTheDocs). Active maintenance with recent upgrade guides and security policy (SECURITY.md).

Low risk for stable use, but watch for breaking changes across major versions—each version (8.0, 9.0, 10.0, 11.0, 12.0, 13.0, 15.0) has dedicated upgrade guides in /docs/source/, suggesting significant API shifts. Single organizational maintainer (LuckyPennySoftware) with no visible GitHub star count in provided data, so community support visibility is unclear. Tight coupling of downstream projects (Collection, ExpressionMapping, EF6, Data, EnumMapping extensions) means breaking changes impact the ecosystem.

Recent focus on multi-version upgrade support and documentation—upgrade guides exist for versions 5.0, 8.0–9.0, 10.0–15.0, indicating active backport and compatibility work. CI workflows (ci.yml, lock.yml, release.yml) suggest ongoing automated testing and NuGet package publishing. Last observable state shows established release automation and documentation maintenance.

Clone the repository: git clone https://github.com/LuckyPennySoftware/AutoMapper.git && cd AutoMapper. Run setup: ./Setup.ps1 (PowerShell on Windows) or source the shell scripts on Linux/Mac. Build the solution: ./Build.ps1 (or open AutoMapper.slnx in Visual Studio 2022+). For documentation: cd docs && pip install -r requirements.txt && make html (or make.bat html on Windows).

Daily commands: Build: ./Build.ps1 in repository root. For tests, execute via Visual Studio Test Explorer or dotnet test against project files in the solution. For documentation preview: cd docs && sphinx-build -b html source build/html (requires sphinx==7.1.2 and sphinx-rtd-theme==1.3.0rc1 from requirements.txt). No live dev server; this is a library, not an application.

• src/AutoMapper/Configuration/MapperConfiguration.cs — Core configuration class that builds and validates the mapping infrastructure; every contributor must understand how mappings are registered and compiled.
• src/AutoMapper/Configuration/MappingExpression.cs — Defines the fluent API for configuring individual type mappings; essential for understanding how mapping rules are specified.
• src/AutoMapper/AutoMapperMappingException.cs — Custom exception type for mapping errors; critical for understanding error handling and diagnostic information flow.
• src/AutoMapper/Configuration/IMappingExpression.cs — Core abstraction defining the fluent mapping configuration interface; all mapping rules flow through this contract.
• src/AutoMapper/Configuration/Conventions.cs — Implements naming conventions and property matching logic that drives convention-based mapping behavior.
• src/AutoMapper.DI.Tests/DependencyTests.cs — Test suite demonstrating dependency injection patterns used throughout the codebase and external integrations.
• Directory.Build.props — Centralized build configuration for all projects; controls versioning, SDK targets, and build behavior across the solution.

Add a Custom Naming Convention

1. Create a new class implementing INamingConvention interface (see src/AutoMapper/Configuration/INamingConvention.cs) (src/AutoMapper/Configuration/INamingConvention.cs)
2. Implement SplitWords() and NormalizeName() methods to define your custom name transformation rules (src/AutoMapper/Configuration/Conventions.cs)
3. Register the convention in your mapper configuration via MapperConfigurationExpression.AddConventionRule() (src/AutoMapper/Configuration/MapperConfigurationExpression.cs)

Add Attribute-Based Member Configuration

1. Create a new custom attribute class in src/AutoMapper/Configuration/Annotations/, inheriting from an appropriate attribute type (src/AutoMapper/Configuration/Annotations/IMemberConfigurationProvider.cs)
2. Implement IMemberConfigurationProvider to read and apply your attribute's configuration (src/AutoMapper/Configuration/Annotations/IMemberConfigurationProvider.cs)
3. Apply your attribute to source or destination members in mapping classes (src/AutoMapper/Configuration/Annotations/AutoMapAttribute.cs)
4. Validate the attribute configuration works via integration tests in src/AutoMapper.DI.Tests/AttributeTests.cs (src/AutoMapper.DI.Tests/AttributeTests.cs)

Create a Custom Mapping Profile

1. Create a class inheriting from Profile (usually found as a base in IProfileExpression) (src/AutoMapper/Configuration/IProfileExpression.cs)
2. Override the constructor and use CreateMap<TSource, TDest>() fluent API to define mappings (src/AutoMapper/Configuration/MappingExpression.cs)
3. Configure individual mappings with ForMember(), MapFrom(), Condition(), custom converters, etc. (src/AutoMapper/Configuration/IMemberConfigurationExpression.cs)
4. Register your profile in MapperConfiguration via cfg.AddProfile(typeof(YourProfile)) (src/AutoMapper/Configuration/MapperConfiguration.cs)

Add a Custom Value Resolver or Converter

1. Define your custom resolver or converter logic using the ValueResolverAttribute or ValueConverterAttribute patterns (see Configuration/Annotations/) (src/AutoMapper/Configuration/Annotations/ValueResolverAttribute.cs)
2. In your mapping profile, use .ResolveUsing(myResolver) or .ConvertUsing(myConverter) in the fluent ForMember() call (src/AutoMapper/Configuration/MappingExpression.cs)
3. If using DI, ensure your resolver/converter is registered in the service provider and accessible via MapperOperationOptions (src/AutoMapper/Configuration/IMappingOperationOptions.cs)

• C# / .NET — AutoMapper targets the .NET ecosystem; C# enables compile-time type safety for mapping configurations and LINQ/Expression tree usage.
• LINQ Expressions & Expression Trees — Core to AutoMapper's approach: mappings are compiled to efficient IL code at configuration time, avoiding reflection overhead at runtime.
• Fluent API / DSL — Provides an intuitive, chainable configuration syntax (CreateMap → ForMember → MapFrom → Condition) that reads as declarative intent.
• Dependency Injection / Service Provider — Allows custom resolvers, converters, and services to be injected during mapping, enabling testability and decoupling.
• Attribute-Based Configuration — Enables declarative mapping rules directly on source/destination types without separate configuration code.

• Eager compilation at
  • Why: undefined
  • Consequence: undefined

PowerShell scripts (Build.ps1, Setup.ps1, Push.ps1) are Windows-primary; Linux/Mac users must adapt or use dotnet CLI directly. Strong name signing (AutoMapper.snk) is enforced—custom builds or forks must regenerate or disable signing in Directory.Build.props. Documentation build requires exact versions (sphinx==7.1.2, not 7.2+) per requirements.txt. No visible .env or appsettings—configuration is code-first via MapperConfiguration, no external config files expected.

• Convention-Based Mapping — AutoMapper's core philosophy—automatically infer property mappings by name pattern (e.g., FirstName → FirstName) rather than explicit configuration, drastically reducing boilerplate.
• IL Code Generation — AutoMapper compiles mapping expressions to IL at configuration time for near-reflection-free runtime performance; understanding this explains why configuration validation (AssertConfigurationIsValid) is critical and why some mapping patterns compile faster than others.
• Flattening and Unflattening — AutoMapper can map nested objects (Order.Customer.Name) to flat DTOs (CustomerName) and vice versa by naming convention; this is a key differentiator from manual mapping and enables clean DTO design.
• LINQ-to-SQL Expression Translation (IQueryable Projection) — AutoMapper can translate mapping rules into LINQ expressions that execute on the database (not in memory), avoiding N+1 queries and data transfer overhead—critical for ORMs like Entity Framework.
• Value Resolvers and Custom Type Converters — AutoMapper provides pluggable interfaces (IValueResolver, ITypeConverter, ICondition) for custom logic when convention-based mapping is insufficient; understanding these enables extending AutoMapper without modifying core mappings.
• Dependency Injection Integration — AutoMapper integrates with .NET's IServiceCollection (AddAutoMapper) and automatically registers resolver/converter implementations from specified assemblies; this is essential for enterprise ASP.NET Core applications.
• Reverse Mapping (Unflattening) — AutoMapper can automatically generate reverse mappings (DTO back to domain model) from forward mappings, with support for unflattening (flat properties back to nested objects); critical for two-way synchronization in CRUD scenarios.

• AutoMapper/AutoMapper.Collection — Official extension enabling mapping of nested collections and IEnumerable relationships; directly extends AutoMapper core for complex object graphs.
• AutoMapper/AutoMapper.Extensions.ExpressionMapping — Companion library for mapping expressions and LINQ queries directly (complementary to Queryable-Extensions); required for advanced projection scenarios.
• AutoMapper/AutoMapper.Data — Official extension for mapping from IDataReader and database records to objects; essential for legacy ADO.NET and Dapper integration.
• MapsterMapper/Mapster — Leading alternative to AutoMapper in .NET ecosystem; faster via IL generation and more minimal API, but less feature-rich—often compared in migration discussions.
• TinyMapper/TinyMapper — Lightweight object mapping library emphasizing simplicity and performance over convention-based flexibility; niche alternative for low-overhead scenarios.

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 upgrade guide for version 13.0+ breaking changes

The docs/source folder contains upgrade guides for versions 5.0 through 15.0, but the 13.0-Upgrade-Guide.md and 15.0-Upgrade-Guide.md appear incomplete based on the pattern of other guides. Given AutoMapper's frequency of breaking changes and the importance of migration paths, a detailed guide covering the gap between 13.0 and 15.0 (including 14.0 if it exists) would be high-value for users upgrading to the latest versions.

• [ ] Review git history between v13.0 and v15.0 tags to identify breaking changes
• [ ] Document API removals, deprecated methods, and behavioral changes in docs/source/14.0-Upgrade-Guide.md (if v14 exists)
• [ ] Expand docs/source/15.0-Upgrade-Guide.md with migration examples matching the structure of 13.0-Upgrade-Guide.md
• [ ] Add cross-references from docs/source/API-Changes.md to the new upgrade guides
• [ ] Verify the guides render correctly by building docs locally with the Sphinx configuration

Add integration tests for dependency injection with ServiceLifetime scoping scenarios

The src/AutoMapper.DI.Tests/Integrations/ServiceLifetimeTests.cs file exists but appears minimal. Given that dependency injection is a core feature (as evidenced by Dependency-injection.md in docs), comprehensive tests covering Singleton, Scoped, and Transient lifetime scenarios with nested mapper resolution would prevent regressions and validate DI integration across supported containers.

• [ ] Expand ServiceLifetimeTests.cs with test cases for each DI container (Microsoft.Extensions.DependencyInjection, etc.)
• [ ] Add tests for nested mapper resolution with different service lifetimes
• [ ] Test IMapper and IConfigurationProvider scope isolation
• [ ] Add tests for circular dependency detection in DI scenarios
• [ ] Ensure all test cases pass in the CI pipeline (reference .github/workflows/ci.yml)

Create tests for Dynamic and ExpandoObject mapping edge cases

docs/source/Dynamic-and-ExpandoObject-Mapping.md documents a feature, but src/AutoMapper.DI.Tests suggests limited coverage of these scenarios. AutoMapper's dynamic mapping is complex (handling runtime type information, null values, nested dynamics) and would benefit from a dedicated test suite covering edge cases like null ExpandoObjects, circular references, and mixed static/dynamic property mapping.

• [ ] Create src/AutoMapper.Tests/DynamicMappingTests.cs with tests for ExpandoObject scenarios
• [ ] Add tests for null ExpandoObject handling and missing property resolution
• [ ] Test nested ExpandoObject mapping (ExpandoObject containing ExpandoObject)
• [ ] Add tests for mixed scenarios (dynamic to POCO and POCO to dynamic)
• [ ] Validate behavior matches documentation in docs/source/Dynamic-and-ExpandoObject-Mapping.md

• Add unit tests for edge cases in custom type converter chaining (ITypeConverter implementations). The codebase shows extensive converter interfaces (IValueResolver, IMemberValueResolver, ITypeConverter, IValueConverter, ICondition, IPreCondition) but no visible test coverage list in the top 60 files—identify gaps and add test cases.
• Expand Queryable-Extensions.md documentation with real-world LINQ-to-SQL examples and performance gotchas. The docs/source/ folder shows the file exists but is likely skeletal; add concrete examples of projection compilation, N+1 prevention, and entity tracking behavior.
• Create a migration guide or validator tool for developers upgrading from AutoMapper 12.0 to 15.0. Multiple upgrade guides exist (12.0-Upgrade-Guide.md, 13.0-Upgrade-Guide.md, 15.0-Upgrade-Guide.md) but no unified tool to detect breaking changes in user code; this would be high-value for the community.

The AutoMapper repository demonstrates a reasonable security posture with established security policies and responsible disclosure procedures. The main concerns are outdated and pre-release documentation dependencies that should be updated to stable, current versions. The codebase structure shows no obvious injection vulnerabilities or exposed secrets in the file listing. However, dependency management could be strengthened through the use of lock files and more aggressive update schedules. The incomplete SECURITY.md file should be completed for clarity. Overall, the project follows security best practices but requires attention to dependency version management.

• Medium · Outdated Sphinx Documentation Dependency — docs/requirements.txt. The sphinx==7.1.2 dependency is pinned to a specific version that may contain known vulnerabilities. Sphinx 7.1.2 was released in September 2023 and may have security patches available in later versions. Regular dependency updates should be performed. Fix: Update to the latest stable version of Sphinx. Run 'pip list --outdated' to identify newer versions and update to sphinx>=7.2.0 or later after testing compatibility.
• Medium · Pre-release Theme Dependency — docs/requirements.txt. The sphinx-rtd-theme==1.3.0rc1 is pinned to a release candidate (rc1) version, which is not production-ready. Release candidates may contain bugs and incomplete features that could affect security or stability. Fix: Update to the latest stable release of sphinx-rtd-theme. Replace '1.3.0rc1' with a stable version number (e.g., '>=1.3.0' once released, or use the latest stable available).
• Low · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated at the disclosure process section. The complete security policy should include information about security update timelines, embargo periods, and acknowledgment procedures. Fix: Complete the SECURITY.md file with full disclosure timeline details, expected response times, and contributor acknowledgment policy.
• Low · Unsigned NuGet Package Potential — AutoMapper.snk. The presence of 'AutoMapper.snk' (strong name key file) in the repository root suggests code signing capability, but there's no visible documentation on package signing practices or verification in the provided files. Fix: Document the code signing and package signing practices in security documentation. Ensure all released NuGet packages are signed and verify signatures during distribution.
• Low · Missing Dependency Lock File — Repository root / docs. The docs/requirements.txt contains pinned versions, but there's no evidence of a lock file (like requirements.lock or poetry.lock) for the entire project, which could make reproducible builds difficult. Fix: Implement a dependency lock file mechanism using poetry, pip-tools, or similar to ensure reproducible builds and security audit trails.

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.