Scribe
menu

roadmap

public direction / alpha

Scribe exists to remove the frontend and infrastructure tax from publishing technical work on a website you own. The host remains the website. Scribe makes the publication machinery dependable.

This roadmap is direction, not a promise of ship dates. Sequencing stays deliberately loose: real integration evidence can change the order, and a broken contract outranks a shiny speculative feature.

Scribe roadmap phases

near horizon

purpose

Harden the public alpha against the websites people actually bring us, without turning every edge case into another configuration system.

outcome

A developer should be able to add Scribe to an established React site, understand any real limits, and trust the result across builds, browsers, and Studio.

what this means

  1. Turn adopter failures into small, permanent regression fixtures.

  2. Expand host-preservation coverage when a real styling architecture demands it.

  3. Strengthen browser, package, framework, and computed-style evidence.

  4. Make setup and compiler diagnostics precise enough to act on without reading Scribe internals.

  5. Harden Studio editing, tables, recovery, and source-safe refusal paths.

  6. Document integration patterns and limitations from verified behavior.

after the evidence

purpose

Support sites whose identity lives in scoped classes or private semantic components, while keeping Scribe's publication machinery intact.

outcome

Hosts gain narrow bridges for real integration gaps. Scribe keeps control of semantics, accessibility, code behavior, and responsive publishing mechanics.

what this means

  1. Derive each extension point from observed integrations, not imagined flexibility.

  2. Prefer additive class, style, and safe-attribute slots over element replacement.

  3. Define deterministic prop composition and useful invalid-configuration diagnostics.

  4. Add narrow semantic renderer overrides only where additive styling cannot solve a proven need.

  5. Prove Server and Client Component behavior, serialization, client islands, and bundle impact in production Next.js and Vite fixtures.

  6. Keep headings, code frames, and other machinery-heavy surfaces Scribe-owned until evidence says otherwise.

toward 1.0

purpose

Turn a capable prerelease into a durable publishing contract that long-lived websites and outside contributors can reason about.

outcome

Compatibility, change, migration, security, and maintenance expectations become explicit and backed by repeatable evidence.

what this means

  1. Declare compatibility ranges only where CI and real consumers support them.

  2. Audit public APIs and package exports before committing to 1.0 stability.

  3. Define versioning, deprecation, and migration rules for supported surfaces.

  4. Treat visual changes as reviewed compatibility work, with evidence and migration guidance where needed.

  5. Make content trust and security boundaries explicit; add safer modes only when real untrusted workflows exist.

  6. Keep improving the contributor front door without manufacturing foundation-scale governance.

how priorities move

Use is evidence.

A reproducible integration failure, a repeated source-safety concern, or a missing primitive encountered while publishing can pull work forward. Technical curiosity alone does not.

Contained fixes do not need a permission ceremony. Changes to public contracts should begin with the problem so contributors and maintainers do not design incompatible answers in parallel.

If Scribe gets in the way of something you are trying to publish, bring the failing case to the repository.