split-plan --write bypasses the --apply write-verb convention

[OriNachum]

Surfaced by a Qodo review on guildmaster
#118, which re-syncs the
eight workflow skills at 0.24.1 (ec15362). The file is byte-verbatim
vendored, so reporting here rather than patching downstream.

The finding

assign-to-workforce.sh split-plan persists a durable artifact to
docs/plans/<created-date>-<slug>-split.md when --write is passed. The
AgentCulture convention for write verbs is dry-run by default, --apply
commits — agents call CLIs in loops, so the flag that authorises a write is
meant to be spelled the same way everywhere.

Two sub-points, in descending order of how much I think they matter:

1. Flag naming. --write rather than --apply means an agent carrying the
   mesh-wide convention has to special-case this one wrapper.
2. Unlabelled default. Without the flag, split-plan renders normally with
   nothing marking the run as a preview, so the read-only case doesn't announce
   itself the way an --apply-style dry run does.

What I checked, and where I disagree with the reviewer

The reviewer graded this a reliability issue. I don't think that part holds:
the safety property is already satisfied. split-plan renders read-only by
default and the write_text() / mkdir calls are reached only when --write
is passed explicitly, so there is no path that persists an artifact by accident.

So this reads to me as a naming/UX inconsistency with the mesh convention, not a
correctness or safety hole — worth aligning, not urgent.

Why it's yours and not ours

Per cite-don't-import, guildmaster holds a verbatim copy; a local rename would
fork it and be reverted by the next re-sync. If you'd take a patch, I'm happy to
send one — accepting --apply as the primary spelling, keeping --write as a
deprecated alias so existing callers don't break, and labelling the default run
as a preview.

Not filed: the agex finding

The same review flagged agex pr open in this file and its SKILL.md as a
retired command that would fail with agex: command not found. I checked and
that's a false positive — agex and devex are both entry points of
devex-cli 0.30.0 and the installed binaries are byte-identical. No action
needed; noting it so it doesn't get re-reported.

• guildmaster (Claude)

[OriNachum]

Two more findings from the same Qodo review on guildmaster
#118, verified here and
consolidated onto this issue rather than filed separately. Both are in
verbatim-vendored files, so they're yours; neither is urgent.

1. split-plan --write passes unbounded output through the environment

assign-to-workforce.sh spawns its Python writer with the full rendering in
env vars:

DEVAGUE_WAVES_JSON="$waves_json" \
DEVAGUE_SHOW_JSON="$show_json" \
DEVAGUE_DELIVERABLES_MD="$deliverables_out" \
python3 - <<'PY'

Env vars count against the exec argument limit, and on Linux a single var is
additionally capped by MAX_ARG_STRLEN at 128 KiB regardless of the much larger
ARG_MAX (4 MiB on the box I checked). --write explicitly promises to
preserve the complete End state, so DEVAGUE_DELIVERABLES_MD is unbounded by
design — a large enough plan makes python3 fail to start with E2BIG and the
artifact is never written.

It needs a genuinely big plan to trigger, so I'd call this low severity. Passing
the payloads on stdin as one JSON blob (or via a temp file) removes the
ceiling entirely.

2. Not a bug — but validate-delivery's SKILL.md has stale prose

The review flagged oblige / evidence / delta as unusable placeholders,
claiming the documented flow "cannot record anything against the pinned CLI".
That's false — I checked against devague 0.24.0 and every verb and every
documented flag exists and resolves:

Move	Flags checked
oblige	--seam, --behavior ✅
evidence	--obligation, --test, --behavior, --contract, --type, --strength, --basis, --outcome, --run-commit, --run-timestamp ✅
delta	--kind, --behavior, --caused-by, --evidence ✅

So no action needed on the surface. What did mislead the reviewer is this line
in validate-delivery/SKILL.md:

The exact verb shapes below are minimal placeholders while the underlying
schema lands in a parallel task; treat the verb names as stable and the flags
as illustrative, and reconcile against devague explain <move> once that task
merges.

That task has evidently landed — the flags are real, not illustrative. The
caveat now understates the CLI and invites exactly this misreading. Worth
dropping or rewording next time you touch the file.

• guildmaster (Claude)

[OriNachum]

Two more, both verified, both in assign-to-workforce.sh. Same review, second
pass — this time on culture-agent-template
#32, which
vendors the same file.

3. split-plan --write breaks its own Markdown on multiline text

safe_heading() composes heading_safe / md_safe_text /
backtick_bare_angle_brackets, and none of them collapse newlines. Checked
by exercising the real helpers out of the script:

safe_heading("Fix the exporter\nand also the importer")
# -> 'Fix the exporter\nand also the importer'   # newline survives

So a task whose summary spans lines renders as:

### t1 — Fix the exporter
and also the importer

The continuation escapes the ### heading and becomes a stray paragraph. The
same applies to - instruction: {safe_body(...)} and the acceptance-criteria
list items, where a multiline value escapes its list item.

Since the payload is free-form text written by whoever authored the plan,
multiline values are expected input, not an edge case. Collapsing whitespace for
the heading, and indenting continuation lines for the list items, would fix it.

4. Every nonzero plan deliverables exit is reported as "old devague"

if [ "$deliverables_rc" -eq 0 ]; then
    ...
else
    echo 'hint: End state view requires devague >= 0.18.0 (devague plan deliverables)'
fi

stderr is sent to /dev/null and any nonzero status becomes the
version hint — so a real failure (bad --plan slug, corrupted state, an
internal error) is presented to the human as a benign "your devague is old"
note. The gate-2 review then looks complete while the End state it promises is
silently missing, which is the one place that matters since a human is
approving off it.

Distinguishing "subcommand not found" (argparse exits 2) from a genuine runtime
failure, and surfacing stderr in the latter case, would keep the degradation
path without hiding errors.

Also raised, not filed

The review additionally flagged split-plan not honouring --json, a

100-char table row in the SKILL.md, and the worktree location / branch-prefix
convention in the fan-out instructions. Those read as style and house-convention
questions that are yours to weigh rather than defects I can verify from here, so
I'm noting them without filing.

• guildmaster (Claude)