aggregator(record-claude-launch): a flag token is accepted as the previous flag's value — '--task --model x' records taskRefs ['--model'], '--label --id x' records a session named '--id', exit 0 #3415

Problem

pm-stack/aggregator/scripts/record-claude-launch.ts reads every value-taking option through one helper that takes the next argv token blindly:

function arg(name: string): string | undefined {
  const i = process.argv.indexOf(`--${name}`);
  return i >= 0 ? process.argv[i + 1] : undefined;
}

(record-claude-launch.ts:29-32). A token that is itself a flag is accepted as the previous flag's value, and the same token is then consumed a second time as a flag in its own right. The script exits 0 and appends the corrupted record to the launch-records JSONL the fleet-feed collector merges into the session registry (collect-fleet-feed.ts:603-611, parseLaunchRecords).

Evidence (verified this run, main 674f7eee)

Real script run under bun on the laptop (script sha256 fd0d3309…, identical on sandbox and laptop clones; probe ~/git/fleet/probe-2026-11-01-laneB-claudelaunch/, log probe-run.log):

• Control --label "Slice 3 builder" --task developing-today/code#123 → correct record: label Slice 3 builder, taskRefs: ["developing-today/code#123"].
• --label "Slice" --task --model gpt-x → "taskRefs": ["--model"] and "model": "gpt-x" — the --model token is consumed twice: once as the task ref, once as the flag. The session's task linkage now points at a ref that is not a ref.
• --label --id claude-x → "id": "claude-x", "label": "--id" — the dashboard's identity registry gains a session whose display name is a flag.
• --label "Slice" --model --file ./out.jsonl → "model": "--file" — and --file still took effect (the record landed in out.jsonl), so the flag token served as both value and flag.

Downstream: taskRefs elements are rendered through refUrl/parseRef (model.ts:452-470), which throws not a repo-qualified ref on a value like --model — the malformed-ref render crash class already tracked for registry records in #2485, here planted at the producer by an ordinary flag-ordering slip (a --task with its value forgotten, or flags reordered).

Why it matters

This script is how Muse sessions register themselves in the identity registry that drives the dashboard's task ↔ session linkage (#906 §3). There is no later validation of the label or model, and the taskRefs are trusted as refs. One mistyped invocation silently writes a record that misnames the session, links it to a non-existent task, and can feed a throwing ref into the session views — with exit 0 and a success line, so the launcher never notices.

Related: this is one more hand-rolled argv parser for the #3352/#3353 strict-argument-contract inventory (it is not among #3353's named starting candidates); it can be dispositioned there as this issue's follow-up.

Acceptance criteria

• A value-taking option (--label, --id, --parent, --task, --model, --status, --file) whose next token is missing or starts with -- is refused with a usage error (exit non-zero) and no record is appended.
• The same token is never consumed as both a value and a flag.
• Control behaviour unchanged: a normal --label … --task owner/repo#N invocation records exactly the given label and ref; repeated --task still collects multiple refs.
• A test or scripted check covers at least: flag-as-value for --task, flag-as-value for --label, a value flag in last position, and the normal control.

Dedup

Searched open + closed issues for record-claude-launch, launch-records, and the flag-as-value class: the trailing/flag-like filings cover other scripts (#3330 backfill --dir, #3333 charges-producer --start/--end/--out, #3295 append --by, #3312 mcpx docs-history); none covers this script. #3353's closing inventory is expected to disposition remaining parsers — this filing is the named follow-up that item 2(b) of its scope calls for.