H1Platform PRD - Molino App
version: 2026.04
status: locked
owner: Molino
scope: framework / auth / users / integrations / studio
last_updated: 2026-04-26
H2Focus Strip
| Now | Lock | Do Not Break | Next Closure |
|---|---|---|---|
| Shared boundaries | API vs action rule | auth/user ownership, Studio nav | classify routes before broad platform cleanup |
| State | Meaning |
|---|---|
| built/locked | auth/user/API surfaces exist, /md exists |
| built/partial | mixed API/action patterns |
| docs-ahead | route-by-route boundary classification |
H10. Implementation Snapshot
H2Current goal
H3Keep Platform as the shared application rule layer
Use it for architecture, auth, users, integrations, API boundaries, and editorial conventions.
H2Remaining features
H3Keep auth and user mutation boundaries explicit
Protect user mutation ownership.
H3Reserve API routes for external, machine-driven, webhook, callback, or sync access
Keep internal UI flows away from the external API surface.
H3Keep Studio navigation rules centralized and consistent
Preserve the shared nav contract.
H3Keep integrations isolated from domain-specific business authority
Do not let integrations take over module truth.
H2Next build steps
H3Inspect `app/auth/`, `app/users/`, `app/api/user/`, `app/api/admin/users/`, `app/api/partners/`, and `app/api/sync/`
Check the surface areas that depend on Platform rules.
H3Verify internal UI flows call actions instead of internal API routes
Keep internal flows on the action boundary.
H3Confirm Studio nav remains Home, Skills, Practice, Experience
Keep the primary menu locked.
H3Archive superseded platform notes locally when replacing them
Keep the rule layer tidy as it changes.
H2Prompt starter summary
H3Preserve the shared architecture, auth/users/integrations layer
Keep API routes reserved for external or machine-driven access.
H2Prompt starter
Implement the next Platform PRD slice. Use _PRD/platform/README.md as source of truth. Platform defines shared architecture, auth, users, integrations, API boundaries, and editorial conventions. Keep auth/user mutations in their proper server-side boundaries. API routes are for external systems, webhooks, callbacks, CRON, sync, or machine-to-machine access; internal UI workflows should not call the app's own API routes. Preserve Studio nav rules: Home, Skills, Practice, Experience. Keep integrations isolated from vertical module authority.
H21. Product Identity
H3Name
Platform
H3One-line Definition
Platform is the shared application system that defines architectural rules, auth boundaries, users, integrations, and editorial surfaces.
H3Internal Platform Purpose
Inside Molino App, this feature exists to:
- preserve repository-wide authority rules
- keep auth and user flows separate from business module truth
- hold integration and editorial conventions in one clean place
H22. Scope
H3In Scope
- framework and architecture notes
- auth and user surfaces
- integration routes and external callbacks
- studio and editorial support systems
- shared route and API conventions
H3Out of Scope
- replacing domain-specific PRDs
- collapsing all module logic into one system doc
H23. Authority Model
- framework docs define the rules
- auth actions own login and user mutation flows
- API routes are reserved for external or machine-driven access
- editorial or studio surfaces stay separate from commercial truth
- the Studio menu is locked to Home, Skills, Practice, and Experience
- Travel and Trips are derived from Experience, not top-level primary nav
- Writing remains secondary until explicitly promoted
H24. Current Implementation Surface
app/auth/app/users/app/api/user/app/api/admin/users/app/api/partners/app/api/sync/app/md/app/lib/_PRD/framework/_PRD/studio/_PRD/tools/integrations/
H24.1 Code Audit - 2026-04-26
H3Built / locked
- Auth and user code exists under both
app/auth/and selectedapp/api/auth/*routes. - User service and action files exist under
app/users/. - Platform API surfaces exist for user, admin users, partners, sync, projects, auth, and assistant-related machine routes.
app/md/exists as the PRD/markdown browser and execution-router surface.
H3Built / partial
- The repository still has mixed internal API and server-action patterns. Treat the PRD rule as the target: internal UI work should prefer server actions, while API routes remain for external, callback, sync, or machine access.
- Studio navigation is mostly locked in
EditorialHeader, with non-primary Writing/Journey/Tourism links commented out.
H3Docs-ahead / pending
- Platform docs still need a deeper route-by-route classification of which API endpoints are external/machine surfaces and which should eventually move behind actions.
- Duplicate auth option locations should be audited before auth changes.
H3Critical next step
Do not start a broad Platform cleanup before the commercial pipeline is stable. When Platform is touched, classify routes by boundary first, then migrate internal-only UI calls to server actions deliberately.
H25. Acceptance Criteria
- architecture rules remain easy to find
- auth and user mutation boundaries stay explicit
- integration surfaces are isolated and easy to inspect
- older platform notes move into
archive/when superseded
H26. Locked Summary
Platform is Molino's shared operating system layer. It sets the rules for auth, users, integrations, and editorial surfaces without taking over domain authority from vertical PRDs.