Decouple CLI as internal developer interface

[BytecodeBrewer]

Goal

Keep the CLI as an internal developer/power-user interface while separating all core logic from CLI-specific input/output.

Why

The long-term product interface should be GUI/frontend-based. The CLI can remain useful for development, debugging, experiments and advanced workflows, but it should not define the main user experience or architecture.

Scope

• Identify which current CLI features are useful for development
• Move reusable logic into services/modules outside CLI code
• Keep CLI input/output thin
• Avoid presenting CLI as the main product interface in README
• Document how maintainers can run the CLI locally

Acceptance criteria

• Core conversion/data logic can be used without CLI
• CLI calls reusable services instead of owning business logic
• CLI is documented as developer/internal interface
• GUI/frontend can reuse the same service layer
• README does not describe CLI as the long-term main interface

Notes

The CLI may offer more advanced/dev-oriented options than the GUI, but it should stay hidden from normal user-facing project positioning.

Note

Priority: Low
Type: Recactor / Architecure
Area: CLI / Application Architecture