@zitadel/cli 0.1.0-alpha.8 → 1.0.0-alpha.20

package/dist/journey-guidance-BGrOX_gT.mjs

@@ -0,0 +1,40 @@
+import { j as publicCliCommand } from "./oclif-CanO3zdt.mjs";
+//#region src/lib/journey-guidance.ts
+/**
+* Journey-staged guidance copy shared by `setup` and `status`.
+*
+* The staging exists because of alpha tester feedback (Elina, alpha.15):
+* printing customize/publish steps before the user has logged in once reads
+* as noise, but dropping them entirely recreates the round-1 dead end where
+* nothing pointed to the next step. So the guidance tracks journey position —
+* verify first, customize/publish once login demonstrably works — and both
+* commands quote the same copy so the story doesn't fork.
+*/
+/**
+* The verify mission: prove the scaffolded auth round-trips before touching
+* config. `openUrl` prefixes the browser destination for callers that have
+* not already narrated it (setup's box has a separate "Start your project"
+* line; status has only the issuer).
+*/
+function verifyLoginAction(openUrl) {
+	return `Verify auth in the browser: ${openUrl ? `open ${openUrl}, ` : ""}register a user, log out, log in again with the same user, and confirm /profile shows Signed in.`;
+}
+/** The customize/publish pair, in Elina's tested wording. */
+function customizeAndPublishActions(cliVersion) {
+	return ["Customize what you ask for and how people sign in: edit .zitadel/schemas/ to change the information you collect, and .zitadel/flows/ to change the sign-up/sign-in experience. Each folder has a README with examples.", `See your changes before they go live: ${publicCliCommand("plan", cliVersion)} to preview, then ${publicCliCommand("apply", cliVersion)} to publish.`];
+}
+/**
+* How to change the login's look, depending on whether setup already ejected
+* a starter design. With a design, revision 1 is already live and the
+* template is repo-owned — point at the files and the plan/apply loop.
+* Without one, point at `branding eject` so the built-in template's
+* customization path stays discoverable after setup.
+*/
+function brandingGuidanceAction(design, cliVersion) {
+	if (design) return `Make the login yours: the ${design} design is live as branding revision 1. Edit .zitadel/branding/login.liquid (logo and hero image URLs live in branding.json), then ${publicCliCommand("plan", cliVersion)} and ${publicCliCommand("apply", cliVersion)} to publish the next revision.`;
+	return `Change how the login looks: ${publicCliCommand("branding eject", cliVersion)} scaffolds .zitadel/branding/ from a starter design (centered, split, split-right, hero, minimal) for you to edit.`;
+}
+//#endregion
+export { customizeAndPublishActions as n, verifyLoginAction as r, brandingGuidanceAction as t };
+
+//# sourceMappingURL=journey-guidance-BGrOX_gT.mjs.map

package/dist/journey-guidance-BGrOX_gT.mjs.map

@@ -0,0 +1 @@
+{"version":3,"file":"journey-guidance-BGrOX_gT.mjs","names":[],"sources":["../src/lib/journey-guidance.ts"],"sourcesContent":["import { publicCliCommand } from \"./public-cli\";\n\n/**\n * Journey-staged guidance copy shared by `setup` and `status`.\n *\n * The staging exists because of alpha tester feedback (Elina, alpha.15):\n * printing customize/publish steps before the user has logged in once reads\n * as noise, but dropping them entirely recreates the round-1 dead end where\n * nothing pointed to the next step. So the guidance tracks journey position —\n * verify first, customize/publish once login demonstrably works — and both\n * commands quote the same copy so the story doesn't fork.\n */\n\n/**\n * The verify mission: prove the scaffolded auth round-trips before touching\n * config. `openUrl` prefixes the browser destination for callers that have\n * not already narrated it (setup's box has a separate \"Start your project\"\n * line; status has only the issuer).\n */\nexport function verifyLoginAction(openUrl?: string): string {\n  const open = openUrl ? `open ${openUrl}, ` : \"\";\n  return (\n    `Verify auth in the browser: ${open}register a user, log out, ` +\n    \"log in again with the same user, and confirm /profile shows Signed in.\"\n  );\n}\n\n/** The customize/publish pair, in Elina's tested wording. */\nexport function customizeAndPublishActions(cliVersion: string): string[] {\n  return [\n    \"Customize what you ask for and how people sign in: edit .zitadel/schemas/ to change \" +\n      \"the information you collect, and .zitadel/flows/ to change the sign-up/sign-in \" +\n      \"experience. Each folder has a README with examples.\",\n    `See your changes before they go live: ${publicCliCommand(\"plan\", cliVersion)} to preview, ` +\n      `then ${publicCliCommand(\"apply\", cliVersion)} to publish.`,\n  ];\n}\n\n/**\n * How to change the login's look, depending on whether setup already ejected\n * a starter design. With a design, revision 1 is already live and the\n * template is repo-owned — point at the files and the plan/apply loop.\n * Without one, point at `branding eject` so the built-in template's\n * customization path stays discoverable after setup.\n */\nexport function brandingGuidanceAction(\n  design: string | undefined,\n  cliVersion: string,\n): string {\n  if (design) {\n    return (\n      `Make the login yours: the ${design} design is live as branding revision 1. ` +\n      \"Edit .zitadel/branding/login.liquid (logo and hero image URLs live in \" +\n      `branding.json), then ${publicCliCommand(\"plan\", cliVersion)} and ` +\n      `${publicCliCommand(\"apply\", cliVersion)} to publish the next revision.`\n    );\n  }\n  return (\n    \"Change how the login looks: \" +\n    `${publicCliCommand(\"branding eject\", cliVersion)} scaffolds .zitadel/branding/ ` +\n    \"from a starter design (centered, split, split-right, hero, minimal) for you to edit.\"\n  );\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;AAmBA,SAAgB,kBAAkB,SAA0B;AAE1D,QACE,+BAFW,UAAU,QAAQ,QAAQ,MAAM,GAEP;;;AAMxC,SAAgB,2BAA2B,YAA8B;AACvE,QAAO,CACL,0NAGA,yCAAyC,iBAAiB,QAAQ,WAAW,CAAC,oBACpE,iBAAiB,SAAS,WAAW,CAAC,cACjD;;;;;;;;;AAUH,SAAgB,uBACd,QACA,YACQ;AACR,KAAI,OACF,QACE,6BAA6B,OAAO,qIAEZ,iBAAiB,QAAQ,WAAW,CAAC,OAC1D,iBAAiB,SAAS,WAAW,CAAC;AAG7C,QACE,+BACG,iBAAiB,kBAAkB,WAAW,CAAC"}