TRIZ Problem Solver — Rust Edition

Systematic innovation methodology for Rust engineering problems.

Core Protocol

Contradiction-First Approach

1. STATE the problem in one sentence
2. IDENTIFY contradiction: "Improving [X] causes [Y] to worsen"
3. CHECK if contradiction is real or apparent
4. RESOLVE using separation principles
5. VALIDATE no new contradictions introduced

Ideal Final Result (IFR)

"The ideal Rust solution delivers all benefits with zero cost, zero unsafe, zero clones"

1. What is the ideal outcome? (no implementation details)
2. What prevents reaching it? (Rust constraints: ownership, lifetimes, traits)
3. Which constraints are real vs assumed?
4. Can the type system enforce correctness without runtime checks?

Inventive Principles (Software Edition)

Principles Applied to Rust

This table is the complete set the contradiction matrix below draws from. A resolution citing a number absent from this table has not applied a principle.

Contradiction Matrix (Software)

Improving            vs Worsening              → Principle
──────────────────────────────────────────────────────────────
Functionality        vs Complexity             → #1, #9, #15
Performance          vs Maintainability        → #7, #13, #17
Flexibility          vs Simplicity             → #6, #2, #3
Security             vs Usability              → #12, #4, #17
Scalability          vs Resource Cost          → #1, #13, #35

Rust-Specific Additions

Compile time         vs Runtime perf           → #13, #35
API ergonomics       vs Binary size            → #1, #15
Async surface        vs Blocking cost          → #1, #15
Genericity           vs Compile time           → #2, #6

Decision Workflow

Step 1: Frame Problem

Problem: [One sentence]
Current approach: [What you're doing]
Stuck because: [Why it doesn't work]
Rust constraints hit: [Ownership / Lifetime / Trait bounds / Async / Unsafe]

Step 2: Identify Contradiction

Improving: [Parameter that needs improvement]
Worsens: [Parameter that degrades]
Type: [Technical / Physical / Inherent]
Rust-specific: [Is the borrow checker the bottleneck?]

Step 3: Apply Resolution

Choose separation strategy:

• Time: Different behavior at different stages
  • Rust: OnceCell, Phased init, staged builder
• Space: Different behavior in different contexts
  • Rust: feature flags, #[cfg], target_arch
• Condition: Different behavior based on input type
  • Rust: trait objects, sealed traits, match
• System-level: Add component that resolves both
  • Rust: newtype wrapper, sidecar crate, separate binary

Step 4: Validate

✓ Original problem solved
✓ No new contradictions introduced
✓ Solution approaches IFR (minimal complexity added)
✓ `cargo clippy --workspace --all-targets --all-features -- -D warnings` passes
✓ `cargo nextest run --workspace` passes
✓ No `unsafe` without `// SAFETY:` rationale

Examples

Example 1: Compile Time vs Runtime Performance

Problem: Heavy generics in core crate cause slow dev builds
Contradiction: Genericity (improve) vs Compile time (worsen)
Apply: #2 Taking out → Extract hot-loop into runtime-dispatched `dyn Trait` crate
Result: Core crate compiles fast, hot loop dispatched at runtime

Example 2: API Ergonomics vs Binary Size

Problem: Convenience methods bloat the binary
Contradiction: API ergonomics (improve) vs Binary size (worsen)
Apply: #1 Segmentation → Feature-gate convenience methods, default off
Result: Users opt in to convenience, base binary stays small

Example 3: Async Surface vs Blocking Cost

Problem: Exposing async requires every caller to .await
Contradiction: Async surface (improve) vs Blocking cost (worsen)
Apply: #12 Inversion → Provide blocking wrapper that calls `tokio::runtime::Handle::block_on`
Result: Both sync and async callers served

Example 4: Security vs Usability (Auth)

Problem: Strong auth improves security but hurts UX
Contradiction: Security (improve) vs Usability (worsen)
Apply: #12 Inversion → Risk-based auth (challenge only suspicious sessions)
Result: Both sync and async callers served

Example 5: Agent Instruction Optimization

Problem: More instructions improve reliability but consume context
Contradiction: Completeness (improve) vs Token limits (worsen)
Apply: #4 Asymmetry → Heavy knowledge in `references/`, load lazily
Result: Reliability maintained, context efficiency improved

Example 6: Lifetime vs Extensibility

Problem: Adding a borrow makes the trait less flexible for downstream impls
Contradiction: Borrow safety (improve) vs Extensibility (worsen)
Apply: #7 Nesting → Use `Cow<'_, T>` or lifetime-generic type parameter
Result: Borrow enforced where needed, flexible where not

Integration with Other Skills

• task-decomposition: Use TRIZ to identify contradictions before decomposing
• agent-coordination: Apply IFR to coordination strategy selection
• iterative-refinement: Use contradiction analysis to guide refinement cycles
• triz-analysis: Audit first, then solve
• anti-ai-slop: Validate the TRIZ solution isn't boilerplate-heavy

Quality Checklist

• Contradiction explicitly stated before solution
• IFR defined before implementation
• Solution verified against contradiction matrix
• No new contradictions introduced
• Approaches ideal state (minimal added complexity, idiomatic Rust)
• cargo clippy and cargo nextest pass

Rationalizations

Red Flags

• Proposing a solution without explicitly stating the contradiction first
• Skipping IFR definition and jumping to implementation details
• Introducing new contradictions without validating the solution
• Using unsafe to bypass the borrow checker instead of redesigning
• Adding unwrap(), clone(), or Box<dyn Trait> as the first solution

Reference Files

• The Rust Performance Book
• Rust API Guidelines
• Rustonomicon

Related Skills

• triz-analysis - Audit first, then solve
• task-decomposition - Break complex problems into sub-tasks
• goap-agent - Use TRIZ in Phase 1 (Analyze) of GOAP
• anti-ai-slop - Audit rewritten code for boilerplate