Commands are case sensitive.

[Arnaxx54]

Upon entering the command Order cake, it returned Unknown Command. This is inconvenient for the user as he/she will have to remember the exact format of each command. The error message also doesn't inform the user that the error might be because of wrong use of uppercase letters. This might give the impression that the command does not exist.

Moreover, not all commands are lower case. Example: deleteOrder.

[nus-pe-bot]

Team's Response

This issue raises the same concern as per the one in #3413. Our response is the same:

Thank you for your feedback. We understand that making commands case-insensitive could reduce minor typing errors and potentially improve convenience for some users. However, the current implementation of case sensitivity is intentional and consistent with the app's CLI design, which emphasizes precision and clarity.

For our primary users, restaurants this is not a significant concern, as they typically use consistent casing when entering commands as part of their operational workflows. This minimizes the likelihood of errors arising from accidental capitalization.

Furthermore, this behavior aligns with industry-standard CLI tools, which often rely on case-sensitive commands. Maintaining this consistency ensures that the app remains predictable and intuitive for users familiar with similar tools. Our focus is on features that directly enhance core functionality and usability, which we believe have a greater impact on our target audience.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

case-sensitivity for commands

Case sensitivity for help command is unnecessary, as it reduces users CLI typing speed if they accidentally mis-click the shift and capitalise a letter for example.

---

_{[original: nus-cs2103-AY2425S1/pe-interim#2501] [original labels: type.FeatureFlaw severity.Low]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thank you for your feedback. We understand that making commands case-insensitive could reduce minor typing errors and potentially improve convenience for some users. However, the current implementation of case sensitivity is intentional and consistent with the app's CLI design, which emphasizes precision and clarity.

For our primary users, restaurants this is not a significant concern, as they typically use consistent casing when entering commands as part of their operational workflows. This minimizes the likelihood of errors arising from accidental capitalization.

Furthermore, this behavior aligns with industry-standard CLI tools, which often rely on case-sensitive commands. Maintaining this consistency ensures that the app remains predictable and intuitive for users familiar with similar tools. Our focus is on features that directly enhance core functionality and usability, which we believe have a greater impact on our target audience.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** Thank you for your feedback. You've mentioned in your response that the case sensitivity within your application is consistent. A counter example would be `deleteOrder` vs `listarchive`. Moreover, my bug report mentions that the application returns the wrong feedback message stating `Unknown Command`. Instead, it should inform the user that they have utilised incorrect capitalisation. Your response does not provide a relevant explanation for this incorrect user feedback message.

---

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.DocumentationBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---