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.

The /ship phase closes the development cycle with a set of mandatory rituals: documentation updates, a memory gate, semantic versioning, CHANGELOG finalization, and a structured Git commit proposal. These steps exist because a shipped feature with no documentation trail, no version bump, and no commit message is a feature that cannot be maintained, audited, or rolled back. Shipping is not pushing code — it is completing the record.

​
Documentation updates

Before anything else, the assistant updates the project’s human-readable artifacts to reflect the completed work:
  • README.md — updated to reflect the current state of the project, including any new features, changed setup steps, or updated script usage.
  • walkthrough.md — completed with a summary of the work performed in this cycle: what was built, what decisions were made, and what changed from the original specification.
  • task.md — the completed task is marked as done, and a brief “Snapshot de Contexto” is written so the next session can resume without losing the thread.

​
Memory Gate (MANDATORY)

Before the task is considered closed, the assistant must print a <memory_update_proposal> XML block in the chat. This is the Memory Gate: it makes persistent knowledge explicit rather than leaving it buried in conversation history. If there are lessons learned, architectural decisions, or technical insights worth preserving, use the appropriate section — Lecciones for bugs and lessons, Log de Decisiones Técnicas for ADRs, or Mapa de Relaciones for the module map: 
<memory_update_proposal>
  <section>Lecciones</section>
  <entry>El bug X ocurre por Y: al renovar la sesión, si el cliente reintenta
  antes de que la BD confirme la escritura anterior se produce una inconsistencia
  de estado. Solución: envolver el upsert en una transacción atómica.</entry>
</memory_update_proposal>
If this cycle produced no new lessons or architectural decisions, the assistant prints: 
<memory_update_proposal>none</memory_update_proposal>
<reason>
  Este ciclo solo fue un refactor menor de estilos CSS sin decisiones
  arquitectónicas nuevas ni lecciones aprendidas.
</reason>
Printing none without a <reason> is not acceptable. The absence of new knowledge must be justified, not assumed.

​
Agent Readiness Verification (web projects)

For web projects with Agent Readiness (Web) active, the assistant verifies that the deployment configuration correctly injects the Link HTTP header with all three required relations: 
Link: </.well-known/agent-skills/index.json>; rel="agent-skills",
      </.well-known/mcp.json>; rel="mcp-server-card",
      </.well-known/api-catalog>; rel="api-catalog"
This verification checks the actual hosting configuration file (e.g. firebase.json, netlify.toml) — not just that the files exist on disk.

​
Cross-platform start/stop scripts

The assistant generates two pairs of execution scripts in the project root, always — regardless of stack:
ScriptPlatform
start.cmd / stop.cmdWindows
start.sh / stop.shmacOS / Linux (with chmod +x applied)
For Python projects, these scripts must activate and deactivate the local venv automatically. The README.md must document how to use all four scripts.

​
Semantic versioning

The assistant presents a versioning prompt to the developer:
La versión actual es X.Y.Z. ¿Qué tipo de cambio fue este? [1] Patch (X.Y.Z+1) — solo corrección de bugs [2] Minor (X.Y+1.0) — nueva funcionalidad, sin romper nada ✅ recomendado [3] Major (X+1.0.0) — cambio importante o rediseño [4] Sin cambio de versión — solo docs o ajustes menores
The developer’s selection determines the new version number used in the CHANGELOG, the Git tag, and the README.

​
CHANGELOG finalization

With the version number confirmed, the assistant moves all entries from the [Sin publicar] (Unreleased) section to a new versioned section with today’s date: 
## [1.2.0] - 2025-07-10

### Added
- Endpoint POST /sessions with atomic upsert and JWT validation

### Fixed
- Race condition in session renewal when refresh_token arrives expired
The comparison links at the bottom of CHANGELOG.md are also updated to reference the new tag.

​
Git commit and tag

If the project uses Git, the assistant proposes a commit message in Conventional Commits format and creates a version tag: 
# Proposed commit message:
feat: add session management with atomic upsert (v1.2.0)

# Create the version tag:
git tag v1.2.0
The assistant suggests the push command but does not execute it. The developer must run the push manually:
git push origin main --tags
This ensures the developer retains explicit control over what leaves the local environment.

Build docs developers (and LLMs) love

Get started for freeTalk to us