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/geektutu/7days-golang 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 2y ago

• 5 active contributors
• MIT licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 94% of recent commits
• ⚠ No CI workflows detected
• ⚠ 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 geektutu/7days-golang repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/geektutu/7days-golang.

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

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

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

A progressive educational monorepo implementing 4 core Go systems from scratch: Gee (gin-like web framework), GeeCache (groupcache-like distributed cache), GeeORM (gorm/xorm-like ORM), and GeeRPC (RPC framework). Each system is split into 7 daily milestones showing incremental feature implementation, plus demo-wasm examples for WebAssembly interop. Flat monorepo structure: gee-web/ (7 daily directories), gee-cache/ (7 daily directories), gee-orm/ (implied from README), gee-bolt/ (B+tree KV store, 3 days), demo-wasm/ (4 separate WebAssembly examples). Each day is a standalone Go module (go.mod per directory) allowing independent study and incremental complexity. No shared /pkg or /internal directories—each stage is self-contained.

Go learners and intermediate developers who want to understand internals of production libraries—specifically those building web services, distributed systems, or databases and wanting to see how routing trees, LRU eviction, connection pooling, and RPC marshaling actually work under the hood.

Actively maintained educational project (not production library). Code is clean and well-structured with tests present in key modules (lru_test.go, geecache_test.go visible). No CI/CD pipeline evident in file list. Useful for learning but not battle-tested for production use; intended as tutorial reference material, not as drop-in replacement for gin/gorm.

Single-maintainer repo (geektutu) with no apparent test coverage across all modules—test files only visible in gee-cache examples. No dependency declarations in go.mod snippets shown; likely minimal external deps but needs verification. Breaking changes between day-stages expected as design evolves. Not recommended for production; suitable only for educational/prototyping purposes.

No recent activity data visible from file list. Repository appears stable/archival—designed as a static educational series rather than active development project. Last updates likely from initial creation of each 7-day series; no PRs, issue tracker, or milestone activity data present.

git clone https://github.com/geektutu/7days-golang && cd gee-cache/day1-lru && go mod download && go test ./geecache/lru

Daily commands: Each day is independent. Example: cd gee-cache/day3-http-server/geecache && go test ./... To run HTTP server: cd gee-web/day1-http-base && go run main.go (then curl http://localhost:8000). WebAssembly: cd demo-wasm/hello-world && make && open index.html

• gee-cache/day1-lru/geecache/lru/lru.go: Core LRU cache eviction algorithm—doubly-linked list + map pattern foundational to all cache systems
• gee-cache/day3-http-server/geecache/http.go: HTTP peer communication for distributed cache—shows net/http server setup and client logic
• gee-web/day3-router/router.go: Trie-tree router implementation—critical pattern for URL routing in web frameworks
• gee-cache/day4-consistent-hash/hash.go: Consistent hashing for node distribution—enables scalable multi-node cache architectures
• gee-bolt/day3-tree/node.go: B+tree node structure—foundational for embedded key-value storage
• demo-wasm/hello-world/main.go: Go-to-WebAssembly compilation example—shows syscall/js bridge for browser interop

For web framework features: edit gee-web/day{N}/engine.go or router.go. For cache features: edit gee-cache/day{N}/geecache/geecache.go or lru/lru.go. For ORM: gee-orm/day{N}/ (structure inferred from README). Add tests alongside code—e.g., lru_test.go pattern. Each day builds on previous, so understand day1 before modifying day2+.

Each day's directory is a separate Go module with its own go.mod—import paths do NOT work across days (day1 LRU cannot be imported by day2, code is duplicated). Tests only present in gee-cache modules; gee-web, gee-orm, gee-bolt may lack test files (verify locally). WebAssembly demos require GOOS=js GOARCH=wasm build tags and specific Makefiles—standard go run will fail. No README files in subdirectories; all docs link to external geektutu.com articles.

• LRU Cache Eviction — Gee-Cache day1 core algorithm—without understanding doubly-linked list + map O(1) operations, cache implementations appear magical
• Trie Tree (Prefix Tree) for Routing — Gee-Web day3—enables O(log n) URL route matching with wildcard support, foundational to all modern web frameworks
• Consistent Hashing — GeeCache day4—solves the problem of mapping cache keys to nodes such that adding/removing nodes only rebalances O(1/n) of data, not all data
• Single-Flight Pattern (Request Deduplication) — GeeCache day6—prevents 'thundering herd' where multiple goroutines request same uncached key, each triggering separate DB query
• Memory-Mapped I/O (mmap) — Gee-Bolt day2—allows direct OS memory page access to database file without copying, critical for embedded KV store performance
• B+Tree Index Structure — Gee-Bolt day3—balances storage efficiency and range query performance, the index structure behind most relational databases
• Reflection for Struct-to-SQL Mapping — GeeORM (implied)—Go's reflect package enables ORM magic: inspecting struct fields to auto-generate CREATE TABLE and INSERT statements

• gin-gonic/gin — Production web framework that Gee mimics—reference implementation for routing, middleware, context patterns
• golang/groupcache — Official distributed cache library that GeeCache is based on—shows how memcached-like caching works at scale
• jinzhu/gorm — Production ORM that GeeORM references for query builder and struct mapping design
• go-xorm/xorm — Alternative ORM with simpler interface that GeeORM explicitly borrows API patterns from
• geektutu/high-performance-go — Companion repo by same author on Go optimization techniques—applies to performance-critical paths in Gee/GeeCache

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 benchmarking suite for GeeCache consistent hash implementation

The gee-cache/day4-consistent-hash/geecache/consistenthash/ directory has a consistenthash.go with a test file, but lacks performance benchmarks. Given that consistent hashing is critical for distributed cache performance, adding benchmarks would help contributors understand performance characteristics of Get(), Add(), and node lookup operations across varying node counts. This is especially valuable since the repo is educational.

• [ ] Create gee-cache/day4-consistent-hash/geecache/consistenthash/consistenthash_bench_test.go
• [ ] Add benchmarks for Get() with 10, 100, 1000 nodes to measure lookup latency
• [ ] Add benchmarks for Add() operation to measure hash ring rebuild costs
• [ ] Add benchmarks comparing virtual node counts (10, 50, 150) impact on distribution
• [ ] Document results in gee-cache/day4-consistent-hash/README.md

Add integration tests connecting GeeCache HTTP server with multiple nodes

The gee-cache/day3-http-server/main.go and day4-consistent-hash/main.go show single-node HTTP server examples, but there are no integration tests verifying multi-node cache retrieval, peer communication, and fallback behavior. This is critical for an educational distributed cache framework to demonstrate real-world usage patterns.

• [ ] Create gee-cache/day4-consistent-hash/integration_test.go
• [ ] Write TestMultiNodeCacheRetrieval that spins up 3 cache nodes on different ports
• [ ] Add TestPeerNotAvailableFallback verifying behavior when a peer node is down
• [ ] Add TestDataConsistencyAcrossNodes verifying same key returns same value across all nodes
• [ ] Add TestHashRingRebalancing when nodes are added/removed dynamically

Add end-to-end tests and documentation for demo-wasm examples

The demo-wasm directory contains 4 complete examples (hello-world, callback, manipulate-dom, register-functions) with Makefiles and index.html files, but lacks automated testing and a consolidated README explaining each example's purpose and how to run them. New contributors cannot easily understand what each demo teaches or verify they work correctly.

• [ ] Create demo-wasm/README.md documenting each example's learning objectives and build/run instructions
• [ ] Add demo-wasm/Makefile.test script that compiles all 4 examples and validates generated .wasm files
• [ ] Create demo-wasm/test_wasm.sh shell script that optionally runs examples in a headless browser (wasmtime or wasmer)
• [ ] Add comments in each main.go explaining the WASM concepts being demonstrated (e.g., 'register-functions' shows JS-Go interop)
• [ ] Document expected behavior and output for each example in their respective directories

• Add benchmarking tests (BenchmarkLRUEviction, BenchmarkCacheHit) to gee-cache/day1-lru/geecache/lru/lru_test.go to quantify performance improvements across days 1-7
• Create gee-web/day*/README.md for each day explaining the specific pattern (e.g., 'day3: Trie Router with wildcard support'), filling the gap left by external-only documentation
• Add concurrent access tests (TestConcurrentGet, TestConcurrentSet using sync.WaitGroup) to gee-cache/day2-single-node/geecache/geecache_test.go to validate thread-safety claims

This is an educational codebase ('7 days golang programs from scratch') designed for learning purposes, not production deployment. The primary security concern is the use of Go 1.13 (outdated, lacking security patches). The framework implementations lack explicit security features typical of production systems (TLS, comprehensive input validation, security headers). However, as a learning project, the codebase demonstrates basic architectural patterns. If any components are adapted for production use, significant security hardening is required, particularly around input validation, error handling, cryptography, and secure HTTP configuration.

• Medium · Outdated Go Version — gee-bolt/day1-pages/go.mod and other go.mod files. The project specifies Go 1.13 in go.mod files, which is significantly outdated (released September 2019). This version lacks security patches and bug fixes from newer Go releases, exposing the code to known vulnerabilities in the standard library and runtime. Fix: Update to the latest stable Go version (1.21+) to receive security patches, performance improvements, and bug fixes. Review and test the codebase for compatibility.
• Medium · Missing Input Validation in HTTP Server — gee-cache/day3-http-server/geecache/http.go. The gee-cache HTTP server implementation (gee-cache/day3-http-server/geecache/http.go) may lack proper input validation and sanitization. Without explicit validation, the HTTP server could be vulnerable to HTTP request smuggling, path traversal, or other HTTP-based attacks. Fix: Implement comprehensive input validation for all HTTP endpoints. Validate request paths, headers, and query parameters. Use standard library functions for URL parsing and validation.
• Low · Potential Race Conditions in Cache Operations — gee-cache/day*/geecache/lru/lru.go and cache.go. The cache implementation (gee-cache components) uses synchronization mechanisms (lru.go), but without reviewing the actual code, concurrent access patterns could introduce race conditions, especially in multi-threaded environments. Fix: Run the codebase with go test -race to detect race conditions. Ensure all shared data structures are properly protected with mutexes or other synchronization primitives.
• Low · No HTTPS/TLS Configuration Visible — gee-cache/day3-http-server/main.go and similar entry points. The HTTP server implementation does not show explicit TLS/SSL configuration. If the cache or framework is deployed in production, unencrypted communication could expose data in transit. Fix: Implement TLS support for all HTTP servers. Use certificates from a trusted CA (Let's Encrypt for production). Configure secure cipher suites and HTTPS redirects.
• Low · Insufficient Error Handling — Throughout codebase (main.go files, error handling in handlers). Educational code often has minimal error handling. If this framework is adapted for production use, errors could leak sensitive information or cause unexpected behavior. Fix: Implement comprehensive error handling. Log errors securely without exposing stack traces to clients. Return generic error messages to end users.
• Low · Missing Security Headers — gee-cache/day3-http-server/geecache/http.go and Gee framework HTTP handling. Web framework implementations (Gee) may not include security headers like HSTS, Content-Security-Policy, X-Frame-Options, or X-Content-Type-Options, which could increase vulnerability to various web attacks. Fix: Add middleware to inject security headers in all HTTP responses. Implement HSTS, CSP, X-Frame-Options, X-Content-Type-Options, and X-XSS-Protection headers.

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.