31 lines
1.5 KiB
Markdown
31 lines
1.5 KiB
Markdown
|
# Cross-Project Learning & Reusable Intelligence
|
||
|
|
|
||
|
|
### What Transfers Well
|
||
|
|
|
||
|
|
| Type | Transferability | Example |
|
||
|
|
|------|----------------|---------|
|
||
|
|
| **Problem-solving patterns** (abstract) | ✅ High | "When implementing OAuth, these are the common pitfalls and the architecture that avoids them" |
|
||
|
|
| **Code templates & scaffolding** | ✅ With adaptation | Proven auth module structure, tested payment integration pattern |
|
||
|
|
| **Learned pitfalls** | ✅ High | "When integrating Stripe, these edge cases around webhooks most implementations miss" |
|
||
|
|
| **Project-specific conventions** | ❌ Does not transfer | Architectural decisions are contextual |
|
||
|
|
| **Domain logic** | ❌ Does not transfer | Business rules are project-specific |
|
||
|
|
|
||
|
|
### The Optimal Architecture: A Pattern Library
|
||
|
|
|
||
|
|
Each pattern includes:
|
||
|
|
- Description of the problem it solves
|
||
|
|
- The approach and tradeoffs
|
||
|
|
- Common pitfalls
|
||
|
|
- Verification tests
|
||
|
|
- Reference implementation
|
||
|
|
|
||
|
|
### Growth Through Extraction, Not Manual Curation
|
||
|
|
|
||
|
|
When a task completes with high quality (first-attempt success, no subsequent modifications, clean review), flag it as a **candidate for pattern extraction.** A dedicated pass determines whether the solution embodies a generalizable pattern.
|
||
|
|
|
||
|
|
### The Critical Constraint
|
||
|
|
|
||
|
|
Patterns should be **descriptive, not prescriptive** — "here's an approach that has worked well, with these tradeoffs" not "always do it this way." Grok adds an overfitting guard: require **3+ project examples** before promoting to reusable.
|
||
|
|
|
||
|
|
---
|