spec-intake: --mode flag and interactive answers don't override inferred executionPreference

[khaliqgant]

Repro

A design spec that legitimately discusses both local and Cloud execution (e.g. a primitive whose API supports both runtimes) trips the execution-mode-conflict clarification on every ricky run, even when the user explicitly passes --mode local and answers the interactive prompt.

ricky --mode local --spec-file specs/slack-primitive.md --run
✔ Should this workflow run locally/BYOH, in Cloud, or generate artifacts for both paths? locally
Generation: failed (status: needs_clarification).
Reason: routing: Spec has unresolved workflow authoring questions: The spec mentions both local and Cloud execution without a clear preference.
Auto-fix: errored after 1/7 attempt(s)

Diagnosis

Two interacting issues in src/product/spec-intake/:

1. inferExecutionPreference (normalizer.ts:98) is the only writer of NormalizedWorkflowSpec.executionPreference. It returns 'auto' whenever the spec text contains both \b(local|byoh|on this machine)\b and \b(cloud|hosted|remote)\b. There is no path for the CLI's --mode <local|cloud|both> flag to override this.

2. Interactive clarification answers are not persisted back into the normalized spec. A grep for applyClarificationAnswer / applyAnswer returns nothing in the source tree. The user answers "locally" interactively, but the next intake call (auto-fix retry, follow-up --run) re-parses the spec text and re-asks the same question. The retry loop runs out of attempts and fails.

executionModeConflictQuestion (clarifications.ts:228) gates on spec.executionPreference !== 'auto', so neither (1) nor (2) lets the user escape the gate without editing the spec text.

Expected

At least one of:

• --mode local|cloud overrides the inferred executionPreference before clarification analysis runs.
• The interactive clarification answer is persisted (e.g. on the run record or on a normalized-spec cache) so subsequent intake calls within the same run skip the resolved question.
• A frontmatter / explicit field in the spec (e.g. Runtime: local) is honored by the normalizer and bypasses regex-based inference.

Workaround

Today: write a separate, short implementation spec that mentions only one runtime keyword. The design doc remains a design doc; the implementation prompt is a different artifact fed to ricky.

Context

Hit while iterating on relay/specs/slack-primitive.md — a design spec for a primitive whose whole point is to support both runtimes, so the body cannot remove either keyword without losing meaning.

[khaliqgant]

Validated against current code. This is no longer reproducible: spec intake now honors explicit CLI mode metadata (mode/executionPreference) before keyword inference, and appended clarification answers resolve the mixed local/Cloud execution question.

Verification run:

• npx vitest run src/product/spec-intake/parser.test.ts (37 passed)
• npx vitest run src/local/entrypoint.test.ts -t "does not ask execution-mode clarification when CLI mode already chose local" (1 passed)

Closing as fixed.