Skip to content

docs: clarify output shape and safe full-document packaging flow#2

Closed
stevenobiajulu wants to merge 1 commit intoAnsonLai:masterfrom
stevenobiajulu:docs/clarify-flatopc-vs-documentxml
Closed

docs: clarify output shape and safe full-document packaging flow#2
stevenobiajulu wants to merge 1 commit intoAnsonLai:masterfrom
stevenobiajulu:docs/clarify-flatopc-vs-documentxml

Conversation

@stevenobiajulu
Copy link

Summary

Thanks for maintaining this project. This PR is a docs-only clarification to reduce a packaging footgun I ran into while integrating full-document flows.

I may have misunderstood part of the output contract at first, so I framed this as guidance rather than an implementation claim.

What this changes

  • Adds an Output Shape Matrix in README.md
  • Adds a short Do / Don't for Packaging section
  • Adds a safer full-document snippet that calls out package payload detection
  • Adds AGENTS.md guardrails for <pkg:package> outputs

Why

Some API paths can return OOXML shapes that are not safe to write directly into word/document.xml.
An explicit note and helper pointer (extractReplacementNodesFromOoxml) should help prevent unreadable DOCX outputs from integration misuse.

Scope

  • Docs only
  • No behavior/API changes

Related issue: #1

Why:\nUsers integrating full-document workflows can confuse fragment/document/package payloads and accidentally write package-level XML into word/document.xml, producing unreadable DOCX files.\n\nWhat:\n- Adds an output-shape matrix by API\n- Adds do/don't packaging guidance\n- Adds explicit guardrails in AGENTS.md for <pkg:package> payloads\n- Points to extractReplacementNodesFromOoxml as the normalization helper\n\nRef: #1
@stevenobiajulu stevenobiajulu closed this by deleting the head repository Mar 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant