End-to-end scan command pipeline for Detektor CLI

[meisterware-admin]

Overview

Implement the end-to-end scan execution pipeline for the detektor scan CLI command.

This issue integrates the core components developed in earlier issues into a single deterministic execution flow:

• CLI command invocation
• artifact discovery and loading
• rule engine execution
• finding aggregation
• OpenPAKT report generation

The goal is to enable a complete Detektor scan that produces a valid OpenPAKT report from a repository or artifact target.

---

Motivation

While individual components such as the CLI, artifact loader, rule engine, and report writer are implemented separately, Detektor requires a unified pipeline that connects these components into a functioning scanner.

Without this integration:

• the CLI cannot execute a full scan
• rules cannot evaluate artifacts
• findings cannot be aggregated
• reports cannot be generated

The end-to-end pipeline transforms Detektor from a collection of components into a working security scanner capable of producing OpenPAKT reports.

---

Proposed Approach

Implement a scan orchestration pipeline triggered by the CLI scan command.

High-level execution flow:

detektor scan <target>
        ↓
Artifact discovery and loading
        ↓
Rule engine execution
        ↓
Finding aggregation
        ↓
OpenPAKT report generation
        ↓
Report written to output file

The scan pipeline should perform the following steps:

1. Accept the scan target path from the CLI.
2. Load artifacts using the artifact loading system.
3. Execute detection rules through the rule engine.
4. Collect findings generated by rules.
5. Generate an OpenPAKT report using the report writer.
6. Write the report to an output file.

Example CLI usage:

detektor scan .

Expected output:

detektor-report.json

The implementation should focus on producing a deterministic pipeline for the v0.1 MVP.

---

Alternatives Considered

1. Implement components without a unified pipeline

Each component could be tested individually without full integration.

However, this approach would delay validating the real behavior of the scanner.

2. Implement pipeline logic inside the CLI command

The pipeline could be implemented directly within the CLI command handler.

However, separating orchestration logic into a dedicated scanner pipeline improves maintainability and future extensibility.

---

Risks and Trade-offs

Pipeline rigidity

If the initial pipeline design is too rigid, adding new processing stages in later versions may require refactoring.

Designing the pipeline as a sequence of modular stages can reduce this risk.

Error handling complexity

Integration of multiple components introduces potential failure points.

The pipeline should include basic error handling and reporting.

Performance considerations

Scanning large repositories may require performance optimizations in future versions.

For v0.1, correctness and determinism should be prioritized over optimization.

---

Open Questions

• Should the scan pipeline support progress output in the CLI?
• Should Detektor support scanning multiple targets in a single invocation?
• Should the report be written only to a file or also printed to stdout?
• Should scan execution support configurable options in future versions?

---

Examples

Example CLI usage:

detektor scan ./repo

Expected behavior:

1. The scanner discovers artifacts in the repository.
2. Detection rules evaluate the artifacts.
3. Findings are collected and normalized.
4. An OpenPAKT report is generated.
5. The report is written to detektor-report.json.

---

Next Steps

If this proposal is accepted:

1. Implement the scan orchestration pipeline.
2. Integrate artifact loading into the pipeline.
3. Connect the rule engine to artifact inputs.
4. Aggregate findings produced by rules.
5. Invoke the OpenPAKT report writer.
6. Output the generated report file.