docs: broaden issue and PR rules to cover our own repo, not just mkaring

Author: RandomCrocodile

CLAUDE.md

@@ -73,45 +73,47 @@ main      — stable, releases only
 
 ---
 
-## Upstream Integration Rules (MANDATORY)
+## Issue & PR Rules (MANDATORY)
 
-Before cherry-picking or adapting ANY change from `mkaring/ConfuserEx`:
+These rules apply to ALL work — our own repo (`mcpolo99/ConfuserExx`) and upstream (`mkaring/ConfuserEx`).
 
-### 1. Verify status first
+### 1. Before starting any work
 
-- Check `gh issue view <number> --repo mkaring/ConfuserEx` for current status
-- Check if a fix was already merged upstream after the issue was filed
-- If the issue is closed/fixed upstream, verify our fork already has the fix
-- Close our corresponding issue if already resolved
-- **Only work on OPEN issues and PRs** — skip closed, wontfix, duplicate, invalid
+- Check if the issue/PR is still open and relevant
+- Check if a fix already exists in our codebase (search commits, PRs, branches)
+- Close issues that are already resolved — comment with the commit hash
+- **Only work on OPEN issues** — skip closed, wontfix, duplicate, invalid
 
-### 2. Review the actual code
-
-- Fetch the PR: `git fetch mkaring pull/<number>/head:pr-<number>`
-- Read the actual diff, not just the title
-- Check if the change conflicts with our existing modifications
-- Test that the cherry-pick applies cleanly
-- **Do NOT blindly cherry-pick — understand what the code does first**
-
-### 3. Analyse code quality
+### 2. Review all PRs thoroughly
 
+- Read the actual diff, not just the title or description
 - Review for correctness, not just intent
 - Check for regressions, missing edge cases, or poor patterns
 - Verify the fix actually solves the stated problem
-- Check if there's a better approach than the upstream PR
+- Check if there's a better approach
+- **Do NOT merge without understanding what the code does**
+
+### 3. When cherry-picking from mkaring/ConfuserEx
+
+- Fetch the PR: `git fetch mkaring pull/<number>/head:pr-<number>`
+- Check if the change conflicts with our existing modifications
+- Test that the cherry-pick applies cleanly
+- **Do NOT blindly cherry-pick — review the code first**
 
-### 4. When creating issues from upstream
+### 4. When creating issues
 
-- Create matching issues on both private and public repos
-- Reference the upstream issue number in the description
+- For upstream issues: create matching issues on our repo, reference the original
 - Mention the original reporter when posting fixes
 - Tag with appropriate labels (enhancement, bug, upstream)
+- Include clear reproduction steps and expected vs actual behavior
 
-### 5. PR iteration rules
+### 5. PR workflow
 
 - Always push fixes to the **same branch** — never create replacement PRs
 - When a PR gets review feedback, push additional commits to the same branch
 - When a tester reports issues, fix on the same branch and ask for re-test
+- Reference the issue number in commits: `fix: handle timeout (#42)`
+- PR description must include `Fixes #<number>` to auto-close the issue
 
 ---