Context
Surfaced by the R3 clj-refactor pass on the Phase 11b Jobs PR (#3). Deliberately out of scope for any of the Wave 1 branches because it's a cross-codebase pattern, not a single track's responsibility.
Pattern
(and (msg/key-press? msg) (msg/key-match? msg "y"))
Always paired — key-press? guards that the message is a keystroke at all; key-match? checks the specific key. The two are never used apart in our code.
Counts
| File |
Instances |
src/eca_cli/chat.clj |
18 |
src/eca_cli/state.clj |
3 |
src/eca_cli/picker.clj |
3 |
src/eca_cli/login.clj |
1 |
| Total |
25 |
Proposed approach
Introduce a single predicate that takes a message + a key string and returns true when both key-press? and key-match? are true, e.g.
(defn key=? [msg k]
(and (key-press? msg) (key-match? msg k)))
Probably belongs in whichever namespace currently exposes msg/key-press? and key-match? (likely charm.message — confirm before placing). If those live outside this repo, the helper goes in a local eca-cli.keys (new ns) or alongside the existing dispatch helpers.
Mechanism / policy framing
key=? is pure mechanism: context-free, reusable, easy to test in isolation. The current inline (and ...) boilerplate is mechanism leaking into policy-heavy dispatch tables, making them noisier than necessary.
Out of scope
- No semantic changes to any dispatch decision — pure refactor.
- Tests should remain green without modification.
- Not touching
key-press? / key-match? themselves.
Sizing
Single file diff per call-site, mechanical. Maybe 2–3 hours including a clj-refactor pass and lint cleanup. Good candidate for a future parallel-agent wave or a single small PR.
Discovered by
R3 (clj-refactor) agent on the Jobs branch flagged it as "30+ duplications in chat.clj alone" — actual count tighter (25 total across 4 files) but the smell is real.
Context
Surfaced by the R3 clj-refactor pass on the Phase 11b Jobs PR (#3). Deliberately out of scope for any of the Wave 1 branches because it's a cross-codebase pattern, not a single track's responsibility.
Pattern
Always paired —
key-press?guards that the message is a keystroke at all;key-match?checks the specific key. The two are never used apart in our code.Counts
src/eca_cli/chat.cljsrc/eca_cli/state.cljsrc/eca_cli/picker.cljsrc/eca_cli/login.cljProposed approach
Introduce a single predicate that takes a message + a key string and returns true when both
key-press?andkey-match?are true, e.g.Probably belongs in whichever namespace currently exposes
msg/key-press?andkey-match?(likelycharm.message— confirm before placing). If those live outside this repo, the helper goes in a localeca-cli.keys(new ns) or alongside the existing dispatch helpers.Mechanism / policy framing
key=?is pure mechanism: context-free, reusable, easy to test in isolation. The current inline(and ...)boilerplate is mechanism leaking into policy-heavy dispatch tables, making them noisier than necessary.Out of scope
key-press?/key-match?themselves.Sizing
Single file diff per call-site, mechanical. Maybe 2–3 hours including a clj-refactor pass and lint cleanup. Good candidate for a future parallel-agent wave or a single small PR.
Discovered by
R3 (clj-refactor) agent on the Jobs branch flagged it as "30+ duplications in chat.clj alone" — actual count tighter (25 total across 4 files) but the smell is real.