test(workstation): guard the history-rewrite confirmation invariant (WS-18) - #2121
Merged
Merged
Conversation
…WS-18) reword-head is the sole entry in HISTORY_REWRITE_WORKFLOW_IDS without requiresConfirmation — verified against the registry, but this is a documented, intentional design choice from #1350, not an oversight: its handler opens an input prompt pre-seeded with the current subject, and submitting that prompt is treated as the confirmation step. Every other history-rewriting workflow goes straight from keystroke to execution with no interstitial step, so it needs requiresConfirmation as its only gate. Whether a pre-filled prompt is sufficient consent for a HEAD-rewriting action, or should additionally require the same explicit y-confirm its siblings get, is a genuine product call - not something to resolve unilaterally. This adds the registry-invariant test the issue itself suggested: it pins down the current, deliberate rule (explicit allowlist for prompt-gated exceptions) so a future history-rewriting workflow added with neither an explicit confirm nor a documented prompt gate fails loudly instead of shipping unprotected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Investigated #1872: is
reword-head(the sole entry inHISTORY_REWRITE_WORKFLOW_IDSwithoutrequiresConfirmation: true) a bug, as the audit's asymmetry-detection flagged?Finding: this is deliberate, documented design, not an oversight.
reword-head's handler (useWorkflowAction.ts) opens an input prompt pre-seeded with the current commit subject, and submitting that prompt is what triggers the rewrite — the existing code comment ininkWorkflows.tssays exactly this ("the prompt itself is the confirmation step"), dating to #1350. Every other history-rewriting workflow (including its closest sibling,amend-head) goes straight from a keystroke/selection to execution with no interstitial step, which is why those need the explicity-confirm as their only safety gate.The issue's own confidence note agrees: "the asymmetry is verified; whether it is wrong is a product call." Whether a pre-filled prompt-and-submit is sufficient consent for a HEAD-rewriting action (vs. requiring the same explicit confirm its siblings get, i.e. prompt and confirm like
amend-headdoes with staged changes) is a UX decision for @gfargo, not something to resolve unilaterally by flipping a flag.What this PR does
Adds the registry-invariant test the issue itself suggested: every id in
HISTORY_REWRITE_WORKFLOW_IDSmust haverequiresConfirmation: trueunless it's in an explicit, documentedPROMPT_GATED_EXCEPTIONSallowlist (currently justreword-head). This doesn't change any runtime behavior — it pins down the current rule so a future history-rewriting workflow added with neither an explicit confirm nor a documented prompt gate fails a test instead of silently shipping unprotected.Leaving #1872 open — the actual policy question (should
reword-headalso require an explicit confirm, or is prompt-implies-consent the right long-term rule for message-editing flows generally) needs your call, not mine. Left a comment on the issue with these findings.Test plan
inkWorkflows.test.ts: everyHISTORY_REWRITE_WORKFLOW_IDSentry requires confirmation unless explicitly allowlisted as prompt-gated; the allowlist itself is validated against the real registrynpx jest src/workstation/runtime/inkWorkflows.test.ts— 24/24 passednpx jest src/workstation— 160 suites / 3149 tests passednpx eslintandnpx tsc --noEmit -p .— cleannpx jest(full suite) — pre-existing, unrelated tree-sitter WASM failures only (same 4 failures present on a cleanorigin/maincheckout in this worktree)