Vision

Why dedocs exists

OOXML already solves fidelity. dedocs exists because fidelity alone does not give humans or AI a good working surface.

Workflow 1

AI-first editing with an exact core

1

Decompile the package

dedocs decompile report.docx report.dedocs

The zip archive becomes one text file with explicit parts, generated guides, and room for semantic transforms.

2

Let an agent reason over one file

\replace-text[part="word/document.xml", count="1"]
...
\insert-comment[...]
...
\end{insert-comment}

The agent edits an inspectable text artifact instead of juggling an archive plus a directory tree of OOXML parts.

3

Compile and verify

dedocs compile report.dedocs rebuilt.docx
dedocs verify report.docx rebuilt.docx

The rebuilt document is judged against the real package, not against a vague promise of readability.

Workflow 2

Collaboration without archive churn

Word collaborator edits

→

dedocs one text artifact

→

git reviewable diffs

Unpacked OOXML gives you exactness but not a stable human workflow. dedocs turns that exact package into a file that can actually move through review, prompts, and version control.

Workflow 3

Static proof instead of hidden tooling

Generated site

The public site, sample files, and downloads are emitted from the repository state itself.

Inspectable examples

Anyone can download the sample `.docx`, inspect the `.dedocs`, rebuild it, and check the same package-level guarantees.

Non-goal

dedocs does not preserve zip trivia like timestamps or compression metadata. The fidelity target is the actual document package.