Home

atk — Developer Wiki

This wiki is for people who want to hack on atk itself — most importantly, adding a new tool to the menu. It documents how the codebase is put together, not how to use the app (see the README for that).

Start here

• Adding a New Tool — the practical, step-by-step page. If you only read one page, read this one.
• Architecture — how main.rs, tui/mod.rs, and a module's own mod.rs fit together; the App/Screen dispatch pattern every tool plugs into.
• TUI Conventions — the shared widgets (Input, buttons, tabs, modals, the History panel), color theme system, and keyboard/mouse conventions every screen follows so the app feels like one tool instead of ten bolted together.
• Config and Secrets — where each tool's settings live on disk and how passwords/API tokens get encrypted at rest.
• SSH and Remote Execution — the shared ssh_exec/ssh_tunnel helpers most tools build on (direct exec, batch exec, SSH-tunneled DB connections).
• CLI Subcommands — how a tool can also expose a scriptable, non-interactive atk <tool> ... CLI surface (SSH User Manager is the current example).

The one-paragraph mental model

atk is a single Rust binary. src/main.rs either launches the TUI (tui::run(), the default with no args) or dispatches a clap subcommand for scriptable use. The TUI itself (src/tui/mod.rs) is a small state machine: one Screen enum variant per tool, one Option<XyzScreen> slot per tool lazily constructed on first visit, and one match self.screen { ... } block each for tick, handle_key, handle_mouse, and draw that all do the same thing — forward to whichever screen is active. Every tool's actual logic (config file, network/SSH calls) lives in its own top-level module (src/<tool>/), completely decoupled from ratatui; the screen (src/tui/<tool>_screen.rs) is the only thing that touches both the tool's module and the TUI framework. That split is why adding a tool never touches another tool's code — only the handful of dispatch points in tui/mod.rs and home.rs need one new line each.