Word task pane: a spike that boots, and reads its own limits correctly

[peopleworks]

Draft on purpose — it has not been loaded inside Word by anybody yet. That is the one question left, and sideloading answers it in a few minutes.

What it proves

Blazor WebAssembly boots in a 340px task pane and the engine runs there. Verified by driving the published page at pane width: 92 words of AI-flavoured text scores 90/100, lists 23 named signals, and says

No verdict at this length. This text is 92 words. The boundary was measured only on texts of 649 words and longer, so no verdict is given — the score is neither evidence that a machine wrote this nor evidence that a person did. Everything below is unaffected.

That is the whole product working in a pane, including the part that refuses to answer.

A third host, not a second product

Every rule, every component and the engine arrive through SignsOfAI.UI. HostCapabilities gets the third entry its own opening comment was written for:

"the day a third host appears… the components do not need revisiting"

It needed a new runtime key rather than reusing the browser's, because "runs 100% in your browser" is false inside Word the same way it was false inside a WPF window.

Why this host is worth more than the others

A task pane is a browser. The engine runs on the machine and the document is never uploaded. Every add-in in this category posts your document to an API; this one has no endpoint to post to.

The manifest asks for ReadDocument, not ReadWriteDocument — so Word itself enforces that this add-in only reads, rather than asking anyone to trust a sentence on a website.

What the spike found by running

• The published page must reference _framework/blazor.webassembly#[.{fingerprint}].js. Without the placeholder the file name only exists during development and the pane never starts.
• The shared stylesheet assumes a page with room. In a pane, anything with a minimum width pushes content off the right edge where there is no way to scroll to it.

Not proved, because it needs Word

• That Word accepts the manifest and shows the ribbon button.
• That Word.run returns the body of a real document. The call is written and has only ever run against nothing.

src/SignsOfAI.Word/README.md has the sideload steps. The shared-folder catalogue walkthrough from PowerPointWebViewer still applies — we solved that once already.

Named rather than forgotten

• boot.js is not used here. The 503 retry from Survive the 503 that made a healthy deployment look like an outage #73/Close the holes the committee found, and stop testing the file's prose #74 lives in SignsOfAI.Web/wwwroot. A pane that hangs inside Word is worse than a tab that hangs, because there is no obvious way to open developer tools. It should move into the shared library before this ships.
• The Pages workflow does not publish /word/ yet, which the manifest's SourceLocation assumes.

PowerPoint is a separate question

Not a second <Host> entry. A deck rarely clears 649 words, so it would mostly withhold the verdict — correctly. Its honest pitch is the character scan and the named tells, which hold at any length: "does this deck carry a humanizer's fingerprints", not "is this AI".

432 tests.

🤖 Generated with Claude Code

https://claude.ai/code/session_015PEbbiYSNPw7jE3LrPNhyF

[peopleworks]

The first sideload: it loads, and it found the gap this PR had named

Pedro sideloaded it into Word on the web. Two results, and the second is not what it looked like.

Word accepts the manifest. The ribbon shows a Signs of AI group with a Read the signs button, and the pane opens over HTTPS. That is the spike's first unknown, answered.

The pane showed the wrong page, plus Word's "This add-in may not load properly". It looked like a flaky local environment. It was not:

GET https://peopleworks.github.io/SignsofAI/word/index.html  →  404

SourceLocation points there, deploy-pages.yml published only SignsOfAI.Web, so Pages answered with its SPA fallback — the web app's index.html — whose Blazor router has no route for /word/index.html and correctly rendered Not found. Word's warning was the 404.

This is exactly the gap the PR description listed as "the Pages workflow does not publish /word/ yet", reaching a user before it reached a fix.

Fixed

deploy-pages.yml now publishes this project into /word/ with its own rewritten <base href>, and fails the deploy when that entry point is missing. A task pane is loaded by URL from inside Word, where a 404 surfaces as an add-in error rather than a missing page — a long way from the cause, so it is worth failing at the deploy instead of in Word a second time.

Verified by simulating the whole deploy locally — publish both apps, rewrite both base hrefs, copy the pane under /word/, serve it, load /SignsofAI/word/index.html. It boots there and renders its own page:

banner: Signs of AI Writing · EN | ES
This pane is open outside Word, so there is no document to read.
footer: built with .NET 10 and Blazor WebAssembly · runs inside Word, on this machine

Still untested

That Word.run returns the body of a real document. The call is written and has only ever run against nothing, because the page containing it never loaded. Worth re-sideloading once this merges and Pages deploys.

The test document in the screenshots is 357 words, which is below the 649-word floor — so the expected result is a score with no verdict, and the named signals underneath.

Measured while in there

First load is 3.4 MB compressed, 2 MB of which is ICU data. That cannot be dropped with InvariantGlobalization — it would silently change how Spanish is handled — so trimming ICU to the locales this needs is the next look.

[peopleworks]

Out of draft. The reason it was one — "nobody has loaded this in Word" — no longer holds: Word accepts the manifest, puts Read the signs on the Home tab, and opens the pane. The 404 that made it show the wrong page is fixed and verified by simulating the whole deploy locally.

The last unknown, Word.run returning a real document's body, can only be tested after this merges, because the page containing that call has to be deployed for Word to load it. That is the chicken-and-egg this PR resolves.

Risk, since merging this deploys

Only one file touches production: deploy-pages.yml. Everything else is a new project nothing depends on, plus two additive locale keys and one HostCapabilities entry.

If publishing the pane fails, or its entry point is missing, the job fails and no deploy happens — the live site keeps serving what it serves today. There is no path where this half-deploys.

After merging

1. Wait for the Pages deploy (it runs on push to main).
2. Confirm the URL is real: https://peopleworks.github.io/SignsofAI/word/index.html should be 200, not 404.
3. Re-sideload the manifest in Word and press Read the signs.

With the 357-word test document, the correct result is a score with no verdict — the boundary was measured on texts of 649 words and longer — and the named signals listed underneath. If the verdict is withheld and the signals appear, Word.run works and the spike is finished.