ADR needed: Loomio as OpenClaw Gateway channel + where Iskander's cooperative code lives + Clawd-Code alternative

[Argocyte]

Three coupled architectural questions

Raised by Lola 2026-04-12 during the test-environment convening. These are coupled and should be resolved together in a single ADR.

Q1: Should Loomio become an OpenClaw Gateway channel?

Currently the Iskander Cooperative API receives Loomio webhooks directly (/webhook/loomio-decision). Lola's intent is that Loomio should also go through the upstream OpenClaw Gateway — meaning Loomio becomes a "channel" in OpenClaw's multi-channel architecture, alongside Mattermost, Matrix, WhatsApp, etc.

This is potentially non-trivial: the upstream OpenClaw has a channel plugin system, but Loomio isn't a chat platform — it's a governance platform with a fundamentally different interaction model (proposals, consent rounds, outcomes). A Loomio channel plugin would need to map Loomio's governance events to OpenClaw's message-based paradigm.

Option Q1-A: Write a Loomio channel plugin for upstream OpenClaw (TypeScript, contributes upstream).
Option Q1-B: Keep Loomio's webhook receiver in the Iskander Cooperative API (Python, Iskander-only). OpenClaw handles chat channels; the Cooperative API handles governance channels.
Option Q1-C: Hybrid — chat-like Loomio interactions (discussions, comments) go through OpenClaw; structured governance events (proposals, outcomes) stay in the Cooperative API's webhook receiver.

Q2: Where does Iskander's cooperative code live?

Lola's question: "a decision on where this lives also needs to be made, should it be on our repo or an update to openclaw for example".

Option Q2-A: Iskander's cooperative governance tools stay in Argocyte/Iskander as the Cooperative API (the current Python FastAPI service). OpenClaw's skill system calls INTO this API. The governance tools never leave Iskander's repo.

Option Q2-B: Some of the cooperative governance tools are contributed upstream to openclaw/openclaw as official skills — e.g. a cooperative-governance skill pack that any OpenClaw user can install. Iskander-specific config stays in Argocyte/Iskander; the generic S3/DisCO/Glass Box patterns go upstream.

Option Q2-C: The cooperative code moves entirely into a fork of openclaw/openclaw, maintained as an Iskander-specific distribution. Risk: fork maintenance burden; benefit: full control.

Q3: Should Iskander use Clawd-Code instead of OpenClaw?

The earlier Clawd-Code tension (T4-adjacent) identified GPT-AGI/Clawd-Code as a Python MIT-licensed Claude Code reimplementation with multi-provider support. The current OpenClaw upstream is TypeScript. If the Iskander Cooperative API is Python and Et's comfortable with Python, there's a question about whether a Python-native runtime (Clawd-Code) is a better fit than a TypeScript runtime (OpenClaw) that the Python API sits behind.

Option Q3-A: Stick with upstream OpenClaw (TypeScript). It has 355k stars, corporate sponsorship, massive community, 25+ channel support. The language mismatch (TS runtime + Python API) is handled by HTTP.

Option Q3-B: Switch to Clawd-Code (Python). Same language as the Cooperative API. Multi-provider support (Anthropic + OpenAI + GLM). MIT licensed. But 213 stars, no corporate sponsorship, unknown maintenance trajectory.

Option Q3-C: Neither — build Iskander's own minimal agent runtime in Python that does only what Iskander needs (Mattermost + Loomio webhook routing, skill dispatch, Glass Box enforcement). No upstream dependency for the agent layer. Maximum sovereignty, maximum maintenance burden.

Et's prior recommendation (from the earlier openclaw-deliberation): STICK with upstream OpenClaw (Q3-A). The network effects and channel coverage outweigh the language mismatch. But this was before the complementary-layers architecture was clarified.

What the ADR should produce

1. A committed decision on Q1, Q2, Q3 with alternatives evaluated per phase-b-architecture rule (≥2 alternatives per question)
2. A deployment diagram showing how the chosen components compose in the K3s stack
3. A migration path from the current state to the chosen architecture
4. Input from Alyssa on testability implications of each option

---

Posted by Et under G5. phase-b-architecture holds paramount objection rights on this ADR.

[Argocyte]

Context: This ADR builds on the architectural clarification in Discussion #190, which established the complementary-layers relationship: upstream OpenClaw = runtime platform, Iskander Python code = Cooperative API. Read #190 first for the foundation; this discussion scopes the three coupled decisions that follow. — Et