test dsh, add smoke test

Author: justdeko

.zopf/workflows/provider-smoke.yaml

@@ -0,0 +1,65 @@
+name: provider-smoke
+description: |-
+  Run one turn through every provider at once, to check the AgentProvider seam rather than any model.
+
+  This is the workflow to run after touching AgentProvider, a provider's argv or its event parsing,
+  and after any of the three CLIs ships a release. Each arm builds a different command and parses a
+  different output shape: claude and codex stream JSON, dsh prints plain text. Asking each one to
+  name itself means the gate shows three different answers, so an arm wired to the wrong CLI is
+  visible rather than merely green.
+
+  It fans out so the arms share the concurrency semaphore, and joins on a gate because a gate reads
+  the results without a shell touching them. Unlike `smoke`, this one costs money, on three vendors,
+  and needs all three CLIs installed and signed in.
+repos:
+  - id: self
+    path: ..
+defaults:
+  repo: self
+nodes:
+  - id: reachable
+    type: shell
+    title: Which CLIs are on the login PATH?
+    command: for c in claude codex dsh; do printf '%s = ' "$c"; command -v "$c" >/dev/null 2>&1 && "$c" --version 2>&1 | head -1 || echo "not on PATH"; done
+  - id: viaClaude
+    type: agent
+    provider: claude
+    title: One turn through claude
+    timeoutSeconds: 300
+    prompt: Reply with exactly one short sentence naming the model you are. Do not read or write any files.
+  - id: viaCodex
+    type: agent
+    provider: codex
+    title: One turn through codex
+    timeoutSeconds: 300
+    prompt: Reply with exactly one short sentence naming the model you are. Do not read or write any files.
+  - id: viaDsh
+    type: agent
+    provider: dsh
+    title: One turn through dsh
+    timeoutSeconds: 300
+    prompt: Reply with exactly one short sentence naming the model you are. Do not read or write any files.
+  - id: compare
+    type: gate
+    title: Did all three answer, each as itself?
+    prompt: |-
+      ${reachable.result}
+
+      claude: ${viaClaude.result}
+
+      codex: ${viaCodex.result}
+
+      dsh: ${viaDsh.result}
+edges:
+  - from: reachable
+    to: viaClaude
+  - from: reachable
+    to: viaCodex
+  - from: reachable
+    to: viaDsh
+  - from: viaClaude
+    to: compare
+  - from: viaCodex
+    to: compare
+  - from: viaDsh
+    to: compare

CLAUDE.md

@@ -283,6 +283,12 @@ Gradle build scripts, which are not Kotlin source sets. Explanation belongs in t
 test name long enough to say what it asserts (`everyWorkflowInTheSkillDocsIsWrittenTheWayTheEditorWouldWriteIt`).
 A comment restating what's here is a second copy that drifts.
 
+Everything that is not a Kotlin source set may comment: the Gradle scripts, the connector scripts,
+`main.swift`, the shell scripts. Comments there earn their place or go. One lowercase fragment on the
+line someone would otherwise break, like `// non-jvm dirs read by unit tests so tests don't go stale`.
+Not a sentence, not a restatement of the line under it, and never a second copy of a paragraph from
+this file. The older scripts predate this and still carry prose; trim them as you touch them.
+
 User-facing strings are full sentences that say what to do next, not error codes —
 `"Repo \"app\" isn't at ~/dev/app any more"`, not `"invalid repo"`. That is a rule against error
 codes, not a licence to explain: one sentence, carrying only what the screen isn't already showing.

README.md

@@ -8,7 +8,7 @@
   <b>A macOS app for running agent workflows as a graph.</b>
 </p>
 
-zopf allows you to connect several claude, codex or deepseek sessions into a graph and run them together instead of one
+zopf allows you to connect several claude, codex or DeepSeek Harness sessions into a graph and run them together instead of one
 terminal session at a time. You can also span this across multiple directories and invoke skills and other context on
 the side.
 
@@ -47,6 +47,11 @@ You need **macOS on Apple Silicon** and one of these installed and signed in:
 > While zopf supports claude code, codex and dsh so far, I've only extensively tested claude code as it is my daily
 driver.
 
+`claude` and `codex` installs can just follow the official instructions. `dsh` needs one extra step: install it
+globally, because zopf looks for a `dsh` binary on your login PATH. After
+that, follow [their guide](https://deepseek-harness.github.io/deepseek-harness/en/guide/providers) to add a provider,
+since dsh ships no model of its own. Note that dsh itself is still a 0.1.x developer preview.
+
 ### The App
 
 Download `zopf-<version>.dmg` from the [latest release](../../releases/latest) and drag it to Applications. On first

core/build.gradle.kts

@@ -4,22 +4,16 @@ plugins {
     alias(libs.plugins.ktlint)
 }
 
-// One version for every surface. Generated rather than checked in so a tagged release and a local
-// build can never disagree with the jar they came from; read back through store/BuildInfo.kt.
 val zopfVersion = (findProperty("packageVersion") ?: findProperty("zopfVersion") ?: "0.0.0").toString()
 
-// The workflow file format, bumped by hand when a change alters what an existing file means. Not
-// the app's version and never overridden by the release tag: the two move independently.
 val workflowVersion = (findProperty("workflowVersion") ?: "1").toString()
 
 val writeVersion =
     tasks.register("writeVersion") {
         description = "Writes the build's version and the workflow format version into resources read back by store/BuildInfo.kt."
-        // Locals, not the script's properties: the configuration cache can't serialize a reference
-        // back into the build script from a task action.
+        // locals: config cache can't serialize script props into task actions
         val version = zopfVersion
         val format = workflowVersion
-        // A directory, because this is wired in as a resources srcDir rather than a single file.
         val output = layout.buildDirectory.dir("generated/zopf")
         inputs.property("version", version)
         inputs.property("workflowVersion", format)
@@ -38,9 +32,6 @@ kotlin {
 
     sourceSets {
         commonMain.dependencies {
-            // Snapshot state, not the compiler: NodeRun and RunRegistry are observable by a
-            // composition when there is one, and ordinary objects when there isn't. It is api()
-            // because those objects hand a SnapshotStateList back to whoever reads them.
             api(libs.compose.runtime)
 
             implementation(libs.kotlinx.coroutinesCore)
@@ -50,9 +41,20 @@ kotlin {
         commonTest.dependencies {
             implementation(libs.kotlin.test)
         }
-        // Fixtures :shared's tests compile too — see ExampleWorkflow.kt for why.
         commonTest { kotlin.srcDir("src/testFixtures/kotlin") }
 
         commonMain { resources.srcDir(writeVersion) }
     }
 }
+
+// non-jvm dirs read by unit tests so tests don't go stale
+tasks.named<Test>("jvmTest") {
+    inputs
+        .dir(rootProject.layout.projectDirectory.dir(".zopf"))
+        .withPropertyName("dogfoodWorkspace")
+        .withPathSensitivity(PathSensitivity.RELATIVE)
+    inputs
+        .dir(rootProject.layout.projectDirectory.dir("plugins/zopf/skills"))
+        .withPropertyName("skillDocs")
+        .withPathSensitivity(PathSensitivity.RELATIVE)
+}

core/src/commonMain/kotlin/com/dk/zopf/model/WorkflowValidation.kt

@@ -306,7 +306,7 @@ private fun WorkflowNode.providerIssues(
     provider.ignoredFields(this).takeIf { it.isNotEmpty() }?.let {
         issues +=
             WorkflowIssue(
-                "$displayTitle runs ${provider.label}, which has no ${it.joinToString()}",
+                "$displayTitle runs ${provider.label}, which ignores ${it.joinToString()}",
                 id,
                 WorkflowIssue.Severity.WARNING,
             )

core/src/commonTest/kotlin/com/dk/zopf/runtime/RuntimeBasicsTest.kt

@@ -247,7 +247,7 @@ class AgentCapabilitiesTest {
     }
 
     @Test
-    fun `a CLI that takes a model suggests some, and dsh suggests none because it takes none`() {
+    fun `a CLI that takes a model suggests some, and dsh suggests none because its model is the profile's`() {
         assertContains(AgentProviderId.CLAUDE.modelOptions, "opus")
         assertTrue(AgentProviderId.CODEX.modelOptions.isNotEmpty())
         assertEquals(emptyList(), AgentProviderId.DSH.modelOptions)

plugins/zopf/skills/zopf-workflows/references/schema.md

@@ -32,8 +32,8 @@ nothing until `zopf validate` reports it as a stray key.
 
 ### version
 
-Leave it out. Absent means the current format, and the editor never adds the key. An older number is
-carried forward on load; a newer one is an error and the run is refused.
+Leave it out. Absent means the current format, and the editor never adds the key. An older number is carried forward on
+load; a newer one is an error and the run is refused.
 
 ## repos
 
@@ -79,7 +79,7 @@ node → workflow `defaults` → workspace `defaults` → the app's Settings.
 | `alsoRead`       | list of string    | `agent`                       | Extra declared repo ids the node may access (`--add-dir`). Grants write access too, not just read.                                  |
 | `allowedTools`   | list of string    | `agent`                       | What runs without being asked: `Read`, `Grep`, `Bash(git push *)`. **Grants, never restricts**, see below. **Not interpolated.**    |
 | `skills`         | list of string    | `agent`                       | Skill **names**, not paths. Resolved against the workflow's repos, the workspace `skills/`, and `~/.claude/skills`.                 |
-| `model`          | string            | `agent`                       | Overrides `defaults.model`. Not read by `dsh`, which has no flag for one.                                                           |
+| `model`          | string            | `agent`                       | Overrides `defaults.model`. Not read by `dsh`; its model lives in the profile.                                                      |
 | `permissionMode` | enum              | `agent` (claude)              | `acceptEdits` \| `auto` \| `bypassPermissions` \| `manual` \| `dontAsk` \| `plan`.                                                  |
 | `sandbox`        | enum              | `agent` (codex)               | `read-only` \| `workspace-write` \| `danger-full-access`. Chosen before launch; codex cannot be asked mid-turn.                     |
 | `schema`         | list of field     | `agent`                       | Declares the answer's shape. Each name becomes `${id.name}`. Absent means prose, as before. See [schema](#schema).                  |
@@ -95,17 +95,18 @@ node → workflow `defaults` → workspace `defaults` → the app's Settings.
 It lists what runs **without stopping to ask**. A node with
 `allowedTools: [Read, Glob, Grep]` still has `Bash`, `Write` and `Edit`, and will use them.
 
-What it doesn't name is left to the CLI: read-only commands (`grep`, `find`, `git log`) run, the rest needs an
-answer. Inline approval answers in the app; `zopf run` has no approver, so headless the answer is no. Name what the
-node needs, patterns included, or it works in the window and fails from cron. `Bash(git push *)` is a real entry.
+What it doesn't name is left to the CLI: read-only commands (`grep`, `find`, `git log`) run, the rest needs an answer.
+Inline approval answers in the app; `zopf run` has no approver, so headless the answer is no. Name what the node needs,
+patterns included, or it works in the window and fails from cron. `Bash(git push *)` is a real entry.
 
 ### Model names belong to a CLI
 
 `opus`, `sonnet` and `haiku` are Claude Code's. codex takes its own names, and zopf ships no list of them — write one
-into the node's `model:` or leave it out and let codex use whatever it is configured for. `dsh` takes none at all: its
-headless profile has no `--model`, so a `model:` on a dsh node is a validation warning. This is enforced rather than
-merely documented: `defaults.model` is read only by nodes running the *workflow's* default CLI, and the app's default
-model only by nodes running the *machine's* default CLI, so `model: opus` in a workflow's defaults never reaches
+into the node's `model:` or leave it out and let codex use whatever it is configured for. `dsh` chooses its model in the
+profile rather than on the command line, because everything in it is a plugin and the model is one of them. There is no
+`--model` for zopf to pass, so a `model:` on a dsh node is a validation warning. This is enforced rather than merely
+documented: `defaults.model` is read only by nodes running the *workflow's* default CLI, and the app's default model
+only by nodes running the *machine's* default CLI, so `model: opus` in a workflow's defaults never reaches
 `codex --model opus`. A node's own `model:` is always honoured, because it was written next to its `provider:`.
 
 ### Which CLI, and what it can do
@@ -117,7 +118,9 @@ and take-over both work on a codex node. `alsoRead:` is ignored there, because c
 its own version of the flag hands out writes instead.
 
 `provider: dsh` runs DeepSeek Harness's headless profile, which is one turn and nothing else: `prompt:`, `repo:` and
-`timeoutSeconds:` are the only node keys it reads, and its whole stdout becomes `${id.result}`.
+`timeoutSeconds:` are the only node keys it reads, and its whole stdout becomes `${id.result}`. Which vendor answers is
+the profile's decision: dsh is provider-agnostic, so a dsh node may be talking to DeepSeek, Anthropic, OpenAI or
+anything else it has a model plugin for.
 
 A field the chosen CLI has no version of is left out of the command and `zopf validate` warns, naming it — so `skills:`
 on a codex node is a warning rather than a silent no-op.
@@ -294,8 +297,8 @@ leaked value is a token to rotate.
 | a duplicated schema field     | `<node> declares the output field "x" more than once`                                  |
 | a schema field named `result` | `<node> declares an output field named "x", which ${id.x} already means`               |
 
-An error stops a run before it starts. `zopf run` prints them and exits 3 without running a node, and the app
-says what to fix instead of starting.
+An error stops a run before it starts. `zopf run` prints them and exits 3 without running a node, and the app says what
+to fix instead of starting.
 
 **Warnings** (exit 0, but read them):
 
@@ -306,7 +309,7 @@ says what to fix instead of starting.
 | `on: failure` from a gate/branch/input   | `<node> is a gate, which never fails, so the edge to <y> can never be taken`                         |
 | both `prompt` and `promptFile`           | `<node> sends <file>, so its inline prompt is ignored`                                               |
 | a `default` outside `choices`            | `<node> offers a, b, so its default "c" can't be picked`                                             |
-| a field the node's CLI has no version of | `<node> runs codex, which has no permissionMode, skills`                                             |
+| a field the node's CLI has no version of | `<node> runs codex, which ignores permissionMode, skills`                                            |
 | a CLI that isn't installed               | `<node> runs codex, which isn't on your PATH. The node will fail when it starts`                     |
 | an unknown skill name                    | `<node> uses the "x" skill, which isn't in this workflow's repos, the workspace or ~/.claude/skills` |
 | a schema field `${...}` can't name       | `<node> declares the output field "x", which ${id.…} can't name`                                     |