Bug: find_or_initialize_by(name: ...) batia em captain_interno existente
com mesmo nome (ex: 'Juliana') e SOBRESCREVIA engine='hermes'. Resultado:
Juliana captain_interno virou Hermes, atendimento legado quebrou.
Fix: chave passa a ser (account_id, hermes_profile_name=slug). Auto-sufixa
nome com ' · Hermes' se colidir com captain_interno do mesmo nome (a não
ser que já tenha 'Hermes' no nome). Também grava captain_unit_id no
record (relação direta agora que existe a coluna).
Reverti manualmente Juliana id=1 + criei id=10 'Juliana · Hermes' fix in
DB. Future provisionamentos pelo Construtor usam o caminho corrigido.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bash script em bin/hermes-provision (instalado em /usr/local/bin/ na VPS)
que recebe spec JSON via stdin e provisiona um agente Hermes ponta-a-ponta:
- Valida spec (slug regex, preços 0-5000, períodos/buckets do catálogo)
- Aloca porta livre no range 8650-8699
- Gera HMAC secret via openssl rand
- Cria Captain::Unit (find_or_create), Captain::PricingCategory/Amount,
Captain::Assistant (engine=hermes) via docker exec rails runner
- Copia template profile da Valentina, patcheia config.yaml com porta +
X-Captain-Assistant-Id (parent_id se setado, senão self id)
- Escreve SOUL.md/SKILL.md do spec
- Gera webhook_subscriptions.json com secret
- Cria systemd unit hermes@<slug>.service e enable+start
- rsync profile pra repo de backup git local
- Idempotente: re-rodar com mesmo slug não duplica nada (find_or_create)
- --dry-run valida sem escrever
- --rollback <slug> destrói tudo (DB + systemd + filesystem)
Construtor (Hermes daemon) chama via terminal skill nativa:
echo '<spec>' | /usr/local/bin/hermes-provision
Próximo passo: atualizar SOUL.md/SKILL.md do Construtor pra invocar
o script ao final do fluxo socrático.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Added a command to sync files in the locale/*/ folder. Run `pnpm
sync:i18n` would copy index.js in `dashboard/locale/en` to every other
folder `dashboard/locale/*/`
---------
Co-authored-by: Pranav <pranavrajs@gmail.com>
By default, Rails does not set a timeout on database statements. For example, this will run for a full day, even if your ruby process goes away. But it's configurable in the database.yml with the statement_timeout variable.
Hence we are enforcing a 14s timeout by default. Migration commands inside chatwoot will run with a 10 minutes timeout. For specific cases like migrations, we can override this timeout using the environment variable POSTGRES_STATEMENT_TIMEOUT while starting a new rails console.
Test the timeouts from the rails console using.
```
ActiveRecord::Base.connection.execute("SELECT pg_sleep(15);")
```
ref: https://github.com/ankane/the-ultimate-guide-to-ruby-timeouts#postgresql
ref: https://til.hashrocket.com/posts/b44baf657d-railspg-statement-timeout-
- feature to store contact IP for accounts
- IP lookup through geocoder gem
- ability to do IP lookup through external APIs
- add commit hook to prevent push to develop and master
- migrations to fix default values for jsonb columns
