node-autotask 0.43.0 → 0.45.0

package/docs/API.md

@@ -260,9 +260,9 @@ status → what the vendor does that triggers it.
 | `QueryTooLongError` | `QUERY_TOO_LONG` | policy | — | caller-requested `via: 'get'` whose serialized URL would exceed the 2048-char GET cap — the SDK never silently degrades to POST |
 | `StaleObjectError` | `STALE_OBJECT` | conflict | — | the caller-supplied `lastModifiedDate` no longer matches the vendor's current value (no `If-Match`/ETag exists) |
 | `ConfirmationRequiredError` | `CONFIRMATION_REQUIRED` | policy | — | a destructive / approval-gated op invoked without its exact confirmation flag (`invoke` governor, section 7) |
-| `DeleteBoundaryError` | `DELETE_BOUNDARY` | policy | — | `operations.recovery` `action: 'delete'` on a resource the vendored spec defines no DELETE for — refused PRE-SEARCH (zero wire; the boundary is the spec-derived plan audit, never a raw vendor 405; issue #9) |
-| `MarkerUnsafeIdError` | `MARKER_UNSAFE_ID` | policy | — | a `operations.recovery` match whose id is beyond `Number.MAX_SAFE_INTEGER` (unaddressable through the typed delete surface) — refused with the typed code, never a silent skip (issue #9, P1) |
-| `RecoveryTruncatedError` | `RECOVERY_TRUNCATED` | policy | — | the `operations.recovery` marker search tripped its match cap (more matches than `limit`) — refused instead of a silent truncation / silent empty (issue #9) |
+| `DeleteBoundaryError` | `DELETE_BOUNDARY` | policy | — | a delete on a resource the vendored spec defines no DELETE for — refused PRE-SEARCH (zero wire; the boundary is the spec-derived plan audit, never a raw vendor 405; issue #9). The throwing op (`operations.recovery`) was deleted in #289 — the refusal code stays in the write-outcome taxonomy |
+| `MarkerUnsafeIdError` | `MARKER_UNSAFE_ID` | policy | — | a marker-filtered match whose id is beyond `Number.MAX_SAFE_INTEGER` (unaddressable through the typed delete surface) — refused with the typed code, never a silent skip (issue #9, P1; the throwing op was deleted in #289 — the refusal code stays) |
+| `RecoveryTruncatedError` | `RECOVERY_TRUNCATED` | policy | — | the marker-filtered bounded search tripped its match cap (more matches than `limit`) — refused instead of a silent truncation / silent empty (issue #9; the throwing op was deleted in #289 — the refusal code stays) |
 | `AutotaskError` | `BUDGET_EXCEEDED` | policy | — (the call that would exceed it is not sent) | `operations.revenueRollup`: the pre-walk estimate exceeds `maxVendorCalls` (refused before any stream; `details: { phase: 'estimate', estimate, budget, suggestions }`) or the counting wrapper reached the budget mid-walk (`phase: 'walk'`; the partial fold is discarded) — `suggestedAction` names the narrowing (issue #234) |
 
 Retryable by contract: `NETWORK_ERROR`, `TIMEOUT`, `RATE_LIMITED`,
@@ -287,8 +287,7 @@ retryability: `emptyReason` (the pinned typed empty-reason — the miss's
 kind + note + authority + remedy; §11.10) and `pointerNote` (the
 known-unusable-op pointer sentence — the status/code are untouched, the
 note routes to the operation that works), plus the additive refusal /
-drift payloads (the `operations.recovery` `candidateIds` refusal, the #13
-shape-drift marker info). A non-pinned surface gets no `details` at all
+drift payloads (the #13 shape-drift `candidateIds` refusal). A non-pinned surface gets no `details` at all
 (no speculation). On the MCP tools' served error payload, `details` is
 passed through verbatim (live-verified 2026-10-04: the W-D3 pointer note
 rides a real `time_entries.getPosted` vendor 500 on the wire; that 500 is gone since 0.32.0, the pointer-note mechanism is unchanged) and the
@@ -685,6 +684,22 @@ carry paging parameters.
   when the limit or the guard truncated the walk and more records exist past
   the stop point; `pageDetails.count` is never surfaced (it is the current
   page's record count — `<resource>.count` is the total).
+  - **`walk: { maxRows: N }` — an explicit export cap (issue #350).**
+    `N` is a positive integer and replaces the total `limit` cap, so
+    `{ walk: { maxRows: 10_000 } }` can return 10,000 rows. `limit` still
+    validates as 1..2500 (default 500) and only sizes pages in this mode:
+    `min(500, limit)`. `truncated` and `hasMore` are true when the final
+    page was sliced, a next cursor remains, or the 1000-page guard stopped
+    the walk, even below `maxRows`; an exhausted exact-cap result reports
+    false. No extra page is fetched to decide completeness. With no `walk`,
+    the ordinary cap and result shape remain unchanged (`truncated` is
+    omitted). `walk` and `latest` cannot be combined. Through `invoke`, the
+    unscoped-walk guard estimates the explicit `maxRows` cap independently
+    of `limit`; narrow the filter or pass `acknowledgeUnscoped: true` when
+    a large unscoped walk is intended. When names are enabled (per call or
+    by client labels), explicit walks apply the existing label budget per
+    fetched vendor page, matching the iterator; invoke does not label the
+    combined result again. Ordinary invoked queries keep their per-call budget.
   - **`latest: N` (issue #59) — the N highest-`id` rows without caller paging.**
     The vendor has NO sort parameter (the vendored spec's `QueryModel` is
     exactly `maxRecords` / `includeFields` / `filter`), so `latest` is a
@@ -780,23 +795,28 @@ Vendor filter structure (swagger `Filter`, recursive):
   `project.<field>` is resolved before the query: the parent entity is read
   (`IncludeFields: ['id']`, at most 300 rows) with the relation's conditions,
   and the leaves become `<relation>ID in [ids]`. Supported by `queryBounded`
-  (and the invoke `query` op), `count` and `operations.aggregate`; the raw
-  `query()`/`queryAll()` walks do not rewrite.
+  (and the invoke `query` op), `count`, `operations.aggregate`, and the raw
+  `query()`/`queryAll()` walks.
   - Inside an `and` (and at the top level) all leaves of one relation share ONE
     parent read; inside an `or` each relation leaf is its own read. Direct
     conditions are untouched and may be mixed freely.
   - No parent match: an `and` matches nothing; an `or` drops that branch. When
     the whole filter matches nothing the child call is not issued: `queryBounded`
     returns `{ items: [], fetched: 0, hasMore: false, pagesWalked: 0,
-    relationNote }`, `count` returns `0`, aggregate group/sum carries
+    relationNote }` (plus `truncated: false` for an explicit `walk`),
+    `count` returns `0`, aggregate group/sum carries
     `relationNote`.
   - More than 300 matching parents: typed `AutotaskConfigError`, child call not
     issued (a capped parent set would be vendor-ordered, so partial totals would
     be biased). Narrow the relation conditions (e.g. a ticket date or status).
   - Pre-request (zero wire): unknown relation, a parent field outside the
-    parent's vendored field set, multi-hop (`ticket.company.x`) and `udf: true`
-    relation leaves are refused. The invoke field-name check skips relation
+    parent's vendored field set and multi-hop (`ticket.company.x`) are
+    refused. The invoke field-name check skips relation
     leaves (they are checked against the parent instead).
+  - Any dotted `udf: true` field is refused before metadata, parent queries,
+    scope counts or child requests, including self prefixes and unknown
+    prefixes (issue #351). Use an undotted tenant UDF name with `udf: true`;
+    `fieldCheck: false` does not bypass this rule.
 
   ```ts
   // company 123's time in October, hours per ticket: 2 calls (tickets ids, then the walk)
@@ -829,11 +849,20 @@ Vendor filter structure (swagger `Filter`, recursive):
   the cap). A GET path exists (`{ via: 'get' }`) and the SDK measures the
   serialized GET URL — over 2048 it throws `QueryTooLongError` (never a
   silent degradation).
-- `includeFields` passes through vendor column selection; the SDK never
-  invents column selection — one exception: when `includeFields` is set the
-  SDK always appends `id` (the vendor omits `id` from a row unless it is
-  named in the selection, and every caller needs the id to act on the row —
-  issue #59).
+- **Own-field aliases (issue #352):** a single self prefix — the resource
+  key, or a relation name targeting that resource — is stripped from
+  ordinary filter fields, `includeFields`, and aggregate `groupBy` / `sum`.
+  On tickets, `ticket.title` and `tickets.title` mean `title`; on time
+  entries, `time_entries.hoursWorked` means `hoursWorked`, while
+  `ticket.companyID` remains a parent relation filter. Aggregate date
+  suffixes are preserved (`time_entries.dateWorked@month` becomes
+  `dateWorked@month`), and result keys use the canonical unprefixed names.
+  Foreign and multi-hop names are never converted into own-field aliases.
+  Projection normalization applies on the first page and every cursor
+  continuation, without mutating the caller's input.
+- `includeFields` selects vendor columns after own-field normalization; the
+  SDK always appends `id` when omitted (the vendor omits `id` unless it is
+  selected, and callers need it to act on the row — issue #59).
 
 ## 6. Mutation safety
 
@@ -962,7 +991,48 @@ candidates and the error code when a resource could not resolve (empty
 the primary text field, exact match only; with `resolution.scanOnMiss` the
 bounded client-scan re-check (and its truncation cap) applies per resource. Returns
 `{ identifier, results: [{ resource, value, resolutionCost, scanned,
-scanTruncated, candidates, error? }], matches }`.
+scanTruncated, candidates, error? }], matches, matched }`.
+
+`match` defaults to `'exact'`. With `match: 'auto'`, every requested
+resource finishes its exact lookup before a contains search can start. Only
+a clean miss everywhere permits the contains sweep; an exact hit,
+ambiguity, truncated scan, unsupported resolver or lookup error suppresses
+it. Numeric ids and digit strings never fall back to contains. Auth,
+rate-limit, server, network, timeout and policy faults propagate.
+
+The contains sweep defaults to the client’s `resolution.maxScanRecords`,
+capped at 500. Optional `limit` must be an integer 1..500 and can only
+narrow that configured cap; invalid values refuse before lookup wire.
+Exact lookup sizes are unchanged. A singleton below the cap resolves; multiple matches
+report candidate ids, and a cap-full result reports `scanTruncated: true`
+and `RESOLUTION_TRUNCATED`, even if the cap is one. `matched` reports
+`'exact'` or `'contains'`; only the latter includes the full sweep in
+`contains`, including an empty sweep.
+
+**`resolveStaff(client, identifier, opts?)`** looks up Autotask resources
+by exact email, userName or name. Text matches require `isActive: true`
+and exclude API users by default, using tenant picklist labels on
+`licenseType` / `userType` rather than fixed numeric values. Numeric ids
+fetch directly and bypass active/API-user exclusions. `emailOnly: true`
+treats even digit strings as email; `includeApiUsers: true` includes API
+users in text matches. Options form a closed plain-object bag: flags must be
+booleans when present and limit must be an integer 1..10. Unknown keys, nulls
+and malformed options refuse with CONFIG_ERROR before metadata or lookup wire.
+
+Returns `{ identifier, lookup: 'id' | 'text', matches: [{ record, apiUser?,
+licenseTypeLabel? }], matchedCount, truncated, metadataState }`. `limit`
+is 1..10 (default 10); the text lookup reads at most 50 records.
+`matchedCount` is after exclusions and before the candidate limit, and is
+a lower bound when truncated. A live cursor or a candidate-limit cut sets
+`truncated: true`; a truncated singleton never proves uniqueness. Text
+misses return an empty `matches`; a numeric miss propagates `NOT_FOUND`.
+`metadataState` is `ok` when API-user labels were found, `none` when labels
+exist without an API label, `absent` when no labels are exposed, or `error`
+when metadata could not be read. Lookup continues if metadata is
+unavailable, and API-user classification is omitted when unproven. Text
+records honor the existing client `labels` setting through the shared row-label
+pass; optional `names` reports incomplete label coverage. Numeric gets keep
+their ordinary record shape.
 
 ### 7.3 `invoke(client, operation, args?, opts?)` — the write governor
 
@@ -989,7 +1059,8 @@ the mode pinned (§7.4). The governor rules (pinned):
   `queryBounded`** (server-side pagination): ONE invoke call returns a
   bounded, complete-enough result — the vendor cursor walk happens inside
   the SDK; the caller passes `limit` as the TOTAL cap (default 500, max
-  2500) and never owns a stream. `queryAll` keeps its raw behavior (the
+  2500), or an independent `walk.maxRows` export cap (section 4), and never
+  owns a stream. `queryAll` keeps its raw behavior (the
   unbounded walk; the catalog text steers the caller away for normal work);
 - a query's `includeFields` NAMES and its `filter` condition FIELD NAMES are
   validated **pre-request** (issues #119b + #125): the authority is the
@@ -1059,118 +1130,45 @@ be cross-mode-refused.
   Pinned by the full-surface suite (`test/operations/invoke/modes.test.ts`:
   all 1281 ops × 3 modes, zero wire).
 
-**Harness approval policy (recommended).** Require approval on every tool
-whose MCP annotation is `readOnlyHint !== true` — today exactly **267
-   tools**: the 265 dedicated write/delete tools (209 `effect=write` + 56
-   `effect=destructive`, every one of them has a dedicated tool) +
-`autotask_write` + `autotask_delete`. The remaining **635 tools** (the 622 dedicated read tools + the 10 core read tools + `autotask_read` +
-`autotask_catalog` + `autotask_describe`) all carry `readOnlyHint: true`
-and are safe ungated: every op they can route is `effect=read` (zero
-mutating requests — pinned by the test inventory, §6 of the split design).
-Refined class for the highest-risk ops: the **57 tools with
-`destructiveHint: true`** (56 dedicated delete tools + `autotask_delete`)
-additionally require `confirm === <operation key>` even inside
-`autotask_delete`, and the 3 approval-gated writes
-(`configuration_items.moveConfigurationItem`, `contacts.moveToCompany`,
-`resources.transferOwnership`) require the same confirm inside
-`autotask_write`. Migration: `autotask_invoke` is REPLACED by
-`autotask_read`/`autotask_write`/`autotask_delete` — update harness config
-(approve the 267 above) and remove any `autotask_invoke` entry. The rule is
-derivable from the registry `effect` column (and the mode tools' fixed
-annotations) — it never needs a hand-maintained name list.
-
-### 7.5 `recovery(client, input, opts?)` — the one-call recovery/cleanup op (issue #9)
+<!-- BEGIN GENERATED:approval-policy -->
+**Harness approval policy (recommended).** Require approval on every tool whose MCP annotation is `readOnlyHint !== true` — today exactly **246 tools**: the 244 dedicated write/delete tools (188 `effect=write` + 56 `effect=destructive`, every one of them has a dedicated tool) + `autotask_write` + `autotask_delete`. The remaining **599 tools** (the 586 dedicated read tools + the 10 core read tools + `autotask_read` + `autotask_catalog` + `autotask_describe`) all carry `readOnlyHint: true` and are safe ungated: every op they can route is `effect=read` (zero mutating requests). Refined class for the highest-risk ops: the **57 tools with `destructiveHint: true`** (56 dedicated delete tools + `autotask_delete`) additionally require `confirm === <operation key>` even inside `autotask_delete`. The approval-gated writes (`configuration_items.moveConfigurationItem`, `contacts.moveToCompany`) require the same confirm inside `autotask_write`. Migration: `autotask_invoke` is REPLACED by `autotask_read`/`autotask_write`/`autotask_delete` — update harness config and remove any `autotask_invoke` entry. The rule is derivable from the registry `effect` column and the mode tools’ fixed annotations; it never needs a hand-maintained name list.
+<!-- END GENERATED:approval-policy -->
+
+### 7.5 the `create` dry-run delete-boundary warning (issue #9)
 
 The delete-boundary reality (§11.1, §11.9): the vendored spec defines NO
 DELETE on many entity paths — most of them the campaign's own resources. A
 `create` that cannot be undone through the API leaves the created record as
-permanent residue once its id is lost (P1). `recovery` is the typed one-call
-path out — a cross-resource special op in the `operations` group (effect
-`write`, the governor's dry-run-first applies; `mcpTool`
-`autotask_recovery`, tier `extended`):
-
-```ts
-import { recovery } from 'node-autotask/operations';
-// find the scratch record a write just stamped (ONE bounded query, zero mutating wire):
-const r = await recovery(client, { resource: 'companies', marker: 'FULL100W-1791110339' });
-// r.delete.available === false + r.cleanup.note — the spec says the vendor has no DELETE.
-// where the vendor DOES allow it (delete available):
-const dry = await recovery(client, { resource: 'configuration_item_dns_records', marker: 'm', field: 'data', parentId: 42, action: 'delete' });
-const applied = await recovery(client, { resource: 'configuration_item_dns_records', marker: 'm', field: 'data', parentId: 42, action: 'delete' },
-  { dryRun: false, confirm: 'operations.recovery' });
-```
+permanent residue once its id is lost (P1). The one-call recovery op that
+turned the boundary into a typed, bounded path (the marker-filtered find +
+confirm-gated delete that shared the SAME generated boundary note) was
+deleted in #289 — no server consumer; the boundary data, the typed error
+codes and the dry-run warning remain (§11.9).
 
-- **`find`** (the default — a read): ONE bounded marker-filtered query
-  (server-side pagination; default `limit` 25, max 100) returns the matched
-  records' ids (`matches: [{ id, value }]`) + the delete-boundary fact
-  (`delete: { available, reason, authority }`) + the UI-only `cleanup` note.
-  Zero mutating wire.
-- **`delete`** (destructive, dry-run-first): the dry run performs the search
-  and reports the match set with **zero DELETE wire** (`simulated: true`);
-  the apply requires the exact confirm string (`confirm ===
-  'operations.recovery'` — the governor forwards the caller's `confirm`
-  through the trailing bag) and issues one DELETE per safe match id + one
-  verification read per id (`deleted: [{ id, verified, code? }]`).
-- **the marker field**: the `contains` filter runs on the name-like field
-  the write stamped — default the plan's `markerField` for the resource
-  (the spec-derived deterministic priority over the vendored model's field
-  set), pass `field` to override; REQUIRED when the resource has no
-  `markerField` (a `CONFIG_ERROR` names the candidates).
-- **P1 discipline — never a silent failure mode**:
-  - a delete on a delete-less resource refuses **PRE-SEARCH** with the typed
-    `DELETE_BOUNDARY` (zero wire — the boundary is the local spec audit,
-    never a raw vendor 405);
-  - a match whose id is beyond `Number.MAX_SAFE_INTEGER` is never a silent
-    skip: `delete` refuses with the typed `MARKER_UNSAFE_ID` (zero DELETE
-    wire); `find` marks the match `id: null` + `unsafeId: true`;
-  - a cap-tripped search (more matches than `limit`) refuses with the typed
-    `RECOVERY_TRUNCATED` — never a silent truncation, never a silent empty;
-  - an unknown `resource` refuses with the typed `RESOURCE_UNKNOWN` (the
-    same code `operations.relationshipMap` uses: carries the resource count
-    + the `autotask_catalog` pointer).
-- **the create dry run warns**: on a delete-less resource,
+- **The create dry run warns**: on a delete-less resource,
   `client.<resource>.create(data, { dryRun: true })` carries the
   report-only `delete-boundary` check (`ok: true` — `wouldApply` is
   preserved) + the boundary note in `warnings[]` (the SAME generated note
-  `recovery` serves — the describe and dry-run channels cannot drift).
-  Pinned by `test/operations/recovery.test.ts` (11 tests) + the full-surface
-  governor suite (`test/operations/invoke/modes.test.ts`).
+  the describe channel carries — the describe and dry-run channels cannot
+  drift). Pinned by `test/resources/mutation-safety.test.ts` + the
+  full-surface governor suite (`test/operations/invoke/modes.test.ts`).
 
-### 7.6 `fetchMany(client, items, opts?)` / `fetchByIds(client, items, opts?)` — bulk fetch by ids
+### 7.6 `fetchByIds(client, items, opts?)` — bulk fetch by ids
 
-Two cross-resource bulk reads with per-item typed results — one entry per
+The cross-resource bulk read with per-item typed results — one entry per
 input occurrence: `{ resource, id, found, value, error?: { code, httpStatus?,
 message } }`; a NOT_FOUND or fault on one item never aborts the rest; the
-result is `{ results, ok, failed }`. Both refuse pre-request (zero wire):
+result is `{ results, ok, failed }`. The op refuses pre-request (zero wire):
 non-numeric string ids (pointing at `operations.resolveAny` — canonical
 integer strings above 2^53 pass with their exact digits), parent-scoped
 children (their `get` needs `parentId`), unknown `fields` keys (the complete
 problem list in one message), unsafe number ids (the canonical-string
 pointer). The op never fabricates rows: values come only from a vendor 2xx
 (query row or GET record); a miss is a typed outcome, never a null-padded
-row.
-
-- **`fetchMany`** — up to 20 items (mixed resources; the pinned
-  `FETCH_MANY_MAX_ITEMS`; over → `CONFIG_ERROR` pre-request, zero wire),
-  one sequential GET per item. Per-item `fields?: string[]` is a client-side
-  projection (the GET returns the full model; projection is post-fetch, zero
-  extra wire).
-  **Live field validation (opt-in `opts.liveFields`, issue #66)**: when
-  `true`, each item's `fields` validate against the tenant's **live** entity
-  field metadata (the existing cached metadata channel — with
-  `fieldCache` configured a warm cache costs zero wire; a cold run is one
-  `entityInformation/fields` GET per DISTINCT resource in the batch) instead
-  of the vendored-spec field set alone. A resource whose metadata is
-  unavailable (network fault, vendor 5xx) falls back to the vendored-spec
-  set for THAT resource only — unavailability never throws and never blocks
-  the batch. When available the live set is authoritative: a field it lacks
-  is refused even if the spec lists it, and a live field the spec lacks is
-  accepted — a tenant whose live TimeEntry entity exposes `postedDate` (the
-  live record carries it even when the vendored model omits it) may project
-  it once `liveFields: true`; the default spec-only path still refuses it.
-  The default (no `liveFields`) is today's vendored-spec-only validation,
-  bit-for-bit, zero metadata wire. Field discovery in both modes:
-  `operations.fieldCatalog`.
+row. The per-item result shapes and the pre-request validation taxonomy are
+reused from the deleted `fetchMany` op (issue #289 — the shared `FetchMany*`
+result types kept their names).
+
 - **`fetchByIds`** — up to 500 items (mixed resources; the pinned
   `FETCH_BY_IDS_MAX_ITEMS`; `opts.maxItems` may lower the cap, never raise
   it; over → `CONFIG_ERROR` pre-request, zero wire). **Query-first**: per
@@ -1185,8 +1183,7 @@ row.
   limited to the plan-pinned blind surfaces). Wire cost: per resource
   `ceil(uniqueIds/250)` query calls + one `get` per query-missed id — a
   clean 500-id single-resource batch is **2 wire** (down from 500 sequential
-  GETs); the blind-surface worst case is 2 + up to 500 gets (fetchMany
-  parity, never worse). A chunk-level vendor fault faults every item of that
+  GETs); the blind-surface worst case is 2 + up to 500 gets. A chunk-level vendor fault faults every item of that
   chunk (the chunk's `code`/`httpStatus`) and the remaining chunks still run
   (input order is preserved across chunks and groups; a duplicate id gets its
   own entry with the identical outcome over one wire fetch).
@@ -1282,10 +1279,12 @@ wire):
   vendor casing via `operations.fieldCatalog`). An empty array / absent = the
   unfiltered call (the vendor-accepted no-filter shape rides the wire as
   `filter: []`; that is also the blind-predicate's stamp case).
-- **`groupBy` / `sum`** = exact vendor field names (validated against the
+- **`groupBy` / `sum`** = vendor field names, accepting the single own-field
+  prefix aliases of section 5 (normalized before validation and folding;
+  result keys are unprefixed). Names are validated against the
   resource's vendored field set pre-request — a hallucinated field is a shape
   error, not a silent fold-miss; the complete problem list in one typed error,
-  zero wire). Non-numeric/absent `sum` values contribute 0 (documented).
+  zero wire. Non-numeric/absent `sum` values contribute 0 (documented).
 - **`top`** (default 25, clamped 1..100) keeps the top-N groups (descending
   count; the deterministic group-key order breaks ties). **`limit`** (default
   2500 = the house `BOUNDED_QUERY_MAX_LIMIT`, clamped down to it) is the
@@ -1411,14 +1410,17 @@ notes cannot be deleted, so they never use create-then-delete.
 
   For per-ticket status / assignee / company use `operations.fetchByIds` on the group ticket ids
   (with `names: true`: `statusLabel`, `assignedResourceIDName`, `companyIDName`).
-- **`tz` on the `dateWorked` ops** (`postedWithin`, `dateWorkedWindow`, `customRange` and the relative
-  windows): the vendor stores `dateWorked` as a date-only value at 00:00 UTC, so the wire bounds are always whole UTC days.
-  For `postedWithin` / `dateWorkedWindow` / `customRange` the `from`/`to` days ARE the days, so `tz` is
-  validated but never shifts them. For the relative windows (`today`, `last7`, `lastFullMonth`, ...) `tz` picks which
-  calendar dates the window covers in that zone and the bounds are whole UTC days of those dates. (Before 0.24.0 a `tz`
-  behind UTC, e.g. `America/Los_Angeles`, selected the NEXT UTC day; live-verified 2026-10-23.)
+- **`dateWorked` windows are whole UTC days (issue #66; consolidated in #290)**: the vendor stores
+  `dateWorked` as a date-only value at 00:00 UTC, so the wire bounds are always whole UTC days.
+  `time_entries.dateWorkedWindow` takes `from`/`to` as `YYYY-MM-DD` and the days ARE the bounds — the
+  `tz` option is gone with the consolidation (before it, `tz` was validated but never shifted these
+  bounds), and the relative windows (`today`, `last7`, `lastFullMonth`, ...) are cut. (Before 0.24.0 a
+  `tz` behind UTC, e.g. `America/Los_Angeles`, selected the NEXT UTC day; live-verified 2026-10-23.)
+
+### 7.12 `timeEntries.approve` — time-entry approval levels (2026-10-26; cut in #292)
 
-### 7.12 `timeEntries.approve` — time-entry approval levels (2026-10-26)
+**Cut in #292** (confirmed unused write op — the CHANGELOG names the raw-composition
+alternative). The vendor facts below stand for anyone composing it by hand:
 
 `timeEntries.approve(id, opts?)` records one approval level for a time entry.
 The vendor keeps approvals in a separate entity (`BillingItemApprovalLevels`)
@@ -1550,9 +1552,8 @@ over a window, by account vertical": the registry op `operations.revenueRollup`
   label }`, absent otherwise). A label shared by several live picklist ids
   selects every one of them.
 - **`groupBy`** (default `['vertical', 'contractType']`): `vertical`
-  (`companies.marketSegmentID`), `contractType`, `contractCategory`,
-  `company`, `month` (the invoice month), `billingItemKind`, and the join
-  dimensions (#235):
+  (`companies.marketSegmentID`), `contractType`, `company`, `month` (the
+  invoice month), and the join dimensions (#235):
   - `contract` — `{ id, name }` (`contractName` joins the contract fetch).
   - `lineOfBusiness` — per billing line (`organizationalLevelAssociationID`;
     no contract-pointer fallback): three batch `id in` fetches (associations,
@@ -1563,26 +1564,18 @@ over a window, by account vertical": the registry op `operations.revenueRollup`
     their amount (LOB figures are floors). A row's `contracts` is "contracts
     with at least one line in this LOB", so per-LOB counts can sum to more than
     `totals.contracts`.
-  - `resource` — labour lines only (`billingItemType` Labor / Labor
-    Adjustment, or the FK fallback): `timeEntryID` → time entry → resource,
-    `{ id: resourceID, name: 'First Last' }`. Non-labour lines, and labour
-    lines with no time entry (e.g. an adjustment), are `{ id: null, label: 'n/a' }`.
-  - `billingCode` — `billingCodeID` → billing code `{ id, name }`; a line
-    without one is `{ id: null, label: 'none' }`.
 
   Each row key is `{ id, label?, name?, division? }`: picklist text in
-  `label`; vendor entity text (untrusted — company, contract, LOB level2,
-  resource and billing-code names) in `name`, and the LOB division (level1
-  name, also untrusted) in `division`. Missing values get their own row
-  (`unassigned`, `uncategorised`, `no LOB assigned`, `n/a`, `none`); a value
-  the picklist does not serve stays id-only and is listed in
-  `coverage.blindSurfaces`. A join id the `id in` fetch does not return is
-  never guessed: the line goes to `coverage.excluded.unresolvedAssociations`
-  (association or its level1/level2), `unresolvedTimeEntries` (time entry or
-  its resource) or `unresolvedBillingCodes`, with its amount. These buckets
-  (and `coverage.lineOfBusiness`) appear only when their dimension is grouped;
-  the line projection grows by `organizationalLevelAssociationID`,
-  `timeEntryID` / the type fields and `billingCodeID` the same way.
+  `label`; vendor entity text (untrusted — company, contract and LOB level2
+  names) in `name`, and the LOB division (level1 name, also untrusted) in
+  `division`. Missing values get their own row (`unassigned`,
+  `no LOB assigned`); a value the picklist does not serve stays id-only and is
+  listed in `coverage.blindSurfaces`. A join id the `id in` fetch does not
+  return is never guessed: the line goes to
+  `coverage.excluded.unresolvedAssociations` (association or its level1/level2)
+  with its amount. The bucket (and `coverage.lineOfBusiness`) appears only
+  when its dimension is grouped; the line projection grows by
+  `organizationalLevelAssociationID` the same way.
 - **Rows** are sorted by revenue descending, then ids; `top` (default 100,
   max 100) keeps the head and folds the tail into `rowsTruncated`. `totals`
   always cover every row.
@@ -1709,19 +1702,19 @@ const lob = await revenueRollup(client, { tenantWide: true, dateFrom: '2025-07-0
 ## 8. Resource surface
 
 <!-- BEGIN GENERATED:api-per-entity -->
-Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page guarded), `queryBounded` (server-side pagination — one call walks the cursor until `limit` TOTAL records, default 500 / max 2500, with a `hasMore` flag; the MCP `query` surface, routed by `invoke`), `queryAll` (collect → `T[]` — the unbounded raw walk), `count`, `get` (id → record; `item: null` → `NotFoundError`), `create` / `update` / `delete` (where the vendor defines them — mutations take a `MutationOpts` bag: `{ dryRun, lastModifiedDate?, maxRetries? }` (issue #105: `maxRetries` overrides the configured retry budget for every request the mutation issues; `0` = exactly one send per request)), plus the helper floor where the plan declares it: `resolve` (all 121), `search` (40 — bounded contains on the resource text field), `getContext` (5 workflow resources), `findBy<Field>` (3), `createIfNotExists` (14). Entity metadata on every resource: `getEntityInfo`, `getFieldInfo`, `getUdfInfo` (UDF-capable 16). Parent-scoped children take `(parentId, id)` on the CRUD methods and require `parentId` on `createIfNotExists` (the scoped create POSTs the scoped collection; the dedup query stays global); `query`/`count`/`resolve`/`search` stay global (narrow with a `parentField` filter). Scoped `update` PATCHes the collection (the vendor keys the record by the id in the body).
+Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page guarded), `queryBounded` (server-side pagination — one call walks the cursor until the total cap: `limit` (default 500 / max 2500), or independent `walk.maxRows` for exports (pages stay `min(500, limit)`); `hasMore` reports incomplete walks, and explicit walks also carry `truncated`; the MCP `query` surface, routed by `invoke`), `queryAll` (collect → `T[]` — the unbounded raw walk), `count`, `get` (id → record; `item: null` → `NotFoundError`), `create` / `update` / `delete` (where the vendor defines them — mutations take a `MutationOpts` bag: `{ dryRun, lastModifiedDate?, maxRetries? }` (issue #105: `maxRetries` overrides the configured retry budget for every request the mutation issues; `0` = exactly one send per request)), plus the helper floor where the plan declares it: `resolve` (122 of 129 — 7 lack it), `search` (41 — bounded contains on the resource text field), `getContext` (5 workflow resources); the `findBy<Field>` methods (findBySerial, findByTicketNumber, findByEmail) are class methods, not plan-declared special ops. Entity metadata on every resource: `getEntityInfo`, `getFieldInfo`, `getUdfInfo` (UDF-capable 16). Parent-scoped children take `(parentId, id)` on the CRUD methods and require `parentId` on `createIfNotExists` (the scoped create POSTs the scoped collection; the dedup query stays global); `query`/`count`/`resolve`/`search` stay global (narrow with a `parentField` filter). Scoped `update` PATCHes the collection (the vendor keys the record by the id in the body).
 
 | resource key | apiEntity | kind | tier | parent | standard ops present | special ops | mcpTool |
 |--------------|-----------|------|------|--------|----------------------|-------------|---------|
 | `appointments` | Appointment | entity | extended | no | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_appointment_get |
 | `billing_codes` | BillingCode | entity | extended | no | query, count, get, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_billingCode_get |
 | `billing_item_approval_levels` | BillingItemApprovalLevel | entity | extended | no | query, count, get, create | — | autotask_billingItemApprovalLevel_get |
-| `billing_items` | BillingItems | entity | extended | no | query, count, get, update, resolve | customRange, getEntityInfo, getFieldInfo, getUdfInfo, last14, last24h, last30, last7, last90, lastFullFortnight, lastFullMonth, lastFullQuarter, lastFullWeek, today, yesterday | autotask_billingItems_get |
-| `change_request_links` | ChangeRequestLink | entity | extended | no | query, count, get, create, delete, resolve | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_changeRequestLinks_get |
+| `billing_items` | BillingItems | entity | extended | no | query, count, get, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_billingItems_get |
+| `change_request_links` | ChangeRequestLink | entity | extended | no | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_changeRequestLinks_get |
 | `checklist_libraries` | ChecklistLibrary | entity | extended | no | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_checklistLibrary_get |
 | `checklist_library_checklist_items` | ChecklistLibraryChecklistItem | entity | extended | yes (checklist_libraries) | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_checklistLibraryChecklistItem_get |
 | `classification_icons` | ClassificationIcon | entity | advanced | no | query, count, get, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_classificationIcon_get |
-| `companies` | Company | entity | core | no | query, count, get, create, update, resolve, search, getContext | fullProfile, getEntityInfo, getFieldInfo, getUdfInfo, prepareCrmWrite, searchByDomain, searchByIdentity, unbilledWork, upsertByName | autotask_company_get |
+| `companies` | Company | entity | core | no | query, count, get, create, update, resolve, search, getContext | fullProfile, getEntityInfo, getFieldInfo, getUdfInfo, prepareCrmWrite, searchByDomain, searchByIdentity, unbilledWork | autotask_company_get |
 | `company_alerts` | CompanyAlert | entity | extended | yes (companies) | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_companyAlert_get |
 | `company_locations` | CompanyLocation | entity | extended | yes (companies) | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_companyLocation_get |
 | `company_notes` | CompanyNote | entity | extended | yes (companies) | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_companyNote_get |
@@ -1736,15 +1729,15 @@ Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page gu
 | `configuration_item_ssl_subject_alternative_names` | ConfigurationItemSslSubjectAlternativeName | entity | extended | yes (configuration_items) | query, count, get, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_configurationItemSslSubjectAlternativeName_get |
 | `configuration_item_types` | ConfigurationItemType | entity | extended | no | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_configurationItemTypes_get |
 | `configuration_item_webhooks` | ConfigurationItemWebhook | entity | extended | yes (configuration_items) | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_configurationItemWebhook_get |
-| `configuration_items` | ConfigurationItem | entity | core | no | query, count, get, create, update, resolve, search, getContext | createIfNotExists, findBySerial, getEntityInfo, getFieldInfo, getUdfInfo, moveConfigurationItem, profile | autotask_configurationItems_get |
+| `configuration_items` | ConfigurationItem | entity | core | no | query, count, get, create, update, resolve, search, getContext | findBySerial, getEntityInfo, getFieldInfo, getUdfInfo, moveConfigurationItem, profile | autotask_configurationItems_get |
 | `contact_group_contacts` | ContactGroupContacts | entity | extended | no | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contactGroupContacts_get |
 | `contact_groups` | ContactGroups | entity | extended | no | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contactGroups_get |
 | `contact_webhooks` | ContactWebhook | entity | extended | yes (contacts) | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contactWebhook_get |
-| `contacts` | Contact | entity | core | yes (companies) | query, count, get, create, update, delete, resolve, search, getContext | findByEmail, getEntityInfo, getFieldInfo, getUdfInfo, moveToCompany, upsertByEmail | autotask_contact_get |
+| `contacts` | Contact | entity | core | yes (companies) | query, count, get, create, update, delete, resolve, search, getContext | findByEmail, fullProfile, getEntityInfo, getFieldInfo, getUdfInfo, moveToCompany | autotask_contact_get |
 | `contract_billing_rules` | ContractBillingRule | entity | extended | yes (contracts) | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractBillingRule_get |
 | `contract_block_hour_factors` | ContractBlockHourFactor | entity | extended | yes (contracts) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractBlockHourFactor_get |
 | `contract_blocks` | ContractBlock | entity | extended | yes (contracts) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractBlock_get |
-| `contract_charges` | ContractCharge | entity | extended | yes (contracts) | query, count, get, create, update, delete, resolve, search | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractCharge_get |
+| `contract_charges` | ContractCharge | entity | extended | yes (contracts) | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractCharge_get |
 | `contract_exclusion_billing_codes` | ContractExclusionBillingCode | entity | extended | yes (contracts) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractExclusionBillingCode_get |
 | `contract_exclusion_roles` | ContractExclusionRoles | entity | extended | yes (contracts) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractExclusionRoles_get |
 | `contract_exclusion_set_excluded_roles` | ContractExclusionSetExcludedRoles | entity | extended | yes (contract_exclusion_sets) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractExclusionSetExcludedRole_get |
@@ -1760,22 +1753,22 @@ Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page gu
 | `contract_service_bundle_units` | ContractServiceBundleUnit | entity | extended | yes (contracts) | query, count, get, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractServiceBundleUnit_get |
 | `contract_service_bundles` | ContractServiceBundle | entity | extended | yes (contracts) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractServiceBundle_get |
 | `contract_service_units` | ContractServiceUnit | entity | extended | yes (contracts) | query, count, get, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractServiceUnit_get |
-| `contract_services` | ContractService | entity | extended | yes (contracts) | query, count, get, create, update, resolve | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractService_get |
+| `contract_services` | ContractService | entity | extended | yes (contracts) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractService_get |
 | `contract_ticket_purchases` | ContractTicketPurchases | entity | extended | yes (contracts) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_contractTicketPurchase_get |
-| `contracts` | Contract | entity | extended | no | query, count, get, create, update, resolve, search | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo, lineOfBusiness, profitability | autotask_contract_get |
+| `contracts` | Contract | entity | extended | no | query, count, get, create, update, resolve, search | fullProfile, getEntityInfo, getFieldInfo, getUdfInfo, lineOfBusiness, profitability | autotask_contract_get |
 | `countries` | Country | entity | advanced | no | query, count, get, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_country_get |
 | `currencies` | Currency | entity | advanced | no | query, count, get, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_currency_get |
 | `departments` | Department | entity | extended | no | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_department_get |
 | `domain_registrars` | DomainRegistrar | entity | extended | no | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_DomainRegistrar_get |
 | `expense_item_attachments` | ExpenseItemAttachment | entity | extended | yes (expense_items) | query, count, get, create, delete, resolve | download, getEntityInfo, getFieldInfo, getUdfInfo | autotask_expenseItemAttachment_get |
-| `expense_items` | ExpenseItem | entity | extended | yes (expense_reports) | query, count, get, create, update, resolve | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_expenseItem_get |
+| `expense_items` | ExpenseItem | entity | extended | yes (expense_reports) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_expenseItem_get |
 | `expense_reports` | ExpenseReport | entity | extended | no | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_expenseReport_get |
-| `holiday_sets` | HolidaySet | entity | advanced | no | query, count, get, create, update, delete, resolve | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_holidaySet_get |
-| `holidays` | Holiday | entity | advanced | yes (holiday_sets) | query, count, get, create, update, delete, resolve | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_holiday_get |
+| `holiday_sets` | HolidaySet | entity | advanced | no | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_holidaySet_get |
+| `holidays` | Holiday | entity | advanced | yes (holiday_sets) | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_holiday_get |
 | `invoice_templates` | InvoiceTemplate | entity | advanced | no | query, count, get | getEntityInfo, getFieldInfo, getUdfInfo | autotask_invoiceTemplate_get |
-| `invoices` | Invoice | entity | extended | no | query, count, get, update, resolve | customRange, getEntityInfo, getFieldInfo, getUdfInfo, last14, last24h, last30, last7, last90, lastFullFortnight, lastFullMonth, lastFullQuarter, lastFullWeek, markupHtml, markupXml, pdf, today, yesterday | autotask_invoice_get |
+| `invoices` | Invoice | entity | extended | no | query, count, get, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo, markupHtml, markupXml, pdf | autotask_invoice_get |
 | `notification_history` | NotificationHistory | entity | advanced | no | query, count, get, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_notificationHistory_get |
-| `opportunities` | Opportunity | entity | extended | no | query, count, get, create, update, resolve | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_opportunity_get |
+| `opportunities` | Opportunity | entity | extended | no | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_opportunity_get |
 | `opportunity_attachments` | OpportunityAttachment | entity | extended | yes (opportunities) | query, count, get, create, delete, resolve | download, getEntityInfo, getFieldInfo, getUdfInfo | autotask_opportunityAttachment_get |
 | `opportunity_categories` | OpportunityCategory | entity | extended | no | query, count, get, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_opportunityCategories_get |
 | `organizational_level1s` | OrganizationalLevel1 | entity | advanced | no | query, count, get, create, update | getEntityInfo, getFieldInfo, getUdfInfo | autotask_organizationalLevel1_get |
@@ -1783,7 +1776,7 @@ Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page gu
 | `organizational_level_associations` | OrganizationalLevelAssociation | entity | advanced | no | query, count, get, create, update | getEntityInfo, getFieldInfo, getUdfInfo | autotask_organizationalLevelAssociation_get |
 | `product_vendors` | ProductVendors | entity | extended | yes (products) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_productVendor_get |
 | `products` | Product | entity | extended | no | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_product_get |
-| `project_charges` | ProjectCharge | entity | extended | yes (projects) | query, count, get, create, update, delete, resolve, search | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_projectCharge_get |
+| `project_charges` | ProjectCharge | entity | extended | yes (projects) | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_projectCharge_get |
 | `project_notes` | ProjectNote | entity | extended | yes (projects) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_projectNote_get |
 | `phases` | Phase | entity | extended | yes (projects) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_phase_get |
 | `tasks` | Task | entity | extended | yes (projects) | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_task_get |
@@ -1795,21 +1788,21 @@ Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page gu
 | `quote_items` | QuoteItem | entity | extended | yes (quotes) | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_quoteItem_get |
 | `quote_locations` | QuoteLocation | entity | extended | yes (quotes) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_quoteLocation_get |
 | `quote_templates` | QuoteTemplate | entity | extended | no | query, count, get, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_quoteTemplate_get |
-| `quotes` | Quote | entity | extended | no | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_quote_get |
+| `quotes` | Quote | entity | extended | no | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo, withItems | autotask_quote_get |
 | `resource_role_queues` | ResourceRoleQueue | entity | extended | yes (resources) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_resourceRoleQueue_get |
 | `resource_roles` | ResourceRole | entity | extended | yes (resources) | query, count, get, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_resourceRole_get |
 | `resource_skills` | ResourceSkill | entity | extended | yes (resources) | query, count, get, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_resourceSkill_get |
 | `resource_time_off_additional` | ResourceTimeOffAdditional | entity | extended | yes (resources) | update, resolve | getByResource, getEntityInfo, getFieldInfo, getUdfInfo | autotask_resourceTimeOffAdditional |
 | `resource_time_off_approvers` | ResourceTimeOffApprover | entity | extended | yes (resources) | query, count, get, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_resourceTimeOffApprover_get |
 | `resource_time_off_balances` | ResourceTimeOffBalance | entity | extended | yes (resources) | get, resolve | getByResource, getByYear, getEntityInfo, getFieldInfo, getUdfInfo | autotask_resourceTimeOffBalance_get |
-| `resources` | Resource | entity | core | no | query, count, get, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo, transferOwnership, whoAmI | autotask_resource_get |
+| `resources` | Resource | entity | core | no | query, count, get, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo, whoAmI, workload | autotask_resource_get |
 | `roles` | Role | entity | extended | no | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_role_get |
 | `sales_orders` | SalesOrder | entity | extended | no | query, count, get, update | getEntityInfo, getFieldInfo, getUdfInfo | autotask_salesOrder_get |
 | `service_call_task_resources` | ServiceCallTaskResource | entity | extended | yes (service_call_tasks) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_serviceCallTaskResource_get |
 | `service_call_tasks` | ServiceCallTask | entity | extended | yes (service_calls) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_serviceCallTask_get |
 | `service_call_ticket_resources` | ServiceCallTicketResource | entity | extended | yes (service_call_tickets) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_serviceCallTicketResource_get |
 | `service_call_tickets` | ServiceCallTicket | entity | extended | yes (service_calls) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_serviceCallTicket_get |
-| `service_calls` | ServiceCall | entity | extended | no | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_serviceCall_get |
+| `service_calls` | ServiceCall | entity | extended | no | query, count, get, create, update, delete, resolve | fullProfile, getEntityInfo, getFieldInfo, getUdfInfo | autotask_serviceCall_get |
 | `service_level_agreement_results` | ServiceLevelAgreementResults | entity | advanced | no | query, count, get, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_serviceLevelAgreementResults_get |
 | `services` | Service | entity | extended | no | query, count, get, create, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_service_get |
 | `skills` | Skill | entity | extended | no | query, count, get, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_skill_get |
@@ -1822,13 +1815,13 @@ Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page gu
 | `tags` | Tag | entity | advanced | no | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_tag_get |
 | `task_secondary_resources` | TaskSecondaryResource | entity | extended | yes (tasks) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_taskSecondaryResources_get |
 | `tax_regions` | TaxRegion | entity | advanced | no | query, count, get, create, update | getEntityInfo, getFieldInfo, getUdfInfo | autotask_taxRegion_get |
-| `ticket_additional_configuration_items` | TicketAdditionalConfigurationItem | entity | extended | yes (tickets) | query, count, get, create, delete, resolve | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketAdditionalConfigurationItem_get |
-| `ticket_additional_contacts` | TicketAdditionalContact | entity | extended | yes (tickets) | query, count, get, create, delete, resolve | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketAdditionalContact_get |
+| `ticket_additional_configuration_items` | TicketAdditionalConfigurationItem | entity | extended | yes (tickets) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketAdditionalConfigurationItem_get |
+| `ticket_additional_contacts` | TicketAdditionalContact | entity | extended | yes (tickets) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketAdditionalContact_get |
 | `ticket_attachments` | TicketAttachment | entity | extended | yes (tickets) | query, count, get, create, delete, resolve | download, getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketAttachment_get |
 | `ticket_categories` | TicketCategory | entity | extended | no | query, count, get, update, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketCategories_get |
 | `ticket_category_field_defaults` | TicketCategoryFieldDefault | entity | extended | yes (ticket_categories) | query, count, get, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketCategoryFieldDefaults_get |
 | `ticket_change_request_approvals` | TicketChangeRequestApproval | entity | extended | yes (tickets) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketChangeRequestApprovals_get |
-| `ticket_charges` | TicketCharge | entity | extended | yes (tickets) | query, count, get, create, update, delete, resolve, search | createIfNotExists, getEntityInfo, getFieldInfo, getUdfInfo, moveToTicket | autotask_ticketCharge_get |
+| `ticket_charges` | TicketCharge | entity | extended | yes (tickets) | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo, moveToTicket | autotask_ticketCharge_get |
 | `ticket_checklist_items` | TicketChecklistItem | entity | extended | yes (tickets) | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketChecklistItem_get |
 | `ticket_checklist_libraries` | TicketChecklistLibrary | entity | extended | yes (tickets) | create, resolve | attachToDocument, getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketChecklistLibrary |
 | `ticket_history` | TicketHistory | entity | extended | no | query, count, get, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketHistory_get |
@@ -1837,8 +1830,8 @@ Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page gu
 | `ticket_notes` | TicketNote | entity | extended | yes (tickets) | query, count, get, create, update, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketNote_get |
 | `ticket_secondary_resources` | TicketSecondaryResource | entity | extended | yes (tickets) | query, count, get, create, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketSecondaryResources_get |
 | `ticket_webhooks` | TicketWebhook | entity | extended | yes (tickets) | query, count, get, create, update, delete, resolve, search | getEntityInfo, getFieldInfo, getUdfInfo | autotask_ticketWebhook_get |
-| `tickets` | Ticket | entity | core | no | query, count, get, create, update, resolve, search, getContext | changeStatus, findByTicketNumber, forResource, fullContext, getEntityInfo, getFieldInfo, getUdfInfo, lineOfBusiness, openWithNoteAndAssign, slaHealthCheck, statusSemantics, summary, timeline | autotask_ticket_get |
-| `time_entries` | TimeEntry | entity | extended | no | query, count, get, create, update, delete, resolve | approve, createForResource, createIfNotExists, customRange, dateWorkedWindow, getEntityInfo, getFieldInfo, getPosted, getUdfInfo, getUnposted, last14, last24h, last30, last7, last90, lastFullFortnight, lastFullMonth, lastFullQuarter, lastFullWeek, moveToTicket, postedWithin, today, yesterday | autotask_timeEntry_get |
+| `tickets` | Ticket | entity | core | no | query, count, get, create, update, resolve, search, getContext | changeStatus, findByTicketNumber, forResource, fullContext, getEntityInfo, getFieldInfo, getUdfInfo, lineOfBusiness, slaHealthCheck, statusSemantics, summary, timeline | autotask_ticket_get |
+| `time_entries` | TimeEntry | entity | extended | no | query, count, get, create, update, delete, resolve | dateWorkedWindow, getEntityInfo, getFieldInfo, getUdfInfo, moveToTicket | autotask_timeEntry_get |
 | `time_entry_attachments` | TimeEntryAttachment | entity | extended | yes (time_entries) | query, count, get, create, delete, resolve | download, getEntityInfo, getFieldInfo, getUdfInfo | autotask_timeEntryAttachment_get |
 | `time_off_requests` | TimeOffRequest | entity | extended | no | query, count, get, resolve | approve, getEntityInfo, getFieldInfo, getUdfInfo, reject | autotask_timeOffRequest_get |
 | `inventory_products` | InventoryProduct | entity | extended | no | query, count, get, create, update, delete, resolve | getEntityInfo, getFieldInfo, getUdfInfo, stockedItemsAdd, stockedItemsRemove, stockedItemsTransfer | autotask_inventoryProduct_get |
@@ -1850,7 +1843,7 @@ Standard methods (every resource, `BaseResource`): `query` (stream, 1000-page gu
 | `threshold_information` | — | integration | core | no | get | — | autotask_threshold_information |
 | `zone_information` | — | integration | advanced | no | get | — | autotask_zone_information |
 
-128 resources (121 entity + 7 integration). Rows are generated from the registry — do not hand-type.
+136 resources (129 entity + 7 integration). Rows are generated from the registry — do not hand-type.
 <!-- END GENERATED:api-per-entity -->
 
 **`companies.search` include_family (issue #59).** `companies.search` is
@@ -1914,15 +1907,14 @@ drift). Records exist only for plan rows that are implemented/tested; the
 plan (`capabilities.plan.json`) is the single source of truth and the
 registry is its compiled form.
 
-**Consumer-defaulted arguments (issue #115).** A manifest CONSUMER may fill an
-argument this registry marks required when the caller omits it — the manifest
-describes the SDK operation, not the consumer's tool contract. The one
-instance today is `contracts.profitability`: the SDK requires
-`dateFrom`/`dateTo`, and iit-mcp-autotask defaults both to the last full
-calendar month (UTC) when the caller omits them. The served
+**SDK-default window (issues #115/#291).** `contracts.profitability` takes
+`dateFrom`/`dateTo` as an optional PAIR: both omitted → the window defaults to
+the last full calendar month (UTC) and the result's `period` carries
+`defaulted: true` plus a note (month label + UTC basis); exactly one supplied
+→ a typed `CONFIG_ERROR` before any wire; both supplied → the existing
+validation. The consumer no longer fills the window — the served
 `metadata.args`/`metadata.usage` and the record's
-`inputSchema.opts.description` state the caveat; a consumer that trusts the
-raw manifest should apply the same contract.
+`inputSchema.opts.description` state the SDK default.
 
 ### 9.1 Generated artifact #5: `src/relationships.ts` (the relationship map + zone facts)
 
@@ -1947,11 +1939,11 @@ cannot drift from the plan):
   describe channel cannot drift.
 - `DELETE_BOUNDARY_NOTES` (issue #9) — resource → the spec-derived
   delete-boundary note (`plan.deleteBoundaries`): the create dry run's
-  `delete-boundary` warning and `operations.recovery` read the SAME map (the
-  describe and runtime channels cannot drift).
-- `MARKER_FIELDS` (issue #9) — resource → the spec-derived name-like field
-  the recovery marker query filters on (the plan's `markerField`; absent when
-  the model has none).
+  `delete-boundary` warning reads the map (the op that shared it,
+  `operations.recovery`, was deleted in #289 — the dry-run and describe
+  channels cannot drift).
+- `MARKER_FIELDS` (issue #9) — resource → the spec-derived name-like marker
+  field (the plan's `markerField`; absent when the model has none).
 - `EMPTY_REASON_STAMPS` (issue #14) — resource → op → the typed empty-reason
   `{ surface, kind, note, authority, remedy }` (`plan.emptyReasons`, the
   ww29-sweep-pinned 184 rows): the runtime lookup `base.ts` attaches to
@@ -1973,10 +1965,10 @@ The per-resource entry also carries `deleteBoundary`
 
 Consumers: the runtime sentinel wrap (T10), `operations.relationshipMap`
 (S12-B — the `autotask_relationship_map` tool serves `RELATIONSHIP_MAP`
-zero-wire by construction), the create dry run (§7.5) and
-`operations.recovery` (issue #9). Drift-guarded: `capabilities:check` fails
-when the artifact bytes ≠ a fresh re-derivation of the plan
-(`test/scripts/relationships-artifact.test.ts` pins it TDD-style).
+zero-wire by construction) and the create dry run (§7.5). Drift-guarded:
+`capabilities:check` fails when the artifact bytes ≠ a fresh re-derivation
+of the plan (`test/scripts/relationships-artifact.test.ts` pins it
+TDD-style).
 ## 10. Response redaction (secret and personal fields)
 
 The SDK boundary redacts response field values. A vendor 2xx JSON body is
@@ -2061,8 +2053,9 @@ resource paths, of which **40** expose a create op (the stampable set; the
 13-record live-verified set above stays a distinct channel, `proof:
 'live-verified'`). The new `plan.deleteBoundaries` block (spec-derived,
 `proof: 'spec-derived'`) stamps each affected create's descriptor
-(`metadata.deleteBoundary`), the create dry run (§7.5) and the one-call
-`recovery` op read the SAME generated note — see §11.9.
+(`metadata.deleteBoundary`) and the create dry run (§7.5) read the SAME
+generated note (the one-call recovery op that shared it was deleted in
+#289) — see §11.9.
 
 ### 11.2 Blind count/query surfaces (get is the authority)
 
@@ -2108,7 +2101,7 @@ resource paths, of which **40** expose a create op (the stampable set; the
   type itself is discoverable via `configuration_item_types.query` (the wall is the
   FK, not the type).
 
-### 11.4 `time_entries.createForResource` — zone facts
+### 11.4 `time_entries.create` — zone facts
 
 - The vendor **double-validates roleID** (an active general allocation code AND
   a Role reference); in ww29 the two sets are disjoint, so the task/ticket
@@ -2241,13 +2234,12 @@ of the data).
   everything — the sentinel notes, the record stamps, the generated
   `src/relationships.ts` (§9.1) and this section.
 - **S12 additions (PLANNED — land with the A/B workstreams, not yet on
-  main)**: 9 new registry ops — `tickets.openWithNoteAndAssign` /
+  main)**: new registry ops — `tickets.openWithNoteAndAssign` /
   `tickets.changeStatus` / `tickets.fullContext` · `contacts.upsertByEmail` ·
   `companies.upsertByName` / `companies.fullProfile` ·
-  `configuration_items.profile` · `operations.fetchMany` (batch read) /
-  `operations.relationshipMap` (serves the §9.1 artifact zero-wire). Each
-  gets a curation row in `MCP_TOOL_OVERRIDES.json` at the post-merge
-  coordinator step.
+  `configuration_items.profile` · `operations.relationshipMap` (serves the
+  §9.1 artifact zero-wire). Each gets a curation row in
+  `MCP_TOOL_OVERRIDES.json` at the post-merge coordinator step.
 
 ### 11.8 Live-validated create examples + the `createIfNotExists` dedupFields shapes
 
@@ -2346,11 +2338,13 @@ treat `entry.evidence` with the same trust you already apply to
 `vendorEvidence` on this surface (plan-grade provenance, not model-facing
 prose). The old `string[]` shape is gone.
 
-### 11.9 Delete-boundary awareness + the one-call recovery (issue #9)
+### 11.9 Delete-boundary awareness (issue #9)
 
 The §11.1 wall (7 live-verified 405 endpoints) is now a **spec-derived
 channel** that covers the whole surface, not just the 13 live-verified
-records. The audit (`scripts/lib/delete-boundary.mjs` — the same shared lib
+records. The one-call recovery op that turned this boundary into a typed,
+bounded path was deleted in #289 (no server consumer) — the channel below
+is the plan data + the create dry run that remain. The audit (`scripts/lib/delete-boundary.mjs` — the same shared lib
 the S11-F stamp channel and the F2 manifest note use) re-derives the
 vendored spec's DELETE-absence set, and the plan carries it as a NEW top-level
 block (distinct from `plan.blindSurfaces`, which the 6-pin set-equality gate
@@ -2366,27 +2360,25 @@ keeps untouched):
   `autotask_describe` surfaces it before the write).
 - **generated runtime data** — `src/relationships.ts` emits
   `DELETE_BOUNDARY_NOTES` (resource → note) + `MARKER_FIELDS` (resource → the
-  spec-derived name-like field the recovery marker query filters on, 22 pins)
-  from the same plan (zero wire by construction).
+  spec-derived name-like marker field, 22 pins) from the same plan (zero
+  wire by construction).
 - **the create dry run** (`src/resources/base.ts`) — on a delete-less
   resource the envelope gains the report-only `delete-boundary` check
   (`ok: true`) + the boundary note in `warnings[]`. The check is
   report-only on purpose: the write itself is valid, so `wouldApply` is
   preserved (the design's `ok: false` example would have broken the pinned
   `companies`/`tickets` create-dry-run contract).
-- **`operations.recovery`** (§7.5) — the one-call recovery/cleanup op that
-  turns the boundary from a wall into a typed, bounded path: find the record
-  a write just created (one bounded marker query), and where the vendor
-  allows it, remove it (dry-run-first, confirm-gated apply, per-id
-  verification). The three new typed errors (`DELETE_BOUNDARY`,
+- **typed errors** — the three issue-#9 refusal codes (`DELETE_BOUNDARY`,
   `MARKER_UNSAFE_ID`, `RECOVERY_TRUNCATED`) + the reused `RESOURCE_UNKNOWN`
-  make every refusal explicit (never a raw 405, never a silent skip, never a
-  silent empty).
-- **the gate** (`scripts/check-capabilities.mjs`) — the new channel has its
-  own set-equality clause: the block must equal a fresh spec re-derivation
+  stay in the write-outcome taxonomy (`src/errors/mutation.ts`) after #289
+  deleted the op that threw them: never a raw 405, never a silent skip,
+  never a silent empty.
+- **the gate** (`scripts/check-capabilities.mjs`) — the channel has its own
+  set-equality clause: the block must equal a fresh spec re-derivation
   over the stampable set, and EXACTLY the pinned create records carry
   `metadata.deleteBoundary` (content match). Pinned by
-  `test/operations/recovery.test.ts` + the full-surface governor suite.
+  `test/scripts/check-capabilities.test.ts` (the F5 clauses) + the
+  full-surface governor suite.
 
 ### 11.10 Typed empty reasons — `emptyReason` (issue #14)
 
@@ -2467,14 +2459,17 @@ blind) return `{ count, emptyReason? }` on a 0 — check
 existing contract, now with the reason alongside).
 
 
-### 11.11 Zero-wire planning reads + the bounded reachability probe (issue #11)
+### 11.11 The zero-wire blind-surface + reachability plan data (issue #11)
 
-Two ops serve the campaign's own discovery data at runtime (ZERO vendor
-calls — generated plan data, drift-guarded by `capabilities:check` clause
-14), so an agent can read "what is blind on this zone" without burning
-budget or guessing:
+The campaign's own discovery data ships as plan data (ZERO vendor calls —
+`plan.reachability` is derived into `src/relationships.ts`, drift-guarded
+by `capabilities:check` clause 14), so an agent can read "what is blind on
+this zone" without burning budget or guessing. The two ops that served it
+at runtime (`operations.blindSurfaces`, `operations.probeReachability`)
+were deleted in #289 (no server consumer) — the data and its derivation
+remain:
 
-- **`operations.blindSurfaces`** — the 124-surface inventory: per surface the
+- **`BLIND_SURFACE_INVENTORY`** — the 124-surface inventory: per surface the
   kind (`unowned-blind` / `unfiltered-blind` / `unknown` — the 46
   data-with-rows surfaces ride `unknown` by design: the sweep's limit-2 read
   proves data, not the absence of it), the recorded `unfilteredRows` (0-2
@@ -2485,14 +2480,13 @@ budget or guessing:
   note. Clause 14 pins the row set equal to the plan's query-able resources,
   the counts derived from the rows, and the row-level kind invariant (a
   blind-class row must have 0 recorded rows).
-- **`operations.probeReachability`** — re-probes chosen surfaces LIVE
-  (effect=read: route it through `autotask_read`): `{ resources?, maxWireCalls?,
-  confirmProbe }` — `confirmProbe: true` is REQUIRED (the probe issues real
-  vendor reads), caps of 40 surfaces / 80 wire calls with OVER-CAP REFUSAL
-  (never truncation), per-surface failure isolation (a 500 on one surface —
-  e.g. the W1 `ticket_history` contract 500 on the unfiltered read — is logged
-  with its machine code and the sweep continues), `wireUsed` single-sourced, zero results honest (a 0
-  from a blind surface proves nothing — the inventory's kind says why).
+- **`REACHABILITY_PROBE_DEFAULTS`** — the derived probe defaults: the hard
+  wire cap (80), the default cap (40), the limit bounds (1-2, default 2)
+  and the default target set — the derived non-data-full rows (the 70
+  surfaces a re-discovery sweep starts from: the 69 blind +
+  `ticket_history`). Derived zero-wire; the gate re-derives the target set,
+  so it cannot drift from the inventory. (A 0 from a blind surface proves
+  nothing — the inventory's kind says why.)
 
 ### 11.12 Zone-fact create guidance (issue #12)
 
@@ -2639,7 +2633,7 @@ metadata is (the `autotask_describe` channel, `capabilities.json`,
   key. Unlike `pointerNote`, caveats ride the describe channel only (they are
   not attached to error details).
 
-### 11.13 Posted state from billing items (W-D3), `getPosted` / `getUnposted` / `postedWithin`, and drifted-create marker recovery (issues #10/#13/#237)
+### 11.13 Posted state from billing items (W-D3), `dateWorkedWindow`, and drifted-create marker recovery (issues #10/#13/#237)
 
 - **W-D3 (live, ww29, re-verified 2026-10-27)** — this zone's TimeEntry entity
   has **no posted-state field**: time-entry reads carry no `postedDate` /
@@ -2659,51 +2653,39 @@ metadata is (the `autotask_describe` channel, `capabilities.json`,
   condition is ever sent. The join is one `BillingItems` query per 250 ids;
   the entry read is capped at 500, so a call costs at most 1 read + 2 joins
   and a window with more than 500 entries returns the first 500 with
-  `hasMore` / `truncated` true and a `nextCursor` to continue from (or use
+  `truncated` true and a `nextCursor` to continue from (or use
   `countOnly` for the window's totals; see the paging bullet below). A 429 or vendor fault propagates as a typed
   error. The API user therefore needs BillingItems read permission; a permission fault propagates as a typed error.
-- **`time_entries.getPosted(opts?)` / `getUnposted(opts?)`** — `opts` is
-  `{ limit?, ticketID?, dateFrom?, dateTo?, cursor?, countOnly?, maxVendorCalls? }`
-  (the paging options: see the paging bullet below; `dateFrom`/`dateTo`:
-  inclusive `dateWorked` days, `YYYY-MM-DD`, never tz-shifted). They return
-  `{ items, hasMore, window, nextCursor, unconfirmed, approvedCount, unapprovedCount }` (a breaking
-  change from the bare `TimeEntry[]`, 0.32.0): `getPosted` items are entries
-  a billing item references; `getUnposted` items are entries none references.
-  `approvedCount` / `unapprovedCount` are informational (items with / without
-  `billingApprovalDateTime`) and are **not** posted state. `window` echoes the
-  bounds (`null` for a bound not given); `hasMore` true means the result is
-  partial (entry read capped, or a join page truncated — unconfirmed entries
-  are withheld, never called unposted). `dateFrom`/`dateTo` are optional, but a call without dates reads the tenant's first 500 time entries (effectively the oldest): a near-empty, misleading slice with `hasMore` true — pass a window.
-- **`time_entries.postedWithin(from, to, opts?)`** — an inclusive UTC
-  `dateWorked` window (`from`/`to` are `YYYY-MM-DD` date strings — the S1c
-  guard forbids Date positionals), one bounded read (`limit` 1-500, default
-  500 — the hard cap, issue #128: a larger window needs `time_entries.query`
-  with the same `dateWorked` filter, its 2500-row walk cap) returning
-  `{ items, postedCount, unpostedCount, window, nextCursor, unconfirmed, truncated }`; the counts come
-  from the billing-item join (any billing item referencing the entry), `opts.posted` narrows client-side after the join
-  (true = posted only, false = unposted only, omitted = both); the counts still split every entry read (before the narrowing), so `items.length` can differ from their sum and `ticketID` /
-  `resourceID` narrow the read. Live evidence for the visibility class
-  (unfiltered query 0 rows, windowed read has data) from 2026-10-06 still
-  stands; the posted/unposted split from that period does not.
-- **`truncated` + the `dateWorkedWindow` alias + `tz` (issue #66)** — the
-  result is now `{ items, postedCount, unpostedCount, window, truncated }`:
-  `truncated` is true when the bounded read came back with a live
-  `pageDetails.nextPageUrl` (more matching rows exist; `requestCount` is the
-  MaxRecords echo, not a total, so it cannot carry this signal) —
-  the posted/unposted counts then cover the returned rows ONLY (at most
-  `limit`); re-query with a wider window or a narrowing filter to reconcile
-  the totals. `time_entries.dateWorkedWindow(from, to, opts?)` is the
-  unambiguous-named alias: the same wire, the same result (incl. `truncated`),
-  its own op identity (plan row / MCP tool
-  `autotask_timeEntry_date_worked_window` / operation label) — the name
-  names the `dateWorked` field the window is on; `postedWithin` keeps its
-  name and default semantics. Both accept `opts.tz` (an IANA zone, validated)
-  but, since 0.24.0, it never shifts the bounds: `dateWorked` is a date-only
-  value at 00:00 UTC, so `from`/`to` are the days (see §7.11). The same `tz`
-  opt is on every date-window op — see §11.22.
-- **Paging past 500 entries and whole-window totals (issue #242)** — all four
-  ops (`getPosted`, `getUnposted`, `postedWithin`, `dateWorkedWindow`) take
-  three more options:
+- **`time_entries.dateWorkedWindow(from, to, opts?)`** — the ONE posted-state read
+  (issue #290; absorbs `getPosted` / `getUnposted` / `postedWithin` and the
+  relative windows). `from`/`to` are required inclusive UTC `dateWorked` days
+  (`YYYY-MM-DD` date strings — the guard forbids Date positionals and refuses
+  impossible days), one bounded read (`limit` 1-500, default 500 — the hard cap,
+  issue #128: a larger window needs `time_entries.query` with the same
+  `dateWorked` filter and a suitable `limit` or explicit `walk.maxRows` cap,
+  section 4) returning
+  `{ items, postedCount, unpostedCount, window, nextCursor, unconfirmed, truncated }`;
+  the counts come from the billing-item join (any billing item referencing the
+  entry) and split every entry read (before the narrowing), so `items.length`
+  can differ from their sum; `opts.state` (`'posted'` / `'unposted'`, omitted =
+  both) narrows `items` client-side after the join, and `ticketID` / `resourceID`
+  narrow the read. The no-window form (a call without dates reading the
+  tenant's first 500 time entries, effectively the oldest) is gone: a read with
+  no `dateWorked` filter goes through `time_entries.query`. Live evidence for
+  the visibility class (unfiltered query 0 rows, windowed read has data) from
+  2026-10-06 still stands; the posted/unposted split from that period does not.
+- **`truncated` (issue #66, consolidated in #290)** — `truncated` is true when
+  the bounded read came back with a live `pageDetails.nextPageUrl` (more
+  matching rows exist; `requestCount` is the MaxRecords echo, not a total, so
+  it cannot carry this signal) or a join page was truncated — the
+  posted/unposted counts then cover the returned rows ONLY (at most `limit`);
+  re-query with a wider window or a narrowing filter to reconcile the totals.
+  The `tz` option is gone with the consolidation (`dateWorked` is a date-only
+  value at 00:00 UTC — the `from`/`to` days ARE the days, never shifted; see
+  §7.11), and the `postedWithin` / `dateWorkedWindow` alias pair is one op now
+  (plan row / MCP tool `autotask_timeEntry_date_worked_window`).
+- **Paging past 500 entries and whole-window totals (issue #242)** —
+  `dateWorkedWindow` takes three more options:
   - `cursor?: string` — every rows result now carries `nextCursor: string | null`
     (the vendor's next-page cursor for the entry read). Pass it back as
     `opts.cursor` with the **same** window and filters to read the next page;
@@ -2714,12 +2696,11 @@ metadata is (the `autotask_describe` channel, `capabilities.json`,
     continuation (`/V1.0/TimeEntries/query/next`), or a cursor longer than
     2,048 characters, is refused (`RESPONSE_REJECTED`) before any request. Every rows result also carries
     `unconfirmed: number`: the entries on this page whose billing-item join
-    page was truncated. They are withheld from `items` (getPosted /
-    getUnposted) and from both counts (postedWithin / dateWorkedWindow, which
-    also withhold them from `items` when `posted` is set; with `posted`
-    omitted they stay in `items`, unclassified), so a cursor loop does not
-    see them as posted or unposted; `unconfirmed` is 0 normally, and when it is
-    above 0 `hasMore` / `truncated` is also true. Sum it across a loop to know
+    page was truncated. They are withheld from a `state`-narrowed `items`
+    (with `state` omitted they stay in `items`, unclassified) and from both
+    counts, so a cursor loop does not see them as posted or unposted;
+    `unconfirmed` is 0 normally, and when it is above 0 `truncated` is also
+    true. Sum it across a loop to know
     how many entries went unclassified (or use `countOnly`, which refuses
     instead).
   - `countOnly?: true` — returns only the whole window's totals:
@@ -2735,7 +2716,7 @@ metadata is (the `autotask_describe` channel, `capabilities.json`,
     and dropped another); a total equal to either count is accepted, so a
     window that grows or shrinks by the time the walk ends still succeeds, and
     one that changes mid-walk can fail or pass depending on timing: retry.
-    `limit` and `posted` do not apply; `cursor` is rejected with `countOnly`
+    `limit` and `state` do not apply; `cursor` is rejected with `countOnly`
     (CONFIG_ERROR).
   - `maxVendorCalls?: number` — the `countOnly` budget (integer 1-200,
     default 30). The estimate is `1 + max(1, ceil(n / 500)) + ceil(n / 250) + 1`
@@ -2821,7 +2802,7 @@ resources, `include: ['fields']`; the closed opts bag is documented in
 the registry record). One bounded entityInformation GET per resource ×
 kind; the wire cost `resources × include` is REFUSED pre-request above
 the pinned cap (`MAX_FIELD_CATALOG_WIRE = 60`) — refused, never
-truncated (the `probeReachability` contract). Per-resource vendor
+truncated (the bounded sweep contract). Per-resource vendor
 failures are recorded on the row (`error: { code, message }`) and never
 abort the sweep. Capability is PLAN-DERIVED, never hardcoded: the
 `getFieldInfo` / `getUdfInfo` row sets and each resource's vendor path
@@ -3334,57 +3315,35 @@ call.
 Pins: `test/operations/expandResourceNames.test.ts` (the plan row's `tests[]`)
 and `test/resources/cache-write-invalidation.test.ts` (mock wire only).
 
-### 11.22 Timezone-anchored date windows for billing items and invoices (issue #66)
-
-The time-entry window helpers pinned their bounds to UTC (the API is UTC)
-while the node computes them in the configured timezone, and billing items /
-invoices had no window helpers at all. Issue #66 makes the zone EXPLICIT and
-additive, and mirrors the family:
-
-- **Two new window families** — the full mirror of the time-entry helpers
-  (the same 12 ops each: `today`, `yesterday`, `last24h`, `last7`, `last14`,
-  `last30`, `last90`, `lastFullWeek`, `lastFullFortnight`, `lastFullMonth`,
-  `lastFullQuarter`, `customRange`):
-  - `billing_items.<kind>(opts?)` — ONE bounded server-filtered query on
-    the billing item's date field **`itemDate`**
-    (`POST /V1.0/BillingItems/query`) → `Promise<BillingItems[]>`;
-  - `invoices.<kind>(opts?)` — ONE bounded server-filtered query on the
-    invoice's date-time field **`invoiceDateTime`**
-    (`POST /V1.0/Invoices/query`) → `Promise<Invoice[]>` (the invoices
-    model has no plain `invoiceDate` — `fromDate`/`toDate` are range
-    fields, not the invoice date).
-- **The zone contract (shared)** — `opts.tz` takes an explicit IANA zone
-  (e.g. `'Australia/Sydney'`); OMITTED `tz` = UTC, the current behaviour
-  bit-for-bit (the regression pin). All three families are DATE-ONLY
-  (`dateWorked`, `itemDate`, `invoiceDateTime` are stored at T00:00:00Z): the
-  zone picks which calendar DATES a relative window means (what today / last
-  full month is in that zone) and the wire bounds are whole UTC days of them
-  (second-precision UTC ISO); explicit `from`/`to` days are never shifted and
-  `tz` is only validated. `time_entries` has worked this way since 0.24.0;
-  `billing_items` and `invoices` since 0.32.0 (behaviour change: before, a zone
-  behind UTC, e.g. America/New_York, sent a zone-converted instant window that
-  dropped the first day and added an extra day; zones ahead of UTC returned the
-  right rows by accident). A zone-converted instant window picks the wrong day
-  behind UTC. DST is
-  handled by inverting local midnights to UTC instants (a local day that
-  gains or loses an hour still pins both boundaries to its TRUE midnights —
-  never clock-hour arithmetic); `last24h` is rolling (`now − 24h → now`)
-  and TZ-invariant by construction. A zone `Intl.DateTimeFormat` rejects is
-  refused pre-request as a typed `CONFIG_ERROR` (zero wire). There is no
-  config-level timezone in v1 (the zone is per-call; a future
-  `config.timeZone` default would be an additive follow-up).
-- **The existing family gains the same opt** — the 12 `time_entries`
-  window ops (incl. `customRange`) plus `postedWithin` and its
-  `dateWorkedWindow` alias accept `opts.tz`
-  with the contract above (date-only for time entries), so the whole window family accepts
-  the same `tz` option (default UTC unchanged).
-- **Shape and wire** — each op is exactly ONE bounded query (`MaxRecords`
-  1-500, default 500 — the hard cap, issue #128: a call without `limit` takes
-  the first 500 rows in id order; a window with more than 500 matching rows
-  needs the bounded query op with the same date-window filter — its 2500-row
-  walk cap; the `itemDate` / `invoiceDateTime` `gte`/`lte` filter rides the
-  wire), and the result is the plain `items[]` array — no counts
-  (the time-entry family shape).
+### 11.22 The cut date-window families — `dateWorkedWindow` and bounded queries (issue #66, consolidated in #290)
+
+Issue #66 made the window zone EXPLICIT (a `tz` option, default UTC) and
+mirrored the time-entry window family onto `billing_items` (`itemDate`) and
+`invoices` (`invoiceDateTime`) — twelve relative ops each. The consolidation
+(issue #290) cut all of them: ONLY the `time_entries` family is consolidated
+into the single op `time_entries.dateWorkedWindow(from, to, opts?)` (§11.13)
+— an inclusive, UTC-anchored `dateWorked` window with the posted/unposted
+split. The `billing_items` and `invoices` date-window families are CUT with
+no replacement op: reading those resources by date window goes through their
+bounded `query` ops on `itemDate` / `invoiceDateTime` (bullet below). The
+`tz` option is gone (`dateWorked` is a date-only value at 00:00 UTC; the
+`from`/`to` days ARE the wire bounds, never shifted, and impossible days are
+refused pre-request).
+
+- **Reading billing items / invoices by date window** — use the bounded `query`
+  ops: `billing_items.query` with an `itemDate` `gte`/`lte` filter on whole UTC
+  days (`POST /V1.0/BillingItems/query`) and `invoices.query` with
+  `invoiceDateTime` (`POST /V1.0/Invoices/query` — the invoices model has no
+  plain `invoiceDate`; `fromDate`/`toDate` are range fields, not the invoice
+  date). Each call is ONE bounded query (`MaxRecords` 1-500, default 500 — the
+  hard cap, issue #128), the plain `items[]` result, no counts.
+- **The zone contract (history)** — before #290 the relative windows
+  (`today`, `lastFullMonth`, ...) computed the calendar dates in `opts.tz` and
+  sent whole UTC days (DST handled by inverting local midnights to UTC instants;
+  `last24h` was rolling, `now − 24h → now`, TZ-invariant by construction); a
+  zone the vendor's `Intl.DateTimeFormat` rejects was refused pre-request as a
+  typed `CONFIG_ERROR` (zero wire). No relative-window op remains, so the
+  contract only matters for historical receipts.
 
 ### 11.23 Free-text caps (issue #61)
 
@@ -3600,8 +3559,8 @@ returns the contract's reconciled P&L over a date window:
   (ticket `createDate`) as UTC instants, and bucketing slices the ISO
   string — in a UTC+10/11 tenant a ticket created late local time buckets
   one UTC day (possibly one month) earlier than its local date. The
-  `time_entries.getPosted` / `getUnposted` ops are NEVER called (the
-  profitability fold already holds the billing items, so the join is
+  posted-state ops are gone (cut in #290 — the profitability fold
+  already holds the billing items, so the join is
   in-memory with no extra wire); posted/unposted derives from the
   `billingItems.timeEntryID` join (unposted = no billing item exists yet).
   The structural exclusions (`/Services/`, `/ExpenseReports/`,
@@ -3682,7 +3641,7 @@ returns the contract's reconciled P&L over a date window:
   SERVICE lines)` (labour and charges never mask a missed recurring
   invoice) · `unposted_time { entries, hours, hoursAbsent?, value, absent? }`
   (billable time with no billing item yet — derived from the billing join,
-  never getPosted/getUnposted; `hours` = Σ `max(0, hoursToBill)`, or `null`
+  never a posted-state op (cut in #290); `hours` = Σ `max(0, hoursToBill)`, or `null`
   + `hoursAbsent: 'HOURS_TO_BILL_MISSING'` when any of the month's unposted
   entries carries no numeric `hoursToBill` — unknown, never a summed 0; a
   deliberate `hoursToBill: 0` stays 0; `value` = Σ `hoursToBill ×
@@ -3865,8 +3824,8 @@ returns the contract's reconciled P&L over a date window:
 ### 11.27 Label siblings on query, aggregate and fetch (opt-in, issue #287)
 
 Rows served by the invoke `<resource>.query` op (the bounded query), the group
-keys of `operations.aggregate`, and the found records of `operations.fetchMany`
-/ `operations.fetchByIds` carry label siblings **when opted in** (issue #287:
+keys of `operations.aggregate`, and the found records of `operations.fetchByIds`
+carry label siblings **when opted in** (issue #287:
 OFF by default — the label pass costs a field-catalog read plus up to 20 cold
 name reads per call, so a plain read returns raw ids), through the same
 `resolveCompositeNames` path the full-context composites use:
@@ -3875,9 +3834,9 @@ name reads per call, so a plain read returns raw ids), through the same
   siblings on for every read surface of that client (the MCP server sets it,
   server-side).
 - **The per-call key:** `names: true` in the query bag / the aggregate opts /
-  the `fetchMany` / `fetchByIds` opts turns them on for that call; `names:
-  false` turns them off (even when the client has `labels: true`); ABSENT =
-  the client's option (the off default). A non-boolean `names` is refused
+  the `fetchByIds` opts turns them on for that call; `names: false` turns them
+  off (even when the client has `labels: true`); ABSENT = the client's option
+  (the off default). A non-boolean `names` is refused
   pre-request.
 
 | field on the row | sibling | example |
@@ -3940,9 +3899,8 @@ name reads per call, so a plain read returns raw ids), through the same
   per-call cap of 20 uncached name reads was hit — names already read are
   cached, so repeating or narrowing the call labels more"`. Unresolvable
   picklists add a note clause and a `reasons` entry per field (the
-  field-catalog honesty note / the value-not-served note); on `fetchMany` /
-  `fetchByIds` the notes merge across resources and `reasons` keys the plain
-  field name. Absent `names` = every sibling was resolved.
+  field-catalog honesty note / the value-not-served note); on `fetchByIds`
+  the notes merge across resources and `reasons` keys the plain field name. Absent `names` = every sibling was resolved.
 - Response size (full model, wrapped names): a tickets row grows ~40% (live,
   100 rows, 31 siblings per row, some of them null: 341,178 B -> 477,325 B;
   more when every FK is populated), a time_entries row ~77% (worst case, every
@@ -4011,6 +3969,35 @@ truncates first, then wraps) — so the explicit `… [+N chars truncated]`
 marker survives INSIDE the wrapped value and the closing marker is never
 cut off.
 
+**`sanitiseResult(client, result, operation)`** exposes that field projection
+as a zero-wire operations helper. Pass the registry key of the read that
+produced the result, for example `tickets.query`; an unknown key is a typed
+`CONFIG_ERROR`. It walks plain objects and arrays, wrapping strings in the
+operation's `metadata.untrustedFields`, including strings in arrays under
+those fields. `userDefinedFields[].value` strings are fenced even when the
+operation has no field stamp. Deeply nested containers are capped at 64
+levels with `[DEPTH]`.
+Inputs are never mutated, wrapping is idempotent, and non-string values
+and `[REDACTED]` pass through. SDK read primitives still return raw values.
+
+This helper supplies field/UDF fencing. The host retains text cleaning,
+free-text caps and trusted formatting exemptions; apply those policies in
+the host before projection where needed. The bounded-query `noteChars`
+option remains a separate SDK cap applied before wrapping.
+
+For hosts that need to clean or cap text before wrapping, the
+`node-autotask/untrusted` subpath exports
+`deepMarkUntrusted(value, fields, projector?)` and the callback type
+`UntrustedStringProjector = (text: string, target: object, key: string | number) => string`.
+The optional callback runs only for marked string values, including UDF
+values and strings in named arrays. `target` is the copied output
+container; `key` is its property name or array index, assigned after the
+callback returns. A host can record provenance in a `WeakMap` keyed by
+`target` and return the raw text, then clean, cap and wrap those marked
+values later. Containers exposed to the callback remain copies even if
+the callback returns unchanged text. Unmarked strings and non-string
+values do not invoke it; omitting the callback keeps the default wrapping.
+
 ## 13. Doctor preflight (issue #2)
 
 `runDoctor(client)` (section 1.10) runs the bounded, sequential preflight