canon drafts + CUST-WP-0060: work-record canonization stages 1-2

- canon/standards/work-record-types_v0.1.md (+ machine registry .yaml):
  work-record umbrella, closed kind registry (workplan/task/intake/
  decision/engagement/register-entry), UUIDv7-internal + canonical-name
  layering, abstract lifecycles incl. intake, promotion as first-class
  transition, source-anywhere + generated index, tags, budgets,
  reconciliation loop. status: draft pending ratification
- canon/standards/autonomy-lanes_v0.1.md: binky AutonomyPolicy lane model
  promoted to fleet canon; lane as mandatory spine field; hub-owned
  time-boxing; attention as WIP-limited workstation. status: draft
- workplans/CUST-WP-0060 (hub 4555741c, T01-T07): ratification,
  terminology v0.2 extension, per-kind schemas, Forgejo CI validation,
  fix-consistency sidetrack detector (C-25), binky-control pilot with
  grandfathered ids, stage-3 handoff. Ratification pending as hub
  decision f4640f9e

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

canon/standards/autonomy-lanes_v0.1.md

@@ -0,0 +1,98 @@
+---
+id: canon-autonomy-lanes
+type: standard
+title: "Autonomy Lanes (Fleet) v0.1"
+domain: custodian
+status: draft
+version: "0.1"
+created: "2026-07-20"
+updated: "2026-07-20"
+scope: fleet
+related_workplans:
+  - CUST-WP-0060
+supersedes: none
+origin: binky-control/AutonomyPolicy.md (ratified for Binky 2026-07-16, DEC-2026-001)
+---
+
+# Autonomy Lanes (Fleet) v0.1
+
+> Draft pending founder ratification (CUST-WP-0060-T01). Promotes the
+> binky-control AutonomyPolicy lane model to fleet canon, unchanged in
+> substance. binky-control's `AutonomyPolicy.md` remains the company-level
+> policy instance; this standard makes the lane vocabulary and enforcement
+> rules fleet-wide.
+
+## The rule
+
+> If the responsible human is unavailable, the system must either continue
+> safely, prepare the next decision, or explicitly defer with evidence. It
+> must not silently idle.
+
+Valid states: `proceeding` | `prepared for review` | `deferred by policy`.
+Invalid state: `waiting because unsure`. Uncertainty triggers research,
+comparison, preparation, or risk classification — not paralysis.
+"Ask the human" is never the default.
+
+## Lanes
+
+| Lane | Name | Agent may | Human involvement |
+| --- | --- | --- | --- |
+| **green** | Safe autonomous | research, summarize, classify, draft, organize, test, prepare | none (human-on-the-loop via logs) |
+| **blue** | Reversible execution | internal docs, backlog updates, local scripts, reports, local commits | none, but logged |
+| **yellow** | Deferred approval | prepare external emails, invoices, offers, releases, payments | async approval via decision records |
+| **orange** | Time-window approval | customer/legal/accounting/banking actions needing business hours | engagement records, batched into command days |
+| **red** | Human-only | signing, strategic commitments, bank/credential changes, sensitive legal/HR/security | always; agents prepare packages only |
+
+Optimization target: **maximize green+blue throughput, queue yellow, batch
+orange, protect red from automation.** Risk-tiered gating (in-the-loop for
+irreversible actions, on-the-loop for recoverable ones) is the only
+oversight pattern that scales.
+
+## Lane as a spine field
+
+`lane` is a **mandatory field on every work record** (see
+`work-record-types_v0.1.md`) and on every agent instance manifest. The
+chain is closed end-to-end:
+
+```
+work record.lane → view routing (autopilot / decision / engagement)
+                 → harness tool profile (enforced allow-list)
+                 → ops-warden credential lane (catalog access)
+```
+
+Declaring a lane an item does not hold is a policy violation the harness
+must catch (tool profile refuses the run).
+
+## Approval packages (yellow and above)
+
+An agent hitting a lane boundary prepares a complete decision package,
+never a bare question: recommended action, reason, evidence links, risk
+level, reversibility, deadline (`needed_by`), attention cost, fallback if
+no response, options.
+
+## Human attention is a WIP-limited workstation
+
+The responsible human's capacity is modeled like any lane capacity:
+attention budget (minutes/day, max decisions/day, max deep topics/day) and
+availability as first-class state (`available | evening_window |
+unavailable | office_hour_day`), with an explicit escalation allow-list
+when unavailable (critical security incident, payment failure, legal
+deadline). Yellow routes to the decision view, orange to the engagement
+view, both subject to that capacity.
+
+**Time-boxing is hub-owned:** `needed_by` / `fallback_if_no_response`
+windows are watched by the hub → NATS → activity-core; a lapsed window
+raises the escalation or executes the declared fallback — never a human
+re-reading a file.
+
+## Raising autonomy
+
+Autonomy per area is raised only after the system proves reliable there,
+by explicit human decision recorded as a decision work record. Lane
+assignments are auditable history; lowering a lane needs no approval.
+
+## References
+
+- `binky-control/AutonomyPolicy.md` (origin instance)
+- `canon/standards/work-record-types_v0.1.md`
+- `research/2026-07-19-work-orchestration-best-practices.md` §2