DM6 Agenda

want

* Add a short “**How to build the WOW position paper**” section to README.md

> To determine its effectiveness, we must first define our goals and establish how we will measure them. While different stakeholders will have some common ideas and goals, they will also have some that differ. Therefore, it will be crucial to identify these similarities and differences at an early stage.

have

todo

# Go into the wiki bundle and install the patched client cd node_modules/wiki npm i ~/Downloads/wiki-ipv6/wiki-client-0.31.3.tgz

roster

wow.dreyeck.ch elm.dm6.dreyeck.ch jpn.dreyeck.ch wiki.ralfbarkow.ch localhost:3000 localhost:3333

inbox

~

Here’s a first joint pass from “all agents” treating `/view/dm6-agenda` as the project’s living front-door. I’ll phrase it as short “notes + proposed next move” per agent so you can decide what to actually do next. ---

### 🔎 codebase-locator **Read of dm6-agenda:** * Treats `dm6-agenda` as the *umbrella workspace* over: * `dmx-platform` (+ `dmx-dita`, `dmx-fedwiki`, `dmx-zettelkasten`) * `gt4nix` / GT image + agents * `wow` (position paper, DITA pipeline) * Elm topic map / wiki frontends (`dm6-elm`, `wiki-plugin-topicmap`, etc.) * The `/view/dm6-agenda` page is effectively the *routing hub* for these projects, but the mapping “page → git repo root” is not yet explicit. **Next move (locator):** * Define a **DM6AgendaCodebaseLocator** (class or config) that knows: * `dm6-agenda` → list of repo roots (workspace paths) * For each repo: primary SPEC doc (e.g. `wow/SPEC.md`, `dmx-platform/docs/…`, `gt4nix/docs/…`). * Expose an API like: ```smalltalk DM6AgendaCodebaseLocator class>>projects DM6AgendaCodebaseLocator class>>specForProjectNamed: ``` so other agents can query “what does dm6-agenda mean in code?”. ---

### 📚 docs-steward **Read of dm6-agenda:** * Right now, “DM6 Agenda” exists more as a *cluster of conversations* than as a clean document set. * The /view page should point to a minimal, shared document spine: * `SPEC.md` – what DM6 Agenda *is* (scope, agents, repos). * `IMPLEMENTATION_PLAN.md` – current focus items and who (which agent) owns them. * `WORKLOG.md` / `PROGRESS.md` – cross-project log (short entries, linking into repo-local logs). **Next move (docs):** * Create a **top-level DM6 Agenda SPEC** (wherever you prefer; e.g. in a dedicated `dm6-agenda` repo or in `wow/docs/DM6-AGENDA-SPEC.md`) with: 1. Purpose: “DM6 Agenda is the coordination layer connecting DMX, GT, Elm/FedWiki, and WOW.” 2. Projects table: columns = *Project* / *Repo* / *Primary Doc* / *Runtime*. 3. Agents table: *Agent* / *Responsibilities* / *Typical inputs* / *Typical outputs*. * Then link that SPEC from `/view/dm6-agenda` as “canonical description”. ---

### 🧭 architecture-scribe **Read of dm6-agenda:** Sees `dm6-agenda` as the **system-of-systems architecture page**. Right now the architecture is present in your head + chats, but not captured as a diagram with clear boundaries. **Next move (architecture):** * Capture **one core diagram** for DM6 Agenda: * Layers: * *Runtime layer*: DMX 5.x (OSGi), GT/Pharo, Nix shells, Node/Elm. * *Integration layer*: DITA plugin, FedWiki plugins, GT codebase locators, agents. * *Interface layer*: FedWiki pages (`/view/...`), Elm topicmaps, GT tools. * *Theory layer*: Luhmann / WOW position paper / Zettelkasten concepts. * Add a short CRC-style note per major “thing”: * `DM6Agenda` – coordinates projects & agents. * `DMXPlatformIntegration` – owns DITA + FedWiki plugs. * `GTAgentHost` – where agents run and access code. * `FedWikiFrontdoor` – how `/view/dm6-agenda` exposes everything. Even a quick hand-rolled Markdown “pseudo-diagram” on the dm6-agenda page would already be a big win. ---

### ⚙️ runtime-orchestrator **Read of dm6-agenda:** * Sees `/view/dm6-agenda` as the **control panel** for multiple runtimes: * DMX runtime (with bundle issues like SLF4J & dmx-dita). * GT image with agents (codebase locator, parsers, wrappers). * Nix environments for dmx-platform, wow, gt4nix. * Node/Elm build chains. **Next move (runtime):** * Declare a tiny **runtime matrix** attached to DM6 Agenda: * For each project: * How to start it (Nix command, GT script, DMX start). * Known incompatibilities (e.g., SLF4J range for dmx-dita-0.2.1 vs DMX 5.3.5). * Which agent “owns” problems there (runtime-orchestrator, pharo-code-emitter, etc.). * Provide one **orchestrator entrypoint** in GT: ```smalltalk DM6AgendaRuntimeOrchestrator class>>openDashboard ``` that, when run, inspects the current workspace and reports: * Which runtimes are available. * Which ones are misconfigured. * Links (or commands) to fix / start them. ---

### 🧪 pharo-code-emitter **Read of dm6-agenda:** * Interprets dm6-agenda as a *spec source* that should be consumable from inside GT, similarly to how WOW’s SPEC/DITA files are being parsed. * Currently there’s logic for `GtWowSpecInputParser`, `DmxCodebaseLocator`, etc. DM6 Agenda itself isn’t yet a first-class object in the image. **Next move (code emitter):** * Introduce a **GtDm6AgendaInputFile / Parser** pair: * Knows how to: * Locate the DM6 Agenda SPEC file (via `DM6AgendaCodebaseLocator`). * Parse essential info (list of projects, agents). * Provide GT views (e.g., tree of agents ↔ repos). * Provide a convenience example: ```smalltalk GtDm6AgendaInputParser class>>exampleOpenAgendaInPlayground ``` that evaluates to a model object representing DM6 Agenda, ready for inspection. ---

### 🌍 web-search-researcher **Read of dm6-agenda:** * Sees it as the **coordination surface** for all external references: * Scientific work (Luhmann, Condorcet, Müller, etc.). * Tool ecosystem docs (DMX, GT, FedWiki, Nix, DITA-OT). * Right now, the links and references are distributed across multiple pages and chats. **Next move (research):** * Maintain a small **“Research Index” section** linked from dm6-agenda: * Subsections like: * *Theoretical Foundations* (Luhmann, Latour, Müller, etc.). * *Tool References* (DMX manual, GT docs, Nix manual, DITA-OT docs). * Each item: short purpose + link. * For each new major feature (e.g., DITA wrapping, SLF4J compatibility, narrative path), add a bullet: * “See also: [external doc / paper] – how it informs this design.” --- ### 🗂 docs-steward + architecture-scribe + runtime-orchestrator: joint proposal **Minimal concrete next iteration, anchored at `/view/dm6-agenda`:** 1. Create a **DM6 Agenda SPEC** (one Markdown file) with: * Project table. * Agent table. * Runtime matrix (high level). 2. Link this SPEC clearly from `/view/dm6-agenda` as: * “DM6 Agenda – current SPEC” 3. In GT: * Teach `DM6AgendaCodebaseLocator` where that SPEC lives. * Add one simple GT example method that opens the SPEC via a `FileReference`. Once that exists, all the other moves (parsers, runtime dashboard, CRC cards) can hook into it. If you tell me where you want the SPEC to live (which repo/path), I can draft the first version of that file plus the corresponding Smalltalk scaffolding in one go.