@ekanos/cli 0.15.0 → 0.17.0

package/templates/harness/app/experience/layout.tsx.tmpl

@@ -0,0 +1,17 @@
+'use client';
+
+import { ConsoleLayout } from '@ekanos/harness/routes';
+
+import experience from __EXPERIENCE_ENTRY__;
+
+export default function ExperienceLayout(props: { children: React.ReactNode }) {
+  return (
+    <ConsoleLayout
+      experience={{
+        widgets: experience.widgets ?? [],
+        pages: experience.pages ?? [],
+      }}
+      {...props}
+    />
+  );
+}

package/templates/harness/app/experience/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperienceSummaryPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/experience/pages/[id]/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperiencePageHost as default } from '@ekanos/harness/routes';

package/templates/harness/app/experience/review-queue/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperienceReviewQueuePage as default } from '@ekanos/harness/routes';

package/templates/harness/app/experience/runs/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperienceRunsPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/experience/widgets/[id]/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperienceWidgetPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/experience/widgets/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperienceWidgetsPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/experience/workflows/[id]/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperienceWorkflowPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/experience/workflows/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperienceWorkflowsPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/connect/page.tsx.tmpl

@@ -0,0 +1 @@
+export { IntegrationConnectPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/events/page.tsx.tmpl

@@ -0,0 +1 @@
+export { IntegrationEventsPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/health/page.tsx.tmpl

@@ -0,0 +1 @@
+export { IntegrationHealthPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/operations/[kind]/[name]/page.tsx.tmpl

@@ -0,0 +1 @@
+export { IntegrationOperationPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/operations/page.tsx.tmpl

@@ -0,0 +1 @@
+export { IntegrationOperationsPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/page.tsx.tmpl

@@ -0,0 +1 @@
+export { IntegrationOverviewPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/preview/activation/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ActivationPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/preview/layout.tsx.tmpl

@@ -0,0 +1 @@
+export { PreviewLayout as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/preview/page.tsx.tmpl

@@ -0,0 +1 @@
+export { PreviewIndexPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/preview/tile/page.tsx.tmpl

@@ -0,0 +1 @@
+export { TilePage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/preview/triggers/page.tsx.tmpl

@@ -0,0 +1 @@
+export { TriggersPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/preview/widgets/[widgetId]/page.tsx.tmpl

@@ -0,0 +1 @@
+export { SingleWidgetPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/preview/widgets/page.tsx.tmpl

@@ -0,0 +1 @@
+export { WidgetsPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/[slug]/runs/page.tsx.tmpl

@@ -0,0 +1 @@
+export { IntegrationRunsPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/layout.tsx.tmpl

@@ -0,0 +1 @@
+export { ConsoleLayout as default } from '@ekanos/harness/routes';

package/templates/harness/app/integrations/page.tsx.tmpl

@@ -0,0 +1 @@
+export { IntegrationsListPage as default } from '@ekanos/harness/routes';

package/templates/harness/app/page.experience.tsx.tmpl

@@ -0,0 +1,5 @@
+import { redirect } from 'next/navigation';
+
+export default function HarnessIndex() {
+  redirect('/experience');
+}

package/templates/harness/repo/app/%5F%5Fekanos/api/[...path]/route.ts.tmpl

@@ -0,0 +1,11 @@
+import { createRepoApiHandlers } from '@ekanos/harness/api';
+
+// Next treats a leading underscore folder as private, so this directory is
+// literally named `%5F%5Fekanos` and serves /__ekanos/api/*. At a repo root it
+// answers the repo overview and forwards `packages/<kind>/<name>/…` to that
+// package's own harness API.
+const handlers = createRepoApiHandlers();
+
+export const GET = handlers.GET;
+export const POST = handlers.POST;
+export const PUT = handlers.PUT;

package/templates/harness/repo/app/(repo)/connections/page.tsx.tmpl

@@ -0,0 +1 @@
+export { RepoConnectionsPage as default } from '@ekanos/harness/routes';

package/templates/harness/repo/app/(repo)/layout.tsx.tmpl

@@ -0,0 +1 @@
+export { RepoLayout as default } from '@ekanos/harness/routes';

package/templates/harness/repo/app/(repo)/page.tsx.tmpl

@@ -0,0 +1 @@
+export { RepoHomePage as default } from '@ekanos/harness/routes';

package/templates/harness/repo/app/experiences/[name]/connect/page.tsx.tmpl

@@ -0,0 +1 @@
+export { ExperienceConnectPage as default } from '@ekanos/harness/routes';

package/templates/harness/repo/app/experiences/[name]/layout.tsx.tmpl

@@ -0,0 +1,9 @@
+'use client';
+
+import { RepoExperienceLayout } from '@ekanos/harness/routes';
+
+import { experienceEntries } from '../../repo-experiences';
+
+export default function ExperienceLayout(props: { children: React.ReactNode }) {
+  return <RepoExperienceLayout entries={experienceEntries} {...props} />;
+}

package/templates/harness/repo/app/experiences/page.tsx.tmpl

@@ -0,0 +1,5 @@
+import { redirect } from 'next/navigation';
+
+export default function ExperiencesIndex() {
+  redirect('/');
+}

package/templates/harness/repo/app/harness-shell.tsx.tmpl

@@ -0,0 +1,9 @@
+'use client';
+
+import { RootLayout } from '@ekanos/harness/app';
+
+import { harnessIntegrations } from '../../../harness.config';
+
+export default function HarnessShell(props: { children: React.ReactNode }) {
+  return <RootLayout integrations={harnessIntegrations} repo {...props} />;
+}

package/templates/harness/repo/app/integrations/[slug]/layout.tsx.tmpl

@@ -0,0 +1 @@
+export { RepoIntegrationLayout as default } from '@ekanos/harness/routes';

package/templates/harness/repo/app/integrations/page.tsx.tmpl

@@ -0,0 +1,5 @@
+import { redirect } from 'next/navigation';
+
+export default function IntegrationsIndex() {
+  redirect('/');
+}

package/templates/harness/repo/app/repo-experiences.ts.tmpl

@@ -0,0 +1,5 @@
+// Generated by `ekanos dev` at a repo root. One entry per experience package:
+// the widgets and pages are React components only the package's own module holds.
+__EXPERIENCE_IMPORTS__
+export const experienceEntries = {
+__EXPERIENCE_ENTRIES__} as const;

package/templates/harness/styles/globals.css.tmpl

@@ -6,7 +6,21 @@
  * `@ekanos/ui`, `@ekanos/sdk` — is already accounted for inside
  * `@ekanos/harness/styles.css`, so nothing about the harness needs a glob here.
  */
-@import '@ekanos/harness/styles.css';
+/*
+ * `source(none)` turns OFF Tailwind v4's automatic source detection. Left on,
+ * it scans everything under this directory — including `.next/`, whose
+ * Turbopack cache holds binary `.sst` blocks that contain fragments of our
+ * own sources split by control bytes. Those become garbage candidates such as
+ * `var(--icon-glyph<ctrl>,16px)`, and the CSS parser then fails with "Parsing
+ * CSS source code failed": every page a build-error overlay and every
+ * harness API route an HTML 500, recurring whenever the cache is rewritten.
+ * Every directory worth scanning is named by an exact `@source` below or
+ * inside the harness stylesheet.
+ */
+@import '@ekanos/harness/styles.css' source(none);
+
+/* The generated shell's own pages — explicit, so `.next/` is never matched. */
+@source '../app/**/*.tsx';
 
 /*
  * Your integration source, and the registry that lists it. A missing @source

package/templates/package.json.tmpl

@@ -12,12 +12,12 @@
     "prepare": "node scripts/setup-hooks.mjs"
   },
   "dependencies": {
-    "@ekanos/sdk": "^0.17.0",
-    "@ekanos/ui": "^0.17.0"
+    "@ekanos/sdk": "^0.19.0",
+    "@ekanos/ui": "^0.19.0"
   },
   "devDependencies": {
-    "@ekanos/cli": "^0.15.0",
-    "@ekanos/harness": "^0.17.0",
+    "@ekanos/cli": "^0.17.0",
+    "@ekanos/harness": "^0.19.0",
     "@hookform/resolvers": "^5.2.2",
     "@tailwindcss/postcss": "^4.3.3",
     "@tanstack/react-query": "^5.101.4",

package/templates/skills/build-agent/SKILL.md

@@ -39,9 +39,15 @@ installed — so check it, every time (§ 4, "Make it reachable").
 ## Hard rules
 
 - Never ask for, accept or write a secret (API key, client secret, webhook
-  signing secret). The user types it at their own terminal — `apps set`,
-  `apps connect`, `teams app set` and `teams connect` ask with hidden input
-  and refuse an agent run — or a team enters it in the Ekanos app.
+  signing secret), and never read one from a file or a variable yourself.
+  The user enters it, and it never passes through you: run the command with
+  `--browser` (`apps set`, `apps connect`, `teams app set`, `teams connect`,
+  `teams mcp token`, `teams llm-key set` take it) and the CLI opens a
+  one-time form in their browser on this computer — tell them to fill it in
+  there. If they would rather, they put it in an environment variable or a
+  file only they can read, and you pass `--secret-env <NAME>` or
+  `--secret-file <path>`. Or they type it at their own terminal, or a team
+  enters it in the Ekanos app. A secret is never a value on the command line.
 - Never `publish`, `rollback` or `archive` without the user's explicit yes to
   that version or agent, after they have seen it. `--yes` records that
   consent; it is never a way past a question.
@@ -105,7 +111,8 @@ list` to find the role holding `agents.review` for reviewers — see the
 `ekanos-platform` skill, "Onboarding a team"), and send the member who will
 sign in the link from `ekanos teams connect <team> <product>`. For the
 Source's app itself, `references/app-setup.md` has the console walk-through.
-Secrets are only ever entered at the user's terminal or in the app.
+Secrets are only ever entered by the user — in the `--browser` form, at
+their terminal, or in the app — never through you.
 
 ## 2. The interview
 
@@ -208,6 +215,32 @@ in parentheses are the recommendation when the user has no preference.
    team pilots
    it first, and do § 4 with them.
 
+## 3b. Only one team, or only the user: a team's own or a personal agent
+
+When the agent is for one team only, or for the user alone (§ 2's rollout
+question, `references/rollout.md`), skip the template: the same files make a
+team's own agent, or with `--personal` the user's own.
+
+1. On their go: `npx @ekanos/cli teams agents create <team> --from agents/<key> --source <slug> --json`
+   (add `--personal` for the user's own). The user becomes its creator, so
+   they must be an active member of that team; a `NOT_A_TEAM_MEMBER` refusal
+   names the command that adds them. Skill folders beside it are pushed as
+   that team's skills. Drop any field only a template has (exit 3 lists them).
+2. It starts as a draft:
+   `npx @ekanos/cli teams agents enable <team> <key> --source <slug> --json`.
+   Confirm what it may use only with the user's yes (`--confirm-access` on
+   `create` or `enable`, or `teams agents confirm <team> <key>`); a personal
+   agent's creator alone may.
+3. Start it from a schedule or a webhook:
+   `npx @ekanos/cli teams triggers add <team> <key> schedule --cron "0 8 * * 1-5" --timezone <zone> --prompt "…" --json`
+   or `… webhook --prompt "…"`. The webhook's token is saved to a file only
+   the user can read — never open or print it; tell them a personal agent's
+   token lets whoever holds it make the agent act as them.
+4. Later changes: edit the files and
+   `npx @ekanos/cli teams agents apply <team> agents/<key> --base-version <n> --json`
+   (`<n>` from `teams agents show`). Never `--overwrite` a conflict you have
+   not shown the user.
+
 ## 4. Make it reachable, and prove it end to end
 
 For each team that turns on an agent with a channel trigger, start with
@@ -225,12 +258,12 @@ screen). For the detail behind it:
    and `agent` (`credentialsSaved`, `connected` = installed, `neededBy`),
    and the `agent-events` webhook in `teamApps[].webhooks` must have an
    `endpoint`. Read the state back to the user in those words.
-3. Not installed: the user runs, **in their own terminal** (it asks for the
-   Linear app's secrets, which you never handle):
-   `npx @ekanos/cli teams connect <team> linear --connection agent --source <slug>`.
-   It asks for the app's client ID, secret and webhook signing secret if
-   missing, opens the install (a Linear workspace admin approves it) and
-   waits. No webhook URL yet: `npx @ekanos/cli teams webhook <team> linear
+3. Not installed: run
+   `npx @ekanos/cli teams connect <team> linear --connection agent --browser --source <slug>`
+   (or the user runs it without `--browser` in their own terminal). If the
+   app's client ID, secret or webhook signing secret is missing, it opens a
+   form in the user's browser for them to fill — you never handle those —
+   then opens the install (a Linear workspace admin approves it) and waits. No webhook URL yet: `npx @ekanos/cli teams webhook <team> linear
    agent-events --source <slug>` (shown once, and saved to a file only the
    user can read — the output names it; the user copies it into the Linear
    app. Never open or print that file yourself).

package/templates/skills/build-agent/references/agent-json.md

@@ -56,7 +56,10 @@ conflicting change unless `--overwrite`. Unknown fields are refused.
 ```
 
 The tool names above are illustrations. Take real ones from
-`ekanos catalog --json`.
+`ekanos catalog --json`; `ekanos catalog <product> --json` gives each tool's
+`inputSchema` (when a tool needs an id, another tool of the product returns
+it) and the product's `connection` (`connectedBy`, `runsUse`,
+`sourceConnection`).
 
 ## Fields
 

package/templates/skills/build-agent/references/app-setup.md

@@ -41,23 +41,30 @@ working from those rather than from Ekanos.
   the provider's docs rather than guessing.
 - The last console step is always "copy the client ID and the secret".
   **Never ask them to paste the secret into the chat.** For the Source's app,
-  have them run, **in their own terminal**:
+  run this yourself, and tell them a form is opening in their browser:
 
   ```bash
-  npx @ekanos/cli apps set <product> --source <slug>
+  npx @ekanos/cli apps set <product> --browser --source <slug>
   ```
 
-  It asks for the client ID, then the secret with hidden input; Enter keeps
-  a saved value, so either can be changed on its own. For a team's
-  app, they enter the fields in the team's setup panel in the Ekanos app.
+  The form asks for the client ID and the secret; a field left empty keeps
+  its saved value, so either can be changed on its own. What they type goes
+  from their browser to the CLI and on to Ekanos, never to you. (Or they run
+  `npx @ekanos/cli apps set <product> --source <slug>` in their own terminal,
+  which asks with hidden input.) For a team's app,
+  `npx @ekanos/cli teams app set <team> <product> --browser --source <slug>`
+  does the same, or they enter the fields in the team's setup panel in the
+  Ekanos app.
 - Then check: `apps show <product> --source <slug> --json` should say
   `configured: true`, and the catalog's step should be `done`. Tell them
   teams can now connect, and what the team-side steps are.
 
 ## When it goes wrong
 
-- `apps set` says it needs a terminal: it was run inside Claude or a script.
-  Ask them to run it in a terminal tab themselves.
+- `apps set` says there is no terminal to ask at: add `--browser`. If
+  `--browser` is refused (CI, SSH, no display), ask them to run it in a
+  terminal tab themselves. The form gives up after five minutes; run it
+  again for a fresh one.
 - `apps set` asks which host: they are signed in to more than one Ekanos;
   add `--host <url>` (the Source's site) or log out of the other.
 - Sign-in later fails with a redirect mismatch: the app is missing one of the

package/templates/skills/build-agent/references/rollout.md

@@ -65,11 +65,35 @@ plan is ready.
 
 ## A team's own agent
 
-Built by a team in the app (Agents → New). Only that team has it; the Source
-cannot update or roll it back, and nothing about it is visible to other teams.
+Built for one team, in the app (Agents → New) or from the terminal with the
+same `agent.json` a template uses:
+`ekanos teams agents create <team> --from agents/<key>` (then
+`ekanos teams agents enable <team> <key>` — it starts as a draft), and
+`ekanos teams agents apply <team> agents/<key> --base-version <n>` to change
+it from the file later. Only that team has it; the Source cannot update or
+roll it back, and nothing about it is visible to other teams. Whoever creates
+it is its creator — its tools run as them — so they must be a member of the
+team who manages its agents. A field only a template has (`connections`,
+`mcpServers`, `teamCustomization`, `triggers`, `links`, `teamOverrides`) is
+refused; add triggers with `ekanos teams triggers add`.
 
 Good for: one team's own process; experiments a team owns.
 
+## A personal agent
+
+One person's agent for themselves: `ekanos teams agents create <team> --from
+agents/<key> --personal`, by a member of that team. It acts for its creator,
+with their own connections, on every trigger, so it is theirs alone: nobody
+else changes it, runs it, decides its approvals or cancels its runs — not a
+team manager, not the Source admin (`PERSONAL_AGENT_CREATOR_ONLY`). Others see
+that it exists, not what its runs read or did. It starts from a schedule or a
+webhook (`ekanos teams triggers add <team> <key> schedule --cron "…" --prompt
+"…"`); whoever holds its webhook token can make it act as its creator, so the
+token goes to a file only they can read, never into a chat.
+
+Good for: "brief me on my day", "draft replies to my inbox" — one person's
+own work on their own accounts.
+
 ## Questions that decide it
 
 - How many teams do this work? The same way?

package/templates/skills/build-agent/references/set-up-an-integration.md

@@ -60,19 +60,32 @@ connect nothing for it.
   `teams show` (or `catalog`) and say what changed ("Ekanos sees the client ID
   and secret now"). If the check disagrees with what they said, look at the
   difference with them; don't move on.
-- **Secrets never pass through the chat.** Client secrets and signing
-  secrets go in at the user's own terminal (`ekanos apps set`,
-  `ekanos teams app set`, with hidden input) or in the team's page in the app.
-  If they paste one into the chat anyway, tell them to rotate it in the
-  provider's console and enter the new one at the terminal.
-- **Connect with `teams connect <team> <product>`, run by the user in their
-  own terminal.** It does whatever the integration needs: asks a form's fields
+- **Secrets never pass through the chat, or through you.** Client secrets
+  and signing secrets go in through a form in the user's browser that you
+  start with `--browser` (`ekanos apps set <product> --browser`,
+  `ekanos teams app set <team> <product> --browser`), at the user's own
+  terminal with hidden input, or in the team's page in the app. Never read
+  one from a file or an environment variable yourself; if the user has put
+  one there, pass its name with `--secret-env <NAME>` or its path with
+  `--secret-file <path>` and let the CLI read it. If they paste one into the
+  chat anyway, tell them to rotate it in the provider's console and enter
+  the new one through the form.
+- **Connect with `teams connect <team> <product>`** — add `--browser` when
+  you run it, so any field it needs opens as a form in the user's browser;
+  without it the user runs it in their own terminal. It does whatever the
+  integration needs: asks a form's fields
   (secrets hidden), runs the team-app prompts first when the team's own app is
   missing, or opens a one-time sign-in link and waits until the team is
-  connected. The provider's consent is still a person's click, by a member of
-  the team (owner/admin for a team-wide connection): the user when they are
-  one, else `--as <email>` prints a link to send that member. `--link-only`
-  prints just the team's page. Tell them who should sign in: the account the
+  connected. Non-secret fields of any type can be passed with
+  `--set <field>=<value>` (a list as `a,b`; secrets and JSON values only at a prompt), so
+  it also runs in a script; optional ones can be left out. The provider's
+  consent is still a person's click, by a member of the team (owner/admin for
+  a team-wide connection): the user when they are one, else `--as <email>`
+  prints a link to send that member. A Source admin who is not on the team
+  joins it first with `ekanos teams members add <team> --self` (no email). A
+  personal product (each person connects their own, such as ROAM) connects
+  the account of whoever runs `teams connect`. `--link-only` prints just the
+  team's page. Tell them who should sign in: the account the
   integration acts as. If the product is not enabled for the Source, a
   super-admin enables it (`sources products` shows what the Source has). A dedicated seat such as "Support agent" makes its replies easy
   to recognise.
@@ -88,11 +101,12 @@ pilot), the team-side steps can be done from the CLI:
 1. `npx @ekanos/cli teams show <team> <product> --source <slug>`: the
    callback URL to register and the integration's steps.
 2. They create the app in the provider's console, step by step as above.
-3. **In their own terminal:**
-   `npx @ekanos/cli teams app set <team> <product> --source <slug>`. It asks
-   for each field and hides the secret ones; Enter keeps a saved value. It
-   refuses to run inside Claude; that is deliberate. To change one value
-   later, they need not re-enter the rest:
+3. Run `npx @ekanos/cli teams app set <team> <product> --browser --source <slug>`
+   and tell them a form is opening in their browser: it has every field,
+   secrets as password inputs, and a field left empty keeps its saved value.
+   What they type never reaches you. (Without `--browser`, they run it in
+   their own terminal, which asks for each field and hides the secret ones.)
+   To change one value later, they need not re-enter the rest:
    `teams app set <team> <product> --field <name>` asks for just that field
    (names are in brackets in `teams show`), `--set <name>=<value>` sets a
    non-secret field (a subdomain, a client ID) without a prompt — you may run
@@ -122,10 +136,11 @@ mentions arrive. When the agent has any Linear trigger:
    redirect URIs, webhooks on with **Agent session events** and **Issues**.
 3. Its webhook URL: `teams webhook <team> linear agent-events` (once; paste
    it into the Linear app's webhook URL).
-4. **In their own terminal:**
-   `npx @ekanos/cli teams connect <team> linear --connection agent --source <slug>`
-   — asks for the client ID, secret and webhook signing secret if any is
-   missing, opens the install for a Linear workspace admin to approve, and
+4. `npx @ekanos/cli teams connect <team> linear --connection agent --browser --source <slug>`
+   — opens a form in the user's browser for the client ID, secret and
+   webhook signing secret if any is missing (without `--browser`, the user
+   runs it in their own terminal and it asks there), opens the install for a
+   Linear workspace admin to approve, and
    waits until it is installed. (`teams connect <team> linear` with no
    `--connection` offers this itself once the personal connection is made,
    when the team has agents with Linear triggers.)
@@ -146,11 +161,12 @@ the Source's connection.
 1. **Connect, once, as the Source.** For an integration where each customer
    brings its own app (Zendesk), first create that app in the shared account,
    exactly as in the worked example below (OAuth client, Confidential), but
-   once, for the Source. Then, **in their own terminal**:
-   `npx @ekanos/cli apps connect <product> --source <slug>`. It asks for the
+   once, for the Source. Then run
+   `npx @ekanos/cli apps connect <product> --browser --source <slug>` (or the
+   user runs it without `--browser` in their own terminal). It asks for the
    app's fields it doesn't have yet (Zendesk: subdomain, client ID, client
-   secret, webhook signing secret; secrets hidden, never as flags, and it
-   refuses to run inside Claude), prints the redirect URL to register and the
+   secret, webhook signing secret) in a form in the user's browser — never
+   through you, never as values on the command line — prints the redirect URL to register and the
    consent link, then waits up to ten minutes until it is connected. Whoever
    clicks the link is the account the integration acts as for every team, so
    suggest a dedicated seat ("Support agent"). `apps list` shows every
@@ -201,9 +217,9 @@ from `teams show zendesk`.
    Center › Apps and integrations › Webhooks › Create webhook › Trigger or
    automation: that URL, POST, JSON, no authentication. Open it and Reveal
    secret.
-3. **Credentials into Ekanos.** `ekanos teams app set <team> zendesk` in
-   their terminal: subdomain, client ID, client secret, webhook signing
-   secret. Any of them can be entered or changed later on its own
+3. **Credentials into Ekanos.** `ekanos teams app set <team> zendesk --browser`
+   (a form in their browser; or without `--browser`, in their terminal):
+   subdomain, client ID, client secret, webhook signing secret. Any of them can be entered or changed later on its own
    (`--field <name>`); `teams show` says which are saved.
 4. **Connect.** `npx @ekanos/cli teams connect <team> zendesk --source <slug>`
    opens the sign-in and waits; whoever approves it should be the Zendesk
@@ -244,5 +260,6 @@ from `teams show zendesk`.
   not installed for this team", or no webhook URL) and the command that
   fixes it. Installed and still silent: the Linear app's webhook must send
   **Agent session events** to the latest URL from `teams webhook`.
-- **A command says it needs a terminal:** it was run inside Claude. Ask them
-  to run it in a terminal tab themselves.
+- **A command says there is no terminal to ask at:** run it again with
+  `--browser`. If `--browser` is refused (CI, SSH, no display), ask them to
+  run it in a terminal tab themselves.

package/templates/skills/build-integration/references/widget-design.md

@@ -185,7 +185,7 @@ mock switch) so the harness can show all four; remove it before publish.
   `border-border`, `bg-primary`, `text-destructive`. NEVER raw palette
   classes (`bg-white`, `text-gray-500`, `bg-amber-400`) or hex/oklch
   literals — they break in dark mode and off-brand tenants.
-- **Accent discipline**: the primary (coral-orange) on ≤10% of the widget —
+- **Accent discipline**: the `primary` token (the Source's accent) on ≤10% of the widget —
   one CTA, one highlighted value, one active state. Semantic status colors
   (success/warning/destructive) are not accents.
 - **Depth via shadow, not borders** where a surface needs lift.