feat(services): services add --json — the created service, machine-readable

[CarmenDou]

What

insta services add gains --json: it prints the created service object instead of the human line.

add was the only services command that produces an object without being able to print it — list, rename, set-access, scale and upgrade all take --json. An agent that had just created a service still had to re-query services list --json to learn the id and domain it was given.

remove deliberately stays without --json: it destroys rather than produces, and matches branch delete / project delete, which take none either.

How

• ServicesAddOpts gains json?; servicesAdd returns printJson(res.body.service) right after the approval gate — the same shape and position as rename / set-access / scale / upgrade.
• serviceArgsDeps(json?) forces tty: false when --json is set, so the prompts this branch stacks on never fire for a caller that asked for parseable stdout. Without it, a question would corrupt the output and hang an agent that happens to own a TTY.

Verify

• npm run typecheck && npm test — 27 files, 247 tests, all green. New case: --json opts out of the prompts even on a terminal.
• insta services add --help lists --json.
• insta services add --json with no positionals prints the kind list as an error and creates nothing.

---

Stacked on #91 — base is feat/services-add-guided, so review that one first. Doc mirror: InsForge/insta-skills branch docs/services-add-json (required by AGENTS.md non-negotiable 4).

---

Summary by cubic

Adds --json to insta services add to print the created service object. Previously add printed a human line only, so automation had to call services list --json to get the id and domain.

• Returns printJson(res.body.service) when --json is set; ServicesAddOpts gains json.
• Disables prompts when --json is set by forcing non-TTY in serviceArgsDeps(json), ensuring parseable stdout even on a terminal; errors still surface when args are missing.
• CLI help documents --json; tests cover prompt opt-out on TTY.
• services remove remains without --json by design.

^{Written for commit 6535cca. Summary will update on new commits.}

[jwfing]

Summary

Adds --json to insta services add so the created service object can be printed machine-readable, closing the last services producer that couldn't emit JSON — clean, tightly scoped, and consistent with its siblings.

Requirements context

No matching spec/plan found — this repo has no /docs/superpowers/ and docs/specs/ is empty. Assessed against the PR description and the surrounding services command conventions in src/commands/services.ts.

Findings

Critical

(none)

Suggestion

• Functionality — JSON purity under the approval gate (src/commands/services.ts:95-96). handleApproval(res) runs before the opts.json check, so a 202 approval_required response prints the human line approval required for … — run: insta approvals approve … on stdout even under --json, and returns before any JSON is emitted. A caller parsing stdout gets non-JSON (or empty) output. This is pre-existing, shared behavior — rename / set-access / scale / upgrade all order the two checks identically, and a 202 means nothing was created — so it is not introduced by this PR and not blocking. Worth a follow-up across all services JSON paths (e.g. emit { "status": "approval_required", "approvalId": … } when --json is set) so agents never have to distinguish JSON from a prose line.

Information

• Software engineering — test scope (test/resolve-service.test.ts:64-73). The new test correctly locks the behavior that actually needed a regression guard: serviceArgsDeps(true).tty === false even when both streams are TTYs (the hang/output-corruption risk the PR body calls out), and it restores the mutated isTTY flags in a finally. The servicesAdd --json → printJson(res.body.service) branch itself is untested, but that mirrors the existing (also untested) JSON branches of rename/scale/etc. and the line is a one-liner over the same res.body.service the human branch already dereferences — acceptable, no new test debt relative to convention.
• Software engineering — help text (src/index.ts:130). .option('--json') carries no description, matching every other --json in the services group (list, rename, set-access, scale, upgrade), so this is consistent, not a gap.
• Security / Performance — no relevant changes. --json only serializes the same response object list --json already exposes; no new user input reaches SQL/shell/HTTP, no secrets/PII newly logged, no auth path touched, no new queries or loops.

Note: this PR is stacked on #91 (base feat/services-add-guided); the diff was reviewed against that base, and the serviceArgsDeps(json?) seam it threads through comes from #91.

Verdict

approved (informational — the human still approves via the approve flow). No Critical findings; the two non-blocking items are follow-ups and a scope note. Posted as a COMMENT.

[jwfing]

LGTM - approved.

[cubic-dev-ai]

No issues found across 4 files

_{Re-trigger cubic}