docx skill: build/runtime failures on Apple Silicon (macOS 26, .NET 9 SDK)

[vokasug]

Summary

The built-in docx skill cannot be used to create a DOCX on Apple Silicon with the current setup. The documented dotnet CLI workflow (dotnet run --project …) fails end-to-end. Eight reproducible issues below.

Environment

• macOS 26 (Tahoe), Apple Silicon (arm64)
• .NET SDK 9.0.315 installed via the skill's own setup.sh (uses dotnet-install.sh)
• Python 3.13.14 (Homebrew)
• Skill path on this machine: ~/.mavis/.builtin-skills/docx/
• LibreOffice 7.x via Homebrew (brew install --cask libreoffice), pdftoppm from poppler

Issues

1. dotnet build is killed by OOM (exit 137 / SIGKILL)

On a freshly cleaned tree (rm -rf obj bin), dotnet build MiniMaxAIDocx.Cli/MiniMaxAIDocx.Cli.csproj is killed by the OS with exit code 137 on the first attempt. Reproducible. Likely cause: NuGet restore plus CSC compilation of the entire Core project — including all 17 Sample files that are compiled unconditionally — exceeds available memory on M-series Macs in the 8–16 GB RAM range.

2. Target framework mismatch with DocumentFormat.OpenXml 3.5.1

Both MiniMaxAIDocx.Core.csproj and MiniMaxAIDocx.Cli.csproj declare <TargetFramework>net9.0</TargetFramework>, but DocumentFormat.OpenXml.Framework 3.5.1 ships assemblies for net35 / netstandard2.0 / net6.0 / net8.0 / net10.0 — not net9.0.

The CLI apphost is therefore built for net9.0, but the package DLLs only target net8.0. Even when the net8.0 DocumentFormat.OpenXml.Framework.dll is copied next to the executable, runtime fails to load it:

System.IO.FileNotFoundException: Could not load file or assembly
'DocumentFormat.OpenXml.Framework, Version=3.5.1.0, ...'

3. runtimeconfig.json lacks rollForward

The CLI is built as Exe + apphost with strict major-version binding. On a machine with only one .NET runtime (typical for an end user), any minor version drift causes:

You must install or update .NET to run this application.

…even when the SDK is present. A <RollForward>Major</RollForward> entry would cover the common case.

4. Hardcoded ~/.minimax paths in NuGet cache and debug symbols

The skill ships with cached NuGet restore state (obj/*.dgspec.json, obj/project.assets.json, obj/project.nuget.cache) and PDBs that contain absolute paths under:

/Users/user/.minimax/.builtin-skills/docx/scripts/dotnet/...

The skill now lives at:

/Users/user/.mavis/.builtin-skills/docx/scripts/dotnet/...

MSBuild treats these as different projects and forces a full rebuild — which then trips issue #1 again. This appears to be a leftover from a minimax → mavis rename that was never re-resolved. Reproduction:

grep -r "/Users/user/.minimax" \
  ~/.mavis/.builtin-skills/docx/scripts/dotnet/obj/ | head -5

5. dotnet installed in a non-standard location, not on PATH

setup.sh uses a private dotnet-install.sh to install the SDK into ~/.dotnet/. This path is not on PATH by default, and DOTNET_ROOT is not exported. After every shell restart, dotnet is "command not found" until both are manually exported. Fragile for first-time setup.

6. LibreOffice / soffice Homebrew install on macOS 26 is fragile

The full-gate setup.sh installs libreoffice and poppler (for pdftoppm) via Homebrew. On macOS Tahoe some formulae lag the Apple release cycle, and cask-vs-formula conflicts can break soffice --headless --convert-to pdf — the step used for rendered acceptance. The skill has no fallback when soffice is unavailable.

7. Python 3.13 + PEP 668 makes pip install fail

System python3 via Homebrew on macOS is 3.13, marked as externally-managed. Any pip install <pkg> errors out with:

note: If you believe this is a mistake, please contact your Python
installation or OS distribution provider. You can override this, at the
risk of breaking your Python installation or OS, by passing
--break-system-packages.

The skill does not document this and provides no venv strategy, so any workflow that needs python-docx or any other pip-only package is blocked on a fresh machine.

8. Documentation does not match reality on Apple Silicon

SKILL.md and docs/task-create.md describe the happy path as dotnet run --project … → works. On Apple Silicon with macOS 26 this is not true out of the box, and setup.sh does not cover issue #2. A user who simply wants a Word document ends up debugging infrastructure instead of getting the deliverable.

Reproduction

# 1. Fresh macOS 26 Apple Silicon, with .NET 9 SDK and Homebrew available
# 2. Run the skill's setup
bash ~/.mavis/.builtin-skills/docx/scripts/setup.sh

# 3. Clean any prior build state
find ~/.mavis/.builtin-skills/docx/scripts/dotnet \
  -type d \( -name obj -o -name bin \) -exec rm -rf {} +

# 4. Try to build the CLI
dotnet build \
  ~/.mavis/.builtin-skills/docx/scripts/dotnet/MiniMaxAIDocx.Cli/MiniMaxAIDocx.Cli.csproj
# → exit 137 (SIGKILL) on the first build attempt

# 5. If it builds anyway, run the CLI
~/.mavis/.builtin-skills/docx/scripts/dotnet/MiniMaxAIDocx.Cli/bin/Debug/net9.0/MiniMaxAIDocx.Cli create --help
# → issues #2 and #3 surface here

Impact

• The full CREATE_DOCX route — the headline feature of the skill — is unreachable on Apple Silicon without manual patches.
• APPLY_TEMPLATE, EDIT_FILL_DOCX, and REPAIR_LAYOUT inherit the same CLI infrastructure and are equally affected.
• Read-only routes (READ_CONTENT, READ_STRUCTURE) work because they only need Python and unzip.

Notes

This report describes behavior observed in a real session, not theoretical analysis. Commands and outputs above are quoted directly from the session log.