@@ -169,7 +169,7 @@ What is missing is the only thing that would turn that into more than a claim: *
 The pieces a second implementer would hit first, in the order we expect them to bite:
 
 - [x] **Action semantics.** *(2026-09-28. `src/action-semantics.ts` declares, for each of the 14 actions, the branch a host takes (`next`), whether it ends the tool loop, whether the run still has model calls afterwards, whether it needs evidence, and how many retries it allows. Exported through `jevloop/contract`; the table is in `docs/DECISION-CONTRACT.md` §3. **Checked against the runtime, not against itself** — `tests/action-semantics.test.ts` drives the loop once per action and asserts the observed behaviour, which caught two wrong assumptions while writing it. The field split that mattered: `stop`, `finish`, `answer` and `escalate` all end the **tool loop** and the run then generates anyway — a single `terminal` flag would have made a second implementer drop that generation.)*
-- [ ] **Projection capability declarations.** A host must register `earlierMaybe`, `toolOrEmpty` and thirteen more; the only description of what each one means is our implementation. Write down what each projection reads and returns, or let the file declare it.
+- [x] **Projection capability declarations.** *(2026-09-28. `src/frame-projections.ts` declares, for each of the 14 names, which state cell it reads, what shape it returns, and **what it promises on a missing value** — that last column is the point: `lastOrNone` sends `（还没有做过任何动作）` where `resultMaybe` sends an empty string, and the difference is part of the criterion, not cosmetics. The name list and every `from` have one source of truth; `decisions.ts` supplies only function bodies, so a missing or extra implementation is a compile error. `tests/frame-projections.test.ts` checks each `from` is a real state cell, each declared `returns` matches what the implementation returns, no projection is declared without being used, and the external host's capability list matches exactly — which is how this caught a phantom: the published report listed a `lastResult` projection that **exists nowhere**, not in the registry and not in `DECISION.md`. A capability report naming a capability that does not exist is worse than no report.)*
 - [ ] **Dynamic provider inputs.** `dynamic: toolsFor(ctx) → candidates` says the provider reads the context; it does not say *which state cells* it reads, so a host cannot check the declaration against its own state.
 - [ ] **Evidence and replay schema.** `frameDigest` and `requestDigest` are recorded, but there is no portable format for replaying one decision inside another runtime.
 - [ ] **One real adopter.** An issue or a partial PR from a host we did not write — three nodes is enough — is worth more here than any further extension of the format.
 
@@ -172,7 +172,54 @@ runtime** — `tests/action-semantics.test.ts` drives the loop once per action a
 asserts the observed behaviour matches. A semantics table nobody checks is just
 another declaration that can lie.
 
-## 4. Adapter conformance checklist
+## 4. Projection declarations
+
+A `frame:` field can name a projection (`+ task 400 earlierMaybe`). A Markdown
+file cannot hold a function, so the host supplies the implementation — but until
+this declaration existed the host only got the **name**. "How does `lastOrNone`
+differ from `resultMaybe`?" was answerable only by reading JevLoop's code, and the
+difference *is part of the criterion*: one sends `（还没有做过任何动作）` when there
+is no result, the other sends an empty string, and a classifier cannot tell "no
+result yet" from "the result was empty" unless the projection says so.
+
+Each projection therefore declares what it reads, what shape it returns, and what
+it promises on a missing value:
+
+| projection | reads | returns | promise when the value is missing |
+|---|---|---|---|
+| `earlierMaybe` | `earlier` | string | empty string |
+| `filesMaybe` | `files` | list | empty list |
+| `readMaybe` | `readFiles` | list | empty list |
+| `resultMaybe` | `lastResult` | string | empty string |
+| `draftMaybe` | `draft` | string | empty string |
+| `toolOrEmpty` | `lastTool` | string | empty string |
+| `lastOrNone` | `lastResult` | string | **`（还没有做过任何动作）` — not empty** |
+| `toolOrUnknown` | `lastTool` | string | **`unknown` — not empty** |
+| `describeDone` | `history` | string | a one-line summary, never a raw array |
+| `lastInput` | `history` | string | — |
+| `readCount` | `readFiles` | count | 0 |
+| `recentSteps` | `history` | list | empty list |
+| `writeEvidence` | `history` | string | — |
+| `localToolRisk` | `lastTool` | count | **omitted entirely** (`absent`), never 0 |
+
+Two of those rows are the reason the table is worth publishing:
+
+- **The non-empty fallbacks are criteria, not cosmetics.** `lastOrNone` and
+  `toolOrUnknown` exist precisely because an empty string would let a judgement
+  confuse *absent* with *empty*, or *unknown tool* with *no tool*.
+- **`localToolRisk` returns no field at all for an unrecognised tool.** `0` means
+  "read-only", so it cannot stand in for "unknown" — the field is dropped and
+  recorded in `Frame.absent`.
+
+The name list and each `from` have **one source of truth**
+(`src/frame-projections.ts`); JevLoop's implementation supplies only function
+bodies, and the key type makes a missing or extra implementation a compile error.
+`tests/frame-projections.test.ts` additionally checks that every declared `from` is
+a real state cell, that every declared `returns` matches what the implementation
+actually returns, that no projection is declared without being used, and that the
+external host fixture's capability list matches the declaration exactly.
+
+## 5. Adapter conformance checklist
 
 An adapter is conforming only if it can demonstrate all of the following:
 
@@ -196,7 +243,7 @@ The test does not need a language model. A deterministic mock decision provider
 is sufficient; the purpose is to prove that the host consumes the contract and
 executes its actions.
 
-## 5. Extending beyond the reference loop
+## 6. Extending beyond the reference loop
 
 The reference JevLoop loop currently has seven named decision blocks and six
 closed positions. That is a property of the reference host, not a limit that a
@@ -306,7 +353,7 @@ The adapter must either implement a namespaced extension or reject it with a
 source-located error. It must never reinterpret an unknown extension as a
 portable action.
 
-## 6. Compatibility boundary
+## 7. Compatibility boundary
 
 The current JevLoop document contains some reference-host details:
 
@@ -320,15 +367,16 @@ These are intentional adapter seams, not yet an industry-wide ABI. A future
 schema version should still publish:
 
 ```text
-projection capability declarations
 dynamic provider input declarations (which state cells it reads)
 evidence schema
 event and replay schema
 ```
 
-Action semantics are **no longer on this list** — see §3. They are declared,
-exported through `jevloop/contract`, and checked against the runtime, so a host no
-longer has to read JevLoop's loop to learn what `stop` or `deliver` does.
+Two items have left this list. **Action semantics** (§3) are declared, exported
+through `jevloop/contract`, and checked against the runtime, so a host no longer
+has to read JevLoop's loop to learn what `stop` or `deliver` does. **Projection
+declarations** (§4) now say what each of the fourteen names reads, returns, and
+promises on a missing value, with one source of truth for the names.
 
 `DECISION.md` now declares its schema version, and a missing or unrecognised one
 is refused — by `schemaProblems()`, surfaced as the `schema` layer of
@@ -338,8 +386,8 @@ things: `problems` says *this file is malformed*; the schema layer says *I canno
 read the semantics this file claims*. A file written for a future version is the
 second case, not the first.
 
-Positions, dynamic providers and actions are now structured rather than
-re-parsed or inferred by each consumer. What is still missing: a `dynamic:`
+Positions, dynamic providers, actions and projections are now structured rather
+than re-parsed or inferred by each consumer. What is still missing: a `dynamic:`
 declaration says only that the provider takes the context, not which state cells
 it reads.
 
@@ -351,7 +399,7 @@ Until the remaining items land, the honest claim is:
 It is not yet correct to claim that any Agent runtime can execute the file
 without an adapter.
 
-## 7. Consuming the contract without the runtime
+## 8. Consuming the contract without the runtime
 
 A host that wants only the checker must not have to install — or satisfy —
 JevLoop's own runtime. Two entry points:
@@ -375,7 +423,7 @@ jevloop            fails without it — the module-load assertion needs our cont
 
 That is the difference between "portable" and "install us first".
 
-## 8. Reference implementation
+## 9. Reference implementation
 
 The reference adapter currently consists of:
 
 
@@ -34,7 +34,6 @@
     "readMaybe",
     "lastOrNone",
     "toolOrEmpty",
-    "lastResult",
     "lastInput",
     "toolOrUnknown",
     "localToolRisk",
 
@@ -66,7 +66,6 @@ const PROJECTIONS: Record<string, Projection> = {
   readMaybe: (state) => state.already_read,
   lastOrNone: (state) => state.last,
   toolOrEmpty: (state) => state.tool,
-  lastResult: (state) => state.output,
   lastInput: (state) => state.input,
   toolOrUnknown: (state) => state.tool || 'unknown',
   localToolRisk: () => 'host-defined',
 
@@ -262,6 +262,8 @@ const LAYER: Record<string, number> = {
   'vocab-decision': 0,
   // 动作语义：只 import `vocab-decision` 的 `Action` 类型，零运行时依赖
   'action-semantics': 0,
+  // 帧投影的能力声明：零 import 的纯数据，可移植入口要 import 它
+  'frame-projections': 0,
   // Adapter capability checks only consume the parsed contract shape; they do not
   // know JevLoop's state, tools, or loop, so they stay at the portable bottom.
   adapter: 0,
 
@@ -41,6 +41,10 @@ export { CURRENT_SCHEMA, SCHEMA_KEY, SUPPORTED_SCHEMAS, DYNAMIC_OUTPUTS, parseDy
 
 // ── 形状：消费方要能命名它拿到的每一个东西 ──────────────────
 export { ANY_POSITION_ACTIONS, KINDS, POSITIONS } from './decision-shape.ts'
+// 帧投影的能力声明：宿主必须实现这几个名字，这里说清各自读哪一格、返回什么
+export { PROJECTIONS, PROJECTION_NAMES, isProjectionName } from './frame-projections.ts'
+export type { ProjectionName, ProjectionReturns, ProjectionSpec } from './frame-projections.ts'
+
 // 动作语义：外部实现者照 `next` 写 switch 就够了，不必读我们的循环
 export { ACTION_SEMANTICS } from './action-semantics.ts'
 export type { ActionSemantics } from './action-semantics.ts'
 
@@ -69,6 +69,7 @@ import { compilePolicy, compileQuestions } from './decision-compile.ts'
 import { toolsFor, fileOptions, pickInputInstructions, describeDone, lastInput } from './frame.ts'
 import type { AgentCtx, FrameSpec } from './frame.ts'
 import { compileFrame, frameSpecViolations, AGENT_CTX_KEYS } from './frame.ts'
+import { PROJECTIONS, PROJECTION_NAMES, isProjectionName, type ProjectionName } from './frame-projections.ts'
 export type { AgentCtx, StepRecord } from './frame.ts'
 
 // ═══════════════════════════════════════════════════════════
@@ -116,52 +117,80 @@ const DONE_LINE_MAX_CHARS = 300
 // ★ 为什么需要这么多：`AgentCtx` 的格是可选的，而**每一栏缺省时发什么**是一个
 //   决定（空串？空表？省略这一栏？）。原来那些决定散在 `?? ''` 里。
 // ═══════════════════════════════════════════════════════════
-const FRAME_PROJECTIONS: Record<string, { from: keyof AgentCtx; fn: (ctx: AgentCtx) => unknown }> = {
+/*
+  ── 投影的**实现**（名字、来源格、返回形状在 `frame-projections.ts`）──────
+
+  ★ 这里只写函数体。键名由 `Record<ProjectionName, …>` 强制和声明**一一对应**：
+
+      声明里加了名字而这里没写实现   → 编译不过（缺键）
+      这里写了实现而声明里没有       → 编译不过（多余的键）
+
+    而 `from` **直接从声明里取**，所以两份不可能分叉 —— 以前 `from` 是手抄的，
+    抄错一格会让「这个判定看了什么」这件事静默说谎，而 `frameSpecViolations`
+    正是靠 `from` 工作的。
+*/
+const PROJECTION_IMPL: Record<ProjectionName, (ctx: AgentCtx) => unknown> = {
   // ── 空值兜底：缺省时发空串 / 空表（原来写作 `?? ''` / `?? []`）──
-  earlierMaybe: { from: 'earlier', fn: (ctx) => ctx.earlier ?? '' },
-  filesMaybe: { from: 'files', fn: (ctx) => ctx.files ?? [] },
-  readMaybe: { from: 'readFiles', fn: (ctx) => ctx.readFiles ?? [] },
-  resultMaybe: { from: 'lastResult', fn: (ctx) => ctx.lastResult ?? '' },
-  draftMaybe: { from: 'draft', fn: (ctx) => ctx.draft ?? '' },
-  toolOrEmpty: { from: 'lastTool', fn: (ctx) => ctx.lastTool ?? '' },
+  earlierMaybe: (ctx) => ctx.earlier ?? '',
+  filesMaybe: (ctx) => ctx.files ?? [],
+  readMaybe: (ctx) => ctx.readFiles ?? [],
+  resultMaybe: (ctx) => ctx.lastResult ?? '',
+  draftMaybe: (ctx) => ctx.draft ?? '',
+  toolOrEmpty: (ctx) => ctx.lastTool ?? '',
   // ── 非空兜底（缺省时那句默认话本身就是判据的一部分）──
-  lastOrNone: {
-    from: 'lastResult',
-    fn: (ctx) => ctx.lastResult ?? '（还没有做过任何动作）',
-  },
-  toolOrUnknown: { from: 'lastTool', fn: (ctx) => ctx.lastTool ?? 'unknown' },
+  lastOrNone: (ctx) => ctx.lastResult ?? '（还没有做过任何动作）',
+  toolOrUnknown: (ctx) => ctx.lastTool ?? 'unknown',
   // ── 派生 ──
-  describeDone: { from: 'history', fn: (ctx) => describeDone(ctx) },
-  lastInput: { from: 'history', fn: (ctx) => lastInput(ctx) },
-  readCount: { from: 'readFiles', fn: (ctx) => (ctx.readFiles ?? []).length },
-  recentSteps: {
-    from: 'history',
-    fn: (ctx) =>
-      (ctx.history ?? []).slice(-5).map((h) => `${h.tool}(${clip(h.input, 60)}) → ${clip(h.result, 200)}`),
-  },
-  writeEvidence: {
-    from: 'history',
-    fn: (ctx) =>
-      (ctx.history ?? []).slice(-3).map((h, i, all) => {
+  describeDone: (ctx) => describeDone(ctx),
+  lastInput: (ctx) => lastInput(ctx),
+  readCount: (ctx) => (ctx.readFiles ?? []).length,
+  recentSteps: (ctx) =>
+    (ctx.history ?? []).slice(-5).map((h) => `${h.tool}(${clip(h.input, 60)}) → ${clip(h.result, 200)}`),
+  /*
+    ★ 返回**字符串**，不是数组。2026-09-28 修正：
+
+    这一份是 `DECISION.md` 的 `can_deliver` **真正在用**的（`framed()` 里
+    文件赢、代码回退）。它以前 `.map()` 之后没有 join，于是运行时拿到数组 ——
+    两个后果都不是想要的：
+
+      · 声明里的 `chars: 600` **从来没有生效过**（`chars` 只管字符串）；
+      · 信任边界（TODO §7）包的是字符串，所以交付闸门的主输入**没被包上**。
+
+    而前面那次改动只改了**代码回退**那一份，所以它当时**没有生效** ——
+    测试用的也是代码回退，于是「测过了」和「真的改了」成了两件事。
+    现在两份一致，并由 `tests/frame.test.ts` 的「文件与代码回退必须逐字段一致」钉住。
+  */
+  writeEvidence: (ctx) =>
+    (ctx.history ?? [])
+      .slice(-3)
+      .map((h, i, all) => {
         const writes = h.tool === 'write_file'
         const inputBudget = writes ? 600 : 60
         const resultBudget = writes ? 60 : i === all.length - 1 ? 600 : 200
         return `${h.tool}(${clip(h.input, inputBudget)}) → ${clip(h.result, resultBudget)}`
-      }),
-  },
+      })
+      .join('\n'),
   /**
    * 工具的静态风险基线。认不出的工具名**不放这一栏** ——
    * 0 分的意思是「只读」，不能用它冒充「未知」（`absent` 与 `unfilled` 必须分开）。
    */
-  localToolRisk: {
-    from: 'lastTool',
-    fn: (ctx) => {
-      const t = ctx.lastTool
-      return t && isToolName(LOCAL_TOOLS, t) ? LOCAL_TOOLS[t].baseRisk : undefined
-    },
+  localToolRisk: (ctx) => {
+    const t = ctx.lastTool
+    return t && isToolName(LOCAL_TOOLS, t) ? LOCAL_TOOLS[t].baseRisk : undefined
   },
 }
 
+/** 实现 + 声明里的 `from`，合成 `frameSpecFromBlock` 要的那张表 */
+const FRAME_PROJECTIONS: Record<ProjectionName, { from: keyof AgentCtx; fn: (ctx: AgentCtx) => unknown }> =
+  Object.fromEntries(
+    // `from` 在声明里是 `string`（那一层够不到 `keyof AgentCtx`，见那个文件头的说明）；
+    // 每个名字都真的是 ctx 的格名，由 `tests/frame-projections.test.ts` 断言
+    PROJECTION_NAMES.map((name) => [
+      name,
+      { from: PROJECTIONS[name].from as keyof AgentCtx, fn: PROJECTION_IMPL[name] },
+    ]),
+  ) as Record<ProjectionName, { from: keyof AgentCtx; fn: (ctx: AgentCtx) => unknown }>
+
 /**
  * 把**一个块**的 `frame:` 声明编成 `FrameSpec`。没写 `frame:` 就返回 `null`，
  * 消费方回退到代码里那份 —— **迁移因此可以逐个节点做，不必一次全搬**。
@@ -180,7 +209,8 @@ export function frameSpecFromBlock(b: DocBlock, node: string): FrameSpec | null
   return {
     node,
     fields: f.fields.map((x) => {
-      const p = x.project ? FRAME_PROJECTIONS[x.project] : undefined
+      // 文件是手写的 ⇒ 投影名是不可信输入，查表前先过 `isProjectionName`
+      const p = x.project && isProjectionName(x.project) ? FRAME_PROJECTIONS[x.project] : undefined
       if (x.project && !p) {
         throw new Error(
           `${where} 里，frame 投影 '${x.project}' 不在注册表里 —— ` +