[curquiza]

What

Give the management commands the project of the config file: an entry may carry cloudId, --project <name> supplies it to update projects and delete projects, and three explicit ways set it: create projects --add-to-config, config add and the new config update with --project-cloud-id, and the new config sync-with-cloud. ADR 0006 records the decisions. Stacked on #7, which it needs; merges into management-projects.

Two new commands and one new flag in one pull request, at the maintainer's request; rule 10 says one per pull request.

Contract

• config update and config sync-with-cloud do not derive from a route and are recorded in the renamed table "Commands that do not derive from a route" of commands.md, which the contract test now ties to the code: every command without routes is listed, every listed command exists. --add-to-config joins the CLI-owned flags of rule 6. The Management API's parent parameter {projectId} is --project-id (rule 4), because --project is the global flag
• Output goes through src/lib/output.ts, errors through src/lib/errors.ts
• The command never waits for a human
• The command never speaks HTTP itself: sync-with-cloud calls one function of the generated SDK with the client BaseCommand built, and declares static api = "management" with no route

Tests

• --help snapshots: two new ones; create, update and delete projects, config add and every command updated on purpose, for the new flags and the --project description
• JSON output: sync-with-cloud success with the three lists and the file written, a project the file does not know ignored, --team-id passed through; config update fields changed and kept, nothing to change, unknown project; create projects --add-to-config file written with the master key as apiKey, name taken before any network call, --project refused; update and delete projects with --project, without cloudId, with both, with neither; cloudId parsed and refused when invalid
• Integration test: not applicable, no new Meilisearch command
• pnpm lint, pnpm typecheck, pnpm test pass locally; the scenario ran against staging: a hand-written entry got its cloudId from sync-with-cloud, without key, and update projects --project used it. --add-to-config was not run against staging: it creates a project

Simplicity

• Nothing in the diff exists for a case the API cannot produce, a caller that does not exist, or a generality nobody asked for (rule 16); the simplify pass ran on the diff
• Shared code in src/lib/: config.ts gains cloudId in the entry, resolveCloudProjectId beside resolveProjectConnection, assertNoProject, parseProjectUrl and the CONFIG_FILE_WARNING of the config commands' help; api-naming.ts gains add-to-config, the --project-id rule and projectFlagForRoute, the one place that says which flag of a route --project can fill, used by BaseCommand.init and by the contract test; BaseCommand gains cloudProjectId(), a one-line delegate

Docs

• docs/contract/: config.md (the cloudId field, the "Cloud projects" section, the principle that the Management API is consulted only on request), commands.md (rule 4, rule 6, the --project row, the config-file flag group, the renamed table with its two rows); CLAUDE.md (the "Cloud only in prose" rule dropped, as decided), the skill, the README, the changeset
• ADR 0006 added. ADR 0005 gets the one allowed edit: its remove then add point is marked superseded by ADR 0006

Housekeeping

• oclif.manifest.json regenerated
• Changeset: two lines in .changeset/first-version.md
• No new dependency

Notes for the reviewer

• Decisions, as taken: cloudId in camelCase; --add-to-config is a boolean and the entry takes the project's name; --add-to-config writes the master key, the one moment the API returns it, and sync-with-cloud never writes a key; config add keeps --project-url required and --project-cloud-id optional; config update exists; --project-id on sub-resources; sync-with-cloud sets cloudId on existing entries only, adds none, and prints a report; no on-the-fly resolution.
• sync-with-cloud in one request: GET /api/v2/projects lists every project the token sees, checked on staging; --team-id narrows it, and then missing is not computed, since an entry of another team would be reported wrongly.
• --project on a management command that takes no project is a usage error, decided from static routes through projectFlagForRoute: a flag is never ignored in silence, and a future update teams --project is refused the same way. --project-url and --project-api-key on a management command are still ignored, as before this change.
• The contract test no longer sorts commands by api but by routes: a command with routes derives from them, a command without is in the table. --id of the projects commands and --project-id of their sub-resources are the only optional path flags, because --project can fill them.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Essentials
• Run ID: ade95c26-7116-44c8-b5de-c452e7bf615a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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