Existing independent application integration
Use Shell and the business-owned MF to try real user CRUD, isolation, publication and container persistence. External delivery is qualified separately.
Run the workspace reference
For source development, build Shell/Auth/content MF and ServerSDK, then Notes. Configure its dedicated identity, API and owned data file and register mappings. Standard Docker can add docker-compose.notes.yml for initial Core registration; do not expose raw port 8186.
pnpm --filter @mosaic-base/notes-example build
pnpm --filter @mosaic-base/notes-example test
mx-env run --no-global -- pnpm --filter @mosaic-base/notes-example startRegister public and management entries
Each directory row has one entryType. Register separate public Zone and admin embed entries targeting the same backend, with the reference scope, targets, permissions and grants. Site pages and APIs go through Gateway without per-business Core controllers.
/notes and /api/notes/notes expose only explicitly published content. /notes/mine and detail pages use /api/notes/mine for private user CRUD; administration is /embed/mosaic-notes-admin. Portal discovery has a 60-second TTL; Gateway still checks enablement per request.
Verify the current workflow
Publish records through delegated management. A signed-in user obtains notes.personal from Shell to create, read, update and delete private notes. The backend constrains realm/userId from the verified session and rejects anonymous/cross-user requests and supplied ownership. Acceptance covers login return, SSR renewal, restart persistence and disablement.
Create an external application and SDK package
A maintainer builds the kit from installed source dependencies and delivers tarballs, generators, browser/Node MF, licenses and integrity metadata. Generate into a new directory outside a pnpm workspace without mounting platform source or node_modules. Generation does not register services or create secrets and refuses existing targets.
The publication/private-record model owns its SQLite database and migrations; sdk/ is a separate package. Installing its tarball provides declarations; runtime resolves journal.records through Shell mappings without a static default instance. Replace the model and pages according to your own business spec.
node scripts/build-developer-kit.mjs --out /tmp/mosaic-kit
node /tmp/mosaic-kit/create-app.mjs --key my-journal --scope journal --out /tmp/my-journal
cd /tmp/my-journal
pnpm install
pnpm test
pnpm build
pnpm typecheck
pnpm pack:sdkA second independent Next consumer
Pass the actual SDK tarball to the consumer generator, then install, typecheck and build independently. SSR creates/disposes a Shell per request, and browser identity changes clear prior data. Missing manifests or exports must fail explicitly; fully reload browsers and restart Node hosts after mapping changes.
node /tmp/mosaic-kit/create-consumer.mjs --key my-reader --scope reader --sdk /tmp/my-journal/artifacts/mosaic-base-my-journal-sdk-0.1.0.tgz --business-scope journal --out /tmp/my-reader
cd /tmp/my-reader
pnpm install
pnpm typecheck
pnpm buildDeploy, register and verify actual behavior
Generate each project lockfile before building its Dockerfile. Configure the private API, dedicated derived identity and database path from its README; persist business /data and keep raw ports private. Register the business Zone, admin entry and consumer Zone separately, then select browser/Node Shell, HTTP, Auth and domain MF for each application. Browser assets use /journal/mf; Node assets stay on private /_mosaic/mf/node.
Verify delegated publication, two-user CRUD and authorization failures, then retained-volume restarts, replacement MF builds with explicit mapping updates, and disablement without affecting other applications. The mosaic-app-development Skill also generates workspace starting points. Full instructions and protected identity delivery are in docs/DEVELOPER_KIT.md.