adf-result-normalization

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ADF Result Normalization

ADF Result Normalization

目的

Purpose

只允許 APPROVED Migration Rule 參與 Normalization;不得用 Normalization 隱藏真正 Business Difference。
Only APPROVED Migration Rule may participate in Normalization; Normalization must not be used to conceal genuine Business Difference.

ADF 共通不變條件

ADF Common Invariants

  • Work Type 僅使用
    NEW
    、
    CHANGE
    、
    MIGRATION
    。
  • 每個 Module 同一時間只允許一個 Active Work Item;Module 是主要隔離邊界。
  • 預設採 Compact Artifacts:
    requirements.md
    、
    rules.md
    、
    standards.md
    、
    design.md
    、
    test-cases.md
    、
    traceability.md
    。
  • 檔案存在不代表 Stage 已完成。
  • 穩定識別碼維持英文:
    REQ-*
    、
    BR-*
    、
    VAL-*
    、
    Q-*
    、
    UI-*
    、
    DEV-*
    、
    MIG-*
    。
  • 無法證明的行為必須標記
    UNKNOWN
    或
    REVIEW_REQUIRED
    。
  • 不得為了取得
    PASS
    而弱化 Expected Result。
  • Project-wide Standards 放在
    standards/
    。
  • Work Type may only use
    NEW
    ,
    CHANGE
    , and
    MIGRATION
    .
  • Each Module may have only one Active Work Item at a time; the Module is the primary isolation boundary.
  • Compact Artifacts are used by default:
    requirements.md
    ,
    rules.md
    ,
    standards.md
    ,
    design.md
    ,
    test-cases.md
    , and
    traceability.md
    .
  • The existence of a file does not mean that the Stage is complete.
  • Stable identifiers remain in English:
    REQ-*
    ,
    BR-*
    ,
    VAL-*
    ,
    Q-*
    ,
    UI-*
    ,
    DEV-*
    , and
    MIG-*
    .
  • Behavior that cannot be proven must be marked as
    UNKNOWN
    or
    REVIEW_REQUIRED
    .
  • Expected Result must not be weakened to obtain a
    PASS
    .
  • Project-wide Standards are stored in
    standards/
    .

Evidence-Guided Q&A

Evidence-Guided Q&A

解析單一官方來源
adf-project-install/references/
下的 interactive-review、question-schema、approval-gate 與 terminology,依其規則執行。來源缺少或版本不相容時停止需要 Review 的階段,不維護本地副本。
Parse the single official source under
adf-project-install/references/
, including interactive-review, question-schema, approval-gate, and terminology, and follow its rules. If the source is missing or its version is incompatible, stop any Stage that requires Review; do not maintain a local copy.

v5.1 資源與舊專案相容性

v5.1 Resources and Legacy Project Compatibility

  • 官方資源唯一位置以
    adf-project-install/references/resources.json
    為準;不複製到專案
    .adf/templates/
    ,不使用客製範本。
  • 從本專案
    .agents/skills/
    或
    .claude/skills/
    解析來源;可使用安裝 Skill 的
    scripts/project.mjs resolve <project> <resource-key>
    。兩處版本或內容衝突時停止,不回退到全域。
  • 官方資源來源 Skill 未安裝或版本不相容時,提示透過
    npx skills
    在專案層級安裝適用正式版本。Review 不可跳過。
  • 先讀取專案
    standards/
    與已核准 Evidence;官方規範範例不是專案核准規範,不自動套用。
  • 保留 v5.0 的 Module 文件、完成狀態與核准紀錄;新版缺少欄位或文件列為補做建議,不自動撤銷核准。需要補做另走 CHANGE。
  • 在尚未採用新版 Gate 的舊 Module,只列出 Functional Scenario / specification 差異;已明確採用的新工作才檢查新版要求。
  • The sole location of official resources is defined by
    adf-project-install/references/resources.json
    ; do not copy them to the project’s
    .adf/templates/
    or use custom templates.
  • Resolve sources from this project’s
    .agents/skills/
    or
    .claude/skills/
    . The installed Skill’s
    scripts/project.mjs resolve <project> <resource-key>
    command may be used. If the versions or content of the two locations conflict, stop; do not fall back to global resources.
  • If the official resource source Skill is not installed or its version is incompatible, prompt the user to install the applicable official version at the project level using
    npx skills
    . Review cannot be skipped.
  • Read the project’s
    standards/
    and approved Evidence first; examples in official standards are not project-approved standards and are not applied automatically.
  • Retain v5.0 Module documentation, completion status, and approval records. Fields or documentation missing from the new version should be listed as remediation recommendations and must not automatically revoke approvals. Remediation must follow the separate CHANGE process.
  • For legacy Modules that have not adopted the new Gate, list only Functional Scenario or specification differences. Check new-version requirements only for work that has explicitly adopted them.