Skip to the library

Versioned CRM

From backup to process map

The process map enables analysis without production access; the new change path connects verifiable findings with review and controlled deployment.

Case study

Updated on October 12, 2026. The analysis pilot is preserved and distinguished from the subsequent multiuser deployment stage.

The second-stage leap

The backup answered what code existed. It did not explain how the business was organized, which functions made up a flow or how to check that a fix had been applied.

The second stage added three pieces:

Piece What it answers
Resource dictionary Which functions use each shared resource and what the blast radius is
Process tree Which flows exist and which functions make up each branch
Analysis contract How a branch should be analyzed and what evidence to deliver

Generated and curated

Data that changes is regenerated on every sync. The conceptual organization is expressed through rules maintained by people.

No manual lists of functions are written into the documentation: they go stale the next day. A rule absorbs new functions and the report flags those that do not fit any branch.

Unit of work: one branch

The process for a person or agent is deliberately bounded:

  1. Open a working copy of the repository.
  2. Pick a branch from the process tree.
  3. Follow the analysis contract.
  4. Deliver three artifacts.
Deliverable Purpose
manual-operativo.md Explain the flow in business terms
mejoras-propuestas.md Rank findings by consequence, anchored to file and line
validar.sh Turn every finding into an executable check

In the original test, the agent started from computed reports rather than a blind search across more than thirteen hundred functions. That size describes the inventory at the time, not an updated count. The advantage of the method is bounded context and repeatable analysis.

The limit that sustains quality

The analysis fixes visible defects; it does not redesign processes or propose broad migrations. On a platform where publishing is immediate, a large redesign of a flow that moves money needs another level of governance.

The restriction does not live only in the prompt: every finding that gets developed must be expressible as an automated check. If it cannot be verified, it is noted as a separate idea and not presented as a ready fix.

Verification without AI

When someone reports they fixed a finding, there is no need to pay for reasoning again to read the code. You run validar.sh against the current snapshot.

Prose goes stale; the check gets re-evaluated. This separation reduces supervision and keeps the report from becoming a frozen truth.

From finding to deployable proposal

The new stage adds continuity to the work: a verifiable finding can become a change proposal separate from the snapshot, pass through a pull request and reach an owner with deployment authority. The map helps choose where to look; the contract determines what evidence to deliver; the deployment path governs when writing is allowed.

These are different checks:

Check What it establishes What it does not establish
Finding check Whether the code satisfies a specific condition Whether the whole process works correctly
Comparison with the production baseline Whether drift is detected under normalized comparison since the proposal was prepared Changes erased by normalization, semantic equivalence or unchanged dependencies
Download after deployment Whether downloaded code matches what was sent under the implemented comparison Whether business effects are as expected

An idempotency fix, for example, can have a static check detecting its guard condition and still need a repeated-execution test to demonstrate that it does not duplicate effects. Having validar.sh improves review; it does not justify confusing code inspection with comprehensive validation.

The multiuser-stage documentation records controls tested with writes disabled and keeps the first real deployment from cambios/ pending. The full workflow is the direction implemented by the project, with that operational validation still open. The pilot below demonstrates analysis and its deliverables, not a subsequent deployment.

Pilot test

A branch with no previous manual was analyzed following only the contract. The agent delivered the three files and the priority findings were verified against the code.

The test found idempotency bugs, incomplete validations and external execution surface that needed review. The anonymization rules keep the problem categories, but do not publish the flow, the names or the client’s exact conditions.

The analysis also flagged as unconfirmed the points the API did not allow checking. That discipline was part of the success, not a limitation to hide.

Choosing the next step

For an unfamiliar flow, start with the map, contract and checks before preparing changes. Once a finding has evidence, use the function platform to organize the proposal and the separation of authorities to bound publication. A broad redesign or a condition that the snapshot cannot establish needs a different investigation; it should not be disguised as a fix ready to deploy.

The benefit

Diagnostic capability stopped depending on whoever knows the organization by heart. The core cost is generating the snapshot and reports; each team member can analyze a branch with their own tool and verify fixes without production access.

Keep going

← Back to the library