Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/davidbuenov/dbv-specs-ops/llms.txt

Use this file to discover all available pages before exploring further.

Once the code works and tests pass, the SDD cycle does not ship immediately. The /code-simplify phase exists because working code is not the same as safe, maintainable code. This phase enforces two mandatory activities: a security audit and a refactoring pass. Neither is skippable, and neither is a courtesy — they are structural requirements of the cycle. The guiding principle is “clarity over cleverness”: if a simpler implementation achieves the same result, the simpler one is chosen. Complexity that cannot be justified is eliminated.

​
The Mandatory Security Review

The security review audits all code produced during /build against three specific checks. Each check addresses a category of risk that is disproportionately common in AI-generated code.

​
Check 1 — Prevent secret leakage

Scan all new and modified files for hardcoded API keys, passwords, tokens, and credentials. Secrets must live in environment variables (.env) and must never be committed to source control. The assistant verifies this explicitly — it does not assume the developer already checked.

​
Check 2 — Validate dependencies

Every imported package, library, or module introduced during /build must be verified as a real, published package in the official registry for its ecosystem (npm, PyPI, Maven, etc.).
AI models can suggest package names that do not exist — a risk known as dependency hallucination or slopsquatting. Attackers actively register these invented names in public registries to serve malicious code. A project that installs a hallucinated package is a compromised project. Every import added by the AI assistant must be manually confirmed to exist before shipping.See Agentic Engineering concepts for a deeper explanation of slopsquatting and how dbv-specs-ops mitigates it.

​
Check 3 — Sanitize and validate critical inputs

Review all endpoints, CLI interfaces, and other entry points that accept external input. Verify that:
  • Inputs are validated against expected types, lengths, and formats before processing.
  • Injection attack vectors (SQL injection, command injection, prompt injection) are mitigated.
  • Public-facing endpoints do not expose internal state or bypass authorization logic.

​
Refactoring rules

After the security review, the refactoring pass applies the “clarity over cleverness” principle:
  • Reduce cyclomatic complexity — break down functions that contain too many branching paths.
  • Eliminate dead code — remove commented-out blocks, unused imports, and stale variables.
  • Improve naming — identifiers should communicate intent without requiring a comment to explain them.
  • No debug artifacts — logs, breakpoints, temporary print statements, and TODO comments that belong to this task (not to tracked technical debt) are removed before the phase ends.
If during the simplify pass the assistant discovers improvements that are out of scope for the current task, they are recorded in task.md as Deuda Técnica (Technical Debt) — not silently fixed, and not silently ignored.

Build docs developers (and LLMs) love

Get started for freeTalk to us