feat(cli): add init, the compute config formalizer

[AmanVarshney01]

prisma-cli init writes a committed prisma.compute.ts for the app in the current directory. Deploy stays zero-config; init pins what deploy would infer so the setup is reviewable and stable for teammates and CI. It never overwrites an existing config, never scaffolds code (that's create-prisma's job), and needs no auth except for the optional link step.

$ prisma-cli init
  app        acme-web  package.json
  framework  Next.js   detected from package.json
  http port  3000      framework default

✔ Wrote prisma.compute.ts
? Link this directory to a Prisma Project now? (Y/n)

Next steps:
- prisma-cli app deploy

// generated prisma.compute.ts
import { defineComputeConfig } from "@prisma/compute-sdk/config";

export default defineComputeConfig({
  app: {
    name: "acme-web",
    framework: "nextjs",
    httpPort: 3000,
  },
});

More examples:

prisma-cli init --framework hono --entry src/index.ts   # explicit framework
prisma-cli init --project proj_123                      # write + link, no prompts
prisma-cli init --no-link --json                        # pure file generator (CI/agents)

Design notes

• Pins identity only (name, framework, httpPort, entry for entrypoint frameworks, region only when passed). No build block, so build-command inference stays live until a user opts into owning it. --framework custom appends a commented build stub since custom artifacts require it.
• INIT_CONFIG_EXISTS when any config exists up to the repo root (nested configs refused, steering monorepos to one root config); INIT_DETECTION_FAILED with the framework list in --json, an interactive picker otherwise.
• Link failures after the write downgrade to warnings; the config stands and init exits 0.
• app deploy success output now hints Config prisma-cli init when the deploy ran on inferred settings.

Testing: 10 new integration tests (572 total green), lint/typecheck/build clean, plus a live run shown above.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 7 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: f4fc2e20-1ea7-4bf2-84b6-4d5e39a68eed

📥 Commits

Reviewing files that changed from the base of the PR and between c131650 and 28399f1.

📒 Files selected for processing (13)

• docs/product/command-spec.md
• docs/product/error-conventions.md
• docs/product/resource-model.md
• packages/cli/src/cli.ts
• packages/cli/src/commands/init/index.ts
• packages/cli/src/controllers/app.ts
• packages/cli/src/controllers/init.ts
• packages/cli/src/lib/app/bun-project.ts
• packages/cli/src/presenters/app.ts
• packages/cli/src/presenters/init.ts
• packages/cli/src/shell/command-meta.ts
• packages/cli/src/types/init.ts
• packages/cli/tests/init.test.ts

Walkthrough

The PR adds a new top-level init CLI command, including command registration, result types, controller flow, presenter output, and tests. It updates the command spec to document init, adjusts deploy output rules to include an init hint when no config is present, and adds build list/show command specifications. The init flow writes prisma.compute.ts, supports framework and app-name resolution, optional install and linking steps, and reports structured success and warning states.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: adding the CLI init command for compute config generation.
Description check	✅ Passed	The description is directly related to the changeset and accurately describes the new init workflow and deploy hint.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/init-command

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch feat/init-command

---

_{Comment @coderabbitai help to get the list of available commands.}

[luanvdw]

🚀

This looks great and the happy path is well covered. There's two edge cases that I think we can tighten a bit,

1. --entry is silently ignored for frameworks that don’t support entrypoints. In resolveInitEntry, we return early when framework.usesEntrypoint is false, before checking whether the user explicitly passed --entry. So prisma-cli init --framework nextjs --entry src/index.ts exits successfully but drops the user’s flag. I think this should match deploy’s behavior and fail with a usage error instead.

2. Interactive framework adjustment can leave entry out of sync with the final framework. runInit resolves entry before maybeAdjustSettings, then writes that old entry with the adjusted framework. If the detected framework is Hono/Bun and the user switches to Next.js, we can write an invalid prisma.compute.ts with entry on a non-entrypoint framework. If the user switches the other way, we may miss the entrypoint we should have pinned.

and then a small docs cleanup, the new INIT_CONFIG_EXISTS / INIT_DETECTION_FAILED codes are in command-spec.md, but not in the central error-conventions.md MVP code list. Since agents/CI branch on these codes, I’d add them there as part of this PR.

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

docs/product/command-spec.md (2)

400-400: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Fix the preview/adjust order.

The controller applies the framework/http-port adjustment before rendering the preview, so the preview is showing the final values rather than being followed by an adjust step. Rephrase this bullet to match the actual flow.

Suggested wording

-- previews the resolved values with per-value source annotations (`detected`, `framework default`, `package.json`, `flag`) before writing; in interactive mode the preview is followed by an optional adjust step for framework and HTTP port, and `--yes` accepts the preview as shown
+- in interactive mode, an optional adjust step for framework and HTTP port runs before the preview; the preview then shows the final resolved values with per-value source annotations (`detected`, `framework default`, `package.json`, `flag`), and `--yes` accepts them as shown

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/product/command-spec.md` at line 400, The preview/adjust sequence
description in the command spec is out of order: the current flow renders the
preview before the interactive adjustment, not after it. Update the bullet in
the command-spec text to describe that the resolved values are previewed first
with source annotations, then in interactive mode the framework and HTTP port
can be adjusted, and `--yes` accepts the preview as shown; use the wording
consistent with the controller flow around the preview and adjust step.

---

395-410: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Clarify that --install is also a remote step.

The spec says linking is the only remote step, but resolveInitTypes() can run execa(...) to install @prisma/compute-sdk after the config write, which also depends on network/package-registry access. Please split "local config write" from the optional install/link steps so the contract matches the controller.

Suggested wording

-- writing the config requires no auth and no network; linking is the only remote step
+- writing the config requires no auth and no network; optional install/link steps may use the network after the file is written

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/product/command-spec.md` around lines 395 - 410, The init spec currently
says linking is the only remote step, but `resolveInitTypes()` can also trigger
an install via `execa(...)` for `@prisma/compute-sdk`, so update the wording to
separate the local config write from optional remote package-manager actions.
Clarify in the `init` section that writing the config is always
local/no-network, while type installation (whether via `--install` or the
interactive prompt) is an optional networked step handled after the write. Refer
to `resolveInitTypes()` and the `init` contract text so the controller behavior
and documentation stay aligned.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/cli/src/controllers/init.ts`:
- Around line 200-227: The `resolveInitTypes` step can throw after
`prisma.compute.ts` has already been written, which makes `runInit` report a
failure even though init partially succeeded. Mirror the protection used in
`resolveInitLink`: wrap the `readBunPackageJson` call in `resolveInitTypes` with
error handling, treat non-ENOENT read failures as a warning via the existing
`hooks.onWarning`, and return a safe skipped/unchanged `InitTypesState` instead
of letting the exception escape. Use the `resolveInitTypes`,
`readBunPackageJson`, and `hooks.onWarning` symbols to locate the fix, and add a
regression test for malformed `package.json`.

---

Outside diff comments:
In `@docs/product/command-spec.md`:
- Line 400: The preview/adjust sequence description in the command spec is out
of order: the current flow renders the preview before the interactive
adjustment, not after it. Update the bullet in the command-spec text to describe
that the resolved values are previewed first with source annotations, then in
interactive mode the framework and HTTP port can be adjusted, and `--yes`
accepts the preview as shown; use the wording consistent with the controller
flow around the preview and adjust step.
- Around line 395-410: The init spec currently says linking is the only remote
step, but `resolveInitTypes()` can also trigger an install via `execa(...)` for
`@prisma/compute-sdk`, so update the wording to separate the local config write
from optional remote package-manager actions. Clarify in the `init` section that
writing the config is always local/no-network, while type installation (whether
via `--install` or the interactive prompt) is an optional networked step handled
after the write. Refer to `resolveInitTypes()` and the `init` contract text so
the controller behavior and documentation stay aligned.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: f3db233d-ece3-419d-90a0-3ba58f3a474e

📥 Commits

Reviewing files that changed from the base of the PR and between 7008a46 and c131650.

📒 Files selected for processing (6)

• docs/product/command-spec.md
• packages/cli/src/commands/init/index.ts
• packages/cli/src/controllers/init.ts
• packages/cli/src/presenters/init.ts
• packages/cli/src/types/init.ts
• packages/cli/tests/init.test.ts

[AmanVarshney01]

@luanvdw Both edge cases fixed in 99f5386:

1. --entry on a non-entrypoint framework now fails with a usage error explaining that the framework derives its entrypoint from build output, instead of silently dropping the flag. Test added, and the config is not written.
2. Entry resolution moved to after the interactive adjust step and validates/derives against the final framework, so a framework switch can no longer write a stale entry or miss one that should be pinned.

INIT_CONFIG_EXISTS and INIT_DETECTION_FAILED are registered in error-conventions.md as well. I also cherry-picked the generic success-warning renderer from #107 onto this branch, so init's degraded steps (failed link, failed types install) now render via the shared runner path instead of bespoke presenter lines.

[luanvdw]

🙏 🚀