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/anjoy8/Blog.Core 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 3w ago
• 7 active contributors
• Distributed ownership (top contributor 48% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

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

What it runs against: a local clone of anjoy8/Blog.Core — 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 anjoy8/Blog.Core | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | 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 ≤ 54 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 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 "Blog.Core.Api/Program.cs" \\
  && ok "Blog.Core.Api/Program.cs" \\
  || miss "missing critical file: Blog.Core.Api/Program.cs"
test -f "Blog.Core.Api/Controllers/BaseApiController.cs" \\
  && ok "Blog.Core.Api/Controllers/BaseApiController.cs" \\
  || miss "missing critical file: Blog.Core.Api/Controllers/BaseApiController.cs"
test -f "Blog.Core.Api/Filter/GlobalExceptionFilter.cs" \\
  && ok "Blog.Core.Api/Filter/GlobalExceptionFilter.cs" \\
  || miss "missing critical file: Blog.Core.Api/Filter/GlobalExceptionFilter.cs"
test -f "Blog.Core.Api/Filter/GlobalAuthorizeFilter.cs" \\
  && ok "Blog.Core.Api/Filter/GlobalAuthorizeFilter.cs" \\
  || miss "missing critical file: Blog.Core.Api/Filter/GlobalAuthorizeFilter.cs"
test -f "Blog.Core.Api/appsettings.json" \\
  && ok "Blog.Core.Api/appsettings.json" \\
  || miss "missing critical file: Blog.Core.Api/appsettings.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 54 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~24d)"
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/anjoy8/Blog.Core"
  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).

Blog.Core is an enterprise-grade ASP.NET Core 8.0 API backend scaffolding framework paired with Vue 2.x frontend, implementing RBAC (Role-Based Access Control) permission system. It provides production-ready database abstraction via SqlSugar ORM, multi-tenant support (database/schema/table strategies), and features like job scheduling (Quartz), real-time messaging (SignalR), and distributed caching. Monolithic ASP.NET Core project structure: Blog.Core.Api/ contains Controllers organized by domain (User, Role, Permission, Topic, Tenant, Systems, DbFirst), with a shared BaseApiController. Database layer abstractions use Blog.Core.Model (entities) and implicit repository pattern via SqlSugar. Multi-tenancy is implemented across three strategies (TenantByDb, TenantById, TenantByTable controllers). CI/CD automation and Docker support indicate cloud-native design.

C# backend developers building enterprise SaaS applications or internal admin portals who need a fully-featured, pre-configured permission system and data access layer rather than building RBAC, ORM setup, and tenant isolation from scratch. Also used by teams adopting ASP.NET Core 6.0+ who want opinionated architectural patterns.

Production-ready and actively maintained. The project claims ~100 real company users and includes Microsoft MVP involvement. GitHub Actions CI/CD pipeline is configured (dotnetcore.yml, CodeQL analysis), suggesting regular testing. README indicates concurrent load testing up to 5k–10k requests across deployed instances. However, the repo structure shows this is a monolithic template project rather than a mature library ecosystem.

Moderate risk: Heavy reliance on SqlSugar ORM (single chosen abstraction—no EF Core alternative visible), and a monolithic architecture means scaling requires architectural changes. The 'enterprise high version' feature split (mentioned in README but not in open code) suggests monetization boundaries that could lead to fragmentation. Single primary author (anjoy8) with community contributors means knowledge concentration. Chinese-first documentation may slow non-Mandarin contributor onboarding.

The README references ASP.NET Core 8.0 support (repo header) and .NET 6.0.1 minimum SDK. GitHub Workflows show active CI/CD. The presence of .template.config/Blog.Core.Webapi.Template.2.5.2.nupkg indicates this doubles as a dotnet new template for project scaffolding. High-version commercial features (data permissions, distributed user session management, position/department hierarchy) are under active development but closed-source.

git clone https://github.com/anjoy8/Blog.Core.git
cd Blog.Core
dotnet restore Blog.Core.Api/Blog.Core.Api.csproj
dotnet build Blog.Core.Api/Blog.Core.Api.csproj
dotnet run --project Blog.Core.Api/Blog.Core.Api.csproj

The project requires .NET 6.0+ SDK. Check Blog.Core.Api/.config/dotnet-tools.json for any tool dependencies.

Daily commands:

dotnet run --project Blog.Core.Api/Blog.Core.Api.csproj

Alternatively:

cd Blog.Core.Api && dotnet run

The Dockerfile and docker-compose (if present) can containerize the app. Default likely runs on http://localhost:5000 or https://localhost:5001.

• Blog.Core.Api/Program.cs — ASP.NET Core 8.0 application entry point; defines dependency injection, middleware pipeline, and service startup configuration that all other components depend on
• Blog.Core.Api/Controllers/BaseApiController.cs — Base controller class inherited by all API endpoints; establishes common routing, authorization, and response handling patterns across the entire API surface
• Blog.Core.Api/Filter/GlobalExceptionFilter.cs — Global exception handling middleware that catches and standardizes error responses across all controllers; critical for API reliability and consistency
• Blog.Core.Api/Filter/GlobalAuthorizeFilter.cs — Authentication and authorization filter applied globally; enforces security policies and token validation for protected endpoints
• Blog.Core.Api/appsettings.json — Core application configuration including database connections, logging, caching, and service endpoints; runtime behavior depends entirely on these settings
• Blog.Core.Api/Filter/AutofacPropertityModuleReg.cs — Autofac dependency injection container configuration; registers all services, repositories, and business logic dependencies used throughout the application
• Blog.Core.Api/Blog.Core.Api.csproj — Project file defining NuGet dependencies, SDK version (8.0), build targets, and package references that enable the framework functionality

Add a new API endpoint for a resource

1. Create a new controller class inheriting from BaseApiController in Blog.Core.Api/Controllers/ (Blog.Core.Api/Controllers/YourResourceController.cs)
2. Define controller-level route attribute (typically [Route("api/[controller]")] following existing patterns in BlogController.cs (Blog.Core.Api/Controllers/BaseApiController.cs)
3. Add action methods (GET, POST, PUT, DELETE) that call underlying business logic or repository layer (Blog.Core.Api/Controllers/UserController.cs)
4. Register service/repository dependencies in the Autofac module at AutofacPropertityModuleReg.cs (Blog.Core.Api/Filter/AutofacPropertityModuleReg.cs)
5. Apply [UseServiceDI] or [Authorize] attributes from Filter folder to control access and injection (Blog.Core.Api/Filter/UseServiceDIAttribute.cs)
6. Test endpoint by running Program.cs locally and consuming via HTTP client or Swagger UI

Add a new scheduled background job

1. Define a job class implementing Quartz.NET IJob interface (reference existing task pattern if available) (Blog.Core.Api/Controllers/TasksQzController.cs)
2. Register the job in Program.cs or startup configuration under services.AddQuartz() (Blog.Core.Api/Program.cs)
3. Create a trigger with cron expression (e.g., 'run daily at 2 AM') and bind to the job class (Blog.Core.Api/appsettings.json)
4. Optionally expose task management endpoints via TasksQzController to pause/resume jobs at runtime

Add a new multi-tenant strategy

1. Create controller in Blog.Core.Api/Controllers/Tenant/ following naming pattern (e.g., TenantByXController.cs) (Blog.Core.Api/Controllers/Tenant/TenantByDbController.cs)
2. Implement tenant resolution logic (query param, header, subdomain, or database row) to identify current tenant (Blog.Core.Api/Controllers/Tenant/TenantByIdController.cs)
3. Override DbContext or SqlSugar connection string selection to route queries to tenant-specific database/schema (Blog.Core.Api/Controllers/Tenant/TenantManagerController.cs)
4. Register new strategy in Program.cs dependency injection and test with multi-tenant aware endpoints

Configure caching for an endpoint

1. Add Redis connection string to appsettings.json under caching configuration section (Blog.Core.Api/appsettings.json)
2. Inject IDistributedCache or custom cache service into your controller constructor (Blog.Core.Api/Controllers/BlogController.cs)
3. Check cache on GET requests (cache.GetString(key)) before querying database (Blog.Core.Api/Controllers/Systems/CacheManageController.cs)
4. Invalidate cache on POST/PUT/DELETE by calling cache.RemoveAsync(key) to ensure freshness (Blog.Core.Api/Filter/GlobalExceptionFilter.cs)
5. Monitor and manage cached entries via CacheManageController endpoints

Database connectivity required at startup: SqlSugar ORM is eager-initialized; app will fail to start without a configured database connection string (likely in appsettings.json, check for .config/dotnet-tools.json hints). DbFirstController schema sync: Running migrations via DbFirstController can overwrite local schema changes—only safe in controlled environments. Redis dependency for high-version features: The README mentions distributed user session management and black-listing require Redis; open-source version may have degraded features without it. SignalR hub configuration: See SignalRTestController.cs—SignalR endpoints must be registered in Startup.cs or Program.cs or real-time features silently fail. Template package versioning: .template.config/ suggests this repo doubles as a dotnet new template (v2.5.2)—installing the NuGet template may pull a different, potentially stale version than the git source.

• Role-Based Access Control (RBAC) — Blog.Core's core value proposition—the permission system is modeled entirely around RBAC (roles, users, permissions, modules). Understanding RBAC matrices and how they map to API endpoints is essential.
• Repository Pattern — Blog.Core abstracts SqlSugar ORM behind repositories (visible in the service layer structure); knowing how to add, query, and update entities through this layer is required for any new feature.
• Multi-Tenancy (Database, Schema, Row-level) — Blog.Core implements three distinct multi-tenancy strategies (TenantByDb, TenantById, TenantByTable); understanding which strategy fits your use case and how routing/filtering changes is critical for SaaS deployments.
• ORM (Object-Relational Mapping) / SqlSugar — SqlSugar is the chosen data access layer throughout Blog.Core; you'll need to understand DbContext, query builders, and async operations to extend the data model.
• JWT (JSON Web Tokens) Authentication — Blog.Core uses JWT for stateless API authentication (see LoginController); understanding token generation, claims, expiration, and validation is essential for modifying auth logic.
• SignalR (Real-time Bidirectional Communication) — Blog.Core includes SignalRTestController for real-time features; SignalR hubs enable push notifications and live updates needed for modern admin dashboards.
• Quartz.NET Job Scheduling — TasksQzController shows scheduled background job execution; understanding cron expressions and distributed scheduling is needed for async operations (reports, cleanups, notifications).

• aspnet/AspNetCore — Official ASP.NET Core framework and reference implementation; Blog.Core is built directly on top of this
• dotnetcore/FreeSql — Alternative ORM in .NET ecosystem (FreeSql vs SqlSugar); Blog.Core chose SqlSugar but FreeSql is a competing abstraction
• IdentityServer/IdentityServer4 — Enterprise-grade OAuth2/OpenID Connect server for .NET; Blog.Core implements custom JWT auth, but IdentityServer is the production standard alternative
• quartz-scheduler/quartz.net — The job scheduling library used in Blog.Core (TasksQzController); official .NET port of Quartz Java scheduler
• alibaba/nacos — Service discovery and config management referenced in NacosController; Blog.Core integrates with Nacos for distributed deployment

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 GlobalExceptionFilter and GlobalAuthorizeFilter

The repo has critical filter classes (Blog.Core.Api/Filter/GlobalExceptionFilter.cs and GlobalAuthorizeFilter.cs) that handle exception handling and authorization across the entire API, but no visible test files for these filters. These filters are fundamental to API stability and security, making them high-value targets for test coverage. This would improve code reliability and provide examples for testing ASP.NET Core filters.

• [ ] Create Blog.Core.Tests/Filter/GlobalExceptionFilterTests.cs with tests for exception handling scenarios (null exceptions, different exception types, response formatting)
• [ ] Create Blog.Core.Tests/Filter/GlobalAuthorizeFilterTests.cs with tests for authorization bypass cases, token validation, and permission checking
• [ ] Add integration tests in Blog.Core.Tests/Integration/FilterIntegrationTests.cs to verify filter execution order and end-to-end behavior
• [ ] Update the test CI workflow (.github/workflows/dotnetcore.yml) to include these new test projects in the build pipeline

Create unit tests for multi-tenancy implementation (TenantByDb, TenantById, TenantByTable controllers)

The repo has three different tenancy strategies (Blog.Core.Api/Controllers/Tenant/) with distinct implementation patterns, but no visible corresponding test suite. Given the complexity of multi-tenant systems and their critical role in data isolation, these controllers need dedicated test coverage to prevent tenant data leakage bugs and ensure isolation correctness.

• [ ] Create Blog.Core.Tests/Tenancy/TenantByDbTests.cs with tests for database selection logic, tenant switching, and isolation verification
• [ ] Create Blog.Core.Tests/Tenancy/TenantByIdTests.cs with tests for ID-based filtering, query interception, and data scope validation
• [ ] Create Blog.Core.Tests/Tenancy/TenantByTableTests.cs with tests for table-based separation and cross-tenant query prevention
• [ ] Add integration tests for tenant context propagation across service layers (Blog.Core.Tests/Tenancy/TenantContextIntegrationTests.cs)

Add Docker Compose configuration and documentation for local development environment

The repo has a Dockerfile for Blog.Core.Api but no docker-compose.yml file visible in the structure. Given the project's complexity with dependencies (databases, caching, SignalR, Nacos service discovery based on controllers), contributors need a documented, reproducible local environment. This would lower onboarding friction and enable consistent development setup.

• [ ] Create docker-compose.yml in the repo root with services for: API container, SQL Server/MySQL (based on .config), Redis (for cache), and any required infrastructure services
• [ ] Create .docs/DOCKER_SETUP.md with step-by-step instructions for running the complete stack locally using docker-compose up
• [ ] Update .dockerignore to optimize image builds and add it to the root .gitignore if missing
• [ ] Document environment variable configuration needed for local development (database connection strings, cache settings, etc.) in .docs/ENV_SETUP.md

• Add integration tests for Blog.Core.Api/Controllers/UserController.cs CRUD operations. Currently no *.Tests project visible; create Blog.Core.Tests/UserControllerTests.cs with xUnit fixtures mocking the SqlSugar repository layer.: Improves test coverage and helps newcomers learn the mocking patterns for this codebase
• Document the permission attribute system by adding inline XML comments to BaseApiController.cs and creating a /docs/Permission-System.md explaining how [Authorize] and custom permission attributes work. Include examples for each permission check strategy.: README lacks deep permission framework documentation; new contributors need clear reference material
• Add a new controller Blog.Core.Api/Controllers/AuditLogController.cs to expose audit trails (who accessed what, when, with what result) using the existing database schema. Include filtering by user, date range, and action type.: Enterprise deployments require audit logging; this is a common feature gap and good exercise in RBAC enforcement
• Create a quickstart.sh script in the repo root that auto-generates appsettings.json with sensible defaults (localhost DB, test credentials, Redis connection string) and runs migrations. Test it in CI.: Reduces onboarding friction for new contributors unfamiliar with .NET Core configuration

• High · Potential Hardcoded Credentials in Configuration Files — Blog.Core.Api/appsettings.*.json files. Multiple appsettings files detected (appsettings.json, appsettings.Development.json, appsettings.apollo.json) that may contain database connection strings, API keys, or other sensitive credentials. These files are typically committed to version control, exposing secrets. Fix: Use Azure Key Vault, environment variables, or user secrets (.NET User Secrets Manager) for sensitive configuration. Never commit secrets to version control. Implement secret scanning in CI/CD pipeline.
• High · SQL Injection Risk in Database Operations — Blog.Core.Api/Controllers/DbFirst/, Blog.Core.Api/Controllers/Test/SqlsugarTestController.cs, Blog.Core.Api/Controllers/SqlSugarTestController.cs. The codebase includes SqlSugar ORM usage (SqlSugarTestController.cs, SqlsugarTestController.cs) and DbFirst operations (DbFirstController.cs). If raw SQL queries are constructed with user input without parameterization, SQL injection is possible. Fix: Ensure all database queries use parameterized queries/prepared statements. Audit SqlSugar usage to confirm parameterized query patterns. Never concatenate user input into SQL strings.
• High · Insufficient Authorization Checks — Blog.Core.Api/Filter/GlobalAuthorizeFilter.cs, Blog.Core.Api/Controllers/. A GlobalAuthorizeFilter exists but its implementation is not visible. Controllers for sensitive operations (UserController, RoleController, PermissionController, PayController) may lack proper role-based access control (RBAC) validation. Fix: Implement comprehensive RBAC checks using [Authorize] attributes with role specifications. Validate permissions on every endpoint. Audit sensitive controllers for authorization logic.
• High · Exposed Sensitive Administrative Endpoints — Blog.Core.Api/Controllers/DbFirst/DbFirstController.cs, Blog.Core.Api/Controllers/DbFirst/MigrateController.cs, Blog.Core.Api/Controllers/Systems/DynamicCodeFirstController.cs, Blog.Core.Api/Controllers/Systems/CacheManageController.cs, Blog.Core.Api/Controllers/Systems/DataBaseController.cs. Multiple administrative endpoints are exposed without apparent access restrictions: DbFirstController, MigrateController, DynamicCodeFirstController, CacheManageController, DataBaseController. These allow database schema modification and system manipulation. Fix: Restrict these endpoints to authenticated administrators only using [Authorize(Roles = "Admin")] attributes. Implement additional IP whitelisting or move to internal-only networks. Disable in production if not needed.
• Medium · Potential XSS Vulnerabilities in API Response Handling — Blog.Core.Api/Controllers/ImgController.cs, Blog.Core.Api/Controllers/WeChatController.cs. Controllers like ImgController, WeChatController suggest user-generated content or file handling. Without proper output encoding when returning user data, XSS attacks are possible. Fix: Implement proper output encoding for all user-supplied data in API responses. Use model binding with [FromBody] for JSON. Validate and sanitize file uploads. Implement Content Security Policy headers.
• Medium · Missing CORS Configuration Validation — Blog.Core.Api/Program.cs. No visible CORS configuration in the file structure. This could allow unauthorized cross-origin requests or be overly permissive (AllowAnyOrigin). Fix: Configure CORS explicitly with specific allowed origins, methods, and headers. Avoid using AllowAnyOrigin in production. Implement proper preflight request handling.
• Medium · Insecure Direct Object References (IDOR) Risk — Blog.Core.Api/Controllers/UserController.cs, Blog.Core.Api/Controllers/BlogController.cs, Blog.Core.Api/Controllers/TopicController.cs. Multiple controllers with ID-based operations (UserController, TopicController, BlogController, etc.) may be vulnerable to IDOR if authorization doesn't validate user ownership of resources. Fix: Implement proper authorization checks to verify users can only access their own resources. Validate resource ownership in addition to authentication. Use UUIDs instead of sequential IDs where possible.
• Medium · undefined — undefined. undefined Fix: undefined

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.