Users of SparkyFitness — a popular self-hosted, family-oriented food/fitness/health tracker — want to log medications and supplements on recurring schedules plus record daily symptoms (onset, duration, intensity) alongside their existing nutrition, sleep, and mood data. This is the chronic-illness 'what did I take and how did I feel' correlation layer, distinct from calorie tracking. The requester flags it as outright blocking their adoption of the app, and the value is having med/symptom data sit next to the rest of the health dataset for trigger analysis.
builder note Don't build yet another standalone pill reminder — the demand is specifically for med/symptom data living NEXT TO food, mood, and sleep logs for correlation. The defensible piece is the trigger view ('flare days vs supplements taken'), which standalone reminder apps structurally can't offer. Ship it as a SparkyFitness module/PR or a companion that reads its DB, not a from-scratch app. This is one explicit 'blocking' request, not viral volume — weigh it as a focused niche bet.
landscape (2 existing solutions)
Standalone FOSS med-reminder apps are mature, but none combine medication and symptom logging with the rest of a self-hosted health dataset (food/mood/sleep) so chronically ill users can correlate triggers. SparkyFitness has the platform and the audience but not the feature.
SparkyFitness Tracks nutrition, exercise, hydration, sleep, fasting, mood, and body measurements per its README — but no medication, supplement, or symptom tracking, and it is not on the roadmap. Dose (dose-android) Mature standalone Android med reminder, but reminder-only, not self-hosted, with no symptom correlation and no integration with a nutrition/mood/sleep dataset. sources (1)
chronic-illnessself-hostedmedication-trackingsymptom-trackerhealth
Home cooks who self-host want to define reusable component recipes (a dough, a bechamel, a bolognese, a stock) once and compose them into larger dishes as a graph, so editing the component updates every dish that uses it AND the component's quantities scale automatically when the parent recipe's servings change. Mealie has no recipe composition at all (the suggested workaround is pasting a hyperlink into the ingredient list, which neither composes nor scales), and Tandoor lets you embed a recipe as a step but does not scale the nested recipe's quantities. Auto-scaling, reusable sub-recipes are the recurring missing primitive across both leading FOSS recipe apps.
builder note The trap is the scaling math, not the linking. Embedding a recipe is easy; the value is unit-aware quantity propagation through a DAG (component yields '1 batch = 500g dough'; parent needs 750g -> 1.5x, and the whole tree re-scales when parent servings change). Get the yield/unit model wrong and you ship the same useless hyperlink everyone already rejects. Best built as a Mealie/Tandoor contribution or a thin layer over their APIs — the audience is already committed to those tools.
landscape (2 existing solutions)
Mealie and Tandoor are the two dominant self-hosted recipe managers. Both handle within-recipe organization (sections/steps), but neither offers reusable component recipes that scale: Mealie has no composition, Tandoor has composition without scaling. The demand is specifically DRY, auto-scaling sub-recipes for cooks who batch shared bases.
Mealie No sub-recipe / nested-recipe composition. Ingredient sections (headings within ONE recipe) exist, but you cannot reference another recipe as a scalable component (per the features page and open issue #7771). Tandoor Recipes You can embed a recipe as a step, but there is no portion/scaling adjustment for the nested recipe — so a shared dough or creme can't be pulled in at different amounts per parent. Documented in open issue #4437 (a user needing shared 'basic recipes (dough or cremes)' in different amounts), which corroborates the cross-app recurrence of this demand. sources (1)
recipe-managerself-hostedsub-recipesscalingfoss
Users of an offline on-device speech-to-text / live-subtitle Android app are independently asking for captions to be translated into another language in real time — e.g. watching Chinese video and wanting English subtitles — not just transcribed in the same language. Every mainstream option misses this exact combination: Android Live Caption and Google Live Transcribe caption on-device but don't translate, while Google Translate's transcribe mode translates but is cloud-dependent. A FOSS, offline, real-time speech-to-translated-caption tool serves both deaf/HoH users and people consuming foreign-language media privately.
builder note The hard part isn't translation quality — it's the end-to-end latency budget (on-device ASR chunk -> on-device MT -> overlay render) while staying offline. Reaching for a cloud MT API is trivial but destroys the privacy/offline value prop that makes users pick this over Google. Pairing a small on-device MT model (e.g. an NLLB distill) with the app's existing ASR is the real differentiator.
landscape (3 existing solutions)
Clear segmentation gap: on-device captioning tools don't translate, and real-time speech-translation tools are cloud-based, while OCR overlays only translate on-screen text. No confirmed FOSS, offline, real-time speech-to-translated-caption tool exists for Android.
Android Live Caption On-device and free, but captions in the SAME language only — does not translate speech into another language. Google Live Transcribe Transcription across 70+ languages, but no translation of the spoken language into a different one. Google Translate (Transcribe mode) Real-time translated transcription exists but is cloud/network-dependent — not the offline, privacy-preserving on-device flow these users want. sources (2)
accessibilitydeaf-hohlive-captionson-device-mltranslation
Developers running Claude Code / Codex autonomously report agents falling into doom loops: re-running tests against a small self-inflicted error (missing import, wrong param) and burning enormous token volume with zero progress. The specific pain is detecting and halting on repeated failed/no-diff actions, which current guardrails treat as a weak heuristic bolted onto a deterministic budget cap that fires a turn or more too late. The wedge is loop/no-progress detection as the PRIMARY halt trigger, independent of spend — and crucially one that catches paraphrased retries, not just exact-match repeats.
builder note Distinct from a budget cap or cost dashboard — users say those fire too late. The defensible product leads with semantic detection (repeated edit-test-fail cycles, no-diff progress over N turns) and halts immediately. The hard part is catching paraphrased retry loops, because naive exact-hash matching misses them; that detection is the moat, not the dashboard.
landscape (3 existing solutions)
Existing guardrails anchor on dollar/token budget caps and treat loop detection as an afterthought, so they halt only after the waste happens; nothing leads with semantic 'agent is repeating failed actions / making no progress' detection as the primary, immediate trigger.
Burnstop Verified by fetch: 'Loop detection is a heuristic; the budget cap is the deterministic backstop.' Loop detection is explicitly secondary, fires roughly one turn behind, and 'can't stop mid-turn' — so a real loop is only caught after the spend, not on the no-progress signal itself. Loopers (tryloopers.com) Primarily a token/dollar budget firewall; 'loop detection' is listed but under-specified, with no distinction between semantic no-progress detection and statistical thresholds. Codex built-in Stop The vendor's own halt is reactive and slow (10-20s inside a tool-call loop) and there is no automatic detection that fires without a human watching. sources (3)
ai-agentsclaude-codecodexloop-detectionguardrails
Developers building Model Context Protocol servers for enterprises keep hitting the same wall: the MCP auth spec assumes OAuth Dynamic Client Registration (DCR), but Microsoft Entra ID — the dominant enterprise IdP — doesn't support DCR, so each builder hand-rolls a proxy that injects a fixed client_id and pretends to the client that DCR works. On top of that, clients like OpenAI Codex dead-end when a refresh token expires, halting with a manual re-auth prompt instead of recovering. The opening is a drop-in SDK/gateway that gives spec-compliant proxy-with-fallback for Entra plus robust automatic re-auth, so builders stop rebuilding the same shim.
builder note Don't pitch 'an MCP auth gateway' generically — the sharp wedge is the two specific failures people name: Entra-no-DCR (a clean proxy-with-fallback that handles the app-registration plumbing for the builder), and clients that halt on an expired refresh token instead of recovering. The auto re-auth loop is the part even OpenAI's own client gets wrong today, so nail that.
landscape (3 existing solutions)
The ecosystem agrees Entra can't do DCR and has converged on the same manual OAuth-proxy shim; Anthropic just shipped enterprise-managed auth but Okta-only, leaving the Entra builder experience and the refresh-token-expiry dead-end unsolved.
FastMCP Azure / OAuth Proxy Verified by fetch: 'Since Azure doesn't support Dynamic Client Registration, this integration uses the OAuth Proxy pattern.' It ships the workaround, not a turnkey fix — the developer still manually creates the app registration, client secret, redirect URI, and scopes, and it does not address the expired-refresh-token dead-end. Anthropic / Okta Enterprise-Managed Authorization (EMA) Announced 2026-06-18 with 'Okta is the first supported identity provider.' Entra ID is not supported and no timeline is given; EMA addresses enterprise consent/audit, not the Entra DCR gap individual server builders hit. Obot (commercial MCP gateway) Confirms 'Microsoft Entra ID does not support Dynamic Client Registration' and sells a hosted paid gateway as the fix — an external intermediary, not something solo and small-team builders can drop into their own clients/SDKs. sources (2)
mcpoauthentra-identerpriseagents