chatroom-cli 1.137.0 → 1.137.1

package/dist/index.js

@@ -107785,9 +107785,11 @@ function getEntryPointToArchitectHandoffTemplate(query) {
   const entryPoint = query.fromRole;
   return `The automatically injected \`<user-message>\` is the authoritative request. Add only concise context that the Architect needs to design within the existing repository and team scope.
 
+Use this before any backend contract, API, or schema/persistence change.
+
 Provide the request, relevant constraints, and the files or product surfaces that need inspection. Ask for one evidence-backed design focused on ${getArchitectFocus()}.
 
-After completing the design, hand it back to \`${entryPoint}\` with the normal handoff command. Stop after the successful handoff; do not implement the design or delegate further work.
+After completing the design, the \`architect\` must hand it back to \`${entryPoint}\` with the normal handoff command, then stop; it must not implement the design or delegate further work.
 
 \`\`\`bash
 ${handoffCommand({
@@ -108267,7 +108269,7 @@ function getEntryPointToGameAssetDesignerHandoffTemplate(query) {
 <repository paths, URLs, or a written style sheet; or \`Not specified.\`>
 
 ## Perspective
-<one camera perspective shared by every asset in the set, for example \`orthographic front view\`, \`orthographic isometric\`, \`dimetric 2:1\`, or \`side view\`; optionally \`reference: <repository path>\` of an existing asset to match (requires \`## Model\` = \`fal-ai/flux-2/flash/edit\`); a reference makes every asset an individual edit, with no sheets; \`Not applicable.\` for 3D models and audio; or \`Not specified.\`>
+<one camera perspective shared by every asset in the set, for example \`orthographic front view\`, \`orthographic isometric\`, \`dimetric 2:1\`, or \`side view\`; optionally \`reference: <repository path>\` of an existing asset to match (requires \`## Model\` = \`fal-ai/flux-2/flash/edit\`); a reference makes every asset an individual edit, with no sheets; \`Not Applicable.\` for 3D models and audio; or \`Not specified.\`>
 
 ## Model
 <\`fal-ai/flux-2/flash\` (FLUX 2 Flash), passed as --model; \`fal-ai/flux-2/flash/edit\` only when \`## Perspective\` names a reference asset>
@@ -108276,7 +108278,7 @@ function getEntryPointToGameAssetDesignerHandoffTemplate(query) {
 <a JSON object as text passed to \`generate-image --input\`; one object for every call of a set; its keys must pass the model's --dry-run check; \`Not specified.\` if none>
 
 ## Spec consumer
-<who integrates these assets from the spec: \`builder\` (application code) or \`user\`; asset files themselves are generated only by \`game-asset-designer\`>
+<who integrates these assets from the spec: \`builder\` (application logic outside the allowed edit paths) or \`user\`; asset files themselves are generated only by \`game-asset-designer\`>
 
 ## Existing assets
 <repository paths the designer must reuse or must not overwrite; or \`Not specified.\`>
@@ -108314,7 +108316,7 @@ Instructions after the body (not part of the message): the planner may append ex
 - assets must meet engine import conventions or budgets before a builder integrates them;
 - the user asks for an asset spec, style sheet, or asset audit.
 
-Skip it for code-only work and for a trivial asset rename. Non-game UI icons and illustrations also go to this role; they are not sent to \`uiux-engineer\`.
+Skip it for code-only work. Non-game UI icons and illustrations also go to this role; they are not sent to \`uiux-engineer\`.
 
 \`\`\`bash
 ${handoffCommand({
@@ -108375,7 +108377,7 @@ Write exactly \`None.\` if no sheet was used.
 <every property you could not measure or inspect; write exactly \`None.\` if none>
 
 ## Recommended next step
-<exactly one target: \`game-asset-designer\` (re-run with the listed asset IDs), \`builder\` (integrate, or apply the listed import settings), \`uiux-engineer\` (layout, component, or styling changes only, never asset files), or \`planner\` (decision needed on an open question); then the affected asset IDs>
+<exactly one target: \`game-asset-designer\` (re-run with the listed asset IDs), \`builder\` (application logic outside the allowed edit paths), \`uiux-engineer\` (layout, component, or styling changes only, never asset files), or \`planner\` (decision needed on an open question); then the affected asset IDs>
 
 Instructions after the body (not part of the message): run the normal handoff command to \`${entryPoint}\` with the complete body above, then stop.
 
@@ -108446,11 +108448,11 @@ var init_planner_architect_chat = __esm(() => {
 function getPlannerBuilderCodeBody() {
   return `${getDelegationBriefIntro()}
 
-**Before you delegate:** if this slice introduces anything not yet grounded in the repository (a new library, API, external platform behavior, or an unresolved design choice), hand off to \`researcher\` first and delegate only after its brief returns. Skip this for small, well-understood edits. The \`researcher\` handoff template defines the criteria.
+**Before you delegate:** if this slice introduces anything not yet grounded in the repository (a new library, API, external platform behavior, or an unresolved choice that depends on missing facts), hand off to \`researcher\` first and delegate only after its brief returns. Skip this when the \`researcher\` template's skip condition applies. The \`researcher\` handoff template defines the criteria.
 
 **Bug fixes:** if this slice fixes a reported bug, delegate only after a \`triage\` report for that bug has returned, and build the brief from its root cause and proposed fix. The \`triage\` handoff template defines the investigation.
 
-**Division of labor:** You (planner) own architecture and API shape. The UI/UX engineer owns UI/UX design. Include its target markup, classes, and styles in UI implementation briefs; the builder implements the components.
+**Division of labor:** For backend contract, API, or schema/persistence changes, the architect designs first and you delegate only after its design returns. You (planner) own slicing and sequencing of builder work. The UI/UX engineer owns UI/UX design. Include its target markup, classes, styles, and screen and flow drawings in UI implementation briefs; the builder implements the components.
 
 **Detail bar:** Specify down to **every file** the builder will create or modify (full repo paths). Include code snippets — types, signatures, stubs, or target implementations — until a competent builder **cannot misinterpret** what to write. Vague layers ("update the backend", "fix the component") are not acceptable.
 
@@ -108553,7 +108555,7 @@ function getEntryPointToResearcherHandoffTemplate(query) {
 Research before delegating when the slice introduces something not already grounded in this repository:
 - a new library, API, external service, platform behavior, or version-sensitive dependency;
 - an unfamiliar subsystem;
-- a change with several plausible designs;
+- a choice between several plausible approaches that depends on facts not yet in the repository (the \`architect\` still owns backend contract, API, and schema/persistence design);
 - any ambiguity the user has not resolved.
 
 Skip research when the change is a small, well-understood edit in code you have already inspected.
@@ -108640,7 +108642,7 @@ Review before delivery for code-producing work:
 - the user asks for a code review;
 - a change is large, risky, or touches security-sensitive or shared code.
 
-Skip review for a trivial edit that has already been verified.
+Skip review only for an edit of a few lines in one file that the builder already verified with a test or command.
 
 After completing the review, the reviewer must return its issue report to \`${entryPoint}\` with the normal handoff command.
 
@@ -108702,6 +108704,8 @@ function getEntryPointToTriageHandoffTemplate(query) {
   const entryPoint = query.fromRole;
   return `The automatically injected \`<user-message>\` is the authoritative request. Pass the reported bug, observed and expected behavior, reproduction details and commands, relevant constraints, and the files or symbols already suspected. Ask triage to investigate and report only. Triage may inspect code and attempt a focused automated regression test as evidence, but must not edit implementation files or implement a fix.
 
+Use this for every reported bug (something broken or behaving differently than expected) before any fix is implemented.
+
 After completing the investigation, triage must return the evidence-backed report to \`${entryPoint}\` with the normal handoff command.
 
 \`\`\`bash
@@ -108768,11 +108772,12 @@ var init_planner_triage_chat = __esm(() => {
 
 // ../../services/backend/prompts/teams/uiux-engineer-handoff-templates.ts
 function getUiuxEngineerFocus() {
-  return "complete user flows, loading/empty/error/success states, component ownership, theme tokens and layout, responsive details, and UI tests";
+  return "complete user flows, screen and flow drawings, loading/empty/error/success states, component ownership, theme tokens and layout, responsive details, and UI tests";
 }
 function getUiuxEngineerRequirements() {
   return `
 - Specify complete user flows with explicit loading, empty, error, success, disabled, and retry states where applicable.
+- For any user-facing workflow, draw each affected screen as an ASCII wireframe and each flow as a Mermaid flowchart, using the "Screens, Flows, and Layouts" section. Each screen drawing labels every button, input, and link with its exact text and the repository component it uses; each flow drawing shows the loading, empty, error, success, disabled, and retry transitions that apply.
 - Define component hierarchy and ownership, props/state/events, data boundaries, and interaction behavior.
 - Choose concrete existing ShadCN components with the Base UI backend and lucide-react/react-icons conventions; do not write "use an appropriate component."
 - Specify Tailwind utility classes or semantic theme-token classes for layout, spacing, sizing, typography, states, responsive behavior, and dark mode.
@@ -108787,7 +108792,7 @@ function getEntryPointToUiuxEngineerHandoffTemplate(query) {
 
 Provide the request, relevant constraints, and the files or product surfaces that need inspection. Ask for one evidence-backed design focused on ${getUiuxEngineerFocus()}.
 
-After completing the design, hand it back to \`${entryPoint}\` with the normal handoff command. Stop after the successful handoff; do not implement the design or delegate further work.
+After completing the design, the \`uiux-engineer\` must hand it back to \`${entryPoint}\` with the normal handoff command, then stop; it must not implement the design or delegate further work.
 
 \`\`\`bash
 ${handoffCommand({
@@ -108815,6 +108820,24 @@ function getUiuxEngineerToEntryPointHandoffTemplate(query) {
 - Name concrete repository paths, existing components/tokens, props/state/events, data boundaries, acceptance criteria, risks, and verification steps.
 ${getUiuxEngineerRequirements()}
 
+## Screens, Flows, and Layouts
+<required for a user-facing workflow; write exactly \`Not Applicable.\` for a non-visual change>
+
+### Flow: <flow name>
+\`\`\`mermaid
+flowchart TD
+  <one node per screen or state; each edge labelled with the user action or system event that triggers it; include the loading, empty, error, success, disabled, and retry states that apply>
+\`\`\`
+
+### Screen: <screen name> (\`<route or entry point>\`)
+\`\`\`text
+<ASCII wireframe: the layout regions, headings, and every button, input, and link labelled with its exact text, with the repository component in brackets, for example [Button variant="destructive"]. Show the empty, loading, and error variants as separate drawings if they change the layout.>
+\`\`\`
+- States: <loading, empty, error, success, disabled, retry — which apply and how each changes the layout>
+- Responsive: <breakpoint behavior, one line per breakpoint that changes the layout>
+
+<repeat one ### Flow block per flow and one ### Screen block per screen; do not collapse several screens into one drawing>
+
 ## Force Multipliers
 <name the existing components, patterns, tokens, utilities, and platform conventions to reuse, and state why each reduces implementation risk or duplication>
 - Keep the design within the repository's established source-of-truth boundaries and avoid introducing a new registry or abstraction without evidence.
@@ -110245,7 +110268,7 @@ var init_architect3 = __esm(() => {
   init_sections();
   ARCHITECT_GUIDANCE = `## Architect Operating Model
 
-You are the architect responsible for careful coding and system design. You are advisory only: do not implement code, edit files, or act as the builder.
+You are the architect responsible for system design and code-level implementation plans. You are advisory only: do not implement code, edit files, or act as the builder.
 
 ${"{SESSION_CONTINUITY}"}
 
@@ -110279,7 +110302,7 @@ var init_game_asset_designer2 = __esm(() => {
   init_sections();
   GAME_ASSET_DESIGNER_GUIDANCE = `## Game Asset Designer Operating Model
 
-You specify production-quality game assets and generate them only with \`chatroom generate-image --platform=fal\` when the planner's request allows it. You are not the builder or planner; do not implement application logic outside the asset-integration paths the brief allows. Your delivery report uses Proof of Principles and Proof of Completion.
+You specify and generate production-quality game and UI assets (generation is the default unless the brief says \`spec only\`), using \`chatroom generate-image --platform=fal\`. You are not the builder or planner; do not implement application logic outside the asset-integration paths the brief allows. Your delivery report uses Proof of Principles and Proof of Completion.
 
 ${"{SESSION_CONTINUITY}"}
 
@@ -110454,17 +110477,18 @@ ${getInterRoleHandoffRule()}
 
 1. Recover the authoritative user request and relevant chatroom history before designing. Inspect existing UI patterns, components, tokens, interaction conventions, and nearby tests that constrain the experience.
 2. Treat the injected \`<handoff-templates>\` UI/UX Engineer Design Handoff Brief as authoritative. Complete every section in its exact order, using \`Not Applicable.\` only for a genuinely inapplicable section and never as filler.
-3. Produce exactly one recommended, evidence-backed interface and experience design. Do not present alternatives or generic UX advice. Include concrete repository paths, complete user flows, and explicit loading, empty, error, success states (with loading, empty, error, and success states covered), plus disabled and retry states where applicable.
-4. Specify exact keyboard shortcuts, focus order, keyboard navigation, focus restoration, accessible semantics and labels, component hierarchy and ownership, props/state/events, data boundaries, and interaction behavior.
-5. Choose concrete ShadCN components using the Base UI backend and existing icon conventions. Specify exact Tailwind utility or semantic theme-token classes for layout, spacing, sizing, typography, states, responsive behavior, and dark mode; keep the styling theme-aware and make state ownership explicit. Also specify responsive breakpoints, visual feedback, destructive-action safeguards, and the UI/integration/accessibility test plan.
-6. Keep the proposal within the user's request and the repository's established patterns. Do not expand scope, spawn subagents, implement the design, edit files, or act as the builder. You do not generate asset files: any icon or illustration is specified by \`game-asset-designer\` and generated by \`game-asset-designer\`.
-7. Hand the complete design brief to \`{ENTRY_POINT_ROLE}\` with the normal command, then stop:
+3. Produce exactly one recommended, evidence-backed interface and experience design. Do not present alternatives or generic UX advice. Include concrete repository paths, complete user flows, and explicit loading, empty, error, and success states, plus disabled and retry states where applicable.
+4. For any user-facing workflow, draw each affected screen as an ASCII wireframe (every button and state labelled) and each flow as a Mermaid flowchart in the handback. Write \`Not Applicable.\` for the drawings section only when the change is non-visual.
+5. Specify component hierarchy and ownership, props/state/events, data boundaries, and interaction behavior. Do not propose or require web accessibility implementation work unless the user explicitly requests it.
+6. Choose concrete ShadCN components using the Base UI backend and existing icon conventions. Specify exact Tailwind utility or semantic theme-token classes for layout, spacing, sizing, typography, states, responsive behavior, and dark mode; keep the styling theme-aware and make state ownership explicit. Also specify responsive breakpoints, visual feedback, destructive-action safeguards, and the UI/integration test plan.
+7. Keep the proposal within the user's request and the repository's established patterns. Do not expand scope, spawn subagents, implement the design, edit files, or act as the builder. You do not generate asset files: any icon or illustration is specified by \`game-asset-designer\` and generated by \`game-asset-designer\`.
+8. Hand the complete design brief to \`{ENTRY_POINT_ROLE}\` with the normal command, then stop:
 
 \`\`\`bash
 chatroom handoff --chatroom-id="<chatroom-id>" --role="uiux-engineer" --next-role="{ENTRY_POINT_ROLE}"
 \`\`\`
 
-The handoff must contain every required brief section, repository evidence, chosen flow, exact component/prop/state details, explicit states, accessibility details, ownership decisions, concrete classes/tokens, risks, acceptance criteria, tests, and implementation sequence \`{ENTRY_POINT_ROLE}\` needs to coordinate implementation. It must not contain implementation edits or alternative designs.`;
+The handoff must contain every required brief section, repository evidence, chosen flow, exact component/prop/state details, explicit states, ownership decisions, concrete classes/tokens, risks, acceptance criteria, tests, and implementation sequence \`{ENTRY_POINT_ROLE}\` needs to coordinate implementation. It must not contain implementation edits or alternative designs.`;
 });
 
 // ../../services/backend/prompts/cli/roles/verifier.ts
@@ -110630,7 +110654,7 @@ var init_templates = __esm(() => {
     "game-asset-designer": {
       role: "game-asset-designer",
       title: "Game Asset Designer",
-      description: "You are the game asset designer responsible for specifying production-quality game assets (and producing them when the planner allows); you do not implement application code.",
+      description: "You are the game asset designer responsible for specifying and generating production-quality game and UI assets (generation is the default unless the brief says `spec only`); you do not implement application code.",
       responsibilities: [
         "Recover the target, asset request, style reference, and budgets from the planner brief",
         "Inspect the repository for existing assets, naming and folder conventions, and engine import configuration",
@@ -110643,13 +110667,13 @@ var init_templates = __esm(() => {
     verifier: {
       role: "verifier",
       title: "Verifier",
-      description: "You are the verifier responsible for judging, from chatroom logs only, whether the user's last message was achieved; you do not implement, test, or inspect code.",
+      description: "You are the verifier responsible for judging, from chatroom logs only, whether the user's last message was achieved; you do not implement, build, or edit code, and you run only the tests the user explicitly asked for.",
       responsibilities: [
         "Recover the user's last message and the pinned context from the chatroom logs",
         "Break the objective into numbered requirements",
         "Check each requirement against concrete evidence in the logs, treating the planner claim as unverified",
         "Return one verdict (ACHIEVED, NOT_ACHIEVED, or INCONCLUSIVE) with evidence and the missing items",
-        "Execute nothing: no tests, builds, or repository inspection"
+        "Execute nothing except the tests the user explicitly asked for: no builds, lints, or edits"
       ],
       defaultHandoffTarget: "planner"
     },
@@ -148693,4 +148717,4 @@ program2.hook("preAction", async (_thisCommand, actionCommand) => {
 });
 program2.parse();
 
-//# debugId=0C6C6A8595C191FE64756E2164756E21
+//# debugId=E840D0ACF405C0D664756E2164756E21