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/asciimoo/wuzz 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 — Slowing — last commit 6mo ago

• Last commit 6mo ago
• 21+ active contributors
• AGPL-3.0 licensed
• CI configured
• ⚠ Slowing — last commit 6mo ago
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility
• ⚠ 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 asciimoo/wuzz repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/asciimoo/wuzz.

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

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.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"

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

Wuzz is an interactive CLI tool for HTTP request inspection and debugging, designed as a curl-like alternative with a TUI interface. It lets you compose, inspect, and modify HTTP requests in real-time with syntax highlighting, request/response formatting (JSON, HTML, text, binary), and history management—all in the terminal. Monolithic CLI structure: wuzz.go is the entry point, commands.go handles keybindings and command dispatch, request-headers.go and status-line.go manage UI state for specific views. The formatter/ package (formatter.go, json.go, html.go, text.go, binary.go) handles response body formatting. Config is loaded from config/config.go and defaults to $XDG_CONFIG_HOME/wuzz/config.toml or ~/.wuzz/config.toml.

API developers and testers who inspect network requests from browser DevTools ('copy as cURL') and need an interactive, formatted alternative to curl/Postman in the terminal. DevOps engineers and CLI enthusiasts who prefer terminal-based workflows.

Mature and stable: the project has binary releases, is packaged in major package managers (apt, apk, scoop, nix), and supports Go ≥1.10. The codebase is relatively small (~72KB Go), with minimal dependencies (gocui for UI, goquery for HTML parsing). CI is configured (.travis.yml present). Likely production-ready for HTTP inspection tasks, though commit recency and issue backlog are not visible here.

Low-risk: dependencies are well-established (BurntSushi/toml, PuerkitoBio/goquery, awesome-gocui/gocui) and the dependency count is modest. Single-maintainer projects carry typical GitHub sustainability risk, but the tool's maturity and broad package distribution reduce operational risk. No breaking changes are apparent from the structure.

No specific active development details are visible from the file list alone (no CHANGELOG dates or recent commit info provided), but the repo maintains releases and package manager integrations. The .travis.yml indicates CI was/is in use.

git clone https://github.com/asciimoo/wuzz.git
cd wuzz
go build -o wuzz ./
./wuzz --help

Or install via: go get github.com/asciimoo/wuzz (requires Go ≥1.10).

Daily commands:

go build -o wuzz ./
./wuzz [OPTIONS]
# Example: wuzz -H 'Authorization: Bearer TOKEN' https://api.example.com
# Or load a saved request: wuzz -c config.toml

Use F1 for keybinding help inside the TUI.

• wuzz.go: Entry point: parses CLI arguments (like curl), initializes the TUI, and orchestrates the main loop
• commands.go: Central dispatch for keyboard events and command execution (send request, save, load, navigate views)
• keys.go: Keybinding definitions (F1–F11, Ctrl+R, Tab, etc.) mapped to handler functions
• formatter/formatter.go: Plugin architecture for response body formatting; individual format types (json.go, html.go, text.go, binary.go) implement the Formatter interface
• config/config.go: Configuration loading and defaults (headers, methods, colors); used to populate initial request state
• request-headers.go: TUI view for HTTP headers, method, and URL input; stateful editor for request composition
• status-line.go: Response metadata display (status code, content-type, response time); UI rendering for HTTP status

Adding a new formatter: Edit formatter/formatter.go and create a new file like formatter/yaml.go with a format function. Adding keybindings: Edit keys.go and commands.go to map key events to actions. Changing UI layout: Edit status-line.go and request-headers.go. Config changes: Modify config/config.go and sample-config.toml. Adding CLI flags: Edit wuzz.go and reference in commands.go.

1. Config file path varies by OS: Linux uses $XDG_CONFIG_HOME/wuzz/config.toml (default ~/.config/wuzz/config.toml), other platforms use ~/.wuzz/config.toml. Use -c to override. 2. Terminal size matters: gocui requires a minimum terminal width/height; small terminals may crash. 3. Blocking I/O: HTTP requests block the TUI; long-running requests will freeze the UI (no async I/O visible in wuzz.go). 4. Go version ≥1.10 required explicitly (see README).

• Terminal User Interface (TUI) with tcell/gocui — Wuzz is built on gocui, a Go framework for mouse/keyboard-driven terminal UIs; understanding Views, keybindings, and event loops is essential to modify UI behavior
• Regular Expression Search (Context-Specific) — Wuzz filters response bodies using regex by default (Ctrl+T toggles format-specific syntax for JSON/HTML); critical for response inspection workflows
• HTTP Request/Response Formatting (Content Negotiation) — Wuzz auto-detects and formats responses (JSON, HTML, plain text, binary); the formatter/ package implements a plugin pattern to parse and syntax-highlight different MIME types
• Cross-Platform Config Paths (XDG Base Directory) — Wuzz respects $XDG_CONFIG_HOME on Linux and ~/.wuzz/ on macOS/Windows; mitchellh/go-homedir abstracts this—important for config/config.go portability
• TOML Configuration Syntax — User configuration (headers, defaults, colors) is stored in TOML format (sample-config.toml); BurntSushi/toml parses it in config/config.go
• CSS Selector Querying (goquery) — HTML responses are parsed and selectable via CSS selectors for search/extraction; goquery wraps Go's net/html with a jQuery-like API (used in formatter/html.go)
• JSON Path Queries (gjson) — JSON responses are filtered using gjson's path syntax (e.g., 'user.name') for context-specific search; tidwall/gjson enables lightweight JSON extraction without unmarshaling

• httpie/httpie — Alternative CLI HTTP client with similar inspect/format features but Python-based; major competitor for terminal HTTP testing
• jqlang/jq — Query and transform JSON responses; often piped with wuzz to filter/extract data from saved responses
• curl/curl — Original inspiration and reference—wuzz uses curl-compatible CLI arguments and targets users migrating from curl
• awesome-gocui/gocui — Direct dependency providing the TUI framework; understanding gocui's View/Key model is essential for modifying wuzz's UI
• BurntSushi/toml — Direct dependency for config parsing; format for sample-config.toml and user configs

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 unit tests for formatter package

The formatter/ directory has multiple format handlers (json.go, html.go, text.go, binary.go) but only formatter_test.go exists. There are no tests for individual formatters, making it risky to refactor or add new format support. New contributors can add comprehensive tests for each formatter to improve code coverage and prevent regressions.

• [ ] Review formatter/formatter_test.go to understand existing test patterns
• [ ] Create formatter/json_test.go with test cases for JSON formatting (valid JSON, invalid JSON, nested objects)
• [ ] Create formatter/html_test.go with test cases for HTML syntax highlighting
• [ ] Create formatter/text_test.go with test cases for plain text formatting
• [ ] Create formatter/binary_test.go with test cases for binary data handling
• [ ] Run go test ./formatter to verify all tests pass

Add GitHub Actions workflow for cross-platform builds

.travis.yml exists but the repo has a Dockerfile and supports multiple platforms (Linux, macOS, Windows via Scoop). A GitHub Actions workflow can build and test on Go 1.24.0 across Linux, macOS, and Windows matrices, replacing the deprecated Travis CI and providing faster feedback.

• [ ] Create .github/workflows/build-test.yml with matrix strategy for [ubuntu-latest, macos-latest, windows-latest]
• [ ] Configure Go version 1.24.0 in the workflow using actions/setup-go@v4
• [ ] Add steps to run: go build -v ./..., go test -v ./..., and go vet ./...
• [ ] Optionally add a step to build Docker image on Linux only
• [ ] Test the workflow by pushing to a branch and verifying it runs on all platforms

Add integration tests for HTTP request/response handling in commands.go

commands.go likely contains core HTTP request logic but has no corresponding test file. Integration tests would verify that wuzz correctly constructs requests, handles headers (see request-headers.go), processes responses, and respects configuration (config/config.go). This is critical for an HTTP inspection tool.

• [ ] Create commands_test.go in the root directory
• [ ] Write tests for request header parsing and construction using Go's httptest package
• [ ] Write tests for status line parsing (reference status-line.go) with various HTTP response codes
• [ ] Write integration tests using httptest.NewServer() to mock HTTP endpoints
• [ ] Test request methods (GET, POST, etc.) and body handling
• [ ] Run go test -v commands_test.go commands.go to verify integration

• Add unit tests for formatter/formatter_test.go: currently only one test file exists; json.go, html.go, text.go, and binary.go have no dedicated tests. Write test cases for edge cases (empty responses, malformed JSON, large payloads).
• Improve documentation in docs/: the README lacks detailed examples of config.toml options beyond 'see sample-config.toml'; create docs/CONFIGURATION.md with annotated examples for headers, proxies, custom formatters.
• Add async request handling: refactor commands.go to run HTTP requests in a goroutine and display a progress indicator, preventing UI freezes during slow API calls.

The wuzz codebase has several significant security concerns, primarily related

• High · Outdated Go Version in Dockerfile — Dockerfile (builder stage). The Dockerfile uses golang:1.14-alpine3.12 for building, which is significantly outdated (released in 2020). This version contains multiple known vulnerabilities and security patches that have been applied in newer Go versions. The go.mod file specifies go 1.24.0, creating a mismatch between the build environment and the intended runtime. Fix: Update the Dockerfile to use a recent, stable Go version (e.g., golang:1.21-alpine or later) that matches or is compatible with the go.mod specification. Regularly update base images to receive security patches.
• High · Outdated Alpine Base Image — Dockerfile (permissions-giver, organizer, and runner stages). The Dockerfile uses alpine:3.12 (released in 2020) as the base image for the final runtime container. This version is no longer actively maintained and lacks critical security updates for system packages. Multiple CVEs exist for packages in this version. Fix: Update to alpine:3.19 or alpine:3.20 (latest stable versions). Run 'apk update && apk upgrade' in the Dockerfile to ensure system packages are patched. Implement automated dependency scanning in the CI/CD pipeline.
• Medium · Missing Security Headers and Input Validation — formatter/ directory (html.go, json.go, text.go). The application appears to process HTTP requests and responses without explicit security validation patterns visible in the file structure. The formatter modules (html.go, json.go) parse external content without clear sanitization, which could lead to code injection or XSS-like vulnerabilities when displaying user-controlled HTTP responses. Fix: Implement strict input validation and output encoding for all user-controlled and HTTP response data. Use established libraries for HTML/JSON parsing with built-in sanitization. Add security tests for malicious payload handling.
• Medium · Insecure Configuration File Handling — config/config.go, sample-config.toml. The application uses TOML configuration files stored in user-writable directories (~/.wuzz/config.toml). No evidence of permission checks or secure file handling is visible. If credentials are stored in config files, they could be exposed through file system permissions issues or world-readable files. Fix: Implement strict file permission checks (0600 for config files containing sensitive data). Document that users should never store credentials in config files. Recommend using environment variables or secure credential managers for sensitive data. Add runtime warnings if config files have overly permissive permissions.
• Medium · Command Injection Risk via shellescape — commands.go, go.mod (alessio/shellescape dependency). The dependency on github.com/alessio/shellescape suggests the application may be executing shell commands. While shellescape provides some protection, improper usage could still lead to command injection vulnerabilities if user input is not properly validated before being passed to shell operations. Fix: Review all uses of shellescape and shell command execution in commands.go. Prefer using Go's standard library exec package with proper argument passing instead of shell execution when possible. Add security tests for command injection with special characters and shell metacharacters.
• Low · Lack of Security Documentation — README.md, docs/. The README and visible documentation do not mention security considerations, best practices for handling sensitive HTTP requests (e.g., API keys), or security incident reporting procedures. This could lead users to inadvertently expose sensitive information. Fix: Add a SECURITY.md file documenting: how to report security issues, warnings about handling sensitive data in the tool, best practices for using with production APIs, and recommendations for secure configuration management.
• Low · Missing Dependency Integrity Verification — go.mod, go.sum. While go.sum is present, there's no evidence of dependency scanning for known vulnerabilities. Some dependencies like golang.org/x/net v0.46.0 may have associated CVEs that should be actively monitored. Fix: Integrate automated dependency vulnerability scanning using tools like 'go list -json -m all | nancy' or GitHub's dependency security alerts. Add pre-commit hooks to prevent commits with known vulnerable dependencies. Regularly run 'go get -u' with vulnerability scanning in the CI/CD pipeline.

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.