Which Node workbook automation workflow should @bilig/headless prove next?

[gregkonush]

@bilig/headless is aimed at Node services and coding agents that need spreadsheet behavior without driving a spreadsheet UI.

The current supported path is:

• build a WorkPaper from arrays, JSON records, or service data
• evaluate formulas
• read ranges and computed summaries
• apply controlled edits
• persist and restore workbook JSON
• verify agent-style writes after recalculation

Runnable starting points:

• npm package: https://www.npmjs.com/package/@bilig/headless
• repo: https://github.com/proompteng/bilig
• examples: https://github.com/proompteng/bilig/tree/main/examples/headless-workpaper
• agent tool-calling recipe: https://github.com/proompteng/bilig/blob/main/docs/agent-workpaper-tool-calling-recipe.md
• Node service recipe: https://github.com/proompteng/bilig/blob/main/docs/node-service-workpaper-recipe.md
• benchmark explainer: https://github.com/proompteng/bilig/blob/main/docs/what-workpaper-benchmark-proves.md

I am looking for concrete workflows to prove next, not generic feature requests.

Useful reply format:

1. Input shape: JSON records, CSV-shaped rows, imported XLSX snapshot, database result, etc.
2. Formula families or workbook behavior that matter.
3. Output you need to trust: computed summary, persisted document, audit log, generated report, agent tool result, etc.
4. What would block you from using a headless workbook API.
5. What you currently use instead, if anything.

Candidate next proofs:

• Vercel AI SDK or LangChain style tool-calling example
• finance model from JSON records with persisted assumptions
• formula-cache verification for an XLSX reduction
• unsupported-formula diagnostics for a service API
• migration notes for a small HyperFormula workflow

Maintainer disclosure: I maintain bilig. The point of this thread is to turn real workflows into small runnable examples, docs, and starter issues.

[gregkonush]

Update from the May 12 growth pass: the repo now has a serverless/API-route WorkPaper recipe wired into the README, npm README, site, sitemap, and llms.txt.

Recipe: https://github.com/proompteng/bilig/blob/main/docs/serverless-workpaper-api-route.md

It accepts JSON revenue records, writes them into a WorkPaper workbook, recalculates summary formulas, persists the workbook JSON, and returns computed values plus verification checks.

The next useful feedback: if you run spreadsheet logic behind HTTP routes or agent tools, which adapter would make this easiest to try first?

• Next.js route handler: docs(serverless): add Next.js route handler adapter #164
• Cloudflare Worker fetch handler: docs(serverless): add Cloudflare Worker fetch adapter #165
• durable JSON persistence variant: docs(serverless): add durable JSON persistence variant #166

[gregkonush]

Update: I added five small first-timer workflow issues so contributors can help prove one practical Node-service example at a time:

• invoice totals from line items: docs(examples): add invoice totals WorkPaper example #201
• budget variance alerts: docs(examples): add budget variance alert WorkPaper example #202
• subscription MRR forecast: docs(examples): add subscription MRR forecast example #203
• quote approval threshold: docs(examples): add quote approval threshold example #204
• fulfillment capacity plan: docs(examples): add fulfillment capacity plan example #205

I am trying to keep these boring and runnable: build a workbook, calculate formulas, read the result, print deterministic JSON, and avoid framework glue.

If you automate spreadsheets from Node, which one would you expect to see first in the package README? If the missing workflow is different, please describe the input data, the formulas, and the output you would want to verify.

[gregkonush]

Shipped the first workflow from this list: invoice totals from line items.

Runnable example: https://github.com/proompteng/bilig/tree/main/examples/headless-workpaper#invoice-totals

It builds invoice rows, calculates line totals, subtotal, tax, and grand total formulas, then verifies computed values plus serialized formula readback. The command is:

npm run invoice-totals

The remaining open examples are budget variance, subscription MRR, quote approval, and fulfillment capacity. Feedback still useful: which one should become the next package README example?

[gregkonush]

Shipped the second workflow from this list: budget variance alerts.

Runnable example: https://github.com/proompteng/bilig/tree/main/examples/headless-workpaper#budget-variance-alerts

It compares budget and actual rows, calculates dollar variance and variance percent, and flags rows that need review with a formula-backed alert:

npm run budget-variance

Remaining open examples are subscription MRR, quote approval, and fulfillment capacity.

[gregkonush]

Shipped the third workflow from this list: subscription MRR forecast.

Runnable example: https://github.com/proompteng/bilig/tree/main/examples/headless-workpaper#subscription-mrr-forecast

It models starting customers, new customers, churn, expansion, and ending recurring revenue with formula-backed rows:

npm run subscription-mrr

Remaining open examples are quote approval and fulfillment capacity.

[gregkonush]

Shipped the fourth workflow from this list: quote approval threshold.

Runnable example: https://github.com/proompteng/bilig/tree/main/examples/headless-workpaper#quote-approval-threshold

It calculates list total, discount amount, quote total, max line discount, and the approval status from formula-backed quote rows:

npm run quote-approval

Remaining open example from this list is fulfillment capacity.

[gregkonush]

Shipped the fifth workflow from this list: fulfillment capacity planning.

Runnable example: https://github.com/proompteng/bilig/tree/main/examples/headless-workpaper#fulfillment-capacity-plan

It compares forecast order volume with available labor hours and reads back required hours, available hours, capacity gap, short days, and status from formula-backed rows:

npm run fulfillment-capacity

That completes the five workflow examples from this discussion: invoice totals, budget variance alerts, subscription MRR, quote approval, and fulfillment capacity.

[gregkonush]

Fresh signal I want to understand: the package has real touchpoints now, but weak GitHub conversion.

Current public numbers as of May 14:

• @bilig/headless@0.14.5
• 15,592 npm downloads last week
• 20,066 GitHub clones in the last traffic window
• 23 GitHub stars
• 106 open first-timer issues

That usually means people are checking it out, but the first minute is not yet convincing enough to bookmark, star, or start an issue. I would rather fix the product/docs than ask for empty stars.

If you tried it or considered it, what made you stop?

Useful answers are concrete:

• missing formula families
• unclear XLSX import/export expectations
• not enough TypeScript examples for your framework
• benchmark shape feels wrong
• persistence API is too custom
• MCP/tool-calling surface needs a different read/write contract
• README does not answer the question you had in the first 90 seconds

The fastest current eval path is still the npm-only smoke test:
https://proompteng.github.io/bilig/try-bilig-headless-in-node.html

The MCP server is now live in the official MCP Registry as io.github.proompteng/bilig-workpaper for @bilig/headless@0.14.5:
https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.proompteng%2Fbilig-workpaper

[gregkonush]

Added a narrower write-up for the current evaluator question: when should spreadsheet automation stop driving a browser grid and use a workbook API instead?

New page: https://proompteng.github.io/bilig/stop-driving-spreadsheets-with-screenshots.html
Source: https://github.com/proompteng/bilig/blob/main/docs/stop-driving-spreadsheets-with-screenshots.md

The concrete boundary I want feedback on is: code or an agent writes inputs, the WorkPaper recalculates formulas, the caller reads exact values, then JSON export/restore proves the same calculated output without a browser session.

If you have a real workflow where you currently use ExcelJS, SheetJS, Google Sheets API, screenshots, or a browser grid to update formula-backed spreadsheets, please drop the shape here: inputs, formulas, expected outputs, persistence needs, and whether XLSX compatibility or service-side readback is the hard part.

[gregkonush]

Added a production-shaped evaluator path for the workflow question in this thread:

https://proompteng.github.io/bilig/quote-approval-workpaper-api.html

It starts from an empty Node directory, installs @bilig/headless from npm, downloads one maintained TypeScript route smoke, writes quote inputs into Inputs!B2:B6, recalculates net revenue / gross margin / approval decision, serializes the WorkPaper JSON, restores it, and verifies:

• decisionChanged: true
• formulasPersisted: true
• inputPersisted: true
• restoredMatchesAfter: true
• verified: true

This is the path I want people to judge before a generic README read. The concrete feedback ask: if this shape is close but not adoptable, what blocks a real service trial: formula coverage, XLSX import/export expectations, persistence shape, framework boundary, or agent/tool readback contract?

[gregkonush]

May 17 update: the useful discovery path so far is not broad social traffic. The visible star jump lined up with HN and headless-spreadsheet topic discovery, and the current weak point is converting serious evaluators after they clone or skim.

If you are evaluating Bilig from HN, LibHunt, npm, or a topic page, the best feedback is one concrete blocker after running one proof:

• backend formulas / agent tools: https://proompteng.github.io/bilig/try-bilig-headless-in-node.html
• quote approval service shape: https://proompteng.github.io/bilig/quote-approval-workpaper-api.html
• XLSX cached-formula pain: https://proompteng.github.io/bilig/xlsx-recalculation-proof.html

Reply with the smallest blocker that would stop production adoption:

• missing formula family
• XLSX import/export behavior
• JSON persistence or diff shape
• agent writeback/readback tool shape
• package/runtime trust issue

A tiny reproducer is more useful than a general feature request.