Extract reusable application logic from CLI command handlers
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- node.js, typescript
- Domain
- cli
Research direction
Start by locating the next command handler and tracing its calls into the engine and storage layers; the issue does not name specific files. Read the validation architecture in #25 for related context, then identify a genuinely reusable use-case and add focused tests that do not depend on Commander or process handling. Done means one command uses that boundary while preserving output and behavior, with CLI formatting and exit handling remaining in the CLI.
Written by the indexing model from the issue text.
Description
Summary
Several CLI command handlers currently combine argument handling, configuration loading, vault/storage access, domain logic, output formatting, and process/exit handling. This is manageable while the command surface is small, but it will make PALEE harder to evolve as more interfaces and commands are added.
This issue is specifically about establishing a reusable application/service boundary between the CLI and the engine/storage layers. It is not a rewrite of the whole architecture.
Problem
A command such as palee next currently performs multiple responsibilities in one command module:
- load configuration
- validate/load the vault
- collect notes
- apply scheduling/recommendation logic
- sort/filter results
- format human output
- format JSON output
- handle CLI errors and exit behavior
If another interface later needs the same behavior (for example a TUI, web UI, or AI tool), that logic should not have to be copied out of the CLI handler.
Proposed direction
Introduce a small application layer for reusable use-cases, for example:
src/application/
get-next-topics.ts
record-review.ts
build-plan.ts
...
Target shape:
CLI / other interface
↓
Application use-case
↓
Engine + storage
The CLI should primarily parse arguments, invoke the use-case, format the result, and map errors to exit codes.
Scope
- Identify command handlers where domain/application logic is mixed with CLI concerns.
- Extract only genuinely reusable logic; do not create unnecessary abstractions.
- Start with
nextas the reference migration. - Keep behavior and output compatibility unchanged unless intentionally documented.
- Add unit tests for the extracted use-case independent of Commander/process handling.
- Document the intended CLI → application → engine/storage boundary.
Acceptance criteria
- At least one representative command has its core use-case callable without Commander or
process.exit. - CLI-specific formatting and exit handling remain in the CLI layer.
- Extracted application logic has focused tests.
- No duplicated domain logic is introduced.
- The architecture remains incremental rather than requiring a broad rewrite.
Related
The validation architecture in #25 already identifies this same responsibility-mixing problem specifically for validate. This issue covers the broader command/application boundary without duplicating the validation-rule work.
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 0
- Avg merge
- 23h 35m
- Merged PRs (30d)
- 159
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Kuldeep2822k/cli
-
core priority: medium tests
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Kuldeep2822k/cli#484 ·
Maintainers usually reply within 1 day
-
bug core priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Kuldeep2822k/cli#343 · 1 comment ·
Maintainers usually reply within 1 day
-
bug core priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Kuldeep2822k/cli#342 · 1 comment ·
Maintainers usually reply within 1 day
-
bug core priority: medium tests
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Kuldeep2822k/cli#304 · 1 comment ·
Maintainers usually reply within 1 day
-
bug core tests
Difficulty 4/5 3-5 days Newbie friendliness 42/100
Kuldeep2822k/cli#514 ·
Maintainers usually reply within 1 day
All issues in Kuldeep2822k/cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
diegosouzapw/OmniRoute#17386 ·
Maintainers usually reply within 1 day
-
ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
area/dashboard kind/bug kind/bug-qa QA/dev-automation
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
vybestack/llxprt-code#3917 · 1 comment ·
Maintainers usually reply within 1 day
-
api-parity
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
IBM/carbon-components-ember#1157 ·
Maintainers usually reply within 1 day