chameleon-refreshlisted

# /chameleon-refresh Re-analyze the current repo, detect drift, update `.chameleon/profile.json`. When <= 10% of files changed, uses partial refresh via cached `file_clusters` in `index.db`; only changed files re-parsed. Falls back to full re-bootstrap when change ratio exceeds 10%. ## When to use - The user explicitly invokes `/chameleon-refresh` - `using-chameleon` primer surfaces `days_since_refresh > 90` and the user asks for a refresh - Reviewer feedback indicates the profile is stale (suggesting many recent edits diverge from the canonical) - Material changes to the codebase: significant refactors, framework upgrades, archetype boundaries shifted ## When NOT to use - The first time a repo has chameleon — that's `/chameleon-init`. Refresh requires an existing profile. - For capturing missed patterns — that's `/chameleon-teach`. Refresh re-derives auto-detectable dimensions only. ## The flow 1. Confirm `.chameleon/profile.json` exists. If missing, suggest `/chameleon-init`. 2. Call `chameleon-mcp::chameleon_lifecycle(action="refresh_repo", params={"repo": <absolute path>})`. 3. The tool acquires an OS-level flock on `.chameleon/.refresh.lock` (per-PID + start timestamp; concurrent invocations fail with stale-lock detection at 1 hour). 4. **Production-pinned repos** (`production_ref` in `.chameleon/config.json`, set at init or migrated below): staleness is the locked ref's TIP SHA, not working-tree changes. Before resolving the tip, refresh runs ONE bounded