triz-analysis

TRIZ Analysis — Rust Edition

Systematic innovation audit for Rust codebases, workspace architectures, and CI/CD pipelines.

When to Use

• Auditing a Rust workspace for technical contradictions
• Reviewing scripts/, CI pipelines, or Cargo.toml manifests for hidden trade-offs
• Analyzing an architecture for scalability vs. complexity bottlenecks
• Performing a swarm-based TRIZ audit on a Rust project
• Reviewing unsafe boundaries, async vs. sync, or tokio::spawn vs. spawn_blocking choices

Input Requirements

• Target Scope: The specific directory, pipeline, or framework to analyze (e.g., crates/, scripts/, .github/workflows/, agent-coordination).
• Language Focus: Rust-specific patterns (ownership, async, traits, lifetimes).

Output Convention

All agent-generated analysis must be written to analysis/ using:

analysis/triz-<scope>-YYYY-MM-DD.md

Example: analysis/triz-scripts-2026-06-18.md

Audit Process

1. SCOPE SCAN: Examine the target scope for existing pain points or trade-offs.
2. CONTRADICTION DISCOVERY: Identify technical contradictions: "Improving [X] in this scope causes [Y] to worsen."
3. PRINCIPLE MAPPING: Map discovered contradictions to TRIZ inventive principles.
4. INNOVATION ROADMAP: Propose specific Rust-idiomatic changes based on TRIZ resolutions.
5. REPORT: Document findings in analysis/.

Core Protocol

Contradiction-First Approach

1. SCAN the scope
2. IDENTIFY contradiction: "Improving [X] causes [Y] to worsen"
3. CHECK if contradiction is real or apparent
4. RESOLVE using separation principles
5. DOCUMENT findings in analysis/

Ideal Final Result (IFR) for Rust Audits

"The ideal Rust system performs its function with zero unsafe, zero clones, zero contention"

1. What is the ideal outcome for this scope?
2. What prevents reaching it? (current type/ownership/CI constraints)
3. Which constraints are real vs assumed?
4. Could the borrow checker enforce correctness instead of runtime checks?