claude-code-autoconfig 1.0.83 → 1.0.85

package/.claude/commands/autoconfig.md

@@ -299,12 +299,10 @@ The file lives at `~/.claude/projects/{encoded-project-path}/memory/MEMORY.md` w
 
 ```markdown
 ## Debugging — Evidence Before Solutions
-NEVER guess the root cause and jump to coding a fix. Always:
+NEVER guess the root cause and jump to coding a fix. Ask yourself: is the cause deterministic and verifiable from the error alone (e.g., stack trace, compile error)? If yes, fix it directly. If not:
 1. Add logging / check actual data first
 2. Confirm root cause with evidence
 3. Only then propose and implement a fix
-If you can't determine the cause from code alone, add diagnostic logging and verify with runtime data.
-CRITICAL: A plausible-looking cause from code reading is NOT confirmed evidence. Even if a mismatch looks obvious across multiple files, verify with runtime data before implementing. The more "obvious" the cause looks, the more important it is to verify — that's when the temptation to skip evidence gathering is strongest.
 ```
 
 **Important**: Use the Write tool (or Edit to append). Do not skip this step — it ensures Claude investigates root causes before making changes in every future session.

package/.claude/updates/001-debug-methodology.md

@@ -11,12 +11,10 @@ Add the following to the user's `MEMORY.md` file (Claude's persistent auto memor
 
 ```markdown
 ## Debugging — Evidence Before Solutions
-NEVER guess the root cause and jump to coding a fix. Always:
+NEVER guess the root cause and jump to coding a fix. Ask yourself: is the cause deterministic and verifiable from the error alone (e.g., stack trace, compile error)? If yes, fix it directly. If not:
 1. Add logging / check actual data first
 2. Confirm root cause with evidence
 3. Only then propose and implement a fix
-If you can't determine the cause from code alone, add diagnostic logging and verify with runtime data.
-CRITICAL: A plausible-looking cause from code reading is NOT confirmed evidence. Even if a mismatch looks obvious across multiple files, verify with runtime data before implementing. The more "obvious" the cause looks, the more important it is to verify — that's when the temptation to skip evidence gathering is strongest.
 ```
 
 ## After Applying

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-autoconfig",
-  "version": "1.0.83",
+  "version": "1.0.85",
   "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",
@@ -34,6 +34,7 @@
     "bin",
     ".claude",
     "!.claude/settings.local.json",
+    "!.claude/commands/publish.md",
     "CLAUDE.md"
   ],
   "engines": {

package/.claude/commands/publish.md

@@ -1,24 +0,0 @@
-<!-- @description Runs tests, bumps version, commits, and publishes to npm. -->
-
-# Publish
-
-Run tests, bump the patch version, commit, push, and publish to npm.
-
-## Steps
-
-1. Run the project's test suite (`npm test`)
-2. **If tests fail, stop here.** Do not publish broken code.
-3. Check for uncommitted changes. If there are any:
-   a. Stage all changes (`git add -A`)
-   b. Generate a conventional commit message based on the diff
-   c. Commit the changes
-4. Bump the version: `npm version patch`
-5. Push the commit and tag: `git push && git push --tags`
-6. Publish to npm: `npm publish`
-7. Output the new version number on success
-
-## Important
-
-- Always run tests before publishing — never skip this step
-- If any step fails, stop immediately and report the error
-- Do not use `--force` on publish unless the user explicitly asks