Using Playstack with Megamono

Megamono and Playstack meet at an explicit boundary: Megamono knows where applications and infrastructure projects belong; Playstack knows which packages and artifacts make a product capability complete.

Neither side needs to duplicate the other. Playstack does not import Megamono, inspect an Nx graph, read megamono.json, or assume apps/web and apps/api unless those paths are passed explicitly.

Start with repository shape

Use Megamono's guided initialization when adopting an existing repository or shaping a new monorepo:

megamono init

Create or register the application-owned database target before adding a persistence-bearing capability:

megamono add database primary --adapter=prisma

Database names are user-defined lowercase slugs. Megamono owns the database project and records the matching named Playstack target; it does not hide the selected ORM or run Playstack package migrations.

Add a Playstack capability

Preview the exact package and surface selection first:

playstack info auth --web --api
playstack add auth \
  --web=apps/web \
  --api=apps/api \
  --database=primary \
  --dry-run

For automation, add --json. The versioned plan includes the entire package closure plus active routes, environment variables, module imports, framework configuration, health checks, required tests, application decisions, and integrity-checked ejectable templates.

Apply the same plan non-interactively after review:

playstack add auth \
  --web=apps/web \
  --api=apps/api \
  --database=primary \
  --yes
playstack init

Megamono may invoke this operation for a concise capability selection such as auth, accounts, billing, or content. It must pass the app paths and database name it already knows. The same Playstack commands remain independently executable in a plain Node repository.

Fully qualified @playstack/* package names are Megamono's direct-install escape hatch when you want a package rather than a capability recipe. Use playstack info <capability> when you want prerequisites and compatible web, API, and persistence surfaces selected together.

Check storage, then materialize artifacts

For an existing Prisma schema, run the read-only compatibility report before writing:

playstack database compatibility --database=primary
playstack database sync --database=primary --dry-run
playstack database sync --database=primary

Then use the application's ORM tooling explicitly:

prisma migrate dev

The sequence is intentionally visible:

megamono add database
  -> playstack add
  -> playstack database compatibility
  -> playstack database sync
  -> application migration tooling

Playstack never connects to the database, generates a migration history, runs schema push, or applies a migration. If an existing schema is semantically equivalent but not physically compatible, implement the package persistence interface in the application rather than declaring the managed artifact satisfied. See Existing schema adoption.

Generate and compose the application boundary

Package installation is not application wiring. Integration-facing packages publish playstack.integration.json; Playstack filters each contract for the selected surface and adapters, then exposes it in add --dry-run --json. Megamono can place and materialize those templates because it knows the Nx project graph. The resulting files are ejectable and application-owned.

The current manifest-backed surfaces include rate limiting, cache and Next caching, queues, auth, accounts, billing, storage, webhooks, and AT Protocol. Requirements can describe module imports, provider tokens, environment variables, endpoint contracts, raw-body handling, framework configuration, health checks, required tests, and unresolved product decisions.

After Playstack and Megamono produce the reviewed plan:

1. construct the portable service with application-owned persistence, events, clocks, IDs, and provider clients;
2. register the optional NestJS or Next.js binding at the relevant app edge;
3. review or complete generated controllers, routes, providers, workers, health checks, and tests around the exported service; and
4. run the repository's ordinary tests, builds, migrations, and deployment checks.

This preserves a useful division of labor: Playstack authors the authoritative integration contract, Megamono places and materializes it, and the application keeps the generated code plus its product and runtime decisions.

Verify the handoff

playstack doctor --check

Megamono can schedule this read-only command in repository health checks. Playstack remains the single owner of managed-artifact, lint, Skills, and ejected-upstream drift logic; Megamono does not reimplement those checks.

playstack init --survey --json uses the same Nx-aware inventory shape for direct adoption: nested Next and Nest applications, Pages or App Router, workers, Redis and BullMQ usage, datasource-bearing Prisma contexts, and generated schema derivatives are reported without human output or writes.