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/urfave/negroni 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 — Stale — last commit 1y ago

• 31+ active contributors
• MIT licensed
• CI configured
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 57% of recent commits
• ⚠ No test directory 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 urfave/negroni repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/urfave/negroni.

What it runs against: a local clone of urfave/negroni — 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 urfave/negroni | 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 ≤ 399 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "urfave/negroni(\\.git)?\\b" \\
  && ok "origin remote is urfave/negroni" \\
  || miss "origin remote is not urfave/negroni (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 399 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~369d)"
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/urfave/negroni"
  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).

Negroni is a lightweight HTTP middleware library for Go that provides idiomatic composition of net/http Handlers without magic or opinionated abstractions. It allows developers to chain middleware (like logging, recovery, static file serving) in a clean, non-intrusive way while remaining fully compatible with Go's standard http.Handler interface. Monolithic package structure: core middleware types (negroni.go, logger.go, recovery.go, static.go) sit in the root directory alongside their paired test files; response_writer.go and variants handle the ResponseWriter wrapping pattern; examples and translations are organized in subdirectories.

Go backend developers building HTTP services who want middleware composition without framework lock-in (unlike Martini). They need logging, panic recovery, and request inspection but prefer explicit composition over convention-based routing.

Production-ready and stable. The codebase shows comprehensive testing (logger_test.go, negroni_test.go, recovery_test.go, static_test.go), CI integration via Travis CI, and multiple language translations indicating wide adoption. The repo is actively maintained with the formal urfave organization hosting (migrated from codegangsta).

Low risk. No external dependencies listed in go.mod (Go 1.17+ only), comprehensive test coverage visible in test files, and built entirely on Go's standard library. The main risk is that it's a foundational middleware library—breaking API changes would be disruptive, so contributors should be careful with the core Negroni type in negroni.go.

The repo is in maintenance mode—the migration from codegangsta to urfave was finalized, v3 is the current version (per go.mod), and the focus is on stability rather than feature expansion. No specific active development branch visible in the file list, suggesting steady-state maintenance.

Clone the repo and run tests to verify setup:

git clone https://github.com/urfave/negroni.git
cd negroni
go test ./...

Then explore the README example or examine negroni_test.go to understand middleware chaining patterns.

Daily commands: This is a library, not an application. To test locally:

go test ./...
go test -bench=. ./...  # run benchmarks from negroni_bench_test.go

To use in a project, see the Getting Started example in README: instantiate negroni.Classic() or negroni.New(), register handlers with .Use() or .UseHandler(), then pass to http.ListenAndServe().

• negroni.go: Core Negroni type definition and middleware chain orchestration—central to understanding how Use() and UseHandler() compose handlers
• response_writer.go: Implements the ResponseWriter wrapper that captures status codes and response size, essential for logging and monitoring middleware
• logger.go: Reference implementation of built-in middleware—demonstrates the correct signature and pattern for writing custom middleware
• recovery.go: Panic recovery middleware showing how to handle errors and prevent server crashes; critical for production middleware understanding
• negroni_test.go: Comprehensive test suite covering middleware ordering, handler execution, and chain-of-responsibility pattern validation
• static.go: Demonstrates middleware with file system integration; useful pattern for request filtering and conditional handler invocation

For adding middleware: create a new file at the root (e.g., cors.go) implementing func(http.ResponseWriter, *http.Request, http.HandlerFunc) and add corresponding _test.go. For core changes: edit negroni.go (the Negroni struct and Use methods). For response handling: modify response_writer.go, response_writer_test.go, and feature/pusher variants. Always add tests in _test.go files following the pattern in negroni_test.go.

1. Middleware registration order matters—first registered runs first, so place logging before recovery if you want to catch panic stack traces. 2) The ResponseWriter wrapper in response_writer.go is only populated after the wrapped handler executes; reading status before calling Next() will be zero. 3) Negroni expects http.HandlerFunc signature (three args: ResponseWriter, *Request, HandlerFunc); http.Handler interface (two args) requires manual wrapping via UseHandler(). 4) The logger uses the Go standard library log package (not a custom logger), so log output goes to os.Stderr by default.

• Chain of Responsibility pattern — Negroni's core architecture—middleware are linked handlers that each call Next() to pass control; understanding this pattern is essential for writing correct middleware for this library
• http.Handler interface and net/http integration — Negroni is built entirely around Go's standard library net/http; all middleware must implement or wrap http.Handler to be compatible
• ResponseWriter wrapping (delegation pattern) — response_writer.go uses wrapper composition to intercept and inspect HTTP response metadata (status, size) without modifying the standard interface; critical pattern for observability middleware
• Panic recovery and error handling in Go — recovery.go demonstrates defer and recover() to catch panics in middleware—essential safety pattern for production HTTP services; Negroni users depend on this middleware preventing server crashes
• net/http.Server lifecycle and graceful shutdown — Negroni itself is middleware-only, but integration with http.ListenAndServe() requires understanding HTTP server lifecycle; recovery and logging middleware must handle in-flight requests correctly
• Functional middleware composition — Negroni uses functional programming patterns (middleware as functions returning functions) rather than class-based OOP; idiomatic Go approach that requires understanding closures and higher-order functions

• gorilla/mux — Idiomatic Go HTTP router often paired with Negroni for request routing (Negroni handles middleware, Gorilla handles routing)
• urfave/cli — Same organization (urfave); CLI framework following similar philosophy of idiomatic, non-magical Go patterns
• go-chi/chi — Modern, lightweight HTTP router and middleware multiplexer—alternative to Gorilla Mux that integrates well with Negroni-style middleware
• codegangsta/gin — Historical predecessor from codegangsta org; provided hot-reload during development before Negroni's design philosophy solidified
• justinas/alice — Complementary middleware chaining library offering a fluent API for composing http.Handler middleware chains

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 HTTP/2 Server Push middleware tests in response_writer_pusher_test.go

The repo has response_writer_pusher.go and response_writer_pusher_test.go, but given the small test file size and the complexity of HTTP/2 Push semantics, there are likely missing edge cases. This would improve reliability for users leveraging Server Push features and ensure compatibility across Go versions.

• [ ] Review response_writer_pusher.go implementation for all public methods
• [ ] Add tests for Push() failures and error conditions in response_writer_pusher_test.go
• [ ] Add tests for Push() with invalid file paths and concurrent push scenarios
• [ ] Add tests verifying Push() works correctly with the middleware chain
• [ ] Run tests against Go 1.17+ to ensure compatibility

Migrate from Travis CI to GitHub Actions in .github/workflows/

The repo still uses .travis.yml for CI (visible in README badges), but GitHub Actions is now the standard for GitHub-hosted projects. This modernizes the build pipeline, improves integration with GitHub, and removes external CI dependency. The .travis.yml file should be replaced with a Go-specific workflow.

• [ ] Create .github/workflows/test.yml for running go test on multiple Go versions (1.17+)
• [ ] Include go fmt, go vet, and go build checks in the workflow
• [ ] Add codecov upload step to maintain coverage tracking
• [ ] Update README.md to replace Travis CI badge with GitHub Actions badge
• [ ] Remove .travis.yml after workflow is verified working

Add missing middleware examples and best practices documentation

The README mentions idiomatic middleware and includes translated versions, but there's no examples/ directory or detailed guide on writing custom middleware. Given negroni.go defines the Handler interface, adding concrete examples (logging, authentication, CORS, error handling) would help contributors and users understand the middleware pattern better.

• [ ] Create examples/ directory with subdirectories for common patterns (e.g., auth, logging, cors)
• [ ] Add example_test.go files demonstrating custom middleware creation with proper signatures
• [ ] Document middleware ordering best practices in README.md or CONTRIBUTING.md
• [ ] Include example of integrating third-party http.Handler middleware
• [ ] Add example showing how to create middleware that wraps http.ResponseWriter (like response_writer.go does)

• Add missing test coverage for response_writer_pusher.go—the file exists but has minimal test surface area; verify HTTP/2 Server Push behavior is tested in response_writer_pusher_test.go
• Write a documentation example for static.go in README.md or a separate examples/ directory—currently only logger and recovery are shown in the Getting Started section
• Add benchmark tests comparing middleware chain overhead (negroni_bench_test.go exists but could expand) with and without logging/recovery to show performance impact of each middleware

Negroni is a lightweight HTTP middleware library with a relatively small attack surface. No critical security vulnerabilities were identified in the file structure or configuration. However, the project uses an outdated Go version (1.17) that should be upgraded to a modern LTS release. A formal vulnerability disclosure policy is absent but would improve security reporting practices. The codebase follows idiomatic Go patterns and doesn't expose obvious injection risks, hardcoded credentials, or misconfigurations based on the available file listing.

• Medium · Go Version Below Current LTS — go.mod. The project specifies go 1.17 in go.mod, which was released in August 2021 and is no longer actively maintained. Current LTS versions (1.20+) include important security patches and performance improvements. Using an older Go version may expose the application to known vulnerabilities in the Go runtime. Fix: Update go.mod to specify a newer Go version, preferably 1.21 or later. Review the Go release notes for breaking changes and test thoroughly before upgrading.
• Low · Missing SECURITY.md or Vulnerability Disclosure Policy — Repository root. The repository does not contain a SECURITY.md file or clear vulnerability disclosure policy. This makes it difficult for security researchers to responsibly report vulnerabilities. Fix: Create a SECURITY.md file in the repository root with instructions for reporting security vulnerabilities, including contact information and expected response timeframes.
• Low · No Evidence of Dependency Pinning in go.mod — go.mod. While go.mod is present, the actual dependency versions are not shown in the provided content. Without explicit version pinning or regular dependency audits, transitive dependencies could introduce security risks. Fix: Ensure go.mod uses explicit version constraints. Run 'go mod tidy' regularly and use 'go list -u -m all' to check for security updates. Consider using tools like 'govulncheck' to scan for known vulnerabilities.

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.