DEV Community: Omar Afifi

SunSync: How I Used TabPFN, Google Gemma, and ElevenLabs to Help Developers Touch Grass

Omar Afifi — Sun, 11 Oct 2026 20:33:46 +0000

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

What I Built

Most software developers spend their working days indoors under artificial lighting, locked to an IDE, staring at screens for hours on end.

By mid-afternoon, the consequences are familiar across the tech community: eye strain, brain fog, fading focus, and a disrupted circadian rhythm that makes quality sleep an uphill battle. For years, I treated this as simply the unavoidable occupational hazard of writing code.

The real issue isn't a lack of discipline or coffee—it's that standard indoor work environments fight against basic human biology.

The human body relies on natural daylight to set its internal circadian clock. But standard office windows filter out the specific daylight wavelengths needed to feel alert. Even sitting right next to a window, indoor lighting is rarely brighter than 400–500 lux—compared to 10,000+ lux outdoors. To the body, sitting inside all day feels like constant twilight, draining energy and throwing off sleep.

And the tech industry's standard answer to developer burnout? Another screen. Wellness apps that demand more typing, habit trackers with endless push notifications, and weather apps that treat sunlight purely as a sunburn hazard.

I built SunSync as a direct alternative.

SunSync is a lightweight open-source daylight timing tool built with a single goal: evaluate local sunlight in under 30 seconds, give you a quick 15-second eyes-free voice brief, lock into a 20-minute outdoor breathing timer, and get you away from your desk into the fresh air.

How It Works in Practice

Zero-Shot Tabular ML on CPU (Prior Labs TabPFN): Instead of naive heuristics, a foundation tabular transformer (TabPFNRegressor) fits 12 daylight hours in a single forward pass without gradient descent, evaluating solar angles, cloud cover, and irradiance to compute your best 20-minute sunlight window (e.g., 13:15 - 13:35).
Eyes-Free Spoken Directive (Google Gemma + ElevenLabs): A 15-second spoken briefing delivers the key window and UV safety tips using ElevenLabs' low-latency eleven_flash_v2_5 model and the natural, calm Charlie voice—turning raw telemetry into a human send-off so you don't have to keep reading a screen.
Production Grounding for Safe Health Guidance: Gemma crafts natural, encouraging dialogue, while a deterministic validation layer guarantees that safety-critical numbers (the computed window start and UV index) remain strictly grounded to the underlying physics.
The Outdoor Breathing Lock: When you tap "I'm going outside", the UI locks into a 20-minute circular breathing timer so you can put your phone away. You focus on the horizon (never staring directly at the sun) and return to your desk refreshed and ready to code.

Demo

The app is live, publicly accessible, and deployed on Google Cloud Run with interactive OpenAPI documentation:

🌐 Live Web Application: https://sunsync.omar-afifi.com
📡 Interactive OpenAPI Specification: https://sunsync.omar-afifi.com/docs
💻 GitHub Repository: https://github.com/OmarAfifi-CSE/sunsync

Mobile-First Interface Tour (Zero Mockups)

☀️ 01 · Hero Protocol	⏱️ 02 · 20-Min Sun Window	🎙️ 03 · Gemma Spoken Brief	🌿 04 · Touch Grass Protocol

Glance card: today's window, live countdown, recharge score — the 10-second answer.	Decision card (GO NOW / Wait / Done) + UV safety bands + daylight curve to 6 PM.	Fact-verified Gemma directive with source badge (✦ Gemma live / ⚡ edge instant) + Charlie voice playback.	The outdoor commitment card: 20-minute breathing timer + auto-playing voice send-off, phone face-down.

Every screenshot above is a raw capture from my live production deployment on Google Cloud Run - zero synthetic device frames, zero mockups.

What to Look for When Testing

The app dynamically adapts to whatever time of day you test it:

Test Your Location or City Presets: Tap Use my location or switch between presets (Cairo, London, New York, Tokyo). SunSync calculates the solar window relative to that location's local solar clock, not your computer's clock.
Dynamic Real-Time States:
- Upcoming Window (Wait): If it's daytime before the computed peak, you'll see a live countdown ticking down to the recharge window.
- Active Window (GO NOW): If you test during the peak window, the status badge flips to GO NOW with live UV guidance.
- Past Window (Done today): If the sun has set or the peak has already passed in that city, the card displays Done today and advises morning light tomorrow—it will never tell someone to go recharge under a dark night sky.
Listen to Charlie (Voice Briefing): Tap Listen · 15s brief on any location to hear the lifelike ElevenLabs voice briefing with real-time UV safety tips.

Code

The entire codebase is open-source, fully tested, and available on GitHub:

💻 GitHub Repository: https://github.com/OmarAfifi-CSE/sunsync

The project is structured around lean, modular Python services:

src/circadian_ml.py: Prior Labs TabPFN zero-shot Bayesian tabular regression on live CPU.
src/gemma_service.py: Google Gemma integration paired with deterministic factual grounding (validate_directive()).
src/audio_service.py: ElevenLabs low-latency voice synthesis via eleven_flash_v2_5 (Charlie voice).
src/data_service.py: Ingests real-time Open-Meteo weather data (solar irradiance, UV index, cloud cover, and sun angles) to feed into TabPFN.
src/app.py: FastAPI application instrumented with distributed Sentry tracing spans.

How I Built It

1. System Architecture & Dual-Lane Decoupling

I enforced a strict architectural principle: The user's first paint must never wait on generative AI.

                ┌─────────────────────────────┐
                │  Live Open-Meteo Telemetry  │
                │(Hourly UV, Solar Irradiance)│
                └──────────────┬──────────────┘
                               │
                               ▼
                ┌─────────────────────────────┐
                │   Feature Vector Assembly   │
                │  (12-Hour Daylight Context) │
                └──────────────┬──────────────┘
                               │
                               ▼
[Sentry Spans]  ┌─────────────────────────────┐
(Distributed) ─►│  Prior Labs TabPFN ML Core  │
(Latency Trace) │ (Zero-Shot Bayesian CPU ML) │
                └──────────────┬──────────────┘
                               │
                               ▼
                ┌─────────────────────────────┐ ◄── [Grounding Layer]
                │ Google Gemma Directive Core │     (Factual Verify:
                │ (Natural Spoken Directive)  │      Window & UV)
                └──────────────┬──────────────┘
                               │
                               ▼
[Google Cloud]  ┌─────────────────────────────┐
(Cloud Run)   ─►│ ElevenLabs Audio Synthesis │
(Public Host)   │ (Lifelike Charlie Briefing) │
                └─────────────────────────────┘

I decoupled the execution into two asynchronous paths:

The Fast Lane (/evaluate): Computes solar geometry, atmospheric vector transforms, and TabPFN scoring. Returns the deterministic solar window and recharge score immediately with an instant analytical draft.
The Slow Upgrade Lane (/directive & /synthesize-audio): Asynchronously generates the personalized Google Gemma voice directive and ElevenLabs audio stream, upgrading the UI quote in place without blocking interaction.

2. Prior Labs TabPFN: Foundation Tabular ML on CPU

In src/circadian_ml.py, I run the real TabPFNRegressor on live CPU. My training context is exactly 12 rows—the daylight operational hours of a single day (7 AM to 6 PM).

Classical ML algorithms like XGBoost or RandomForest fail here: they demand hundreds of rows, hyperparameter tuning, and cross-validation splits that don't exist in single-day telemetry. TabPFN is a prior-fitted transformer trained on millions of synthetic tabular tasks that performs Bayesian posterior inference in a single forward pass without gradient descent:

Metric / Verification Check	Production Measured Result
Peak window reproducibility across consecutive runs	✅ Identical time window every run (deterministic)
Score variance across repeated runs	0.00
Window stability under seeded ±5% sensor noise	✅ Resilient & stable (score Δ 2.6)
Warm inference execution on multi-core CPU	~1.1–1.5 s
Container cold initialization (one-time weight loading)	~15–17 s (isolated to container cold boot; never blocks warm traffic)

# From src/circadian_ml.py
from tabpfn import TabPFNRegressor

# 12 daylight rows. No gradient descent: forward pass stores tabular context
regressor = TabPFNRegressor(device="cpu", n_estimators=4)
regressor.fit(X_train_atmospheric, y_melanopic_target)
predicted_eml = regressor.predict(X_train_atmospheric)

With only 12 hourly data points per day, traditional ML models fall apart. TabPFN is built specifically for this: delivering accurate Bayesian predictions on small tabular data in under a second without overfitting or requiring hours of hyperparameter tuning.

To deploy SunSync cleanly in production, I packaged the application into an optimized container running on Google Cloud Run with 4 vCPUs and 4 GB RAM in europe-west1. Within the container runtime, I tuned PyTorch's intra-op parallelism (torch.set_num_threads(min(4, os.cpu_count()))) and configured TabPFNRegressor(n_estimators=4). This unlocks multi-core execution on the tabular transformer while preventing thread thrashing, keeping memory rock-solid and delivering consistent sub-1.5s inference on warm instances.

3. Sentry Distributed Agent Tracing: Real Production Telemetry Bands

I instrumented the entire pipeline with distributed Sentry tracing spans (ai.telemetry.ingest, ai.model.tabpfn, and ai.llm.gemma) to monitor live production performance, diagnose latency variances, and ensure pipeline health.

Rather than publishing synthetic local benchmarks, Sentry reveals the authentic behavior across live cloud conditions on Google Cloud Run:

Span Name	Operation	Warm Production Range	Production Lifecycle Notes
`ai.telemetry.ingest`	Open-Meteo REST Fetch & Serialization	70–300 ms	Live upstream solar telemetry fetch (varies with DNS & regional latency)
`ai.model.tabpfn`	TabPFN Tabular Feature Fitting & Scoring	~1.1–1.5 s	In-memory zero-shot Bayesian regression on 4 vCPUs
`ai.llm.gemma`	Google Gemma Narrative Generation	~1.4–2.2 s	Non-blocking slow-lane synthesis via OpenRouter/Google AI Studio
Fast-Lane User Delivery	`/evaluate` Deterministic Delivery	~1.5–2.5 s	Immediate deterministic UI paint; zero blocking on LLM or audio generation

What Sentry Revealed: Observability in Action

Cold Starts vs. Warm Multi-Core Execution: In a serverless container environment like Google Cloud Run, initial container spin-up requires importing PyTorch and loading TabPFN's transformer checkpoint into memory (~15–17s on cold boot). Sentry tracing immediately surfaced this difference: once the container is warm, multi-core CPU execution consistently executes in ~1.1–1.5s. Sentry isolated container lifecycle overhead from algorithmic compute.
Upstream Data Hygiene: Distributed tracing caught intermittent floating-point NaNs returned by upstream weather sensors, allowing me to inject a deterministic sanitization layer (_sanitize_float) before data reaches TabPFN.
Dual-Lane User Protection: By tracing span durations, I verified the value of decoupling /evaluate (the fast lane) from /directive and /synthesize-audio (the slow lane). The user's screen renders the photobiology dashboard in ~2 seconds, while Gemma and ElevenLabs upgrade the briefing asynchronously in the background.

4. Google Gemma: Fast Generative Directives with Production Grounding

To deliver a personalized, encouraging voice brief that doesn't sound like a boilerplate weather bot, I integrated Google's Gemma 3 27B (google/gemma-3-27b-it).

Gemma excels at following concise persona instructions while maintaining a natural, empathetic tone. For SunSync's fast-paced user flow, instruction-tuned Gemma delivers punchy 15-second directives in seconds without the latency overhead of extended thinking traces.

Grounding & Health Safety Guardrails (`src/gemma_service.py`)

Because UV exposure and solar timing directly affect user well-being, production AI requires strict factual grounding. Gemma provides the creative, human variety, while code verifies that safety-critical numbers match reality before reaching the user:

# From src/gemma_service.py
def validate_directive(self, text: str, window_time: str, uv_index: float) -> bool:
    """
    Code-decides guardrail: The model narrates, but only verified facts ship.
    A candidate passes iff it repeats the computed window start AND grounds
    the UV reading. Any hallucinated drift is instantly rejected.
    """
    if not text or len(text.strip()) < 20:
        return False

    start = str(window_time).split("-")[0].strip()
    if start and start not in text:
        return False  # Hallucinated or shifted time -> rejected

    try:
        uv_token = f"{float(uv_index):.1f}"
    except (TypeError, ValueError):
        return False

    text_lower = text.lower()
    if uv_token not in text and "uv" not in text_lower:
        return False  # Dropped or fabricated UV safety reading -> rejected

    return True

This dual-layer architecture guarantees total reliability: Gemma crafts natural, motivating copy, while the verification layer ensures that the solar window and UV safety readings remain 100% faithful to the underlying telemetry. The UI displays an authentic badge indicating the exact origin (✦ Gemma live vs ⚡ edge instant).

5. ElevenLabs Voice Architecture: Screen-Free Audio Presence

Standard browser text-to-speech engines sound robotic, monotone, and clinical—developers tune them out immediately. To build an app that genuinely motivates someone to step away from their desk, the voice needed to feel calm, natural, and human.

I integrated ElevenLabs using the eleven_flash_v2_5 model and the official Charlie voice (IKne3meq5aSn9XLyUdCD):

Low-Latency Voice: eleven_flash_v2_5 synthesizes the spoken brief in seconds while the UI stays fully interactive, and a browser-voice fallback guarantees the guide plays even if the API is unreachable.
Calm, Human Pacing: Charlie delivers a natural, reassuring presence when reading the computed UV warnings and window times.
Eyes-Free Outdoor Send-Off: When you tap "I'm going outside", Charlie plays a warm send-off audio message so you can pocket your phone immediately and head out without looking back at the screen.

6. The Field Test: Taking SunSync Outside for 20 Minutes (Bonus Challenge)

The Hacktoberfest Week 1 challenge brief includes an explicit bonus criteria: taking the build outside, testing it in the real world, and reporting the experience.

During development, when SunSync computed my local 20-minute peak recharge window (14:15 - 14:35), I followed my own protocol:

I opened the live production URL on my phone, tapped Listen · 15s brief, heard Charlie read out the computed window and UV safety tips, and tapped the green commitment button ("I'm going outside").
The UI locked into the 20-minute circular breathing ring. I turned the phone face-down, slipped it into my pocket, and walked out under the open sky.
Instead of checking notifications, I just looked out toward the horizon and took a walk (without staring directly at the sun, of course).

How it actually went:
You notice the difference within a few minutes. Staring at an IDE two feet away for hours puts constant strain on your eyes. Looking out at the horizon under natural outdoor daylight lets your eyes relax and gives your nervous system a genuine reset. By the time the 20-minute timer wrapped up and I walked back to my desk, the usual 3:00 PM afternoon slump was gone—no extra coffee required.

7. Handling Timezones & Diurnal States: Real API Outputs

Because SunSync runs live against the target location's solar clock, the decision engine and Gemma's spoken brief adapt dynamically to the time of day. Below are unedited API responses captured from the production service demonstrating how the system handles different diurnal states:

When the Day's Peak Has Already Passed (e.g., Evening in Cairo):
- Coordinates: 30.04° N, 31.24° E · Computed Window: 14:15 - 14:35 · Score: 100/100 · UV: 5.35
- Gemma Spoken Brief: "Quick one: Just noting your daylight break peak — it was 14:15 - 14:35 with a UV of 5.35 — missed it, but let's aim for softer morning light tomorrow!"
- Behavior: Recognizes the peak has passed, the UI displays Done today, and advises softer morning light tomorrow without false "go outside now" prompts in the dark.
When the Day's Peak Is Upcoming (e.g., Morning in New York):
- Coordinates: 40.71° N, -74.01° W · Computed Window: 14:15 - 14:35 · Score: 100/100 · UV: 0.95
- Gemma Spoken Brief: "Hey you: Your daylight break with a UV index of 0.95 opens later today between 14:15 - 14:35, so be ready to step outside then!"
- Behavior: Confirms future tense ("opens later today"), ticking down a live countdown rather than prompting the user prematurely.
When Testing Across Far Timezones (e.g., Midnight in Tokyo):
- Coordinates: 35.68° N, 139.65° E · Computed Window: 12:15 - 12:35 · Score: 100/100 · UV: 5.2
- Gemma Spoken Brief: "Fresh air alert: Your daylight break with a UV value of 5.2 opens between 12:15 - 12:35 today, so prepare to step outside then!"
- Behavior: Evaluates Tokyo-local time (UTC+9) rather than the tester's client time, correctly scheduling the upcoming daylight window.

Why Does Open Innovation Matter?

Closed wellness algorithms treat human biology as a proprietary subscription black box. Building SunSync on an open-source architecture made critical capabilities possible that closed proprietary APIs simply cannot deliver:

Circadian Health Belongs to Everyone, Not Subscription SaaS: Human biology is not an enterprise product. By building SunSync with open-source models, open data, and containerized infrastructure, the entire pipeline costs ~$0.00 to run at this scale. Anyone can fork the repository, deploy the included Dockerfile on Google Cloud Run's free tier, and use it indefinitely without paying a $15/month wellness tax.
Local CPU Independence via TabPFN: Closed AI APIs demand continuous internet connectivity, recurring credit card billing, and API key management. TabPFN running zero-shot on local CPU proves that high-performance scientific modeling doesn't require gigawatt GPU clusters. Serving TabPFN directly on the application CPU keeps tabular predictions fast, self-contained, and completely free of remote ML endpoint costs.
Strict Data Privacy: Commercial wellness applications harvest location history to monetize behavioral profiles. SunSync queries Open-Meteo for atmospheric weather only. My LLM prompts receive pure numerical arrays (irradiance, UV, angles)—personal coordinates are never passed to any AI model.
Transparent, Reproducible Logic: Proprietary health apps hide behind vague, closed algorithms. By keeping SunSync open source, every developer can inspect the exact solar calculations, daylight thresholds, and automated test suites.

Prize Categories

Featured Categories

1. Best Use of TabPFN (Prior Labs)

How SunSync Uses It: Evaluates real 12-row tabular atmospheric telemetry vectors on live CPU using TabPFNRegressor(n_estimators=4) with zero GPU dependencies. TabPFN predicts Equivalent Melanopic Lux (EML) in a single forward pass without gradient descent, achieving a 0.00 score variance across repeated runs. Foundation weights are pre-baked into Docker image layers, and warm multi-core CPU execution consistently evaluates in ~1.1–1.5s on Google Cloud Run.
Evidence in Repo: src/circadian_ml.py · Determinism & stability benchmarks · tests/test_circadian_ml.py

2. Best Use of Gemma (Google)

How SunSync Uses It: Uses Google's state-of-the-art open model (google/gemma-3-27b-it via OpenRouter with Google AI Studio fallback) to synthesize the 15-second spoken outdoor directive. Gemma turns raw telemetry into an encouraging, natural audio brief, protected by a production grounding layer (validate_directive()) that ensures computed window times and UV safety ratings remain strictly accurate.
Evidence in Repo: src/gemma_service.py · tests/test_gemma_service.py

Partner Categories

3. Best Use of Sentry Agent Tracing

How SunSync Uses It: Shows the entire pipeline's performance via distributed tracing spans (ai.telemetry.ingest, ai.model.tabpfn, and ai.llm.gemma). Sentry traces directly revealed upstream network latency, informed the progressive dual-lane decoupling, and surfaced upstream floating-point NaNs that led to the _sanitize_float safety layer. Token metrics (llm.estimated_prompt_tokens: 48) are attached to every span.
Evidence in Repo: src/app.py 42–52 & 212–220 · Latency waterfall table in write-up · Expandable Sentry telemetry HUD in UI

4. Best Use of ElevenLabs

How SunSync Uses It: Powers SunSync's eyes-free audio interface using the eleven_flash_v2_5 model and the official Charlie voice (IKne3meq5aSn9XLyUdCD). Delivers lifelike voice briefings and outdoor send-offs so developers can pocket their phones without looking at screens. ElevenLabs transforms what would otherwise be a robotic notification into a calm, human ritual that encourages stepping away from the desk.
Evidence in Repo: src/audio_service.py · src/static/app.js (voice pipeline: synthesizeAudioElement, speakViaBrowser fallback, playDetoxGuide)

Closing: Step Away from the Screen

For years, I treated developer fatigue as a software problem to be solved with more software, more productivity tools, and more screen time.

Building SunSync reinforced the opposite truth: the most valuable thing an AI tool can do is provide a fast, mathematically grounded answer, get completely out of the way, and encourage a return to the physical world.

Human knowledge has real limits, and so does biological endurance. A developer simply isn't built to spend 14 hours a day under office lights staring at glowing screens.

Now, close this tab.

Lock your screen.

Step outside, and go touch some grass. 🌿

Building an Agent That Can't Afford to Be Wrong: Quran Sanity Agent

Omar Afifi — Sun, 04 Oct 2026 06:59:52 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

When I first opened the Sanity Challenge announcement, one sentence in the Path One brief immediately grabbed my attention:

"Build anything that needs an answer it can't afford to get wrong."

That one line defined this entire project.

If you ask an AI chatbot for movie recommendations or a recipe, a small hallucination is harmless. But if you ask it about the Quran, religious scripture, or classical commentary, getting things wrong is not an option.

Yet that is exactly what standard LLMs do every day:

They drop words from verses or invent Arabic grammar on the fly.
When two classical scholars disagree, the model either invents a fake consensus or blends both opinions into a confusing, contradictory mess.
It cites famous books and scholars with total confidence, even when the quote never existed in that book.

Traditional RAG (Retrieval-Augmented Generation) doesn't fix this either, because dumping raw chunks into a prompt still leaves the model free to summarize, blur, and paraphrase whatever it wants.

I wanted to see what happens when you treat the problem differently: what if the AI literally cannot generate Quranic text? What if the agent only has access to verified, structured records in Sanity, and conflicting historical opinions are modeled cleanly as data rather than smoothed over?

That is what Quran Sanity Agent is built to do.

What I Built

Quran Sanity Agent is a bilingual (Arabic & English) web research workspace where every single verse, translation, and scholarly commentary is anchored to an immutable record in Sanity.

How It Works in Practice

Verses Are Read, Never Generated: The LLM is never asked to recite or recall Quranic text from memory. Every Ayah displayed in the interface is pulled directly from a verified Sanity document matching the authoritative Tanzil Uthmani 1.1 reference standard.
Scholarly Differences as Structured Data: In classical Islamic exegesis (Tafsir), scholars have debated linguistic nuances and legal rulings for over a thousand years. Instead of hiding these differences, the application structures them into two distinct categories:
- Contradictory (Ikhtilaf Tadadd): True conflicting positions (e.g., whether the opening Basmalah is counted as a verse of Al-Fatihah).
- Complementary (Ikhtilaf Tanawwu'): Multi-faceted meanings that coexist (e.g., whether Al-Asr refers to time itself or the afternoon prayer).
The Evidence Drawer: Every verse and commentary card has an interactive citation badge. Clicking it opens a side drawer showing the exact Sanity Document ID, the physical book locator (chapter, volume, and primary URL), and the raw JSON payload straight from the Content Lake.
Honest Evidence Gaps: If you ask a question outside the curated dataset (like modern cryptocurrency rulings), the agent doesn't try to guess or produce an ungrounded opinion. It explicitly reports an Evidence Gap, showing what records it searched and clarifying that no authoritative source is available.

Demo

The app is live, publicly accessible, and backed by a hosted Sanity Studio:

🌐 Live Web Application: https://quran-sanity.omar-afifi.com
🏛️ Hosted Sanity Studio: https://quran-evidence-studio.sanity.studio/
💻 GitHub Repository: https://github.com/OmarAfifi-CSE/quran-sanity-agent

Zero-Trust Transparency: The Live Evidence Drawer

Inspect real-time Sanity Document IDs, physical book locators, and raw JSON payloads straight from the Content Lake.

Queries You Can Test Right Now

Here are four questions you can paste into the live app to see the structured pipeline in action:

Exact Verse Integrity:
- Query: 2:255 (or switch the UI to Arabic and type البقرة ٢٥٥).
- What to look for: Instant retrieval of Ayat al-Kursi with verified Uthmani script and Saheeh International translation. Click the citation badge to view ayah-2-255 in the Evidence Drawer.
Contradictory Divergence:
- Query: Compare interpretations of Al-Fatiha Basmalah
- What to look for: Surfaces the opposing classical positions between Ibn Kathir / Al-Qurtubi vs. Fakhr al-Din al-Razi side-by-side, without the model taking a side or muddying the waters.
Complementary Divergence:
- Query: Compare interpretations of Al-Asr
- What to look for: Shows how Al-Tabari, Ibn Kathir, and Al-Qurtubi each highlight complementary dimensions of the word (time, human deeds, afternoon prayer).
Semantic Retrieval via Sanity Context MCP:
- Query: What does the Quran say about justice even against oneself?
- What to look for: The agent queries the Sanity Context MCP endpoint, ranks Ayah 4:135 at the top, and provides grounded notes quoting the primary text verbatim.

Code

The entire codebase is open-source and available on GitHub:

👉 github.com/OmarAfifi-CSE/quran-sanity-agent

The project is structured as a TypeScript monorepo:

web/: Next.js 15 (App Router) interface with full Arabic RTL support and the Sanity Context MCP integration.
studio/: Sanity Studio v3 with custom Desk Structure and dedicated Islamic hermeneutic schemas.
scripts/: Verification tools ensuring zero character drift against reference text standards.

How I Used Sanity

This project is built around the idea that an agent is only as reliable as the structure behind its content.

Here is how Sanity handles every layer of the architecture:

┌──────────────────────────────────────────────────────────┐
│                   SANITY CONTENT LAKE                    │
│   • 114 Surahs (Surah number, names, revelation type)    │
│   • 6,236 Ayahs (Uthmani text, translation, keywords)    │
│   • 6 Tafsir Authorities (Scholar, death year, school)   │
│   • 12 Audited Interpretive Claims with primary excerpts │
└────────────┬─────────────────────────────┬───────────────┘
             │                             │
    Exact Lookups (GROQ)          Semantic Queries (MCP)
             │                             │
             ▼                             ▼
┌──────────────────────────┐  ┌─────────────────────────────┐
│ Deterministic Lake Fetch │  │ Sanity Context MCP Endpoint │
│  • Sub-50ms response     │  │  • 21,398 library chunks    │
│  • Direct schema joins   │  │  • Vector embeddings rank   │
└────────────┬─────────────┘  └────────────┬────────────────┘
             │                             │
             └──────────────┬──────────────┘
                            ▼
┌──────────────────────────────────────────────────────────┐
│                 NEXT.JS AGENT WORKSPACE                  │
│   • Verifies all candidate IDs against Content Lake      │
│   • Rejects AI notes that lack verbatim source quotes    │
│   • Renders bilingual cards & Evidence Drawer            │
└──────────────────────────────────────────────────────────┘

1. The Content Model (`studio/schemaTypes/`)

Instead of generic blog or article schemas, Sanity Studio manages structured Quranic and classical commentary data:

surah: Core chapter metadata (number, Arabic name, English name, revelation type, verse count).
ayah: Individual verse records containing Tanzil Uthmani text, verified English translations, and references to parent chapters.
tafsirSource: Classical authorities (e.g. Al-Tabari d. 310 AH, Al-Qurtubi d. 671 AH, Ibn Kathir d. 774 AH) with their specific methodology (athari, juridical, rational, linguistic).
interpretiveClaim: An atomic claim linking an ayah to a tafsirSource. It stores the primary excerpt (primaryExcerpt), the physical book locator (sourceLocator), the divergence classification (contradictory, complementary, consensus), and editorial status.
sourceEdition & libraryChunk: Ingestion schemas representing 21,398 chunks across classical commentaries for semantic retrieval.

2. The Editorial Review Gate

One of the most practical things about Sanity Studio is how easily you can customize the Desk Structure to enforce editorial discipline.

In studio/deskStructure.ts, I added a custom "Needs source review" filter:
If an editor enters a new claim but forgets the primary book excerpt, the exact source URL, or the reviewer sign-off, Sanity immediately catches it and moves it into this review queue.

More importantly, the Next.js agent's GROQ queries strictly filter for reviewStatus in ["source_checked", "reviewed"]. If a claim hasn't passed the editorial gate, the AI agent is physically unable to see it or use it in an answer.

3. Sanity Context MCP & Semantic Retrieval

While exact verse numbers (e.g. 2:255) are resolved instantly via deterministic GROQ queries, thematic questions (e.g. "What does the Quran say about justice?") require semantic understanding.

To handle this, I pointed Sanity Context at the imported library of 21,398 chunks and enabled Content Lake embeddings:

When a user asks a conceptual question, the agent queries the remote Sanity Context MCP endpoint.
The MCP server ranks relevant chunks based on semantic similarity and returns their document IDs.
The Grounding Rule: The agent never relies solely on the LLM's summary. It uses those document IDs to re-fetch the raw records directly from the Content Lake.
Verbatim Quotation Enforcement: If the model generates an explanatory note, the application validates that the note quotes words directly from the retrieved source text. If it fails this check, the UI falls back to displaying the raw verified excerpt.

Sanity Project Details

Sanity Project ID: qkca243t
Dataset: production
Hosted Studio: https://quran-evidence-studio.sanity.studio/
Sanity Context MCP Endpoint: https://api.sanity.io/v1/context/organizations/o831wcpb9/mcp/quran-evidence-mcp
Content Lake Stats: 6,369 primary documents (114 Surahs, 6,236 Ayahs, 6 Tafsir Sources, 12 Curated Interpretive Claims) and 21,398 indexed library chunks.

What Building This Taught Me

Building this project made one thing very clear:

The solution to AI hallucination in high-stakes domains isn't "better prompts" or larger models. It's structured content.

When you treat texts as unstructured strings dumped into a vector database, the AI is always one step away from fabricating an answer. But when you model your domain properly—distinguishing chapters from verses, authorities from editions, and consensus from disagreement—the AI stops guessing and starts acting as an interface to verified knowledge.

Sanity was uniquely suited for this: having schemas, the Content Lake, GROQ, and the Context MCP in one unified ecosystem meant I could build a zero-hallucination agent that remains completely transparent with every answer it gives.

Check out the live project at quran-sanity.omar-afifi.com and explore the code on GitHub.

My Phone Broke, and Gemini Fixed It

Omar Afifi — Wed, 09 Sep 2026 22:26:48 +0000

📱 Picture This: An All-Nighter Turns Into a Morning Nightmare

It is early morning. You’ve just pulled an all-nighter tinkering with an Android project over ADB. The sun is already creeping through the window, tests finally pass, and you unplug the USB cable from your OnePlus to finally go to bed.

You unlock your screen, swipe down to open Settings, and freeze.

Right across your menus is a block of bright-red monospace text:

isOverScrolling: false
X: FlingVX: 0.0, ClickVX: 0.0
Y: FlingVY: 15435.0, ClickVY: 0.0
AbortVX:0.0, AbortVY:15435.0

You stare at it, then touch the screen again. The numbers immediately jump, recalculating in real time with every movement of your thumb. You swipe fast, and FlingVY shoots into the tens of thousands.

Then you notice something even worse: the phone is lagging badly.

When you swipe from the screen edge to go back, the gesture stutters. Pulling out the OnePlus Smart Sidebar hesitates and drops frames. The smooth 120Hz display suddenly feels like a cheap phone struggling to keep up.

🥶 Zero Results: When Google Goes Completely Silent

Your developer reflexes kick in immediately. You jump straight into Developer Options:

Pointer Location? Off.
Show Layout Bounds? Off.
Show Taps? Off.
Strict Mode? Off.

Everything is disabled.

Fine. You hold down the power button and reboot. The phone restarts, you unlock it, open Settings, scroll down—and the red numbers are still right there.

That's when you start to panic. You open your browser and start searching:

"red text on android screen": Generic guides telling you to turn off Developer Options.
"OnePlus red text on screen": Threads asking about the red "1" on the lock screen clock (funny, but not helping).
"OnePlus red text error": Nothing remotely relevant.
"isOverScrolling: false" OnePlus: No results found.
"AbortVX" / "ClickVX": Absolute zero.

Zero results. Not a single thread on XDA Forums, not a mention on Reddit, and nothing on the OnePlus Community.

If you've worked with Android long enough, you know what this silence means: when an issue has zero documentation in AOSP and zero community threads, you're usually looking at a full factory reset.

😴 "That’s Future Me’s Problem"

At that point, the morning sun was already up. I had stayed up all night, I was running on zero sleep, completely exhausted, and my brain felt like an OutOfMemory error. I stared at the red numbers on my screen and made the most mature engineering decision possible:

I decided to go to sleep.

"You know what? This is future me's problem."

I put the phone face-down on the nightstand, closed my eyes, and hoped it would just magically disappear by the time I woke up.

Fast forward to later that afternoon: I woke up, tapped the screen, and nope—the red velocity numbers were still right there, tracking every single swipe while I was still half-asleep.

Now awake and ready to deal with it, I decided it was time to bring in serious backup.

🤖 Handing the Terminal to Gemini

I plugged the USB cable back into my laptop. I opened my Antigravity IDE where I had been pair-programming with Gemini, and typed out of pure frustration:

"Hey, you ran some ADB commands on my phone earlier for some app testing and now there's this weird red text on my screen and the edges are lagging. I plugged it in—fix it."

If this were a standard chatbot, you already know what its first response would be:

"Go to Settings > Developer Options and disable 'Pointer Location', 'Show Layout Bounds', or 'Strict Mode'. If those are already off, try backing up your data and performing a factory reset."

Every standard LLM defaults to that exact script because it assumes you're dealing with standard Android toggles. And when you tell it they're already off, it hits a complete dead end.

Instead, Gemini took the wheel. What happened on my terminal over the next few minutes was impressive: rather than giving boilerplate advice, Gemini started systematically diagnosing the operating system from the inside out.

🎨 Step 1: The Canvas Deduction

Gemini didn't guess. It queried the device's runtime settings via ADB:

adb shell settings get system pointer_location
adb shell settings get system show_touches

Both came back 0. Standard Android touch telemetry was definitively off.

Then Gemini dumped the entire live UI hierarchy of the Settings app:

adb shell uiautomator dump /sdcard/window_dump.xml

It grepped the XML tree for isOverScrolling. The result? Empty.

That silence told Gemini everything:

"This text does not exist as a TextView or a system overlay window. It is being painted directly onto the hardware Canvas buffer during draw passes by an internal UI component."

Because the text appeared during scrolling in OnePlus system menus, Gemini formed an immediate hypothesis: the code belonged to OnePlus/OPPO’s proprietary UI toolkit—COUI (ColorOS UI).

🔬 Step 2: Disassembling the Phone on the Fly

Because these OEM classes are completely proprietary and unreleased, Gemini couldn't look up documentation. It had to read the machine code directly from the phone.

To inspect the COUI framework without needing root access, Gemini pulled a built-in pre-installed app that uses the same UI components:

adb pull /product/app/Calculator2/Calculator2.apk ./calc.apk

Then, right inside my terminal, Gemini wrote and executed Python scripts to parse the raw binary DEX (Dalvik Executable) structures of the APK.

1. Hunting the String Table

Gemini parsed the DEX string pool inside calc.apk and found the exact IDs:

String #2600 = 'AbortVX:'
String #37919 = 'isOverScrolling: '

2. Pinpointing the Method

It mapped those string IDs across every class definition in the binary. In seconds, Gemini had the exact location:

Class: androidx.recyclerview.widget.COUIRecyclerView (OnePlus’s internal extension of the Jetpack RecyclerView)
Method: dispatchDraw(Canvas canvas) at bytecode offset 0x1fbea0

3. Reading the Dalvik Bytecode

Gemini disassembled the opcodes at that offset. The bytecode showed exactly what was going on under the hood:

0x1fbea0: invoke-virtual View->dispatchDraw
0x1fbea6: sget COUIRecyclerView->COUI_DEBUG:Z   // Check static boolean flag
0x1fbeaa: if-eqz -> 0x1fc03c                   // If false, skip entirely!
0x1fbeae: iget COUIRecyclerView->mDebugPaint   // Get Paint object
0x1fbec4: invoke-virtual Paint->setColor       // Set paint color to RED
0x1fbed4: const-string 'isOverScrolling: '     // Format velocity strings
0x1fbf2a: const-string 'X: FlingVX: '
0x1fbf86: const-string 'Y: FlingVY: '
0x1fbfe4: const-string 'AbortVX:'
0x1fc036: invoke-virtual Canvas->drawText      // Draw directly on screen!

There it was: an undocumented, internal scroll-physics debugger built by OEM engineers to measure fling velocities during ROM development.

💥 Step 3: The Domino Effect — Finding Patient Zero

Gemini now knew what was painting the screen, but why had COUI_DEBUG suddenly turned true across my entire phone?

Gemini inspected the class initializer <clinit> of COUIRecyclerView:

0x1fb9bc: const-string 'COUIRecyclerView'
0x1fb9c2: invoke-static COUILog->isLoggable("COUIRecyclerView", Log.DEBUG)
0x1fb9d6: sput COUIRecyclerView->COUI_DEBUG:Z

COUILog.isLoggable() simply calls Android's built-in android.util.Log.isLoggable(tag, level).

In Android, Log.isLoggable() first checks for a tag-specific system property (log.tag.<TAG>). If that doesn't exist, it checks the global fallback property:

🎯 The Culprit: persist.log.tag

Gemini queried the phone:

adb shell getprop persist.log.tag

The terminal printed one character:

Connecting the Dots

Hours earlier, while debugging an audio service over ADB, a command had set persist.log.tag to V (Verbose) to inspect background audio logs.

That one command triggered an unexpected chain reaction:

Why it survived reboots: Properties starting with persist. are saved directly to flash storage (/data/property). A reboot does not wipe them.
Why the red text appeared: Every time any app initialized a scrollable list, COUIRecyclerView checked if debug logging was enabled. Because persist.log.tag was set globally to V, Android replied that everything was in verbose mode. COUI_DEBUG became true, and the red velocity overlay activated.
Why the edges were lagging: With global verbose logging enabled across the entire OS, every single touch event, swipe coordinate, and edge gesture flooded the system log daemon with hundreds of log lines per second. The CPU was overwhelmed with logging I/O, dropping frames and causing noticeable edge touch lag.

⚡ The Cure: Total Relief in Five Seconds

Once Gemini identified the exact root cause, the fix was quick and clean:

1. Resetting the Global Flag

Gemini reset the dangerous persistent global log property to empty:

adb shell setprop persist.log.tag ""

2. Preventing It from Happening Again

To make sure COUIRecyclerView could never wake up its debug drawing again—even if global verbose logging were accidentally enabled in a future project—Gemini injected a permanent tag-level suppression rule:

adb shell setprop persist.log.tag.COUIRecyclerView SUPPRESS

3. Killing the Active Process for Instant Testing

Gemini killed the Settings process to immediately test the fix on the current window:

adb shell am force-stop com.android.settings

Gemini triggered an automated swipe gesture through ADB, captured a live screenshot, and verified that the red text had vanished from Settings.

4. The Final Device Reboot: Flushing In-Memory State

While Settings was fixed immediately, Gemini pointed out a crucial Android runtime mechanic:

In the Dalvik/ART virtual machine, static initializers (<clinit>) run only once when a class is first loaded into a process. That meant any app or system service already running in RAM (like the Launcher, SystemUI, or Contacts) still held COUI_DEBUG = true cached in memory.

To guarantee that every background process, system daemon, and service reloaded cleanly from scratch with the new suppressed properties, we performed a fresh device reboot:

adb reboot

Once the phone rebooted, I picked it up, unlocked it, and scrolled through every corner of the system:

The red text was 100% gone across all apps.
The edges were instantly responsive. Edge gestures, the Smart Sidebar, and the silky 120Hz display were completely restored.
Zero personal data touched, zero system partitions modified.
All temporary extraction scripts were cleanly wiped from both the phone and PC.

🎓 Final Thoughts: An Engineering Student Left Speechless

As a Computer & Systems Engineering student, I usually take AI hype with a grain of salt. I understand how systems work under the hood, and I know how complex and messy OEM Android frameworks get when low-level state gets corrupted.

If I had posted this on a forum or asked a standard chatbot, the advice would have been the same generic response: back up your data and factory reset.

Watching Gemini handle this live in my terminal was genuinely impressive. It didn't guess, and it didn't give generic tips. It followed a solid systems debugging process:

It systematically eliminated UI layers until only hardware Canvas rendering was left.
It pulled compiled OEM packages directly from the phone without needing root access.
It wrote Python scripts on the spot to parse binary DEX string pools and find the right class offsets.
It analyzed the raw Dalvik bytecode and isolated the exact sget instruction controlling the overlay.
It traced an undocumented UI flag back to a persistent Linux system property that had survived reboots.

Watching an AI autonomously reverse-engineer compiled bytecode on a live device—and solve an undocumented framework issue in minutes without touching a single byte of my personal data—was amazing to see.

This isn't just about autocompleting syntax or generating boilerplate code anymore. This is a real glimpse into the future of systems engineering—and as an engineering student, it completely blew me away.

The Ghost in the View Transitions API: A Bizarre Debugging Saga with Google AI 👻

Omar Afifi — Fri, 07 Aug 2026 17:35:35 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

🎨 Project Overview

While working on a major upgrade for my personal portfolio (Check it out here: Live Portfolio Link | GitHub Repo), I built a feature called the Theme Showcase. When a user first loads the homepage, a slick View Transitions API animation sweeps across the screen, temporarily switching the site to one of my custom showcase themes (like "Obsidian" or "Midnight"), before gracefully sweeping back to their chosen default theme. It was a 1.7-second "Wow Effect" designed to show off the site's dynamic color system.

🐛 Bug Fix

Soon after deploying, I noticed a terrifying, chaotic bug. Sometimes, I would open the website and quickly switch to another tab to check an email, or minimize the browser window completely. When I switched back...

Instead of my beautiful default theme, the website was permanently stuck on one of the other showcase themes! The animation had frozen mid-way, leaving the site in an awkward intermediate state. While the website was still fully functional and I could manually fix it by selecting my original theme from the dropdown menu, it was a terrible first impression for a professional portfolio. It was as if a ghost had possessed the CSS.

My first instinct? Smash the refresh button. Refreshing would actually fix the glitch and play the animation perfectly—but only if I stayed patiently on the tab and watched it finish! If I refreshed and immediately switched tabs again, the ghost would return.

💻 Code

Here is the exact code change we made to exorcise the ghost. (You can view the full fix in this GitHub Commit)

The Buggy Code (Before):

const transition = document.startViewTransition(() => {
  html.setAttribute('data-theme', theme);
});

// If the browser aborts the transition here, the Promise rejects and execution halts forever!
transition.ready.then(() => {
  const animation = document.documentElement.animate(/* ... */);
  animation.onfinish = resolve;
});

The Bulletproof Code (After):

let isCancelled = false;

// 1. Gracefully handle tab switching
const handleVisibility = () => {
  if (document.hidden) {
    isCancelled = true;
    html.setAttribute('data-theme', originalTheme); // Instantly restore
    document.removeEventListener('visibilitychange', handleVisibility);
  }
};
document.addEventListener('visibilitychange', handleVisibility);

// 2. Bulletproof the View Transition Promise
return new Promise(resolve => {
  try {
    const transition = document.startViewTransition(() => {
      if (!isCancelled) html.setAttribute('data-theme', theme);
    });

    transition.ready.then(() => {
      if (isCancelled) return resolve();

      const animation = document.documentElement.animate(/* ... */);
      animation.onfinish = resolve;
      animation.oncancel = resolve;

    }).catch(() => {
      // THE MAGIC FIX: If the browser aborts the transition (background tab), resolve immediately!
      resolve();
    });
  } catch (error) {
    // Fallback if startViewTransition throws synchronously
    if (!isCancelled) html.setAttribute('data-theme', theme);
    setTimeout(resolve, duration);
  }
});

🛠️ My Improvements

My technical approach to resolving this was two-fold:

State Management on Visibility Change: I added a visibilitychange event listener. If the user navigates away, we instantly cancel the sequence and forcefully restore the original theme to prevent intermediate states.
Error Handling for the View Transitions API: The core issue was that browsers forcefully abort the startViewTransition when a tab is hidden to save battery. This caused the transition.ready Promise to reject. Because there was no .catch() block, the unhandled rejection caused the entire async sequence to hang permanently. By wrapping the transition in a try/catch and adding a .catch(() => resolve()) handler, we guarantee that the execution flow always continues gracefully, even if the browser interrupts it.

🤖 Best Use of Google AI

I couldn't figure out why this bug was only happening sometimes, and no errors were showing up in the console. So, I turned to my trusty pair programmer: Google AI integrated within the Antigravity IDE.

What's really cool about my workflow is that I chat with my AI agent completely casually in Arabic. It feels incredibly natural, like brainstorming with a senior engineer sitting right next to me. But debugging with AI isn't always a "one-shot" magic trick. It’s an iterative journey.

(Note: I interact with my AI agent natively in Arabic! For this post, I have translated our debugging conversation. I've kept the original Arabic screenshots on hand just in case the judges want to see them!)

Phase 1: The Misdiagnosis

At first, I explained the symptoms loosely to the AI:

Me: "I have another issue. Sometimes the theme changes to dark suddenly and weird things happen. I don't know what it is."

The AI analyzed the code and thought the animation feature itself was the bug (assuming it was just annoying the user). So, it enthusiastically offered a "fix" by completely disabling the showcase animation function!

I had to intervene and correct its assumption:

Me: "Bro, no, you misunderstood! The animation at the beginning is natural and fine. What's NOT natural is leaving the website open, going to another tab, and coming back to find it permanently stuck on a new theme."

Phase 2: The Deep Dive

Once I steered the AI in the right direction, it immediately dug into the mechanics of tab-switching. It realized that modern browsers aggressively pause requestAnimationFrame when a tab goes to the background.

The AI wrote the visibilitychange listener, but then we ran into another issue when I was testing it locally with my dev server.

Me: "Why does it open on a different theme every time I hit save in my editor? I have to manually refresh to get my original theme back."

The AI assumed I was just being impatient with the 1.7-second animation delay during live-reloads:

AI: "When you save, the dev server refreshes the page. The animation starts, switches to the showcase theme, and then returns. You are just manually refreshing before the 1.7 seconds finish, trapping yourself in a loop! Just wait 1.7 seconds."

Phase 3: The "Aha!" Moment

I knew I wasn't just being impatient. The UI was literally getting stuck. I pushed the AI to look deeper:

Me: "Bro, I'm not rushing. I open it, find it on a new theme, and it is completely STUCK on it. This causes problems if the user goes to another tab. Focus well, think carefully, and take your time."

That’s when the AI hit the absolute jackpot.

It didn't just hand me a snippet of code; it provided a masterclass on browser mechanics. It analyzed the View Transitions API behavior and uncovered the true root cause: to save battery and resources, modern browsers aggressively throttle or abort animations when a tab is hidden. This aggressive optimization was causing the transition.ready promise to reject silently, which hung the entire async sequence because it lacked a .catch() block.

I initially asked the AI if we could just "force" the browser to play the animation in the background anyway. Instead of blindly agreeing, the AI pushed back and explained the engineering philosophy behind this: it’s a hard performance constraint built into modern browsers. You can't fight the browser's resource management. Instead, it taught me the "Best Practice": monitor the tab's state (which led to the visibilitychange listener), gracefully catch any forced abortions (the .catch() fix), instantly restore the original UI, and respect the browser's rules.

Thanks to Google AI in the Antigravity IDE, I didn't just fix a bug—I learned exactly why the browser was behaving that way under the hood. It transformed a frustrating debugging session into a profound learning experience about advanced JavaScript APIs and browser rendering mechanics. This is exactly what the future of pair programming looks like!

Reviving Daphq: How I Built an Open-Source, Bare-Metal File Transfer Engine Solo with GitHub Copilot

Omar Afifi — Wed, 27 May 2026 21:12:32 +0000

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

What I Built

Daphq is a robust, open-source, cross-platform file transfer application engineered entirely from scratch to deliver hardware-saturating speeds over local area networks (LAN), Wi-Fi, and Mobile Hotspots.

As a solo developer, I built Daphq to solve a personal frustration: the bloated overhead, privacy concerns, and artificial speed limits of conventional HTTP-based or cloud-reliant file-sharing tools. Daphq bypasses the standard Web/REST layer completely, establishing direct, bare-metal TCP Sockets (Socket & ServerSocket) with SocketOption.tcpNoDelay enabled to eliminate protocol latency and push network hardware to its absolute physical limits.

Built using Flutter (Dart) for seamless cross-platform performance (currently native on Android and Windows), Daphq features a highly decoupled architecture using the BLoC/Cubit pattern, multi-gigabyte memory protection guards, and background network synchronization, and intelligent user guidance.

Demo

The entire project is completely open-source and free to review, fork, or run locally:

🌐 Official Product Website: omar-afifi.com/daphq/
💻 GitHub Repository: github.com/omarafifi-cse/daphq

Screenshots in Action

Android UI Layout	Windows Desktop Experience

Clean, robust mobile layout with active background service tracking.	Fluid, modern, and highly responsive desktop experience.

The Comeback Story

Daphq was born under high pressure, but after shipping the bare bones of version v1.0.0, it was essentially abandoned in my local repository directory. The project had immense raw speed potential, but it was plagued by architectural gaps, clunky user workflows, and high-stress bugs that made it unviable for everyday users.

The GitHub Finish-Up-A-Thon Challenge was the exact catalyst I needed to dust off the codebase and transform it from a fragile command-like utility into a highly polished, resilient consumer application (v2.3.0).

The Deep Evolution: v1.0.0 vs. v2.3.0

Here is exactly how the architecture and UX matured over the course of this challenge:

Discovery, Connectivity & Resilience:
- Before (v1.0.0): Zero automation. Users manually typed cryptic IPv4 addresses, and any connection drop required a full app restart.
- After (v2.3.0): A custom UDP Auto-Discovery Service with an integrated watchdog. Backed by a rewritten, Bulletproof Receiver Engine, the app instantly bounces back if a connection drops or cancels abruptly—never getting stuck on "Connecting...".
User Interface, Fluidity & Storage:
- Before (v1.0.0): Rigid layouts, storage bloat from cached files, and main-thread hangs (UI freezing) when selecting large directories.
- After (v2.3.0): A unified dashboard anchored by an "Orbital Radar" and Non-Blocking Async UI. Sharing 1,000+ files is now buttery smooth with zero lagging. Plus, it features Persistent Folders to permanently remember your download path and Smart Auto-Cleaning to wipe cache bloat automatically.
Smart User Guidance:
- Before (v1.0.0): Users suffered from slow transfers due to ISP router bottlenecks without knowing why.
- After (v2.3.0): Integrated a real-time speed monitor that triggers a Smart Hotspot Guide if speeds drop below 2.0 MB/s, guiding users to utilize 5GHz direct hotspots for up to 10x faster speeds.
Memory Safety & Disk I/O Flow Control:
- Before (v1.0.0): High risk of Out-Of-Memory (OOM) crashes when streaming multi-gigabyte files due to unthrottled asynchronous disk reads.
- After (v2.3.0): Implemented zero-copy byte slicing (Uint8List.sublistView) and Natural Socket Backpressure (await socket.flush()). Daphq now self-throttles to match real-time network speeds, saving physical RAM.
Deep System-Wide Integrations:
- Before (v1.0.0): Isolated sandboxed app.
- After (v2.3.0): Deployed deep OS hooks, including native Android Share Menu entry and background execution. On Android, Instant Wake-up intelligently turns on the screen for incoming requests. On Windows, the Context Menu Shell Extension was completely rebuilt to be unbreakable, eliminating all File Explorer hangs.

My Experience with GitHub Copilot

As a solo developer, you are the software architect, the UI designer, the QA technician, and the DevOps engineer all at once. Time is your greatest bottleneck. Throughout this sprint, GitHub Copilot didn’t just autocomplete lines of boilerplate—it acted as an incredibly knowledgeable senior engineering peer, unlocking complex architectural problems.

Here are three distinct breakthroughs where GitHub Copilot completely changed the trajectory of the project:

1. Solving the Math of the Orbital Radar UI

I wanted the home dashboard to feel alive with an evenly distributed, deterministic "Orbital Radar" circle showing available peer devices. Distributing dynamic widgets symmetrically on a circular plane without them overlapping can quickly become a headache.

Copilot's Intervention: By providing Copilot with my layout boundaries and device state arrays, it instantly mapped out the exact trigonometric distribution math using cos and sin over a mapped index. Furthermore, it proactively recommended assigning unique ValueKeys to the dynamically generated widgets, preventing unnecessary re-paints and maximizing rendering performance on low-end hardware.

2. Eliminating the Windows FFI Mutex Deadlock

A critical, highly frustrating platform bug on Windows caused Daphq to accidentally trigger background execution loops whenever a user performed completely unrelated right-click shell actions elsewhere in the OS. Worse, exiting the app caused a stubborn Dart VM deadlock.

Copilot's Intervention: I explained the process conflict to Copilot. It guided me through structuring a clean, platform-specific local session mutex check. When it came to bypassing the Dart VM shutdown hang, Copilot instantly generated the safe native Windows FFI code block to execute a clean ExitProcess command, killing the deadlocks instantly and safely.

3. Engineering Flow-Safe Dynamic Streaming Buffer

To stop aggressive disk-read bursts from triggering Out-Of-Memory exceptions, I needed a way to throttle file streams smoothly based on network capacity.

Copilot's Intervention: Copilot analyzed my asynchronous data-sync loop and suggested transitioning away from arbitrary chunk delay timers. It helped refactor the code to explicitly await socket.flush() based on monitored bytesBuffered thresholds. The result was an automated backpressure loop that scales throughput up or down safely based on real-time network conditions.

// Standard path for larger files: stream in chunks
final reader = fileToRead.openRead();
try {
  await for (var chunk in reader) {
    if (_isCancelled) throw "Transfer Cancelled";
    try {
      socket.add(chunk);
      bytesBuffered += chunk.length;

      if (bytesBuffered >= AppConstants.socketFlushThresholdBytes) {
        // Awaited flush: provides backpressure so the disk read loop
        // runs at network speed, not disk speed. Without this, a fast
        // UFS device would read the entire file in <500ms before any
        // onUpdate fires, causing the snapshot/stutter UI bug.
        await socket.flush();
        bytesBuffered = 0;
      }
    } catch (e) {
      if (_isCancelled) throw "Transfer Cancelled";
      if (e is SocketException || e.toString().contains("reset by peer")) {
        throw "Receiver disconnected during transfer.";
      }
      rethrow;
    }

    // ... UI update logic 
  }
}

The Verdict

Building Daphq independently meant encountering dozens of architectural edge cases. Having GitHub Copilot available to instantly generate platform-specific guards, analyze multi-threaded socket behavior, and handle tedious Win32 registry bindings allowed me to focus on what mattered most: delivering a breathtakingly fast file transfer engine.

Daphq went from an unpolished repository artifact to a production-grade open-source engine capable of hitting 80-90 MB/s (~93% bandwidth saturation) over a standard local Wi-Fi 5 connection. I couldn't be prouder of how this challenge ended.

DEV Community: Omar Afifi

SunSync: How I Used TabPFN, Google Gemma, and ElevenLabs to Help Developers Touch Grass

What I Built

How It Works in Practice

Demo

Mobile-First Interface Tour (Zero Mockups)

What to Look for When Testing

Code

How I Built It

1. System Architecture & Dual-Lane Decoupling

2. Prior Labs TabPFN: Foundation Tabular ML on CPU

3. Sentry Distributed Agent Tracing: Real Production Telemetry Bands

What Sentry Revealed: Observability in Action

4. Google Gemma: Fast Generative Directives with Production Grounding

Grounding & Health Safety Guardrails (src/gemma_service.py)

5. ElevenLabs Voice Architecture: Screen-Free Audio Presence

6. The Field Test: Taking SunSync Outside for 20 Minutes (Bonus Challenge)

7. Handling Timezones & Diurnal States: Real API Outputs

Why Does Open Innovation Matter?

Prize Categories

Featured Categories

1. Best Use of TabPFN (Prior Labs)

2. Best Use of Gemma (Google)

Partner Categories

3. Best Use of Sentry Agent Tracing

4. Best Use of ElevenLabs

Closing: Step Away from the Screen

Building an Agent That Can't Afford to Be Wrong: Quran Sanity Agent

What I Built

How It Works in Practice

Demo

Zero-Trust Transparency: The Live Evidence Drawer

Queries You Can Test Right Now

Code

How I Used Sanity

1. The Content Model (studio/schemaTypes/)

2. The Editorial Review Gate

3. Sanity Context MCP & Semantic Retrieval

Sanity Project Details

What Building This Taught Me

My Phone Broke, and Gemini Fixed It

📱 Picture This: An All-Nighter Turns Into a Morning Nightmare

🥶 Zero Results: When Google Goes Completely Silent

😴 "That’s Future Me’s Problem"

🤖 Handing the Terminal to Gemini

🎨 Step 1: The Canvas Deduction

🔬 Step 2: Disassembling the Phone on the Fly

1. Hunting the String Table

2. Pinpointing the Method

3. Reading the Dalvik Bytecode

💥 Step 3: The Domino Effect — Finding Patient Zero

🎯 The Culprit: persist.log.tag

Connecting the Dots

⚡ The Cure: Total Relief in Five Seconds

1. Resetting the Global Flag

2. Preventing It from Happening Again

3. Killing the Active Process for Instant Testing

4. The Final Device Reboot: Flushing In-Memory State

🎓 Final Thoughts: An Engineering Student Left Speechless

The Ghost in the View Transitions API: A Bizarre Debugging Saga with Google AI 👻

🎨 Project Overview

🐛 Bug Fix

💻 Code

🛠️ My Improvements

🤖 Best Use of Google AI

Phase 1: The Misdiagnosis

Phase 2: The Deep Dive

Phase 3: The "Aha!" Moment

Reviving Daphq: How I Built an Open-Source, Bare-Metal File Transfer Engine Solo with GitHub Copilot

What I Built

Demo

Screenshots in Action

The Comeback Story

The Deep Evolution: v1.0.0 vs. v2.3.0

My Experience with GitHub Copilot

1. Solving the Math of the Orbital Radar UI

2. Eliminating the Windows FFI Mutex Deadlock

3. Engineering Flow-Safe Dynamic Streaming Buffer

The Verdict

Grounding & Health Safety Guardrails (`src/gemma_service.py`)

1. The Content Model (`studio/schemaTypes/`)

🎯 The Culprit: `persist.log.tag`