Import and interoperability — which other writing tools and document formats should WorldScript exchange cleanly with?

[qnbs]

Why this exists

Authors often arrive with existing material and need a trustworthy path into WorldScript. This Discussion explores interoperability without promising proprietary-format support or hiding loss.

Product decision space

Consider DOCX, Markdown/plain text, Fountain, and generic folder/Markdown import. Final Draft/FDX and Scrivener-like migration are open questions, not commitments. WorldScript JSON/project packages should preserve the canonical project model where possible, including characters, worlds, scenes, notes, and research.

Discuss semantic fidelity versus visual fidelity, explicit lossy-import warnings, round-trip expectations, import reports, and how users should review unresolved or unsupported content. A good import should explain what was recognized, what was preserved as opaque material, what was transformed, and what could not be represented.

All imported files are untrusted input. Malformed files, suspicious content, unsupported encodings, future schema versions, and oversized inputs need safe refusal or preserve-first recovery behavior. Proprietary-format support should not be inferred from a file extension or promised before an admitted implementation and test contract exists.

Context only

• export(docx): DOCX export omits characters/worlds/compile-profile and ignores the title toggle #521: DOCX export and document interoperability context.
• core(project-boundary): finish persisted schema/version verdict and retire observation-only shadow authority #553: persisted schema/version admission and preserve-first project-boundary context.
• pwa(files): add permission-scoped local file handles, native-like open/save & installed-PWA file handling #481: local file handling and permission-scoped file workflow context.

These Issues remain implementation authorities. No new Issue crosslinks are added from this Discussion.

Role perspectives

Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, user testimony, or evidence of consensus.

• ✍️ Migrating author: move real work into WorldScript with clear expectations and useful reports.
• 🎬 Screenwriter: preserve screenplay structure and distinguish Fountain or future FDX questions from general text import.
• 🧪 Data preservation/schema: retain unknown data where safe, validate owned fields, and make transformations reversible or explicit.
• 🔐 Untrusted-file security: fail safely on malformed, hostile, oversized, or future-version inputs.
• 🧭 Product scope: prioritize formats and workflows with a defensible fidelity and maintenance contract.

Questions

• Which formats and migration paths are essential first?
• What must round-trip without semantic loss, and what may be explicitly lossy?
• What should an import report show before the author accepts the result?
• How should unsupported or future-version material be preserved and surfaced?
• Which generic folder, Markdown, Fountain, or project-package patterns are most useful?
• Where should visual fidelity yield to semantic fidelity, or vice versa?

Relationship to implementation

This Discussion is interoperability and migration design only. It does not promise Final Draft/FDX, Scrivener-like migration, or any other proprietary-format support, and it does not change #521, #553, or #481 priorities, roadmap admission, acceptance criteria, or sequencing.