It owns the whole stage, not only one diagram.
-
when the business ask is a multi-agent collaboration capability, agent cluster, orchestration runtime, or chat-surface coordination system rather than a single isolated feature, add the following solution-design checks before freezing the business solution:
-
separate the user-visible surface from the runtime truth layer
- for example: chat/channel/thread is the visible workspace; task tree + shared state is the real collaboration object
-
if any participant can be the entry point, still require a single root owner for each root task and a single final delivery exit
-
separate formal external collaboration nodes from node-local internal parallelism
- internal delegate/parallel execution should not automatically pollute the external responsibility graph
-
if the user already has a strong mechanism draft, do not restart discovery from zero
- instead, lift it upward into a business solution document that makes explicit: background, goals, scope/non-goals, roles, closed loop, risks, and reuse judgment
-
when the deliverable is a formal business-solution design document rather than a discussion note, write in the current settled architecture voice
- remove process-language such as “本轮讨论 / 上一版 / 旧方案 / 调整为 / 这版” from the main body unless the user explicitly asks for decision-history retention
- prefer one coherent present-tense solution narrative over a before-vs-after retelling
-
when source materials mix productized/codename naming with technical/responsibility naming, explicitly define a terminology convergence boundary before editing the formal solution artifacts
- formal solution documents, architecture review outputs, and business-solution / technical architecture diagrams should converge to technical responsibility-oriented terms rather than keeping product nicknames as internal module names
- PRD prototypes, demo copy, and market-facing narrative may retain the product-facing term when that term is part of the UX or product story
- do not stop at正文 replacement only: if the formal artifact set includes diagrams, legends, or architecture examples, converge those assets in the same pass
- do not over-normalize by rewriting product/market artifacts unless the user explicitly asks for full-library unification across both technical and product layers
- see
references/terminology-convergence-layering.md for a concrete layered example
-
when the business object itself is a Harness-style control architecture, describe Harness as the solution’s primary control architecture, not as a side runtime hidden inside a larger generic mechanism
- if Guide/Sensor × Computational/Inferential is the real control spine, use that 2×2 explicitly as the main explanatory axis in the solution section instead of treating Harness as a minor submodule
-
for MVP, prefer one surface + one lightweight truth store before multi-channel expansion or heavy workflow-kernel design
-
when the solution direction has already pivoted and the user asks for an updated business-solution document, normalize the final artifact to the latest chosen architecture only
- do not keep “old方案 vs 新方案” comparison prose, transitional caveats, or stale examples in the main document unless the user explicitly asks for decision history
-
if the design pivot changes the architecture picture, update the examples and the business-solution architecture diagram in the same pass
- do not leave placeholders such as “旧图已失效，之后再补” in the final document delivered for review
-
when the user wants a business-facing v2 solution document, explicitly strip out底层技术实现细节 from the solution artifact
- do not foreground concrete runtime names, open-source product choices, protocol names, adapter details, or implementation mechanisms in the business solution doc unless the audience explicitly asks for them
- instead, explain the solution through business modules, user roles, operating entry points, closed-loop flows, and governance outcomes
- treat concrete technology choices as material for the technical overview / 概要设计 layer, not the business solution layer
-
when asked to produce a new independent v2 instead of revising in place, create a separately named document and matching versioned diagram assets rather than mutating the existing canonical files
- keep the old version readable
- keep the v2 business doc's embedded assets self-consistent with its own versioned
resources/ files
This pattern is especially important for Telegram/Slack/Discord-style agent collaboration proposals where the visible conversation is tempting to mistake for the runtime itself.
