chore: move docx-core into folio

[jan-kubica]

Summary

• move @stll/docx-core source into the monorepo
• add build, API, package, changeset, and release validation
• consume the package through the workspace dependency

[coderabbitai]

Warning

Review limit reached

@jan-kubica, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 46 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 967cd779-18ff-4a31-a704-809a7add7900

📥 Commits

Reviewing files that changed from the base of the PR and between d946b78 and 03843d2.

⛔ Files ignored due to path filters (1)

• bun.lock is excluded by !**/*.lock

📒 Files selected for processing (36)

• .changeset/silent-docx-ownership.md
• .github/workflows/ci.yml
• .github/workflows/publish.yml
• api-reports/docx-core/index.api.md
• api-reports/docx-core/model.api.md
• package.json
• packages/core/package.json
• packages/docx-core/LICENSE
• packages/docx-core/NOTICE.md
• packages/docx-core/README.md
• packages/docx-core/package.json
• packages/docx-core/src/index.ts
• packages/docx-core/src/legal-source/compile.ts
• packages/docx-core/src/legal-source/index.ts
• packages/docx-core/src/legal-source/legal-source.test.ts
• packages/docx-core/src/legal-source/parser.ts
• packages/docx-core/src/legal-source/types.ts
• packages/docx-core/src/legal-source/validate.ts
• packages/docx-core/src/model/colors.ts
• packages/docx-core/src/model/content.ts
• packages/docx-core/src/model/document.ts
• packages/docx-core/src/model/formatting.ts
• packages/docx-core/src/model/lists.ts
• packages/docx-core/src/model/styles.ts
• packages/docx-core/src/serialize/docx.test.ts
• packages/docx-core/src/serialize/docx.ts
• packages/docx-core/src/serialize/xml.test.ts
• packages/docx-core/src/serialize/xml.ts
• packages/docx-core/src/validate/docx.test.ts
• packages/docx-core/src/validate/docx.ts
• packages/docx-core/tsconfig.build.json
• packages/docx-core/tsconfig.json
• packages/docx-core/tsdown.config.ts
• scripts/api-reports.ts
• scripts/check-changeset.ts
• scripts/validate-dist.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/docx-core-ownership

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request introduces the @stll/docx-core package, which provides a typed OOXML/DOCX document model with parsing, validation, and serialization, alongside a legal-source compiler. Feedback on the changes highlights three main areas for improvement: expanding the manual numbering prefix regular expression to consistently strip multi-letter Roman numerals, ensuring that theme-colored and auto-colored border properties are preserved during serialization, and adding an explicit type check for math equations in validateParagraphContent to prevent a potential runtime TypeError.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The regular expression MANUAL_NUMBERING_PREFIX_RE uses [A-Za-z][.)] to match single-letter alphabetical or Roman numeral markers. This means single-letter Roman numerals (like I., V., X.) are stripped, but multi-letter Roman numerals (like II., III., IV., VI., IX., XI.) are ignored and not stripped. This causes inconsistent heading stripping in legal documents. Adding [IVXivx]+[.)] to the choices ensures Roman numerals of any length are consistently stripped.

const MANUAL_NUMBERING_PREFIX_RE = /^(?:\d+(?:\.\d+)+|\d+[.)]|[IVXivx]+[.)]|[A-Za-z][.)]|\([a-zivx]+\))\s+/u;

[gemini-code-assist]

The borderEdgeXml function only serializes spec.color?.rgb and defaults to "CCCCCC". It completely ignores themeColor, themeTint, themeShade, and auto properties defined on ColorValue for borders. This means any parsed document with theme-colored or auto-colored borders will lose them upon serialization. Updating the function to serialize these attributes if present preserves the visual fidelity of the document.

const borderEdgeXml = (tag: string, spec: BorderSpec | undefined): string => {
  if (!spec) {
    return "<" + tag + ' w:val="nil"/>';
  }
  if (spec.style === "none" || spec.style === "nil") {
    return "<" + tag + ' w:val="nil"/>';
  }
  const sz = spec.size ?? 4;
  let colorAttrs = ' w:color="CCCCCC"';
  if (spec.color) {
    if (spec.color.auto) {
      colorAttrs = ' w:color="auto"';
    } else if (spec.color.rgb) {
      colorAttrs = ' w:color="' + escapeXml(spec.color.rgb) + '"';
    }
    if (spec.color.themeColor) {
      colorAttrs += ' w:themeColor="' + escapeXml(spec.color.themeColor) + '"';
    }
    if (spec.color.themeTint) {
      colorAttrs += ' w:themeTint="' + escapeXml(spec.color.themeTint) + '"';
    }
    if (spec.color.themeShade) {
      colorAttrs += ' w:themeShade="' + escapeXml(spec.color.themeShade) + '"';
    }
  }
  return "<" + tag + ' w:val="' + escapeXml(spec.style) + '" w:sz="' + sz + '" w:space="0"' + colorAttrs + "/>";
};

[gemini-code-assist]

The validateParagraphContent function accesses content.ommlXml at the end of the function without explicitly checking if content.type === "mathEquation". If any other type falls through (e.g., if a new type is added to ParagraphContent in the future), this will throw a runtime TypeError because ommlXml is undefined. Explicitly checking content.type === "mathEquation" before accessing content.ommlXml makes the code robust and type-safe.

  if (content.type === "moveToRangeEnd") {
    increment(ctx.moveToEnds, content.id);
    return;
  }

  if (content.type === "mathEquation") {
    if (content.ommlXml.trim() === "") {
      addError(ctx, path + ".ommlXml", "Math equation must preserve OMML XML.");
    }
    return;
  }
};