H1Milestones Module (MLV)
Status: supporting execution tracking layer for milestones derived from Markdown or structured planning inputs.
H2Goal
Provide a lightweight /milestones control surface and MD ingestion path that helps execution without duplicating core domain logic.
Route:
/milestones/milestones?projectId=<id>
H21. System Identity
Milestones are an internal planning and tracking layer.
They are:
- derived from Markdown or structured planning inputs
- editable by users as guidance
- useful for tracking execution progress
- positioned before or alongside intent, not inside business truth
They are not:
- a canonical business entity
- Trip
- Offer
- Order
- LineItem
- commercial truth
Milestones support execution of:
- Trips
- Offers
- Orders
- LineItems
- Projection
They do not replace those systems.
H22. Core Execution Model
The real system flows through:
Concept -> Experience -> GroupSession -> Trip -> LineItems -> Offer -> Order -> Projection
Milestones sit outside that chain and help drive it.
The operating model is:
Truth -> Compute -> UI -> Intent -> Actions -> DB -> Projection
Milestones belong on the UI and intent side. They never become a source of truth.
H23. Current Status
H3CORE COMPLETE (MLV)
- MD H1-H3 heading scan
- idempotent project-scoped upsert
/milestonesUI list/edit/toggle/archive- project selector, project reassignment, bulk selection, bulk remove
- prompt starter blocks copied into milestone JSON as guidance payloads
H3PARTIAL
parentIdexists, but no tree UI- no next-action resolver
- no grouping or filtering beyond project scope
- no execution linkage to Trips, Offers, Orders, or LineItems
H3NOT BUILT
- no automation triggers
- no execution orchestration
- no business-entity mutation from milestones
🟥 Deploy note:
- A local-success / container-failure pattern usually means Prisma Client was not regenerated in Docker or the production DB migrations are out of sync.
- Verify
npx prisma generatein the Docker build, thennpx prisma migrate deployagainst production before redeploying. - This is a deployment sync issue, not a Milestones domain bug.
H24. MD Mechanism
MD scan is ingestion only.
It converts headings into milestones and keeps them synced idempotently.
It does not become the business system.
Current parsing stays narrow:
- heading extraction
- prompt starter block capture
- sync into milestone JSON
H25. Connection to Real System
Milestone labels must map to real execution units.
Examples:
Implement Trip Sync->Trip(G2)Generate LineItems->LineItems(G5-G6)Create Offer Flow->Offer(G8-G10)Checkout Flow->Order(G20)
These are the execution anchors. Milestones should point at real entities, not stand alone as generic tasks.
H26. Next Steps
H3PRIORITY 1 (HIGH)
- Link milestone -> entityId (
tripId,offerId,orderIdoptional relation) - Add a
next actionableresolver:- first non-completed
- lowest priority
- Surface milestone state in Trips / Offers UI
H3PRIORITY 2 (MEDIUM)
- parentId tree UI
- group by module (
Trips,Offers,Projection) - inline create/edit
H3PRIORITY 3 (LOW)
- automation hooks
- milestone templates
H27. Hard Rules
- Milestones never mutate business entities.
- Milestones never contain business truth.
- Milestones never replace actions.
- Milestones are always derived or user-edited guidance.
H28. Final Positioning
Milestones are a lightweight execution tracking layer that helps drive the completion of core Molino systems, but they are not part of the canonical domain model or commercial pipeline.
Prompt starter:
Use the current Milestones MLV as a support-layer spec. Preserve MD H1-H3 ingestion, project-scoped upserts, occurrence-based sourceKey, prompt starter syncing, and the /milestones control surface. Keep Milestones outside the canonical business domain, and only add next-action, tree, or entity-linking notes as support features rather than core commerce logic.