review-system-design
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese/design-by-contract
Present the system design of a scope — a diff, a spec, or both — to a human
reviewer, one batch at a time.
Write reviewer-facing prose in ASD-STE100 Simplified Technical English, inside
a closed vocabulary: the ubiquitous language of ,
terms used exactly, and code identifiers as code spans. When
the vocabulary lacks a term, flag a glossary proposal through .
Write complete clauses: every verb keeps its object, and every definite noun
has an antecedent.
CONTEXT.mdcodebase-designdomain-modelingMap the selected contracts as a contract dependency tree: every contract
branches into the contracts that depend on it. A spec's contract table names
the contracts; a diff is the truth for what changed. When both exist, reconcile
them and flag any contract found only in the diff as unplanned.
The review surface is implementation only: production source. Exclude test
suites, documentation, and workspace fixtures. Treat a spec row that names one
of those surfaces as a sign-off device; review its knobs at their owning
contract.
Work the tree in rounds. The frontier is every contract whose upstream
contracts are already reviewed. A round starts with
, then presents the whole frontier through
, including only the visuals it selects. Prefix contracts
with handles , , … across rounds. For each contract, state why it
changed in one or two sentences and link its spec or ADR once.
## <scope name> — round N of Mdesign-by-contractC1C2Then wait for the reviewer's reply. One reply advances the batch: challenged
contracts become logged concerns, each with its agreed fix when one emerges;
the rest are accepted. Keep the scope frozen while the review runs. A proposed
fix is a log entry until the review ends.
Finding facts is your job, never the reviewer's. Use a sub-agent when the diff,
spec, or a call site must establish a fact; the reviewer supplies only verdicts.
Finish after every contract in the tree is visited. Summarize concerns and
their agreed fixes, then apply the amendments the reviewer confirms. When the
reviewer requests a guide, write it where they say: one review pointer, the
contracts in handle order, and the selected visuals.
/design-by-contract
将范围(差异、规格说明或两者兼具)的系统设计分批展示给人工审核者。
面向审核者的文本需使用ASD-STE100简化技术英语,并遵循封闭词汇表:严格使用中的通用语言、术语,代码标识符以代码跨度形式呈现。当词汇表缺少对应术语时,通过标记术语表提案。语句需完整:每个动词均保留其宾语,每个定指名词均有先行词。
CONTEXT.mdcodebase-designdomain-modeling将选定的契约映射为契约依赖树:每个契约分支为依赖它的契约。规格说明的契约表会列出契约名称;差异是变更内容的真实依据。当两者同时存在时,需进行协调,并将仅在差异中出现的契约标记为未规划项。
审核范围仅限实现代码:即生产环境源代码。排除测试套件、文档和工作区固定装置。规格说明中提及上述内容的条目视为签署凭证;其相关配置需在所属契约中进行审核。
按轮次处理依赖树。前沿集合指所有上游契约已完成审核的契约。每一轮以开头,然后通过展示整个前沿集合,仅包含选定的可视化内容。跨轮次为契约添加、…的标识前缀。针对每个契约,用1-2句话说明变更原因,并链接其对应的规格说明或ADR一次。
## <范围名称> — 第N轮,共M轮design-by-contractC1C2随后等待审核者回复。每一次回复推进一批处理:受到质疑的契约会被记录为问题,若达成修复方案则一并记录;其余契约视为通过审核。审核期间保持范围固定。在审核结束前,提议的修复方案仅作为日志条目存在。
查找事实是你的职责,而非审核者的。当需要从差异、规格说明或调用站点确认事实时,使用子代理(sub-agent);审核者仅提供裁决结果。
当依赖树中的所有契约均已处理完毕时,审核结束。总结问题及对应的已达成修复方案,然后应用审核者确认的修改内容。若审核者要求提供指南,按其指定位置撰写:包含一个审核指引、按标识顺序排列的契约,以及选定的可视化内容。