Review — avaperu.oficial

meta.md declares template='scripted', which specifies a 14-section structure (identity_and_context, style_and_tone, engagement_signals, conversation_logic, happy_path_general_example, knowledge_base, prequalification_questions, trigger_keywords, lead_magnets, qualification_criteria, agent_instruction, instruction_priority, hard_rules, pre_send_checklist). The agent's system.md follows a 6-section 'principles' template structure (Identidad, Voz, Flujo, Calibración, Principios, Herramientas, TEMPLATE PRECIOS) with no engagement_signals, instruction_priority, or pre_send_checklist sections.

examples.md contains 23 examples, exceeding the 20-example cap. However, the agent has keywords.json (4 keywords) requiring keyword-trigger examples, and program.json declares pricing rules requiring price-objection examples. The examples cover all 7 base scenarios (happy path, resource delivery, objection handling, disqualification, emotional lead, re-engagement, off-topic) plus conditional scenarios (keyword triggers in Examples 4, 17, 18; price objections in Examples 5, 6, 19, 20). The excess is driven by legitimate conditional coverage and detailed branching scenarios (Bootcamp variants in Examples 21, 22, 23). While over 20, the coverage is complete and justified by the agent's configuration.

All examples in examples.md follow the flow defined in system.md (Verificar → Precalificar → Contexto → Nutrir → Cerrar) and reach terminal states (link sent, NO_RESPONSE, or graceful closure). Examples progress through steps in order without skipping required stages.

system.md contains one potential tension: 'Regla universal: Si la verificación profesional NO se completó, verificar primero antes de cualquier acción' vs. 'Keyword triggers: Verificar vet PRIMERO, después continuar flujo principal.' However, these are not contradictory — both state that verification must occur first. The keyword rule explicitly names verification as the precondition, not an exception. No shared precondition produces conflicting outputs.

All SDK files align on behavior and data. examples.md demonstrates the flow and pricing rules from system.md correctly. keywords.json notes state 'Verificar vet primero' (matching system.md's universal rule). program.json pricing rules match TEMPLATE PRECIOS in system.md. resources.json provides the single call_admision link used consistently across examples.md and system.md. No file declares behavior or data that contradicts another under the same precondition.

All examples use the same persona (Francisco, warm and consultive), vocabulary (doc, chévere, qué bueno), formality level (casual, WhatsApp-style), and dialect (neutral Spanish, tuteo, no voseo). No jarring tonal shifts across the 23 examples.

The primary risky action — sending the call link — is guarded in system.md: 'Nunca enviar el link directo, siempre proponer la reunión, explicar el valor y pedir permiso. Enviar solo después del sí del lead.' This guard is demonstrated consistently across Examples 1, 2, 5, 9, 19, 20, 21, 22, 23, where the agent asks 'te gustaría que te lo comparta?' and only sends the link after affirmative response ('si dale' / 'dale'). The guard is explicit and working examples confirm its intended behavior.

All examples use current flow language and CTAs from system.md. Closing language ('me avisas si los horarios no te llegan a funcionar, estoy atento a cualquier cosa') matches the current flow definition. No stale phrases from prior versions detected.

Each behavioral instruction has a single canonical home. The verification rule appears once in Flujo (step 1) and is reinforced by a principle ('Verificar siempre antes de avanzar') — this is principle + example reinforcement, not duplication. The pricing template is stated once in TEMPLATE PRECIOS and referenced in objections.md with a cross-reference, not duplicated. No instruction is restated in two locations.

Behavioral guidance (tone, flow, conversational style) is expressed via Voz section (principles + examples) and Flujo (flow steps with examples). Hard rules are reserved for factual constraints (programs, pricing approach, support email, link fallback). The balance is appropriate — behavior is shown through examples and principles; facts remain as rules.