Back to Details

adf-backend-development

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ADF Backend Development

ADF Backend Development

目的

Purpose

實作已核准 BR/Q/VAL、安全、交易與錯誤語意；不得在 Coding 階段自行重新定義 Requirement。
Implement approved BR/Q/VAL, security, transaction, and error semantics; the Coding stage must not independently redefine Requirements.

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
    , or 
    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 has been completed.
  • Stable identifiers remain in English: 
    REQ-*
    , 
    BR-*
    , 
    VAL-*
    , 
    Q-*
    , 
    UI-*
    , 
    DEV-*
    , and 
    MIG-*
    .
  • Behavior that cannot be verified must be marked 
    UNKNOWN
    or 
    REVIEW_REQUIRED
    .
  • Expected Results must not be weakened merely to obtain a 
    PASS
    .
  • Project-wide Standards belong in 
    standards/
    .

Evidence-Guided Q&A

Evidence-Guided Q&A

解析單一官方來源 
adf-project-install/references/
下的 interactive-review、question-schema、approval-gate 與 terminology，依其規則執行。來源缺少或版本不相容時停止需要 Review 的階段，不維護本地副本。
Resolve the single official source for interactive-review, question-schema, approval-gate, and terminology under 
adf-project-install/references/
, and follow their rules. If a source is missing or version-incompatible, stop any Stage requiring 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 authoritative location for 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>
    may be used. If the versions or content conflict between the two locations, stop; do not fall back to the global scope.
  • If the Skill providing the official resources is not installed or is version-incompatible, prompt the user to install the applicable official version at the project level through 
    npx skills
    . Review must not be skipped.
  • Read the project's 
    standards/
    and approved Evidence first; examples in the official specifications are not project-approved standards and are not applied automatically.
  • Preserve v5.0 Module documentation, completion status, and approval records. Fields or documents missing from the new version should be listed as remediation suggestions, and approvals must not be automatically revoked. Any required remediation must follow a separate CHANGE.
  • For legacy Modules that have not adopted the new Gate, list only Functional Scenario or specification differences. New-version requirements should be checked only for new work that has explicitly adopted them.