library-design-patterns

Use two-tier design: separate the core library logic from CLI wrapper interfaces. This pattern improves reusability, testability, and modularity by decoupling business logic from command-line concerns, enabling the library to be imported and used programmatically across the autonomous-dev ecosystem.

Implement security-first architecture with input validation, audit logging, and CWE-22/CWE-78-informed practices. Progressive enhancement lets you add validation incrementally without breaking existing code, while non-blocking enhancements allow graceful degradation when security checks fail.

Apply the two-tier pattern: keep the CLI as a thin wrapper around a core library. Document APIs with comprehensive docstrings, use separation of concerns to isolate CLI logic from library logic, and ensure the core remains importable independently for programmatic use.

Yes, use progressive enhancement and non-blocking enhancements. These patterns let you layer new functionality—including security checks and validation—incrementally. Code degrades gracefully when enhancements aren't available, preserving backward compatibility.

Document and mitigate CWE-22 (path traversal), CWE-59 (link following), CWE-78 (command injection), and CWE-117 (log injection). Security-first architecture embeds input validation and audit logging into design from the start, reducing exposure across all library consumers.

Separation of concerns isolates testability, reusability, and security logic. Libraries can be used in multiple contexts—CLI, imports, server plugins—without duplicating validation or audit logic. This design supports the modular, autonomous-dev plugin ecosystem.