---

name: onenote-rate-limits description: >- Implement bounded OneNote throttling, concurrency, retry, and queue backpressure from current service limits and observed responses. Use when handling 429s or scaling a delegated workload. Trigger with "handle OneNote throttling", "fix OneNote 429", or "limit OneNote concurrency". allowed-tools: Read,Glob,Grep,Write,Edit argument-hint: " " version: 1.7.0 license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags: [saas, onenote, throttling] model: inherit effort: high compatibility: "Designed for Claude Code; live OneNote actions require network access, delegated authentication, and explicit approval"

OneNote Throttling and Backpressure

Overview

Implement bounded OneNote throttling, concurrency, retry, and queue backpressure from current service limits and observed responses.. This workflow produces an auditable decision or artifact before any live action.

Prerequisites

• Current first-party Microsoft Graph OneNote documentation and the selected integration's tested contract.
• Named identity, content, workload, security, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures with secrets and real notebook content removed.

Current Contract

Current service-specific documentation defines per-app per-user delegated request windows and a small concurrency ceiling, and says OneNote resources do not return Retry-After on 429. Recheck mutable limits at execution time and use bounded exponential backoff with jitter when the server supplies no delay. Recheck the dated evidence map before relying on mutable permissions, limits, SDK behavior, supported resources, or cloud availability.

Authentication

Partition control by approved delegated user and application without exposing token values or multiplying users to evade service policy.

Instructions

1. Inventory operations, user partitions, bursts, concurrency, queues, retries, and downstream acknowledgements.
2. Read the current OneNote service limits and set conservative token buckets and concurrency below them.
3. Honor a valid server delay if observed; otherwise apply capped exponential backoff with jitter.
4. Retry only idempotent reads or writes whose idempotency and reconciliation contract is proven.
5. Feed 429 rate and delay into queue admission, circuit state, and tenant-fair backpressure.
6. Load-test with synthetic content, then document the safe envelope and emergency reduction controls.

Tool Discipline

Use Read, Glob, and Grep to inspect documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Invocation alone does not authorize network access, delegated credentials, tenant or notebook content, consent, file transfer, deployment, writes, spend, sharing changes, or deletion.

Approval Boundaries

Require the workload and sandbox owners before load tests. Do not add identities, apps, or users to circumvent limits.

Error Handling

• A 429 without Retry-After is expected contract behavior, not a parser failure.
• Stop retries at the attempt or elapsed-time budget.
• Quarantine ambiguous writes before any replay.

Output

Return current cited limits, observed headers, control parameters, retry matrix, queue policy, test curve, and rollback threshold. Identify assumptions, owners, expirations, and evidence gaps explicitly.

Examples

• Recover from a 429 response with no Retry-After.
• Prove concurrency never exceeds the configured per-user ceiling.

Validation

Exercise and record these paths with expected and observed results:

• short window
• hour window
• concurrency
• missing Retry-After
• ambiguous write
• queue saturation

Resources

• Current first-party evidence map — recheck dated sources before relying on mutable behavior.
• Treat observed tenant behavior as environment-specific evidence, never a universal OneNote guarantee.