[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-84189":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":17,"stars90d":16,"forks30d":16,"starsTrendScore":17,"compositeScore":18,"rankGlobal":10,"rankLanguage":10,"license":19,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":22,"hasPages":22,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":41,"readmeContent":42,"aiSummary":10,"trendingCount":16,"starSnapshotCount":16,"syncStatus":43,"lastSyncTime":44,"discoverSource":45},84189,"ParkinSUM","albertzhzhou-droid\u002FParkinSUM","albertzhzhou-droid","Local-first Flutter application for Parkinson's disease diet-medication education and levodopa-food interaction awareness.","",null,"Dart",118,13,8,11,0,20,3.44,"Apache License 2.0",false,"main",true,[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"clinical-decision-support","dart","diet-tracking","digital-health","education","firebase","flutter","health-education","local-first","medical","medication-management","mhealth","neurodegenerative-diseases","nutrition","open-source","parkinsons","parkinsons-disease","2026-06-12 02:04:38","# ParkinSUM Companion\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\"assets\u002Fbrand\u002Fparkinsum-wordmark.png\" alt=\"ParkinSUM food medication interaction logo\" width=\"720\">\n\u003C\u002Fp>\n\n[![CI](https:\u002F\u002Fgithub.com\u002Falbertzhzhou-droid\u002FParkinSUM\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg?branch=main)](https:\u002F\u002Fgithub.com\u002Falbertzhzhou-droid\u002FParkinSUM\u002Factions\u002Fworkflows\u002Fci.yml)\n\nA provenance-first Parkinson medication-food interaction prototype for explainable CDSS architecture, Firebase governance, and synthetic-data demos.\n\n**Educational architecture prototype only. Not medical advice or a clinical decision tool.**\n\n![Flutter](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FFlutter-Prototype-blue)\n![Firebase](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FFirebase-Governance-orange)\n![Educational Prototype](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FScope-Educational%20Prototype-lightgrey)\n![Synthetic Data Only](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FData-Synthetic%20Only-green)\n![Public Showcase](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FMode-Public%20Showcase-purple)\n\nParkinSUM Companion is a local-first Flutter prototype that demonstrates how a health-adjacent app can combine synthetic meal logging, medication context, deterministic rule checks, evidence-oriented explanations, and release safety guardrails without making clinical claims.\n\nIt is a production-architecture prototype designed for educational demonstrations, software architecture review, and academic discussion of local-first digital health prototypes. It is not a medical device and must not be used for diagnosis, treatment, medication timing, dietary guidance, clinical decision-making, patient care, or emergency support.\n\nPublic demos should use synthetic or sample data only.\n\n## What It Demonstrates\n\n- Meal logging and medication-context capture for a Parkinson's disease education scenario.\n- Deterministic food-drug interaction checks instead of black-box medical advice.\n- Evidence-oriented explanations that show why a prototype rule fired.\n- Local-first app behavior for public demos and development.\n- Optional Firebase-backed paths for internal operator validation and governance.\n- Public-release guardrails around disclaimers, security, contribution rules, and synthetic data.\n\n## Algorithm and Safety Boundary\n\nParkinSUM's conflict engine is **deterministic and evidence-linked**: no LLM\nsits inside it, and every educational rule that fires carries a structured\nexplanation with source references, provenance, the input fields actually\nused, any missing or uncertain inputs, an explicit limitation, and a hard\nnot-advice boundary.\n\nMedication context must be **catalog-backed and unit-explicit** before any\nfood-medication rule is evaluated. A bare numeric dose such as `100`, an\nunstructured string such as `\"100 tablets\"`, or a name without a unit such as\n`levodopa 100` is rejected outright — ParkinSUM does not infer mg, tablet\ncount, schedule, formulation, or release type from such input. Entries\nwithout an active ingredient, drug product variant, formulation, or\nprovenance are treated as insufficient context and do not produce a conflict\nresult.\n\nHigh-value contributor work in this area includes:\n\n- Medication context validation (`lib\u002Fdomain\u002Fusecases\u002Fmedication_entry_validator.dart`).\n- Evidence-linked rule explanations (`lib\u002Fdomain\u002Fentities\u002Frule_explanation.dart`).\n- Importer provenance fields (basis, scope, jurisdiction, confidence, source).\n- Negative safety tests that prevent educational copy from drifting into\n  medication timing, dose, dietary, or clinical-validation claims\n  (`test\u002Fmedication_entry_validator_test.dart`,\n  `test\u002Frule_explanation_safety_test.dart`).\n\nSee [docs\u002FRULE_ENGINE.md](docs\u002FRULE_ENGINE.md) for the medication context\ngate, the structured rule-explanation template, a worked levodopa+protein\nexample, and the negative-test expectations.\n\n## Mechanistic Conflict and Recommendation Engine\n\nParkinSUM now includes a deterministic, time-axis, literature-informed\n**educational conflict engine** that models meal composition, gastric\nemptying assumptions, small-intestinal arrival, a levodopa absorption\nopportunity window, an amino-acid competition proxy, overlapping-meal\neffects, and uncertainty bands. Every modeled assumption is backed by a\nlocal source registry (`lib\u002Fdomain\u002Fusecases\u002Fmodel_assumption_registry.dart`)\nthat cites entries in [Bibliographies.md](Bibliographies.md) (MLA format).\n\nThe next-meal recommendation engine accepts a **user-defined time window**\nand a regional food library, then ranks candidate foods inside that window\nby modeled overlap with the educational simulation. **The engine does not\ndecide when the user eats**, does not produce medication timing or dietary\nadvice, and returns `insufficient_context` whenever the window or\nmedication context is missing.\n\nThe mechanistic engine is now the **primary ranker** for next-meal\nrecommendations whenever the request carries a user-defined time window\nand the engine has at least `medium` confidence — see\n`docs\u002FCONFLICT_ENGINE_MODEL.md` for the promotion contract and the\n`rankerUsed` field. Candidate scoring uses **deterministic multi-point\nsampling** (5–12 samples, capped) across the user-provided window; the\nworst-case overlap drives ranking and the best\u002Faverage\u002Fper-sample summary\nis surfaced for trace and UI. Gastric-emptying numerics live in a single\n`GastricEmptyingParameterSet` with per-parameter `sourceRefs`, and the\namino-acid competition layer now applies a coarse, direction-only\n**LNAA load factor** per protein source (animal vs plant). The runtime\nfood repository is augmented at app boot with foods projected from CDSS\nobservations so the scorer can rank real catalog-backed candidates, not\nonly synthetic replay items.\n\nThe data chain preserves fidelity end-to-end: missing nutrient data is\ncarried as **unknown, never coerced to a fake `0 g`** (`missingNutrientFields`\n→ null components → lowered composition completeness → widened uncertainty);\nactual USDA FDC **amino-acid fields** (verified nutrient-number mapping) feed\nthe LNAA layer in preference to the protein-source proxy; per-candidate\n`CandidateMetadata` (authority, jurisdiction match, completeness, provenance)\nis built from imported source data so official-in-jurisdiction outranks\nsynthetic\u002Fseed. The medication **dose is taken only from the user's entered\ndosage note** (value + unit must both be explicit) — there is no private\ndefault; a missing\u002Fambiguous dose yields insufficient context and blocks\ndose-dependent interpretation. The conflict engine evaluates **each levodopa\ndose** on a multi-dose time axis and aggregates with deterministic\nmax-overlap, keeping per-dose traces.\n\nCompact mechanistic-trace UI cards render alongside the existing\nrecommendation and conflict-result views via an `ExpansionTile` so the\nnew surface stays out of the way until a reviewer expands it. Raw trace\nJSON is never shown by default.\n\nSynthetic replay scenarios are available via the CLI:\n\n```sh\ndart run tool\u002Frun_mechanistic_replay.dart\n# or\nnpm run mechanistic:replay\n```\n\nThe runner writes `build\u002Fmechanistic_replay\u002Flatest.{json,md}` and exits\nnon-zero on any expectation mismatch or banned-phrase hit.\n\nSee [docs\u002FCONFLICT_ENGINE_MODEL.md](docs\u002FCONFLICT_ENGINE_MODEL.md) for the\nlayered model description and [docs\u002FREPLAY_RUNNER.md](docs\u002FREPLAY_RUNNER.md)\nfor the scenario format and CLI details. ParkinSUM does not overclaim\nclinical accuracy; the engine is an educational simulation, not a\npatient-care tool.\n\n## Educational Model Guardrails\n\nThe mechanistic conflict engine is **not clinically calibrated**. Its\ngastric-emptying values are literature-informed prototype parameters; the\namino-acid (LNAA) competition layer is an educational proxy. It makes **no\npatient-specific pharmacokinetic\u002Fpharmacodynamic prediction**, gives no\nmedication-timing, dietary, or dose guidance, and carries no clinical-validation\nclaim. All importer adapters are fixture-validated (not live production\ningestion); the optional live-source smoke harness is opt-in, excluded from\nnormal tests, fetches official metadata only, and is not used for clinical\nadvice. Source-specific legal\u002Flicense review remains future work — see\n[docs\u002FSOURCE_ACCESS_AND_LICENSES.md](docs\u002FSOURCE_ACCESS_AND_LICENSES.md).\n\n## Multi-Jurisdiction Metadata & Protein Redistribution\n\nParkinSUM's importer layer is multi-jurisdiction: source-adapter specs cover\nDailyMed (US), Health Canada DPD (CA), EMA + EU national registers (EU\u002FEEA),\nNHS dm+d (GB), PMDA (JP), NMPA (CN), and food-composition sources (USDA FDC,\nCiqual, China CDC), with a deterministic source-authority scorer\n(official-in-jurisdiction outranks others; reference translations are\ndowngraded; seed\u002Fsynthetic never overrides official; cross-jurisdiction\nconflicts are preserved, not merged). Canonical source\u002Fprovenance metadata —\njurisdiction, language, unit, basis, authority tier, completeness, limitation\n— is preserved from importer to runtime so the mechanistic engine and scorer\ncan reason about it.\n\nThe next-meal scorer models **protein redistribution, not global protein\nminimization**: protein is penalized only in modeled high-overlap windows and\nallowed in low-overlap windows, with a non-clinical nutrition-adequacy proxy\nso zero-protein does not automatically win. Window role is decided primarily\nfrom modeled overlap, not the clock. The next-meal page lets the user provide\na meal-time *window*; mechanistic-primary ranking activates only with a\nuser-provided window and sufficient context.\n\nSee [docs\u002FIMPORTER_METADATA_FLOW.md](docs\u002FIMPORTER_METADATA_FLOW.md) for the\ncanonical metadata model, source-authority policy, cross-jurisdiction conflict\npolicy, completeness gate, and the protein-redistribution objective, and\n[docs\u002FMANUAL_VALIDATION.md](docs\u002FMANUAL_VALIDATION.md) for a hands-on\nwalkthrough.\n\nFixture-tested medication source parsers now cover DailyMed, Health Canada\nDPD, EMA, PMDA, **NHS dm+d** (identity\u002Fcoding — not a complete food-effect\nsource), **EU national registers** (member-state identity vs full SmPC), and\n**NMPA** (fixture-validated \u002F prototype, honestly downgraded). A\n`SourceFetchClient` abstraction (with an offline `FixtureSourceFetchClient`\nreturning structured `SourceFetchResult`s) keeps all tests deterministic;\nlive fetch is optional and never used for clinical advice. Per-food\namino-acid fields, when present, drive the LNAA competition layer in\npreference to the protein-source proxy. The legacy heuristic can only order\nresults when `rankerEligibility.mechanisticPrimaryEligible == false`, with the\nreason surfaced in UI + replay.\n\n## Evidence & Traceability Architecture\n\nParkinSUM's most reviewable surface is its **evidence and provenance layer**.\nEvery educational output is deterministic, source-linked, and serializable for\nreview — without any patient data.\n\n- **Deterministic mechanistic replay** — 41 synthetic scenarios, banned-phrase\n  scanned (`docs\u002FREPLAY_RUNNER.md`).\n- **CDSS-style source\u002Fprovenance metadata** with **source-authority** and\n  **metadata-completeness** gates (`docs\u002FIMPORTER_METADATA_FLOW.md`).\n- **FDC nutrient provenance tiers** (analytical \u002F calculated \u002F imputed \u002F unknown)\n  as **source-quality signals** that affect modeled confidence, not advice.\n- **Multi-dose medication traces** with per-dose modeled overlap.\n- **Local EvidenceTraceBundle** — a ParkinSUM-local artifact (explicitly **not** a\n  FHIR Bundle) pairing the two inspired views (`docs\u002FEVIDENCE_TRACE_BUNDLE.md`).\n- **FHIR-inspired, non-conformant** NutritionIntake \u002F MedicationKnowledge views\n  (PHI-free; `inspired_not_conformant`) with a conservative **LOINC section-code**\n  trace.\n- **Source-quality perturbation report** — shows how scoring moves when only\n  source\u002Fprovenance quality changes (`docs\u002FSOURCE_QUALITY_PERTURBATION_REPORT.md`).\n- **Public preflight + Firestore rules contract** release guardrails.\n\n```text\nsource\u002Fimporter metadata → normalized facts (missing ≠ zero)\n  → metadata completeness + source authority\n  → mechanistic engine (per-dose) → replay \u002F source-quality report\n  → FHIR-inspired views + local EvidenceTraceBundle\n```\n\nReviewer entry points: **[docs\u002FEVIDENCE_AND_TRACEABILITY_DEMO_GUIDE.md](docs\u002FEVIDENCE_AND_TRACEABILITY_DEMO_GUIDE.md)**\n(guided walkthrough), **[docs\u002FCAPABILITY_MATRIX.md](docs\u002FCAPABILITY_MATRIX.md)**\n(implemented vs future work), **[docs\u002FPUBLIC_VERIFICATION.md](docs\u002FPUBLIC_VERIFICATION.md)**\n(exact commands), and the **[docs index](docs\u002FREADME.md)**. These artifacts are\ndeterministic synthetic-data demonstrations — they are **not** clinical\nvalidation, and the source-quality report is **not** a clinical dashboard.\n\n## Demo Media\n\nThe screenshots below use synthetic local demo data only. Real account identifiers are redacted or replaced with a synthetic demo address. They show the current public prototype flow and are not medical advice, clinical validation, or patient data.\n\n| Feature shown | Demo screenshot | What it demonstrates |\n| --- | --- | --- |\n| Account entry | ![ParkinSUM sign-in screen with synthetic local demo styling](docs\u002Fassets\u002Fscreenshots\u002Fauth-sign-in.png) | Authentication shell and privacy\u002Fdisclaimer entry point. |\n| Next-meal setup | ![Next-meal setup screen with time-window controls and local AI toggle](docs\u002Fassets\u002Fscreenshots\u002Fnext-meal-setup.png) | User-provided meal timing window, conservative path, and optional local-AI wording polish. |\n| Next-meal results | ![Next-meal recommendation results with ranked synthetic food candidates](docs\u002Fassets\u002Fscreenshots\u002Fnext-meal-results.png) | Ranked food candidates, allow labels, and explanation bullets from the deterministic recommendation flow. |\n| Timeline overview | ![Meal and medication timeline showing synthetic medication and meal events](docs\u002Fassets\u002Fscreenshots\u002Ftimeline-overview.png) | Meal-medication chronology, nearest-event context, and editing controls. |\n| Timeline action state | ![Timeline action state with add-meal and log-medication controls](docs\u002Fassets\u002Fscreenshots\u002Ftimeline-action-state.png) | Floating meal and medication logging actions in the timeline workflow. |\n| Medication catalog | ![Medication list with selected synthetic levodopa-combination context](docs\u002Fassets\u002Fscreenshots\u002Fmedications-catalog.png) | Medication catalog entries, jurisdiction source labels, and selected medication context. |\n| Search\u002Fcatalog showcase | ![Catalog page with ParkinSUM branded showcase module and searchable foods](docs\u002Fassets\u002Fscreenshots\u002Fcatalog-showcase.png) | GitHub-style branded repository module integrated into catalog search. |\n| Conflict explanation | ![Meal check conflict explanation dialog with conservative high-risk educational copy](docs\u002Fassets\u002Fscreenshots\u002Fconflict-explanation.png) | Evidence-oriented safety explanation, rule weights, model trace, and non-clinical boundary copy. |\n| Analytics and local AI | ![Analytics screen with localization status and local AI configuration fields](docs\u002Fassets\u002Fscreenshots\u002Fanalytics-local-ai.png) | Localization status, local AI provider settings, model names, endpoints, and conservative recommendation path. |\n\nCapture requirements are tracked in [docs\u002Fmedia-capture-checklist.md](docs\u002Fmedia-capture-checklist.md), with asset-folder notes in [docs\u002Fassets\u002Fscreenshots\u002FREADME.md](docs\u002Fassets\u002Fscreenshots\u002FREADME.md) and [docs\u002Fassets\u002Fdemo\u002FREADME.md](docs\u002Fassets\u002Fdemo\u002FREADME.md).\n\n## Quick Start\n\n## High-Impact Contribution Request\n\nThe current priority is [Issue #8](https:\u002F\u002Fgithub.com\u002Falbertzhzhou-droid\u002FParkinSUM\u002Fissues\u002F8): mapping one educational rule explanation to explicit evidence fields.\n\nThe most valuable contribution right now is not adding new medical rules. Instead, contributors should help make existing rule explanations more traceable and reviewable by improving:\n\n- source references\n- provenance clarity\n- limitation text\n- safety-boundary wording\n- negative tests that prevent unsupported clinical claims\n\nSee [docs\u002FRULE_ENGINE.md](docs\u002FRULE_ENGINE.md) for the contributor-facing rule explanation template and worked example.\n\nInstall Flutter, Node.js, and npm first. Then run these commands from the repository root:\n\n```sh\ngit clone https:\u002F\u002Fgithub.com\u002Falbertzhzhou-droid\u002FParkinSUM.git\ncd ParkinSUM\nflutter pub get\nflutter run -d chrome\n```\n\nEvaluate the prototype locally:\n\n```sh\ndart format --output=none --set-exit-if-changed .\nflutter analyze\nflutter test\nnpm ci\nnpm run public:preflight\nnpm run rules:contract\n```\n\nRun the deterministic evidence artifacts (synthetic data; not clinical\nvalidation):\n\n```sh\ndart run tool\u002Frun_mechanistic_replay.dart            # or: npm run mechanistic:replay\ndart run tool\u002Frun_source_quality_perturbation_report.dart  # or: npm run source:quality\n```\n\nSee [docs\u002FPUBLIC_VERIFICATION.md](docs\u002FPUBLIC_VERIFICATION.md) for what each\ncommand checks, its expected output, and what failure means.\n\nThe default public-demo path is local mode. Firebase-backed commands are retained for internal operator validation and require project access.\n\n## Release\n\nThe current public showcase target is `v0.2.0-beta`. Release materials are tracked in [CHANGELOG.md](CHANGELOG.md), [docs\u002Frelease\u002Fv0.2.0-beta-notes.md](docs\u002Frelease\u002Fv0.2.0-beta-notes.md), [docs\u002Frelease\u002Fsynthetic-demo-data.md](docs\u002Frelease\u002Fsynthetic-demo-data.md), and [docs\u002Frelease\u002Frelease-checklist.md](docs\u002Frelease\u002Frelease-checklist.md). The earlier alpha materials remain at [docs\u002Frelease\u002Fv0.1.0-alpha-notes.md](docs\u002Frelease\u002Fv0.1.0-alpha-notes.md).\n\nA scoped release-metadata package is published to GitHub Packages (npm registry) as `@albertzhzhou-droid\u002Fparkinsum-companion` on each tagged release; see [packages\u002Fnpm\u002FREADME.md](packages\u002Fnpm\u002FREADME.md).\n\nAny Android APK generated for this beta must be labeled as a beta\u002Fdemo\u002Fdebug artifact unless production signing is handled in a separate release process.\n\n## Project Website\n\nA lightweight GitHub Pages landing page is available in [docs\u002Fsite\u002Findex.html](docs\u002Fsite\u002Findex.html). Setup instructions are in [docs\u002Fsite\u002FREADME.md](docs\u002Fsite\u002FREADME.md).\n\nAn animated Liquid Glass-style showcase wiki is available in [docs\u002Fwiki\u002Findex.html](docs\u002Fwiki\u002Findex.html). GitHub Wiki-compatible Markdown pages are staged in [docs\u002Fgithub-wiki\u002F](docs\u002Fgithub-wiki\u002F) so they can be published to the repository Wiki interface.\n\n## Contribute\n\nStart with the [contribution guide](CONTRIBUTING.md), then choose a scoped item from the [public contribution backlog](docs\u002Fcontribution-backlog.md). Use the structured GitHub issue templates for bugs, features, documentation improvements, and research-rule evidence requests. A small real contributor PR request is drafted in [docs\u002Fmentor-pr-request.md](docs\u002Fmentor-pr-request.md) for classmates or mentors who want to test the project without making medical claims. Public examples must use synthetic or sample data only.\n\nSecondary creators who need to fork the project, configure local GitHub authentication, and submit updates by pull request should follow the [secondary creator token flow](docs\u002Fsecondary-creator-token-flow.md). The repository documents fork-scoped token permissions and setup steps, but never stores real token values.\n\n## Architecture Overview\n\n```mermaid\nflowchart LR\n  UI[\"Flutter UI\"]\n  State[\"App State\"]\n  Data[\"Local-first Data Layer\"]\n  Rules[\"Deterministic Rule Engine\"]\n  Evidence[\"Evidence Explanation Layer\"]\n  Output[\"Educational Awareness Output\"]\n\n  UI --> State\n  State --> Data\n  Data --> Rules\n  Rules --> Evidence\n  Evidence --> Output\n```\n\nThe app separates user-facing screens, app state, local data handling, deterministic rule evaluation, and evidence-oriented explanation copy. Firebase services are available for internal validation, but the public prototype should be evaluated with synthetic data and conservative claims.\n\nSee [docs\u002FARCHITECTURE.md](docs\u002FARCHITECTURE.md) and [docs\u002FRULE_ENGINE.md](docs\u002FRULE_ENGINE.md) for more detail.\n\n## Safety Boundary\n\nParkinSUM Companion is an educational awareness prototype only.\n\n- It does not diagnose, treat, monitor, prevent, or manage disease.\n- It does not provide individualized dietary, medication, clinical, or emergency advice.\n- It has no patient-outcome validation or clinical-use approval.\n- It should not be connected to real health records for public demos.\n- Screenshots, tests, walkthroughs, and examples should use synthetic or sample data only.\n\nRead [DISCLAIMER.md](DISCLAIMER.md) and [docs\u002FPUBLIC_DEMO_BOUNDARY.md](docs\u002FPUBLIC_DEMO_BOUNDARY.md) before presenting or reusing the project.\n\n## Repository Map\n\n| Path | Purpose |\n| --- | --- |\n| `lib\u002Fapp\u002F` | Flutter app bootstrap and top-level app wiring. |\n| `lib\u002Ffeatures\u002F` | User-facing flows such as dashboard, meals, medications, onboarding, import, and recommendations. |\n| `lib\u002Fcore\u002F` | Shared models, state, services, database adapters, constants, i18n, and copy helpers. |\n| `lib\u002Fdomain\u002F` | Entities, repositories, deterministic rule use cases, recommendation orchestration, and evidence-oriented runtime logic. |\n| `lib\u002Fdata\u002F` | Local and remote data-source implementations, importers, and repository implementations. |\n| `test\u002F` | Focused Flutter and Dart tests for rule execution, importers, onboarding, Firebase boundaries, and recommendation copy. |\n| `tool\u002F` | Public preflight, Firebase governance, release, monitoring, and operator-validation scripts. |\n| `docs\u002F` | Architecture, rule-engine, release, public-boundary, risk, security-adjacent, and operations documentation. |\n\n## Current Status\n\n- Public release type: prototype showcase.\n- Current public release target: `v0.2.0-beta`.\n- Package name: `parkinsum_companion`.\n- Current app version: `0.2.0+2`.\n- Default public-demo backend: local mode.\n- Firebase backend mode: internal operator validation only.\n- Public contact: `parkinsumservice@gmail.com`.\n- Public readiness gate: `npm run public:preflight` should report zero `BLOCKER` findings before publication.\n\nPublic GitHub visibility does not claim external clinical, legal, privacy, regulatory, or patient-outcome approval.\n\n## Roadmap\n\nNear-term work is tracked in [ROADMAP.md](ROADMAP.md). Current priorities include:\n\n- Capture clean synthetic-data screenshots and a short demo GIF.\n- Keep the rule engine evidence-linked and auditable.\n- Improve accessibility, localization, and caregiver-oriented educational flows.\n- Expand sample-data walkthroughs without adding real patient data.\n- Maintain release, security, and public-readiness checks as the prototype changes.\n\n## Citation \u002F Academic Use\n\nParkinSUM Companion may be cited as a software prototype or educational research artifact. Do not cite it as a clinical intervention, medical device, treatment system, or patient-outcome study.\n\nSuggested citation format:\n\n```text\nZhou, Z. ParkinSUM Companion: a local-first Flutter prototype for Parkinson's disease diet-medication education. GitHub repository, 2026. Available at: https:\u002F\u002Fgithub.com\u002Falbertzhzhou-droid\u002FParkinSUM\n```\n\nIf you discuss the project academically, include the safety boundary: educational awareness only, synthetic\u002Fdemo data only, and no diagnosis, treatment, medication timing, dietary guidance, clinical decision-making, or patient-care use.\n\n## Documentation\n\n### Start here\n- [Documentation index](docs\u002FREADME.md)\n- [Public verification guide](docs\u002FPUBLIC_VERIFICATION.md)\n- [Contribution guide](CONTRIBUTING.md)\n- [Rule engine overview](docs\u002FRULE_ENGINE.md)\n- [Project website](docs\u002Fsite\u002Findex.html)\n- [Animated showcase wiki](docs\u002Fwiki\u002Findex.html)\n- [GitHub Wiki source pages](docs\u002Fgithub-wiki\u002FHome.md)\n\n### Architecture\n- [Architecture overview](docs\u002FARCHITECTURE.md)\n- [Conflict engine model](docs\u002FCONFLICT_ENGINE_MODEL.md)\n- [Importer & metadata flow](docs\u002FIMPORTER_METADATA_FLOW.md)\n- [Evidence trace bundle](docs\u002FEVIDENCE_TRACE_BUNDLE.md)\n\n### Safety and release\n- [Disclaimer](DISCLAIMER.md)\n- [Security policy](SECURITY.md)\n- [Roadmap](ROADMAP.md)\n- [Contribution guide](CONTRIBUTING.md)\n- [Contribution backlog](docs\u002Fcontribution-backlog.md)\n- [Secondary creator token flow](docs\u002Fsecondary-creator-token-flow.md)\n- [Mentor\u002Fclassmate PR request](docs\u002Fmentor-pr-request.md)\n- [Changelog](CHANGELOG.md)\n- [Citation metadata](CITATION.cff)\n- [Repository metadata recommendations](docs\u002Frepository-metadata.md)\n- [Social preview brief](docs\u002Fmedia\u002Fsocial-preview.md)\n- [Rule engine testing](docs\u002Frule-engine-testing.md)\n- [Impact one-page summary](docs\u002Fimpact\u002Fone-page-summary.md)\n- [Impact technical case study](docs\u002Fimpact\u002Ftechnical-case-study.md)\n- [Impact project pitch](docs\u002Fimpact\u002Fproject-pitch.md)\n- [Impact FAQ](docs\u002Fimpact\u002Ffaq.md)\n- [Impact safety and ethics](docs\u002Fimpact\u002Fsafety-and-ethics.md)\n- [v0.2.0-beta release notes](docs\u002Frelease\u002Fv0.2.0-beta-notes.md)\n- [v0.1.0-alpha release notes](docs\u002Frelease\u002Fv0.1.0-alpha-notes.md)\n- [Synthetic demo data](docs\u002Frelease\u002Fsynthetic-demo-data.md)\n- [Synthetic demo scenarios](docs\u002Fdemo-scenarios.md)\n- [Release checklist](docs\u002Frelease\u002Frelease-checklist.md)\n- [Project website](docs\u002Fsite\u002Findex.html)\n- [Animated showcase wiki](docs\u002Fwiki\u002Findex.html)\n- [GitHub Wiki source pages](docs\u002Fgithub-wiki\u002FHome.md)\n- [GitHub Pages setup](docs\u002Fsite\u002FREADME.md)\n- [Public showcase readiness](PUBLIC_SHOWCASE_READINESS.md)\n- [Public demo boundary](docs\u002FPUBLIC_DEMO_BOUNDARY.md)\n- [Release checklist](docs\u002Frelease\u002Frelease-checklist.md)\n- [Known risks](docs\u002Fknown_risks.md)\n\n### Demo and impact\n- [Synthetic demo scenarios](docs\u002Fdemo-scenarios.md)\n- [Media capture checklist](docs\u002Fmedia-capture-checklist.md)\n- [Impact one-page summary](docs\u002Fimpact\u002Fone-page-summary.md)\n## Contributing\n\nContributions are welcome when they keep the public prototype boundary intact. Good first areas include documentation, UI strings, accessibility notes, synthetic sample interactions, and focused tests. Start with [CONTRIBUTING.md](CONTRIBUTING.md).\n\nDo not submit personal health information, real medication schedules, credentials, service account keys, private Firebase exports, or raw operator logs.\n",2,"2026-06-11 04:12:31","CREATED_QUERY"]