modem-dev/hunk

Summary Hunk currently calls its single-column diff presentation the stack or stacked layout. That terminology is incorrect: the implemented presentation is a unified diff. Rename this layout to unified throughout the product, public APIs, implementation, tests, documentation, examples, and maintained media. This is a terminology change only. Rendering, navigation, responsive behavior, wrapping, copying, notes, and scrolling should behave exactly as they do today. Look at the implementation plan before starting. It contains the investigated file map, compatibility policy, rename guidance, test coverage, media audit, and validation checklist. Desired vocabulary Current Replacement Stack layout Unified layout Stacked view Unified view Canonical stack value Canonical unified value Internal Stack* / stack* names Unified* / unified* Apply these replacements only where “stack” describes the diff layout. Do not rename unrelated uses such as call stacks, stack traces, parse

Problem The shared key-chord parser removes empty segments after splitting a chord on +. As a result, malformed bindings are silently interpreted as different valid shortcuts: s+ → s +s → s ctrl++s → ctrl+s ctrl+s+ → ctrl+s For example, parseKeyChord("s+") currently returns the same parsed chord as parseKeyChord("s"), and the malformed chord matches a real s key event. The behavior comes from filtering empty tokens before the parser validates the modifier and base-key structure in src/extension-api/keys.ts. Why this matters This grammar is shared by user [keybindings], extension registerCommand bindings, Hunk's own command table, and the public matchesKey helper. A typo can therefore claim and execute a real shortcut instead of being rejected and surfaced as an unusable chord. This is also inconsistent with the parser's existing behavior for other malformed chords such as ctlr+s, f13, and ctrl+, which are rejected rather than normalized. Expected behavior Key cho

Problem synthesizeKeyEvent returns a plain object asserted as OpenTUI's KeyEvent. The synthetic object contains the chord fields used by current matching, but omits required event fields such as eventType and source. Its preventDefault and stopPropagation methods also do not update the state exposed by real KeyEvent getters. The current round-trip test only verifies chord matching. Synthetic events are also passed to command matchers and programmatically invoked handlers, which may legitimately inspect the rest of the KeyEvent contract. Proposed direction Construct the exported OpenTUI KeyEvent class with a complete parsed-key payload instead of asserting a partial object. Use explicit synthetic defaults such as eventType: "press" and source: "raw" unless a more appropriate source is available. Acceptance criteria synthesizeKeyEvent returns a real KeyEvent instance without a double assertion. Existing chord matching behavior remains unchanged. eventType and source are populated. preve

Problem The deprecated registerSidebarView contract declares files as a mutable ExtensionDiffFile[], while the pane contract uses a readonly list and the host supplies frozen file views. Registration currently bridges the component types with a double assertion. A legacy sidebar following its declared contract and calling files.sort(), files.push(), or another mutating method can therefore throw during rendering. Proposed direction Replace the component assertion with an explicit legacy adapter that maps ExtensionPaneProps to ExtensionSidebarViewProps. If the deprecated mutable contract must remain compatible, pass a shallow mutable copy of the files array. The adapter should also make the intentionally omitted new pane fields explicit rather than relying on function variance. Acceptance criteria A legacy sidebar can mutate its received files array without mutating host-owned state or throwing because the array is frozen. Modern pane components continue receiving the readonly host pro

Problem reviewEventId can produce IDs that parseReviewEventId rejects for valid ReviewPublicationAddress values. The parser currently limits the revision component to 15 digits: /^revent:([a-z-]+):(.+)@(\d{1,15})$/ Elsewhere, state revisions are accepted as non-negative safe integers. Safe integers can contain 16 digits; for example, Number.MAX_SAFE_INTEGER is 9007199254740991. As a result, an event ID built from a valid high revision does not round-trip through the shared parser. Why this matters The event ID builder and parser form one protocol grammar used by SSE producers and consumers. A value emitted by the builder should not be rejected by the parser when its source address satisfies the shared publication contract. Proposed direction Allow up to 16 digits in the event-ID grammar and retain Number.isSafeInteger as the authoritative numeric bound, matching the generation parser's approach. Acceptance criteria IDs built with Number.MAX_SAFE_INTEGER parse successfully. Values abov