Hanzo Dev
5a55ce029f
Normalize every packages/* package for public npm publish: - version: pre-1.0 (0.x) → 1.0.0; already-≥1.0 kept (mcp 2.4.1, cli-tools 1.8.0, dxt 1.8.1, browser/hanzo-ide/office/outlook 1.9.31, gworkspace 1.9.30, aci/auth 1.0.0) - remove "private" from all 22 gated packages/* (apps/site + repo root stay private — site is a deployed website, not an npm library) - add publishConfig.access=public everywhere (scoped @hanzo/* need it) - add files[] + valid main pointing at built output so no empty tarballs; no-build packages ship src+README CI npm job now publishes the whole workspace: - build @hanzo/cards first (slack/teams import its dist), then pnpm -r --if-present run build || true - pnpm -r publish --access public --no-git-checks --ignore-scripts --ignore-scripts prevents raycast/vscode `publish` lifecycle scripts (Raycast Store / VS Marketplace) from hijacking and aborting the run. workspace:* (auth, cards) is rewritten to the real version at publish.
Hanzo AI for PDFs
A self-contained web PDF workspace: a PDF.js viewer on the left, a Hanzo AI panel on the right. Open a filing, an executed contract, or a discovery document, then ask, summarize, and extract over it. This is the surface a lawyer spends the most time in — and unlike Acrobat's C++/Windows plugin SDK, this runs anywhere a browser does, with no Adobe license.
It reuses the same backend as the rest of the Hanzo productivity suite: model
calls go through api.hanzo.ai/v1 (OpenAI-compatible, streamed over SSE), the
same gateway the Office add-in (@hanzo/office-addin) uses. No new API surface.
What it does
- Renders the PDF (PDF.js) with page navigation and text selection.
- Extracts the selectable text of every page in the browser.
- Answers questions grounded in that text, streaming the reply — with a legal-analyst system prompt that cites page numbers and refuses to guess.
- Law-office quick actions: Summarize · Extract parties, dates & obligations · Find & explain risky clauses · Explain the selection plainly · Draft a summary memo.
Nothing leaves the browser except the pages sent with a question. Scanned image PDFs (no text layer) are detected and reported honestly — there is no OCR here.
Large PDFs — honest context windowing
A 500-page filing does not fit a model context window and is never sent
wholesale. buildContext (in src/config.ts, pure and unit-tested) caps the
attached text at CONTEXT_CHAR_BUDGET (48 000 chars) and:
- Whole document scope windows from page 1, including as many whole pages as fit the budget, in order.
- Current page only scope windows from the page you're viewing, so a question about what's on screen sends that page and its neighbours, not the top of the document.
- The first line of every request is a context note stating the exact page range sent and, when pages were dropped, telling the model to answer only from what it sees and to say so if a full answer needs the omitted pages. The model is never told it has the whole document when it doesn't.
An oversized single page is hard-cut to the budget (and flagged truncated) rather than silently overflowing.
Auth
Paste a Hanzo API key (hk-…); it is validated by a real /v1/models call
before it is saved to localStorage, so a dead key is rejected at paste time,
not at first question. An empty key still reaches the gateway's public models.
OAuth via hanzo.id (device login) is the documented future upgrade — the bearer
plumbing already tolerates any token, so it slots in without a rewrite.
Build
pnpm --filter @hanzo/pdf build # production (base https://pdf.hanzo.ai)
pnpm --filter @hanzo/pdf test # vitest — pure logic
pnpm --filter @hanzo/pdf typecheck # tsc --noEmit
build.js (esbuild → dist/) bundles app.ts as ESM and copies PDF.js's
worker (pdf.worker.mjs) beside it — app.js resolves it at runtime via
new URL('./pdf.worker.mjs', import.meta.url), so the worker must sit next to
app.js. dist/ is fully static: index.html, app.js, pdf.worker.mjs,
styles.css, assets/. Override the hosting base for local dev:
HANZO_PDF_BASE=https://localhost:8080 pnpm --filter @hanzo/pdf build
Run / host
dist/ is a static site — serve it over HTTPS from any static host. Locally:
pnpm --filter @hanzo/pdf build
cd packages/pdf/dist && python3 -m http.server 8080 # then open http://localhost:8080
Deploy target: pdf.hanzo.ai over hanzoai/static (the k8s-native static
plugin behind hanzoai/ingress — no nginx/caddy). Point the static plugin at the
built dist/; there is no server-side component. CORS is not needed —
api.hanzo.ai is same-origin-policy-friendly for the browser fetch; the
gateway sets the response headers.
The engine is small, pure, and tested
The logic-heavy parts live in their own modules with vitest coverage (tests/):
config.ts— endpoints,pickBearer, andbuildContext/contextNote(the large-PDF windowing and the honest scope note).chat.ts— request/response shaping (buildMessages,requestBody,extractContent,streamDelta,ask,askStream,listModels) — the same wire contract as the Office add-in.pdf-view.ts— the PDF.js binding;itemsToText(the text-flattening helper) is isolated and unit-tested without a real PDF.
app.ts is the thin, browser-only DOM glue that binds them together.