feat: add receipt data structure, receipt repository, and get receipts data

[4shb0rne]

Adding basic structure for receipt, receipt repository (to fetch data from persistance storage), and slash command for getting all receipt data in that specific channel

Issue : #6

Note :

• Currently receipt structure save receiptDate data in string since i have concern where there is different format of a date like DD/MM/YYYY and MM/DD/YYYY (can update this later)

Demo :
https://youtu.be/FTD9vMYv-mQ

[Sing-Li]

few comments above - to make it more generic allowing for freeform evolution of the app.

[Sing-Li]

excellent work! Thanks for your contributions. We can definitely up-level this project for 2025.

[Sing-Li]

kudos! Separating the prompts is the most important thing to do in "prompt engineering heavy" project like this one. We will end up with bits and pieces of prompts everywhere if not careful and the project will become unmanageable over time.

This is why we have #7

Can you please modify this file to become more of a "prompt library" and/or "prompt repository" as specified above. You don't have to add any of the other cases. Just put these existing prompts into a structure as described so you call something like PromptLib.getReceiptScanPrompt() (just a suggestion, use your own naming) to get the RECEIPT_SCAN_PROMPT etc. And then add one or two unit tests. This will start a basis that other can readily contribute to 🙏

Be sure to separate the set of prompts by model (name including version, num parameters, quantization) in the implementation. This will allow the app to migrate to different but similar models without code rewrite -- just testing with a variation and then update the prompts.

A "bonus idea" is to implement some sort of "prompt engineers dev-mode" where the prompts are persisted at runtime and then made modifiable in the App Settings, allowing the end admin/user to customize their own prompt for the llm that they may be using. (but pls don't do it for this PR)

[Sing-Li]

brilliant! I think something like this can become prompt-engineering best practices.

[Sing-Li]

good enough set of exceptions handled. contributors can always add to this as the project evolve.

[Sing-Li]

I don't know what to say here.

I think the implementation is good enough for this specific purpose.

But on the other hand, we MUST layer this so the app can grow without having to rewrite all of this.

It is the entire reason why we have:

#6

I think I need to ask you to add shallow implementation of the following:
- separate getbyUserXXXXX onto another top layer (since app does server-wide handling on user's behalf)
- add some sort of chained (index) operation - such as getReceiptsFromRoomOrderedByScannedReceiptDate (again, pls don't use these my verbose naming 🙏 ) as a basis for other contributors to build on as we better define what the "schema" + "indexes" should really be in this app.