Integration planning

Inspect package-authored application requirements and ejectable wiring before a repository generator writes code.

Playstack packages declare the application work needed to compose a capability in playstack.integration.json. The package remains authoritative for its framework requirements and templates; the repository tool decides where reviewed application-owned files belong.

Inspect the selected closure

npx playstack add rate-limit \
  --api=apps/api \
  --adapter=redis \
  --dry-run \
  --json

The report declares writes: false and contains both the selected package closure and normalized integrationRequirements. Exact surface, adapter:<name>, and package conditions remove irrelevant requirements before the plan reaches Megamono.

Requirement	What it communicates
Templates	Integrity-checked, ejectable source plus the suggested application target.
Module imports and provider tokens	Framework registration and dependency-injection boundaries.
Routes	Endpoint method, path purpose, and handler contract.
Environment	Semantic key, suggested names, whether it is required, and whether it is secret.
Database artifacts	Schema requirements tied to the selected named database target.
Framework configuration	Raw-body, proxy, cache, or other host-framework changes.
Health checks	Bounded readiness checks expected for the selected provider.
Required tests	Contract, integration, and application-policy checks to retain.
Decisions	Product-specific questions that automation cannot safely answer.

Keep generation application-owned

Dry runs now expose integrationCoverage separately from requirements: dependencyValidation is declared-ranges-only and applicationVerification is not-run. Each inspected package reports manifest availability, selected templates and required tests; applicationPersistence lists application-owned adapter work. Missing integration declarations can be appropriate for utilities, but a successful installation plan is not completed wiring or a passing integration suite.

Playstack does not apply the JSON report or write routes and modules itself. Megamono consumes the plan with its Nx-aware project inventory, resolves destinations, reports conflicts, and materializes reviewed templates as application code. A repository without Megamono can copy or adapt the same package-owned templates manually.

Generated wiring is intentionally ejectable. Once materialized, the application owns authorization, credentials, route names, infrastructure lifecycle, deployment topology, and product policy. Managed database and other security-critical artifacts remain under Playstack's separate artifact synchronization contract.

Published contracts are verified

Every integration manifest is validated against a shared schema before a package is published, and each referenced template ships with its SHA-256 hash, so a dry-run plan is executable however the package was installed.

Manifests cover adoption-focused surfaces including rate limiting, cache, queues (now including Cloudflare Worker templates), auth, accounts, billing, storage, webhooks, AT Protocol and localization. Some declare requirements without templates. Use the selected plan's coverage rather than treating this list as a universal wiring guarantee.

Existing workspace discovery

playstack init --survey recognizes project.json, package-manifest Nx declarations, and npm/Yarn/pnpm workspace patterns and exclusions. Dual declarations merge by project root, with project.json taking precedence; duplicate names and conflicts are reported. Generated/symlinked directories are excluded, and root dependencies alone do not turn a source-less tooling project into a Next/Nest app.

This remains static discovery, not execution of Nx inference plugins. Review ambiguous projects and explicit surfaces, or use Megamono's richer project inventory. A survey does not authorize changing deployment targets or existing CI.

Separate planning from installation

Review the JSON plan before running the corresponding mutation:

npx playstack add rate-limit \
  --api=apps/api \
  --adapter=redis \
  --yes

The CLI re-resolves package and peer ranges during installation. An existing dependency counts as compatible only when its declared range fits the verified adapter range; presence by package name alone is insufficient.