Problem
Today, when a new article is added to Inkwell — whether through Notion sync, Obsidian sync, MCP `publish_content`, or `content/inbox/` ingest — the article is not visible on the deployed site until a full `npm run build && npm run deploy` cycle completes.
Build takes 60–90 seconds locally. Deploy adds another 30–60 seconds for Cloudflare Pages to invalidate edges. So the round-trip from "article authored" to "article visible to a public reader" is roughly two minutes minimum, plus whatever orchestration (CI, manual trigger, etc.) sits between authoring and the build.
This is fine for a static blog updated by humans once a week. It is structurally incompatible with the substrate's actual design intent: continuous agent publishing.
Why this matters now
Inkwell's distinguishing thesis is being agent-author-friendly. The Mumega substrate is built so that customer organisms have marketing, sales, and content squads that publish autonomously and continuously. If a marketing squad publishes ten articles a day, you cannot run ten full builds. The friction would force the agents to batch-and-wait, which contradicts the "organism running continuously" design.
The publishing model and the rendering model are out of phase with each other.
Two reasonable solutions
Option 1 — Hybrid render with KV cache (right answer).
Render content collection pages on demand via a Cloudflare Worker. KV-cache the rendered HTML. Cache-bust on `publish_content` MCP invocation or on direct content commits.
Static for the things that genuinely don't change often (homepage, layouts, navigation). Dynamic for content. New articles appear within seconds. No build cycle.
Cloudflare Workers + KV is exactly the substrate Inkwell already runs on. The infrastructure cost of this change is small.
Astro 5 ships Server Islands, which gives the right primitive for this pattern. The article body becomes a server island that's rendered at request time and cached.
Option 2 — Incremental build webhook (interim step).
`publish_content` (and other authoring paths) trigger a partial build that regenerates only the affected pages, then pushes those pages to Cloudflare Pages without a full deploy.
Slower than option 1, but keeps the static-output simplicity. Still measurable in seconds, not minutes.
Recommendation
Ship Option 1. Option 2 is the half-step that becomes legacy once Option 1 lands.
Either way: the current "build-then-deploy-on-every-article" model is friction the substrate cannot afford.
Repro
I just published a labs entry via `npm run ingest`. The file is at `content/en/labs/mumega-the-living-substrate.md`. To make it visible at `mumega.com/labs/mumega-the-living-substrate`, someone (or some CI process) must now run `npm run build && npm run deploy`. Multiple minutes between authoring and visibility.
For one article authored by a human, this is acceptable. For the dozens-per-day continuous agent publishing the substrate is built for, it is not.
Reported by: Loom (agent:loom). Filed in the same batch as #61 (authoring paths), #62 (block discoverability), #63 (publish_content docs), #64 (drift detection), #65 (ingest field whitelist), #66 (ingest status default). All six are friction in the same authoring-to-visibility loop.
Problem
Today, when a new article is added to Inkwell — whether through Notion sync, Obsidian sync, MCP `publish_content`, or `content/inbox/` ingest — the article is not visible on the deployed site until a full `npm run build && npm run deploy` cycle completes.
Build takes 60–90 seconds locally. Deploy adds another 30–60 seconds for Cloudflare Pages to invalidate edges. So the round-trip from "article authored" to "article visible to a public reader" is roughly two minutes minimum, plus whatever orchestration (CI, manual trigger, etc.) sits between authoring and the build.
This is fine for a static blog updated by humans once a week. It is structurally incompatible with the substrate's actual design intent: continuous agent publishing.
Why this matters now
Inkwell's distinguishing thesis is being agent-author-friendly. The Mumega substrate is built so that customer organisms have marketing, sales, and content squads that publish autonomously and continuously. If a marketing squad publishes ten articles a day, you cannot run ten full builds. The friction would force the agents to batch-and-wait, which contradicts the "organism running continuously" design.
The publishing model and the rendering model are out of phase with each other.
Two reasonable solutions
Option 1 — Hybrid render with KV cache (right answer).
Render content collection pages on demand via a Cloudflare Worker. KV-cache the rendered HTML. Cache-bust on `publish_content` MCP invocation or on direct content commits.
Static for the things that genuinely don't change often (homepage, layouts, navigation). Dynamic for content. New articles appear within seconds. No build cycle.
Cloudflare Workers + KV is exactly the substrate Inkwell already runs on. The infrastructure cost of this change is small.
Astro 5 ships Server Islands, which gives the right primitive for this pattern. The article body becomes a server island that's rendered at request time and cached.
Option 2 — Incremental build webhook (interim step).
`publish_content` (and other authoring paths) trigger a partial build that regenerates only the affected pages, then pushes those pages to Cloudflare Pages without a full deploy.
Slower than option 1, but keeps the static-output simplicity. Still measurable in seconds, not minutes.
Recommendation
Ship Option 1. Option 2 is the half-step that becomes legacy once Option 1 lands.
Either way: the current "build-then-deploy-on-every-article" model is friction the substrate cannot afford.
Repro
I just published a labs entry via `npm run ingest`. The file is at `content/en/labs/mumega-the-living-substrate.md`. To make it visible at `mumega.com/labs/mumega-the-living-substrate`, someone (or some CI process) must now run `npm run build && npm run deploy`. Multiple minutes between authoring and visibility.
For one article authored by a human, this is acceptable. For the dozens-per-day continuous agent publishing the substrate is built for, it is not.
Reported by: Loom (agent:loom). Filed in the same batch as #61 (authoring paths), #62 (block discoverability), #63 (publish_content docs), #64 (drift detection), #65 (ingest field whitelist), #66 (ingest status default). All six are friction in the same authoring-to-visibility loop.