@@ -31,7 +31,7 @@ question's computed truth; a card that does not load is red in CI.
 | Layer | Key | What it states |
 |:---|:---|:---|
 | 1 | `prompt` | `{ short, detailed }`, each `{ zh?, en? }` with at least one language. |
-| 2 | `expect` | The structural expectation the deterministic scorer reads, field for field: `objects`, `minFieldsPerObject?`, `selectFields?` (`{ object, field, minOptions }`), `lookups?` (`{ object, field, to }`), `dashboards?`, `appNavTargets?`. |
+| 2 | `expect` | The structural expectation the deterministic scorer reads, field for field: `objects`, `minFieldsPerObject?`, `selectFields?` (`{ object, field, minOptions }`), `lookups?` (`{ object, field, to }`), `dashboards?`, `appNavTargets?`. The runner's build prompt states every row by name ([Build checks trace to the prompt](#build-checks-trace-to-the-prompt)). |
 | 3 | `capabilities`, `businessFunctions` | Tags `<area>.<name>`, where `<area>` is a closed set: the basenames of `docs/qa/platform-checklist/areas/*.json`, read from the tree. `businessFunctions` is the marketplace taxonomy's business-function facet, read from `@objectstack/spec/marketplace` (`MarketplaceBusinessFunctionsSchema`, defined once in `packages/spec/src/marketplace/taxonomy.zod.ts`): 1-3 distinct values, the primary one first — the card is classified the way the template it graduates into will be listed. |
 | 4 | `run.seed`, `run.questions`, `run.personas` | Seed rows per object; at least five read-only questions, each with a **declarative** truth spec; at least two personas, each a role, the objects or fields it must NOT see, and optionally a row `scope`. |
 | 5 | `run.operations`, `run.guardrails`, `run.agentActions?` | At least two writes, each acting as a persona and declaring its `outcome`; the five guardrail checks; optionally the agent-callable business actions. |
@@ -210,6 +210,27 @@ the loader enforces; each card's own test pins the rest:
   action, a refused overstep, a refused validation violation and one multi-step chain;
 - at least three agent actions, one of them confirm-gated.
 
+## Build checks trace to the prompt
+
+Every Build check must trace to text the build prompt carries; otherwise a faithful build fails
+for not guessing a name.
+
+- **Names.** The runner's data contract states the seed (objects and fields), each persona's
+  permission set and every `expect` row by name: lookup targets, option fields with their
+  minimum option counts, dashboards and app navigation targets. The iterate prompt does the
+  same for `iterate.expectDelta`. A card therefore picks its dashboard names knowing the build
+  is told them.
+- **Tags.** A capability tag whose check reads something the seed does not show is asked for
+  in the card's prose: `records-forms.master-detail-inline-edit` names the detail edited inline
+  on its master, in every language the prompt carries.
+- **Approvals.** A card either exercises the platform approval engine or models approvals as
+  data, never both. A card that seeds approval history as rows (an approval step object, or an
+  approver and decision date on the record) and grades approving as a data write models them
+  as data: its prose says each decision is a record it updates, asks for no approval process,
+  and it carries no `approvals.*` tag, whose checks read the engine's Approval node. The engine
+  keeps its own history, which no seed row can preload. Every open card models approvals as
+  data today.
+
 ## Adding a card
 
 1. Write `<id>.json` here; `id` equals the basename, `code` is one no other card uses, and
 
@@ -12,8 +12,8 @@
       "en": "Build a fixed-asset lifecycle app: an asset register, checkout and return, repairs, monthly depreciation and a scrap approval."
     },
     "detailed": {
-      "zh": "固定资产全生命周期应用。资产按类别登记(笔记本电脑、显示器、手机、办公椅),每个类别规定使用月数和折旧方法(直线法,无残值);每项资产记录资产编号、序列号、类别、所属部门、采购日期和采购成本。资产管理员把资产领用给员工,一次可以领用多件;领用单记录领用日期、应还日期(长期配发不填)、归还日期和归还时的状况。领用后资产状态自动变为使用中、保管人为领用人,归还后保管人清空;只有在库的资产才能领用,否则不能保存。资产损坏时开维修单(故障描述、状态、维修费用),维修期间资产状态为维修中。每月最后一天由定时流程给每项未报废的资产计提一个月折旧(采购当月不计提);资产的累计折旧汇总它的折旧记录,账面价值 = 采购成本 − 累计折旧。报废要走审批:报废申请由资产所属部门的经理审批,批准后由资产管理员执行报废;执行报废不可撤销,资产变为已报废、剩余账面价值核销,此后不再计提折旧。员工只能看到自己保管的资产,以及自己的领用单、自己报修的维修单和自己提交的报废申请,看不到采购成本、累计折旧、账面价值、折旧记录和部门资产预算;部门经理能看到本部门的资产、本部门员工的领用单,以及本部门资产的维修单、报废申请和折旧记录;资产管理员能看到全部资产,但看不到部门资产预算;员工的家庭住址(用于寄送设备)只有资产管理员可见。需要一个按类别和部门统计资产数量和账面价值的报表。尽量用声明式配置(公式字段、汇总字段、校验规则、审批流程、定时流程)而不是代码钩子,以便应用能以非托管方式安装。",
-      "en": "A fixed-asset lifecycle app. Assets are registered by category (laptop, monitor, mobile phone, office chair); each category sets a useful life in months and a depreciation method (straight line, no salvage value), and each asset records its asset tag, serial number, category, owning department, purchase date and purchase cost. The asset administrator checks assets out to employees, several at once if needed; a checkout records the checkout date, a due date (none for a permanent assignment), the return date and the condition on return. A checkout sets the asset in use with the employee as its custodian, and a return clears the custodian; only an asset in stock can be checked out, otherwise the checkout cannot be saved. A damaged asset gets a repair order (the fault, a status and the repair cost) and is in repair until it is fixed. On the last day of each month a scheduled flow posts one month of depreciation for every asset not disposed of (nothing for the purchase month); an asset's accumulated depreciation sums its depreciation entries, and its book value is the purchase cost minus the accumulated depreciation. Scrapping needs an approval: the manager of the asset's department decides a scrap request, and once it is approved the asset administrator disposes of the asset; a disposal cannot be undone, sets the asset disposed, writes off its remaining book value and stops its depreciation. An employee sees only the assets they hold and their own checkouts, the repairs they reported and the scrap requests they filed, and sees no purchase cost, accumulated depreciation, book value, depreciation entry or department asset budget; a department manager sees their department's assets, their own people's checkouts, and the repairs, scrap requests and depreciation of their department's assets; the asset administrator sees every asset but no department's asset budget; an employee's home address (used to ship equipment) is visible to the asset administrator only. Add a report of asset count and book value by category and department. Prefer declarative configuration (formula and roll-up fields, validation rules, an approval process, a scheduled flow) over code hooks, so the app can be installed unmanaged."
+      "zh": "固定资产全生命周期应用。资产按类别登记(笔记本电脑、显示器、手机、办公椅),每个类别规定使用月数和折旧方法(直线法,无残值);每项资产记录资产编号、序列号、类别、所属部门、采购日期和采购成本。资产管理员把资产领用给员工,一次可以领用多件;领用单记录领用日期、应还日期(长期配发不填)、归还日期和归还时的状况。领用后资产状态自动变为使用中、保管人为领用人,归还后保管人清空;只有在库的资产才能领用,否则不能保存。资产损坏时开维修单(故障描述、状态、维修费用),维修期间资产状态为维修中。每月最后一天由定时流程给每项未报废的资产计提一个月折旧(采购当月不计提);资产的累计折旧汇总它的折旧记录,账面价值 = 采购成本 − 累计折旧。报废要走审批:报废申请由资产所属部门的经理审批,审批人、状态和审批日期都记在报废申请本身上(审批就是更新这条申请),批准后由资产管理员执行报废;执行报废不可撤销,资产变为已报废、剩余账面价值核销,此后不再计提折旧。员工只能看到自己保管的资产,以及自己的领用单、自己报修的维修单和自己提交的报废申请,看不到采购成本、累计折旧、账面价值、折旧记录和部门资产预算;部门经理能看到本部门的资产、本部门员工的领用单,以及本部门资产的维修单、报废申请和折旧记录;资产管理员能看到全部资产,但看不到部门资产预算;员工的家庭住址(用于寄送设备)只有资产管理员可见。需要一个按类别和部门统计资产数量和账面价值的报表。尽量用声明式配置(公式字段、汇总字段、校验规则、定时流程)而不是代码钩子,以便应用能以非托管方式安装。",
+      "en": "A fixed-asset lifecycle app. Assets are registered by category (laptop, monitor, mobile phone, office chair); each category sets a useful life in months and a depreciation method (straight line, no salvage value), and each asset records its asset tag, serial number, category, owning department, purchase date and purchase cost. The asset administrator checks assets out to employees, several at once if needed; a checkout records the checkout date, a due date (none for a permanent assignment), the return date and the condition on return. A checkout sets the asset in use with the employee as its custodian, and a return clears the custodian; only an asset in stock can be checked out, otherwise the checkout cannot be saved. A damaged asset gets a repair order (the fault, a status and the repair cost) and is in repair until it is fixed. On the last day of each month a scheduled flow posts one month of depreciation for every asset not disposed of (nothing for the purchase month); an asset's accumulated depreciation sums its depreciation entries, and its book value is the purchase cost minus the accumulated depreciation. Scrapping needs an approval: the manager of the asset's department decides a scrap request, which records its own approver, status and decision date (deciding it updates the request), and once it is approved the asset administrator disposes of the asset; a disposal cannot be undone, sets the asset disposed, writes off its remaining book value and stops its depreciation. An employee sees only the assets they hold and their own checkouts, the repairs they reported and the scrap requests they filed, and sees no purchase cost, accumulated depreciation, book value, depreciation entry or department asset budget; a department manager sees their department's assets, their own people's checkouts, and the repairs, scrap requests and depreciation of their department's assets; the asset administrator sees every asset but no department's asset budget; an employee's home address (used to ship equipment) is visible to the asset administrator only. Add a report of asset count and book value by category and department. Prefer declarative configuration (formula and roll-up fields, validation rules, a scheduled flow) over code hooks, so the app can be installed unmanaged."
     }
   },
   "expect": {
@@ -59,7 +59,6 @@
     "records-forms.roll-up-summary",
     "records-forms.validation-rule",
     "records-forms.select-options",
-    "approvals.dynamic-approver-routing",
     "automation.record-triggered-flow",
     "automation.scheduled-flow",
     "access-security.row-level-security",
 
@@ -8,7 +8,7 @@
   "prompt": {
     "short": {"en": "Build an invoicing app with invoices and their line items."},
     "detailed": {
-      "en": "Model an invoicing app: an invoice with multiple line items (product, quantity, unit price, amount). The invoice total should sum its line amounts, and line items are entered together with the invoice."
+      "en": "Model an invoicing app: an invoice with multiple line items (product, quantity, unit price, amount). The invoice total should sum its line amounts, and line items are entered together with the invoice, inline on its form."
     }
   },
   "expect": {
Original file line number	Diff line number	Diff line change
`@@ -8,7 +8,7 @@`
`8`	`8`	`"prompt": {`
`9`	`9`	`"short": {"en": "Build an invoicing app with invoices and their line items."},`
`10`	`10`	`"detailed": {`
`11`		`- "en": "Model an invoicing app: an invoice with multiple line items (product, quantity, unit price, amount). The invoice total should sum its line amounts, and line items are entered together with the invoice."`
	`11`	`+ "en": "Model an invoicing app: an invoice with multiple line items (product, quantity, unit price, amount). The invoice total should sum its line amounts, and line items are entered together with the invoice, inline on its form."`
`12`	`12`	`}`
`13`	`13`	`},`
`14`	`14`	`"expect": {`