claude-code-autoconfig 1.0.97 → 1.0.99

package/README.md

@@ -85,7 +85,6 @@ Autoconfig is **self-configuring**. Run `/autoconfig` and Claude:
 | CLAUDE.md introspection | Yes | Yes |
 | Slash commands | Yes | Yes |
 | MEMORY.md | Yes | Yes |
-| Update system | Yes | Yes |
 | Auto-format hook | Yes | Coming soon |
 | Optimized permissions | Yes | Coming soon |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-autoconfig",
-  "version": "1.0.97",
+  "version": "1.0.99",
   "description": "Intelligent, self-configuring setup for Claude Code. One command analyzes your project, configures Claude, and shows you what it did.",
   "author": "ADAC 1001 <info@adac1001.com>",
   "license": "MIT",
@@ -36,6 +36,7 @@
     "!.claude/settings.local.json",
     "!.claude/commands/publish.md",
     "!.claude/commands/gls.md",
+    "!.claude/docs/multi-stack-parity-plan.md",
     "CLAUDE.md"
   ],
   "engines": {

package/.claude/docs/multi-stack-parity-plan.md

@@ -1,205 +0,0 @@
-# Multi-Stack Parity: Python & .NET Support
-
-> Design document for expanding claude-code-autoconfig beyond JS/TS.
-> Upload this into a Claude Code session to resume implementation.
-
-## Background
-
-claude-code-autoconfig detects 8 language stacks during `/autoconfig` but only provides full end-to-end support (formatter, settings, hooks, permissions) for JS/TS. Python and .NET projects get correct CLAUDE.md generation, but everything else is JS-oriented: npm-specific permission patterns, a format hook that only handles JS files, and Prettier-only formatter setup.
-
-**Current version:** 1.0.96 (as of 2026-02-09)
-
-## What "Full Support" Means Per Stack
-
-| Feature | JS/TS (current) | Python (needed) | .NET (needed) |
-|---------|-----------------|-----------------|---------------|
-| CLAUDE.md generation | Yes | Yes (already works) | Yes (already works) |
-| Formatter detection | Prettier | black, ruff | dotnet format (built-in) |
-| Formatter install offer | `npm install -D prettier` | `pip install black` | N/A (SDK includes it) |
-| Format hook (Write/Edit) | `npm run format` on `.js/.ts/.css/etc` | `ruff format {file}` or `black {file}` on `.py` | `dotnet format` on `.cs/.fs/.vb` |
-| Allow patterns | `Bash(npm run test:*)`, `Bash(npm run build)`, etc. | `Bash(pytest)`, `Bash(pip install *)`, etc. | `Bash(dotnet test)`, `Bash(dotnet build)`, etc. |
-| Deny patterns | `Edit(./node_modules/**)`, `Edit(./dist/**)` | `Edit(./venv/**)`, `Edit(./__pycache__/**)` | `Edit(./bin/**)`, `Edit(./obj/**)` |
-| Env vars | `NODE_ENV: development` | `PYTHONDONTWRITEBYTECODE: 1` | `DOTNET_CLI_TELEMETRY_OPTOUT: 1` |
-
-## Current Architecture
-
-Understanding the architecture is critical before choosing an approach.
-
-### How the system works today
-
-1. **`bin/cli.js`** — Dumb file copier. Downloads the npm package, copies `.claude/` directory structure into the user's project. Zero project analysis. No stack detection.
-
-2. **`.claude/commands/autoconfig.md`** — Natural-language instruction file that Claude interprets at runtime. Claude follows these steps to analyze the project and generate configuration. This is where all the intelligence lives. It's non-deterministic — Claude interprets the instructions, not code.
-
-3. **`.claude/hooks/format.js`** — Actual Node.js code executed as a PostToolUse hook. Receives JSON on stdin describing what file was edited, checks extension, runs `npm run format`. This IS deterministic code.
-
-4. **`.claude/settings.json`** — Static template copied as-is by cli.js. Currently contains JS-specific `Bash(npm run *)` allow patterns hardcoded in the template.
-
-### The intelligence split
-
-| Component | Intelligence | Deterministic? |
-|-----------|-------------|----------------|
-| `cli.js` | None — copies files | Yes |
-| `autoconfig.md` | Full — Claude analyzes project | No |
-| `format.js` | Partial — checks file extensions | Yes |
-| `settings.json` | None — static template | Yes |
-
-## The Factory Pattern Question
-
-### Problem
-
-The original plan was:
-1. Ship a generic `settings.json` template (no stack-specific patterns)
-2. Rely on `/autoconfig` (Claude interpreting markdown) to dynamically add the right allow/deny patterns
-
-This means `settings.json` correctness depends on Claude's interpretation of markdown instructions — which is **non-deterministic**. Claude might add slightly different patterns each run, or miss some entirely.
-
-### Option A: Keep cli.js Dumb (Current Plan)
-
-```
-cli.js → copies generic settings.json → /autoconfig → Claude adds stack-specific patterns
-```
-
-**Pros:**
-- Minimal change to cli.js architecture
-- format.js handles multi-stack detection cleanly at runtime (strategy pattern by file extension)
-- Keeps all intelligence in one place (/autoconfig)
-
-**Cons:**
-- settings.json correctness depends on Claude's interpretation
-- Non-deterministic — may vary between runs
-- If user doesn't run /autoconfig, they get generic settings with no stack-specific permissions
-
-### Option B: Make cli.js Stack-Aware (Factory Pattern)
-
-```
-cli.js → detects stack → generates stack-specific settings.json → /autoconfig → Claude fine-tunes
-```
-
-cli.js would:
-1. Check for `package.json` → JS stack
-2. Check for `requirements.txt`/`pyproject.toml` → Python stack
-3. Check for `*.csproj`/`*.sln` → .NET stack
-4. Select or generate the appropriate settings.json with correct allow/deny/env patterns
-
-**Pros:**
-- Deterministic — correct permissions from first install, before /autoconfig runs
-- Users who skip /autoconfig still get stack-appropriate settings
-- Testable — can unit test the stack detection and template selection
-
-**Cons:**
-- cli.js becomes smarter (more complexity in the bootstrapper)
-- Need to maintain stack detection logic in TWO places (cli.js AND autoconfig.md)
-- Could use template files (`settings.js.json`, `settings.python.json`, `settings.dotnet.json`) or a builder function
-
-### Option C: Hybrid — cli.js Detects, Merges at Runtime
-
-```
-cli.js → detects stack → writes .claude/.stack marker → copies generic settings.json
-/autoconfig → reads .stack marker → applies deterministic stack config
-format.js → reads .stack marker OR detects by file extension
-```
-
-A small `.claude/.stack` file (e.g., `{"stack": "python", "detectedAt": "2026-02-09"}`) gives all components a deterministic signal without duplicating detection logic.
-
-**Pros:**
-- cli.js stays mostly dumb (just writes a small marker)
-- /autoconfig has a deterministic signal to work from
-- Detection logic lives in one place (cli.js), consumers just read the marker
-- Can be overridden by the user
-
-**Cons:**
-- Adds a new file to the .claude/ directory
-- Marker could become stale if project stack changes
-
-## Files That Need Changes (Any Approach)
-
-### `.claude/hooks/format.js`
-
-Refactor to detect file type by extension and run appropriate formatter. This is clean regardless of which architecture option is chosen — runtime file extension detection is the right approach for the hook.
-
-```javascript
-const STACKS = {
-  js: {
-    extensions: /\.(js|jsx|ts|tsx|json|css|scss|md|html)$/,
-    skipDirs: ['node_modules', 'dist/', 'build/'],
-    format: (filePath, cwd) => {
-      execSync('npm run format --silent || true', { cwd, stdio: 'ignore' });
-    }
-  },
-  python: {
-    extensions: /\.(py|pyi)$/,
-    skipDirs: ['venv/', '.venv/', '__pycache__/', '.egg-info/'],
-    format: (filePath, cwd) => {
-      try { execSync(`ruff format "${filePath}"`, { cwd, stdio: 'ignore' }); }
-      catch { try { execSync(`black "${filePath}"`, { cwd, stdio: 'ignore' }); } catch {} }
-    }
-  },
-  dotnet: {
-    extensions: /\.(cs|fs|vb)$/,
-    skipDirs: ['bin/', 'obj/'],
-    format: (filePath, cwd) => {
-      execSync('dotnet format || true', { cwd, stdio: 'ignore' });
-    }
-  }
-};
-```
-
-### `.claude/commands/autoconfig.md` — Steps 5 and 6
-
-**Step 5** needs sub-steps per stack:
-- 5a: Detect stack from project markers
-- 5b: JS/TS formatter (existing Prettier logic, unchanged)
-- 5c: Python formatter (detect black/ruff, offer install)
-- 5d: .NET formatter (dotnet format, built-in)
-- 5e: Add PostToolUse hook (same for all — format.js handles detection)
-
-**Step 6** needs stack-conditional tables for deny/allow/env patterns.
-
-### `.claude/settings.json`
-
-Current template has JS-specific `Bash(npm run *)` patterns hardcoded. Needs to either:
-- **Option A**: Become generic (remove npm patterns, let /autoconfig add them)
-- **Option B**: Be replaced by stack-specific templates selected by cli.js
-- **Option C**: Stay generic, with cli.js writing a `.stack` marker for /autoconfig
-
-### `test/cli-install.test.js`
-
-Add multi-stack test sections:
-- format.js handles Python file extensions (`.py`, `.pyi`)
-- format.js handles .NET file extensions (`.cs`, `.fs`, `.vb`)
-- format.js has Python skip dirs (`venv/`, `__pycache__/`)
-- format.js has .NET skip dirs (`bin/`, `obj/`)
-- format.js runs ruff/black for Python
-- format.js runs dotnet format for .NET
-
-## Stack-Specific Details
-
-### Python Considerations
-- `pip install black` may need a virtual environment — should check if venv is active
-- Some projects use `python3`/`pip3` vs `python`/`pip`
-- `ruff` is faster and gaining adoption but `black` is the established standard
-- `pyproject.toml` can contain deps in `[project.dependencies]` or `[tool.poetry.dependencies]`
-
-### .NET Considerations
-- `dotnet format` requires the .NET SDK (not just runtime)
-- `*.csproj` files may be in subdirectories (solution structure)
-- `dotnet format` formats the whole project (no practical single-file mode)
-
-### Mixed-Stack Projects
-- A repo with both `package.json` and `requirements.txt` (JS frontend + Python backend)
-- Per-file extension detection in format.js handles this naturally
-- For settings.json, should include patterns for ALL detected stacks, not just primary
-
-## Decision Needed
-
-Before implementing, decide on the architecture:
-- **Option A**: Keep cli.js dumb, trust /autoconfig (simpler, less reliable)
-- **Option B**: Factory pattern in cli.js (more reliable, more complex)
-- **Option C**: Hybrid with .stack marker (balanced)
-
-Recommendation: **Option B or C** — deterministic stack-appropriate settings from first install is a better user experience than relying on Claude's interpretation of markdown instructions.
-
-## Work Already Completed (Revert Before Starting)
-
-A multi-stack `format.js` was written but reverted since we paused to think about architecture. The code is in this doc above as reference. No other files were modified.