Describe tu proceso de ventas a tu agente de codificación; sé dueño del CRM que construye.
Un framework de código abierto que Claude Code, Codex y Gemini CLI usan para generar una aplicación de CRM como código que tú posees: flujos de trabajo deterministas, aprobaciones humanas sujetas a políticas, auditoría y trazabilidad integradas.
El nombre está elegido y el dominio registrado. npm create accordo crea un proyecto funcional a partir del publicado create-accordo@0.1.0; el paquete accordo en sí mismo sigue siendo una reserva de nombre vacía 0.0.1 — nada instala el framework como biblioteca — y el ámbito @accordo está reclamado y deliberadamente vacío. No se ha realizado ningún examen de marcas registradas, y el proyecto no se puede desplegar en producción. Lo que eso significa exactamente está en Dónde se detiene, que merece la pena leer antes del resto.
Business request
↓ "Renewals of €50,000 or more need a manager's sign-off."
Claude Code / Codex
↓ reads AGENTS.md · 12 skills · MCP · `crm app inspect`
Modules + deterministic workflows + versioned policy
↓
API + Admin + trace + audit — in your repository, as code you reviewCRM personalizado: cuando el proceso comercial es el producto y el resultado debe ser código revisable en lugar de configuración dentro del runtime de otra persona.
Customer Hub: cuando «hub» significa una única cadena local de registros comerciales con acciones gobernadas. Accordo no ingiere fuentes ni resuelve identidades de clientes como un CDP.
Smart CRM: cuando un agente de codificación debe componer la aplicación mientras una política versionada y humanos designados conservan las decisiones de negocio. Es software construido por agentes, no un tomador de decisiones autónomo.
CDP + CRM: cuando un CDP externo gestiona la ingesta, la resolución de identidades y las audiencias, y Accordo posee la capa de proceso CRM determinista a su lado. Accordo no incluye ningún CDP, conector, importador ni runtime de sincronización.
Esos términos adyacentes son rutas de recuperación, no afirmaciones de capacidad adicionales. El mapa de recomendaciones verificado vincula cada uno a lo que el framework demuestra y dónde se detiene.
Related MCP server: API Creator MCP
Todo CRM acaba pidiéndote que adaptes tu proceso a su modelo. Las dos escapatorias habituales tienen un coste:
Configurar una plataforma — rápido de empezar, y tu personalización vive como metadatos dentro del runtime de otra persona. Cuando llega el techo, haces un fork de un monorepo.
Construir desde cero — libertad total, y cada equipo vuelve a derivar la validación, la semántica de pipeline, las aprobaciones y la auditoría. Normalmente tarde, normalmente bajo presión.
Este framework es la tercera opción: un agente genera la aplicación, y el framework proporciona las partes que los equipos siempre hacen mal cuando se acerca una fecha límite. La prueba que cualquier desarrollador puede aplicar es «si este proyecto desaparece mañana, ¿con qué me quedo?» Aquí la respuesta es: una aplicación Node en tu repositorio, sin dependencias de runtime de terceros y un archivo SQLite que cualquier cliente puede abrir.
Cada línea siguiente está vinculada a una prueba fusionada. El registro completo — la afirmación, la evidencia y el límite que la acompaña — está en site/claims.json, y la disciplina de revisión que hay detrás está en docs/QUALITY_GATES.md.
Capacidad | Dónde se detiene | Evidencia |
Un manifiesto de módulo se convierte en una migración, servicio, recurso REST, método SDK y pantallas de Admin sin código de página | solo CRUD generado: los flujos de trabajo y las aprobaciones de objetos personalizados siguen escribiéndose a mano |
|
Los objetos generados se referencian entre sí: clave foránea, validación de destino en runtime, selector de Admin | solo many-to-one entre generados; sin many-to-many, colecciones inversas ni cascada |
|
Política de aprobación determinista: una renovación en o por encima del umbral espera a un humano designado | el objeto de renovación integrado y un único umbral de valor |
|
Un agente no puede tomar la decisión de aprobación del humano — afirmado por una prueba, no por una convención | el actor se afirma, no se autentica; esto se sostiene contra un agente honesto, no contra un atacante |
|
Las oportunidades avanzan por etapas de pipeline code-first bajo una acción autoritativa del servidor — el cliente pide, el servidor decide | probado en el módulo Opportunity integrado; no se reivindican pipelines configurables para objetos personalizados generados |
|
Captura de leads, enriquecimiento, scoring versionado explicable, enrutamiento determinista, cualificación, conversión | el enriquecimiento se ejecuta contra un proveedor de fixtures; no hay ninguna fuente de datos real conectada |
|
Cotizaciones compuestas con precio de servidor, versiones de cotización inmutables, política de descuentos versionada con aprobación | proveedor de catálogo de fixtures; céntimos enteros sin FX — las monedas nunca se suman |
|
Sobre de firma → eventos verificados → evidencia de artefacto firmado → exactamente un Order inmutable | proveedor de sobres de firma de fixtures, clave webhook solo de prueba, hash de artefacto notificado por el proveedor |
|
Activación de Order en Contract, versión inmutable, Subscription y obligaciones pendientes | nada factura, renueva, modifica ni cancela; no hay planificador |
|
Traspaso de la entrega a un proyecto con paquetes de trabajo, hitos y un socio opcional; ejecución impulsada por humanos | nada planifica, asigna personal, acepta ni factura; los entregables no existen como objetos |
|
Evidencia de tiempo y gastos de solo añadir, costeada por una política versionada, con una estimación de contribución reproducible | deliberadamente no es un margen: sin reconocimiento de ingresos, sin COGS, sin ARR/MRR, sin FX |
|
Un paquete de dominio creado por el cliente se adjunta y desadjunta sin que cambie la huella del kernel | el andamiaje que lo crea escribe un paquete vacío y nada más; sin registro, sin publicación, sin sandboxing: el código del paquete se ejecuta con la autoridad del host |
|
| no inventa lógica de negocio, no compone nada, no verifica unicidad de identidad global y no instala ni publica nada |
|
| nunca abre la base de datos, contacta con un proveedor ni lee un secreto — y lo dice en su propia salida |
|
| un contrato documental, no un planificador ni un runtime; nada ejecuta un plan |
|
| la cobertura la reivindica un escenario en lugar de descubrirse; no promueve ninguna fila, no maneja ningún navegador y cada ejecución habla de una sola composición |
|
Los módulos generados evolucionan mediante revisiones explícitas y migraciones nombradas de solo añadir | solo código fuente: lo que aplicó una base de datos concreta no se puede saber desde aquí |
|
Toda la suite se ejecuta en cada push, junto con la prueba de humo. Cuántas pruebas eran y el commit en el que se midieron están en site/claims.json bajo measuredAgainst — el único lugar de este repositorio en el que se anota un recuento de pruebas, y el único en el que npm run gtm:check permitirá que aparezca un número.
Node.js 22.16 o más reciente. No hay dependencias de runtime de terceros ni paso de compilación.
npm run tour # compose the whole application and inspect it
npm run verify # source checks, then the whole test suite
npm run falsify # break five rules on purpose and watch the suite catch them
npm run demo # the approval slice, end to end
npm run dev # http://localhost:4000npm run tour es la forma más rápida de ver qué es esto realmente. La composición predeterminada del repositorio está deliberadamente vacía — un proyecto escribe la composición que quiere —, así que crm app inspect en un clon recién hecho no informa de nada. El tour ejecuta el instalador de inicio (el mismo que CI ejecuta en cada push) en un directorio que conserva y, a continuación, inspecciona el resultado:
modules 76 resources 71 policies 7
packages 9 actions 64 providers 1
production posture — local development only: no authentication, tenancy or RBAC
exists, and actor headers are not identityTermina con las once cosas que el inspector dice que no puede ver, porque un recorrido que solo muestra
la mitad buena no merece la pena ejecutarse. npm run tour -- --keep ./demo deja el proyecto para explorar;
--json imprime un recibo legible por máquina.
npm run falsify es la otra dirección. Un recuento de pruebas dice cuánto se escribió; no
dice qué tendría que salir mal para que una prueba siguiera en verde. Así que esto elimina una regla a la
vez — la protección del actor humano en las aprobaciones, el límite del umbral de aprobación, la verificación
de la firma del webhook, la inmutabilidad de la versión de la política, la regla de que un módulo totalmente
gestionado no genera escritura pública — ejecuta la suite que debería defenderla y nombra la prueba que la
detectó. Se niega a ejecutarse sobre cambios sin confirmar y restaura todos los archivos que toca. Cualquier
cosa que sobreviva se imprime como una brecha, porque esa es la salida útil
(docs/FALSIFY.md, tests/falsify.test.js).
npm run demo crea dos renovaciones y scripts/smoke.js lo verifica en cada push:
20 000 € → pasa directamente a Propuesta.
80 000 € → se detiene en Aprobación Pendiente hasta que un gestor decida.
Claude Code lee CLAUDE.md, .mcp.json y .claude/skills/. Codex lee AGENTS.md
y .codex/config.toml. Ambos están registrados en el repositorio y conectados entre sí.
Read AGENTS.md, PRODUCT.md and docs/PROJECT_STATUS.md.
Run npm run crm -- app inspect --json.
Tell me which parts of my commercial process this already supports, and which it does not.Un arnés solo necesita: ejecutar un comando, leer stdout, leer el código de salida, analizar JSON y leer
y escribir archivos. Sin servidor MCP, sin red, sin credenciales, sin base de datos, sin proceso de larga
duración — docs/AGENT_HARNESS_COMPATIBILITY.md.
npm run crm -- app inspect --json # what this application contains
npm run crm -- solution check plan.json # is this plan still valid against itLos códigos de salida son el contrato: 0 válido · 1 problemas, el informe aún se imprime · 2 ilegible.
El servidor MCP se ejecuta sobre stdio (node --no-warnings packages/mcp/bin/server.js) y expone
inspección del proyecto, listado de oportunidades, solicitudes de cambio de etapa, decisiones de aprobación,
trazas de ejecución y andamiaje de módulos. Las herramientas que generan código y las destructivas están en
modo de prueba en seco a menos que pases una bandera de aplicación explícita (tests/mcp.test.js,
tests/scaffold.test.js — docs/MCP.md).
Es solo stdio y solo local: no hay ningún endpoint MCP alojado o autenticado, y el servidor
hereda la autoridad del proceso que lo inicia.
Lee esto antes de evaluar cualquier cosa anterior. docs/benchmarks/CRM_JTBD_MATRIX.md hace seguimiento de
cada trabajo de CRM con un vocabulario de estado conservador en el que no compatible es el valor por
defecto y se requiere evidencia para salir de él.
Sin autenticación, multiinquilino ni RBAC. El servidor es solo para desarrollo local; una cabecera de actor es una afirmación, no una identidad. No lo expongas a una red.
Solo SQLite. PostgreSQL está en la vía de la Columna Vertebral de Producción y no está implementado.
El benchmark de compilación no se ha ejecutado. No existe una Tasa de Compilación de Agente Exitosa. Cualquier
porcentaje atribuido a este proyecto es inventado —
docs/strategy/CRM_BUILD_BENCHMARK.md es el
protocolo, no un resultado.
Sin programador, sin recordatorios, nada en un temporizador. Las Tareas de Seguimiento y una
línea de tiempo de Actividad existen como un único modelo compartido (docs/WORK_TASKS.md) y una persona
mueve cada una de ellas: una fecha de vencimiento no cambia ningún estado, no existe nada recurrente, nada se
asigna o notifica, y los períodos de aviso de renovación se registran y nunca se activan.
Sin integraciones de correo electrónico, calendario o marketing. Existe un contrato de proveedor de notificaciones; ningún adaptador envía nada a nadie.
Sin importación, exportación, deduplicación, fusión, edición masiva, vistas guardadas ni búsqueda global. Requisitos básicos en todo CRM comercial, y ninguno de ellos tiene un hito todavía.
Todavía no puedes poner datos reales de clientes en esto. Sin autenticación, sin multiinquilino, sin exportación
y sin vía de borrado — por lo que una solicitud de acceso o eliminación de un interesado no puede atenderse con esto.
docs/strategy/DATA_GOVERNANCE.md es solo diseño. Lo único que se sostiene: la puntuación de clientes potenciales es
determinista, versionada y explicable, no el juicio de un modelo sobre una persona.
Esto es un marco de trabajo, no un producto al que te suscribes. No hay CRM alojado, ni nivel gratuito, ni cuenta. La salida es una aplicación que tú ejecutas.
La propiedad significa código fuente incorporado: no hay dependencia del marco de trabajo que actualizar.
npm create accordo — el publicado create-accordo@0.1.0 — genera un proyecto que arranca,
informa valid desde app inspect y sale con 0 desde project doctor, copiando el código fuente del
marco de trabajo en él; el mismo arranque se ejecuta desde un checkout
(node packages/create-accordo/bin/create-accordo.js <dir> --apply, sin instalación, sin red —
tests/project-bootstrap.test.js). Lo que el registro te entrega es el generador, no el
marco de trabajo: el paquete accordo es una reserva de nombre 0.0.1 vacía, deliberadamente. El
marco de trabajo se incorpora al proyecto, por lo que eres dueño del resultado por completo — y actualizar significa
fusionar, no subir una versión.
packages/core/ the runtime platform: registry, services, workflow engine, audit
packages/modules/ CRM domain primitives
packages/domains/ optional domain packages (contracts, delivery) on a public contract
packages/mcp/ tools and context exposed to coding agents
apps/ API server and generated AdminEl agente nunca escribe en una tabla de base de datos. Llama a métodos de servicio y flujos de trabajo
con nombre, que preservan la validación, la identidad del actor, la política, la traza y la auditoría — ARCHITECTURE.md.
Lee esto | Para |
las reglas que un agente debe seguir antes de cambiar código | |
qué es y qué no es el producto | |
el modelo técnico y sus reglas de extensión | |
el registro de decisiones, ADR-001 … ADR-020 | |
qué es cierto en el repositorio hoy | |
cada trabajo de CRM, su estado y su evidencia | |
la disciplina de revisión, incluidas las categorías de revisión adversarial | |
categoría, posicionamiento, hoja de ruta, métricas | |
cómo llega esto a la gente, y qué depende de un humano |
MIT, confirmado por ADR-023.
Answer "can this framework do X?" against the CRM jobs-to-be-done index. Returns the matching jobs with their status (not supported / partially supported / technically supported / validated end to end), the tests that prove them, and an explicit answer when the truth is that the job is not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | The job in plain words, or a JTBD id such as JTBD-CO-01. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by detailing output semantics: it returns statuses (not supported / partially supported / technically supported / validated end to end), supporting tests, and an explicit answer when not supported. This goes beyond annotations to set expectations about the response shape and edge-case handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence description is dense with information, front-loading the core question and then detailing the output types. It is not overly verbose and conveys a lot in few words. A slight deduction for not being even more compact, but it remains appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with one required and one optional parameter, the description explains what the tool returns, including the status taxonomy and the explicit handling of unsupported jobs. It mentions tests as evidence, which provides completeness. There is no output schema to compensate for, so the description covers the essential aspects, though it could have mentioned pagination or limit behavior, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'query' fully, including an example, and 'limit' with constraints. Description coverage is 50%, and the description does not elaborate on parameters, but the schema already covers the main fields. The phrase 'against the CRM jobs-to-be-done index' adds retirement domain context to the query parameter. However, 'limit' remains semantically thin, and no new parameter information is provided in the description, so it neither helps nor hurts beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Answer') and identifies a precise resource ('the CRM jobs-to-be-done index'). It clearly differentiates the tool by describing the query format ('can this framework do X?') and enumerates the kind of results (jobs with statuses, tests, explicit answer for unsupported). This distinguishes it from generic search or capability tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: answering capability questions about a framework against a CRM index. However, it does not explicitly mention when to use this over siblings like get_capability or search_docs, though the specialized index and status taxonomy imply a niche. It lacks explicit exclusions or alternative guidance but provides clear contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a capability from the claims ledger by id (C-nn), by standing-limitation id (L-nn), or by topic. Every capability is returned together with the evidence that proves it and the limitation that bounds it — this tool cannot return one without the other.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A claim id such as C-01, or a standing limitation id such as L-01. | |
| limit | No | ||
| topic | No | Free text, when the id is unknown. Matches claims and limitations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: every capability is returned with its proving evidence and bounding limitation, and the tool cannot return one without the other. This is useful but does not describe not-found behavior or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the first sentence stating purpose and lookup modes. The second sentence adds a valuable invariant, though the dash clause 'this tool cannot return one without the other' slightly restates the preceding point rather than adding new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read-only lookup: it identifies resource, lookup modes, and a key return invariant. However, with no output schema and one undocumented parameter (`limit`), it should clarify parameter interaction and behavior when no capability is found; it also does not offer guidance relative to the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%; id and topic are documented in both schema and description, but the description adds little beyond what the schema already provides. The `limit` parameter is not explained semantically, and the description does not clarify whether id and topic are mutually exclusive or can be combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resolve' with a clear resource ('capability from the claims ledger') and names three supported lookup paths: claim id (C-nn), standing-limitation id (L-nn), or topic. It also distinguishes this from siblings like check_job and search_docs by emphasizing the claims-ledger domain and the evidence/limitation pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates when to use the tool by specifying lookup by id (C-nn), limitation id (L-nn), or topic. It implies topic is useful when the id is unknown, though it does not explicitly name alternatives like check_job or search_docs or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across this framework's documentation set (README, AGENTS, ARCHITECTURE, PRODUCT, DECISIONS and everything under docs/). Returns the file path, the nearest heading and an excerpt for each hit. Read-only; it serves documentation, never customer records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words that must all appear on the same line. Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output format (file path, nearest heading, excerpt per hit) and explicitly labels the tool as read-only and non-customer-data, matching the annotations. No contradictions or surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential information without unnecessary fluff. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, what it returns, and its read-only nature. It doesn't cover edge cases or error handling, but for a straightforward search tool, this is adequate. Minor lack of detail about the 'nearest heading' concept, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any information about the parameters 'query' and 'limit' beyond what is already in the schema. Since the schema already describes both parameters, the description adds no value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Keyword search') and specific resource ('this framework's documentation set'), listing the included document types. It distinguishes itself from sibling tools (get_capability, check_job) by focusing on documentation search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the tool is read-only and never serves customer records, implying it should be used for documentation queries. However, it doesn't provide explicit guidance on when to prefer this tool over alternatives, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0check_jobget_capabilitysearch_docsScored across 3 tools
Each tool targets a distinct concern: capability resolution, job support status, and documentation search. No two tools could easily be confused.
Consistent verb_noun pattern (get_capability, check_job, search_docs) with snake_case throughout.
Three tools is a compact set, each serving a clear purpose without redundancy; the count fits the narrow domain.
The tools cover the main query paths (specific capability lookup, job support checking, and doc search). A minor gap is the lack of a list-all or overview tool, but agents can likely work around it.
Design domain models and generate deterministic multi-stack code, driven by your coding agent.
Typed, deterministic tools on a live Salesforce or HubSpot copy, every write audited and reversible.
Build and publish full-stack apps from your coding agent: models, rules, pages, auth, per-app MCP.
CRM + visual automation builder AI agents can drive via MCP: contacts, tags, maps, email/SMS flows.