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/NancyFx/Nancy 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

• 26+ active contributors
• Distributed ownership (top contributor 49% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 5y ago

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

What it runs against: a local clone of NancyFx/Nancy — 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 NancyFx/Nancy | 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 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1961 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "NancyFx/Nancy(\\.git)?\\b" \\
  && ok "origin remote is NancyFx/Nancy" \\
  || miss "origin remote is not NancyFx/Nancy (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"

# 4. Critical files exist
test -f "Nancy.sln" \\
  && ok "Nancy.sln" \\
  || miss "missing critical file: Nancy.sln"
test -f "build.cake" \\
  && ok "build.cake" \\
  || miss "missing critical file: build.cake"
test -f "SharedAssemblyInfo.cs" \\
  && ok "SharedAssemblyInfo.cs" \\
  || miss "missing critical file: SharedAssemblyInfo.cs"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"
test -f "Nancy.ruleset" \\
  && ok "Nancy.ruleset" \\
  || miss "missing critical file: Nancy.ruleset"

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

Nancy is a lightweight, low-ceremony HTTP web framework for .NET Framework, .NET Core, and Mono that provides a minimal DSL for building REST services with minimal boilerplate. It handles HTTP verbs (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS) and lets developers define routes inline within NancyModule classes, emphasizing developer happiness over configuration complexity. Single monorepo structure: core Nancy framework lives in src/ (inferred from .sln), samples/ contains 5+ demo applications (authentication, async, forms) showing real usage patterns, build configuration via Cake (build.cake), and NuGet package management via NuGet.config. Tests likely colocated with source files (.csproj convention).

.NET developers building RESTful microservices and HTTP APIs who want rapid development without the ceremony of ASP.NET MVC/Core—particularly those working in constrained environments (Mono) or preferring convention-over-configuration frameworks similar to Ruby's Sinatra or Node's Express.

Nancy is no longer maintained as of the README announcement—the project was active and production-ready (150+ contributors, extensive samples in /samples/) but is now in archive/legacy status. The presence of AppVeyor/Travis CI configuration, comprehensive test coverage patterns, and stable Cake build scripts (build.cake, build.ps1, build.sh) indicate it was well-engineered, but no active development is occurring.

Critical risk: Nancy is unmaintained. The README explicitly states 'Nancy is no longer being maintained,' meaning no security patches, bug fixes, or .NET version updates will be applied. While the license is permissive for forking, the core team recommends commercial support (nancyfx.help@gmail.com) for production systems. Use only for legacy codebases; do not start new projects on this framework.

No active development—the README announcement supersedes any commit history. The last visible activity is the maintenance notice itself. No PRs, milestones, or ongoing work is being tracked. The community is directed to commercial support contacts or encouraged to fork for continued maintenance.

git clone https://github.com/NancyFx/Nancy.git
cd Nancy
# Windows
.\build.ps1
# Linux/Mac
./build.sh

Alternatively, use dotnet build Nancy.sln if targeting .NET Core. See how_to_build.txt for detailed steps.

Daily commands: After cloning:

# Build all projects
.\build.ps1 -Target Build  # Windows
./build.sh -t Build        # Linux/Mac

# Run a sample
cd samples/Nancy.Demo.Authentication.Forms
dotnet run  # or msbuild then execute .exe

See individual sample .csproj files for entry points (Program.cs in each demo).

• Nancy.sln — Primary solution file defining the entire project structure and all dependencies for building the Nancy framework
• build.cake — Build automation script (Cake) that orchestrates compilation, testing, and packaging—essential for understanding the development workflow
• SharedAssemblyInfo.cs — Shared assembly metadata and versioning configuration applied across all Nancy assemblies
• .github/CONTRIBUTING.md — Contribution guidelines that define coding standards, commit conventions, and PR expectations for all contributors
• Nancy.ruleset — Code analysis and style enforcement rules (FxCop, StyleCop) that maintain consistency across the codebase
• README.md — Project overview, status (unmaintained), and high-level architecture overview for onboarding new contributors
• .travis.yml — CI/CD pipeline configuration for Travis CI that validates every commit and pull request

Add a new HTTP module with routes

1. Create a new C# file under samples/ directory following the naming convention: Nancy.Demo.[Feature] (samples/Nancy.Demo.Authentication.Basic/MainModule.cs)
2. Define a class inheriting from NancyModule and declare HTTP routes in the constructor (samples/Nancy.Demo.Authentication.Basic/MainModule.cs)
3. Register the module in the bootstrapper's ConfigureApplicationContainer or RequestStartup method if custom behavior is needed (samples/Nancy.Demo.Authentication.Basic/AuthenticationBootstrapper.cs)
4. Reference the new project in Nancy.sln and ensure it compiles via build.cake targets (Nancy.sln)

Implement a new authentication scheme

1. Create a new bootstrapper by extending DefaultNancyBootstrapper and override RequestStartup to register security pipelines (samples/Nancy.Demo.Authentication.Forms/FormsAuthBootstrapper.cs)
2. Define secure modules using [RequiresAuthentication] or equivalent custom attributes/pipelines (samples/Nancy.Demo.Authentication.Forms/SecureModule.cs)
3. Implement a user validator or token handler to authenticate requests (Forms: UserValidator.cs, Stateless: token parsing) (samples/Nancy.Demo.Authentication.Basic/UserValidator.cs)
4. Add test coverage using Nancy testing abstractions (reference Nancy.Demo.Authentication.Forms.TestingDemo) (samples/Nancy.Demo.Authentication.Forms.TestingDemo/LoginFixture.cs)

Add a caching layer to responses

1. Reference the Nancy.Demo.Caching project pattern and define a CachedResponse model or decorator (samples/Nancy.Demo.Caching/CachedResponse.cs)
2. Modify route handlers to check cache (e.g., in-memory, Redis, or HTTP cache headers) before processing (samples/Nancy.Demo.Caching/CachedResponse.cs)
3. Configure cache invalidation policies in the bootstrapper's ConfigureApplicationContainer or via middleware (samples/Nancy.Demo.Bootstrapper.Aspnet/Bootstrapper.cs)
4. Run build.cake to test and validate caching behavior end-to-end (build.cake)

• .NET Framework / Mono — Nancy is a CLR-based web framework enabling cross-platform HTTP service development on Windows, Linux, and macOS via Mono
• Cake Build Automation — Provides a C# DSL for build scripting, enabling consistent builds across Windows (PowerShell), Linux/macOS (Bash), and CI/CD systems
• Bootstrapper Pattern (IoC Container) — Allows developers to customize dependency injection, authentication, view engines, and request pipelines without modifying core framework code
• Module-based Routing — Organizes HTTP routes into cohesive NancyModule classes, improving discoverability and separation of concerns for complex applications
• Fluent Configuration API — Enables low-ceremony setup of routes, security, and response handling through method chaining and lambda expressions

• Low-ceremony framework vs. built-in ORM/database support

  • Why: Nancy prioritizes simplicity and composability, leaving data access to developer choice (Entity Framework, Dapper, etc.)
  • Consequence: Flexibility to use any database library, but requires manual integration and no out-of-box persistence patterns

• Per-request module instantiation vs. singleton modules

  • Why: Nancy instantiates modules per request to ensure thread safety and isolation
  • Consequence: Slightly higher memory/CPU overhead per request, but eliminates shared state bugs and simplifies concurrent request handling

• Convention-based view discovery vs. explicit registration

  • Why: Nancy discovers views from disk based on naming conventions (e.g., /Views/[ModuleName]/[RouteName].cshtml)
  • Consequence: Reduces boilerplate configuration but requires developers to follow strict directory/naming structure

• Stateless HTTP focus with optional session support

  • Why: Aligns with RESTful principles while allowing forms-based and token authentication for legacy/UI scenarios
  • Consequence: Encourages stateless API design but adds complexity if session state is required (bootstrapper customization needed)

• Does not provide built-in ORM or database access layer (intentionally delegated to user choice)
• Does not include real-time features like WebSockets or SignalR (use separate libraries)
• Does not mandate a specific front-end framework or view engine (supports Razor, SuperSimpleViewEngine, etc., or none for APIs)
• Does not enforce or provide testing frameworks (testing is framework-agnostic; samples show xUnit/NUnit patterns)
• Project is no longer actively maintained as of the README announcement—support is community-driven only

1. Project is unmaintained: No support or updates—building locally works, but runtime issues on modern .NET versions are unsupported. 2. Mono/legacy platform focus: Samples target older .NET Framework; .NET Core support varies per version. 3. Bootstrapper is mandatory: DI/auth configuration requires custom Bootstrapper subclass (see FormsAuthBootstrapper.cs pattern)—forgetting this is a common gotcha. 4. View engine selection: Default view engine must be configured in Bootstrapper; mismatched view file extensions (.cshtml vs .spark) will cause silent 404s. 5. No .env or secrets management: Configuration is hardcoded in Web.config or bootstrapper—see Web.Debug.config vs Web.Release.config pattern for environment separation.

• Module-based Routing (NancyModule pattern) — Nancy organizes routes as methods within NancyModule subclasses (e.g., Get/Post/Put)—understanding this class-per-feature convention is essential to writing Nancy handlers and organizing large applications
• Bootstrapper & Dependency Injection — Nancy requires a custom Bootstrapper subclass to configure the DI container, authentication pipeline, and module registration—this is the extension point for auth, logging, and middleware setup unique to Nancy's architecture
• View Engine Abstraction — Nancy abstracts view rendering (Razor, Spark, etc.) via IViewEngine; selecting and configuring the right engine in Bootstrapper affects how .cshtml/.spark files are compiled and cached
• Request/Response Pipeline & Hooks — Nancy provides Before/After request hooks and error handlers in Bootstrapper for cross-cutting concerns like logging, CORS, and custom error responses—essential for middleware-like functionality
• DSL for HTTP Responses — Nancy's core feature is inline response definitions (Get("/path", x => "Hello")) returning strings, objects, or View results—understanding implicit serialization (JSON, XML) vs explicit View rendering is critical
• Content Negotiation — Nancy automatically selects response format (JSON, XML, HTML) based on Accept headers and available serializers—misconfigured negotiation causes content-type mismatches in client calls
• Forms-Based Authentication Pipeline — The samples/Nancy.Demo.Authentication.Forms example shows a complete authentication flow (login form → credential validation → cookie-based session)—understanding this pattern is necessary for adding auth to Nancy apps

• aspnet/AspNetCore — Direct successor in the Microsoft ecosystem—ASP.NET Core provides modern, maintained HTTP framework for .NET with similar routing patterns
• ServiceStack/ServiceStack — Alternative .NET REST framework with similar low-ceremony philosophy; actively maintained and production-ready for new projects
• restsharp/RestSharp — Companion HTTP client library commonly used by Nancy API consumers for integration testing and external API calls
• NancyFx/Nancy.Authentication.Forms — Official Nancy authentication plugin repo (if separate); extends Nancy with pluggable authentication strategies
• Sinatra/sinatra — Spiritual predecessor (Ruby framework) that inspired Nancy's DSL-first, low-ceremony design philosophy

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 CI/CD migration guide from Travis CI to GitHub Actions

The repo currently uses .travis.yml and appveyor.yml (legacy CI systems), but GitHub Actions is now the standard for GitHub-hosted projects. Since Nancy is no longer actively maintained, creating a migration guide would help community forks and maintainers quickly set up modern CI/CD. This would involve documenting the build process defined in build.cake, build.ps1, and build.sh within a new .github/workflows directory.

• [ ] Create .github/workflows/build.yml for multi-platform builds (.NET Framework, .NET Core/5+)
• [ ] Reference build.cake and build.ps1 execution steps from the workflow
• [ ] Document in .github/CONTRIBUTING.md how to run builds locally using build.sh and build.ps1
• [ ] Add status badge to README.md pointing to the new GitHub Actions workflow

Add missing unit tests for Authentication.Stateless sample implementation

The samples/Nancy.Demo.Authentication.Stateless directory contains AuthModule.cs, StatelessAuthBootstrapper.cs, and SecureModule.cs but no corresponding test project (unlike samples/Nancy.Demo.Authentication.Forms.TestingDemo which has LoginFixture.cs). Adding comprehensive tests would serve as both validation and documentation for stateless authentication patterns.

• [ ] Create samples/Nancy.Demo.Authentication.Stateless.Tests project
• [ ] Add test fixtures for StatelessAuthBootstrapper configuration and token validation
• [ ] Add integration tests for AuthModule endpoints (login, token generation)
• [ ] Add tests for SecureModule route protection with valid/invalid tokens
• [ ] Reference xUnit or NUnit patterns used in existing test projects

Create MAINTENANCE.md guide for community fork maintainers

Given the README explicitly states 'Nancy is no longer being maintained', new maintainers forking the project need clear guidance on maintenance responsibilities. This document should cover build system specifics (Cake build script, NuGet.config), release procedures, and architectural decision records already made by the core team.

• [ ] Document build prerequisites and how_to_build.txt enhancement with version requirements
• [ ] Explain the purpose of Nancy.ruleset and Nancy.sln.DotSettings for code quality
• [ ] Document the NancyFx/.mailmap usage and contributor attribution workflow
• [ ] Create guidance on updating dependencies and running the full test suite (referenced in build.cake)
• [ ] Add decision log template for future architectural changes to preserve intent

• Review and document the module routing syntax: The samples/Nancy.Demo.Async/MainModule.cs shows async/await patterns, but there is no dedicated 'Async Routes' guide in the repo—add a markdown document explaining async handler patterns with examples from that demo.
• Add unit test stubs for authentication validators: samples/Nancy.Demo.Authentication.Basic/UserValidator.cs likely lacks test coverage—create Nancy.Demo.Authentication.Basic.Tests/*.cs files with xUnit/NUnit test cases for custom credential validation.
• Document Bootstrapper customization: The FormsAuthBootstrapper.cs pattern is powerful but undocumented in code comments—add XML doc comments explaining DI container registration, pipeline hooks, and module registration flow for future maintainers.

The NancyFx codebase presents significant security concerns due to its unmaintained status. The framework is no longer receiving security updates, making it vulnerable to newly discovered threats and exploits. Critical issues include the lack of dependency analysis, potential hardcoded credentials in configuration files, and authentication implementation concerns in sample code. The project should be considered for migration to an actively maintained framework like ASP.NET Core. Immediate actions needed: conduct a comprehensive dependency audit, remove all hardcoded credentials, review authentication implementations, and implement security headers.

• High · Unmaintained Framework — README.md - Project announcement. Nancy framework is officially announced as no longer being maintained. This means no security patches, bug fixes, or updates will be released. The framework is vulnerable to emerging security threats and known vulnerabilities will not be addressed. Fix: Migrate to an actively maintained web framework such as ASP.NET Core, which receives regular security updates and patches.
• High · Missing Dependency Vulnerability Analysis — Dependencies section (not provided). No package file content (packages.config, .csproj, or dependencies.json) was provided for analysis. Cannot assess if the project depends on vulnerable NuGet packages or outdated dependencies. Fix: Conduct a comprehensive dependency audit using tools like OWASP Dependency-Check, Snyk, or WhiteSource. Review all NuGet packages for known vulnerabilities and update to patched versions.
• Medium · Potential Hardcoded Credentials in Configuration Files — samples/Nancy.Demo.Authentication*/Web.*.config files. Multiple Web.config files are present in the samples directory (Web.Debug.config, Web.Release.config). These configuration files may contain hardcoded database connection strings, API keys, or credentials. Fix: Review all config files and remove hardcoded credentials. Use secure configuration management practices such as Azure Key Vault, AWS Secrets Manager, or environment variables. Never commit sensitive credentials to version control.
• Medium · Authentication Sample Security Concerns — samples/Nancy.Demo.Authentication* directories. The authentication samples (Forms, Basic, Stateless) may contain insecure implementations as examples. BasicAuth credentials are transmitted in Base64 encoding which is easily reversible. Forms authentication samples may lack CSRF protection or secure session handling. Fix: Ensure all authentication samples use HTTPS/TLS. For BasicAuth, enforce SSL/TLS. For Forms auth, implement CSRF tokens and secure session cookies with HttpOnly and Secure flags. Add detailed security notes to sample documentation.
• Medium · Potential XSS Vulnerabilities in View Templates — samples/Nancy.Demo.Authentication*/Views/*.cshtml. Cshtml view files are present (Views/*.cshtml) in authentication samples. Without inspection, there's a risk of XSS vulnerabilities if user input is rendered without proper HTML encoding. Fix: Review all view templates to ensure proper HTML encoding. Use @Html.Encode() or equivalent for all user-controlled output. Enable ASP.NET's built-in XSS protection headers.
• Low · Missing Security Headers Configuration — Nancy configuration/bootstrapper files (not shown in detail). No evidence of security header configuration (CSP, HSTS, X-Frame-Options, X-Content-Type-Options) in the visible file structure. Fix: Implement security headers in the application bootstrapper: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, X-XSS-Protection.
• Low · No Evidence of Input Validation Framework — Project-wide. The file structure does not show explicit input validation or sanitization libraries being used consistently across the codebase. Fix: Implement a comprehensive input validation strategy. Use Nancy's binding validation features and add additional validation layers. Validate all user inputs on both client and server side.

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.