Components

This page describes the current technical building blocks of Divekit CLI and how responsibilities are split in the codebase.

Components Overview

graph TB
    CLI["cmd/divekit + internal/cmd"]
    SHELL["shell / input / output / middleware"]
    SERVICE["service layer"]
    CONFIG["repository/config + project"]
    PROVIDER["repository/provider"]
    TEMPLATE["templating + individualizer"]
    SCRIPT["scripting + run"]
    REPORT["report + passcheck + overview"]
    INFRA["infrastructure + secrets + filesystem + concurrency"]

    CLI --> SHELL
    CLI --> SERVICE
    SERVICE --> CONFIG
    SERVICE --> PROVIDER
    SERVICE --> TEMPLATE
    SERVICE --> SCRIPT
    SERVICE --> REPORT
    SERVICE --> INFRA

Current Module Roles

CLI and Command Layer

• cmd/divekit: Cobra command definitions and help text
• internal/cmd/divekit: command handlers and command-specific execution logic
• internal/cmd/middleware: shared setup, error rendering, and execution wrapping

Shell and Interaction Layer

• internal/shell/*: logging, output formatting, prompts, progress rendering, and TTY-aware interaction
• internal/context: runtime context such as interaction mode

Service Layer

• internal/service: orchestration for configuration, distribution, diagnostics, scripting, and related workflows
• this is where command handlers usually delegate cross-cutting logic

Configuration and Project Resolution

• internal/repository/config: file loading, persistence, compatibility handling, and path resolution
• internal/project: project discovery and root detection
• internal/constants: canonical file names, target names, and standard paths

Repository Provider Layer

• internal/repository/provider: remote-system abstraction
• GitLab is the primary backend, but commands are structured around provider-facing operations rather than raw API calls everywhere
• indexing and retry support also live under internal/repository

Templating and Individualization

• internal/templating/*: token replacement, variable handling, solution deletion, detection utilities, and individualization logic
• this is the core of content customization during distribute

Scripting and Extensions

• internal/scripting/*: runtime contracts and language-specific execution helpers
• divekit run uses this area to execute extensions across fetched repositories

Reporting and Evaluation-Pipeline Consumers

• internal/cmd/report: report generation
• passcheck and overview build on remote state plus generated artifacts
• plugin-produced report artifacts feed into this part of the system

Infrastructure

• internal/infrastructure/*: filesystem helpers, secret storage, concurrency primitives, and local data helpers
• this keeps OS- and environment-specific concerns out of higher-level command logic

Design Notes

1. Divekit is CLI-first. There is no active Web UI layer in the current architecture.
2. Configuration resolution and templating are core subsystems, not incidental helpers.
3. Evaluation pipeline and plugin support are layered on top of the same configuration and provider primitives used by normal distribution flows.