@starlein/paperclip-plugin-company-wizard 0.3.24 → 0.4.2

package/dist/ui/index.js

@@ -549,7 +549,8 @@ var __iconNode41 = [
 var Zap = createLucideIcon("zap", __iconNode41);
 
 // src/ui/components/WizardShell.tsx
-import { useEffect as useEffect6 } from "react";
+import { useEffect as useEffect6, useState as useState9 } from "react";
+import { usePluginAction as usePluginAction6 } from "@paperclipai/plugin-sdk/ui";
 
 // src/ui/context/WizardContext.tsx
 import { createContext, useCallback, useContext, useState } from "react";
@@ -4319,7 +4320,7 @@ function StepGoal() {
   return /* @__PURE__ */ jsxs3("div", { className: "space-y-6", children: [
     /* @__PURE__ */ jsxs3("div", { className: "space-y-2", children: [
       /* @__PURE__ */ jsx7("h2", { className: "text-xl font-semibold tracking-tight", children: "Company goal" }),
-      /* @__PURE__ */ jsx7("p", { className: "text-sm text-muted-foreground", children: "What's the top-level objective? This drives all agent work." })
+      /* @__PURE__ */ jsx7("p", { className: "text-sm text-muted-foreground", children: "What's the top-level outcome? Lead with the primary deliverable or operating result; put secondary constraints such as compliance, security, or accessibility in the description as quality bars." })
     ] }),
     /* @__PURE__ */ jsxs3("div", { className: "space-y-4", children: [
       /* @__PURE__ */ jsxs3("div", { className: "space-y-2", children: [
@@ -4327,7 +4328,7 @@ function StepGoal() {
         /* @__PURE__ */ jsx7(
           Input,
           {
-            placeholder: "e.g. Ship MVP by end of month",
+            placeholder: "e.g. Build and launch the core product",
             value: state.goals[0]?.title || "",
             onChange: (e) => dispatch({
               type: "SET_GOALS",
@@ -4347,7 +4348,7 @@ function StepGoal() {
           "textarea",
           {
             className: "flex min-h-[80px] w-full rounded-md border border-input bg-transparent px-3 py-2 text-sm shadow-sm placeholder:text-muted-foreground focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring resize-none",
-            placeholder: "More context about what success looks like...",
+            placeholder: "Primary outcome and scope first. Then add constraints / quality bars such as compliance, security, accessibility, or performance.",
             value: state.goals[0]?.description || "",
             onChange: (e) => dispatch({
               type: "SET_GOALS",
@@ -4389,15 +4390,13 @@ function getRepositoryUrl(project) {
   return project?.workspace?.repoUrl || project?.repoUrl || "";
 }
 function getRepositoryRef(project, mode) {
-  return project?.workspace?.defaultRef || project?.workspace?.repoRef || project?.defaultRef || project?.repoRef || (mode === "external" ? "origin/main" : "main");
+  const configured = project?.workspace?.defaultRef || project?.workspace?.repoRef || project?.defaultRef || project?.repoRef || "";
+  return configured || (mode === "new" ? "main" : "");
 }
 function normalizeExternalRepoRef(value) {
   const trimmed = value.trim();
-  if (!trimmed) return "origin/main";
-  if (trimmed.startsWith("origin/") || trimmed.startsWith("refs/")) {
-    return trimmed;
-  }
-  return `origin/${trimmed}`;
+  if (!trimmed) return "";
+  return /^[A-Za-z0-9._:/-]+$/.test(trimmed) ? trimmed : "";
 }
 function normalizeNewRepoBranch(value) {
   const raw = value.trim().replace(/^origin\//, "") || "main";
@@ -4410,19 +4409,14 @@ function repositoryProjectFields(mode, repoUrl, repoRef) {
     return {
       workspaceSourceType: "git_repo",
       repoUrl: url,
-      repoRef: ref,
-      defaultRef: ref,
+      ...ref ? { repoRef: ref, defaultRef: ref } : { repoRef: void 0, defaultRef: void 0 },
       workspace: {
         sourceType: "git_repo",
         repoUrl: url,
-        repoRef: ref,
-        defaultRef: ref,
+        ...ref ? { repoRef: ref, defaultRef: ref } : {},
         isPrimary: true
       },
-      executionWorkspacePolicy: {
-        defaultMode: "isolated_workspace",
-        workspaceStrategy: { type: "git_worktree", baseRef: ref }
-      }
+      executionWorkspacePolicy: void 0
     };
   }
   const branch = normalizeNewRepoBranch(repoRef);
@@ -4515,9 +4509,6 @@ function StepRepository() {
   const externalRepoMissing = mode === "external" && !repoUrl.trim();
   const chooseMode = (nextMode) => {
     setMode(nextMode);
-    if (nextMode === "external" && (!repoRef.trim() || repoRef.trim() === "main")) {
-      setRepoRef("origin/main");
-    }
     if (nextMode === "new" && (!repoRef.trim() || repoRef.trim().startsWith("origin/"))) {
       setRepoRef("main");
     }
@@ -4596,7 +4587,7 @@ function StepRepository() {
         /* @__PURE__ */ jsx8(
           Input,
           {
-            placeholder: "origin/main",
+            placeholder: "Leave blank to use Paperclip/project default, or enter an explicit ref",
             value: repoRef,
             onChange: (e) => setRepoRef(e.target.value),
             onKeyDown: (e) => e.key === "Enter" && handleNext()
@@ -5186,9 +5177,6 @@ function RepositoryEdit({
   const [repoRef, setRepoRef] = useState6(getRepositoryRef(project, initialMode));
   const chooseMode = (next) => {
     setMode(next);
-    if (next === "external" && (!repoRef.trim() || repoRef.trim() === "main")) {
-      setRepoRef("origin/main");
-    }
     if (next === "new" && (!repoRef.trim() || repoRef.trim().startsWith("origin/"))) {
       setRepoRef("main");
     }
@@ -5240,7 +5228,7 @@ function RepositoryEdit({
           className: inputClass,
           value: repoRef,
           onChange: (e) => setRepoRef(e.target.value),
-          placeholder: "Default ref (e.g. origin/main)",
+          placeholder: "Leave blank to use Paperclip/project default, or enter an explicit ref",
           onKeyDown: (e) => {
             if (e.key === "Enter") save();
             if (e.key === "Escape") onCancel();
@@ -6071,24 +6059,24 @@ import { useState as useState8, useRef as useRef4, useEffect as useEffect4 } fro
 import { usePluginAction as usePluginAction4 } from "@paperclipai/plugin-sdk/ui";
 
 // raw:/paperclip/paperclip-plugin-company-wizard/src/ui/prompts/interview-system.md
-var interview_system_default = 'You are the Company Wizard \u2014 an expert at assembling AI agent teams. You\'re enthusiastic but concise. Company Wizard bootstraps AI-agent company workspaces from composable templates.\n\nYou are conducting a guided interview to understand what company to set up.\n\n{{CATALOG}}\n\n## How Roles Work\n\n- **Base roles** (marked "always included") are auto-added. You do NOT list them in the JSON.\n- **All other roles** (listed under "Available Extra Roles") are OPTIONAL and must be EXPLICITLY listed in your JSON `roles` array if you want them.\n- **Critically: `engineer` is NOT a base role.** Most software projects need an engineer. If the project involves writing code, building software, or maintaining a repository, you MUST include `engineer` in your `roles` array. The preset does NOT auto-add roles \u2014 you must list every non-base role the company needs.\n- When in doubt, include the engineer. A company that builds software without an engineer agent will have no one to write code.\n\n## Interview Rules\n\n- Ask exactly ONE question per turn. Keep it short and energetic (1-2 sentences). Use a conversational tone.\n- Do NOT output JSON during questions \u2014 just ask the question as plain text.\n- Tailor each question based on previous answers. Show you understood what they said.\n- After 3 questions, summarize what you understood in a brief, enthusiastic paragraph. End with: "Ready to generate your configuration?"\n- When the user confirms, output a human-readable recommendation with reasoning, then the JSON config.\n\n## What to Ask About\n\nAcross your 3 questions, try to cover as many of these as the user\'s initial description left unclear:\n\n1. **What they\'re building** \u2014 Product type, target users, domain (fintech, SaaS, game, etc.)\n2. **Current stage** \u2014 Greenfield, existing codebase, research phase, relaunch?\n3. **Quality vs speed** \u2014 Ship fast, iterate? Or production-grade, high quality from the start?\n4. **Team needs** \u2014 Do they need code review, security, design, marketing, docs, DevOps?\n5. **Special requirements** \u2014 Compliance, accessibility, specific tech stack, CI/CD, game engine?\n6. **Repository** \u2014 Should Paperclip create a new Git repository/workspace, or should the agents use an existing external repo such as GitHub/GitLab? If external, ask for URL and branch/ref; never ask for tokens.\n\nDon\'t ask about things already clear from the initial description. Skip to what\'s missing.\n\n## Information Preservation\n\nThe user\'s interview answers are the primary source of context for the company. When generating the configuration:\n\n- **`companyDescription`**: Write a comprehensive 2-4 paragraph description that captures EVERYTHING learned during the interview \u2014 what the company does, what it\'s building, who it\'s for, key technical decisions, constraints, priorities, and any special context. This is the company\'s permanent record. Be thorough. Do NOT summarize into a single vague sentence.\n- **`goals`**: Array of goals. The first goal is the main user-specific company goal \u2014 its description is the most important field. Write a THOROUGH, DETAILED description that includes EVERYTHING the user shared: full requirements, technical specs, acceptance criteria, constraints, edge cases, API contracts, user stories, design decisions, performance targets. If the user dropped a full spec, reproduce it in full. This is the primary brief all agents work from. Multiple paragraphs expected. Additional goals can be sub-goals (use `parentGoal` to reference the parent\'s title). Most setups need 1 main goal + 0-2 sub-goals. Preset/module template goals are added by the wizard after your JSON, so do NOT replace the user\'s objective with generic preset goals like "Build a REST API" or "Set up CI/CD" unless the user explicitly asked only for that.\n- **`projects`**: Array of projects. Each has a `name`, `description`, `goals` array (goal titles it\'s linked to), and repository workspace metadata. If the user chose an external repo, use `workspace.sourceType: "git_repo"` with `repoUrl`, `repoRef`/`defaultRef`, and isolated git worktrees. If no external repo was provided, use a fresh local Git repository with `workspace.sourceType: "local_path"`, `workspace.defaultRef: "main"`, `workspace.setupCommand: "git init -b main"`, and `workspace.isPrimary: true`.\n- **`issues`**: Array of 6-12 CONCRETE, domain-specific initial work items taken straight from what you learned in the interview \u2014 the real features, components, and integrations the user actually described, each with a `title`, a `description` with acceptance criteria, a `priority` (`critical`/`high`/`medium`/`low`), and `assignTo` set to a role on the team. These seed the backlog so the project starts in its actual domain. Do NOT put generic scaffolding here (vision docs, linters, CI, branch protection) \u2014 the wizard adds those automatically.\n\n## RECOMMENDATION Format (when generating config)\n\n- One paragraph explaining your reasoning: why this preset, why these modules, why these roles.\n- A bullet list of the key choices.\n\nThen output the JSON (no markdown fences):\n{{CONFIG_FORMAT}}\n\n## Rules\n\n- `modules` should list ALL modules to activate (including preset ones).\n- `roles` should list ALL non-base roles the company needs. This includes roles that come with the preset. The system does not auto-add preset roles \u2014 you must list them explicitly.\n- If the project involves building software, `engineer` MUST be in `roles`.\n- The primary project MUST state whether it uses a fresh local Git repository or an external Git repository. Do not put credentials or tokens in repository fields.\n- Be pragmatic \u2014 don\'t over-engineer. Match the config to actual needs.\n';
+var interview_system_default = 'You are the Company Wizard \u2014 an expert at assembling AI agent teams. You\'re enthusiastic but concise. Company Wizard bootstraps AI-agent company workspaces from composable templates.\n\nYou are conducting a guided interview to understand what company to set up.\n\n{{CATALOG}}\n\n## How Roles Work\n\n- **Base roles** (marked "always included") are auto-added. You do NOT list them in the JSON.\n- **All other roles** (listed under "Available Extra Roles") are OPTIONAL and must be EXPLICITLY listed in your JSON `roles` array if you want them.\n- **Critically: `engineer` is NOT a base role.** Most software projects need an engineer. If the project involves writing code, building software, or maintaining a repository, you MUST include `engineer` in your `roles` array. The preset does NOT auto-add roles \u2014 you must list every non-base role the company needs.\n- When in doubt, include the engineer. A company that builds software without an engineer agent will have no one to write code.\n\n## Interview Rules\n\n- Ask exactly ONE question per turn. Keep it short and energetic (1-2 sentences). Use a conversational tone.\n- Do NOT output JSON during questions \u2014 just ask the question as plain text.\n- Tailor each question based on previous answers. Show you understood what they said.\n- After 3 questions, summarize what you understood in a brief, enthusiastic paragraph. End with: "Ready to generate your configuration?"\n- When the user confirms, output a human-readable recommendation with reasoning, then the JSON config.\n\n## What to Ask About\n\nAcross your 3 questions, try to cover as many of these as the user\'s initial description left unclear:\n\n1. **What they\'re building** \u2014 Product type, target users, domain (fintech, SaaS, game, etc.)\n2. **Current stage** \u2014 Greenfield, existing codebase, research phase, relaunch?\n3. **Quality vs speed** \u2014 Ship fast, iterate? Or production-grade, high quality from the start?\n4. **Team needs** \u2014 Do they need code review, security, design, marketing, docs, DevOps?\n5. **Special requirements** \u2014 Compliance, accessibility, specific tech stack, CI/CD, game engine?\n6. **Repository** \u2014 Should Paperclip create a new Git repository/workspace, or should the agents use an existing external repo such as GitHub/GitLab? If external, ask for URL and branch/ref; never ask for tokens.\n\nDon\'t ask about things already clear from the initial description. Skip to what\'s missing.\n\n## Information Preservation\n\nThe user\'s interview answers are the primary source of context for the company. When generating the configuration:\n\n- **`companyDescription`**: Write a comprehensive 2-4 paragraph description that captures EVERYTHING learned during the interview \u2014 what the company does, what it\'s building, who it\'s for, key technical decisions, constraints, priorities, and any special context. This is the company\'s permanent record. Be thorough. Do NOT summarize into a single vague sentence.\n- **`goals`**: Array of goals. The first goal is the main user-specific company goal \u2014 its description is the most important field. Keep it outcome-first and product-first: the title and opening sentence must state the primary deliverable or operating outcome, not a supporting constraint. Write a THOROUGH, DETAILED description that includes EVERYTHING the user shared: full requirements, technical specs, acceptance criteria, constraints, edge cases, API contracts, user stories, design decisions, performance targets. Put compliance/security/accessibility/performance constraints in a clearly labelled "Constraints / quality bars" section unless the user explicitly says that constraint is the primary project. If the user\'s wording mixes a main outcome with secondary facts, determine which thing the agents should build/operate first and write that as the top-level goal; put side facts into acceptance criteria, risks, or sub-goals only when they are independent workstreams. Preset/module template goals are added by the wizard after your JSON, so do NOT replace the user\'s objective with generic preset goals like "Build a REST API" or "Set up CI/CD" unless the user explicitly asked only for that.\n- **`projects`**: Array of projects. Each has a `name`, `description`, `goals` array (goal titles it\'s linked to), and repository workspace metadata. If the user chose an external repo, use `workspace.sourceType: "git_repo"` with `repoUrl`, plus `repoRef`/`defaultRef` exactly when the user or repository context provides one; do not force a branch name or remote prefix. If no external repo was provided, use a fresh local Git repository with `workspace.sourceType: "local_path"`, `workspace.defaultRef: "main"` unless the user requested another initial branch, `workspace.setupCommand: "git init -b <defaultRef>"`, and `workspace.isPrimary: true`. Do not include `executionWorkspacePolicy`; the assembler applies isolated worktrees only when Paperclip\'s experimental isolated-workspaces setting is enabled and a usable project base ref exists.\n- **`issues`**: Array of 6-12 CONCRETE, domain-specific initial work items taken straight from what you learned in the interview \u2014 the real features, components, and integrations the user actually described, each with a `title`, a `description` with acceptance criteria, a `priority` (`critical`/`high`/`medium`/`low`), and `assignTo` set to a role on the team. These seed the backlog so the project starts in its actual domain. Issue titles should lead with the core product capability; secondary constraints belong in acceptance criteria or risk notes unless the issue is specifically about that constraint. Do NOT put generic scaffolding here (vision docs, linters, CI, branch protection) \u2014 the wizard adds those automatically.\n\n## RECOMMENDATION Format (when generating config)\n\n- One paragraph explaining your reasoning: why this preset, why these modules, why these roles.\n- A bullet list of the key choices.\n\nThen output the JSON (no markdown fences):\n{{CONFIG_FORMAT}}\n\n## Rules\n\n- `modules` should list ALL modules to activate (including preset ones).\n- `roles` should list ALL non-base roles the company needs. This includes roles that come with the preset. The system does not auto-add preset roles \u2014 you must list them explicitly.\n- If the project involves building software, `engineer` MUST be in `roles`.\n- The primary project MUST state whether it uses a fresh local Git repository or an external Git repository. Do not put credentials or tokens in repository fields.\n- Be pragmatic \u2014 don\'t over-engineer. Match the config to actual needs.\n';
 
 // raw:/paperclip/paperclip-plugin-company-wizard/src/ui/prompts/single-shot-system.md
-var single_shot_system_default = 'You are the Company Wizard. Company Wizard bootstraps AI-agent company workspaces from composable templates.\n\nGiven a natural language description of what the user wants to build, you select the best configuration.\n\n{{CATALOG}}\n\n## How Roles Work\n\n- **Base roles** (marked "always included") are auto-added. You do NOT list them in the JSON.\n- **All other roles** (listed under "Available Extra Roles") are OPTIONAL and must be EXPLICITLY listed in your JSON `roles` array if you want them.\n- **Critically: `engineer` is NOT a base role.** Most software projects need an engineer. If the project involves writing code, building software, or maintaining a repository, you MUST include `engineer` in your `roles` array. The preset does NOT auto-add roles \u2014 you must list every non-base role the company needs.\n- When in doubt, include the engineer. A company that builds software without an engineer agent will have no one to write code.\n\n## Instructions\n\n1. Analyze the user\'s description to understand: what they\'re building, their team size preference, quality vs speed priority, and any specific needs.\n2. Select the best preset as a starting point.\n3. List ALL modules to activate (including preset ones). Add extra modules beyond the preset if the description warrants them.\n4. List ALL non-base roles the company needs. This includes roles from the preset. If the project involves software, include `engineer`.\n5. Suggest a company name (PascalCase-friendly, short, memorable) if not obvious from the description.\n6. Write a thorough company description (2-4 paragraphs) capturing everything the user described \u2014 product, audience, tech stack, constraints, priorities, stage, and special context. This is the company\'s permanent record.\n7. Define goals as an array. The first goal is the main user-specific company goal \u2014 its description is the most important field. Include EVERYTHING the user described: full requirements, technical specs, acceptance criteria, constraints, edge cases, API contracts, user stories, performance targets. If the user provided a detailed spec, reproduce it in full. This is the primary brief all agents work from. Do NOT summarize \u2014 preserve every detail. Add sub-goals with `parentGoal` if the description warrants separate workstreams. Preset/module template goals are added by the wizard after your JSON, so do NOT replace the user\'s objective with generic preset goals like "Build a REST API" or "Set up CI/CD" unless the user explicitly asked only for that.\n8. Define projects as an array. Most setups need one project linked to all goals. Name and describe the project concretely.\n9. Always decide the repository setup for the primary project:\n   - If the user gives an existing GitHub/GitLab/remote Git repo, set `workspace.sourceType: "git_repo"`, include `repoUrl`, set `repoRef`/`defaultRef` when known (default to `origin/main`), and use `executionWorkspacePolicy.defaultMode: "isolated_workspace"` with a `git_worktree` strategy.\n   - If no external repository is given, assume Paperclip should create a fresh local Git repository. Set `workspace.sourceType: "local_path"`, `workspace.defaultRef: "main"`, `workspace.setupCommand: "git init -b main"`, and `workspace.isPrimary: true`. Do NOT include an `executionWorkspacePolicy` for a fresh local repository \u2014 the repo and its base ref do not exist yet, so isolated git worktrees would fail on the first run. Agents work in the shared project workspace until the repo is established.\n   - Never include credentials or tokens in repository URLs or project text.\n10. Define an `issues` array of 6-12 CONCRETE, domain-specific initial work items taken straight from the description \u2014 the real features, components, and integrations the user actually described, each with a `title`, a `description` with acceptance criteria, a `priority`, and `assignTo` set to a role on the team. These seed the backlog so the project starts in its actual domain instead of only doing generic setup. Do NOT put generic scaffolding here (vision docs, linters, CI, branch protection) \u2014 the wizard adds those automatically.\n\nFirst write one paragraph explaining your reasoning: why this preset, why these modules, why these roles.\n\nThen output the JSON (no markdown fences):\n{{CONFIG_FORMAT}}\n';
+var single_shot_system_default = 'You are the Company Wizard. Company Wizard bootstraps AI-agent company workspaces from composable templates.\n\nGiven a natural language description of what the user wants to build, you select the best configuration.\n\n{{CATALOG}}\n\n## How Roles Work\n\n- **Base roles** (marked "always included") are auto-added. You do NOT list them in the JSON.\n- **All other roles** (listed under "Available Extra Roles") are OPTIONAL and must be EXPLICITLY listed in your JSON `roles` array if you want them.\n- **Critically: `engineer` is NOT a base role.** Most software projects need an engineer. If the project involves writing code, building software, or maintaining a repository, you MUST include `engineer` in your `roles` array. The preset does NOT auto-add roles \u2014 you must list every non-base role the company needs.\n- When in doubt, include the engineer. A company that builds software without an engineer agent will have no one to write code.\n\n## Instructions\n\n1. Analyze the user\'s description to understand: what they\'re building, their team size preference, quality vs speed priority, and any specific needs.\n2. Select the best preset as a starting point.\n3. List ALL modules to activate (including preset ones). Add extra modules beyond the preset if the description warrants them.\n4. List ALL non-base roles the company needs. This includes roles from the preset. If the project involves software, include `engineer`.\n5. Suggest a company name (PascalCase-friendly, short, memorable) if not obvious from the description.\n6. Write a thorough company description (2-4 paragraphs) capturing everything the user described \u2014 product, audience, tech stack, constraints, priorities, stage, and special context. This is the company\'s permanent record.\n7. Define goals as an array. The first goal is the main user-specific company goal \u2014 its description is the most important field. Keep it **outcome-first and product-first**: the title and opening sentence must state the primary deliverable or operating outcome, not a supporting constraint. Preserve compliance, security, accessibility, performance, tech-stack, and domain constraints inside the description under a clear "Constraints / quality bars" section unless the user explicitly says that constraint is the primary project. If the user\'s wording mixes a main outcome with secondary facts, ask yourself which thing the agents should build/operate first and write that as the top-level goal; put side facts into acceptance criteria, risks, or sub-goals only when they are independent workstreams. Include EVERYTHING the user described: full requirements, technical specs, acceptance criteria, constraints, edge cases, API contracts, user stories, performance targets. If the user provided a detailed spec, reproduce it in full, but do not let one constraint dominate the goal or initial issues. Preset/module template goals are added by the wizard after your JSON, so do NOT replace the user\'s objective with generic preset goals like "Build a REST API" or "Set up CI/CD" unless the user explicitly asked only for that.\n8. Define projects as an array. Most setups need one project linked to all goals. Name and describe the project concretely.\n9. Always decide the repository setup for the primary project:\n   - If the user gives an existing GitHub/GitLab/remote Git repo, set `workspace.sourceType: "git_repo"`, include `repoUrl`, and set `repoRef`/`defaultRef` exactly when the user or repository context provides one. Do not force a branch name or remote prefix; Paperclip\'s project/worktree settings decide the worktree base ref.\n   - If no external repository is given, assume Paperclip should create a fresh local Git repository. Set `workspace.sourceType: "local_path"`, `workspace.defaultRef: "main"` unless the user requested another initial branch, `workspace.setupCommand: "git init -b <defaultRef>"`, and `workspace.isPrimary: true`. Do NOT include an `executionWorkspacePolicy`; the assembler applies isolated worktrees only when Paperclip\'s experimental isolated-workspaces setting is enabled and a usable project base ref exists.\n   - Never include credentials or tokens in repository URLs or project text.\n10. Define an `issues` array of 6-12 CONCRETE, domain-specific initial work items taken straight from the description \u2014 the real features, components, and integrations the user actually described, each with a `title`, a `description` with acceptance criteria, a `priority`, and `assignTo` set to a role on the team. These seed the backlog so the project starts in its actual domain instead of only doing generic setup. Issue titles should lead with the core product capability; secondary constraints belong in acceptance criteria or risk notes unless the issue is specifically about that constraint. Do NOT put generic scaffolding here (vision docs, linters, CI, branch protection) \u2014 the wizard adds those automatically.\n\nFirst write one paragraph explaining your reasoning: why this preset, why these modules, why these roles.\n\nThen output the JSON (no markdown fences):\n{{CONFIG_FORMAT}}\n';
 
 // src/ui/prompts/messages.json
 var messages_default = {
   interviewStart: "Here's what I want to build:\n\n{{DESCRIPTION}}\n\nStart the interview. Ask your first question.",
   singleShot: "{{DESCRIPTION}}",
   generateConfig: "Generate the configuration now. Remember: include ALL non-base roles the company needs in the roles array (engineer is NOT a base role \u2014 list it if this project involves code). Write a thorough companyDescription that captures everything we discussed. The goals array must preserve the user-specific objectives; preset/module template goals are added later by the wizard, so do not replace the user's requested outcome with a generic preset goal like \"Build a REST API\" unless that is truly the entire objective. The first goal's description must contain ALL requirements, specs, and details \u2014 this is the primary brief for all agents. The primary project must explicitly choose repository setup: either a fresh local Git repository or an external Git repository such as GitHub. Never include credentials or tokens in repository fields. Also include an `issues` array of 6-12 CONCRETE, domain-specific initial work items taken straight from the brief \u2014 the real features, components, and integrations the user's spec actually describes, each with a `title`, a `description` with acceptance criteria, a `priority`, and `assignTo` set to a role on the team. These seed the backlog so the project starts in its actual domain. Do NOT put generic scaffolding here (vision docs, linters, CI, branch protection) \u2014 the wizard adds those automatically.",
-  configFormat: `Respond with ONLY a JSON object using this shape. Use exactly one project object for a single-project setup. For a fresh/new repository, use workspace.sourceType=local_path, defaultRef=main, setupCommand=git init -b main, and isPrimary=true, and do NOT include executionWorkspacePolicy (the repo does not exist yet, so isolated git worktrees would fail on the first run). For an existing external repo, use workspace.sourceType=git_repo, include repoUrl plus repoRef/defaultRef (default origin/main), and include executionWorkspacePolicy with isolated git_worktree.
+  configFormat: `Respond with ONLY a JSON object using this shape. Use exactly one project object for a single-project setup. For a fresh/new repository, use workspace.sourceType=local_path, defaultRef=main unless another initial branch was requested, setupCommand=git init -b <defaultRef>, and isPrimary=true, and do NOT include executionWorkspacePolicy. For an existing external repo, use workspace.sourceType=git_repo, include repoUrl plus repoRef/defaultRef only when the user or repository context provides one. Do not force a branch name or remote prefix. Do not include executionWorkspacePolicy; the assembler applies isolated worktrees only when Paperclip's experimental isolated-workspaces setting is enabled.
 {
   "name": "CompanyName",
   "companyDescription": "Comprehensive 2-4 paragraph description of what this company does, what it is building, who it is for, key technical decisions, priorities, constraints, and any special context. This is the company's permanent record \u2014 be thorough and specific.",
   "goals": [
     {
       "title": "Main user-specific goal title",
-      "description": "THOROUGH description with ALL requirements, specs, acceptance criteria, constraints, edge cases, and every detail the user provided. This is the primary brief for all agents \u2014 preserve every detail, do NOT summarize. Multiple paragraphs expected. Do not use a generic preset goal title unless the user asked for exactly that."
+      "description": "THOROUGH description with ALL requirements, specs, acceptance criteria, constraints, edge cases, and every detail the user provided. This is the primary brief for all agents \u2014 preserve every detail, do NOT summarize. Multiple paragraphs expected. Lead with the primary deliverable or operating outcome; put side constraints under Constraints / quality bars unless one is explicitly the main project."
     },
     {
       "title": "Additional user-specific goal if needed",
@@ -7142,11 +7130,52 @@ function StepIndicator() {
 function WizardShell() {
   const state = useWizard();
   const dispatch = useWizardDispatch();
+  const checkUpdate = usePluginAction6("check-update");
+  const [updateInfo, setUpdateInfo] = useState9(null);
   const StepComponent = STEP_COMPONENTS[state.step];
   useEffect6(() => {
     window.scrollTo({ top: 0 });
   }, [state.step]);
+  useEffect6(() => {
+    let cancelled = false;
+    checkUpdate({}).then((result) => {
+      if (!cancelled) setUpdateInfo(result);
+    }).catch(() => {
+      if (!cancelled) setUpdateInfo(null);
+    });
+    return () => {
+      cancelled = true;
+    };
+  }, []);
   return /* @__PURE__ */ jsxs13("div", { className: "flex flex-col", children: [
+    updateInfo?.ok && updateInfo.updateAvailable && /* @__PURE__ */ jsx19("div", { className: "mx-6 mt-4 rounded-lg border border-amber-500/30 bg-amber-500/10 p-3 text-xs text-amber-800 dark:text-amber-200", children: /* @__PURE__ */ jsxs13("div", { className: "flex items-start justify-between gap-3", children: [
+      /* @__PURE__ */ jsxs13("div", { className: "flex items-start gap-2", children: [
+        /* @__PURE__ */ jsx19(TriangleAlert, { className: "h-4 w-4 shrink-0 mt-0.5" }),
+        /* @__PURE__ */ jsxs13("div", { children: [
+          /* @__PURE__ */ jsx19("p", { className: "font-medium", children: "Company Wizard update available" }),
+          /* @__PURE__ */ jsxs13("p", { className: "mt-0.5 text-amber-700 dark:text-amber-300", children: [
+            "Installed ",
+            updateInfo.currentVersion,
+            "; latest ",
+            updateInfo.latestVersion,
+            ". Update the plugin package, then reload Paperclip."
+          ] })
+        ] })
+      ] }),
+      updateInfo.url && /* @__PURE__ */ jsxs13(
+        "a",
+        {
+          href: updateInfo.url,
+          target: "_blank",
+          rel: "noreferrer",
+          className: "inline-flex items-center gap-1 whitespace-nowrap font-medium hover:underline",
+          children: [
+            "npm",
+            /* @__PURE__ */ jsx19(ExternalLink, { className: "h-3 w-3" })
+          ]
+        }
+      )
+    ] }) }),
     getUserStepIndex(state) >= 1 && state.step !== "provision" && state.step !== "done" && /* @__PURE__ */ jsx19("div", { className: "flex items-center justify-end px-6 py-3", children: /* @__PURE__ */ jsx19(StepIndicator, {}) }),
     /* @__PURE__ */ jsx19("main", { className: "flex-1 flex items-start justify-center p-6", children: /* @__PURE__ */ jsx19("div", { className: "w-full max-w-2xl", children: /* @__PURE__ */ jsx19(StepComponent, {}) }) }),
     state.error && /* @__PURE__ */ jsxs13("div", { className: "fixed bottom-0 inset-x-0 bg-destructive/10 border-t border-destructive/20 px-6 py-3 text-sm text-destructive flex items-center justify-between", children: [