docs: plan the open-source OPF render/edit/convert toolkit

CHANGELOG.md

@@ -7,6 +7,7 @@
 - Shipped every `.opf.json` deck under `examples/` inside the npm package and exposed them via `@openpresentation/opf/examples` (`examples`, `galleries`, `exampleCategories`, `getExample`, `getGallery`, `getExamplesByGallery`, `getExamplesByCategory`). Each example deck is validated against the presentation schema at build time.
 - Shipped the top-level `docs/*.md` reference pages inside the npm package and exposed them via `@openpresentation/opf/docs` (`docs`, `getDoc`). Subdirectories like `docs/migrations` and `docs/plans` are intentionally excluded.
 - Shipped the upstream `README.md` markdown at the pinned release version via `@openpresentation/opf/repo-readme` so consumer sites can mirror it without a network fetch.
+- Repositioned the repo docs around the OpenPresentation OSS boundary: specs, catalogs, examples, local validation, and planned local render/edit/convert libraries, with hosted service layers left to downstream applications.
 
 ## 0.2.2
 
@@ -28,11 +29,11 @@
 - Kept the canonical spec npm artifact on the existing `@openpresentation/opf` package instead of adding a separate `@openpresentation/opf-spec` package.
 - Removed Xano-hosted chart preview URL objects from the bundled chart-type catalog records and chart-type index.
 - Kept the JavaScript package boundary local and format-level: schemas, catalogs, generated TypeScript types, and local validation only.
-- Included the full raw `spec/` tree in the packed JavaScript package, including `spec/openapi.yaml`, schemas, catalogs, reference files, and catalog indexes.
+- Included the full raw `spec/` tree in the packed JavaScript package, including the optional downstream-service reference `spec/openapi.yaml`, schemas, catalogs, reference files, and catalog indexes.
 - Added typed raw spec file manifest exports at `@openpresentation/opf/spec-files`.
 - Added a GitHub Actions npm publish workflow for semver tags with npm provenance.
 - Clarified that the OPF CLI remains local-only and is not published as part of `@openpresentation/opf` v0.2.0.
 
 ### Not Included
 
-- No hosted rendering, parsing, generation, remote catalog fetching, or PPTX.dev client behavior is included in this release-prep change.
+- No hosted rendering, parsing, generation, remote catalog fetching, or hosted-service client behavior is included in this release-prep change.

PRODUCT.md

@@ -1,33 +1,40 @@
 # Product Strategy: OPF — Open Presentation Format
 
-## Tier in the presentation stack
+## Position in the OpenPresentation ecosystem
 
-**Tier 1 — open-source primitive (MIT).** OPF is the foundation of the Open Presentation / PPTX.dev presentation stack.
+**Open-source primitives (MIT).** OPF is the foundation of the OpenPresentation project.
 
 ```
-Top:    STORYD2 (+ DeckChat)        — commercial consumer wrappers (Tier 3)
-Middle: pptx.dev                    — hosted engine / metered pay-per-use API (Tier 2)
-Bottom: OPF + pptx.gallery + SDKs   — open-source primitives, MIT (Tier 1)  ← you are here
+OpenPresentation OSS:
+  Current: OPF spec, schemas, catalogs, examples, validation, and local CLI
+  Planned: local render/edit/convert libraries
+  opf-render / opf-editor / opf-pptx
+
+Downstream applications:
+  Hosted services, agent workflows, custom editors, internal tools,
+  and self-hosted systems built by integrators
 ```
 
-- **Role in Tier 1:** OPF is the interchange format. It defines the JSON contract between LLM intent and rendered presentations so every agent in the ecosystem — ours or a third party's — can produce interoperable deck documents.
-- **Siblings in Tier 1:** [pptx.gallery](https://www.pptx.gallery) provides the human-browsable shared vocabulary. The canonical package source for machine consumers lives in this repo under `spec/` and `@openpresentation/opf`.
-- **Relationship to Tier 2 (pptx.dev):** OPF documents flow into `https://api.pptx.dev/v1` for rendering, parsing, generation, and export. The hosted engine is the paid surface. Core OPF packages do not call that API.
-- **Relationship to Tier 3 (STORYD2, DeckChat):** Commercial wrappers produce OPF and hand it to pptx.dev. Keeping OPF MIT makes STORYD2 and DeckChat *more* valuable, not less — the format is open so every AI tool standardizes on it, and the consumer products compete on UX and agent strategy.
+OpenPresentation publishes open-source code and documentation only. It does **not** provide hosted APIs, hosted rendering functions, queues, storage, authentication, jobs, previews, SLAs, telemetry, or managed infrastructure. Downstream applications can wrap the OSS primitives in their own products and services.
+
+- **Role in OpenPresentation OSS:** OPF is the interchange format. It defines the JSON contract between authoring intent and rendered presentations so agents, editors, validators, renderers, and converters can interoperate.
+- **Siblings in OpenPresentation OSS:** [pptx.gallery](https://www.pptx.gallery) provides the human-browsable shared vocabulary. The canonical package source for machine consumers lives in this repo under `spec/` and `@openpresentation/opf`.
+- **Relationship to downstream applications:** Integrators can use OPF and the toolkit to build hosted services, chatbot or agent workflows, custom editors, internal automation, and self-hosted systems without depending on OpenPresentation-hosted functions.
+- **Relationship to hosted services:** Hosted services are downstream products. They may consume OPF, run the renderer or converters, store files, manage users, or provide workflow UX, but those service layers are outside the OpenPresentation OSS boundary.
 
 ## Vision
 
-**The portable, LLM-native document format for slide decks.** `.pptx` is a zipped XML bundle that humans can't diff, LLMs can't reliably write, and git can't track. OPF is plain JSON — a real document format that models can *author*, not just decorate. Every agent, IDE, chat surface, or shell can read and write OPF, and one hosted engine (pptx.dev) renders it to `.pptx`, PDF, SVG, or PNG.
+**The portable, LLM-native document format for slide decks.** `.pptx` is a zipped XML bundle that humans can't diff, LLMs can't reliably write, and git can't track. OPF is plain JSON — a real document format that models can *author*, not just decorate. Every agent, IDE, chat surface, or shell can read and write OPF, then render or convert it locally with OSS tooling or hand it to downstream applications.
 
 ## Target Users
 
 1. **AI agent developers** building tools that generate or edit presentations programmatically (Claude Code, Cursor, Codex, LangChain, LlamaIndex, custom agents).
-2. **Developers** embedding presentation workflows in SaaS, notebooks, CI/CD, or content pipelines.
-3. **LLM application vendors** who want their product to emit durable, versionable deck artifacts without shipping their own OOXML generator.
+2. **Developers** embedding presentation workflows in SaaS, notebooks, CI/CD, internal systems, or content pipelines.
+3. **Application builders** who want durable, versionable deck artifacts without shipping their own presentation schema.
 
 ## Positioning
 
-"A JSON document format for slide decks — write it by hand, generate it with an agent, render it with one API call." OPF is the shared format; pptx.dev is the shared engine; gallery is the shared vocabulary.
+"A JSON document format for slide decks — write it by hand, generate it with an agent, validate it locally, and render or convert it with open tooling." OPF is the shared format; OpenPresentation provides open specs and libraries; integrators build the products around them.
 
 ## Distribution surfaces
 
@@ -39,30 +46,35 @@ One format, every runtime:
 | JSON Schema | `https://openpresentation.org/schema/opf/v1` | Any JSON Schema validator, editor, or agent |
 | JavaScript/TypeScript OPF package | `@openpresentation/opf` (public npm package, pre-stable 0.x) | Schemas, catalogs, types, local validation |
 | Local OPF CLI | `opf` (local workspace source; distribution deferred) | Validate, format, and inspect OPF locally |
+| Future render toolkit | `opf-render` | Local and embeddable SVG, PNG, and PDF rendering |
+| Future editor toolkit | `opf-editor` | Headless bindings and optional embeddable editor components |
+| Future PPTX toolkit | `opf-pptx` | Local OPF-to-PPTX export and PPTX-to-OPF import |
 | Future Python OPF package | TBD | Local models, schemas, catalogs, validation |
 | Future Go OPF module | TBD | Local structs, embedded schemas/catalogs, validation |
 
-PPTX.dev-specific `@pptx/sdk`, `pptx-dev`, `pptx.dev/go`, `@pptx/cli`, and `pptx-mcp` source belongs to PPTX.dev-owned repositories. Those packages consume OPF and handle hosted generation/rendering workflows; they are not the canonical OPF package direction.
+Hosted-service clients, managed workflows, and product-specific client libraries should live outside the core OPF repo. They consume OPF and the toolkit as downstream integrators; they are not the canonical OpenPresentation package direction.
 
 ## Monetization
 
-**None in Tier 1.** OPF, the JSON schema, the SDKs, the CLIs, and the MCP server are MIT-licensed public goods. Revenue flows to Tier 2 (metered pay-per-use on the hosted engine) and Tier 3 (subscriptions on STORYD2 and DeckChat). The more widely OPF is adopted, the more valuable the Tier-2 engine becomes as the default renderer.
+**None in OpenPresentation OSS.** OPF, the JSON schemas, local packages, CLI source, docs, examples, and planned render/edit/convert toolkit (`opf-render`, `opf-editor`, `opf-pptx`) are MIT-licensed public goods. The project optimizes for adoption, interoperability, local execution, and embeddable primitives. Downstream vendors may build hosted or managed products separately; OpenPresentation does not ship those hosted layers.
 
 ## Current Priorities
 
-1. **v1 spec freeze** — finalize the OPF JSON Schema, OpenAPI contract, and TS/Python/Go type surfaces so downstream SDKs can ship stable releases.
+1. **v1 spec freeze** — finalize the OPF JSON Schema, optional reference OpenAPI contract, and TS/Python/Go type surfaces so downstream packages can ship stable releases.
 2. **Canonical OPF packages** — JavaScript first, then Python and Go local-only packages for schemas, catalogs, types/models, and validation.
-3. **Local OPF CLI** — validate, format, and inspect OPF without calling PPTX.dev.
-4. **Gallery integration** — OPF documents reference catalog items by slug; packages expose the canonical bundled catalogs while pptx.gallery remains the browsable reference.
-5. **Ecosystem adoption** — inbound partnerships with agent frameworks (Claude Code, Cursor, Codex, LangChain, LlamaIndex) so OPF is the default deck format.
+3. **Local OPF CLI** — validate, format, and inspect OPF without calling a hosted service.
+4. **Render/edit/convert toolkit** — ship MIT local libraries for SVG/PNG/PDF rendering, embeddable editing, and PPTX import/export.
+5. **Gallery integration** — OPF documents reference catalog items by slug; packages expose the canonical bundled catalogs while pptx.gallery remains the browsable reference.
+6. **Ecosystem adoption** — make OPF the default deck format for agents, editors, self-hosters, and downstream applications.
 
 ## Key Decisions
 
-- **MIT license, always.** The format and client tools must stay open so every AI tool (including competitors) can produce OPF. Format lock-in is not the moat — ecosystem adoption is.
+- **MIT license, always.** The format and client tools must stay open so every AI tool and application can produce OPF. Format lock-in is not the goal — ecosystem adoption is.
 - **Open Presentation Format is the public name.** `OPF` is shorthand, and `*.opf.json` is the recommended filename pattern for complete JSON deck documents.
-- **Spec + local format packages live together, service clients move separately.** This repo owns the OPF spec, schemas, catalogs, and local validation packages. Hosted PPTX.dev clients and MCP tooling should live with the PPTX.dev service.
-- **Vanity URLs are stable.** `pptx.dev/go`, `@pptx/*`, `pptx-dev` (PyPI), and `https://openpresentation.org/schema/opf/v1` do not move even as source repos move. Existing users do not need to update import paths.
-- **PPTX.dev consumes OPF.** The hosted engine generates, renders, parses, stores, and previews presentations. OPF packages define and validate the data contract locally.
+- **OpenPresentation owns OSS primitives only.** This repo owns the OPF spec, schemas, catalogs, examples, local validation packages, and local tooling. The render/edit/convert toolkit lives in separate MIT repos and depends on this format package.
+- **No OpenPresentation-hosted runtime.** OpenPresentation libraries must run without required network calls, hosted callbacks, hidden telemetry, or managed infrastructure assumptions.
+- **Downstream applications own product surfaces.** Auth, storage, collaboration, queues, jobs, previews, billing, analytics, support, and workflow UX belong to integrators building on the OSS primitives.
+- **Stable integration seams matter.** Packages should expose predictable APIs, structured errors, package-addressable assets, custom catalog/font/theme/asset hooks, and documented semver compatibility with `@openpresentation/opf`.
 
 ## What OPF models
 

README.md

@@ -8,7 +8,7 @@ Public npm package: [`@openpresentation/opf`](https://www.npmjs.com/package/@ope
 
 Open Presentation Format is the portable, human-readable JSON document format for slide decks.
 
-This repository is the canonical home for the OPF **spec**, **JSON Schemas**, **catalog presets**, generated developer types, and local validation tooling. Anything that renders PowerPoint files, fills presentations with AI, parses `.pptx`, or calls the hosted [pptx.dev](https://pptx.dev) API belongs to PPTX.dev-specific packages, not the core OPF package.
+This repository is the canonical home for the OPF **spec**, **JSON Schemas**, **catalog presets**, examples, generated developer types, local validation tooling, and planning docs for the future render/edit/convert toolkit. OpenPresentation publishes open-source code and documentation only; it does not provide hosted APIs, hosted rendering functions, queues, storage, authentication, jobs, previews, SLAs, telemetry, or managed infrastructure.
 
 ## File naming
 
@@ -18,7 +18,7 @@ Avoid using bare `*.opf` for OPF JSON. The `.opf` extension is already used by o
 
 ## Naming and reuse
 
-The format name is **Open Presentation Format**. The schemas, catalogs, packages, and local tooling in this repository are free and open source under the MIT license, so third-party tools may read, write, validate, and describe support for Open Presentation Format without using PPTX.dev branding.
+The format name is **Open Presentation Format**. The schemas, catalogs, packages, and local tooling in this repository are free and open source under the MIT license, so third-party tools may read, write, validate, render, convert, and describe support for Open Presentation Format without adopting any product-specific branding.
 
 ## Why OPF
 
@@ -40,7 +40,19 @@ The canonical JavaScript/TypeScript package is published at [`packages/javascrip
 - generate TypeScript types, with `Presentation` as the top-level type
 - validate OPF JSON and catalog records locally
 
-It does not render `.pptx`, parse `.pptx`, generate content with AI, fetch remote catalogs, or call PPTX.dev.
+It does not render `.pptx`, parse `.pptx`, generate content with AI, fetch remote catalogs, call hosted APIs, or provide managed services. Future render/edit/convert packages are planned as separate MIT repos that depend on `@openpresentation/opf`.
+
+## Toolkit roadmap
+
+The OPF format package is shipping first. The planned toolkit lives outside this format-only repo:
+
+| Planned repo | Role | Boundary |
+|---|---|---|
+| `opf-render` | OPF to SVG/PNG/PDF | Local and embeddable rendering library |
+| `opf-editor` | WYSIWYG bindings/components | Headless editor primitives plus optional UI components |
+| `opf-pptx` | OPF to PPTX and PPTX to OPF | Pure local import/export library for browser and server use where supported |
+
+These repos provide OSS primitives only. Downstream applications own hosting, auth, storage, collaboration, queues, previews, analytics, support, and workflow UX.
 
 ### Expected Usage
 
@@ -119,20 +131,20 @@ node packages/cli/dist/index.js validate path/to/deck.opf.json
 | [`docs/examples.md`](./docs/examples.md) | Guide to the expanded scenario-oriented examples under `examples/gallery/`. |
 | [`spec/schemas/*.schema.json`](./spec/schemas) | Companion schemas for catalog records and sub-objects. |
 | [`spec/catalogs/<catalog-kind>/`](./spec/catalogs) | Canonical bundled catalog records. |
-| [`spec/openapi.yaml`](./spec/openapi.yaml) | OpenAPI contract included as raw spec content in the npm package. |
+| [`spec/openapi.yaml`](./spec/openapi.yaml) | Optional reference OpenAPI contract for downstream services that choose to expose OPF over HTTP. OpenPresentation does not host this API. |
 | [`examples/technical/`](./examples/technical) | Focused OPF fixtures for validator, renderer, catalog-resolution, design, content-payload, and region behavior. |
 | [`examples/gallery/`](./examples/gallery) | Broader OPF example decks organized by industry, function, education, government, presentation type, international, and design/media scenarios. |
 | [`packages/javascript/`](./packages/javascript) | Public pre-stable source for `@openpresentation/opf`. |
 | [`packages/cli/`](./packages/cli) | Local-only OPF CLI source; native distribution is deferred. |
-| [`legacy/`](./legacy) | Tombstone for PPTX.dev clients, CLIs, SDKs, and MCP source migrated to PPTX.dev-owned repositories. |
+| [`legacy/`](./legacy) | Tombstone for service-specific clients, CLIs, tool integrations, and workflows removed from the OpenPresentation OSS repo. |
 
-## Package Boundary
+## OpenPresentation Boundary
 
-OPF defines the format and bundled presets. PPTX.dev consumes OPF to provide hosted generation, rendering, parsing, storage, authentication, jobs, previews, and AI workflows.
+OpenPresentation defines the format, bundled presets, local validation, examples, docs, and planned local render/edit/convert libraries. It does not provide hosted functions or managed product surfaces.
 
-Future non-JavaScript OPF packages should follow the same local-only boundary: Python and Go packages should expose schemas, types/models, catalogs, and validation, not PPTX.dev rendering or generation.
+Future non-JavaScript OPF packages should follow the same local-first boundary: Python and Go packages should expose schemas, types/models, catalogs, validation, and package-addressable assets. Future toolkit packages should expose embeddable library APIs with no required network calls, hosted callbacks, hidden telemetry, or managed infrastructure assumptions.
 
-The published JavaScript package copies package-addressable OPF schemas, catalogs, reference assets, and `spec/openapi.yaml` from `spec/`. It intentionally remains `@openpresentation/opf` instead of introducing a separate `@openpresentation/opf-spec` package so downstream imports can advance by semver-pinning one canonical package.
+The published JavaScript package copies package-addressable OPF schemas, catalogs, reference assets, and the optional reference `spec/openapi.yaml` from `spec/`. It intentionally remains `@openpresentation/opf` instead of introducing a separate `@openpresentation/opf-spec` package so downstream imports can advance by semver-pinning one canonical package.
 
 ## License