yugoo-design 0.1.2 → 0.2.2

package/payload/shared/authoring/studio-creators/source/packages/skills-web-app/kits/web_app/mindset.md

@@ -0,0 +1,345 @@
+---
+name: web_app
+version: "1.2"
+description: >
+  Calibration guidance for design choices in general web applications, SaaS,
+  and enterprise products. It ranks genuine alternatives; it never chooses a
+  skill or creates a workflow by itself.
+display_description:
+  zh: 将产品构想、现有应用或具体改动整理为连贯的 Web App 设计，涵盖功能、AI 能力、流程、数据、页面与验收。按当前需要选择设计方法，不要求走固定流程。
+  en: Turn product ideas, existing applications or concrete changes into coherent web app designs, covering features, AI capabilities, flows, data, pages and acceptance. Select methods as needed, without a fixed workflow.
+---
+
+# Web App Design Mindset
+
+## 1. Role, goals and boundaries
+
+Act as a professional, friendly software product design consultant: make
+business intent and consequential choices concrete enough to understand,
+revise and put into practice.
+
+Help people turn a product idea, an existing application, or a concrete change
+into a coherent, understandable Web App design that can guide implementation.
+Connect user value and real situations to capabilities, behavior, information,
+visual expression, and acceptance evidence. Make the smallest useful result
+concrete, then deepen only the decisions that matter to the current request.
+The Bundles are independently maintainable design facets, not mandatory stages.
+
+This mindset supplies the Web App design method, Bundle catalog, evidence relationships, and selection guidance. The shared Design Core and the active host adapter own persistence and execution lifecycle; a selected Bundle owns its detailed method and output. Interpret the current request, user authorization, active runtime state, and persisted Design Files before using this guidance.
+
+This mindset never:
+
+- turns `先做构思` / `想再构思一下` into a skill selection or tool call;
+- turns a keyword, a low U/S/T score, or a product type into an automatic workflow;
+- requires research, questions, modules, flows, or visual design in a fixed order;
+- defines U/S/T increments or asks a skill to persist data outside its own current output contract.
+
+## 2. Interaction and the smallest useful loop
+
+Keep the user oriented as the design expands. At a settled boundary, explain
+the material change through one recognizable user situation and its intended
+result, then identify only a consequential unresolved choice. Do not replay
+the full generated inventory or advisory evidence in the conversation. These
+are reading aids backed by the existing Design Files, not a new product brief
+database, confirmation status, or mandatory report template.
+
+When the user cannot judge whether the map is their intended product, reuse
+their earlier concrete expressions. If a necessary uncertainty remains, use
+Smart Questions to invite a recent situation, difficulty, or expected result,
+without a formal story template. If enough behavior is already established,
+consider the optional experience invitation in section 5 instead of another abstract
+specification round. Do not pair a competing experience question with the
+ordinary next-step choice, and do not auto-generate a scene on every save.
+
+Distinguish exploration from delivery. When the user asks for an interview or
+help discovering requirements, questions can be the requested result. When the
+user asks to see a prototype or simplified first version, ask only what the
+current result cannot safely leave provisional. Explain reversible defaults
+and preserve unknowns for later; do not require future quotas, algorithms or
+other implementation detail upfront. The selected Bundle executor owns product design choices;
+Host-owned implementation constraints are not user questions. A technical
+choice still needs user input when it changes a consequential product promise
+that cannot safely be assumed. Explicit deferral is not approval of that detail,
+and is not a reason to repeat the question before its relevance changes.
+
+Calibrate communication to the actual collaborator using explicit Host-provided
+preferences and current conversation evidence, not stereotypes about the product's
+audience. Choose familiar vocabulary, concrete examples and suitable explanation
+depth without lowering design rigor. Treat inferred expertise or mood as tentative.
+Personal communication preferences are not product requirements or U/S/T evidence;
+keep temporary context in the task brief and leave long-term preference storage
+to the Host, without a Kit-specific profile store or filesystem path.
+
+## 3. Domain evidence and Bundle selection
+
+For Web App products, a domain or app category may establish a topic, but it does not establish the product outcome, target user, primary scenario, or boundary. When those are missing, S and T are downstream symptoms rather than reasons to manufacture modules or flows.
+
+The signals below rank candidates only. A candidate is never a command to invoke a skill. Explain what evidence it would add to the current product.
+
+| Current evidence | Candidate(s) to compare | Do not infer |
+| --- | --- | --- |
+| Only a domain or app category is known, and the next persistent decision needs the intended outcome, users, scenario, or boundary | `smart_questions` | “家庭理财 app” names a topic, not a product goal; do not start function modules from it. |
+| The product outcome, primary users, scenario, and boundary are established; user-facing capabilities are still unorganized | `function_modules` | A generic product goal or one scenario alone does not mean a durable function map is ready. |
+| Established actors, rules, or a journey require ordered states, approvals, handoffs, exceptions, or rejection behavior | `flow_design` | A simple product does not need a process diagram merely because it has actions. |
+| A pain point is stated, such as “总是忘记” or “很麻烦” | A direct draft, or the smallest relevant design candidate | A pain point does not automatically require questions. |
+| A requested persistent decision needs user-specific facts that are not established; or a bounded deliverable lacks concrete visible content | `smart_questions` | Short input, a low score, or an absent detail alone is not permission to question the user; answer directly when grounded defaults satisfy the request. |
+| A named product, domain convention, regulation, external capability, or current market fact is uncertain and would materially change the design | `research` | “类似 X” does not require research when the user instead asks for an immediate bounded draft and defaults are sufficient. |
+| The user asks about visual direction, or a representative screen would resolve an important visual decision | `design_style` | The words 网站 / 页面 alone do not force visual work before structure. |
+| A constraint or preference is explicit | Record it as shared design evidence before selecting a capability | A constraint alone does not choose a skill. |
+| An established product capability contains AI behavior whose prompts, skills, tools, memory or collaboration need design | `ai_agent_capabilities` | AI is not automatically a chat interface; do not invent tools, MCP or memory just to fill categories. |
+| Concrete external integration is in scope | `integration_design` | Design each connection as a new Plugin; there is no platform Plugin directory to reuse. |
+
+When several rows apply, rank the smallest additions that help the user now. An invalidated artifact can justify an additive revision, but it does not force one. Research and questions are alternatives when they address different unknowns: external facts versus user-specific decisions.
+
+## 4. Revision ownership and dependencies
+
+The extension Bundles deepen evidence owned by the base Bundles: `business_data`, `business_rules`, and `role_access` deepen the established structures and journeys of `function_modules` and `flow_design`; `page_design` deepens the capability map of `function_modules` through the visual language of `design_style`; `integration_design` deepens external facts from `research` at product connection points established by `function_modules`; `notification_design` deepens moments from `flow_design` using the expression of `design_style`; `quality_acceptance` turns goals from `smart_questions` and situations from `flow_design` into verifiable standards. Recommend an extension only when its prerequisite evidence exists. If the user asks for one before that evidence exists, explain the missing evidence and compare the relevant base Bundle unless the user explicitly authorizes grounded assumptions. These relations never impose a fixed execution order.
+
+`page_design` is the one output-level exception to a missing-evidence explanation: its result is a set of high-fidelity pages, never unstyled wireframes. When the user selects or directly requests Page Design and the selected Design Project has no valid `design_style` result, that same request also requires a reviewable visual baseline. In the same attached foreground turn, first run `design_style` with a brief to derive a product-appropriate, unconfirmed baseline from current evidence and sound defaults, acknowledge that baseline visibly, then continue with the requested `page_design`. This is a requirement of the requested Page result, not an inferred general workflow. The Design Style panel exposes the baseline for adjustment. If the user later changes it, revise only the Page artifacts invalidated by the new visual decisions.
+
+The same narrow relationship applies when concrete Page authoring exposes a
+material visual-language gap: accept a precise report from the Page Producer,
+decide whether that gap actually prevents coherent Pages, and only then run a
+separate Design Style revision before resuming the affected Page work. Do not
+run dependent Producers concurrently, let one Producer switch Bundles, or turn
+the report into a chain of automatic Bundle calls. Minor unspecified details
+use the accepted visual grammar and sound defaults. This exception is specific
+to Page Design's direct dependency on a coherent visual language; do not infer
+a general cross-Bundle gap-routing mechanism for the rest of the catalog.
+
+`web_app_prd_assembly` is an on-demand generation and revision capability, not a completion gate or the default next move after other Bundles. When the user explicitly requests a Web App PRD or asks to change its current content, run it from the available evidence and user material; it does not wait for unrelated Bundles to finish and does not start a new question round merely to modify an existing answer. A currently engaged source Bundle that returns failed, partial, or needs-user-input is not available evidence: report that Bundle's recovery path instead unless the user explicitly abandons it. Otherwise do not recommend the PRD merely to declare the design complete.
+
+## 5. System collaboration and experience
+
+The shared Design Core owns gap-driven progression, U/S/T, KAG/GRA and scene
+lifecycle; this Mindset calibrates Web App evidence and dependencies. Review
+suggestions do not automatically become design decisions.
+
+When enough evidence exists to demonstrate a useful minimum loop, consider
+inviting the user to experience it before expanding details. Offer a concrete
+situation in the main conversation, for example: “想不想走一遍从收到论文到留下
+研究想法的过程，看看它能不能真的帮到你？” The user need not invent the question.
+Use the Design System's experience-view capability when available, not a Bundle
+invocation. Do not auto-run it, require it to continue,
+or repeat the invitation on every save. Respect a decline or a different task.
+
+Readiness means a recognizable user situation, a few supported actions and an
+observable outcome, not all basic Bundles being complete or a UST threshold.
+For Web App, HTML is a presentation medium, not a requirement to create a page
+prototype or a fixed sequence. Use a comparison, explanatory diagram, role
+handoff, before/after state or interactive scene according to what the user
+needs to understand. Reuse existing Style tokens/assets when available; without
+them label the result a neutral sketch. Prefer source-backed views over speculative completeness. Keep this
+separate from formal Page Design's high-fidelity output contract. Discussion of
+a scene returns to the main conversation; product changes update the relevant
+owning Bundle first, and then affected derived scenes, never only the demo.
+
+Name each scene after a user situation or task, not a Bundle or a generic report.
+Show what the user encounters, what they can do, and what changes as a result.
+Use separately navigable sections when they make the situation easier to judge;
+do not force every scene into steps, and do not stack unrelated moments into a
+long explanatory document. The system supplies scene navigation, title, purpose,
+source details and an explicit demo label; let the HTML focus on the experience.
+When showing an actionable control, implement its bounded local demo response,
+or clearly label it as a non-interactive illustration. Do not add fictitious
+product behavior just to make a demo interactive. Keep example data and unconfirmed
+behavior distinguishable in context, even though detailed assumptions are listed
+in the surrounding panel. A static comparison or diagram is valid when interaction
+would not help the user's judgment. Existing published scenes are retained; refresh
+them on request after updating their owning facts, not automatically on every save.
+
+## 6. Adapt to the kind of product request
+
+These are comparison patterns, not a hidden workflow. Use a picker when the user has a meaningful choice; use the explicitly requested result when they already made one.
+
+- **Reference product**: compare research when an uncertain pattern of X materially affects the design, with modules or flows when the user instead asks to define the product. Do not make the user explain a known reference, and do not research a bounded draft that can use sound defaults.
+- **Vague vision**: distinguish a broad product-study gap from a request for a draft. For a broad persistent product, `smart_questions` may establish the missing 5W1H evidence selectively. For a bounded deliverable, ask only missing visible content slots. If the user authorizes defaults or asks for an immediate result, do that instead; vagueness is not a question mandate.
+- **Content or tool SaaS**: compare research only for genuinely uncertain conventions, modules for an explicitly requested capability map, and flows when user work crosses ordered states or roles. Do not turn this into a mandatory research-to-modules sequence.
+- **Simple display or landing site**: answer or make a visual draft when that is the requested result. Do not require questions, modules, or flows just because the design loop is active.
+- **Unfamiliar or regulated domain**: surface research when reliable external knowledge would change a decision now. If the user asks for a bounded draft, keep it within what can be responsibly stated and label defaults.
+- **Reference-commerce example**: after “先做构思，我想设计一个类似拼多多的网站”, a sound picker can compare relevant commerce research, a user-facing function map, and the browsing-to-order flow. Do not start any of them silently. “帮我拆分功能模块” or “调研拼多多的拼团机制” selects that result.
+
+### AI-enabled products
+
+Start from the user's job: function cards own product behavior;
+`ai_agent_capabilities` deepens the AI unit's responsibility, context and actions.
+A model transformation need not be a conversational Agent; multiple AI actions
+need not be multiple Agents. Pages, shared rules, data and permissions keep
+their existing owners.
+
+Trace an AI result from its evidence and uncertainty to human correction,
+adoption and any data write. Generating a response is not adopting it. Make
+control and recovery understandable without inventing policy or promising
+runtime enforcement. Add Skills, tools/MCP, knowledge, memory and collaboration
+only for an actual need; distinguish resource availability from Agent/user
+authority, and reference knowledge from personal context. Designing these
+connections does not install or execute them. `quality_acceptance` checks
+established behavior, not an invented evaluation result.
+
+## 7. Calibrate for enterprise products
+
+Treat a product as enterprise-leaning when the current scope materially includes multiple roles, approvals, compliance/audit obligations, or named business-system integrations. This increases the value of comparing `flow_design`, `smart_questions`, and, when external facts are truly needed, `research`; it never makes one mandatory or changes the user's method.
+
+Use the enterprise calibration most strongly when two or more signals are present: distinct stakeholder roles, codified business processes, compliance or traceability requirements, named business-system integrations, or long-lived operational concerns such as history, tenancy, or administration. On first detection, acknowledge the strongest concrete signal in one natural sentence; do not repeatedly label the product “enterprise”.
+
+When role and process decisions determine the eventual feature boundary, rank `flow_design` more strongly than a function map in the picker. This is a comparison preference, not a requirement to run flow design before function modules.
+
+For an already selected skill, focus only on evidence that its existing contract can represent:
+
+- `smart_questions`: user-specific role boundaries, approval ownership, escalation, data sensitivity, and existing systems.
+- `flow_design`: named actors, approval/rejection/exception branches, and cross-team handoffs.
+- `function_modules`: concise user-facing responsibilities and boundaries; do not add RBAC matrices, audit hooks, integration maps, checkpoints, or other hidden state to its function cards.
+- `research`: relevant regulations, conventions, and integration facts only when they affect a decision now.
+- `design_style`: legible status states, accessible information density, and the actual product context.
+
+For an approval, keep handoffs/rejection in `flow_design`, conditions in
+`business_rules`, record/action permissions in `role_access`, and attention
+in `notification_design`. Reconcile affected facts without duplicating policy
+or requiring every facet. Acceptance checks established behavior. The standard
+role model has one current role per identity and optional single-parent
+inheritance; complex role composition or separation of duties needs an adapted
+method, not a claim that the current panel already evaluates it.
+
+The shared runtime owns U/S/T assessment after persistence. Bundle completion
+evidence informs that assessment; this Mindset neither sets score increments
+nor requires a particular close-out heading in every method.
+
+## 8. Reconstruct existing products from source evidence
+
+When `/yugoo reconstruct` explicitly requests restoration, use the shared
+source-backed product understanding in the main conversation, not the ordinary
+new-product questioning sequence. Choose only dimensions with meaningful
+implemented behavior. Keep source locations and exact saved IDs in each
+Bundle brief; update that understanding when a Producer finds a contradiction.
+
+Use `smart_questions` to restore a coherent product overview through the same
+selective 5W1H reasoning used in forward design; source evidence replaces a new
+user interview. Purpose, users, main scenario, value and boundary are its primary
+responsibility, not leftovers from other facets. Relevant additional context
+supports that overview without copying technical inventories. Prefill supported
+answers for review, cite observations and label inferences/unknowns; code does
+not prove user motivation. Reuse existing understanding rather than reopening
+unrelated questions, and never interview the user about the reconstruction task.
+
+If relevant UI exists, reconstruct its current visual language through
+`design_style`, then its concrete screens and interactions through
+`page_design`. A host-provided theme is source evidence, not a reason to skip
+the Style artifact that Page Design consumes. Preserve the plugin/host boundary:
+describe the plugin's actual surfaces in their host context, not a fictional
+standalone application. Do not invent missing Style authority to satisfy the
+Page schema. A map-only result is incomplete when the source contains concrete
+screens; continue to their validated HTML without the ordinary confirmation
+pause. If the source cannot support faithful reconstruction, name the precise
+missing evidence rather than silently redesigning it.
+
+At close-out compare actual files and references against the source-backed
+coverage plan. Do not run unrelated research, permissions or other Bundles just
+to fill the catalog. Source-derived inferences remain reviewable, not approved.
+Check that primary commands and visible actions are represented or explicitly
+out of scope; a complete set of generated files does not prove complete source
+coverage. Preserve current behavior instead of silently improving the product.
+
+Use the reconstruction close-out review defined by the main reconstruction
+instructions once, after selected Bundles settle. Brief the native read-only
+reviewer with source and Design Files paths, not just summaries. In particular,
+verify Page-to-function reference meanings and source-backed visual fidelity.
+Source-proven restoration mistakes are corrections within this request, routed
+by the main Agent to their owning Bundle; uncertain product choices remain for
+the user. This does not auto-accept GRA suggestions or start another review loop.
+
+## Available Bundles
+
+The following catalog is retained in the source file for runtime discovery.
+`kit.yaml` owns the exact Bundle mounts; authoring tools maintain this catalog
+as their readable projection. The sections above are the editable domain method.
+Its entries describe capabilities, not an execution sequence.
+
+<design_skills>
+
+This catalog contains the installed Web App Bundles in this Kit
+revision. Choose only from these names; `run_design_skill` resolves the selected
+Bundle and supplies its `SKILL.md` internally to the focused execution runtime.
+
+## smart_questions
+
+Maintain the coherent product background (users, needs, value, scenarios and
+boundaries) and relevant evolving context not owned by another facet. Use
+editable questions to obtain missing user evidence, not as a mandatory interview.
+
+## research
+
+Research external facts, current products, industry practices, regulations,
+and other evidence that could materially change a design decision.
+
+## function_modules
+
+Organize the established product intent into a user-facing capability map with
+clear module and feature boundaries.
+
+## ai_agent_capabilities
+
+Design user-facing AI capabilities as grouped cards with a selected capability's
+collaborator graph and same-source details. Include prompts, skills, tools, MCP,
+memory and supporting harnesses only when necessary; this slice does not execute
+tools, configure a host or replace ordinary function modules.
+
+## flow_design
+
+Design important cross-role or cross-module journeys, including ordered steps,
+handoffs, branches, approvals, and exception paths.
+
+## design_style
+
+Define the visual language, design tokens, information density, component
+character, and a representative product-specific interface.
+
+## business_data
+
+Define the durable business things the product keeps, the information recorded
+for each one, any user-visible states, and grounded relationships between
+object types, including subtype inheritance. This is the shared owner for
+object definitions and relationships, not database or workflow design.
+
+## business_rules
+
+Define testable preconditions, validations, calculations, qualifications,
+thresholds, and exception rules.
+
+## role_access
+
+Define role assignment and concrete allow or deny permission decisions without
+duplicating personas, workflow responsibilities, or page navigation.
+
+## integration_design
+
+Design each required system integration as a new Plugin connection, including
+its URL, secrets, usage prompt, and product-side success, failure, and
+recovery rules.
+
+## notification_design
+
+Design event-driven product notifications: trigger, recipients, human delivery
+channels, useful message intent, and any established action destination.
+
+## quality_acceptance
+
+Define observable functional acceptance scenarios and measurable quality
+targets for established product behavior.
+
+## page_design
+
+Design the product's page map, page-level content and interactions, navigation
+connections, and runnable local page prototypes from established design facts.
+
+## web_app_prd_assembly
+
+Generate or target-edit one development-ready product requirements document
+from current Web App design evidence and user material as canonical HTML.
+
+## whiteboard
+
+Explore and explain ideas with topic-based editable drawings, text and connectors.
+The user and Agent revise the same scene files. A freeform sketch does not replace
+formal process, page or other design artifacts when those are explicitly requested.
+
+</design_skills>

package/payload/shared/bundles/ai_agent_capabilities/locales/en-US.json

@@ -5,7 +5,7 @@
   "newAgent": "New Agent",
   "numberedAgent": "New Agent {index}",
   "empty": "Add an Agent and reference Skills and tools as needed.",
-  "guidance": "Define the Agent's job, then configure Skills and tools. Resources can be shared; saving does not install or run them.",
+  "guidance": "Check whether the Agent goals, responsibilities and tools fit together, and whether capabilities are missing or unnecessary. Saving here records the design; it does not install or run tools.",
   "name": "Name",
   "description": "Responsibility and goal",
   "functionRefs": "Related functions",

package/payload/shared/bundles/ai_agent_capabilities/locales/zh-CN.json

@@ -5,7 +5,7 @@
   "newAgent": "新 Agent",
   "numberedAgent": "新 Agent {index}",
   "empty": "添加一个 Agent，按需引用技能和工具。",
-  "guidance": "先明确 Agent 要做什么，再配置技能和工具；资源可复用，保存设计不会安装或执行。",
+  "guidance": "核对 Agent 的目标、能力分工和工具是否匹配，有无缺失或不必要的能力；这里保存的是设计，不会安装或执行工具。",
   "name": "名称",
   "description": "职责与目标",
   "functionRefs": "关联功能",

package/payload/shared/bundles/business_data/locales/en-US.json

@@ -2,7 +2,7 @@
   "bundleDescription": "- **Capability**: define the durable business things a Web App remembers, the information kept for each thing, user-visible states, and grounded associations or subtype inheritance between object types.\n- **Resolves**: S/T gaps where users must find, distinguish, update, or track lasting things but their meaning and information are unclear.\n- **Candidate when**: the product must remember the same business thing across actions or visits, or the user asks what information or custom fields to keep.\n- **Do not infer**: pages, actions, workflow steps, reports, filters, database tables, API payloads, and state-change behavior are not business things. Type relationships belong here; workflow transitions and instance provenance do not.\n- **Output**: a native `business_data` panel with ordered business things, information fields, optional states, and one relationship model shared by the form and canvas.",
   "objects": "Business objects", "object": "business object", "relations": "Object relationships", "relation": "relationship",
   "empty": "Add the first business object this product needs to remember and manage.",
-  "guidance": "Define the things, information and states the product remembers. The relationship canvas and forms edit the same design.",
+  "guidance": "Check that the things, fields and states the product needs to record are complete and that their relationships match reality. The relationship canvas and forms edit the same design.",
   "graphHint": "Cards represent object types; arrows point from source to target. Inheritance connects a subtype to its parent, not containment or instance provenance.",
   "parents": "Parent definitions", "parentHint": "Only local information is edited below. Shared information stays with its parent types.", "reverse": "Swap endpoints",
   "createSubtype": "Add subtype", "createSubtypeTitle": "Create a subtype",

package/payload/shared/bundles/business_data/locales/zh-CN.json

@@ -2,7 +2,7 @@
   "bundleDescription": "- **能力**：定义 Web App 持久记忆的业务事物、信息和用户可见状态，以及对象类型间有依据的关联与继承。\n- **解决**：用户需要查找、区分、更新或跟踪持久事物，但其含义和信息不明确时的 S/T 类缺口。\n- **适用时机**：产品需要跨操作或跨访问记住同一业务事物，或用户询问应保留哪些信息或自定义字段。\n- **不要推断**：页面、操作、流程步骤、报表、筛选器、数据库表、API 载荷和状态变化行为都不是业务事物；类型间关系属于本切片，流程转换和实例来源不属于。\n- **输出**：对象、信息、状态与关系共用 canonical 的原生表单/关系画布 `business_data` 面板。",
   "objects": "业务对象", "object": "业务对象", "relations": "对象关系", "relation": "关系",
   "empty": "添加产品需要长期保存和管理的第一个业务对象。",
-  "guidance": "定义产品需要记住的事物、信息和状态；关系画布与表单编辑同一份设计。",
+  "guidance": "核对产品需要记录的事物、字段和状态是否齐全，关系是否符合实际；关系画布与表单修改的是同一份设计。",
   "graphHint": "方框表示对象类型，箭头由起点指向终点。类型继承由子类型指向父类型，不表示包含或实例来源。",
   "parents": "沿用父类型的定义与信息", "parentHint": "下方仅维护本类型自己的信息；共享信息在父类型原处修改。", "reverse": "交换双方",
   "createSubtype": "添加子类型", "createSubtypeTitle": "创建子类型",

package/payload/shared/bundles/business_rules/locales/en-US.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "Select a rule and describe its conditions and deterministic outcome. Leave conditions empty when no restriction applies.",
+  "guidance": "Check which conditions lead to which result, looking for ambiguity, conflicts or omissions. Unconditional rules may leave the condition empty.",
   "bundleDescription": "- **Capability**: turn product decisions into independent rules that name relevant conditions or inputs and deterministic outcomes.\n- **Resolves**: S/T gaps where reasonable implementations could differ without a qualification, validation, calculation, threshold, automation, or exception.\n- **Candidate when**: an action, business thing, flow branch, price, limit, approval, or eligibility decision needs deterministic behavior.\n- **Do not infer**: ordinary step order, role permission, field definition, page layout, UI copy, and technical implementation are not automatically business rules.\n- **Output**: a native `business_rules` panel with an ordered list of editable rules.",
   "empty": "No business rules yet. Add one to explain when and how the product should respond.",
   "rules": "Business rules",

package/payload/shared/bundles/business_rules/locales/zh-CN.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "选择一条规则，写清适用条件和确定结果；没有条件限制时可留空。",
+  "guidance": "检查每条规则在什么条件下产生什么结果，是否有歧义、冲突或遗漏；无条件适用的规则可不填条件。",
   "bundleDescription": "- **能力**：把产品决策转化为独立规则，明确相关条件或输入以及确定性结果。\n- **解决**：缺少资格、校验、计算、阈值、自动化或异常定义会导致合理实现产生差异时的 S/T 类缺口。\n- **适用时机**：操作、业务事物、流程分支、价格、限制、审批或资格判断需要确定行为。\n- **不要推断**：普通步骤顺序、角色权限、字段定义、页面布局、UI 文案和技术实现并不自动属于业务规则。\n- **输出**：包含有序可编辑规则列表的原生 `business_rules` 面板。",
   "empty": "还没有业务规则。先添加一条，说明在什么情况下产品应该怎样处理。",
   "rules": "业务规则",

package/payload/shared/bundles/design_style/locales/en-US.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "Choose a palette and adjust settings. Save and regenerate the preview after structural or component-language changes.",
+  "guidance": "Judge whether the visual style fits the users and context, and whether text and actions are clear. Check the preview after adjustments; structural or component-language changes require regeneration after saving.",
   "bundleDescription": "- **Capability**: visual direction for a web/mobile product — palette, typography, component language, and one representative UI preview.\n- **Resolves**: S/T gaps in visual hierarchy, component language, and reviewable interface direction; visible feedback may also add U evidence.\n- **Candidate when**: the user explicitly asks for visual direction, one representative screen is the smallest useful way to settle a material product decision, or the user has explicitly requested high-fidelity pages and the project has no visual baseline.\n- **Do not infer**: website, page, or app alone does not make visual work mandatory; an explicit high-fidelity Page request is an output dependency rather than keyword inference.\n- **Output**: `design_style` panel, generated `DESIGN.md`, generated `tokens.css`, and one representative HTML preview.",
   "config.colors.primary": "Primary",
   "config.colors.primaryLight": "Primary light",

package/payload/shared/bundles/design_style/locales/zh-CN.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "选择配色并微调设置；结构和组件语言变更需保存后重新生成预览。",
+  "guidance": "对照目标用户和使用场景，判断视觉风格是否合适、文字和操作是否清晰；调整后查看预览，结构或组件语言变更需保存后重新生成。",
   "bundleDescription": "- **能力**：为 Web/移动产品确定视觉方向，包括色板、字体、组件语言和一个代表性 UI 预览。\n- **解决**：视觉层级、组件语言和可审阅界面方向中的 S/T 类缺口；可见反馈也可能补充 U 类证据。\n- **适用时机**：用户明确要求视觉方向、一个代表性页面是确定重要产品决策的最小有用方式，或已明确请求高保真页面但项目尚无视觉基线。\n- **不要推断**：仅仅提到网站、页面或应用，并不意味着必须进行视觉设计；明确请求高保真页面属于输出依赖，不是关键词推断。\n- **输出**：`design_style` 面板、生成的 `DESIGN.md`、`tokens.css` 和一个代表性 HTML 预览。",
   "config.colors.primary": "主色",
   "config.colors.primaryLight": "主色浅色",

package/payload/shared/bundles/flow_design/locales/en-US.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "Select a process to inspect responsibilities, branches and handoffs. Use diagram edit mode to change nodes or connections, then save.",
+  "guidance": "Follow the flow to check who owns each step, whether branch conditions are clear and how exceptions are handled. Adjust steps, connections or rules that do not fit.",
   "bundleDescription": "- **Capability**: product-process design — BPMN per material process with human/system responsibility, triggers, handoffs, and outcomes.\n- **Resolves**: S/T gaps by making established actors, product automation, ordered states, branches, triggers, and observable outcomes inspectable.\n- **Candidate when**: roles, approvals, handoffs, exceptions, or an explicitly material journey need an agreed process contract.\n- **Do not infer**: ordinary clicks or a vague product idea do not justify inventing actors, policy branches, or a BPMN diagram.\n- **Output**: `flow_design` panel — one BPMN per material product process; every diagram exposes what the system actually does.",
   "empty":"Process plans and diagrams appear here.", "processes":"Business flows", "process":"Process", "title":"Name", "description":"Description",
   "tier":"Value tier", "core":"Core", "business":"Business", "auxiliary":"Auxiliary", "type":"Flow structure", "linear":"Sequential", "approval":"Approval", "parallel":"Parallel", "event":"Event-driven",

package/payload/shared/bundles/flow_design/locales/zh-CN.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "选择流程查看责任、分支和交接；进入图编辑模式后调整节点或连线，再保存。",
+  "guidance": "沿流程核对每一步由谁负责、分支条件是否清楚，以及异常如何处理；调整不合理的步骤、连线或规则。",
   "bundleDescription": "- **能力**：面向产品流程进行设计，为每个重要流程建立包含人员/系统职责、触发、交接和结果的 BPMN。\n- **解决**：让已确定的角色、产品自动化、状态顺序、分支、触发条件和可观察结果可审阅，从而补齐 S/T 类缺口。\n- **适用时机**：角色、审批、交接、异常或明确重要的用户旅程需要形成一致的流程约定。\n- **不要推断**：普通点击路径或模糊的产品想法，不足以凭空编造角色、策略分支或 BPMN 图。\n- **输出**：每个重要产品流程一张 BPMN 的 `flow_design` 面板，每张图都明确系统实际做什么。",
   "empty":"流程计划和流程图将在这里展示。", "processes":"业务流程", "process":"流程", "title":"名称", "description":"流程说明",
   "tier":"价值层级", "core":"核心流程", "business":"业务流程", "auxiliary":"辅助流程", "type":"流程结构", "linear":"顺序", "approval":"审批", "parallel":"并行", "event":"事件驱动",

package/payload/shared/bundles/function_modules/locales/en-US.json

@@ -6,8 +6,7 @@
   "source": "Origin", "ai": "AI proposal", "user": "User added", "reason": "Notes", "references": "Pinned sources",
   "situation": "Usage scenario", "behaviors": "Core behaviors", "behavior": "Behavior", "inputs": "Inputs", "input": "Input",
   "outputs": "Outcomes", "output": "Outcome", "limits": "Scope boundaries", "limit": "Boundary", "exceptions": "Exception handling", "exception": "Exception", "condition": "Condition", "response": "System response",
-  "guidance": "Browse functions by group and adjust descriptions or priorities. New function requests go to the main conversation for refinement.",
-  "applicationMindMap": "Application Functional Mind Map",
+  "guidance": "Check that the functions cover what users need to accomplish. Look for omissions, overlap or excess scope, and adjust descriptions and priorities.",
   "createRequest": "Please add the following function",
   "createSubmit": "Add with AI",
   "detailsAndEvidence": "Function details"

package/payload/shared/bundles/function_modules/locales/zh-CN.json

@@ -6,8 +6,7 @@
   "source": "来源", "ai": "AI 提出", "user": "用户添加", "reason": "备注", "references": "关联来源",
   "situation": "使用场景", "behaviors": "核心行为", "behavior": "行为", "inputs": "输入", "input": "输入",
   "outputs": "结果", "output": "结果", "limits": "范围边界", "limit": "边界", "exceptions": "异常处理", "exception": "异常情况", "condition": "发生条件", "response": "处理方式",
-  "guidance": "按分组浏览功能，调整说明和优先级；新增功能会交给主对话继续完善。",
-  "applicationMindMap": "应用功能脑图",
+  "guidance": "检查功能是否覆盖用户要完成的事情，有无遗漏、重复或超出范围；调整不准确的说明和优先级。",
   "createRequest": "请新增以下功能",
   "createSubmit": "AI 智能添加",
   "detailsAndEvidence": "功能详情"

package/payload/shared/bundles/function_modules/panel.yaml

@@ -72,7 +72,7 @@ ui:
   guidance: "$t:guidance"
   sidebar_icon: blocks
   id: function-board
-  title: $t:applicationMindMap
+  title: $t:functions
   source: functions
   board:
     request_create:

package/payload/shared/bundles/integration_design/locales/en-US.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "Describe the connection's purpose, then add verified information and usage instructions. Do not enter real secrets.",
+  "guidance": "Check what each external connection exchanges, why it is needed and what happens on failure. Add actual interface references, without entering real secrets.",
   "bundleDescription": "- **Capability**: design each product-relevant external connection as a complete new Plugin, with concise product-side notes.\n- **Resolves**: S/T gaps around which external capability the product needs, how the Agent accesses and uses it, and what the product does when the connection succeeds or fails.\n- **Candidate when**: a product behavior depends on an external API, webhook, SDK, MCP tool, third-party component, device, or team-operated system.\n- **Do not infer**: never invent vendor behavior, URL, credential, endpoint, or field-level API contract.\n- **Output**: `integration_design` panel — one editable Plugin-style connection record plus product-side remarks for every external capability.",
   "empty": "No integrations yet. Add connection instructions and product-side rules as needed.",
   "integrations": "System integrations",

package/payload/shared/bundles/integration_design/locales/zh-CN.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "先说明外部连接的目的，再补充真实资料和调用提示；不要填写真实密钥。",
+  "guidance": "核对每个外部连接要交换什么、为何需要，以及失败时如何处理；补充真实接口资料，不填写真实密钥。",
   "bundleDescription": "- **能力**：把每项与产品相关的外部连接设计成完整的新 Plugin，并附上简洁的产品侧说明。\n- **解决**：产品需要哪种外部能力、Agent 如何访问和使用它，以及连接成功或失败时产品如何处理等 S/T 类缺口。\n- **适用时机**：产品行为依赖外部 API、Webhook、SDK、MCP 工具、第三方组件、设备或团队运营的系统。\n- **不要推断**：绝不凭空编造供应商行为、URL、凭证、端点或字段级 API 约定。\n- **输出**：`integration_design` 面板，为每项外部能力提供一条可编辑的 Plugin 风格连接记录和产品侧备注。",
   "empty": "还没有系统集成。根据产品需要添加接入说明和业务规则。",
   "integrations": "系统集成",

package/payload/shared/bundles/notification_design/locales/en-US.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "Specify when to notify whom, through which channel, and the next action. The content preview does not send notifications.",
+  "guidance": "Check that the trigger, recipients and channel are appropriate and that the message helps them take the next action. Previewing content does not send a notification.",
   "bundleDescription": "- **Capability**: decide when an established business moment should proactively reach which people, through which human channel, with what useful message and next action.\n- **Resolves**: S/T gaps where a user could miss a material approval, deadline, exception, handoff, or completed result while not looking at the relevant page.\n- **Candidate when**: an established flow contains waiting, handoff, deadline, exception, or material status change and somebody must know or act without already being on that page.\n- **Do not infer**: every state change needs a notification; page feedback, dashboards, reports, exports, audit history, machine webhooks, and final marketing copy belong elsewhere.\n- **Output**: `notification_design` panel — an ordered, editable set of proactive notification moments.",
   "empty": "Add a notification: when it appears, who receives it, which channel is used and what it says.",
   "notifications": "Notifications",

package/payload/shared/bundles/notification_design/locales/zh-CN.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "写清何时通知谁、通过什么渠道以及下一步行动；内容预览不会发送通知。",
+  "guidance": "核对触发时机、接收人和渠道是否合适，信息能否帮助对方采取下一步行动；内容预览不会发送通知。",
   "bundleDescription": "- **能力**：确定已经建立的业务时刻应在何时、通过哪种人工渠道、向哪些人主动发送什么有用信息和下一步操作。\n- **解决**：用户未停留在相关页面时可能错过重要审批、截止日期、异常、交接或完成结果的 S/T 类缺口。\n- **适用时机**：已建立的流程包含等待、交接、截止、异常或重要状态变化，且有人必须及时知晓或行动。\n- **不要推断**：并非每次状态变化都需要通知；页面反馈、仪表盘、报表、导出、审计历史、机器 Webhook 和最终营销文案不属于这里。\n- **输出**：包含一组有序、可编辑的主动通知时刻的 `notification_design` 面板。",
   "empty": "添加一个通知时刻，说明何时、向谁、通过什么渠道传达什么信息。",
   "notifications": "通知时刻",

package/payload/shared/bundles/page_design/locales/en-US.json

@@ -29,6 +29,6 @@
   "hotspotLabel": "Source hotspot label",
   "members": "Pages in group",
   "map": "Page map",
-  "guidance": "Select a page to preview it or a connection to edit navigation. Map positions and groups organize the map only.",
+  "guidance": "Walk through the user task and check that page content, actions and navigation form a coherent path without gaps or dead ends. Map positions and groups only organize the view.",
   "shared": "Shared specification"
 }

package/payload/shared/bundles/page_design/locales/zh-CN.json

@@ -29,6 +29,6 @@
   "hotspotLabel": "源热点说明",
   "members": "分区内页面",
   "map": "页面地图",
-  "guidance": "选择页面看预览，选择连线改跳转；地图位置和分区只影响地图组织。",
+  "guidance": "从用户要完成的任务出发，检查页面内容、操作和跳转是否连贯，有没有遗漏或死路；地图位置和分区只影响组织方式。",
   "shared": "公共规格"
 }

package/payload/shared/bundles/quality_acceptance/locales/en-US.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "Describe the acceptance scenario and an observable passing result. Add a verification method only when unclear; test code is not required.",
+  "guidance": "Check whether each acceptance item has a clear situation and an observable passing result. Add a checking method only when it is unclear; test code is not required.",
   "bundleDescription": "- **Capability**: define the small set of observable requirements that tell users and the delivery team when established product behavior and material quality are good enough to accept.\n- **Resolves**: T gaps where an important function, rule, flow, page, or integration has no concrete passing result, or a material quality expectation remains vague.\n- **Candidate when**: the user asks for acceptance criteria, quality requirements, non-functional requirements, or a clear definition of done for product behavior.\n- **Do not infer**: business rules, missing product behavior, test code, release governance, project plans, risk registers, or a generic enterprise NFR checklist do not belong here.\n- **Output**: `quality_acceptance` panel — one editable ordered list of acceptance requirements.",
   "empty": "Add an acceptance requirement: describe the situation and the outcome that counts as success.",
   "requirements": "Acceptance requirements",

package/payload/shared/bundles/quality_acceptance/locales/zh-CN.json

@@ -1,5 +1,5 @@
 {
-  "guidance": "写清验收情境和可观察的通过结果；检查方法不明显时再补充，不必写测试代码。",
+  "guidance": "检查每项验收是否有明确情境和可观察的通过结果，能否据此判断做对了；检查方法不明显时再补充，无需编写测试代码。",
   "bundleDescription": "- **能力**：定义一小组可观察的要求，让用户和交付团队判断既定产品行为及重要质量是否足以验收。\n- **解决**：重要功能、规则、流程、页面或集成缺少具体通过结果，或重要质量期望仍模糊时的 T 类缺口。\n- **适用时机**：用户要求验收标准、质量要求、非功能要求，或产品行为清晰的完成定义。\n- **不要推断**：业务规则、缺失的产品行为、测试代码、发布治理、项目计划、风险登记表或泛化的企业 NFR 清单不属于这里。\n- **输出**：包含有序验收要求列表的可编辑 `quality_acceptance` 面板。",
   "empty": "添加一项验收要求，说明在什么情况下，出现什么结果才算通过。",
   "requirements": "验收要求",