DEV Community: Noor Ul Huda

Orderly: An AI WhatsApp Order-Taker That Refuses to Guess

Noor Ul Huda — Sun, 25 Oct 2026 12:26:54 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2

Orderly: An AI WhatsApp Order-Taker That Refuses to Guess
Small shops often receive customer orders through WhatsApp like:

“2 kg rice, 1 litre oil, and 1 kg sugar.”

But real messages can be much messier — Telugu + English, corrections, unclear quantities, or voice notes.

The difficult part isn't just understanding the message.

The real problem is knowing whether the AI understood the complete order correctly.

That's why I built Orderly.

What I Built
Orderly is an AI-assisted WhatsApp order-taker for small shops.

It converts messy text and voice orders into structured orders and checks them before confirmation.

The core principle is:

AI extracts. Code verifies. Catalog decides. Human confirms when evidence is insufficient.

If the order is clear and the evidence is sufficient, Orderly can mark it CONFIRMED.

If something is unclear, missing, incomplete, or unsafe to verify, it returns NEEDS_REVIEW instead of guessing.

Demo
🎥 Watch the Orderly Demo Video

The demo shows Orderly processing customer orders, validating extracted items, and handling cases where confirmation should not be automatic.

Video Transcript
Hi, this is Orderly, an AI-powered WhatsApp order-taker for small shops.

It handles messy text and voice orders, including Telugu-English messages.

The key principle is:

AI extracts. Code verifies. Catalog decides. Human confirms when evidence is insufficient.

Orderly checks the extracted items against the catalog and validates the customer's request.

If the evidence is sufficient, the order can be CONFIRMED.

If anything is unclear or incomplete, Orderly returns NEEDS_REVIEW instead of guessing.

The goal is simple:

Never falsely confirm an incomplete order.

Try Orderly, explore the code, and share your feedback or ideas for improving safe AI-powered ordering for small shops.

Code
🔗 GitHub Repository

Orderly is built as a small Python application with:

Web interface
CLI
Deterministic validation
Catalog checks
Automated safety tests
Fake extractors for deterministic adversarial testing
How I Built It
The pipeline is:

Customer message → transcription → AI extraction → deterministic validation → catalog verification → confirmation/review

For voice orders, speech is transcribed before extraction.

The AI produces structured order information, but the application does not treat the AI response as proof that the extraction is complete or correct.

The deterministic code checks the extracted information against the customer's message and the shop catalog.

This separation is intentional.

An LLM can misunderstand a message, hallucinate an item, or simply miss something.

So the system is designed so that:

AI proposes. Code verifies. Evidence determines whether confirmation is allowed.

Safety First
One of the biggest risks I focused on was customer-item omission.

For example, if a customer says:

“2 kg rice and 5 litres sunflower oil”

but the AI extracts only:

“2 kg rice”

a normal pipeline might accidentally confirm the incomplete order.

Orderly is designed to treat this as a NEEDS_REVIEW situation rather than assuming that the extracted list is complete.

I specifically tested adversarial cases involving:

Multiple products with one item omitted
Three products with one or more items omitted
Middle-item omission
Final-item omission
The same product with different sizes
Corrections
Mixed Telugu + English orders
“And also” constructions
Long messages containing unrelated text
The goal is not to maximize the number of CONFIRMED orders.

The goal is to avoid falsely confirming an incomplete order.

Why Open Innovation Matters
This project uses open-source AI because useful AI systems should not always require a closed cloud service.

Open models and open-source tools make it possible for developers to experiment, inspect the pipeline, run models locally, and build systems for specific real-world problems.

For a small-shop use case, local and open tooling can also provide more control over how customer data is processed.

The important lesson for me is that open AI becomes more useful when it is combined with traditional deterministic software rather than being trusted blindly.

My Agent Session
I used AI-assisted development to inspect the project, improve the implementation, create adversarial safety tests, investigate edge cases, and verify the application.

The development process focused heavily on finding cases where an AI extraction could appear correct while still being incomplete.

That led to a stronger design principle:

Never confuse a successful AI response with proof that the customer's complete request was understood.

Testing
The automated test suite contains 156 tests: 155 passed, 0 failed, and 1 expected failure (xfail).

Orderly automated test suite showing 156 tests collected, with 155 tests passed, 0 failed, and 1 expected failure (xfail). The terminal output demonstrates the project's deterministic safety, validation, and adversarial testing results.

The expected failure is intentional. It documents a known limitation involving an unknown product such as bellam when the extractor completely omits that product and the customer message does not provide enough recognizable evidence for the completeness checker to detect the omission.

The limitation is documented rather than hidden.

The tests are primarily deterministic safety and validation tests. They use controlled/fake extraction behavior to test whether the application fails safely when extraction is incomplete.

Real-Gemma validation was not performed in the current environment, so these test results should not be interpreted as evidence of real-model extraction quality.

Current Limitations
Orderly is a prototype, not a production-ready autonomous ordering system.

Completeness is difficult to guarantee perfectly for:

Completely unknown products
Ambiguous language
Speech-recognition errors
Unusual phrasing
Product names appearing in unrelated text
Corrections that are difficult to resolve
Messages where the customer's intent cannot be reliably identified
A particularly important limitation is that a completeness checker cannot mathematically prove that an LLM extracted every possible customer intent from arbitrary natural language.

Therefore, the safest behavior is to request human confirmation whenever sufficient evidence is unavailable.

Because of this documented limitation, Orderly should not be considered production-safe for unattended autonomous ordering.

Final Thoughts
Orderly started as an AI order-taking idea, but the more important lesson became verification.

AI is good at understanding messy human language.

Code is better at enforcing deterministic rules.

Putting the two together creates a safer system than relying on either one alone.

AI extracts. Code verifies. Catalog decides. Human confirms when evidence is insufficient.

The most important design decision was not making the AI say CONFIRMED.

It was making sure that when the system cannot establish that the customer's complete request is represented, it refuses to guess.

Try Orderly, explore the code, and share your feedback or ideas for making AI-powered ordering safer for small shops.

devchallenge #weekendchallenge #hf26challenge #opensource #ai #python

MediaMind _ hf26challenge

Noor Ul Huda — Sat, 24 Oct 2026 22:44:37 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

Prize Categories

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

MediaMend is a local AI assistant for people who record far more media than they will ever review: blurry photos, black video frames, silent recordings, empty files, duplicates.

The lazy way to clean that up is "delete everything below a threshold", and that is also the way to lose the one blurry, unrepeatable shot that mattered. MediaMend takes a safer lazy path:

Scan a folder. Everything runs on your computer. Nothing is uploaded.
Review a short queue of flagged files, each with a reason and a confidence level.
Move to Bin. Approved files leave your folders but are not deleted.
Restore, Archive or Delete permanently from the Bin. Permanent deletion needs a separate confirmation.

You never inspect the whole folder. You only judge the cases the tool is unsure about.

Code

https://github.com/noorulhuda07/mediamend

How I Built It

Deterministic checks for measurable problems: OpenCV Laplacian variance for blur, resolution checks, sampled video frames for blank-frame share, FFmpeg decoding for silence measured relative to each recording's own level, SHA-256 for exact duplicates.
A local open-weight vision-language model for judgment: [model name and tag, e.g. via Ollama] looks at flagged photos and answers one narrow question: could this imperfect image still be worth keeping? It returns structured JSON that I validate. If the model is unavailable or answers badly, the app says so instead of faking a result.
A safety layer: every move records the original path, size and SHA-256 in a manifest and verifies the checksum afterwards. Restore never overwrites an existing file, and nothing outside the scanned folder can be touched.
Stack: Python, Streamlit, OpenCV, FFmpeg, [Ollama + model].

Technical measurements and AI opinions are stored separately, so a model's guess never overwrites measured evidence.

Results

I tested on [N] labelled files ([N] photos, [N] videos, [N] audio, [N] other). Ground truth was labelled before scanning.

Metric	Result
Blur precision / recall	[x/y], [x/y]
False positives on must-keep files (rules only)	[n]
False positives on must-keep files (rules + AI)	[n]
Bin/restore checksum success	[x/y]
Scan time ([N] files)	[seconds]
AI time per photo	[seconds] on [hardware]

Where it failed: [real examples, e.g. a dark but valid photo flagged as blurry because low contrast lowers the sharpness score; the model's wrong call on ...]. The thresholds are starting points I tuned on this set, not universal values.

Why Open Innovation Matters

Privacy: personal photos and voice recordings never leave the machine.
Control: I can swap or compare models ([model A] vs [model B]) and inspect the exact prompt and outputs.
Cost: no per-image API fees for scanning thousands of files.
Transparency and reproducibility: the code, prompt, thresholds and test set are public, so anyone can rerun the benchmark and see the failures.

The honest trade-off: [hardware needs, model speed on your laptop, accuracy limits].

Limitations

AI cannot judge creative value perfectly. Deleting from the Bin may not securely erase every copy on SSDs, backups or synced folders. [Anything else you observed.]

devchallenge #hf26challenge

MediaMend

Noor Ul Huda — Sat, 24 Oct 2026 22:39:02 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

MediaMend is a local AI assistant for people who record far more media than they will ever review: blurry photos, black video frames, silent recordings, empty files, duplicates.

The lazy way to clean that up is "delete everything below a threshold", and that is also the way to lose the one blurry, unrepeatable shot that mattered. MediaMend takes a safer lazy path:

Scan a folder. Everything runs on your computer. Nothing is uploaded.
Review a short queue of flagged files, each with a reason and a confidence level.
Move to Bin. Approved files leave your folders but are not deleted.
Restore, Archive or Delete permanently from the Bin. Permanent deletion needs a separate confirmation.

You never inspect the whole folder. You only judge the cases the tool is unsure about.

Code

https://github.com/noorulhuda07/mediamend

How I Built It

Deterministic checks for measurable problems: OpenCV Laplacian variance for blur, resolution checks, sampled video frames for blank-frame share, FFmpeg decoding for silence measured relative to each recording's own level, SHA-256 for exact duplicates.
A local open-weight vision-language model for judgment: [model name and tag, e.g. via Ollama] looks at flagged photos and answers one narrow question: could this imperfect image still be worth keeping? It returns structured JSON that I validate. If the model is unavailable or answers badly, the app says so instead of faking a result.
A safety layer: every move records the original path, size and SHA-256 in a manifest and verifies the checksum afterwards. Restore never overwrites an existing file, and nothing outside the scanned folder can be touched.
Stack: Python, Streamlit, OpenCV, FFmpeg, [Ollama + model].

Technical measurements and AI opinions are stored separately, so a model's guess never overwrites measured evidence.

Results

I tested on [N] labelled files ([N] photos, [N] videos, [N] audio, [N] other). Ground truth was labelled before scanning.

Metric	Result
Blur precision / recall	[x/y], [x/y]
False positives on must-keep files (rules only)	[n]
False positives on must-keep files (rules + AI)	[n]
Bin/restore checksum success	[x/y]
Scan time ([N] files)	[seconds]
AI time per photo	[seconds] on [hardware]

Why Open Innovation Matters

Privacy: personal photos and voice recordings never leave the machine.
Control: I can swap or compare models ([model A] vs [model B]) and inspect the exact prompt and outputs.
Cost: no per-image API fees for scanning thousands of files.
Transparency and reproducibility: the code, prompt, thresholds and test set are public, so anyone can rerun the benchmark and see the failures.

The honest trade-off: [hardware needs, model speed on your laptop, accuracy limits].

Limitations

AI cannot judge creative value perfectly. Deleting from the Bin may not securely erase every copy on SSDs, backups or synced folders. [Anything else you observed.]

devchallenge #hf26challengehis is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady*

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

Prize Categories

s a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady*

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

Prize Categories

MediaMend

Noor Ul Huda — Sat, 24 Oct 2026 22:33:03 +0000

T*This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

MediaMend is a local AI assistant for people who record far more media than they will ever review: blurry photos, black video frames, silent recordings, empty files, duplicates.

The lazy way to clean that up is "delete everything below a threshold", and that is also the way to lose the one blurry, unrepeatable shot that mattered. MediaMend takes a safer lazy path:

Scan a folder. Everything runs on your computer. Nothing is uploaded.
Review a short queue of flagged files, each with a reason and a confidence level.
Move to Bin. Approved files leave your folders but are not deleted.
Restore, Archive or Delete permanently from the Bin. Permanent deletion needs a separate confirmation.

You never inspect the whole folder. You only judge the cases the tool is unsure about.

Code

https://github.com/noorulhuda07/mediamend

How I Built It

Deterministic checks for measurable problems: OpenCV Laplacian variance for blur, resolution checks, sampled video frames for blank-frame share, FFmpeg decoding for silence measured relative to each recording's own level, SHA-256 for exact duplicates.
A local open-weight vision-language model for judgment: [model name and tag, e.g. via Ollama] looks at flagged photos and answers one narrow question: could this imperfect image still be worth keeping? It returns structured JSON that I validate. If the model is unavailable or answers badly, the app says so instead of faking a result.
A safety layer: every move records the original path, size and SHA-256 in a manifest and verifies the checksum afterwards. Restore never overwrites an existing file, and nothing outside the scanned folder can be touched.
Stack: Python, Streamlit, OpenCV, FFmpeg, [Ollama + model].

Technical measurements and AI opinions are stored separately, so a model's guess never overwrites measured evidence.

Results

I tested on [N] labelled files ([N] photos, [N] videos, [N] audio, [N] other). Ground truth was labelled before scanning.

Metric	Result
Blur precision / recall	[x/y], [x/y]
False positives on must-keep files (rules only)	[n]
False positives on must-keep files (rules + AI)	[n]
Bin/restore checksum success	[x/y]
Scan time ([N] files)	[seconds]
AI time per photo	[seconds] on [hardware]

Why Open Innovation Matters

Privacy: personal photos and voice recordings never leave the machine.
Control: I can swap or compare models ([model A] vs [model B]) and inspect the exact prompt and outputs.
Cost: no per-image API fees for scanning thousands of files.
Transparency and reproducibility: the code, prompt, thresholds and test set are public, so anyone can rerun the benchmark and see the failures.

The honest trade-off: [hardware needs, model speed on your laptop, accuracy limits].

Limitations

AI cannot judge creative value perfectly. Deleting from the Bin may not securely erase every copy on SSDs, backups or synced folders. [Anything else you observed.]

devchallenge #hf26challengehis is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady*

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

Prize Categories

"TrailQuest: an open-weight AI plans your walk, then tells you to put the phone away"

Noor Ul Huda — Sun, 11 Oct 2026 04:52:28 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Most fitness apps want your attention. TrailQuest wants the opposite.

You tell it how you feel today: your energy, your mood, how many minutes you have, indoors or outdoors, and a goal like 8,000 steps. It builds you a short quest: a warm-up, a brisk walk with faster intervals, a nature challenge (like "spot something with three colors"), and a cooldown.

Then you press Start, and the screen turns into a plain timer that says Phone away. Go enjoy it. You walk. When you come back, you log your steps and earn XP and a Touch Grass streak.

The streak counts any finished quest, even an easy recovery walk. It rewards showing up, not pushing harder.

It's for people who want to move more but burn out on apps that demand attention, and for tired days when a gentle 10-minute quest beats skipping.

Demo

▶ Watch the 50-second demo video

In the demo, I create an account with an email code and set a 10-minute outdoor quest. I press Start and the phone-away timer runs. Then I log 3,200 steps and get 82 XP and a 1-day streak. I also open the dashboard, the daily journal, the trail map and the badges, and switch to dark mode with the Ocean theme and miles.

Code

GitHub repo: github.com/noorulhuda07/trailquest

To run it: docker compose up --build, open http://localhost:8080, and click Try the demo.

How I Built It

Stack: React and Vite for the frontend, FastAPI for the backend, Gemma through Ollama for quest generation, SQLite for accounts, and Docker Compose to run it all.

User → FastAPI → Gemma (via Ollama) → Validator → Quest
                         ↓ fails or unavailable
                  Rules-based fallback → Quest

My main rule is AI suggests, code validates. Gemma never talks to the user directly. Its answer must pass these checks first:

Is it valid JSON with all the required fields?
Does the intensity match the energy the user chose?
Do the step durations add up to the time they have?
Does any step contain unsafe wording?
Is it an indoor quest? Then there are no nature challenges.

If a check fails, or Gemma isn't available, a small rules engine builds a safe quest instead. Every quest carries a badge that says which one wrote it: Gemma (gemma3), self-hosted, code-validated or Backup rules engine. The server sets the badge, not the model, so the model can't claim credit it didn't earn.

I also kept free text out of the prompt. Energy, mood and target are fixed options, and the workout type comes from a fixed list, so a user can't smuggle instructions into the model.

Around the AI, I built sign-up with email or phone codes, Google sign-in, a one-click demo mode, and light and dark modes with four color themes. I tested the app with 42 backend tests and 5 frontend tests. The backend tests cover forged login tokens, SQL injection strings, code guessing, rate limits, and malformed or unsafe model output. GitHub Actions runs the tests and security scans on every push.

What I Saw When I Ran It

In my recorded demo, the quest came from the backup rules engine, not from Gemma, and the badge on screen says so. I'd rather show that than hide it. It's the point of the design: a missing or bad AI answer never reaches the user, and the app always gives a safe quest.

Why Does Open Innovation Matter?

Your mood stays yours. A quest request contains your energy, mood and schedule. With an open-weight model running on your own machine, that data doesn't need to leave it.
I can swap the model with one setting. GEMMA_MODEL=gemma3:1b for a laptop with little memory, or a bigger one if you have the hardware. Fine-tuning for coaching styles is possible later.
No bill per quest. Running it costs electricity, not API fees.
I control the guardrails. Because I run the model, I choose the output format and what happens when it misbehaves.

The trade-offs: the first run downloads about 3 GB, and a small model on a CPU is slower and less reliable than a large hosted one. That is exactly why the validator and fallback exist.

My Agent Session

I built TrailQuest with help from an AI coding assistant, then ran and tested the result myself.

What's Next

Weather and location tools so a rainy day gives an indoor quest, then friends, group quests and challenges. Real step tracking comes with a phone app.

Built by noorulhuda07.

Orderly: An AI WhatsApp Order-Taker That Refuses to Guess

Noor Ul Huda — Mon, 05 Oct 2026 07:07:23 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2

Orderly: An AI WhatsApp Order-Taker That Refuses to Guess

Small shops often receive customer orders through WhatsApp like:

“2 kg rice, 1 litre oil, and 1 kg sugar.”

But real messages can be much messier — Telugu + English, corrections, unclear quantities, or voice notes.

The difficult part isn't just understanding the message.

The real problem is knowing whether the AI understood the complete order correctly.

That's why I built Orderly.

What I Built

Orderly is an AI-assisted WhatsApp order-taker for small shops.

It converts messy text and voice orders into structured orders and checks them before confirmation.

The core principle is:

AI extracts. Code verifies. Catalog decides. Human confirms when evidence is insufficient.

If the order is clear and the evidence is sufficient, Orderly can mark it CONFIRMED.

If something is unclear, missing, incomplete, or unsafe to verify, it returns NEEDS_REVIEW instead of guessing.

Demo

🎥 Watch the Orderly Demo Video

The demo shows Orderly processing customer orders, validating extracted items, and handling cases where confirmation should not be automatic.

Video Transcript

Hi, this is Orderly, an AI-powered WhatsApp order-taker for small shops.

It handles messy text and voice orders, including Telugu-English messages.

The key principle is:

AI extracts. Code verifies. Catalog decides. Human confirms when evidence is insufficient.

Orderly checks the extracted items against the catalog and validates the customer's request.

If the evidence is sufficient, the order can be CONFIRMED.

If anything is unclear or incomplete, Orderly returns NEEDS_REVIEW instead of guessing.

The goal is simple:

Never falsely confirm an incomplete order.

Try Orderly, explore the code, and share your feedback or ideas for improving safe AI-powered ordering for small shops.

Code

🔗 GitHub Repository

Orderly is built as a small Python application with:

Web interface
CLI
Deterministic validation
Catalog checks
Automated safety tests
Fake extractors for deterministic adversarial testing

How I Built It

The pipeline is:

Customer message → transcription → AI extraction → deterministic validation → catalog verification → confirmation/review

For voice orders, speech is transcribed before extraction.

The AI produces structured order information, but the application does not treat the AI response as proof that the extraction is complete or correct.

The deterministic code checks the extracted information against the customer's message and the shop catalog.

This separation is intentional.

An LLM can misunderstand a message, hallucinate an item, or simply miss something.

So the system is designed so that:

AI proposes. Code verifies. Evidence determines whether confirmation is allowed.

Safety First

One of the biggest risks I focused on was customer-item omission.

For example, if a customer says:

“2 kg rice and 5 litres sunflower oil”

but the AI extracts only:

“2 kg rice”

a normal pipeline might accidentally confirm the incomplete order.

Orderly is designed to treat this as a NEEDS_REVIEW situation rather than assuming that the extracted list is complete.

I specifically tested adversarial cases involving:

Multiple products with one item omitted
Three products with one or more items omitted
Middle-item omission
Final-item omission
The same product with different sizes
Corrections
Mixed Telugu + English orders
“And also” constructions
Long messages containing unrelated text

The goal is not to maximize the number of CONFIRMED orders.

The goal is to avoid falsely confirming an incomplete order.

Why Open Innovation Matters

This project uses open-source AI because useful AI systems should not always require a closed cloud service.

Open models and open-source tools make it possible for developers to experiment, inspect the pipeline, run models locally, and build systems for specific real-world problems.

For a small-shop use case, local and open tooling can also provide more control over how customer data is processed.

The important lesson for me is that open AI becomes more useful when it is combined with traditional deterministic software rather than being trusted blindly.

My Agent Session

I used AI-assisted development to inspect the project, improve the implementation, create adversarial safety tests, investigate edge cases, and verify the application.

The development process focused heavily on finding cases where an AI extraction could appear correct while still being incomplete.

That led to a stronger design principle:

Never confuse a successful AI response with proof that the customer's complete request was understood.

Testing

The automated test suite contains 156 tests: 155 passed, 0 failed, and 1 expected failure (xfail).

The expected failure is intentional. It documents a known limitation involving an unknown product such as bellam when the extractor completely omits that product and the customer message does not provide enough recognizable evidence for the completeness checker to detect the omission.

The limitation is documented rather than hidden.

The tests are primarily deterministic safety and validation tests. They use controlled/fake extraction behavior to test whether the application fails safely when extraction is incomplete.

Real-Gemma validation was not performed in the current environment, so these test results should not be interpreted as evidence of real-model extraction quality.

Current Limitations

Orderly is a prototype, not a production-ready autonomous ordering system.

Completeness is difficult to guarantee perfectly for:

Completely unknown products
Ambiguous language
Speech-recognition errors
Unusual phrasing
Product names appearing in unrelated text
Corrections that are difficult to resolve
Messages where the customer's intent cannot be reliably identified

A particularly important limitation is that a completeness checker cannot mathematically prove that an LLM extracted every possible customer intent from arbitrary natural language.

Therefore, the safest behavior is to request human confirmation whenever sufficient evidence is unavailable.

Because of this documented limitation, Orderly should not be considered production-safe for unattended autonomous ordering.

Final Thoughts

Orderly started as an AI order-taking idea, but the more important lesson became verification.

AI is good at understanding messy human language.

Code is better at enforcing deterministic rules.

Putting the two together creates a safer system than relying on either one alone.

AI extracts. Code verifies. Catalog decides. Human confirms when evidence is insufficient.

The most important design decision was not making the AI say CONFIRMED.

It was making sure that when the system cannot establish that the customer's complete request is represented, it refuses to guess.

Try Orderly, explore the code, and share your feedback or ideas for making AI-powered ordering safer for small shops.

devchallenge #weekendchallenge #hf26challenge #opensource #ai #python