yugoo-design 0.1.2 → 0.2.0

package/payload/desktop-preparation/studio-authoring-template/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/reference/bpmn_authoring.md

@@ -0,0 +1,200 @@
+# BPMN authoring contract
+
+This is the authoritative contract for one `flow_design` BPMN artifact. The
+foreground Producer reads it for serial authorship and supplies it with any
+bounded delegated assignment. A Worker writes only its exact pre-bound BPMN
+file, runs the Bundle layout and final validator, and repairs it in the same
+active Worker loop. The Producer reads the landed file receipt and updates
+canonical JSON, or authors and repairs the same XML itself when delegation is
+not useful.
+
+## Output boundary
+
+- Output one complete `<bpmn:definitions>` document containing exactly one
+  `<bpmn:process>`.
+- Author structure first. The same Agent then runs the Bundle layout script and
+  persists its `bpmndi:*`, `dc:*`, and `di:*` output as the final file.
+- Use Chinese for visible `name` values and ASCII-only machine ids.
+- Every node and sequence-flow id uses `{ElementType}_{process_id}_{number}`.
+  Every lane id uses `Lane_{process_id}_{number}`. Role names belong only in
+  lane `name`, never in ids.
+- Include exactly one start event and at least one named end event. Every
+  `sourceRef`, `targetRef`, and `flowNodeRef` resolves inside this process.
+- Every flow node is reachable from that start and every active path reaches a
+  named end. Do not place a disconnected admin/maintenance mini-flow beside
+  the main narrative; make it a separate material process or omit it.
+
+## 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
+responsibility, it should not have reached this worker.
+
+For two or more participating roles, create exactly one lane per supplied role
+and put every flow node in exactly one lane. For a single-role process, omit the
+laneSet. Cross-lane sequence flows are valid.
+
+Inside a lane, refer to an independently defined node only as:
+
+```xml
+<bpmn:flowNodeRef>ExclusiveGateway_P-001_1</bpmn:flowNodeRef>
+```
+
+Never turn an id into a tag name:
+
+```xml
+<!-- Invalid: this is not a BPMN element type. -->
+<bpmn:exclusiveGateway_P-001_1 />
+```
+
+## Choose semantic nodes from evidence
+
+Use the most specific evidenced BPMN node. Do not use richer glyphs merely as
+decoration and do not flatten known semantics into generic tasks.
+
+| Business meaning | BPMN element |
+|---|---|
+| 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 `系统` |
+| Evidence does not distinguish a more specific activity | `task` |
+
+Never place `userTask`/`manualTask` in `系统`. Never place
+`serviceTask`/`businessRuleTask`/`sendTask`/`receiveTask` in a human lane.
+
+Use gateways by their actual control-flow semantics:
+
+- `exclusiveGateway`: exactly one outcome proceeds. Name the gateway as a
+  question and every outgoing branch as its concrete answer.
+- `parallelGateway`: concurrent split or synchronization join. A process with
+  `process_type=parallel` must show the explicit split and, where the branches
+  synchronize, its matching join.
+- `eventBasedGateway`: wait for the first of at least two evidenced events.
+  Every outgoing flow targets an `intermediateCatchEvent` or `receiveTask`.
+- Do not substitute an exclusive gateway for parallel or event-race behavior.
+
+Start from the happy path, then add only grounded decisions, exceptions, and
+feedback paths. Keep splits and joins explicit. Do not invent a timeout,
+message, error, condition, or signal that is absent from `trigger_hints`.
+
+Before the first file mutation, settle a compact inventory of lanes, semantic
+nodes, event definitions, and sequence paths against the canonical process
+descriptor. Write one coherent structure-only BPMN candidate. After a
+validator diagnostic, repair the existing candidate with a targeted edit;
+do not repeatedly replace the whole file merely to reconsider modeling that
+should have been resolved from the descriptor first.
+
+## Trigger hints become event definitions
+
+Every trigger hint in the brief must appear as the matching event definition
+on an appropriate start/intermediate/boundary/end event:
+
+| `trigger_hints[].kind` | Required definition |
+|---|---|
+| `timer` | `timerEventDefinition` |
+| `message` | `messageEventDefinition` |
+| `error` | `errorEventDefinition` |
+| `conditional` | `conditionalEventDefinition` |
+| `signal` | `signalEventDefinition` |
+
+This table applies only after the plan has classified a fact as a genuine
+event. Do not use `trigger_hints` for an ordinary gateway condition or for a
+deterministic effect of the preceding task. For example, “mark closed, then
+archive” is a service task followed by another service task (or one combined
+service task), not a conditional catch event. A conditional event is
+appropriate only when the process independently waits for or observes a
+condition that may become true outside the immediately preceding activity.
+
+A boundary event is active only while its attached activity is active. Attach
+a timer to the long-running wait, review, approval, or receive activity whose
+duration it monitors. Never attach a timeout to an instantaneous task that
+merely initializes status; the timer would cease to exist as soon as that task
+finishes.
+
+Example timeout structure (adapt the ids and semantics; do not copy blindly):
+
+```xml
+<bpmn:userTask id="UserTask_P-001_2" name="确认支付" />
+<bpmn:boundaryEvent id="BoundaryEvent_P-001_1" name="等待支付超时"
+                    attachedToRef="UserTask_P-001_2" cancelActivity="true">
+  <bpmn:timerEventDefinition id="TimerEventDefinition_P-001_1">
+    <bpmn:timeDuration>PT24H</bpmn:timeDuration>
+  </bpmn:timerEventDefinition>
+</bpmn:boundaryEvent>
+```
+
+Only encode a concrete duration/expression when the brief provides it. A
+trigger is incomplete unless its sequence path reaches the supplied expected
+outcome.
+
+## Compact complete example
+
+This example demonstrates lane references and typed human/system work. Adapt
+the structure to the brief; never copy its business facts or ids blindly.
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
+                  id="Definitions_P-001"
+                  targetNamespace="http://bpmn.io/schema/bpmn">
+  <bpmn:process id="Process_P-001" name="请假审批" isExecutable="false">
+    <bpmn:laneSet id="LaneSet_P-001">
+      <bpmn:lane id="Lane_P-001_1" name="员工">
+        <bpmn:flowNodeRef>StartEvent_P-001_1</bpmn:flowNodeRef>
+        <bpmn:flowNodeRef>UserTask_P-001_1</bpmn:flowNodeRef>
+      </bpmn:lane>
+      <bpmn:lane id="Lane_P-001_2" name="直属领导">
+        <bpmn:flowNodeRef>UserTask_P-001_2</bpmn:flowNodeRef>
+        <bpmn:flowNodeRef>ExclusiveGateway_P-001_1</bpmn:flowNodeRef>
+      </bpmn:lane>
+      <bpmn:lane id="Lane_P-001_3" name="系统">
+        <bpmn:flowNodeRef>SendTask_P-001_1</bpmn:flowNodeRef>
+        <bpmn:flowNodeRef>SendTask_P-001_2</bpmn:flowNodeRef>
+        <bpmn:flowNodeRef>EndEvent_P-001_1</bpmn:flowNodeRef>
+        <bpmn:flowNodeRef>EndEvent_P-001_2</bpmn:flowNodeRef>
+      </bpmn:lane>
+    </bpmn:laneSet>
+    <bpmn:startEvent id="StartEvent_P-001_1" name="员工准备申请" />
+    <bpmn:userTask id="UserTask_P-001_1" name="填写请假申请" />
+    <bpmn:userTask id="UserTask_P-001_2" name="审批请假申请" />
+    <bpmn:exclusiveGateway id="ExclusiveGateway_P-001_1" name="是否通过" />
+    <bpmn:sendTask id="SendTask_P-001_1" name="发送通过通知" />
+    <bpmn:sendTask id="SendTask_P-001_2" name="发送驳回通知" />
+    <bpmn:endEvent id="EndEvent_P-001_1" name="通过结果已送达" />
+    <bpmn:endEvent id="EndEvent_P-001_2" name="驳回结果已送达" />
+    <bpmn:sequenceFlow id="SequenceFlow_P-001_1" sourceRef="StartEvent_P-001_1" targetRef="UserTask_P-001_1" />
+    <bpmn:sequenceFlow id="SequenceFlow_P-001_2" sourceRef="UserTask_P-001_1" targetRef="UserTask_P-001_2" />
+    <bpmn:sequenceFlow id="SequenceFlow_P-001_3" sourceRef="UserTask_P-001_2" targetRef="ExclusiveGateway_P-001_1" />
+    <bpmn:sequenceFlow id="SequenceFlow_P-001_4" name="通过" sourceRef="ExclusiveGateway_P-001_1" targetRef="SendTask_P-001_1" />
+    <bpmn:sequenceFlow id="SequenceFlow_P-001_5" name="驳回" sourceRef="ExclusiveGateway_P-001_1" targetRef="SendTask_P-001_2" />
+    <bpmn:sequenceFlow id="SequenceFlow_P-001_6" sourceRef="SendTask_P-001_1" targetRef="EndEvent_P-001_1" />
+    <bpmn:sequenceFlow id="SequenceFlow_P-001_7" sourceRef="SendTask_P-001_2" targetRef="EndEvent_P-001_2" />
+  </bpmn:process>
+</bpmn:definitions>
+```
+
+## Final self-check before submit
+
+1. One connected process, one start, at least one named end. The structure input
+   has no DI/layout elements; the final file has the layout script's DI output.
+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
+   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
+   gateways.
+7. Follow [artifact-contract.md](artifact-contract.md) to validate, lay out and
+   validate the final file in place. Repair that file in the active author loop;
+   return its receipt, not the complete XML through model messages. A serial
+   Producer follows the same repair loop directly.
+   Treat XML parser diagnostics as local syntax defects: repair the reported
+   token, closing tag, attribute, or namespace without deleting established
+   triggers, events, branches, roles, or system responsibilities. A candidate
+   passes only when its BPMN semantics still realize the canonical process
+   descriptor after syntax repair.

package/payload/desktop-preparation/studio-authoring-template/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/reference/canvas-guide.md

@@ -0,0 +1,39 @@
+# BPMN process canvas
+
+Shared design/reconstruction entry. Preserve the complete [flow output
+contract](artifact-contract.md) and [BPMN authoring contract](bpmn_authoring.md).
+They remain the exact format, lane grammar, node semantics, example and file
+validation/layout authorities. This guide is an index, not a parallel BPMN spec.
+
+## Sources and semantics
+
+`flow_design/flow_design.json` owns the plan/order and accepted BPMN file refs;
+each bound `flow_design/<process_id>.bpmn` owns that diagram. Use established
+triggers, supplied role names and product behavior, not invented automation.
+Processes/lane participants/tasks/events/gateways/flows retain BPMN meanings.
+For reconstruction preserve observed policy and exceptions; ordinary design
+uses the existing SKILL's product-boundary and process-granularity methods.
+
+## Layout, routing, labels and missing evidence
+
+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.
+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
+unknown; a plan path is not an accepted file. Do not invent a task merely for
+lane balance or treat dense real flows as permission to remove branches.
+
+## Interaction, saving and acceptance
+
+The `diagram_workspace` reads the canonical descriptor and exact BPMN artifact;
+describe only the installed editor's supported actions. Serial authors/Workers
+validate/repair their own bound file; the owning executor integrates the accepted
+ref and uses existing publication. XML never becomes an inline JSON graph.
+Read the existing complete example in `bpmn_authoring.md`; no new sample authority.
+Check invalid XML, bad role/lane/endpoint semantics and missing/final-DI failure
+through the actual validators. With an available view inspect one meaningful
+branch/return and resize/readable zoom; report parser/layout, rendered review,
+save/reopen and native execution separately. Do not claim process execution.

package/payload/desktop-preparation/studio-authoring-template/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/schema.yaml

@@ -0,0 +1,61 @@
+# flow_design Design Files data contract (write-time validation).
+# Faithful declarative translation of sdk-pilot
+# skill/design_skills/flow_design/schema.py (Pydantic, extra="allow").
+#
+# Disk-as-truth: the heavy BPMN XML lives on disk at
+# design_files/flow_design/{process_id}.bpmn. The owning process carries only
+# the durable direct file reference; Host execution events drive queued/running/
+# failed activity in the panel.
+#
+# `nullable: true` marks fields the Pydantic model types `str | None`;
+# the write-time validator accepts null for them.
+type: object
+properties:
+  skill_name: { knowledge: { role: metadata }, type: string }
+  topic: { type: string }
+  epoch: { knowledge: { role: metadata }, type: number }
+  roles:
+    knowledge: { role: metadata }
+    type: array
+    items:
+      type: object
+      properties:
+        id: { type: string }     # ASCII slug for lane ids, e.g. "Buyer"
+        name: { type: string }   # Chinese display name, e.g. "采购员"
+  processes:
+    type: map
+    value:
+      type: object
+      required: [process_id]
+      properties:
+        process_id: { type: string }
+        title: { type: string }
+        description: { type: string }
+        tier: { type: enum, values: [core, business, auxiliary] }         # default core
+        process_type: { type: enum, values: [linear, approval, parallel, event_driven] } # default linear
+        stakeholders: { type: array, items: { type: string } }
+        system_responsibilities: { type: array, items: { type: string } }
+        trigger_hints:
+          type: array
+          items:
+            type: object
+            required: [kind, trigger, expected_outcome]
+            properties:
+              kind: { type: enum, values: [timer, message, error, conditional, signal] }
+              trigger: { type: string }
+              expected_outcome: { type: string }
+        key_features: { type: array, items: { type: string } }
+        business_rules: { type: array, items: { type: string } }
+        exception_handling:
+          type: array
+          items:
+            type: object
+            required: [scenario, handling]   # both must be non-empty (validation.yaml)
+            properties:
+              scenario: { type: string }
+              handling: { type: string }
+        deleted: { type: boolean }           # default false
+        bpmn_file: { type: string, nullable: true }
+  process_order:
+    type: array
+    items: { type: string }

package/payload/desktop-preparation/studio-authoring-template/authoring/studio-creators/source/packages/skills-web-app/bundles/flow_design/validation.yaml

@@ -0,0 +1,64 @@
+# flow_design validation contract.
+# Issue codes and repair hints for the Bundle-owned Flow validators.
+#
+# Contract summary: each active process owes one direct `bpmn_file` reference.
+# A flow_design run is not done until every process in `process_order` points
+# to a non-empty validated BPMN artifact.
+skill: flow_design
+
+rules:
+  - id: referenced_files_present
+    scope: [state]
+    code: flow_design.referenced_artifact_invalid
+    check:
+      referenced_files: ["processes.*.bpmn_file"]
+
+  # ---- validate_state ----
+  - id: empty_plan
+    scope: [state]
+    code: flow_design.empty_plan
+    message: "The flow plan has no processes."
+    repair_hint: "Add at least one complete process before execution."
+    check: { non_empty_map: processes }
+
+  - id: empty_order
+    scope: [state]
+    code: flow_design.empty_order
+    message: "process_order is empty, so no process can be executed or rendered."
+    repair_hint: "List every active process id in process_order."
+    check: { non_empty_list: process_order }
+
+  - id: missing_process
+    scope: [state]
+    code: flow_design.missing_process
+    message: "process_order references missing process {pid}."
+    repair_hint: "Add the complete process entry or remove the dangling id."
+    check: { order_refs_map: { order: process_order, map: processes } }
+
+  - id: empty_title
+    scope: [state]
+    code: flow_design.empty_title
+    message: "Process {pid} has an empty title."
+    repair_hint: "Provide a concrete title before starting BPMN work."
+    check:
+      for_each_in_order: { order: process_order, map: processes }
+      non_empty_string: title
+
+  - id: empty_description
+    scope: [state]
+    code: flow_design.empty_description
+    message: "Process {pid} has an empty description."
+    repair_hint: "Provide a concrete description before starting BPMN work."
+    check:
+      for_each_in_order: { order: process_order, map: processes }
+      non_empty_string: description
+
+  # ---- validate_completion ----
+  - id: completed_artifact_ref
+    scope: [completion]
+    code: flow_design.incomplete
+    message: "Process {pid} has no BPMN artifact reference."
+    repair_hint: "Validate and lay out that process with the Bundle scripts, then publish the BPMN file and its direct ref atomically."
+    check:
+      for_each_in_order: { order: process_order, map: processes }
+      non_empty_string: bpmn_file

package/payload/desktop-preparation/studio-authoring-template/authoring/studio-creators/source/packages/skills-web-app/bundles/function_modules/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: function_modules
+description: |-
+  - **Capability**: organize the product into user-facing function cards.
+  - **Resolves**: S gaps by turning an established product goal and core scenarios into a non-overlapping capability map.
+  - **Candidate when**: the outcome, primary users, and material boundary are established, or the user explicitly asks to split or revise functions.
+  - **Do not infer**: an app category, domain name, or generic product goal is not enough evidence to invent a function map.
+  - **Output**: a function-module panel grouped by Epic for browsing.
+---
+
+# Function Modules
+
+For canvas generation or revision, read [the canvas guide](reference/canvas-guide.md).
+It supplements the existing methods and output contract; it applies to both
+new design and reconstruction without replacing domain-specific rules.
+
+## Ownership and tools
+
+`function_modules/function_modules.json` is the only canonical state. The
+active executor (main Agent or Producer, selected by execution.mode) uses project-scoped `list` and `read_design_file` to inspect the current
+map, GROUND, and relevant Design evidence. It uses `write` or `edit` to maintain
+the complete function map in its owned WorkingCopy. Placement does not change
+ownership, the schema, or optional Worker artifact boundaries.
+
+Before authoring, read [the output contract](reference/artifact-contract.md).
+It covers the optional structured local details and pinned source references.
+
+Before publication, the executor calls `design_validate`. It repairs every
+schema or declarative validation diagnostic in the same WorkingCopy, repeats until valid, then
+calls `design_publish({action:"complete"})`. A panel save already persists the
+user's card edits; later runs read and preserve those edits.
+
+## Maintaining existing design
+
+The saved `function_modules` state is the authority for the current module
+map. When it already contains material functions, this skill maintains that
+map rather than creating a second "refine" route or a replacement document.
+
+- Read the current state before a material revision when the relevant module,
+  Epic, priority, local details, references, or rejected status is not already in the
+  current design context.
+- Preserve unaffected Epic/function IDs, order, descriptions, priorities,
+  local details, references, and `rejected` records. A function rejected by the user
+  remains visible as rejected; only a truly removed function disappears.
+- For any add, split, merge, rename, reprioritisation, rejection, or
+  description refinement of an established map, produce the complete updated
+  state and preserve every unaffected card and nested detail/reference key in the executor's WorkingCopy.
+- Never recreate an existing map merely because the user asks to refine it.
+
+## When to use
+
+Use this skill when the product goal is understood but the user-facing capabilities are not yet enumerated, or when the user wants to add, split, revise, accept, or reject functions. Do not use it to model infrastructure or to create a separate Epic entity.
+
+## Derive capabilities from outcomes
+
+Start from the established user's situation and intended result, then trace
+the smallest meaningful journey that achieves it. Derive the capabilities
+needed along that journey; a competitor's feature list or a set of screens is
+not itself a reason to include them. For each proposed capability, explain who
+uses it, what it enables, and why that matters to the current scope. Put the
+concise behavior summary in `function_description`. Use `reason` (shown as Notes)
+for the proposal's basis, design rationale, tradeoffs, supplementary context or
+unresolved points. Keep core behaviors, inputs, outcomes, boundaries and exceptions
+in their own detail fields, not in a long Notes field. Use optional `details`
+for grounded local specifications, not a story
+collection, discovery database, roadmap, or a second shared product definition.
+
+Check granularity by user purpose: independent user outcomes may deserve
+separate functions; buttons, fields and steps of the same capability usually
+do not. Group related capabilities into Epics only after their purposes are
+clear. Walk a representative journey through the map to find a missing link
+or two cards promising the same result.
+
+Prioritize by contribution to the agreed outcome and dependencies, not by
+competitor prevalence or giving every card High. When a consequential solution
+choice is genuinely open, explain the alternatives and their tradeoffs rather
+than include both by default. External evidence supports a proposal; it does
+not establish that this user needs or has accepted it.
+
+"Complete" means complete for the agreed scope, not every conceivable future
+use. For a personal reading tool, collecting an article, finding it later and
+retaining useful notes can form a journey without team invitations or approval
+flows. The example is not a mandatory feature set. Respect deferred scope and
+preserve existing confirmed functions; reducing scope requires user direction,
+not an automatic minimalist rewrite. Detailed flows, policies and acceptance
+specifications remain with their owning facets.
+
+## Deepen only what helps the user judge the capability
+
+Reuse the user's existing concrete situations and answers as evidence. Do not
+start a new interview just to fill detail fields. Explain a proposed function
+through who encounters the situation, what they can do, and what useful result
+changes; a hypothetical example is a proposal, never user confirmation.
+
+Where supported, use one `details.situation` usage scenario to explain who uses
+the capability, in what circumstances and for what useful outcome. It combines
+purpose and situation without repeating the card's capability summary. Add core
+behaviors, inputs/results, limits, and exception handling using the contract's
+stable-key maps. These are
+optional dimensions, not a checklist for every card. Unknown facts remain
+absent; don't write six empty sections or make completeness depend on counts.
+Local examples and observable conditions belong here even if testable. Full
+cross-functional flows, shared rules/access/data, and formal acceptance retain
+their existing owners; cite real records instead of duplicating their authority.
+
+Use `references` only when a source really exists in this project's Design Files
+at an exact commit. Keep target file/pointer/revision separate from the optional
+subject_pointer in the current function. Preserve historical provenance but
+reconcile later user intent against current source facts. Positional array
+references are historical evidence only, never guessed current identity.
+Missing upstream records do not force another Bundle or prohibit known local
+behavior. Omit unsupported references rather than invent one.
+
+Only during an explicitly authorized upgrade of old split purpose/situation
+data, use the conversion described in the output contract. Preserve both texts,
+all other fields and source pins; do not silently upgrade an active project.
+
+When authorized shared specifications later replace local ones, update the owner
+through its ordinary authorized path before replacing duplicate local norms with
+references. Similar text alone grants no cross-Bundle write authority. Preserve
+function-level explanation and history. Renaming keeps IDs; splitting/merging
+requires deliberate reference repair, not regeneration of the whole map.
+
+At handoff, name the material change and one concrete user consequence, with a
+necessary decision only if one remains. An optional derived experience can help
+the user judge established behavior; describe the relevant scene to the main
+conversation, not a forced next Bundle. Never generate an unrelated scene or
+modify another owner from this invocation, and don't require a story view.
+
+## Close-out evidence
+
+Close only after the active function map and any accept/reject decisions are persisted. A confirmed map primarily adds S evidence by establishing a complete, non-overlapping product skeleton. It can improve U when explicit functions settle the product boundary, and T only to the extent that descriptions make expected user-facing behavior reviewable. Report the persisted evidence behind those changes; card count alone adds no clarity.
+
+### Typical evidence guidance
+
+- Assess U/S/T only from persisted evidence using the shared Host rubric; no fixed increment follows from running this Bundle or filling optional details.
+- Rejected functions count only insofar as their rejection clarifies the active product boundary; they do not add score merely by remaining visible in the rejected view.
+- A draft with overlapping functions, missing user-facing descriptions, or unresolved module scope may leave scores unchanged or lower them.
+
+## Output contract
+
+Read [the shared output contract](reference/artifact-contract.md) for these field meanings, examples and checks; it is used by both ordinary design and reconstruction.