approval-md 0.3.0 → 0.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "approval-md",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Human approval for agent actions. CLI runtime for the approval.md convention (pre-release).",
   "type": "module",
   "bin": {
@@ -18,6 +18,7 @@
     "schema",
     "docs/adapter-api.md",
     "docs/cli-reference.md",
+    "docs/README-extended.md",
     "SPEC.md",
     "README.md",
     "LICENSE",
@@ -57,5 +58,6 @@
     "ajv-formats": "3.0.1",
     "better-sqlite3": "12.11.1",
     "yaml": "2.9.0"
-  }
+  },
+  "gitHead": "fb0cf987985c2b9884ebe46b7b3b4419147d057e"
 }

package/schema/event.schema.json

@@ -92,6 +92,13 @@
         }
       ]
     },
+    "daemon": {
+      "type": "string",
+      "minLength": 1,
+      "maxLength": 64,
+      "pattern": "^[a-z0-9][a-z0-9._-]*$",
+      "description": "SPEC.md §8 (amended, APRV-383): WHICH daemon instance appended this record. Present exactly on the records a daemon wrote, so a tenant whose daemon is hosted by another party can open their own log and tell which host process acted on their behalf — before this field every daemon-written record carried the same generic `system:daemon` actor and nothing else. The value is either the id declared in the daemon's launch environment (`APPROVAL_DAEMON_ID`) or `daemon-` followed by the eight hex digits of the instance id `approval doctor` prints as its `keychain-scope` suffix, so it is stable across restarts on one machine and keystore without anything being stored.\n\nOPTIONAL and additive: every record written before the field existed still validates and still verifies, and the ABSENCE of the field is absence — it is never read as a claim that no daemon wrote the record, because until this task no daemon could say.\n\nSELF-REPORTED, and bounded by SPEC.md §11.1 invariant 4 in the only way a self-reported field may be: a policy MAY list the ids permitted to write (`daemons` in `policy.schema.json`), an id the list does not name is REFUSED at the write boundary (`daemon-not-allowed`), and an id the list DOES name gains nothing at all — no verdict, autonomy, budget, floor, sampling draw, token or TTL reads this field or that list. Its SHAPE is constrained here for the reason `payload.harness_version`'s is: the value comes from a launch environment and is being written into an append-only log, so a banner, a path, a newline or a shell fragment cannot arrive through it, and two ids differing only in case would be two ids nobody can tell apart on a phone."
+    },
     "task": {
       "type": "string",
       "minLength": 1,
@@ -118,9 +125,10 @@
             "cursor",
             "codex",
             "grok",
-            "muse"
+            "muse",
+            "hermes"
           ],
-          "description": "SPEC.md §10.1 (amended, APRV-227): which harness hook wrote this record. A closed set, extended only by a task that adds the case, because it is the discriminator a reader scopes `harness_version` by: one log holds the records of every harness that ever wrote to it, and a version with no binary named beside it is a string nobody can compare against anything. OPTIONAL and additive — every record written before the field existed still validates and still verifies, and the two fields travel together or not at all. APRV-358 added `grok`, which APRV-243 shipped an adapter for and never added here: a Grok session's manual-class registration failed validation at the write boundary, so the request never reached a human. Closed does not mean hand-maintained any more. This list is pinned set-equal to `HARNESS_KINDS` in `src/core/harness-version.ts` by `tests/harness-enum.test.ts`, along with every other place a harness name is enumerated, so the next adapter cannot land with the enum left behind."
+          "description": "SPEC.md §10.1 (amended, APRV-227): which harness hook wrote this record. A closed set, extended only by a task that adds the case, because it is the discriminator a reader scopes `harness_version` by: one log holds the records of every harness that ever wrote to it, and a version with no binary named beside it is a string nobody can compare against anything. OPTIONAL and additive — every record written before the field existed still validates and still verifies, and the two fields travel together or not at all. APRV-358 added `grok`, which APRV-243 shipped an adapter for and never added here: a Grok session's manual-class registration failed validation at the write boundary, so the request never reached a human. Closed does not mean hand-maintained any more. This list is pinned set-equal to `HARNESS_KINDS` in `src/core/harness-version.ts` by `tests/harness-enum.test.ts`, along with every other place a harness name is enumerated, so the next adapter cannot land with the enum left behind. APRV-398 added `hermes`, the Hermes Agent adapter, through that pinning rather than after it."
         },
         "harness_version": {
           "type": "string",
@@ -833,6 +841,36 @@
         }
       }
     },
+    {
+      "$comment": "SPEC.md §8 (amended, APRV-447, pending sign-off): a harness `execution.started` carries `policy_sha256`, the SHA-256 of the attested policy the write boundary re-checked the action's class against when it recorded the start (on the hook route the verdict was drawn from the hook's own earlier read, so a re-attest landing between the two leaves the stamp naming the policy in force at the append). Before it, a policy-authorized start (autonomous, supervised, an unselected supervised-live draw) named no policy at all, and a reader had to reconstruct the rules in force from the latest `policy.updated` before the record's seq; a granted start could reach its policy through `grant_seq` and carries the stamp too, written by the same code. The runtime assigns the value at the write boundary from its own attestation check, exactly as it assigns `policy_sha256` on `approval.requested` and `ts` on every gate-typed event: no caller parameter carries it, and a caller-supplied value of the same name is ignored. No verdict, budget, draw or refusal reads it back, so §11.1 invariant 4 is untouched. It is covered by the record hash like every other payload field. OPTIONAL and additive: every record written before the field existed still validates and still verifies, an `execution.started` written by any other path records none, and only the SHAPE is constrained here, a 64-character lowercase hex digest. Whether the hash names an attestation the log actually carries is not expressible in a schema that sees one record. The field name is a stable contract: downstream followers of the log use it to join a start to the rules it ran under.",
+      "if": {
+        "type": "object",
+        "properties": {
+          "event": {
+            "const": "execution.started"
+          }
+        },
+        "required": [
+          "event"
+        ]
+      },
+      "then": {
+        "type": "object",
+        "properties": {
+          "payload": {
+            "type": "object",
+            "properties": {
+              "policy_sha256": {
+                "type": "string",
+                "pattern": "^[a-f0-9]{64}$",
+                "description": "SPEC.md §8 (amended, APRV-447): SHA-256 (lowercase hex) of the attested policy file's exact bytes the write boundary re-checked this start's class against, stamped by the runtime at the write boundary. Never a caller's parameter and never an input to a verdict.",
+                "examples": ["5f1c0de9a3b7e2d4c6f8091a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e"]
+              }
+            }
+          }
+        }
+      }
+    },
     {
       "$comment": "SPEC.md §10.3 (amended, APRV-38): a decision collected as part of a batch gesture carries the batch's channel delivery id as a first-class payload field. Optional — a unit decision has no batch — and constrained only when present, so the field can never arrive as an empty string or a number that audit would have to guess at.",
       "if": {
@@ -1126,6 +1164,25 @@
                 "type": "string",
                 "pattern": "^[a-f0-9]{64}$",
                 "description": "SPEC.md §9/§10.3 (APRV-119): SHA-256 (lowercase hex) over the UTF-8 text of the canonical rendering of this request's payload, as produced by the versioned deterministic renderer named inside that text."
+              },
+              "harness_cap_ms": {
+                "type": "integer",
+                "minimum": 60001,
+                "maximum": 86400000,
+                "description": "SPEC.md §6 (APRV-423): the ceiling, in milliseconds, that the harness running the requesting hook imposes on that hook's own process — Hermes caps a `pre_tool_call` entry at 300 s, Claude Code kills the hook at the `timeout` in its settings file. A BOUNDED INPUT and never a deadline of its own: the runtime judges the request against the SHORTER of this minus a fixed margin and the policy's `defaults.approval_ttl`, so a stated cap can only move the lapse EARLIER (§11.1 invariant 4). The minimum is HARNESS_CAP_MARGIN_MS + 1 (src/core/harness-wait.ts, 60 000 ms; tests/harness-cap-ttl.test.ts pins the two equal): a cap at or below the margin leaves a zero-length window, a question that lapses as it is asked, and the hook refuses such a configuration before it appends, so a record carrying one could only come from a caller that skipped the hook and is refused here. Above 24 h is a number no harness contract states."
+              }
+            },
+            "dependentSchemas": {
+              "harness_cap_ms": {
+                "$comment": "APRV-423. A record carrying a harness ceiling MUST also declare `execution: \"harness\"`. The ceiling shortens the window in which this request may be decided, and a request that mints an execution token would otherwise hold an authorization with a longer shelf life than the question that produced it. A schema sees one record, which is exactly enough to see both fields, so the pairing is refused at the write boundary rather than left to a caller's discipline.",
+                "properties": {
+                  "execution": {
+                    "const": "harness"
+                  }
+                },
+                "required": [
+                  "execution"
+                ]
               }
             }
           }

package/schema/fixtures/event/invalid/daemon-id-malformed.json

@@ -0,0 +1,15 @@
+{
+  "seq": 63,
+  "ts": "2026-09-20T11:06:02Z",
+  "event": "audit.sampled",
+  "task": "task-311",
+  "action_key": "task-311:digest:2026-09-20",
+  "actor": "system:auditor",
+  "daemon": "Village Goa 1\nrate: 1.0",
+  "payload": {
+    "rate": 0.1
+  },
+  "alg": "sha256/jcs",
+  "prev": "07453feb30c2b0b1a2806398cdd17b38d98f9abf52b8a75ca42878c9101d8264",
+  "hash": "9d4c0be1a7fb25308c6ef4a1d0b39724ce85f16a2b0d7c39e8145af62b0c73d8"
+}

package/schema/fixtures/event/invalid/execution-started-truncated-policy-sha256.json

@@ -0,0 +1,18 @@
+{
+  "seq": 9,
+  "ts": "2026-10-04T09:19:02Z",
+  "event": "execution.started",
+  "task": "hook:sess-1:tu-1",
+  "action_key": "hook:sess-1:tu-1:files.write.workspace",
+  "actor": "agent:claude-code",
+  "payload": {
+    "class": "files.write.workspace",
+    "est_cost_usd": "0",
+    "execution": "harness",
+    "payload_hash": "9f2b1c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f809",
+    "policy_sha256": "5f1c0de9a3b7"
+  },
+  "alg": "sha256/jcs",
+  "prev": "d973375d6aeec5e6cd2de3a0f7dc8f5bc1d9be77225f9af0f851e7fc519a07c3",
+  "hash": "707b79cfa14ec43224c8f71a4fee3ddbff52369f82525aab19bec18c369d5cad"
+}

package/schema/fixtures/event/invalid/harness-cap-at-margin.json

@@ -0,0 +1,16 @@
+{
+  "seq": 76,
+  "ts": "2026-09-22T08:34:20Z",
+  "event": "approval.requested",
+  "task": "hook:hermes-sess-1:tool-12",
+  "action_key": "hook:hermes-sess-1:tool-12:deps.add",
+  "actor": "agent:hermes",
+  "payload": {
+    "class": "deps.add",
+    "execution": "harness",
+    "harness_cap_ms": 60000
+  },
+  "alg": "sha256/jcs",
+  "prev": "1515151515151515151515151515151515151515151515151515151515151515",
+  "hash": "1616161616161616161616161616161616161616161616161616161616161616"
+}

package/schema/fixtures/event/invalid/harness-cap-fractional.json

@@ -0,0 +1,16 @@
+{
+  "seq": 74,
+  "ts": "2026-09-22T08:33:19Z",
+  "event": "approval.requested",
+  "task": "hook:hermes-sess-1:tool-10",
+  "action_key": "hook:hermes-sess-1:tool-10:deps.add",
+  "actor": "agent:hermes",
+  "payload": {
+    "class": "deps.add",
+    "execution": "harness",
+    "harness_cap_ms": 299999.5
+  },
+  "alg": "sha256/jcs",
+  "prev": "1313131313131313131313131313131313131313131313131313131313131313",
+  "hash": "1414141414141414141414141414141414141414141414141414141414141414"
+}

package/schema/fixtures/event/invalid/harness-cap-negative.json

@@ -0,0 +1,16 @@
+{
+  "seq": 73,
+  "ts": "2026-09-22T08:32:44Z",
+  "event": "approval.requested",
+  "task": "hook:hermes-sess-1:tool-9",
+  "action_key": "hook:hermes-sess-1:tool-9:deps.add",
+  "actor": "agent:hermes",
+  "payload": {
+    "class": "deps.add",
+    "execution": "harness",
+    "harness_cap_ms": -300000
+  },
+  "alg": "sha256/jcs",
+  "prev": "1212121212121212121212121212121212121212121212121212121212121212",
+  "hash": "1313131313131313131313131313131313131313131313131313131313131313"
+}

package/schema/fixtures/event/invalid/harness-cap-string.json

@@ -0,0 +1,16 @@
+{
+  "seq": 75,
+  "ts": "2026-09-22T08:33:52Z",
+  "event": "approval.requested",
+  "task": "hook:hermes-sess-1:tool-11",
+  "action_key": "hook:hermes-sess-1:tool-11:deps.add",
+  "actor": "agent:hermes",
+  "payload": {
+    "class": "deps.add",
+    "execution": "harness",
+    "harness_cap_ms": "300s"
+  },
+  "alg": "sha256/jcs",
+  "prev": "1414141414141414141414141414141414141414141414141414141414141414",
+  "hash": "1515151515151515151515151515151515151515151515151515151515151515"
+}

package/schema/fixtures/event/invalid/harness-cap-without-harness-execution.json

@@ -0,0 +1,16 @@
+{
+  "seq": 77,
+  "ts": "2026-09-22T08:34:51Z",
+  "event": "approval.requested",
+  "task": "hook:hermes-sess-1:tool-13",
+  "action_key": "hook:hermes-sess-1:tool-13:deps.add",
+  "actor": "agent:hermes",
+  "payload": {
+    "class": "deps.add",
+    "harness_cap_ms": 300000,
+    "payload_hash": "5f1c2a6f3e9d4b8a7c0e1d2b3a4958677889aabbccddeeff0011223344556677"
+  },
+  "alg": "sha256/jcs",
+  "prev": "1616161616161616161616161616161616161616161616161616161616161616",
+  "hash": "1717171717171717171717171717171717171717171717171717171717171717"
+}

package/schema/fixtures/event/invalid/harness-cap-zero.json

@@ -0,0 +1,16 @@
+{
+  "seq": 72,
+  "ts": "2026-09-22T08:32:01Z",
+  "event": "approval.requested",
+  "task": "hook:hermes-sess-1:tool-8",
+  "action_key": "hook:hermes-sess-1:tool-8:deps.add",
+  "actor": "agent:hermes",
+  "payload": {
+    "class": "deps.add",
+    "execution": "harness",
+    "harness_cap_ms": 0
+  },
+  "alg": "sha256/jcs",
+  "prev": "1111111111111111111111111111111111111111111111111111111111111111",
+  "hash": "1212121212121212121212121212121212121212121212121212121212121212"
+}

package/schema/fixtures/event/valid/approval-requested-harness-cap.json

@@ -0,0 +1,18 @@
+{
+  "seq": 71,
+  "ts": "2026-09-22T08:31:14Z",
+  "event": "approval.requested",
+  "task": "hook:hermes-sess-1:tool-7",
+  "action_key": "hook:hermes-sess-1:tool-7:deps.add",
+  "actor": "agent:hermes",
+  "channel": "telegram",
+  "payload": {
+    "class": "deps.add",
+    "execution": "harness",
+    "harness_cap_ms": 300000,
+    "payload_hash": "5f1c2a6f3e9d4b8a7c0e1d2b3a4958677889aabbccddeeff0011223344556677"
+  },
+  "alg": "sha256/jcs",
+  "prev": "1010101010101010101010101010101010101010101010101010101010101010",
+  "hash": "1111111111111111111111111111111111111111111111111111111111111111"
+}

package/schema/fixtures/event/valid/daemon-identity-declared.json

@@ -0,0 +1,17 @@
+{
+  "seq": 62,
+  "ts": "2026-09-20T11:05:44Z",
+  "event": "envelope.drift",
+  "task": "task-311",
+  "actor": "system:daemon",
+  "daemon": "village-goa-1",
+  "payload": {
+    "file": "backlog/tasks/task-311.md",
+    "declared_state": "requested",
+    "derived_state": "granted",
+    "reason": "state-mismatch"
+  },
+  "alg": "sha256/jcs",
+  "prev": "c0a1dd6b0f5a9b7fe7cf7d90cbb4aa4cf0a1eb2d5c7318cbbbd7a2b9efc33150",
+  "hash": "5b2f0c8419a7dd3e6f0b4a1c93de8027f5cbb1a40de92f7c3ab6051d8e4f29c7"
+}

package/schema/fixtures/event/valid/daemon-identity.json

@@ -0,0 +1,15 @@
+{
+  "seq": 61,
+  "ts": "2026-09-20T11:04:19Z",
+  "event": "audit.sampled",
+  "task": "task-311",
+  "action_key": "task-311:digest:2026-09-20",
+  "actor": "system:auditor",
+  "daemon": "daemon-3f2a9c11",
+  "payload": {
+    "rate": 0.1
+  },
+  "alg": "sha256/jcs",
+  "prev": "07453feb30c2b0b1a2806398cdd17b38d98f9abf52b8a75ca42878c9101d8264",
+  "hash": "c0a1dd6b0f5a9b7fe7cf7d90cbb4aa4cf0a1eb2d5c7318cbbbd7a2b9efc33150"
+}

package/schema/fixtures/event/valid/execution-started-policy-sha256.json

@@ -0,0 +1,18 @@
+{
+  "seq": 9,
+  "ts": "2026-10-04T09:19:02Z",
+  "event": "execution.started",
+  "task": "hook:sess-1:tu-1",
+  "action_key": "hook:sess-1:tu-1:files.write.workspace",
+  "actor": "agent:claude-code",
+  "payload": {
+    "class": "files.write.workspace",
+    "est_cost_usd": "0",
+    "execution": "harness",
+    "payload_hash": "9f2b1c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f809",
+    "policy_sha256": "5f1c0de9a3b7e2d4c6f8091a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e"
+  },
+  "alg": "sha256/jcs",
+  "prev": "d973375d6aeec5e6cd2de3a0f7dc8f5bc1d9be77225f9af0f851e7fc519a07c3",
+  "hash": "707b79cfa14ec43224c8f71a4fee3ddbff52369f82525aab19bec18c369d5cad"
+}

package/schema/fixtures/event/valid/harness-kind-hermes.json

@@ -0,0 +1,23 @@
+{
+  "seq": 56,
+  "ts": "2026-09-20T09:41:12Z",
+  "event": "task.registered",
+  "task": "hook:hermes-sess-1:toolu-16",
+  "actor": "agent:hermes",
+  "payload": {
+    "state": "proposed",
+    "actions": [
+      {
+        "class": "deps.add",
+        "summary": "npm install --save-dev oxlint",
+        "idempotency_key": "hook:hermes-sess-1:toolu-16:deps.add",
+        "payload_hash": "4d0a9c2b7e5f13860ad4c9b217e3f508cc61a7d2394b8e05f7ca61d3b8092e4f"
+      }
+    ],
+    "harness": "hermes",
+    "harness_version": "hermes 0.21.3"
+  },
+  "alg": "sha256/jcs",
+  "prev": "7d925ec380b14fa6c05e971b3d4287ac6fb015e93c2a480df6b1e7c05a83942f",
+  "hash": "e1f6a30c4d7b92815ac0fe43b6d258907cb14fe2839a5d07f4cb62e1a9350b7d"
+}

package/schema/fixtures/policy/invalid/daemons-malformed-id.json

@@ -0,0 +1,10 @@
+{
+  "version": "0.1",
+  "defaults": {
+    "autonomy": "manual"
+  },
+  "daemons": ["Village-Goa-1"],
+  "classes": {
+    "communicate.email.external": { "autonomy": "manual" }
+  }
+}

package/schema/fixtures/policy/valid/daemons-allowlist.json

@@ -0,0 +1,19 @@
+{
+  "version": "0.1",
+  "defaults": {
+    "autonomy": "manual",
+    "channel": "telegram",
+    "approval_ttl": "30m",
+    "on_expiry": "reject"
+  },
+  "approvers": {
+    "carter": {
+      "channels": ["telegram", "cli"],
+      "senders": { "telegram": "5551234567" }
+    }
+  },
+  "daemons": ["daemon-3f2a9c11", "village-goa-1"],
+  "classes": {
+    "communicate.email.external": { "autonomy": "manual" }
+  }
+}

package/schema/fixtures/policy-md/invalid/schema-invalid-agent-may-request.md

@@ -0,0 +1,21 @@
+# Approval Policy
+
+Two invalid spellings of `agent_may_request` (APRV-445): a string where a
+boolean belongs, and `true` on a `human-only` rule, which is inert to agents
+and may not be opened to them. Either alone fails the whole policy closed:
+`schema-invalid`.
+
+```yaml approval-policy
+version: "0.1"
+
+defaults:
+  autonomy: manual
+
+classes:
+  intent.publish.inferred.index:
+    autonomy: manual
+    agent_may_request: "yes"
+  account.credential:
+    autonomy: human-only
+    agent_may_request: true
+```

package/schema/fixtures/policy-md/valid/agent-may-request.md

@@ -0,0 +1,24 @@
+# Approval Policy
+
+`agent_may_request` (APRV-445) opens `approval propose` to classes the operator
+declares by name. The family line opens the branch; each member is still a line
+of its own, and the closed member says no for itself.
+
+```yaml approval-policy
+version: "0.1"
+
+defaults:
+  autonomy: manual
+  approval_ttl: 72h
+
+classes:
+  intent.publish.*:
+    autonomy: manual
+    agent_may_request: true
+  intent.publish.inferred.index: { autonomy: manual }
+  intent.publish.stated.index: { autonomy: autonomous }
+  intent.publish.closed:
+    autonomy: manual
+    agent_may_request: false
+  communicate.email.external: { autonomy: manual }
+```

package/schema/policy.schema.json

@@ -135,19 +135,43 @@
                     "12345678",
                     "hmac-sha256:3f2a9c11b4d7e6085a1c2f9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a"
                   ]
+                },
+                "edgeos": {
+                  "type": "string",
+                  "minLength": 1,
+                  "pattern": "^(?:[A-Za-z0-9][A-Za-z0-9._-]{0,127}|hmac-sha256:[0-9a-f]{64})$",
+                  "description": "The EdgeOS account this person decides from, in one of two forms (SPEC.md §5.2/§10.3, APRV-455, on the ground APRV-324 laid for `telegram`).\n\nRAW: the stable human id the EdgeOS identity service returns from `/humans/me` for the session the person authenticated in, as a string. The runtime treats it as OPAQUE and compares it byte for byte; the grammar admits what such an id is made of (an ASCII letter or digit, then up to 127 letters, digits, `.`, `_` or `-`), which covers a UUID and a decimal id alike. It holds no `:` and no whitespace, so a raw id can never be mistaken for the keyed form and can never contain the separator the runtime's sender index uses. Never an email address or a display name: those are chosen or changed by the person, and a mapping keyed on one would transfer an identity with an edit.\n\nKEYED: `hmac-sha256:<64 lowercase hex>`, the HMAC-SHA-256 of that same id under the operator-held `APPROVAL_SENDER_KEY`, exactly as for `telegram` and for the same reason: a published policy and a published log otherwise disclose the account.\n\nThe id reaches the runtime through `approval channel relay`, whose authenticated caller (the operator's control plane, holding `APPROVAL_RELAY_SECRET`) reports which EdgeOS session made the gesture. The daemon trusts that report the way it trusts the Telegram Bot API's `from.id`: it is operator trust in a relay, stated as such, and the resident cannot choose the id the relay attributes to them.",
+                  "examples": [
+                    "4f1c2a9e-7b3d-4e8a-9c21-5d6e7f8a9b0c",
+                    "hmac-sha256:3f2a9c11b4d7e6085a1c2f9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a"
+                  ]
                 }
               },
               "examples": [
                 { "telegram": "12345678" },
                 {
                   "telegram": "hmac-sha256:3f2a9c11b4d7e6085a1c2f9d8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a"
-                }
+                },
+                { "telegram": "12345678", "edgeos": "4f1c2a9e-7b3d-4e8a-9c21-5d6e7f8a9b0c" }
               ]
             }
           }
         }
       }
     },
+    "daemons": {
+      "type": "array",
+      "uniqueItems": true,
+      "description": "SPEC.md §5.2 (amended, APRV-383): the daemon instance ids permitted to append to this log. An ALLOWLIST, and the counterpart of `approvers` one layer down: that key says which humans may decide, this one says which daemon processes may write the records of those decisions down.\n\nIt exists for the hosted case (`design/hosted-daemon-identity.md`): when one party runs the daemon for another, records the daemon appends carry `daemon` (see `event.schema.json`) naming the instance that wrote them, and this list is how the tenant's own attested policy states which of them it expects. A daemon whose id this list does not name is refused AT THE WRITE BOUNDARY with `daemon-not-allowed` and writes nothing.\n\nABSENT means NO RESTRICTION, not an empty list: a policy that never declares the key behaves exactly as every policy written before it existed, and the daemon-written records still carry their id. An empty array is a policy that admits no daemon at all, which is a thing an author may say and the runtime will enforce.\n\nWhat being LISTED buys is nothing (SPEC.md §11.1 invariant 4). The id is self-reported by the writing process, so it may only ever cost a daemon the ability to write: no verdict, autonomy, budget, floor, sampling draw, token or TTL reads this key or the record field, and a hostile host holding the tenant's log handle is not what this defends against. What it catches is a daemon started against the wrong tenant's log, a second daemon nobody meant to leave running, and a rebuilt container whose id changed, each of which used to write records indistinguishable from the intended daemon's.\n\nIt is a top-level key rather than a member of the `daemon` block below, and the distinction is worth the two names: `daemon` (singular) is how THIS daemon reads a log it already may write, every key in it a latency setting whose strictest value is the default, while `daemons` (plural) is an ENFORCEMENT key deciding WHICH daemons may write at all. Read only from an ATTESTED policy, like every other fact a refusal is derived from.",
+      "items": {
+        "type": "string",
+        "minLength": 1,
+        "maxLength": 64,
+        "pattern": "^[a-z0-9][a-z0-9._-]*$",
+        "description": "One daemon instance id, in the same grammar the `daemon` record field carries: lowercase letters, digits, `.`, `-` and `_`, starting with a letter or digit. Either an id the operator declared in that daemon's launch environment through `APPROVAL_DAEMON_ID`, or the derived `daemon-<instance id>` form that `approval status` and `approval doctor` print for the instance they are run against."
+      },
+      "examples": [["daemon-3f2a9c11"], ["village-goa-1", "village-goa-2"]]
+    },
     "classes": {
       "type": "object",
       "additionalProperties": false,
@@ -213,7 +237,7 @@
     "daemon": {
       "type": "object",
       "additionalProperties": false,
-      "description": "APRV-217 (docs/proposals/incremental-prefix-proof.md): how the long-lived readers of this log prove a cached prefix before they reuse it. Read by `approval daemon run` and `approval up` and by nothing else: one-shot processes, the Claude Code hook included, always prove in full, and `approval log verify` and `approval doctor` never use the cache at all. Every key here is a LATENCY setting whose strictest value is the default, so a policy that omits the block, or the whole block, behaves exactly as the runtime did before it existed.",
+      "description": "APRV-217 (docs/proposals/incremental-prefix-proof.md): how the long-lived readers of this log prove a cached prefix before they reuse it. Read by `approval daemon run` and `approval up` and by nothing else: one-shot processes, the Claude Code hook included, always prove in full, and `approval log verify` and `approval doctor` never use the cache at all. Every key here is a LATENCY setting whose strictest value is the default, so a policy that omits the block, or the whole block, behaves exactly as the runtime did before it existed. Not to be confused with the top-level `daemons` list above (APRV-383), which is an enforcement key naming WHICH daemon instances may append to this log; this block is how a daemon that may already write reads.",
       "properties": {
         "read_proof": {
           "type": "string",
@@ -402,9 +426,9 @@
     },
     "senderChannel": {
       "type": "string",
-      "enum": ["telegram"],
-      "description": "SPEC.md §10.3 (amended, APRV-324): a channel whose transport attributes a gesture to an account id, and therefore the only kind of channel an `approvers.<id>.senders` entry may name. `telegram` qualifies because the Bot API reports `callback_query.from.id`, which the sender cannot choose. `web` and `cli` are deliberately absent: an unauthenticated form post names nobody and a local process names whoever runs it, so a sender mapping for either would be a binding the runtime cannot check and an identity key the channel cannot support.",
-      "examples": ["telegram"]
+      "enum": ["telegram", "edgeos"],
+      "description": "SPEC.md §10.3 (amended, APRV-324; widened, APRV-455): a channel whose transport attributes a gesture to an account id, and therefore the only kind of channel an `approvers.<id>.senders` entry may name. `telegram` qualifies because the Bot API reports `callback_query.from.id`, which the sender cannot choose. `edgeos` qualifies on the same ground: the gesture arrives through `approval channel relay`, authenticated by a shared secret from the daemon's launch environment, from a control plane that attributes it to the EdgeOS `/humans/me` id of the session the person signed in with, which the person cannot choose either. In both cases the daemon trusts the relay's report of who acted, and that is operator trust (APRV-422: no hosted service has authority over decisions; the relay carries a person's gesture and decides nothing). `web` and `cli` are deliberately absent: an unauthenticated form post names nobody and a local process names whoever runs it, so a sender mapping for either would be a binding the runtime cannot check and an identity key the channel cannot support.",
+      "examples": ["telegram", "edgeos"]
     },
     "classPattern": {
       "type": "string",
@@ -415,7 +439,7 @@
       "type": "object",
       "additionalProperties": false,
       "required": ["autonomy"],
-      "description": "SPEC.md §5.1: a class rule. The shorthand form is `{ autonomy }` alone; the full form may add rates, `allow_irreversible`, `approvers` and `limits`. Both are this one shape — `autonomy` is always REQUIRED, since a rule without it cannot decide anything, and unknown keys are rejected so a typo'd constraint is never silently ignored.",
+      "description": "SPEC.md §5.1: a class rule. The shorthand form is `{ autonomy }` alone; the full form may add rates, `allow_irreversible`, `agent_may_request`, `approvers` and `limits`. Both are this one shape — `autonomy` is always REQUIRED, since a rule without it cannot decide anything, and unknown keys are rejected so a typo'd constraint is never silently ignored.",
       "allOf": [
         {
           "$comment": "SPEC.md §5.2 (amended, APRV-127): `live_rate` belongs to `supervised-live` and to nothing else. Required there, because a live mode with no fraction declares a control without saying how much of it runs, and the runtime would have to invent the number an author did not write. Forbidden everywhere else, because a rate sitting on a `manual`, `supervised-retro` or `autonomous` rule is a fraction its author believes is in force that nothing reads — the same silent no-op this schema's closed shape exists to prevent. APRV-185 adds `human-only` to that everywhere-else, and the `else` branch below already carries it with no new clause: a level whose actions no agent may take has no fraction of them to gate, so a `live_rate` written there is a control its author believes is running over a population of size zero.",
@@ -467,6 +491,22 @@
               }
             }
           }
+        },
+        {
+          "$comment": "SPEC.md §5.2 (amended, APRV-445): `agent_may_request: true` opens the `propose` verb to a class an operator declared, so the level it sits on must be one an agent may ask about. Refused on `human-only` as a load error: a human-only class is inert to agents (SPEC.md §11.1 invariant 9), and a flag saying an agent may file a request for one is a door the gate would only slam. False is admitted everywhere as the explicit spelling of the default.",
+          "if": {
+            "type": "object",
+            "properties": { "agent_may_request": { "const": true } },
+            "required": ["agent_may_request"]
+          },
+          "then": {
+            "type": "object",
+            "properties": {
+              "autonomy": {
+                "enum": ["supervised-live", "supervised", "supervised-retro", "autonomous", "manual"]
+              }
+            }
+          }
         }
       ],
       "properties": {
@@ -480,6 +520,10 @@
           "type": "boolean",
           "description": "SPEC.md §5.2/§7 (amended, APRV-317): explicit permission for truthful `reversible: false` actions matching this rule to retain its nonmanual autonomy. Omission or false preserves the manual floor. Every equally most-specific matching rule must say true; defaults and action metadata cannot supply it."
         },
+        "agent_may_request": {
+          "type": "boolean",
+          "description": "SPEC.md §5.2 (amended, APRV-445): whether an agent may open a request in this class with `approval propose`, naming the class itself and carrying its payload inline. Absent and false mean no. It is read two ways and only these two: on a key that names the class EXACTLY, and on a declared family key `<prefix>.*` the class falls under. `propose` additionally requires the class to be an exact key of `classes`, so a wildcard rule alone never makes a class proposable; the exact key's own value wins when it states one, and otherwise the most specific family that states one decides. Adding or changing it is a policy edit like any other and takes a human re-attestation, which voids pending requests (`policy-drift`)."
+        },
         "approvers": {
           "type": "array",
           "minItems": 1,