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/MapsterMapper/Mapster 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 the board

• Last commit 3d ago
• 11 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 59% 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 MapsterMapper/Mapster repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/MapsterMapper/Mapster.

What it runs against: a local clone of MapsterMapper/Mapster — 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 MapsterMapper/Mapster | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

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

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

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

Mapster is a code-generation-based object-to-object mapper for .NET that automatically generates optimized mapping code at compile-time or runtime. It eliminates boilerplate mapping methods by using expressions and IL generation to create fast, type-safe transformations between domain objects, DTOs, and entities. Modular NuGet package architecture: core mapping engine in Mapster.Core, integration packages for EFCore/EF6 (Mapster.EFCore, Mapster.EF6), DI support (Mapster.DependencyInjection), serialization (Mapster.JsonNet), and immutable types (Mapster.Immutable). Documentation lives in docs/articles/{configuration,mapping,packages,settings} with compiled API docs in docs/api/.

.NET developers building layered applications (ASP.NET Core, Entity Framework, microservices) who need to map between domain models, view models, and DTOs without writing repetitive hand-coded mapping methods or maintaining heavy configuration-based mappers.

Actively maintained and production-ready. The repo shows 1M+ lines of C# code, multiple NuGet packages (Mapster, Mapster.Core, Mapster.DependencyInjection, Mapster.EFCore, Mapster.EF6, Mapster.JsonNet, Mapster.Immutable, Mapster.Diagnostics), automated CI/CD via GitHub Actions (build-deploy-docs.yml, dotnet-buildandtest.yml, conventional-commits.yml), and comprehensive documentation in docs/articles/ covering configuration, mapping strategies, and integrations.

Low risk for production use, but monolithic package structure (no visible source separation in file list) and single-organization maintenance could create bottlenecks. No visible breaking-change log or deprecation strategy documented in the provided file structure. Dependency on FastExpressionCompiler and EF variants means compatibility risks with major .NET version upgrades.

Active maintenance with conventional commits workflow (conventional-commits.yml), API documentation generation pipeline (build-deploy-docs.yml), and multi-framework .NET testing (dotnet-buildandtest.yml). SpellCheck (cSpell.json) and MarkdownLint (.markdownlint.jsonc) suggest documentation-focused releases.

Clone: git clone https://github.com/MapsterMapper/Mapster.git. Install .NET SDK (version in global.json if present). Build: dotnet build. Tests: dotnet test. Documentation: ./docs/Clean-and-Build-Docs.ps1 (PowerShell on Windows) or review existing docs in docs/articles/.

Daily commands: No traditional 'dev server'—this is a library. Build with dotnet build. Run unit tests with dotnet test. Publish packages with dotnet pack. Generate docs with ./docs/Build-Docs.ps1 (Windows) or equivalent PowerShell.

• docs/articles/configuration/Configuration.md: Master guide to configuring Mapster's behavior; essential reading for any user customizing mappings
• .github/workflows/dotnet-buildandtest.yml: Defines the CI pipeline; shows required build steps, test frameworks, and target .NET versions
• docs/articles/mapping/Basic-usages.md: Entry point to understand how Mapster works in practice; shows the public API patterns
• CONTRIBUTING.md: Contributor guidelines; mandatory reading before submitting PRs
• .github/workflows/conventional-commits.yml: Enforces commit message format; understand this to avoid CI failures on PRs
• docs/articles/packages/Dependency-Injection.md: Shows how to integrate Mapster into ASP.NET Core DI containers; common real-world scenario

Core mapping logic: likely in src/ (not visible in provided list, but standard for NuGet packages). Configuration examples in docs/articles/configuration/{Config-instance.md, Config-location.md, Config-inheritance.md}. Integration code in separate package directories (EFCore, DependencyInjection). Add new feature: update relevant package, add tests, document in docs/articles/, follow conventional commits (per .github/workflows/conventional-commits.yml).

.NET SDK version (check global.json if present—not shown in file list). PowerShell requirement for docs building on Windows (Build-Docs.ps1). FastExpressionCompiler dependency; version mismatches can break IL generation. EF6 vs. EF Core packages are separate; must choose the right one for your project. No visible environment variable configuration in provided files—check docs/articles/configuration/ for runtime settings.

• Expression Trees (System.Linq.Expressions) — Mapster's core mechanism; instead of reflection at runtime, it builds compiled expression trees that become fast IL, avoiding per-map reflection overhead
• IL Emission & FastExpressionCompiler — Mapster delegates to FastExpressionCompiler to convert expressions into native IL, bypassing the default expression compiler for higher throughput
• Convention-over-Configuration Mapping — Mapster auto-matches properties by name and type; understanding when it works and when custom rules are needed (Config-instance.md) is critical
• Nested Mapping & Type Adaptation — Mapster recursively maps nested objects (collections, complex types); Config-for-nested-mapping.md covers strategies to avoid infinite recursion and performance traps
• Lazy Code Generation — Mapster generates mappers on-demand (runtime) or ahead-of-time; understanding the trade-off between startup time and warm-up latency is key for performance tuning
• Object Reference Tracking & Circular Dependency Handling — When mapping graphs with cycles (parent → children → parent), Mapster's reference tracking prevents infinite loops; documented in docs/articles/settings/Object-references.md
• Entity Framework Integration (Projection vs. Materialization) — Mapster.EFCore/Mapster.EF6 convert map configs into LINQ expressions for database projection; avoiding N+1 queries requires understanding when to project vs. materialize

• AutoMapper/AutoMapper — Direct competitor; reflection-based mapping with convention-driven configuration; compare for mature alternative approach
• agileobjects/AgileMapper — Alternative expression-tree mapper for .NET; shares design philosophy with Mapster but different IL generation strategy
• ExpressMapper/ExpressMapper — Lightweight expression-based mapper; inspiration or predecessor for optimization patterns Mapster uses
• jbogard/MassTransit — Common companion library; MassTransit users often integrate Mapster for message DTO transformations
• dotnet/efcore — Ecosystem dependency; Mapster.EFCore and Mapster.EF6 packages exist specifically to bridge EF object tracking with mapping

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 integration tests for EF Core mapping scenarios

The repo has documentation for EF-6-and-EF-Core.md but there's no evidence of dedicated integration test suite for Entity Framework scenarios. New contributors could add tests covering lazy loading, change tracking, and shadow property mappings—critical real-world use cases that deserve explicit test coverage alongside the existing unit tests.

• [ ] Create docs/articles/packages/EF-Core-Integration-Tests.md documenting test patterns
• [ ] Add test project targeting EF Core DbContext mapping scenarios
• [ ] Test lazy-loaded navigation properties with Mapster
• [ ] Test mapping of shadow properties and computed columns
• [ ] Add tests for change tracking preservation during mapping

Document and add tests for the TextTemplate code generation tool

docs/articles/tools/TextTemplate.md exists but appears minimal. The mapster-tool subdirectory shows attribute and configuration-based code generation, but TextTemplate integration lacks concrete examples and test coverage. Contributors could bridge this gap with executable examples.

• [ ] Expand docs/articles/tools/TextTemplate.md with step-by-step examples
• [ ] Create sample T4 template files in docs/articles/tools/examples/
• [ ] Add integration tests verifying generated code from TextTemplate matches expected output
• [ ] Document the differences between TextTemplate, attribute-based, and configuration-based generation
• [ ] Add troubleshooting section for common TextTemplate+Mapster issues

Add diagnostic/validation test suite for Configuration-based-Code-generation

docs/articles/tools/mapster-tool/Configuration-based-Code-generation.md exists, but there's no visible test suite validating that invalid configurations produce helpful error messages. Contributors could add tests ensuring developers get clear feedback when configuration is malformed or conflicting.

• [ ] Create test file for configuration validation scenarios
• [ ] Test duplicate mapping configuration detection with clear error messages
• [ ] Test invalid naming convention configurations
• [ ] Test conflicting ignore/include rules
• [ ] Add tests for unsupported type combinations with actionable error guidance
• [ ] Document validation rules in docs/articles/configuration/Config-validation-and-compilation.md

• Add C# doc comments to public API surface in core mapping classes (mentioned in .github/prompts/csharp-docs.prompt.md suggesting tooling exists for this). Improves IntelliSense and API docs.
• Expand docs/articles/mapping/Data-types.md with concrete examples for nested collection mapping (List<T>, IEnumerable<T>, arrays); tests in dotnet-buildandtest.yml likely cover this but docs lag.
• Add example in docs/articles/packages/ for common scenario: ASP.NET Core 8+ with latest EF Core + Mapster + minimal APIs; currently no example covers all three together.

The Mapster codebase demonstrates a generally secure posture. No critical vulnerabilities were identified in the visible file structure and configuration. The primary concerns are minor operational security practices: managing development signing keys properly, implementing security headers for documentation, and following GitHub Actions security best practices. The project appears to be well-maintained with standard .gitignore, proper license documentation, and organized structure. Dependencies analysis could not be performed as the package file content was not provided, which would be the next area for security review.

• Low · Unsigned Assembly in Benchmark Project — src/Benchmark.Development/Benchmark.Development.snk. The Benchmark.Development project contains a .snk (strong name key) file (Benchmark.Development.snk), which suggests assemblies may be signed with a development key. If this private key is committed to the repository, it could be used to create fraudulent assemblies. Fix: Ensure private key files (.snk) are never committed to version control. Add *.snk to .gitignore and use secure key management practices for production signing.
• Low · Missing Security Headers Configuration — docs/docfx.json. The documentation build configuration (docs/docfx.json) does not show explicit security headers or content security policy settings for the generated documentation site. Fix: Configure security headers (X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security) in the web server or hosting configuration for the documentation site.
• Low · GitHub Actions Workflow Security Review — .github/workflows/. Multiple GitHub Actions workflows are present (.github/workflows/). While the file contents are not fully visible, workflows should be reviewed to ensure they follow security best practices such as using pinned action versions and avoiding secrets in logs. Fix: Review all workflow files to: 1) Use pinned action versions (with commit SHAs), 2) Implement proper secrets management, 3) Restrict workflow permissions with 'permissions' directive, 4) Avoid logging sensitive data.

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.