feat: add core/ tier reflecting actual universal workflow

The original repo presented everything as equal rules. In reality, the
workflow has two tiers: core practices (used in every project) and advanced
rules (only in complex projects like Mortdecai).

Core tier adds:
- backup-before-edit (global CLAUDE.md rule)
- superpowers-workflow (the actual workflow engine)
- memory-system (persistent feedback and project memories)
- document-hierarchy (CLAUDE.md/SESSION.md/CONTEXT.md/IDEA.md)
- commit-and-push discipline
- feedback-driven behaviors

Updated README, docs, and dynamic-methodology to reflect the two-tier
reality instead of presenting advanced rules as universal.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

core/feedback-driven-behaviors.md

@@ -0,0 +1,82 @@
+# Feedback-Driven Behaviors
+
+Over time, corrections and confirmed approaches accumulate into persistent behavioral patterns. These are the real workflow rules — not written in a rules file, but learned from experience and stored in memory.
+
+## How It Works
+
+When the user corrects the AI ("don't do X") or confirms a non-obvious approach ("yes, exactly like that"), the correction or confirmation is saved as a feedback memory. Future sessions load these memories and adjust behavior accordingly.
+
+This means the workflow evolves organically. The rules files define the framework, but feedback memories define the actual behavior within that framework.
+
+## Common Feedback Patterns
+
+These are examples of the kinds of behavioral rules that emerge from real usage:
+
+### Execution Style
+- **Prefer immediate execution over confirmation dialogs.** When the task is obvious, communicate what you're doing and go. Don't ask "should I proceed?" for routine operations.
+- **Queue awareness.** Users often queue follow-up instructions while work runs in the background. Always check for and address ALL queued messages before moving on.
+
+### Subagent Safety
+- **Use subagent-driven execution by default** for independent tasks — it's faster and keeps context clean.
+- **NEVER use subagents for destructive operations.** Git history changes, bare repo operations, database modifications, file deletions on remote servers — do these manually in the main conversation, one at a time. A subagent can't be stopped mid-operation if something goes wrong.
+
+### Research Depth
+- **Read memory files before creating tasks or starting work.** Feedback memories contain corrections that prevent repeating past mistakes. Skipping them means re-learning the same lessons.
+- **Verify infrastructure before acting on documentation.** Ping IPs before SSH, check services before connecting. Docs go stale faster than code.
+
+### Communication
+- **Voice opinions.** Push back when the user's direction seems wrong. "I think there's a better approach because..." is more valuable than silent compliance.
+- **Use the question tool for design choices.** Don't make assumptions about architecture or design — ask explicitly when multiple valid approaches exist.
+
+## Recording New Feedback
+
+When a correction happens:
+
+```markdown
+---
+name: feedback_no_mock_database
+description: Integration tests must use real database, not mocks
+type: feedback
+---
+
+Integration tests must hit a real database, not mocks.
+
+**Why:** Prior incident where mocked tests passed but the production migration failed.
+Mock/prod divergence masked a broken migration.
+
+**How to apply:** When writing tests that touch database operations, always use a
+test database instance. Never mock the database layer in integration tests.
+```
+
+Key elements:
+- **The rule itself** (lead with this)
+- **Why** — the reason, often a past incident or strong preference
+- **How to apply** — when/where this guidance kicks in
+
+## Recording Confirmed Approaches
+
+Corrections are obvious. Confirmations are quieter — watch for them:
+
+- "Yes, exactly" or "perfect, keep doing that"
+- Accepting an unusual choice without pushback
+- "The single bundled PR was the right call here"
+
+Save these too. If you only save corrections, you drift away from approaches the user has already validated.
+
+## Feedback vs Rules
+
+| Aspect | Rules (`.claude/rules/`) | Feedback (memory) |
+|--------|--------------------------|-------------------|
+| Scope | Project-wide | Often personal/contextual |
+| Authority | Highest (cannot override) | Advisory (can override freely) |
+| Creation | Deliberate, authored | Organic, from corrections |
+| Maintenance | Manual | Decays if unused |
+| Loading | Auto-loaded every session | Auto-loaded via MEMORY.md |
+
+In most projects, feedback memories ARE the rules — there are no `.claude/rules/` files. The governance comes entirely from accumulated corrections and confirmed approaches.
+
+## When Feedback Contradicts Rules
+
+If a feedback memory says "skip tests for quick fixes" but a rule says "always write tests," follow the rule. Feedback memories are subordinate to explicit rules (see the authority hierarchy).
+
+But in projects without explicit rules, feedback memories are the highest available authority after user instructions.