mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5
19407bad1f
The previous contract could not fail. Its guard and its closing assertion both keyed on apiURL -- the one field the merge itself writes -- so once any run had set the URL, every later run skipped the merge on a false_condition and still reported all assertions passed. The live row shows what that hides: an apiKey of `sk-` followed by 48 literal `a` characters, which the gateway answers 401 to, and defaultModel `llama3:latest` while the round's gateway serves only `smollm2:135m`. The merge task is `skipping` in every deploy log on this host. The read now compares the whole desired service and bot with jsonb equality and answers `converged` or `stale`, so a drifted key or model is drift the guard can see. jsonb equality is key-order independent, which keeps the check from depending on how Jinja happened to serialise the dict. Both SQL templates render from the same two role vars, so read and write cannot disagree about what correct means. The `jsonb_typeof(...) = 'array'` guards stay: before the first write those keys exist as JSON null, coalesce does not fire on JSON null, and jsonb_array_elements then raises "cannot extract elements from a scalar". A row edit cannot create the bot account, which is why the Playwright spec 404s on user `agent`. In mattermost-plugin-agents v2.5.1 the config lives in an in-memory atomic pointer; bots.EnsureBots() is the only path that calls pluginAPI.Bot.Create, and it runs from OnActivate and from the config update listener. Writing straight into agents_confighistory reaches neither. The role's only reload lever was `notify: container recreate`, which never fired -- the container is unchanged with RestartCount 0 while the config row was written inside it. The plugin is now cycled explicitly through mmctl, and the enable step moves into tasks/utils/agents/enable.yml so the MCP path and the AI path share one definition. The closing gate is deliberately not another read of what we wrote: it polls the bots-to-users join until the agent account exists. That table is written by the plugin and never by this role, so it cannot pass by echoing the deploy's own work. The reload fires on stale config OR a missing bot, which covers the state this stack is actually in, where the config matched but no account existed. Verified: the stale row, the absent bot account and the always-skipping merge are all measured on the live stack; the EnsureBots path was read from upstream v2.5.1 source rather than inferred; every changed task file parses. Not verified: none of this has executed yet. Specifically open are whether `MATTERMOST_LITELLM_SERVICE | to_json` renders nested Jinja inside a dict var, whether the converged/stale SQL is valid against live Postgres, and whether a disable/enable cycle triggers EnsureBots on this version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
21 lines
543 B
YAML
21 lines
543 B
YAML
---
|
|
- name: "🧩 Mattermost | Activate the prepackaged Agents plugin"
|
|
ansible.builtin.command:
|
|
argv:
|
|
- container
|
|
- exec
|
|
- -i
|
|
- "{{ mattermost_agents_cid }}" # nocheck: container-exec-resolver
|
|
- /mattermost/bin/mmctl
|
|
- --local
|
|
- plugin
|
|
- enable
|
|
- "{{ MATTERMOST_MCP_PLUGIN_ID }}"
|
|
register: mattermost_agents_plugin_enable
|
|
retries: 60
|
|
delay: 5
|
|
until: mattermost_agents_plugin_enable.rc == 0
|
|
changed_when: false
|
|
delegate_to: "{{ mattermost_agents_node }}"
|
|
run_once: true
|