meuusSoul LEARN layer
The detailed Journey methodology and manual worksheets can be public learning content now. meuusSoul does not need to pretend it is the authenticated Journey execution app.
Current meuus.app evidence
Accepted control records preserve current Vercel production, active Supabase production, profile data, growth-path structures, user-path records, task structure/data, and accepted authenticated Android Journey/task reads. These are real implementation/runtime evidence classes and should not be erased.
What is not proved by that evidence
It does not automatically prove a full personalized 90-day dashboard, cross-device synchronization, automatic notifications, Garden/full gamification, AI Journey coaching, re-DLAS, validated scoring, practitioner review, payment/entitlement, or every Nine-Pillar journey stack.
Historical target briefs are not runtime evidence
Recovered meuus.app briefs describe target routes for Journey home, day pages and progress. They explicitly say TARGET — FULL BUILD and warn that the file does not claim the route is implemented, deployed or public. DEPTH-07 preserves them as design targets.
Use granular capability labels
Classify a Journey capability as Runtime Verified, Source Implemented, Database Present, Partial, Manual, Pilot, In Review, Historical Architecture, Present But Not Verified, or Not Found. Do not force the whole Journey system into one label.
Reflection
Questions to sit with
- What exact claim about Journey runtime am I making?
- Which evidence class supports it?
- Am I accidentally upgrading architecture or database presence into end-to-end runtime?