openprompt-lang 0.3.0

package/docs/referencia-metodologia/Fase - 8 .- Entrega, capacitaci/303/263n y mantenimiento.md"

@@ -0,0 +1,55 @@
+
+---
+> [!abstract] Objetivo de la Fase
+> Esta etapa marca el fin del ciclo de desarrollo del MVP y el comienzo de la operación en el mundo real. Su propósito es transferir el producto de forma ordenada, blindar legalmente al desarrollador frente a imprevistos de terceros y establecer las reglas claras del modelo de soporte (SaaS o Llave en mano).
+
+## a. Protocolo de Entrega y Cierre Administrativo
+
+Nunca se hace un pase a producción en silencio ni "por WhatsApp". La entrega oficial requiere una validación formal para cerrar el alcance del proyecto y evitar que el cliente siga pidiendo cambios gratuitos.
+
+- **Firma de Conformidad (Acta de Recepción):** Se envía un documento digital donde el cliente firma y acepta que el proyecto fue entregado según las condiciones y alcances acordados en la Fase 4.
+- **Diferenciación por Modelo de Negocio:**
+  - *Proyectos de Compra Única (Llave en mano):* Se entrega el contrato final definiendo la propiedad del código, los plazos de garantía técnica y el finiquito de la relación de desarrollo activo.
+  - *Proyectos SaaS (Suscripción Mensual):* Se activa el Acuerdo de Nivel de Servicio (SLA) que rige la relación continua y el pago recurrente.
+
+> [!warning] Límites de Responsabilidad (Disclaimer)
+> Se estipula por escrito que el desarrollador **NO es responsable** por:
+> 1. Mal uso del sistema por parte de empleados (Ej: borrar registros por error).
+> 2. Caídas de servidores de terceros (Railway, Netlify, Supabase, Webpay).
+> 3. Pérdida de acceso por compartir contraseñas de administrador.
+
+---
+
+## b. Capacitación y Onboarding del Cliente
+
+El software carece de valor si el cliente no sabe utilizarlo. Se garantiza un proceso de adaptación para asegurar que la transición tecnológica sea un éxito y reducir la carga de soporte posterior.
+
+- **Sesión de Lanzamiento:** Capacitación presencial o mediante videollamada dedicada exclusivamente a enseñar el uso del sistema en tiempo real.
+- **Entregables de Apoyo:** Entrega de manuales de uso (PDF/Notion), tutoriales en video grabados de la pantalla y documentación en el formato de preferencia del cliente.
+- **Periodo de Adaptación (Handover):** Se establece un margen de **hasta 1 semana** de acompañamiento intensivo para que el cliente y su equipo hagan la transición y resuelvan dudas de uso diario.
+
+---
+
+## c. Políticas de Soporte y Canales de Comunicación
+
+Para evitar el agotamiento (*Burnout*) y el abuso de confianza (mensajes a las 2 AM un domingo), el soporte técnico se rige por reglas estrictas.
+
+- **Canales Oficiales:** Toda comunicación de soporte se canaliza únicamente a través de WhatsApp, Correo Electrónico o Llamada Telefónica.
+- **Horario de Atención:** El soporte estándar se brinda exclusivamente dentro de un horario laboral estipulado previamente en el contrato.
+- **Protocolo de Emergencias:** En caso de caídas críticas fuera de horario, se podrá brindar atención inmediata, pero **sujeta a un cobro adicional por urgencia**, dependiendo del impacto del problema.
+- **Soporte en Terreno:** De ser estrictamente necesario para resolver un bloqueo operativo, se incluye la asistencia presencial (con viáticos cubiertos si aplica).
+
+---
+
+## d. Mantenimiento, Monitoreo y Escalabilidad
+
+El software es un ente vivo. El mantenimiento correctivo (bugs tuyos) se maneja distinto al mantenimiento evolutivo (mejoras o crecimiento del cliente).
+
+- **Mantenimiento y Garantía:**
+  - *Bugs de Producción:* Cualquier error de lógica que provenga del desarrollo y haya escapado a las pruebas de la Fase 7, se repara **sin costo**.
+  - *Periodo de Gracia (Compra Única):* Dependiendo del presupuesto inicial, se otorgan hasta 3 meses de mantenimiento gratuito. Pasado ese tiempo, toda intervención técnica se cobra por hora o tarea.
+  - *Modelo SaaS:* En suscripciones, la mantención y correcciones están incluidas en la cuota mensual.
+
+> [!tip] Monitoreo Proactivo y Upselling (Venta Cruzada)
+> - **Alertas de Tráfico:** Se implementa un sistema (propio o revisando logs de Railway/Sentry) para detectar si los recursos del servidor están por saturarse debido a picos de usuarios.
+> - **Escalabilidad Monetizada:** Si el negocio del cliente crece, se le avisa proactivamente sobre la necesidad de subir el plan del servidor (Tier). Esta reconfiguración de infraestructura conlleva un **costo extra por servicio técnico** (Setup fee), independientemente de lo que cobre la plataforma de hosting.

package/docs/referencia-metodologia/Figma prompt template.md

@@ -0,0 +1,130 @@
+> [!example] Universal Figma Prompt Template for Project Workspace Design
+> ```text
+> Create a flexible, reusable workspace template that can be adapted to many types of software projects. The goal is to build a universal project execution environment where the user can define the project context, working area, and product idea, then customize the structure according to the specific project type.
+>
+> Main purpose:
+> Design a modular workspace system that can serve as the foundation for different project types such as SaaS dashboards, internal tools, admin panels, MVPs, client projects, and product prototypes.
+>
+> Core concept:
+> This is not a fixed application design. It is a universal work area template that includes:
+> - Project context area.
+> - Environment / setup area.
+> - Idea / objective area.
+> - Workspace layout.
+> - Reusable task and content blocks.
+> - Flexible sections that can be adapted to the project type.
+>
+> What the template must allow:
+> The design should leave space for:
+> - Project name and type.
+> - Industry or domain.
+> - Main objective.
+> - Target users.
+> - Current stage.
+> - Stack or environment.
+> - Main features or modules.
+> - Task workflow.
+> - Notes and decisions.
+> - AI context / prompt section.
+>
+> Layout structure:
+> 1. Project Context Panel
+>    - Project name
+>    - Project type
+>    - Short description
+>    - Status
+>    - Version or stage
+>
+> 2. Environment Panel
+>    - Stack or tools
+>    - Folder structure overview
+>    - Key dependencies
+>    - Environment notes
+>    - Technical constraints
+>
+> 3. Idea / Goal Panel
+>    - Problem to solve
+>    - Product vision
+>    - Expected outcome
+>    - Scope notes
+>    - Success criteria
+>
+> 4. Main Workspace Area
+>    - Central working panel
+>    - Active task or current focus
+>    - Editable content blocks
+>    - AI-generated context block
+>    - Action buttons
+>
+> 5. Supporting Panels
+>    - Task list
+>    - Status indicators
+>    - Notes
+>    - Progress tracking
+>    - Activity or history
+>
+> Design principles:
+> - Make the system universal and adaptable.
+> - Avoid hardcoding the design for one single app type.
+> - Keep room for later customization depending on the project.
+> - Use reusable components with variants.
+> - Avoid inline styling decisions in the structure.
+> - Keep the layout clean, modular, and easy to translate into React + Tailwind.
+> - Use clear spacing, visual hierarchy, and flexible panels.
+>
+> Component system:
+> - WorkspaceShell
+> - ProjectContextCard
+> - EnvironmentCard
+> - IdeaCard
+> - GoalCard
+> - TaskCard
+> - StatusBadge
+> - StageBadge
+> - ProgressCard
+> - NotesPanel
+> - ActivityPanel
+> - AIContextPanel
+> - ActionBar
+> - TabNavigation
+> - SidebarNavigation
+> - EmptyState
+>
+> Variant system:
+> Each component should support variants for:
+> - default
+> - compact
+> - expanded
+> - active
+> - selected
+> - blocked
+> - completed
+> - warning
+> - informational
+>
+> Adaptability rules:
+> - Leave areas that can be edited based on the project type.
+> - Use placeholder text and flexible labels instead of fixed product-specific content.
+> - Allow the same template to be used for different types of products and workflows.
+> - Make the structure capable of supporting both technical and non-technical project contexts.
+>
+> Visual style:
+> - Clean modern SaaS style.
+> - Dark mode first.
+> - Minimal but professional.
+> - High readability.
+> - Modular cards and panels.
+> - No terminal style.
+> - No decorative clutter.
+> - No over-specific visual assumptions.
+>
+> React and Tailwind direction:
+> The design should be easy to convert into:
+> - React components.
+> - Tailwind utility classes.
+> - Shared primitives.
+> - Separate domain-based folders.
+>
+> Final instruction:
+> Build a universal workspace template that can later be specialized by project type. The design should help the user define the environment, the context, the goal, and the execution area before starting the actual product design or development process.
+> ```