DEV Community: Chestly Ace

DuckWalk: a rubber duck that won't talk to you until you go outside

Chestly Ace — Mon, 12 Oct 2026 02:39:08 +0000

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

What I Built

I kept skipping breaks while coding, not out of willpower but because leaving the desk felt like it would cost me my mental context. So I built something that removes that cost on purpose.

DuckWalk watches for when you're stuck, writes down exactly where you are so there's nothing to lose by leaving, and pings your phone with one line. Then it makes you actually go outside before it'll say another word. Once you're walking, a Socratic duck talks you through the problem by voice, your screen off the whole time, asking questions and never handing you the fix.

A laptop daemon watches signals like time since your last break, failed test runs, how many times you've touched the same file, and undo ratio, and scores each 5-minute window with TabPFN. Cross a threshold, and it grabs a breadcrumb (your branch, diff, last terminal error) and compresses it into a 60-word note with Gemma. Your phone buzzes with that note, self-hosted so it never touches a third party's server. You tap "Walk," the screen goes black except for a stop button, and outside you talk it through while the duck asks questions back. When you're done, one screen tells you what you worked out and what to try next, readable in about ten seconds.

The rule I held myself to the whole build: minimize time looking at a screen. If a feature didn't push work onto the AI, it got cut.

Underneath, it's a durable Temporal workflow, every stage traced in Sentry, and the duck's voice is a 4B model I fine-tuned on Tinker until it matched a much larger cloud model on this specific job.

Demo

I'm writing this at 2am, and the whole point of the project is a real walk outside, so I wasn't going to fake that with a clip filmed at my desk. What I can show instead is something that doesn't need daylight: a real crash mid-conversation, and Temporal picking it back up without losing a word.

Duck: It's intermittent. What distinguishes the times it passes from the times it doesn't?
You: I've got an integration test and go that times out sometimes...
--- worker process killed here, restarted 5 seconds later ---
Duck: Sorry, I lost you for a moment. Where were we?
You: I've got an integration test and go that times out sometimes...
Duck: It's intermittent. When it only gets two events, is the third one missing...

That's a real transcript from killing the worker process mid-walk and bringing it back up five seconds later. The other three failure drills (Ollama going down, the phone going offline, a malformed detector input) are in docs/traces/phase8-drills.md, and the actual outdoor walk-through is scripted shot by shot in demo-script.md for whenever the sun's up.

Code

chestlyace / DuckWalk

A local-first AI companion that notices when a developer is stuck, gets them away from the screen, and helps them think out loud while they walk. The screen is the shortest part of the experience.

DuckWalk

A local-first AI companion that notices when a developer is stuck, gets them away from the screen, and helps them think out loud while they walk. The screen is the shortest part of the experience.

Setup

Linux x86_64. Requires uv, Ollama, git, cmake, a C++ compiler and curl.

bash scripts/setup.sh

This installs Python 3.12 and the dependencies, pulls gemma4:e4b (local default), and puts the Temporal CLI, whisper.cpp (base.en) and the Piper voice (en_US-lessac-medium) under vendor/ (gitignored). It also creates .env from .env.example. Add your SENTRY_DSN there. To use Ollama's cloud instead of a local model, set OLLAMA_MODEL=gemma4:31b-cloud (requires ollama signin and ollama pull gemma4:31b-cloud).

Then check everything:

vendor/bin/temporal server start-dev     # separate terminal; UI at http://localhost:8233
uv run python scripts/doctor.py          # pass/fail table for every service
uv run python scripts/doctor.py --sentry-test   # also sends a test error to Sentry

The Flutter…

View on GitHub

How I Built It

The stuck detector runs on TabPFN: six features per 5-minute window, no hyperparameter tuning, no feature engineering past picking honest signals. It's meant to be the thing that decides for you that it's time to stop, which only works if it's not annoying about it, so there's also flow protection (don't nudge during a high-edit-rate streak with nothing broken) and natural-break timing (hold the nudge for the next commit or green test instead of interrupting mid-thought).

Gemma writes the breadcrumb and the nudge. gemma4:e4b runs locally by default, and the same prompts work fine against gemma4:31b-cloud on machines that can't run it locally. The breadcrumb is really the whole trick that makes leaving the desk feel safe: the model writes down where you were so you don't have to.

The duck's own voice needed something narrower than general-purpose chat: always exactly one question, never the fix, plain and short. Gemma isn't available through Tinker, so I fine-tuned Qwen3.5-4B on filtered teacher dialogues instead. The untuned model passed a frozen 8-criteria rubric 68% of the time; after tuning, 98%. Measured against the deployed cloud Gemma duck (80%), I'd call that equal quality from a 4B model, not better. A second, independent judge put the two within noise of each other, and I wrote up that caveat along with the rest of the methodology in eval/results.md.

The whole thing runs as one Temporal workflow: breadcrumb, nudge, wait for movement, voice loop, brief, with retries on every LLM call. I needed this because a real walk can drop off wifi for ninety minutes and come back, and the workflow just waits it out. It's also what let the crash-and-resume above happen without losing the conversation.

Sentry traces every stage, tagged with model and token counts. That's how I found a real bottleneck instead of guessing at one: per-turn timings showed speech-to-text eating about 4 seconds a turn, way past the LLM call (0.76s) or the TTS (0.63s). Turned out whisper.cpp was running 5-beam search by default. Switching to greedy decoding cut it to about 2.6 seconds, 36% faster, with identical transcription text. Before-and-after numbers are in docs/traces/phase8-bottleneck.md.

The phone side is Flutter, three screens (nudge, walking, return brief), and it has to handle a walk going out of range: live-streamed to the laptop when reachable, an on-device Gemma conversation when it isn't, syncing the transcript back once it reconnects so the laptop still writes the final brief with the bigger model.

Why Does Open Innovation Matter?

Everything above runs on my own machine unless I deliberately opt out of that. Gemma through Ollama, whisper.cpp, Piper for text-to-speech, a self-hosted push server instead of someone else's, TabPFN doing inference on-device. No code, diffs, prompts, or transcripts leave the laptop. The only thing that goes out is Sentry trace metadata, and by design that's never the content of what you said, just how long each stage took.

Being able to swap the pieces is also what let me actually measure anything instead of trusting a vendor's claim. I pointed the duck's backend at Ollama, a local llama-server, and Tinker's cloud, one env var at a time, and compared them directly. The fine-tuning number above only exists because Tinker made training and serving a small open model cheap enough to run that comparison for real.

And it costs nothing to run every day, which matters for something meant to interrupt you several times a shift. A tool you hesitate to use because of a bill is a tool you turn off.

Results

The fine-tuning went from 68% to 98% on a frozen 50-prompt rubric, matching a much larger cloud model on a 4B budget. Full caveats in eval/results.md.

For reliability: a 2-hour run, 23 walk sessions back to back across 5 bug scenarios and 3 scripted conversations, zero failures and no manual intervention. My dev machine actually rebooted partway through the night, so I confirmed this straight from Temporal's own workflow history rather than a log file that didn't survive.

All four failure drills pass. Ollama going down makes the nudge and brief fall back to canned text instead of killing the walk. The worker restarting mid-conversation resumes without losing anything. The phone going offline just syncs later. A malformed detector input fails with a clear error instead of hanging.

What isn't done: the stuck detector has no real held-out precision or recall yet. Hand-labeling real work windows didn't get finished before the deadline, so I'm saying that plainly instead of papering over it with a synthetic number. ml/train_detector.py is ready to produce the real learning curve the moment there's labeled data to feed it.

Prize Categories

Best Use of Gemma. Writes the breadcrumb, the nudge, the walk-mode pick, and the return brief, and was also the teacher model behind the fine-tuning data and the eval judge.

Best Use of TabPFN. Classifies each 5-minute window as stuck or flow from six local signals with no feature engineering or tuning. I'll say the caveat up front: real held-out metrics aren't collected yet, for the reason above. The classifier, its Sentry instrumentation, and its failure handling are all real and tested regardless.

Best Use of Tinker. Took a 4B model from 68% to 98% on an 8-criteria behavioral rubric, with real before-and-after numbers and a second judge checking the first one's work, not just a vibe.

Best Use of Temporal. The crash-and-resume up top isn't a demo trick. It's the actual thing that turns a phone losing signal for an hour into a non-event instead of a risk of losing the whole walk.

Best Use of Sentry Agent Tracing. Full per-stage tracing is what turned a guess about the bottleneck into a measured 36% fix, and it's the backbone of all four failure drills.

Plumb: I built my friend a tutor for her own codebase, because "the AI writes the code now"

Chestly Ace — Sun, 04 Oct 2026 17:24:15 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

A friend of mine, a software engineer, asked me a question I couldn't shake: why should she keep learning when an AI agent can write the code?

I didn't want to answer with a lecture, so I built her an answer instead. Plumb is a tutor for her own codebase. It doesn't write code. It makes sure she stays the person who understands it.

You run tutor in a repo and it opens a chat:

Before a change, describe what you're about to build ("let users mark items as favorites"). Plumb reads the real files, explains what the change touches and which patterns to follow, then asks 2–3 questions about the design choices. Each has 2–3 reasonable answers, never trick distractors.
"I don't understand" is always an option. Plumb then explains the concept using her own code, and checks with one question.
After the change, /review reads the diff and compares it with the decisions she made earlier: followed, changed, or not addressed.
/tour walks the repo from an entry point outward, one file per stop.
Skip is free. Any question can be skipped. Skipped topics come back later, at a calm moment, never as a nag.

Two things matter more than any feature:

Every claim cites file:lines, and Plumb checks every citation against the real file before she sees it. Wrong files, lines past the end, or lazy ranges like models.py:14-113 are struck through on screen.
Every "why" is labeled. documented means a commit message or doc said so, and Plumb verifies it actually saw that commit. inferred means it's the model's reading. confirmed means she agreed. A guess is never presented as fact.

What she knows, what she skipped and what she decided live in a .tutor/ folder of plain JSON files in her project, which she can open, edit or delete.

Demo

That's a real, unedited session on the public FastAPI full-stack template. Waits are fast-forwarded. In order:

the request is typed;
the explanation streams in, with citations highlighted;
two citations get rejected as too broad;
a design question about the N+1 problem;
"I don't understand" on the next one;
an explanation built from the repo's own User / UserPublic models;
a check question.

This recording used the hosted gemma4:31b-cloud through Ollama. On her laptop it runs on a local Gemma.

Code

chestlyace / Plumb-cli

Plumb-cli is a local-first command-line tool that teaches a developer her own codebase, and checks she understands each architectural decision before and after code is written. It is built for one real person: a software-engineer friend who asked why she should keep learning when an AI agent can write the code.

Plumb

Plumb is a local-first tutor for your own codebase. Before you build a feature, it walks you through what the change touches in your code and asks you a few questions about the design choices. After you've built it, it reviews what changed against what you decided. It can also give you a guided tour of the repo, one file at a time.

It was built for one real person: a software-engineer friend who asked why she should keep learning when an AI agent can write the code. Plumb's answer let the agent write code if you like, but stay the person who understands it.

Runs on your laptop. An open-weight model (Gemma) served by Ollama Your code stays on your machine.
Grounded in your files. Every claim cites file:lines, and Plumb checks each citation against the real file before you see it.
Honest about the "why".…

View on GitHub

She's on Windows, so installing is one line in PowerShell:

irm https://raw.githubusercontent.com/chestlyace/Plumb-cli/main/install.ps1 | iex

Then tutor in any project. The first run is a short guided setup:

It finds Ollama, or offers to install it and starts it.
It reads her RAM and recommends a model: gemma4:e2b (4.6 GB) on an 8 GB laptop, gemma4:e4b (6.6 GB) with more. Then it downloads her pick with a progress bar.
It lets her choose a cloud fallback, or none. It says plainly that a cloud model means her files leave the laptop while it's in use, and it walks her through signing in to Ollama if she picks one.

(macOS and Linux get the same thing with curl … install.sh | sh.)

How I Built It

Gemma 4 via Ollama. Her laptop has no GPU, so Plumb runs a small Gemma 4 on the CPU and picks the size from her memory. The model is one setting. If the local model fails, Plumb switches to the fallback she chose (Gemma 4 31B on Ollama's cloud, by default) for the rest of the session, and tells her so.

Code does the heavy lifting, and each model call gets one small job. A small model gets a narrow context and a single task:

a repo map: tree-sitter symbols, an import graph across Python, JS/TS, Dart and a dozen other languages, git history and entry points, cached by file hash;
six read-only tools (read_file, grep, list_dir, git_log, repo_map, memory) that refuse anything outside the repo, ignored files and .env;
narrow calls: explore and explain, write questions, explain a concept, and a tiny classifier that tells "describe a change" apart from "ask a question".

PydanticAI as the agent loop, behind my own driver interface, with guardrails I wrote around it:

a step limit;
one retry on invalid output;
loop detection, so the model can't re-read the same file forever;
a scripted fake model, so the 187 tests run without Ollama.

Textual for the chat UI. The engine never imports it, and --plain gives the same chat as plain text.

Things Gemma taught me

Gemma answered in prose instead of calling an output tool. With PydanticAI's default tool-based structured output, the model kept writing the question as nicely formatted prose and only produced valid output on its retry. Switching to prompted JSON output gave 3 out of 3 with no retries. That one change is what makes the questions reliable.
It cites lines confidently and imprecisely. In review mode, citations into a diff were off by one or two lines, because a diff only gives a starting line per hunk. Numbering every diff line with its line in the current file fixed that. Now the review points at exactly the right lines.
It cites whole files when it's lazy, so citations wider than 60 lines are rejected. A tutor that says "see lines 1-400" isn't teaching.

Why Does Open Innovation Matter?

Her code stays on her laptop. A tool that reads your whole codebase should not need to send it to a server you don't control. With an open-weight model running locally, it doesn't.
It costs nothing to run, so she can ask "I don't understand" as many times as she wants. A tutor you hesitate to use because of a bill is a bad tutor.
The model is swappable. It's one line in a config file. When a better small open model ships, she switches. I could also test exactly how Gemma behaves (prose instead of tool calls, imprecise line numbers) and design around it, instead of hoping an API keeps behaving the same.
Everything is inspectable. The model, the agent loop, the tools and the memory files are all open. When it tells her something about her code, she can check where it came from. That's the whole point of a tutor.

My Agent Session

Prize Categories

Best Use of Gemma. Gemma 4 is the only model family Plumb uses: a local gemma4:e2b or gemma4:e4b sized to her laptop, and gemma4:31b-cloud as the default fallback. The design is shaped around what a small Gemma can do reliably: narrow calls, prompted JSON, checked citations.

Kyuutai: Turning Fandom Into a Living Diary of Gaming, Anime, and Music

Chestly Ace — Mon, 13 Jul 2026 06:34:04 +0000

This is a submission for Weekend Challenge: Passion Edition

What We Built

Kyuutai is a fandom devotion platform for people who want to track, reflect on, and celebrate the things they love most. Instead of treating fandom like a casual list of favorites, it turns it into an interactive experience built around three passions: gaming, anime, and music.

The project is organized around four connected experiences:

Devotion Log — a journal for recording what I watched, played, or listened to, with mood tags, voice dictation, and a timeline view.
Weekly Recap — an AI-generated narrated summary of the last 7 days of fandom activity, with audio playback.
Passion Card — a personalized passion radar that analyzes top games, anime, and artists into an archetype profile, recommendations, and a downloadable visual card.
OST Detective — a soundtrack guessing game built around real game and anime clips, with AI-written questions and narrator reactions.

Team submission:

Dylane(https://dev.to/yveane) — anime
Ace — gaming
Kanjo(https://dev.to/alchemycodes) — music

The goal was to make fandom feel personal, expressive, and a little dramatic — like a living diary for obsession, taste, and identity.

Demo

Live demo: https://kyuutai.vercel.app
Video demo:

Code

GitHub repository:

yvesdylane / kyuutai

Kyuutai is a passion journal with a twist: tell it what game, anime, or song owned your brain today - by voice or text - and it grows into a living timeline of your fandom.

View on GitHub

How I Built It

Kyuutai is built with Next.js 16, React 19, TypeScript, Tailwind CSS 4, PostgreSQL, NextAuth, Google Gemini, and ElevenLabs.

I kept the app organized with a clean App Router structure and a route -> service -> repository pattern so the HTTP layer, business logic, and SQL stay separated.

Google Gemini powers the intelligence layer. It generates weekly recap scripts, analyzes favorite media into a structured passion profile, and writes the short question/reaction text used in OST Detective. Each feature uses a different prompt style: recap narration is warm and dramatic, passion profiles return structured JSON, and OST Detective uses short game-show-style lines.

ElevenLabs handles the voice layer. It turns recap scripts and passion blurbs into audio files saved under public/audio/, which makes the app feel more like a fandom experience than a standard dashboard.

The Devotion Log also uses browser speech recognition for hands-free note-taking, while OST Detective pulls real soundtrack clips from YouTube using yt-dlp and trims them with ffmpeg for short blind-test rounds.

On the database side, the app uses raw SQL with parameterized queries, UUIDs, and a schema designed around journal entries, recap history, passion cards, and game sessions.

Prize Categories

Best Use of Google AI

Google Gemini is the intelligence layer behind multiple parts of Kyuutai, not just a single feature. It writes the weekly recap narration, transforms favorite media into a structured passion profile, and powers the short question and reaction text in OST Detective. I used different prompt styles for each experience: narrative generation for recap audio, strict JSON output for the Passion Card, and concise game-show style writing for the trivia game. That made Google AI central to both the app’s core functionality and its personality.

Best Use of ElevenLabs

ElevenLabs brings Kyuutai’s emotional layer to life through voice. The app converts AI-generated recap scripts and passion blurbs into spoken audio, making the experience feel like a fandom show rather than just a dashboard. In practice, ElevenLabs is used to create weekly recap narration and the Passion Card voice profile, giving users something they can listen to, not just read. The audio output is part of what makes the app feel immersive and polished.

My First Global Hackathon: What I Learned Building Moonsu Link

Chestly Ace — Sat, 04 Jul 2026 02:14:15 +0000

This was my first global hackathon, with 500+ participants from around the world, and although I didn’t win, I’m honestly proud of how much I learned from the experience.

I worked on Moonsu Link, a project I care about deeply. It wasn’t just about building something technical. It was about trying to solve a real problem and pushing an unfinished idea all the way into something more complete, more usable, and more meaningful.

Like many hackathon projects, Moonsu Link came with its own challenges. There were moments of uncertainty, moments where the product needed more structure, and moments where it would have been easy to slow down or stop. But I kept going because I believed the idea was worth finishing.

The Power of Collaboration & Community

What made this experience special was the teamwork. Building with others, sharing ideas, dividing responsibilities, and trying to keep the momentum alive taught me a lot about collaboration. A hackathon is not just about code. It is also about communication, trust, iteration, and resilience.@alchemycodes @yvesdylane

I also learned that progress matters, even when the final result is not a win. Finishing something, improving it, and learning through the process can be just as valuable as a prize.

One of the things I’m happy about is that I received a badge from the DEVPost community. That recognition means a lot to me because it reflects the effort, growth, and persistence behind the project.

Key Takeaways

This hackathon reminded me that:

First attempts are still valuable – Every expert was once a beginner. Starting is half the battle.
Teamwork makes a huge difference – Bouncing ideas off others and distributing tasks accelerates growth.
Challenges are part of the process – Friction and bugs are inevitable; navigating them builds engineering maturity.
Not winning does not mean losing – The knowledge and connections gained are permanent assets.
Learning and finishing count – Shipping a complete product cycle is a victory in itself.

Moving Forward

Moonsu Link may not have taken the top prize, but it gave me something important: experience, confidence, and a stronger mindset for the next challenge.

I’m grateful for the opportunity, grateful for the people I worked with, and grateful that I chose not to give up.

Have you ever participated in a global hackathon? What was your biggest takeaway from your first dev challenge? Let's connect in the comments below!

From Prototype to Production: Finishing Moonsu Link, a Chat-Native Agricultural Marketplace for Cameroon

Chestly Ace — Sun, 07 Jun 2026 23:58:08 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What We Built

Moonsu Link is a chat-native agricultural marketplace built for farmers and buyers in Cameroon.

In Cameroon, agriculture is central to daily life, but the way products are bought and sold is still fragmented. In many towns, roadside markets and middlemen control access to buyers. In rural areas, farmers often depend on word of mouth, informal contacts, or market days to move their goods.

That creates real friction.

A farmer in Bamenda, Bafoussam, Douala, or Yaoundé may have produce ready, but still struggle to find a buyer quickly, get a fair price, or know where demand is strongest. At the same time, many people already use WhatsApp and Telegram every day, while mobile data costs, app installs, and complicated onboarding can get in the way. Language matters too. Cameroon is bilingual, and any useful product has to feel natural in both English and French while staying simple enough for users with different levels of digital comfort.

Moonsu Link was built to close that gap by bringing the marketplace into the chat apps people already use. The goal is to reduce friction and make trade feel more direct, local, and trustworthy.

The idea is simple:
help farmers list produce easily, help buyers search in plain language, and let both sides trade without needing a separate app.

Instead of pushing users into a dashboard-first experience, Moonsu Link works through WhatsApp and Telegram, the platforms people already know.

With Moonsu Link, a farmer can list produce with location, price, quantity, and optional photos. Buyers can search naturally, compare listings, check market prices, and express interest. The platform also supports farmer verification, community reports, farming advice, voice messages, and cross-platform use across WhatsApp and Telegram.

What began as an unfinished idea is now a real product with a clear user flow, a polished web presence, and a backend that connects messaging, AI, search, verification, and notifications into one system.

Demo

Live app: https://moonsulink.vercel.app
GitHub repository:https://github.com/yvesdylane/Moonsun-Link-api , https://github.com/yvesdylane/MoonsuLinkFrontend
Video walkthrough: https://youtu.be/6skq9w_mw-s?si=c5YCVunZ3RC5Qfqs
Screenshots:!Moonsu Telegram Bot(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b1ewivz77iwyli4gh01a.jpeg) , !Moonsu Whatsapp (https://dev-to-uploads.s3.amazonaws.com/uploads/articles/op3lmh99vio6zbxu4bcl.jpg) , !Moonsu Admin Dahboard(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cit70l8bc84pijmworrj.jpg)

The Comeback Story

!Moonsu website before finishathon(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2nlqiwperncglto84re2.png)
Moonsu Link did not start as a finished product. It began as a prototype built around a real problem, but like many hackathon projects, it never fully crossed the finish line.

The idea was strong, but the product needed more structure, cleaner UX, better flow, and real end-to-end functionality before it could genuinely help users.

For this challenge, We came back to it with a different mindset. We treated it like a real product, not just a demo.

That meant focusing on the things that matter most:

making the experience feel unified across WhatsApp, Telegram, and the web
refining the landing page so the product story is clear immediately
building a visual identity that reflects a Cameroon-first agricultural context
improving backend flows for messaging, listings, verification, search, and notifications
making the product feel trustworthy, usable, and ready to present to real users

The biggest difference is that the project is no longer just an idea. It now has a clear user journey, a stronger brand, and real functionality that shows what the product is supposed to do.

Our Experience with GitHub Copilot

GitHub Copilot helped me move faster and finish with more confidence.

It was especially useful for:

building repetitive frontend sections faster
cleaning up component structure
speeding up backend boilerplate and integrations
iterating on UI copy and layout
reducing friction while refactoring and finishing incomplete parts of the project

What mattered most was not just speed, but momentum.

Copilot helped us keep the project moving when we needed to turn unfinished ideas into working features and a coherent product experience.

Why This Project Matters
Agriculture is one of the most important parts of everyday life in Cameroon, but many farmers still struggle with discovery, pricing, trust, and access to buyers.

Moonsu Link tries to solve that with one simple idea:

Meet users where they already are.

No app install
No complicated onboarding
No unfamiliar workflow
Just a practical marketplace inside the chat platforms people already use

That is why this project felt worth finishing. It is not just a technical build. It is a tool that could genuinely reduce friction for farmers and buyers.

The Stack

Frontend:
Next.js 16, React 19, TypeScript, Tailwind CSS v4, Framer Motion

Backend:
FastAPI, PostgreSQL, Telegram Bot API, WhatsApp integration, AI-powered message handling, translation, voice transcription, image upload, and admin APIs

What Changed During the Comeback

The project went from unfinished to presentable by focusing on:

a clearer product story
a stronger landing page
better visual consistency
real cross-platform marketplace flows
verification and trust features
AI-assisted handling of user messages
more polished communication for farmers and buyers

Authors
Main Author: Yves Dylane @yveane _
Co-Author: _Chestly Amahndong @chestly_ace
Co-Author: _Kanjo Elkamira @alchemycodes
_