yugoo-design 0.2.6 → 0.2.8

package/payload/overlays/codex/authoring/studio-creators/source/docs/system-design-baseline.md

@@ -101,7 +101,7 @@ Every host assembles the same instruction layers in this order: the host's own b
 
 DeepSeek Harness registers these layers and tools as native Cordis plugin contributions and embeds the shared Design UI in the Web application. Its Host Provider uses `agent.inject()` for durable, non-waking model context, exposes `ctx.userQuestions` for an in-turn blocking question when Bundle policy or the Agent requires native ask-user, creates each required Producer through the public Agent factory, and exposes native nested delegation to that Producer as an optional acceleration capability. It supplies package-owned `dsh.client` modules plus Remote services for the Design panel and Studio. Persistent asynchronous continuation is presented by the plugin continuation UI, and acceptance enters as an ordinary logged user turn; advisory dispositions remain plugin-owned review decisions rather than `ctx.userQuestions` interactions. The provider resolves the active Design Project through the Design System binding store instead of a Design Project, Kit, Design File, or clarity projection. Its standard `designAdvisoryInbox` projection is only a refresh/read-model mechanism and is not Design authority. CLI adapters render clarity and lifecycle state as deterministic text.
 
-Every embedded client stylesheet participates in the Host's plugin-module lifecycle. The DSH provider tags its Panel-shell, trusted-provider, and third-party panel styles with the owning `dsh.client` plugin id at module materialization, so reload and HMR replace the complete style set atomically. A late injected service scope must not privately create or dispose global stylesheet tags; provider-specific styling and shared Panel chrome cannot therefore disappear independently. Component-local inline styles remain permissible only when their DOM lifetime intentionally owns them.
+Every embedded client stylesheet participates in the Host's plugin-module lifecycle. The DSH provider tags its Panel-shell, trusted-provider, and third-party panel styles with the owning `dsh.client` package id, including its published scope, so reload and HMR replace the complete style set atomically. This ownership metadata is distinct from stable Cordis and RPC identities. On materialization, an existing tag with the same stylesheet key receives the current text and package owner; its presence alone must not retain an older revision. Independent ESM renderers retain explicit stylesheet ownership outside synchronous Host factory materialization. A late injected service scope must not privately create or dispose global stylesheet tags; provider-specific styling and shared Panel chrome cannot therefore disappear independently. Component-local inline styles remain permissible only when their DOM lifetime intentionally owns them.
 
 Codex and Claude Code integrations begin with capability discrimination, not assumed native APIs. Each adapter proves which session identity, tool, filesystem, human-question, Agent, nested-delegation, and UI capabilities are available in the installed Host version and selects only supported mappings. MCP, Skills, hooks, commands, or a companion browser may carry those mappings. Subagent placement requires an isolated Producer runtime; main placement requires equivalent invocation-scoped Design capabilities in the existing conversation. An adapter must reject an unsupported requested placement, not silently replace it. Nested delegation remains a separate optional capability. Detached execution negotiation applies only to G/R/A advisories. These presentation and execution differences cannot change selection, validation, publication, foreground attachment, or handoff semantics.
 

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/SKILL.md

@@ -218,8 +218,10 @@ with pending records; never claim it is complete
 before the BPMN artifacts settle.
 
 1. **PLAN.** FIRST decide the product-wide role cast. It includes the built-in
-   `{"id":"System","name":"系统"}` role whenever the product has an active
-   responsibility in the process. THEN maintain ALL process
+   role with stable `id: "System"` whenever the product has an active
+   responsibility in the process. Its canonical display name follows the authored
+   language (`系统` in the Chinese example below, `System` in English); IDs and
+   display names remain unique. THEN maintain ALL process
    descriptors in ONE complete canonical state. The
    cast is decided once so every process + BPMN lane reuses the SAME names
    (no 主管/审批主管 drift). `process.stakeholders` MUST be drawn from
@@ -287,7 +289,8 @@ policy. G/R/A owns ongoing cross-Bundle drift detection after this check.
 - The plan must carry COMPLETE descriptors (description, stakeholders,
   system_responsibilities, trigger_hints, business_rules, exception_handling)
   — BPMN is authored only from this established state and the role cast.
-- Every active process includes `系统` and at least one concrete
+- Every active process includes the canonical display name of role `id: "System"`
+  and at least one concrete
   `system_responsibilities` item. If the product has no responsibility in the
   procedure, omit that procedure rather than drawing human-only choreography.
 - `trigger_hints` records only established asynchronous or event-waiting
@@ -364,7 +367,7 @@ when no exception is established.
 - **Element ids without process prefix** — causes id collisions when multiple processes render together. Always use `{ElementType}_{process_id}_{num}`.
 - **Process without a start or end event** — BPMN requires both. Every process has exactly one `<bpmn:startEvent>` and at least one `<bpmn:endEvent>`.
 - **Infrastructure "processes"** — do NOT propose processes for deployment, server setup, database migrations, CI/CD, log rotation, etc. Those are platform-managed. Only propose product user-facing / business-facing behavior.
-- **Human-only procedure presented as a product flow** — every process must reveal an actual product responsibility in the `系统` role.
+- **Human-only procedure presented as a product flow** — every process must reveal an actual product responsibility in the role with stable `id: "System"`, using its canonical display name.
 - **Known automation flattened into generic tasks** — state product work in `system_responsibilities`; author it with the appropriate BPMN activity type.
 - **Decorative BPMN events** — only express timer/message/error/conditional/signal facts established in `trigger_hints`.
 - **Inventing stakeholder roles not mentioned by the user** — use a generic name only for an evidenced participant; neither an organization title nor `管理员` is a default extra actor.

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/reference/artifact-contract.md

@@ -6,10 +6,14 @@ new design and reconstruction without replacing domain-specific rules.
 
 Shared by authoring and reconstruction; convert established behavior into BPMN without inventing policy. Canonical state is `flow_design/flow_design.json`; active processes are listed by `process_order`, stakeholders reuse `roles[].name`. The installed schema/validation are unchanged.
 
-For product automation, the existing built-in role is
-`{"id":"System","name":"系统"}`. `System` is its ID, not its stakeholder or
-lane label: process stakeholders and BPMN lanes use the exact name `系统`.
-Check this in the canonical plan as well as the XML before accepting a file.
+For product automation, keep exactly one built-in role with stable `id: "System"`
+and a non-empty display name in the authored language, for example
+`{"id":"System","name":"系统"}` in Chinese or
+`{"id":"System","name":"System"}` in English. Role IDs and display names
+remain unique. Process stakeholders and BPMN lanes reuse the exact canonical
+`roles[].name`; resolve the product's display name by its `System` ID, never by
+a translated-name whitelist or lane ID. Check the cast, participating roles and
+automated/human task ownership before accepting a file.
 
 Bind serial/delegated activity using `artifact_kind: "flow_bpmn"`, the stable process ID and `artifact_file: "flow_design/<process_id>.bpmn"`. A Worker receives the matching process descriptor, focused evidence and this shared contract; the Producer integrates its returned file reference.
 
@@ -25,10 +29,13 @@ model tool arguments.
 Validate the file with `run_skill_script`: use `path: "bpmn-validator.mjs"`,
 `args: ["validate-bpmn-file"]`, `input_file` equal to the pre-bound BPMN path,
 and `input_context` containing
-`{"process_id":"P-...","process":{...}}`. The bounded `process` object is the
+`{"process_id":"P-...","process":{...},"roles":[...]}`. `roles` is the existing
+canonical role cast, not a new process field. The bounded `process` object is the
 matching canonical descriptor; it needs the supplied stakeholders,
 system_responsibilities, trigger_hints, and process_type. The validator returns
 only validity and diagnostics. Repair the same file and retry until it passes.
+Older calls without `roles` retain the original Chinese system-lane semantics;
+always include the canonical cast for new or revised localized files.
 
 Next call `run_skill_script` with `path: "layout.mjs"`, the same `input_file`, no
 args, and `output_file` equal to that same BPMN path. On exit 0 the Host writes the

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/reference/bpmn_authoring.md

@@ -26,9 +26,11 @@ not useful.
 
 ## Product boundary and lanes
 
-`系统` is the product being designed, not an invented organization role. The
-brief always states its grounded responsibilities. Realize those
-responsibilities in the `系统` lane; if a proposed process has no product
+The role with stable `id: "System"` is the product being designed, not an invented
+organization role. Its display name comes from the supplied canonical cast
+(`系统` in the Chinese example below, `System` in English). The brief always
+states its grounded responsibilities. Realize those responsibilities in that
+role's exact display-name lane; if a proposed process has no product
 responsibility, it should not have reached this worker.
 
 For two or more participating roles, create exactly one lane per supplied role
@@ -57,14 +59,15 @@ decoration and do not flatten known semantics into generic tasks.
 |---|---|
 | Human works in/with the product | `userTask` in that human role lane |
 | Human performs offline work | `manualTask` in that human role lane |
-| Product runs an automated operation | `serviceTask` in `系统` |
-| Product evaluates a stated decision table/rule | `businessRuleTask` in `系统` |
-| Product sends a message/notification | `sendTask` in `系统` |
-| Product waits for a message | `receiveTask` in `系统` |
+| Product runs an automated operation | `serviceTask` in the System role lane |
+| Product evaluates a stated decision table/rule | `businessRuleTask` in the System role lane |
+| Product sends a message/notification | `sendTask` in the System role lane |
+| Product waits for a message | `receiveTask` in the System role lane |
 | Evidence does not distinguish a more specific activity | `task` |
 
-Never place `userTask`/`manualTask` in `系统`. Never place
-`serviceTask`/`businessRuleTask`/`sendTask`/`receiveTask` in a human lane.
+Never place `userTask`/`manualTask` in the System role lane, and do not use a generic
+`task` for its automated responsibility. Never place
+`serviceTask`/`businessRuleTask`/`scriptTask`/`sendTask`/`receiveTask` in a human lane.
 
 Use gateways by their actual control-flow semantics:
 
@@ -184,7 +187,7 @@ the structure to the brief; never copy its business facts or ids blindly.
 2. All ids are ASCII and process-prefixed; all references resolve.
 3. Lane names exactly match supplied stakeholders; every node belongs to one
    responsible lane.
-4. `系统` responsibilities are typed system activities; human work stays in
+4. The System role's responsibilities are typed system activities; human work stays in
    human lanes.
 5. Every supplied trigger hint is realized, and no ungrounded trigger appears.
 6. Exclusive outcomes are named; parallel/event-driven shapes use the matching

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/reference/canvas-guide.md

@@ -19,7 +19,8 @@ uses the existing SKILL's product-boundary and process-granularity methods.
 Use the installed Bundle's structure-validation → layout → final-validation
 pipeline by file path. The layout script produces BPMN DI; never hand-author a
 second layout or patch truncated output. Lane labels use actual supplied names;
-the built-in System ID and the exact lane/stakeholder name follow the contract.
+resolve the built-in System display name from its stable ID in the canonical
+role cast, and pass that cast to both file validators as the contract specifies.
 Ports/bindings and routing remain BPMN/layout behavior, not the AI midpoint rule.
 Review readable node/condition labels and real branch/return meaning; valid DI
 does not prove readability or correct process semantics. Missing sources stay

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/schema.yaml

@@ -21,7 +21,7 @@ properties:
       type: object
       properties:
         id: { type: string }     # ASCII slug for lane ids, e.g. "Buyer"
-        name: { type: string }   # Chinese display name, e.g. "采购员"
+        name: { type: string }   # Canonical display name in the authored language, e.g. "采购员" or "Buyer"
   processes:
     type: map
     value:

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/function_modules/reference/artifact-contract.md

@@ -75,6 +75,11 @@ do not send it to a differently pinned validator or rewrite its retained state.
 }
 ```
 
+- Optional `function_order` holds function map keys in the user’s chosen reading order.
+  Preserve it during revisions, remove deleted keys and append new keys without
+  changing unaffected positions. If absent, existing map order is used; the Panel
+  writes an order only when the user actually moves a card. Grouping still comes
+  from `function_epic`, not another membership list.
 - `function_id`, `function_name`, `function_description`, `function_epic`
   are required for every function. `priority` is optional (panel default Medium).
 - `rejected` means the user rejected the function. It remains visible in the

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/function_modules/reference/preview.json

@@ -1,4 +1,5 @@
 {
+  "function_order": ["F-PREVIEW-001", "F-PREVIEW-002"],
   "functions": {
     "F-PREVIEW-001": {
       "function_id": "F-PREVIEW-001",

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/function_modules/schema.yaml

@@ -10,6 +10,10 @@ type: object
 additional_properties: false
 properties:
   skill_name: { knowledge: { role: metadata }, type: string }
+  function_order:
+    knowledge: { role: metadata }
+    type: array
+    items: { type: string }
   functions:
     type: map
     value:

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/smart_questions/SKILL.md

@@ -58,8 +58,10 @@ The question panel remains the interaction surface: put a concise proposal,
 its useful context and the decision to make in the card's `prompt`, with
 appropriate `choices` or free-text input. Do not put the proposed answer into
 the user's `answer` or use `detail` as a substitute for visible question text.
-In forward design, leave new `detail` empty unless it preserves an actual
-user-supplied explanation or a faithful summary of explicit user evidence.
+Free-text questions have one response field: `answer`. Keep their `detail`
+empty; any user-supplied explanation belongs with that answer. Choice questions
+may use `detail` for an actual user-supplied explanation or a faithful summary
+of explicit user evidence. Do not generate a second response area for free text.
 Put your proposed scope, rationale, examples and unresolved questions in
 `prompt`, not in user-response fields. Your earlier proposal, a Producer brief,
 and another Agent's summary do not establish that the user said or confirmed

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/smart_questions/reference/artifact-contract.md

@@ -60,8 +60,11 @@ overview from representative entry points and user journeys, then include only
 material supporting context. Do not ask the user how many Bundles to scan, or
 replace the overview with component, SEO, billing or deployment inventories.
 
-Put a concise source-supported answer in `answer`; use `detail` for exact
-source locations, observation versus supported inference, and remaining limits.
+Put a concise source-supported answer in `answer`. For a free-text question,
+keep source locations, observation versus supported inference and remaining
+limits with that answer; leave `detail` empty. A choice question may use its
+optional `detail` for those qualifications. Free text has no separate supplement
+input or historical supplement display.
 A supported interpretation may explain the overall product, but label it as
 inferred, not stated user intent. Do not infer commercial positioning or target
 audience merely from the presence of an admin route or a technical capability.
@@ -70,8 +73,9 @@ Reconstruction prefill is reviewable, not user confirmation; it is not a license
 to guess answers during ordinary questioning.
 
 If evidence supports part of the answer, retain that part and identify remaining
-unknowns in `detail`. Split independent topics rather than let one known fact
-mask a separate unknown. Leave genuinely unsupported answers empty. Missing
+unknowns in the same answer (or `detail` for a choice). Split independent topics
+rather than let one known fact mask a separate unknown. Leave genuinely
+unsupported answers empty. Missing
 information in one summary document is not proof of absence in the repository:
 inspect a relevant source when the missing fact matters. Preserve user answers
 and explain conflicting source evidence without replacing their decisions.
@@ -79,8 +83,9 @@ and explain conflicting source evidence without replacing their decisions.
 Before closing, read the cards as a whole: can a reader understand the product's
 purpose, intended users, main scenario and scope to the extent the source permits?
 Are later details supporting that account rather than displacing it? Check that
-`detail` does not contain a verified answer missing from `answer`, that unknowns
-remain honest, and that each inference is supported. This is an Agent self-check,
+free-text `detail` is empty, choice `detail` does not contain a verified answer
+missing from `answer`, unknowns remain honest, and each inference is supported.
+This is an Agent self-check,
 not a new validator or host gate.
 
 ## Fixed-card contract
@@ -172,7 +177,7 @@ existing panel, carry the fixed-card definition and prior user decisions
 forward into the complete canonical state without adding them to the new round.
 
 - `value` is the stable selection token. `label` is visible text. Answers always store `value`, never a label, recommendation suffix, or invented internal token.
-- `single` stores one `value`; `multiple` stores comma-separated `value`s; `text` stores its substantive free-text response in `answer` and has no choices. A known answer must not exist only in `detail`; the answer should remain understandable without opening the supplementary explanation.
+- `single` stores one `value`; `multiple` stores comma-separated `value`s; `text` stores its complete free-text response in `answer`, has no choices and leaves `detail` empty. The answer, including useful qualifications, is read and edited in one place.
 - `recommended` is the only recommendation mechanism. Do not add a question-level `suggest` field or append `(推荐)` to stored labels.
 - Dynamic-card `round` controls the FE's round grouping; the latest round renders
   first. Assign a nonnegative integer explicitly: use 0 for the first dynamic
@@ -183,7 +188,10 @@ forward into the complete canonical state without adding them to the new round.
   values to 0 and truncates fractions for grouping only. Preserve those saved
   values on unrelated edits rather than silently renumbering history. Fixed
   cards do not participate in round-number allocation.
-- `detail` records the user's optional explanation, constraints, or source/provenance notes in reconstruction; it supplements rather than duplicates the answer. Preserve older detail-only records without automatically promoting uncertainty or provenance into an answer. When the user answers
+- For a choice question, `detail` records the user's optional explanation,
+  constraints or source/provenance notes in reconstruction; it supplements rather
+  than duplicates the selection. It is not a second field for free-text questions.
+  Preserve unrelated saved data without automatic answer conversion. When the user answers
   a choice question with wording that does not match a rendered option, keep
   `answer` empty and preserve the exact wording in `detail`; never replace it
   with a recommended option. On dynamic cards, `rejected` means the user

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/smart_questions/schema.yaml

@@ -66,8 +66,8 @@ properties:
         # in reconstruction belong here too, without implying user confirmation.
         # Leave genuinely unknown answers empty; never promote a proposal as an answer.
         answer: { type: string }
-        # Optional supplementary explanation, constraints or source locations.
-        # Do not put a known text answer only here. A choice response outside the
+        # Optional choice-question explanation, constraints or source locations.
+        # Text questions use only answer and leave detail empty. A choice response outside the
         # available options may be preserved here without inventing a selection.
         # Supplementary detail alone does not mark the question answered.
         detail: { type: string }

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/web_app_prd_assembly/SKILL.md

@@ -291,6 +291,10 @@ enters Git history, G/R/A owns ongoing cross-Bundle drift checks.
 
 ### 4. Finalize inside the same agentic loop
 
+Keep `<html lang>` in the authored document's language. Fixed visual labels use
+that language as described in the shared contract; source business names remain
+unchanged and switching the Host UI does not translate the document.
+
 Once prose and provenance are complete, run the shared contract’s file-mode finalization against the already-written HTML. Do not rewrite the document or transport visual bytes through model context.
 
 If the script reports diagnostics, preserve valid content, apply the smallest

package/payload/overlays/codex/authoring/studio-creators/source/packages/skills-web-app/bundles/web_app_prd_assembly/reference/artifact-contract.md

@@ -115,6 +115,12 @@ use file-mode scripts for transforms and final checks.
 
 ## File-mode finalization
 
+Keep the document's `<html lang>` aligned with its authored language. The visual
+script uses this existing language for fixed map captions, navigation legends
+and empty-state labels (`en`/`en-*` use English; existing Chinese/default output
+is retained otherwise). It does not translate source business text or follow
+the Host UI language. Materialization and validation use the same document language.
+
 Once the prose and provenance are complete, process the already-written HTML;
 do not rewrite it for finalization. First call `run_skill_script` with
 `path: "prd.mjs"`, `args: ["materialize-visuals"]`, and both `input_file` and

package/payload/overlays/qoder/.qoder-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "yugoo-design",
-  "version": "0.2.6",
+  "version": "0.2.8",
   "description": "Yugoo Design: interactive Design Panels with Qoder-native Producers, Workers and background reviews."
 }