Office Romeo, deployed at office.rominur.com, is a browser office suite — document, spreadsheet, presentation and PDF editors under one shell — whose assistant edits the file that is open rather than answering beside it. The distinction is the point of the system. An assistant that replies in a chat pane leaves the user to copy, paste and reconcile; an assistant that regenerates the whole document to change one paragraph destroys the parts nobody asked it to touch. Office Romeo takes a third path: the model is constrained to return a small JSON patch against the live canvas — a replacement for the current selection, a fragment to append, a cell write, a colour, a slide to add or update — and is instructed to prefer the smallest patch that accomplishes the request. Full-document replacement exists but is reserved for requests that genuinely mean the whole document. This paper describes four decisions supporting that design. First, a framework-neutral router: a single handleApi function returning {status, body, headers} is mounted twice, as Vite middleware in development and as serverless functions in production, so both environments execute identical routing code and the “works locally, 404 in production” class of bug is structurally excluded. Second, a latency budget computed against the platform's function ceiling: a three-model fallback chain runs under a total budget below the cap, with a per-model timeout, reasoning mode explicitly disabled because a canvas patch needs neither the latency nor the output tokens, and an early exit on authentication and billing failures where retrying cannot help. Third, a defensive reader for model output, since a model told to emit JSON will occasionally wrap it in prose or a fence. Fourth, a spreadsheet engine that is a real evaluator — tokeniser, parser, AST interpreter, sixty functions, memoised pull-based dependency walk, cycle detection and the standard error values — because a copilot that writes =SUM(D2:D6) into a grid that cannot evaluate it has not done the work. Documents are stored per user under AES-256-GCM envelope encryption, so the object store holds only ciphertext.
The common shape of an AI writing assistant is a chat panel beside a document. It is easy to build and it moves the work to the wrong place: the model produces text in one region and the user performs the actual edit by hand in another, reconciling two versions that neither party owns completely. The obvious remedy — let the model rewrite the document — substitutes a worse failure. Asked to fix a heading, a model given the whole document returns a whole document, and the paragraphs it silently reworded on the way are discovered later or not at all.
Office Romeo is built on the position that the unit of an AI edit should be a patch, and that the patch should be as small as the request allows. The model does not hold the document; the canvas does. What the model returns is a description of a change, expressed in fields the client knows how to apply to a specific region of a specific editor. A request to recolour a selection produces a colour. A request to summarise produces a fragment to append. Only a request that means the entire document — change the tone of everything — produces a full replacement.
The suite spans four editors sharing one shell: a document editor over contentEditable, a spreadsheet with its own formula engine, a slide editor, and a PDF page editor, with mail and chat surfaces alongside. The whole application is roughly nine and a half thousand lines of JavaScript and JSX with four API routes behind it.
Development and production usually run different server code. In a Vite project the dev server is middleware and production is a set of platform functions, and the routing logic gets written twice — which means it gets to disagree with itself. The disagreement surfaces as the most tedious bug in the genre: an endpoint that works on the developer's machine and returns 404 after deploy.
Office Romeo writes the router once. handleApi({ method, path, body, headers }) knows nothing about any framework and returns a plain { status, body, headers }. Two thin adapters mount it. A Vite plugin attaches it as middleware under /api for both the dev server and the preview server, additionally hydrating .env files without overriding real environment variables and capping request bodies. A serverless adapter wraps the same function as a platform handler, normalising body parsing across the several shapes a request body can arrive in.
Each production route file is then a single line that binds a path to the shared router. One of them is worth noting for a small piece of care: the authentication route is a dynamic segment, and rather than parsing the URL again it reconstructs the logical path from the platform's own parsed query parameter, so the router receives the same canonical path shape in both runtimes.
The system prompt fixes the response as a JSON object with a known set of optional fields and one required field, and instructs the model to include only the fields it actually sets. The instruction that carries the design is explicit: prefer the smallest patch; use a selection replacement for a selection, an append for added content, a colour for formatting; send full HTML only when the whole document must change.
| Field | Applies to | Effect |
|---|---|---|
message | all | Required. Short explanation shown in the panel. |
selectionHtml | doc, slides, pdf | Replaces only the highlighted range. Preferred whenever a selection exists. |
appendHtml | doc, pdf | Appends a fragment — the route a summary takes into the file itself. |
html | doc, pdf | Full replacement. Reserved for whole-document rewrites. |
cells | sheet | Zero-indexed row/column writes carrying a literal or a formula. |
formats | sheet | Bold, fill, colour, number format per cell. |
color | doc, sheet, slides, pdf | Font colour over the selection, or the used range when there is none. |
addSlide / updateSlide | slides | Adds a slide from a layout, or patches the current one. |
notes | slides, pdf | Speaker notes or page annotations. |
Selection awareness is stated as a rule rather than left to inference: when the context carries a non-empty selection, the model is told to revise or analyse only that selection, to set the selection replacement and specifically not the full-document field. This is the instruction that prevents the characteristic failure of document assistants, in which highlighting one sentence and asking for a rewrite returns a rewritten essay.
The client applies patches through per-editor handlers, and every HTML-bearing field is sanitised before it reaches the canvas — the document, slide and PDF editors each pass model fragments through a sanitiser before insertion, since model output is untrusted input like any other.
The Copilot route is the only one given a raised duration limit, and the client of that limit is written to respect it rather than to discover it. A three-model fallback chain runs under a total budget deliberately set below the platform ceiling, with a shorter per-model timeout, and the loop stops entering new attempts when too little of the budget remains to finish one.
| Parameter | Setting | Reason |
|---|---|---|
| Function duration | 30 s | Declared per-route; only the Copilot endpoint needs it. |
| Total chain budget | 26 s | Leaves headroom so the whole fallback chain finishes inside the ceiling. |
| Per-model timeout | 20 s | Bounds one attempt; the remaining budget shortens it near the end. |
| Minimum to start | 2 s | A new attempt is not begun when it cannot plausibly finish. |
| Reasoning mode | disabled | Multiplies latency and consumes the output budget; a canvas patch needs neither. |
| Response format | JSON object | Structured output requested at the API level, not only in the prompt. |
| Temperature | 0.3 | Patches are edits, not drafts. |
| Early exit | auth / billing status | Retrying a rejected key or an exhausted balance cannot succeed. |
The early exit is the detail most often missing from fallback chains. A chain that retries every model on a 401 turns one configuration error into three failed calls and three times the latency before reporting the same problem. Failures are also translated before they surface: a message matching exhausted balance or quota becomes a plain statement that the assistant is temporarily unavailable, rather than a provider error string shown to a user who can do nothing with it.
Request inputs are bounded on the way in as well — the prompt is truncated, the serialised file context is truncated, and only the last few turns of history are forwarded — so a large document cannot push the request past what the model or the function can absorb.
Structured output is requested at the API level and again in the prompt, and a model will still occasionally wrap its JSON in a markdown fence or precede it with a sentence. The reader is written for that reality rather than against it: it strips a fenced block when one is present, then takes the substring between the first opening brace and the last closing brace, and parses that. When parsing fails at any stage it does not throw — it returns the raw text as the message field, so the user sees what the model said instead of an error.
const fenced = raw.match(/```(?:json)?\s*([\s\S]*?)```/i)
const candidate = fenced ? fenced[1].trim() : raw
const start = candidate.indexOf('{')
const end = candidate.lastIndexOf('}')
if (start < 0 || end <= start) return { message: raw }
The degradation path matters more than the parsing. A malformed patch costs the user an edit; a thrown exception costs them the response entirely, including any explanation of why the edit was not possible.
Some intents are cheap to recognise without a model and expensive to get wrong with one. Font colour is the example the codebase singles out. A small module matches colour words in Indonesian and English against a palette, gated by a context test so that the word “merah” inside prose does not trigger a recolour of the document.
Its second function is more interesting: it detects refusals. A model asked to change a font colour sometimes answers that it cannot edit files and suggests opening a desktop application — a response that is both false here and useless. When a colour intent is detected and the returned message matches a refusal pattern, the patch is repaired: the colour is filled in and the message replaced with a statement of what was done. The deterministic layer does not replace the model; it catches a specific, recognisable way the model fails and completes the request anyway.
A copilot that writes formulas into a grid that cannot evaluate them produces a screenshot, not a spreadsheet. The sheet editor is backed by a genuine evaluator: a tokeniser, a parser producing an AST, and an interpreter, in roughly seven hundred lines.
| Property | Implementation |
|---|---|
| Functions | Around sixty, including SUM, AVERAGE, COUNTIF, SUMIF, VLOOKUP, INDEX, MATCH, RANK, STDEV, MEDIAN, IFERROR, TEXTJOIN, SUBSTITUTE and the date parts. |
| Evaluation | Lazy pull-based walk from each cell through its references, memoised in a map for the duration of one recalculation. |
| Cycle detection | A visiting set; re-entry on an in-progress cell yields the cycle error rather than recursing. |
| Errors | The standard set: cycle, division by zero, reference, value and name. |
| Dates | Excel serial numbers on the 1899-12-30 epoch, rendered in UTC so a serial does not shift by a day across time zones. |
| Display | Locale-aware formatting for currency, accounting, percent, scientific, date, time and plain number, with configurable decimals. |
| Literals | Leading apostrophe forces text; trailing percent divides by a hundred; leading-zero strings are preserved rather than coerced to numbers. |
The leading-zero rule is a small piece of practical care. A cell containing an identifier that begins with zero is text, not a number that has lost a digit — the defect that has quietly corrupted spreadsheets for as long as spreadsheets have existed.
Files are stored per user, keyed by a hash of the account identifier rather than the identifier itself, and the payload is encrypted before it leaves the server. The scheme is AES-256-GCM with a random initialisation vector per write, the authentication tag stored alongside, and a key derived from the server secret through a hash with a purpose string so that the storage key and the session key are not the same value.
The consequence is that the object store holds ciphertext only. Writes are timestamp-named and stale objects are removed after the new one lands, which gives a simple write-then-replace ordering: a failure between the two leaves the previous version intact rather than a truncated current one. The same module falls back to an encrypted file on disk when no object-store token is configured, so local development exercises the identical encryption path rather than a plaintext shortcut.
Sessions are a signed cookie implemented directly: a base64url payload carrying subject, profile and expiry, joined to an HMAC-SHA256 signature over that payload. Verification compares signatures with a constant-time comparison, guarded by a length check first — the comparison primitive throws on unequal lengths, so the guard is required rather than defensive. The cookie is HTTP-only with same-site restriction and a thirty-day lifetime, and the secure attribute is set from the forwarded protocol and host so that local development over plain HTTP still works.
Sign-in verifies a Google identity token against Google's own endpoint and checks the audience against the configured client, the issuer against both accepted spellings, the presence of a subject, and the expiry — with a request timeout and a length cap on the submitted credential. The trade-off is deliberate and worth naming: validating against the endpoint is simpler than verifying a signature against a rotating key set locally, at the cost of a network round trip on every sign-in.
Every HTML-bearing patch field is sanitised before insertion. The sanitiser parses into an inert template element — content parsed there is not executed and does not fetch — removes script, frame, object, embed, link, meta and style elements, then walks the remaining attributes and strips event handlers and script-scheme URLs.
The honest description of this control is that it is a denylist, and denylists over HTML are a category with a long history of bypasses. The current implementation checks a small set of URL-bearing attributes and compares against a trimmed value, which is not equivalent to the normalisation a browser's own URL parser performs. Moving to an allowlist of elements and attributes, and normalising values before comparison, is the correct direction and is the principal outstanding item in this part of the codebase. The threat model is not hypothetical: a document assistant processes text the user did not write, so anything the model emits should be treated as attacker-influenced input.
The suite is a working model of an office application, not a replacement for one. Export covers plain text, comma-separated values and HTML; it does not write the binary formats whose extensions the interface displays, so a file leaves in a form other tools can read but not in the format its name implies.
Usage of the assistant is not yet metered or attributed per account, which is the next piece of work: an endpoint that spends money on behalf of whoever calls it needs both an identity check and a budget, in that order, and the design for both already exists elsewhere in the author's work. Storage is bounded by a per-user payload ceiling, which embedded images reach quickly. Two dependencies are declared as floating latest versions rather than pinned, so two builds of the same commit can differ. And the grid is fixed at a modest size, evaluated in full on each recalculation — adequate at that size, and not an approach that survives a much larger sheet.
The argument of Office Romeo is that an assistant inside a document should return an edit, not a draft, and that the smaller the edit the more useful it is. Constraining the model to a patch vocabulary makes the assistant composable with an editor the user still controls: the selection stays the selection, the untouched paragraphs stay untouched, and the failure of one patch costs one edit rather than the document.
Two supporting decisions generalise beyond this application. Writing the router once and mounting it in both runtimes removes an entire class of environment-drift bug for the cost of one indirection. And budgeting a model call against the platform's own ceiling — total budget, per-attempt timeout, a floor below which a new attempt is not begun, and an early exit where retrying cannot help — converts an unbounded external dependency into something that fails predictably and on time.