Chameleon v0.5.11 Fixes the Part of AI Coding Everyone Reviews by Hand

Most AI coding demos end at the moment the code compiles. Most engineering work starts after that. The generated diff may pass tests and still feel wrong: wrong file, wrong abstraction, wrong naming convention, wrong wrapper, wrong test shape, wrong local dialect. Chameleon v0.5.11 is interesting because it attacks that review tax before the edit lands.

Chameleon is a Claude Code plugin that learns a repository’s actual conventions and injects archetype-aware guidance before Edit, Write, and NotebookEdit operations. It currently focuses on TypeScript and Ruby on Rails, with install paths also documented for Cursor, Codex CLI, and Gemini CLI. The project is early — created May 10, pushed May 18, one open issue, no meaningful public traction yet — but the problem is not early. Every team using coding agents in a mature codebase has seen the same thing: the agent writes code that is logically close and socially unacceptable.

The repo has a dialect, and the model does not speak it by default

Framework conventions are not enough. Two Rails apps can disagree about service object placement, JSON shaping, background-job wrappers, error handling, test fixtures, and whether controllers are allowed to do anything interesting. Two TypeScript frontends can share React and still disagree about hooks, file layout, data fetching, internal clients, and naming. A model trained on broad public code will default to the median pattern. Your repo probably is not the median.

Chameleon’s workflow is built around that fact. /chameleon-init scans the repo, clusters files into archetypes using AST and statistical signatures, selects canonical examples, and writes a committed .chameleon/profile.json. /chameleon-trust is a per-user approval gate; the profile can live in the repo, but each developer decides whether to trust it locally. Before edits, a PreToolUse hook calls the Chameleon MCP server and injects a <chameleon-context> block containing the matching archetype’s canonical excerpt, rules, and team idioms. /chameleon-teach captures rules an AST cannot infer, such as banned imports, required internal wrappers, or conventions that reviewers keep repeating.

That is a better loop than yelling at the agent after the PR. The highest-leverage moment for style guidance is not review; it is just before generation. If the agent is about to create a new API client, show it the existing API client shape. If it is editing a controller, show it the project’s controller idiom. If the team has a mandatory wrapper around HTTP calls, put that rule in the context before the model invents a direct fetch.

The v0.5.11 patch fixes two bugs that only appear once the tool meets real agent workflows. First, the daemon listen backlog rises from 16 to 128 after parallel-agent bursts of 100 concurrent connects produced ECONNREFUSED for roughly 80 of 100 attempts against v0.5.10. That is the agentic-coding story in miniature: what works for one developer in one terminal breaks when teams run many agents, worktrees, or sessions at once.

Second, Chameleon adds a cumulative 200KB cap on idioms.md. The old 50KB per-call guard prevented one giant teach, but hundreds of small teachings could push the file past 100KB. Worse, the 8,000-character context envelope meant anything past roughly the first 80 idioms no longer reached the model. This is not just a storage bug. It is a knowledge-management bug. Teams need a way to encode local conventions, but if the guidance grows without pruning, the oldest or least important rules crowd out the ones the agent actually needs.

Convention tools live in the edit hot path, so security counts

The prior v0.5.10 release matters because it hardened the per-edit path. Warm get_pattern_context p50 reportedly dropped from about 15ms to 1.2ms on a real TypeScript client, mostly through memoization and a process-global excerpt cache. Bootstrap archetype collapse reduced one real API repo from 19 to 12 archetypes and one client repo from 39 to 16, while preserving alternate canonical examples. That reduces contradictory guidance and avoids dead archetypes the resolver can never select.

More importantly, v0.5.10 added fd-based O_NOFOLLOW reads, seven-part cache keys using device, inode, size, mtime, ctime, and transform version, post-read fstat checks, C0 control-byte stripping, and fail-open empty excerpts instead of poisoned context. Those are not niceties. Any tool that reads canonical code and injects it into the model becomes a prompt-injection and data-exposure surface. If an attacker or a broken script can swap a canonical witness for a symlink, preserve timestamps, or sneak control characters into model context, your “style helper” becomes an exfiltration helper wearing a friendly badge.

This is where teams should be stricter than the average plugin README. A convention layer should never read outside the repo. It should make profiles reviewable. It should fail closed on suspicious examples and fail open by withholding context when a safe read cannot be guaranteed. It should give developers an opt-out: Chameleon supports a committed repo skip file, a global environment variable, a session disable command, and a 15-minute pause. That may sound excessive until the plugin misfires during a production hotfix. Escape hatches are part of trust.

For practitioners, the action item is to add local-convention fit to your agent evaluation. Give the same feature task to your preferred coding agent in a mature repo and score more than test pass rate. Did it choose the right file location? Did it use the internal client? Did it follow test layout? Did it preserve error-handling conventions? Did it avoid importing a library the team intentionally avoids? Then convert repeated review comments into executable guidance: Chameleon, CLAUDE.md, Cursor rules, Copilot skills, Codex config, custom hooks — the specific mechanism matters less than moving the feedback before the edit.

There is also a useful governance split. Some conventions belong in linters and tests because they are objective. Some belong in docs because they require human judgment. Some belong in pre-edit context because they are examples and tendencies: “controllers here are thin,” “new integrations wrap retries this way,” “tests use factory helpers from this folder,” “never shape API responses directly in the route.” Chameleon is aiming at that third bucket, where most AI-generated-code review friction currently lives.

The caveat is obvious: Chameleon needs adoption signal and independent proof that reviewer comments actually fall. It is young, Claude Code-centered, and limited by language support. But the direction is correct. Vibe coding’s next wall is not whether a model can emit more code. It is whether that code can blend into a codebase with enough local taste that teammates review the logic instead of rewriting the boring parts by hand.

The editorial take: tests tell you whether generated code works. Convention-aware edit context helps decide whether the team will accept it. That is not cosmetic. In a mature repo, “looks like our code” is part of correctness.

Sources: GitHub — Chameleon v0.5.11, Chameleon README, Chameleon changelog, Chameleon architecture, Cursor Composer 2.5 context