Initial commit: SKEEN Derma Experts - Sistema Integral de Gestión Clínica

- Frontend React (SKEEN Brand) con Vite, TypeScript, Tailwind
- Frontend Homenest (versión alternativa)
- Módulos Odoo 17 custom (citas, pacientes, monedero, pagos, ventas, inventario, whatsapp)
- WACRM fork (Next.js 16 + Supabase)
- Hermes + Bridge + Skills (Qwen3.6 via Nan Builders)
- Scripts de migración y operación
- Documentación extensiva en docs/

wacrm/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,76 @@
+name: Bug report
+description: Something in the template isn't working the way the docs say it should.
+title: "[bug] "
+labels: ["bug", "triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for reporting! The more specific you can be, the faster we
+        can land a fix.
+
+        **Not a bug in the code?** If this is a security issue, close this
+        form and follow [SECURITY.md](https://github.com/ArnasDon/wacrm/blob/main/.github/SECURITY.md)
+        instead.
+
+  - type: textarea
+    id: summary
+    attributes:
+      label: What happened?
+      description: One or two sentences describing the symptom.
+      placeholder: Clicking a conversation leaves the thread stuck on "No messages yet".
+    validations:
+      required: true
+
+  - type: textarea
+    id: steps
+    attributes:
+      label: Steps to reproduce
+      description: The minimum steps we need to trigger the bug on our side.
+      placeholder: |
+        1. Sign in, go to /inbox.
+        2. Click any conversation that has past messages.
+        3. Thread pane shows "No messages yet" until hard refresh.
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected
+    attributes:
+      label: What did you expect?
+      placeholder: Messages load the first time, every time.
+    validations:
+      required: true
+
+  - type: input
+    id: version
+    attributes:
+      label: Commit / version
+      description: |
+        The commit SHA or release you're on. `git rev-parse --short HEAD`
+        in the fork works.
+      placeholder: "e.g. d6a4677 or v0.2.0"
+    validations:
+      required: false
+
+  - type: dropdown
+    id: runtime
+    attributes:
+      label: Where is it running?
+      options:
+        - Local dev (npm run dev)
+        - Hostinger Managed Node.js
+        - Hostinger VPS
+        - Vercel
+        - Other Node host
+    validations:
+      required: false
+
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs / screenshots
+      description: Server logs, browser console errors, network tab — anything that looks suspicious. Scrub tokens before pasting.
+      render: text
+    validations:
+      required: false

wacrm/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Security vulnerability (private)
+    url: https://github.com/ArnasDon/wacrm/security/advisories/new
+    about: Do not file security issues in public. Follow the private disclosure flow.
+  - name: Setup / "how do I..." questions
+    url: https://github.com/ArnasDon/wacrm/blob/main/docs/README.md
+    about: Check the docs first — setup, deploy, troubleshooting are all covered.
+  - name: Using this as a template (forking)
+    url: https://github.com/ArnasDon/wacrm/blob/main/CONTRIBUTING.md
+    about: This is a template. Most changes belong in your fork, not an upstream issue — here's how that works.

wacrm/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,68 @@
+name: Feature request
+description: Propose a new feature or a meaningful enhancement.
+title: "[feat] "
+labels: ["enhancement", "triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for the idea — but read this first.
+
+        This is a **template**, not a collaborative product. The
+        upstream scope is intentionally narrow, so most feature
+        requests end up as *"build this in your fork"* rather than
+        landing here. That's the point of a template.
+
+        When an upstream feature request *is* useful:
+
+        - It fixes a correctness problem in the template.
+        - It makes the template cleaner for the next forker (reducing
+          friction, removing footguns).
+        - It's in scope for "a generic WhatsApp CRM template" rather
+          than a bet on your specific workflow.
+
+        If the feature is really for your own deployment, fork and
+        build it there — see
+        [CONTRIBUTING.md](https://github.com/ArnasDon/wacrm/blob/main/CONTRIBUTING.md).
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: What's the problem?
+      description: What are you trying to do today that the template makes harder than it should?
+      placeholder: |
+        When a broadcast ends I have no way to see which recipients
+        didn't reply so I can follow up manually.
+    validations:
+      required: true
+
+  - type: textarea
+    id: proposal
+    attributes:
+      label: What would you like to see?
+      description: Describe the feature from the user's perspective, not the implementation.
+      placeholder: |
+        On the broadcast detail page, a "No reply" filter that lists
+        recipients who received but didn't reply within 24 hours.
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives you considered
+      description: Things that kinda work today, workarounds, related features in other tools.
+    validations:
+      required: false
+
+  - type: dropdown
+    id: scope
+    attributes:
+      label: Scope
+      description: Your guess — we'll re-scope if needed.
+      options:
+        - Small (a couple of hours)
+        - Medium (a couple of days)
+        - Large (a couple of weeks, probably breaks into multiple PRs)
+    validations:
+      required: false