Bug
update-epic takes the epic id as a positional argument, but every other epic-mutating
command in this session's muscle memory (add-epic --id <x>) uses --id as a named flag. Passing
--id <epic-id> to update-epic doesn't error with something like "unrecognized flag --id" — it
just prints the bare usage line and exits, with zero indication of what's wrong:
$ node conductor.mjs update-epic --id my-epic --priority P1
conductor: engine 0.23.1 @ .../scripts
usage: conductor.mjs update-epic <id> [--title T] [--external-id X] [--external-url U] [--parent P] [--status S] [--priority P] [--link "<type>:<epic>[:<reason>]"] [--review-mode off|standard|thorough] [--add-story "<title>"] [--story <n> --done]
The usage line itself hints at the fix (<id> with no leading --), but only if you stop and
read it carefully rather than assume the printed usage means "your flags were malformed" (a
reasonable assumption when several of the other flags on the same line ARE ---prefixed).
Correct invocation:
node conductor.mjs update-epic my-epic --priority P1
Cost real diagnostic time during a live production-incident remediation session, where every
extra round-trip mattered.
Suggested fix: detect the specific case of --id <value> being passed as the first token and
either (a) accept it as an alias for the positional id, or (b) emit a targeted error
("update-epic takes the epic id positionally, not as --id — try: update-epic <id> ...")
instead of the generic usage dump.
Related, smaller gap hit in the same session
update-epic has no --notes flag to append or update the free-text notes field an epic was
created with via add-epic --notes "...". The only way to attach further narrative to an existing
epic post-creation is --add-story "<title>", which is semantically a checklist item, not a notes
update — usable as a workaround, but it's the wrong shape for "here's what happened when this
incident was resolved."
Related to #66 (other update-epic gaps: no --lane, undocumented valueless --link), but this
is a distinct pair of issues (id-passing UX + missing notes setter), so filing separately rather
than piling onto that thread.
Bug
update-epictakes the epic id as a positional argument, but every other epic-mutatingcommand in this session's muscle memory (
add-epic --id <x>) uses--idas a named flag. Passing--id <epic-id>toupdate-epicdoesn't error with something like "unrecognized flag --id" — itjust prints the bare usage line and exits, with zero indication of what's wrong:
The usage line itself hints at the fix (
<id>with no leading--), but only if you stop andread it carefully rather than assume the printed usage means "your flags were malformed" (a
reasonable assumption when several of the other flags on the same line ARE
---prefixed).Correct invocation:
Cost real diagnostic time during a live production-incident remediation session, where every
extra round-trip mattered.
Suggested fix: detect the specific case of
--id <value>being passed as the first token andeither (a) accept it as an alias for the positional id, or (b) emit a targeted error
("
update-epictakes the epic id positionally, not as --id — try:update-epic <id> ...")instead of the generic usage dump.
Related, smaller gap hit in the same session
update-epichas no--notesflag to append or update the free-textnotesfield an epic wascreated with via
add-epic --notes "...". The only way to attach further narrative to an existingepic post-creation is
--add-story "<title>", which is semantically a checklist item, not a notesupdate — usable as a workaround, but it's the wrong shape for "here's what happened when this
incident was resolved."
Related to #66 (other
update-epicgaps: no--lane, undocumented valueless--link), but thisis a distinct pair of issues (id-passing UX + missing notes setter), so filing separately rather
than piling onto that thread.