The Trilogy Times

Linear: AERIE-2796

## Testing contract

### What this PR delivers

A one-off, operator-run data correction for sites.driveFolderId on eight named sites.

Four active sites (Kirkland, NYC 180 Maiden Ln South, Carrollton, Austin Hudson Bend) have their managed Drive folder pointing into the RHODES Dev Sandbox shared drive instead of the Education Ops shared drive. Every document registered on them since about June landed in the sandbox: 194 current registrations, including executed leases and W-9s, in a tree shared as anyone-with-the-link. Four more active sites (Jersey City, Bedford Corners, Charlotte, Alpha World School) have no folder linked although an Education Ops folder exists. Reported by Artemis Fletcher on 2026-10-08 (PAP-16840); I confirmed the stored values and the sharing.

The ordinary path, linkDriveFolder, deliberately refuses to replace an existing folder, and the public API treats the field as locked, so the four re-points cannot be made today. This adds migrations/repointSiteDriveFolders with run (dry run by default) and verify.

It adds no product surface and changes no existing behaviour. linkDriveFolder keeps its guard.

### Who uses it and where

An operator with operations.siteFields.write, from the Convex CLI against production. No UI, API or MCP surface.

### Conditions needed

- Signed in as a user whose role has operations.siteFields.write.

- For the four re-points: the site's folder contents already moved in Drive from the sandbox folder into the Education Ops folder. A Drive move keeps file IDs, so stored document links keep working. The mutation cannot see Drive and does not check this; the order is the operator's responsibility and is stated in the file header.

### Expected behavior and examples

- Dry run changes nothing. run '{"execute":false}' reports each site as would_update, already_correct, conflict or not_found.

- Execution needs the phrase. execute: true without confirm: "REPOINT_SITE_DRIVE_FOLDERS" is refused.

- Applies only when the stored value is the one recorded. Each target carries the folder it expects to replace (expectedCurrent, or none). If the stored folder is anything else, the site is reported as conflict and left alone. Example: Carrollton's folder was changed by someone else after this was written → conflict, untouched.

- only runs one site at a time, so each site can be re-pointed right after its own folder move. Naming a site that is not a target is refused.

- Every applied change writes an audit entry site.driveFolder.repointed with before and after values, attributed to the operator.

- Idempotent. A second run reports already_correct and writes nothing.

- Sites are matched by immutable public Site ID, never by slug or name. Sites that are not targets are never read or written.

Commands are in the file header. Sequence for production: run dry → move one site's folder → run with only for that site → repeat → verify.

### Limits and unanswered questions

- Not included: the two cancelled sites in the same state (no Education Ops folder exists), 80 Willow Rd Menlo Park (its current folder could not be read, so the target is unconfirmed), and two sites with no Education Ops folder yet.

- Document approvals pending at the moment of a re-point compare against the stored root and will fail closed; they would need resubmitting.

- Turning off link sharing on the sandbox tree and moving the folders are Drive operations outside this PR.

## Business Value

Executed leases and W-9s for four live schools are reachable by anyone holding a link, and the Education Ops team cannot find those sites' documents where they work. This is the piece of the fix that only the platform can provide: without it the sites keep sending new uploads to the sandbox even after the existing files are moved.

## Manual Effort Estimate

About 3 hours by hand (trace the link paths, write the guarded correction and its tests). Proposed figure; Keval to confirm or adjust.

## Testing

- vitest run convex/migrations/repointSiteDriveFolders.test.ts: 6 tests pass against a real test database, covering the plan's shape, authentication and capability gates, dry run, the confirmation phrase, only, conflict handling, audit entries and idempotency.

- tsc -p convex/tsconfig.json --noEmit and biome check clean for the new files.

- Not run: the full repository test suite.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

- implement the approved My Tasks and Team Tasks list designs with By Site and Simple views

- add staged filters, compact counters, linked sites, unified people clusters, and responsive list behavior

- add full-page create/edit and Task Detail experiences, including title-level lifecycle and approval actions

- reuse the shared Internal Chat frontend for the closed-by-default Task Discussion panel while preserving Task Notes semantics

- add bounded projection and note maintenance plus a durable UI contract linked to the approved mocks

## Live UI acceptance

Authenticated clickthrough covered 1536x900, 1280x800, and 390x844 across My/Team lists, search, scope counters, sorting, staged filters, pagination, Create validation/pickers/textarea/Cancel, Detail edit anchors/actions/history/activity, and Discussion open/close/focus behavior. The final two live blockers were repaired and re-tested: Team By Site to Simple retains 50 rows immediately, and the mobile Request changes panel is fully contained in a 390px viewport.

## Validation

- final GitHub CI: all 9 checks passing, including Typecheck, Test, lint/boundaries, builds, Docker builds, Workers build, secret scan, and Mercy review

- focused Task Board browser suites: 21/21 passing after final repairs

- broader Task Board UI suites: 44/44 passing before the final two focused regressions

- projection and Rhodes parity suites: 110/110 passing

- platform error inventory: 5/5 passing

- projection verifier: 201 Task rows, 623 participant rows, 201 portfolio rows, 0 mismatches or bound violations

- Task Note verifier: 201 rows, 0 mismatches or overflow tasks

- local health: 20/20 final checks healthy on ports 3010 and 3011

This is a fresh isolated PR and does not modify or merge PR #1760. No Due Diligence writeback was triggered.

## Summary

This PR is Phase 3 of 3 for [AERIE-2744 - Launch and verify the complete Task Board](https://linear.app/builder-team/issue/AERIE-2744/launch-and-verify-the-complete-task-board), part of the [Human Task Assignment from Aerie project](https://linear.app/builder-team/project/human-task-assignment-from-aerie-b3582376ae6e).

It adapts the existing agent runtime, shared tool protocol, and Rhodes worker tools to the public Task API and canonical DSS workflows activated in #1815. It also removes the remaining temporary Task launch gate. The Task UI and daily digest remain excluded.

Production effect: activation.

## Why

The Task API and its canonical DSS workflows are already complete in #1815. This final slice updates the agent runtime and worker surfaces that consume those contracts, then removes the last launch gate. Keeping this separate prevents worker and protocol changes from obscuring review of the API activation boundary.

## Business Value

- Gives agents the Task read and write tools described by the canonical DSS workflows in #1815.

- Lets the agent runtime and Rhodes worker use My Tasks and the explicit lifecycle actions without private Site-ID translation.

- Keeps agent actions on the same permissions and lifecycle rules as the public API and Aerie users.

- Removes the temporary Task launch gate after both the engine and API are in place.

## How does it work

1. The shared agent protocol and tool registry advertise the Task reads and writes already documented by DSS in #1815.

2. The agent runtime exposes those tools with the canonical Task capabilities and authority checks.

3. Rhodes worker Task tools translate agent calls into the same public Task contracts.

4. The remaining lifecycle-tool filter and temporary Task gate are removed because the engine, API, catalog, runtime, and worker now agree.

6. The launch guide records verification and rollout steps. It does not enable the redesigned UI or digest delivery.

## Scope

### Included in this phase

- Agent run protocol and tool registry support for Task operations.

- Existing agent runtime and Rhodes tool exposure aligned with the canonical authorization and dispatch paths from #1815.

- Rhodes worker Task tools and confirmation behavior.

- Final Task agent-schema parity checks.

- Removal of the temporary Task launch gate.

- Final Task Board feature and launch documentation.

- Exact final diff paths:

chat/convex/_generated/api.d.ts
chat/convex/agentRuns.test.ts
chat/convex/agentRuns/runs.ts
chat/convex/rhodesMcpMutationParity.test.ts
chat/convex/taskBoard/completion.test.ts
chat/convex/taskBoard/documents.test.ts
chat/convex/taskBoard/gate.ts
chat/convex/taskBoard/watchers.test.ts
chat/lib/rhodes-mcp-contract.ts
chat/lib/rhodes-mutation-tools.ts
chat/lib/task-agent-schema-parity.node.test.ts
chat/rhodes-worker/mcp-server/lib/confirm.ts
chat/rhodes-worker/mcp-server/tools/portfolioParity.test.ts
chat/rhodes-worker/mcp-server/tools/tasks.ts
docs/README.md
docs/task-board/FEATURE.md
docs/task-board/LAUNCH.md
packages/contracts/src/agent-run-protocol.ts
packages/contracts/src/agent-tool-registry.test.ts
packages/contracts/src/agent-tool-registry.ts

### Deliberately excluded for later phases

- My Tasks and Team Tasks UI and global navigation exposure. The refreshed UI work owns these.

- Task Scenario digest delivery. The digest remains disabled until its content is redesigned.

- Automatic account creation and other approved V1 non-goals.

- Rollback-only compatibility, speculative fallbacks, stale cursor hardening, and unrelated Mercy hardening.

## Test plan

### Automated validation

- Agent runtime, Rhodes mutation parity, Task participant, projection, and schema-parity suites: 274/274 passed across 7 files (pnpm --dir chat exec vitest run convex/agentRuns.test.ts convex/rhodesMcpMutationParity.test.ts convex/taskBoard/completion.test.ts convex/taskBoard/documents.test.ts convex/taskBoard/watchers.test.ts lib/public-api/agent-context/projection.node.test.ts lib/task-agent-schema-parity.node.test.ts). The projection suite is owned by #1815; it was included here to validate the full stacked head.

- Shared agent tool registry suite: 22/22 passed (pnpm --dir packages/contracts exec vitest run src/agent-tool-registry.test.ts --maxWorkers=1).

- Full Rhodes worker suite: 307/307 passed (pnpm --dir chat/rhodes-worker test).

- Full monorepo typecheck passed (pnpm typecheck).

- Biome passed across all 16 changed files that remain after the gate file deletion.

- git diff --check passed.

- Exact-head layer diff against #1815: 20 paths, 1,061 insertions, 763 deletions, 131,395 raw bytes.

### Time for Implementation

An engineer working without AI assistance would likely need about one week to align agent discovery, mutation dispatch, worker tooling, and end-to-end contract tests with the public Task API.

## Review repairs and contract clarifications

Latest review: https://github.com/AI-Builder-Team/Aerie/pull/1816#pullrequestreview-5490998181. Tracking issue: AERIE-2744. Repair commit: 255ef3e2f.

Mercy reported 3 blocking findings, representing 2 root causes:

- Fixed: a failed pending-mutation deduplication read no longer looks like "no existing mutation". The worker now stops and returns the failure, so it cannot create a duplicate approval record.

- Fixed: both launch-order findings identified the same issue. The existing Work Management API activation hold now remains in place until Task participant reconciliation and fresh identity verification both pass.

- Not included: Mercy explicitly deferred the broader schema-parity test suggestion. It is not one of the 3 blockers.

The repair changes only the confirmation failure behavior, its focused regression test, and the launch order. It adds no rollout system, compatibility path, UI, or digest behavior.

Validation before push:

- Confirmation module: 14/14 tests passed, including the new failed-deduplication regression.

- Biome passed for the changed TypeScript files.

- git diff --check passed.

- Hosted CI and Mercy are validating exact commit 255ef3e2f.

## Summary

This PR is a focused production repair within [AERIE-2744 — Launch and verify the complete Task Board](https://linear.app/builder-team/issue/AERIE-2744/launch-and-verify-the-complete-task-board).

It repairs Team Tasks catalog loading, separates My Tasks participant rebuilding from Team Tasks indexing, and makes the My Tasks API accept its documented page limit of 100.

Production effect: controlled rollout or migration.

## Why

Production now contains more Tasks than Team Tasks can read in one database request, and some existing Tasks contain more searchable text than the old index accepts. This leaves Team Tasks unavailable and can also prevent My Tasks participant records from being rebuilt. The public My Tasks API separately rejects its documented limit of 100.

## Business Value

- Team Tasks can load and search the complete production Task catalog.

- My Tasks participant records can be repaired even if one Team Tasks row cannot be indexed.

- Agents can request 100 My Tasks per page as documented.

## How does it work

1. Team Tasks stores its compact display rows and complete searchable text separately.

2. The browser reads both datasets in bounded pages, then applies exact search, filters, counts and sorting before showing 50 results at a time.

3. Participant reconciliation commits My Tasks relationships before Team Tasks indexing starts. Team Tasks failures are reported separately and do not undo participant repairs.

4. The My Tasks API and its published contract both accept limits from 1 to 100.

5. The launch reconciliation upgrades existing Team Tasks index rows to the new paged format and verifies the repaired data.

## Scope

### Included in this phase

- Paged Team Tasks catalog and complete full-text search indexing.

- Independent My Tasks participant and Team Tasks index reconciliation.

- My Tasks API limit validation and contract alignment.

- Exact final diff paths:

chat/components/task-board/team-tasks-catalog.node.test.ts
chat/components/task-board/team-tasks-catalog.ts
chat/components/task-board/team-tasks-view.test.tsx
chat/components/task-board/team-tasks-view.tsx
chat/convex/migrations/taskParticipants.test.ts
chat/convex/migrations/taskParticipants.ts
chat/convex/publicApi/v2/domains/workManagementTaskBoardWrites.test.ts
chat/convex/publicApi/v2/workManagementData.ts
chat/convex/rhodes/schema.ts
chat/convex/taskBoard/participants.ts
chat/convex/taskBoard/mutations.test.ts
chat/convex/taskBoard/projectionMaintenance.test.ts
chat/convex/taskBoard/queries.test.ts
chat/convex/taskBoard/queries.ts
chat/convex/taskBoard/teamProjection.test.ts
chat/convex/taskBoard/teamProjection.ts
chat/lib/public-api/v2/domains/work-management-task-board.node.test.ts
chat/lib/public-api/v2/domains/work-management.ts
docs/task-board/FEATURE.md
docs/task-board/LAUNCH.md

### Deliberately excluded for later phases

- No unrelated Task Board behavior is changed by this repair.

## Test plan

### Automated validation

- Projection and reconciliation tests — 20/20 passed (pnpm --dir chat exec vitest run convex/taskBoard/teamProjection.test.ts convex/migrations/taskParticipants.test.ts --maxWorkers=1)

- Team Tasks query tests — 42/42 passed (pnpm --dir chat exec vitest run convex/taskBoard/queries.test.ts --maxWorkers=1)

- Catalog selection tests — 4/4 passed (pnpm --dir chat exec vitest run components/task-board/team-tasks-catalog.node.test.ts --maxWorkers=1)

- Team Tasks browser tests — 14/14 passed (pnpm --dir chat exec vitest run components/task-board/team-tasks-view.test.tsx --maxWorkers=1)

- Work Management API tests — 15/15 passed (pnpm --dir chat exec vitest run convex/publicApi/v2/domains/workManagementTaskBoardWrites.test.ts --maxWorkers=1)

- Chat TypeScript check — passed (./chat/node_modules/.bin/tsc --noEmit -p chat/tsconfig.json)

- Convex path check — passed (node scripts/check-convex-paths.mjs)

- Biome on every changed TypeScript file — passed through the pre-commit gate

- git diff --check — passed

- Exact-head diff scope — only the paths listed above

### Time for Implementation

An engineer working without AI assistance would likely need 3 to 5 days to investigate the production limits, redesign the index, implement the repair, add migration safeguards and verify the affected UI and API behavior.

## Review repairs and contract clarifications

Mercy review [5494382520](https://github.com/AI-Builder-Team/Aerie/pull/1833#pullrequestreview-5494382520) identified one real compatibility-query gap. Commit 666ce27f04e0c05f5282bd2baf4407c6c77bf572 verifies the expected v4 chunk count and contiguous indexes before matching.

Mercy review [5495695732](https://github.com/AI-Builder-Team/Aerie/pull/1833#pullrequestreview-5495695732) identified a second real issue: independently paged catalog rows and search chunks could briefly come from different Task edits while preserving the same chunk count. This repair gives each catalog row and all of its search chunks the same content revision. Both the browser path and compatibility query now fail closed in the existing data-updating state if revisions do not match.

The migration-continuation finding does not describe an active production path. Reconciliation is an operator-run launch action, its continuation is held only by the caller, and the production run already completed with continuation: null. The required post-deploy repair starts from {}. Adding a legacy phase branch would therefore add unused compatibility machinery without protecting production data. No migration behavior was changed for that finding.

Validation before this push: 80/80 focused projection, migration, query, selector, and browser tests passed. The full Chat and Convex TypeScript check passed. Biome and git diff --check passed. The repair remains limited to the three fixes in this PR plus the shared search-revision check required to keep paged search results consistent.

Linear: KLAIR-3594 (slice 3 of 3; slice 1 = #3861 merged, slice 2 = #3862)

## What

The shared Anthropic billed-dollar allocation block (AICostsService._anthropic_billed_allocation_cte) used by the BU dashboard, Budget tab, TF day-factor and weekly emails now splits the keyless Claude Code dollars across the people who ran them — the same method as the fct_ai_spend mart (slice 2) and the slice-1 view, so every surface agrees.

- Keyless pool = NULL-api_key_id rows from allocation tiers 0–2 (usage-backed), per (day, org bu, model). Residual per person = per-user report − their own claude_code_key_* usage, weights 1/5/0.1/1.25, share = w / GREATEST(Σw, pool_weight). Report's estimated cost never used.

- Person rows carry api_key_id = email and bu = directory BU (exact email, then unique local part, else the org BU), so an (anthropic, email) override applies through the existing _get_anthropic_override_join with no consumer change. The unexplained share stays on the original keyless rows (scaled), so dollars are conserved per cell.

- Sales-tax uplift still applies at the terminal CTE; TF routing untouched (all keyless rows are non-TF).

- Param list grows from 6 to 12 date params (three new windowed CTEs); every caller composes cte_params + …, tests updated. The kl_reported CTE text lives in a module constant because the Claude.ai drift guard forbids the usage_date literal in the class source.

## Validation (read-only, prod, 2026-07-01..2026-09-30, real block via Data API)

| | main | this PR |

|---|---|---|

| total allocated | 8,324,496.15 | 8,324,496.14 |

| Trilogy-Inc | 6,156,642.75 | 5,995,578.31 |

| Academics | — | 159,933.73 (72 person rows) |

Trilogy-Inc drops $161.1k = the person-row total; Alpha Anywhere, IgniteTech, etc. get small shares; other BUs unchanged.

## Tests

Five executable SQLite tests (conservation, unexplained remainder, no-report no-op, directory BU fallbacks, personal-key subtraction) on top of the existing allocation harness (fixtures gained email_local, the Claude Code usage table, and SPLIT_PART/GREATEST shims). 802 passed across the AI cost / spend suites and tests/mart_saas_metrics.

## Rollout

Service-only, deploys with the normal pipeline. Slice 2's proc apply should land right after this reaches the target environment so the People tab (mart) and the BU views agree; before the apply the People tab simply still shows the keyless dollars on Trilogy-Inc.

## Business Value

Closes KLAIR-3594: the ~$160k+ per quarter of account-signed-in Claude Code spend stops hiding on Trilogy-Inc and shows up in the budgets, dashboards and weekly emails of the BUs whose people incurred it — and the same dollars by person on the People tab — with the bill tie-out unchanged.

## Manual Effort Estimate

Proposed: ~1.5 days (porting the split into the service CTE, param/test churn, prod validation). Keval to confirm/adjust.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

## Summary

This PR is Phase 2 of 3 for [AERIE-2744 - Launch and verify the complete Task Board](https://linear.app/builder-team/issue/AERIE-2744/launch-and-verify-the-complete-task-board), part of the [Human Task Assignment from Aerie project](https://linear.app/builder-team/project/human-task-assignment-from-aerie-b3582376ae6e).

It activates the public Task API, publishes its canonical Task semantics and DSS workflows, connects Work Plan Task changes to the engine shipped in #1812, and adapts existing Rhodes Task consumers to the same model. Task digest delivery stays disabled, while the separate agent runtime and worker-tool launch remains gated for Phase 3.

Production effect: activation.

## Why

The previous launch PR combined the API, agent runtime, UI, release controls, and review-only hardening in one large change. This slice gives the public API and existing Work Plan paths one independently safe production boundary. The canonical DSS workflow catalog ships with the active operations because Aerie requires every published operation to have complete workflow coverage. Existing Rhodes Task consumers also move with the new model so they cannot keep writing the retired Task shape.

## Business Value

- Lets approved users and their API keys create and manage Tasks through one public API.

- Gives Task participants the same note, watcher, evidence, approval, and history actions available through Aerie.

- Keeps existing Work Plan Task creation compact while using the same lifecycle rules underneath.

- Gives agents accurate DSS guidance for every active Task API operation.

- Sends immediate Task events while keeping the unfinished daily digest disabled.

## How does it work

1. Public Work Management routes use the Task engine from #1812 for Task reads and writes.

2. API-key owners may act on Tasks they participate in. Users with operations.tasks.write retain global Task management.

3. Task responses expose current allowed actions, unified internal and external assignments, and bounded history.

4. Work Plan writers use the same Task creation and update logic without requiring the expanded Task fields.

5. Immediate Task notification events remain active. Digest delivery stays disabled behind AERIE_TASK_SCENARIO_DIGEST_ENABLED.

6. The canonical Task semantics and DSS workflows cover every active Task operation, so the public API manifest stays complete.

7. Existing Rhodes Task reads and mutations use the same Task authority and lifecycle contracts. Phase 3 still owns the agent runtime protocol, worker tooling, and final launch-gate removal.

## Scope

### Included in this phase

- Public Task list, detail, My Tasks, create, update, assignment, notes, watcher, completion, review, document, and history operations.

- Participant-level API authority and global Task manager authority.

- Work Plan integration with the canonical Task lifecycle.

- Unified internal-user and external-email assignments.

- Immediate Task notification events and the explicit digest hold.

- Current authorization recheck before returning an idempotent append replay.

- Task-specific authority for generic Task-anchored Note updates and deletion.

- Canonical Task semantics and DSS workflows required by the active API manifest.

- Permanent Rhodes read, mutation-dispatch, and mutation-contract adaptations required by the new Task model.

- Exact final diff paths:

chat/app/(main)/tools/api-docs/page.tsx
chat/convex/agentRuns/runs.ts
chat/convex/automations/cronRegistry.ts
chat/convex/migrations/taskLifecycleContract.test.ts
chat/convex/publicApi/apiKeyAuth.ts
chat/convex/publicApi/routeManifest.test.ts
chat/convex/publicApi/v2/domains/workManagement.ts
chat/convex/publicApi/v2/domains/workManagementTaskBoardWrites.test.ts
chat/convex/publicApi/v2/domains/workManagementWrites.test.ts
chat/convex/publicApi/v2/http.test.ts
chat/convex/publicApi/v2/http.ts
chat/convex/publicApi/v2/siteNotes.test.ts
chat/convex/publicApi/v2/workManagement.test.ts
chat/convex/publicApi/v2/workManagementData.ts
chat/convex/publicApi/v2/workManagementWrites.ts
chat/convex/rhodes/mcp.ts
chat/convex/rhodes/portfolioWorkbench.ts
chat/convex/rhodes/runtime/mutationAuthorization.ts
chat/convex/rhodes/runtime/mutationDispatcher.ts
chat/convex/rhodes/runtime/writes/noteWrites.ts
chat/convex/rhodes/runtime/writes/taskWrites.ts
chat/convex/rhodesMcpMutationParity.test.ts
chat/convex/rhodesPortfolioWorkbench.test.ts
chat/convex/taskBoard/appendReceipts.ts
chat/convex/taskBoard/assignmentModel.ts
chat/convex/taskBoard/auth.ts
chat/convex/taskBoard/comments.ts
chat/convex/taskBoard/completion.test.ts
chat/convex/taskBoard/digest.test.ts
chat/convex/taskBoard/digest.ts
chat/convex/taskBoard/documents.test.ts
chat/convex/taskBoard/notifications.test.ts
chat/convex/taskBoard/notifications.ts
chat/convex/taskBoard/queries.test.ts
chat/convex/taskBoard/queries.ts
chat/convex/taskBoard/watchers.test.ts
chat/convex/taskBoard/watchers.ts
chat/lib/completion-history-pagination.node.test.ts
chat/lib/public-api/agent-context/projection.node.test.ts
chat/lib/public-api/v2/domains/work-management-schemas.ts
chat/lib/public-api/v2/domains/work-management-task-board.node.test.ts
chat/lib/public-api/v2/domains/work-management.node.test.ts
chat/lib/public-api/v2/domains/work-management.ts
chat/lib/public-api/v2/meta.ts
chat/lib/public-api/v2/openapi.node.test.ts
chat/lib/public-api/v2/openapi.ts
chat/lib/rhodes-mutation-tools.ts
packages/contracts/src/public-api-v2.test.ts
packages/contracts/src/public-api-v2.ts

### Deliberately excluded for later phases

- Agent run protocol, final lifecycle-tool discovery, and Rhodes worker Task tools. Phase 3 owns these.

- Removal of the remaining Task launch gate. Phase 3 removes it when the agent runtime and worker tools are ready.

- My Tasks and Team Tasks UI and global navigation exposure. The refreshed UI work owns these.

- Task Scenario digest delivery. The content will be redesigned before activation.

- Rollback-only compatibility, speculative fallbacks, stale cursor hardening, and unrelated Mercy hardening.

## Test plan

### Automated validation

- Focused Node API, OpenAPI, and pagination contracts: 18/18 passed (pnpm --dir chat exec vitest run --project node lib/public-api/v2/domains/work-management.node.test.ts lib/public-api/v2/domains/work-management-task-board.node.test.ts lib/public-api/v2/openapi.node.test.ts lib/completion-history-pagination.node.test.ts --maxWorkers=1).

- Focused Convex Task, public API, Work Plan, and Site Note suites: 189/189 passed across 11 files (pnpm --dir chat exec vitest run --project edge convex/publicApi/v2/workManagement.test.ts convex/publicApi/v2/domains/workManagementTaskBoardWrites.test.ts convex/publicApi/v2/domains/workManagementWrites.test.ts convex/publicApi/v2/siteNotes.test.ts convex/rhodesPortfolioWorkbench.test.ts convex/taskBoard/completion.test.ts convex/taskBoard/digest.test.ts convex/taskBoard/documents.test.ts convex/taskBoard/notifications.test.ts convex/taskBoard/queries.test.ts convex/taskBoard/watchers.test.ts --maxWorkers=1).

- Split-boundary Rhodes and global API-manifest regressions: 132/132 passed across 4 files (pnpm --dir chat exec vitest run convex/rhodesMcpMutationParity.test.ts lib/public-api/v2/domains/directory.node.test.ts lib/public-api/v2/domains/portfolio.node.test.ts lib/public-api/v2/domains/property.node.test.ts).

- Focused canonical Task catalog, Rhodes, and Task participant regressions: 151/151 passed across 6 files (pnpm --dir chat exec vitest run lib/public-api/v2/domains/work-management-task-board.node.test.ts lib/public-api/v2/domains/work-management.node.test.ts convex/rhodesMcpMutationParity.test.ts convex/taskBoard/completion.test.ts convex/taskBoard/documents.test.ts convex/taskBoard/watchers.test.ts).

- Full monorepo typecheck passed (pnpm typecheck).

- Biome passed across all 9 files in the boundary repair commit and all previously changed files.

- Convex path validation passed in the pre-commit hook.

- git diff --check passed.

- Exact-head diff against current main: 49 paths, 3,978 insertions, 1,932 deletions, 398,391 raw bytes.

### Time for Implementation

An engineer working without AI assistance would likely need about one and a half weeks to trace the public Task and Work Plan paths, align their authorization and lifecycle contracts, and validate the release boundary.

## Summary

Public API requests no longer fail with a bare 500 when several calls from the same API key land in the same rate-limit window. A write conflict on the rate-limit counter is now retried, so every request gets a real allow or a 429. Fixes [AERIE-2799](https://linear.app/builder-team/issue/AERIE-2799) and [AERIE-2830](https://linear.app/builder-team/issue/AERIE-2830).

## Why it's needed

consumeRateLimit reads and then increments one apiRateLimitWindows row per principal, bucket, and minute. When a client bursts (AERIE-2830 saw 10 GET /v2/portfolio/sites calls within ~750ms), every request writes that same row. Convex's built-in conflict retries run out, and the error falls through to the generic internal_error 500 and gets captured as a Platform Error.

Sharding the counter would make limits approximate, which doesn't work at the 10/min sensitive tier. The @convex-dev/rate-limiter component would be a new dependency. Retrying the single counter write keeps counts exact and leaves the data model unchanged.

## Changes

- chat/convex/publicApi/rateLimit.ts (new): consumePublicApiRateLimit(ctx, args) runs consumeRateLimit and retries Convex write conflicts up to 4 times, with a short jittered backoff (25ms × attempt × 1–2).

- Write conflicts are matched on OptimisticConcurrencyControlFailure or "changed while this mutation was being run".

- A conflicted mutation commits nothing, so running it again cannot double-count.

- Any other error, including ConvexErrors and argument validation errors, is thrown immediately.

- Once retries run out, the original error propagates unchanged.

- All nine call sites switch to the helper:

- v2 auth in apiKeyAuth.ts: main tier, denial, and audit buckets;

- v2 unmatched-route audit;

- v1 authorizeApiRequest;

- the Forge session buckets.

- consumeRateLimit and the schema are unchanged.

## Breaking changes

None.

## Test plan

- [x] rateLimit.test.ts:

- retries conflicts until success;

- returns 429 decisions without retrying;

- never retries ConvexErrors, validation errors, or other backend failures;

- propagates after exhaustion;

- backs off with jitter.

- [x] keys.test.ts: a burst of 12 concurrent consumeRateLimit calls at limit 10 yields exactly 10 allows, 2 denials, and one window row with count: 10.

- [x] chat: npx vitest run convex/publicApi (543 pass)

- [x] Pre-commit biome + typecheck-chat

- [x] CI

- [ ] After deploy: no new captures of this error class for public API routes

## Summary

When GET /v2/portfolio/sites/{siteRef}/buildout/milestones (or a milestone detail read) returns 503 milestone_data_unavailable, the captured Platform Error now records why the stored milestones couldn't be projected. Callers get the same 503 as before. Closes [AERIE-2824](https://linear.app/builder-team/issue/AERIE-2824).

## Why it's needed

The 19 events in AERIE-2824 were most likely the malformed-date case already fixed by #1781 (AERIE-2333), which shipped to production in today's release.

- On current code, the "status is invalid" check that triage blamed can't fire: resolveSiteMilestones and getPhaseMilestones already replace a missing or unrecognized status with notStarted before projection.

- Before #1781, the same projector also threw on malformed milestone dates. That throw sat inside the same catch-all, which is the only other way to reach this 503.

The catch-all discarded the original error, so neither Diagnostics nor triage could tell which field failed. If this 503 comes back, the event should name the cause.

## Changes

- PublicApiV2Error gains an optional diagnosticDetail string. problemResponse only copies fields it names explicitly, so this field never reaches the API response.

- The v2 request boundary adds diagnosticDetail to the captured event's metadata, which goes through the existing metadata sanitizer and 500-character cap.

- milestoneCollection puts the projector's error message in diagnosticDetail instead of dropping it.

## Breaking changes

None. Response status, code, and body are unchanged.

## Test plan

- [x] http.test.ts: a 503 carrying diagnosticDetail records it on the captured event's metadata, and the response body doesn't contain it. The test fails without the boundary change.

- [x] chat: npx vitest run convex/publicApi (546 pass)

- [x] Pre-commit biome + typecheck-chat

- [x] CI

- [ ] After deploy: no new milestone_data_unavailable events; any that do appear include diagnosticDetail

## Summary

When the Aerie Agent gateway fails to reach Rhodes at the network layer ("Unable to reach Rhodes: …"), it now classifies the failure as rhodes_mcp_upstream_error / transient_failure. Previously it was gateway_upstream_error / unexpected_failure. Closes AERIE-2829.

## Why it's needed

codeForGatewayError had no branch for the "Unable to reach Rhodes:" message that fetchWithTimeout and the Rhodes mutation propose path throw when fetch rejects. Those failures fell through to the default gateway_upstream_error code, which classifyGatewayError treats as unexpected. Each one was therefore captured as an unexpected Platform Error, and the user saw "An Aerie Agent tool failed unexpectedly." There were 4 occurrences across driveSearchFiles, listTasks, getSite, and getQualityBarScore.

## Changes

- chat/convex/agentRuns/http.ts: codeForGatewayError maps messages starting with "Unable to reach Rhodes:" to rhodes_mcp_upstream_error, the existing transient Rhodes upstream code. The check comes before the generic "not found" and "must be" checks, so an upstream error text containing those words can't be misread as a client error. The HTTP status stays 502.

- chat/convex/agentRuns.test.ts: a gateway test where the Rhodes fetch rejects. It expects a 502 with rhodes_mcp_upstream_error, transient_failure, retryable: true, and a captured event whose metadata uses the transient classification and the "temporarily unavailable" user message.

## Breaking changes

None.

## Test plan

- [x] New gateway test passes, and fails without the http.ts change (the code falls back to gateway_upstream_error).

- [x] convex/agentRuns.test.ts, convex/agentRuns, convex/skillTelemetry: 207 tests pass.

- [x] CI

## Summary

When a Google Doc or Sheet is over Drive's 10 MB export limit, it now fails indexing as too_large ("optimize the file, then Reindex") instead of "The document source cannot be accessed."

Closes AERIE-2836

## Why it's needed

The indexer reads native Google files by exporting them. Over the 10 MB cap, Drive returns a 403 with reason exportSizeLimitExceeded, and we mapped every 403 to an access-denied failure. That's what happened with POSH's FF&F catalog: an image-heavy Sheet looked like a sharing problem, and nothing told anyone the file was too big. Native Google files have no Drive size, so the size check we run before downloading can't catch this.

## Changes

- rhodes-worker/lib/document-knowledge/drive-reader.ts: on a 403, read the error body (capped at 16 KiB) and map exportSizeLimitExceeded to FILE_TOO_LARGE, which already classifies as too_large. Any other 403, or a body we can't read, stays PERMISSION_DENIED.

- convex/documentKnowledge/status.ts: the too_large message now says the limit is 10 MB for Google Docs and Sheets, alongside the 25 MiB extraction limit.

## Breaking changes

None.

## Test plan

- [x] New drive-reader.test.ts: an exportSizeLimitExceeded 403 classifies as too_large (this fails without the fix); other 403s and an unreadable body stay source_access_denied

- [x] pnpm test and pnpm typecheck in chat/rhodes-worker (310 tests)

- [x] npx vitest run convex/documentKnowledge

- [x] Pre-commit hooks: biome and typecheck-chat

- [ ] CI

## Summary

This PR delivers the Q22 lifetime CAPEX mart and the Finance-requested Bills, Vendor Credits, and Deposits source additions, while marking the older site CAPEX marts as deprecated for new consumers.

- Publishes separate Q22 lifetime CAPEX detail, school aggregates, run receipts, and source findings from the latest accepted QuickBooks snapshot.

- Adds direct-account Bill AccountBasedExpenseLineDetail, VendorCredit AccountBasedExpenseLineDetail, and Deposit DepositLineDetail Fixed Asset lines. Bills are positive; VendorCredit and Deposit credits are negative. The procedure also validates extraction lineage, duplicate keys, line expansion, direct account references, and USD currencies.

- Keeps item-based Bill/VendorCredit lines out of the Finance direct-account tie-out because their historical account would have to be inferred through today's Item setup.

- Preserves the existing Purchase/JournalEntry leg and the controlled 62700 Core leg, including allocation exclusions and durable findings.

- Adds the guarded local Q22 runner and preflight checks for freshness, snapshot lineage, and mapping alignment.

- Marks mart_education.agg_school_capex_summary and mart_education.agg_school_capex_txn_detail deprecated in canonical comments and an independent forward migration. Adds a standalone backup script for those legacy tables. The legacy writer and schedule remain active pending consumer cutover; Q22 is not a drop-in replacement for the legacy site, budget, or NetSuite semantics.

## Verification

- Q22 runner tests: 26 passed.

- Legacy CAPEX runner tests: 78 passed.

- Latest accepted snapshot preflight passed with zero unaccepted raw extractions and zero stale mappings.

- On the accepted snapshot, the new Fixed Asset source projection produced 2,664 Bill lines / $44,421,936.36, 49 VendorCredit lines / -$2,155,728.34, and one Deposit line / -$4,467.43.

## Live operational status during PR preparation

- The stored procedure was replaced in Redshift as sanket.ghia; owner and CQL_download_OM execute grant were verified.

- A guarded local Q22 refresh published run q22-local-7e9aeeb3cc894b8787ec28c2ed4f6dc6 on snapshot d892c287-31a4-432b-bb32-ef3014ac2721: 13,432 Fixed Asset lines / $58,706,807.30; 226 included 62700 lines / $9,189,369.83; total lifetime CAPEX $67,896,177.13; 13,730 detail rows, 221 aggregate rows, zero findings.

- Before that refresh, the independent Q22 backup script created and verified 27 sandbox_finance copies with suffix _bak_q22_20261008_053659.

- The independent legacy backup script created and verified backups of 41 summary rows and 2,593 detail rows with suffix _bak_legacy_capex_20261008_054505.

- The legacy deprecation migration is included but remains unapplied. Attempts as sanket.ghia and CQL_download_OM failed because the live tables are owned by marcus.day; the transaction rolled back. Apply the migration as that table owner or a superuser.

## Follow-ups

- The requested QuickBooks file-to-school attribution is not implemented here. The latest Q22 output still has $52,925,743.50 across 10,699 Fixed Asset lines in unmapped_class. A follow-up must attribute school-owned files by the governed company-to-school link and use class mappings only for shared/central files. The Core P&L source also participates in the 62700 leg, so this follow-up needs coordinated Core and Q22 attribution behavior.

- Q22's Core-success trigger still needs production deployment/verification. The Finance review requested two consecutive successful daily runs.

- Per-seat CAPEX remains out of scope because no seat-capacity source is available.

Linear: KLAIR-3594 (slice 2 of 3; slice 1 = #3861, merged)

## What

sp_refresh_fct_ai_spend now splits the keyless Claude Code spend (anthropic rows with NULL api_key_id, parked on the org BU Trilogy-Inc) across the people who ran it, as anthropic entity_type='user' rows (entity_id = lowercased email). The People tab already reads those rows, so no Python change is needed.

- Same method as the slice-1 view: residual = per-user report − the person's own claude_code_key_* usage, per token type, floored at 0; weights 1 / 5 / 0.1 / 1.25; share = w / GREATEST(Σw, pool_weight).

- Per (day, org bu, model) cell dollars and every token column are conserved; the unexplained remainder stays a NULL-entity row. The report's estimated_cost_usd is never used.

- BU for a person: exact email, then unique email local part in esw_people_accounts, else the org BU; an (anthropic, email) BU override still wins.

- The Anthropic allocation is now staged in TEMP tables (tmp_anthropic_pre, tmp_anthropic_raw). Written as CTEs of the one INSERT, the new union branches trip a Redshift planner assertion (mod == -1 && size == 0, type 705) regardless of casts or branch order; the staged form is the same logic and plans cleanly.

## Validation (read-only, against prod, real statements in one Data API session into a temp table)

| | live mart | new |

|---|---|---|

| anthropic cost | 13,323,592.7664 | 13,109,257.5218 + 214,335.2444 = 13,323,592.7662 |

| input / output / cache-read / cache-write tokens | 649,327,507,807 / 110,651,952,889 / 8,601,393,035,141 / 624,031,319,893 | identical sums |

| anthropic rows | 182,671 | 182,671 key rows (156 pool rows → 156 remainder rows) + 281 user rows |

| other providers | | identical |

The 0.0002 cost difference is numeric(18,6) rounding across 281 rows. Trilogy-Inc keyless dollars 309,892 → 95,695; about $210k lands on Academics (5 people), the rest on Alpha Anywhere, Skyvera, Core Education, Crossover etc.

## Tests

New test_fct_ai_spend_keyless_split.py runs the real CTE block in SQLite: conservation, remainder, over-report cap, personal-key subtraction, no-report passthrough, untouched keyed/other rows, [1m] normalisation, directory BU fallbacks, ambiguous directory. pytest tests/mart_saas_metrics: 113 passed.

## Apply (Keval, out of band) — hold until slice 3 deploys

Until slice 3 the BU dashboard / Budget tab / weekly emails still compute the allocation themselves, so applying this alone makes the People tab disagree with the BU views.

1. Baseline: CREATE TABLE mart_saas_metrics.fct_ai_spend_bak_YYYYMMDD AS SELECT * FROM mart_saas_metrics.fct_ai_spend.

2. Run only the CREATE OR REPLACE PROCEDURE statement from the file (the file starts with DROP TABLE).

3. CALL mart_saas_metrics.sp_refresh_fct_ai_spend();, then re-apply the table COMMENT ON TABLE.

4. Verify SUM(anthropic total_cost_dollars) equals SUM(raw_anthropic_cost_reports.amount) and the token sums match the backup.

5. Rollback: re-apply the previous proc and CALL.

## Business Value

Claude Code spend that signs in with an account instead of an API key (about $214k in this window) was invisible per person: it sat on Trilogy-Inc, which is not a budget BU. After this, those dollars are credited to the people and BUs that incurred them, so BU owners see real budgets-vs-actuals and per-person usage is answerable (the open David Harpur / Sandeep per-person questions), with the bill tie-out unchanged.

## Manual Effort Estimate

Proposed: ~3 days of focused time (allocation SQL design, a Redshift planner bug that needs bisecting, validation against prod, tests). Keval to confirm/adjust.

🤖 Generated with [Claude Code](https://claude.com/claude-code)