Architecture

Architecture

Prev: Building Native C++ Plugins | Home | Next: Architecture Overview

This section explains how ReqPack is structured internally.

Goal is practical orientation rather than deep internal design history: where code lives, which component owns what, and how requests move through the system.

Reading Order

1. Architecture Overview
2. Execution Flow
3. Data, State, and Trust

What ReqPack Is Made Of

At a high level:

• CLI parses requests and config overrides.
• Registry knows plugins and registry metadata.
• Planner turns requests into an execution graph.
• Validator applies security policy and audit logic.
• Executor runs actions through plugins.
• Exporters handle audit, SBOM, and snapshot output.
• Remote runtime exposes the same command engine over sockets.

Dynamic plugin loading is Lua-based today. Native rqp plugin is built into rqp binary.

Repository Areas

• src/main/cpp: main implementation.
• src/main/include: public and internal headers.
• src/main/cpp/core and src/main/include/core: domain-oriented core folders such as config, registry, planning, execution, security, and remote.
• plugins/: local and built-in Lua plugin examples.
• tests/: unit, integration, and coverage-oriented tests.

Related Pages

• Architecture Overview
• Execution Flow
• Data, State, and Trust

Prev: Building Native C++ Plugins | Home | Next: Architecture Overview