Mustard Mod Management

This document describes normal operational maintenance of Mustard mod JARs and the maintained update workflow. Source-specific implementation, build, and validation details remain in minecraft-projects.

Document Scope

This document covers:

• The active mod directory and artifact roles.
• The distinction between downloaded mods, Mustard-owned compatibility builds, and reconstructed patched artifacts.
• The temporary .old convention.
• Routine mod-update tooling and its intended deployed layout.
• The role of reusable diagnostic and validation tooling.
• Human review requirements for update candidates.

It does not define automated deployment or replace compatibility-project READMEs.

Active Mod Location

Active server mod JARs are stored in:

/home/container/mods/

Downloaded upstream JARs are runtime dependencies and deployment artifacts. They are not locally maintained source.

Mustard-owned compatibility source is maintained in Git. Built compatibility JARs are deployment artifacts and remain outside Git. Source-specific build procedures, hashes, version pins, and validation records remain in the corresponding Mustard source collection.

Superseded Artifact Convention

A replaced or superseded JAR may be retained temporarily with a .old suffix.

• A .old file is not an active server mod.
• It must not be reported as current deployment.
• It is a cleanup or short-term history artifact rather than source authority.
• It does not need to be retained indefinitely.

This convention allows an artifact to be removed from active loading without losing immediate rollback or reconciliation context.

Mustard Compatibility Artifacts

Operational mod maintenance distinguishes:

• Downloaded upstream mods.
• Mustard-owned compiled compatibility mods built from Git-maintained source.
• Reconstructed patched third-party artifacts produced by deterministic Git-maintained tooling.

The deployed Dual Gauge artifact is:

create_dual_guage_track-1.0-SNAPSHOT-mustardfix.jar

Its approved identities, exact semantic patch, and reconstruction procedure are documented in the Dual Gauge project README.

Routine Update Workflow

Routine mod, datapack, TreePack and configuration maintenance follows the restart-only procedure: stop Minecraft completely, apply reviewed deployment files, run the established world-asset synchronization while stopped, start and verify. Do not substitute /reload, live /datapack enable or live /datapack disable for that workflow. Offline datapack priority and protection of unrelated runtime TreePack resources remain unchanged. No automatic restart or scheduling change is introduced.

The maintained routine tools are intended to be deployed beneath the individual server's own scripts directory:

<server-root>/scripts/

Inside the Pterodactyl container, the same location is normally visible as /home/container/scripts/. Host-side paths may differ between Wings nodes and server volumes.

The active routine tools derive <server-root> from their deployed path and resolve the selected world through level-name in server.properties. The merged PR #43 sync helper prepares fresh-world initial selection before the first startup while preserving property backups and unrelated runtime TreePack content. Follow fresh-world preparation for the stopped-server sequence; no preliminary boot or synthetic level.dat is needed. Review the observed full-pack limitation and offline fallback: dynamically registered packs can still appear after the Mustard packs. For an already-generated world, the no-argument priority helper remains the supported stopped-world level.dat correction, with a session lock and backup. Always restart and verify actual resource loading and final pack order.

The Python implementation of audit-server-mod-updates.py is intentional. It uses the Python standard library, requires no shell rewrite or wrapper, and is intended to be executable directly through its shebang after separately authorized deployment:

<server-root>/scripts/audit-server-mod-updates.py

The auditor reads installed JARs, contacts Modrinth, and writes reports beneath:

<server-root>/update-tests/server-mod-update-audits/

The hardened routine update-test tooling is deployed on Mustard. Its required unchanged-mod 00-no-fixes checkpoint, complete-log guards, TreePack restoration path, normal staged comparisons, and finalization flow were exercised successfully through a completed October 2026 update cycle.

Maintained source and detailed behavior are documented in the update-testing collection.

Diagnostic and Validation Tooling

Reusable analysis and validation scripts are maintained separately from routine maintenance tools. They support targeted diagnostics, regression investigation, structure and resource analysis, and compatibility troubleshooting.

Their Git source is maintained in the analysis and validation collections. Deployed or working copies may live beneath:

/home/container/update-tests/scripts/

That directory is a reusable diagnostic toolbox, not merely disposable per-run data. Temporary investigation scripts that were not retained in Git remain disposable.

Update Review

Automated update results are candidates for human review, not automatic upgrade instructions. Review is especially important for:

• Beta and alpha releases.
• Server/client environment ambiguity.
• Compatibility shims and patched artifacts.
• Version-pinned Mustard fixes.
• Updates that change generated data or startup behavior.

Use the update-test workflow and review logs and generated comparisons before accepting a candidate.

Related Documentation

Change History

2026-10-19

• Linked merged fresh-world initialization, the observed full-pack priority limitation and the existing offline fallback without duplicating the maintenance procedure.

2026-10-18

• Linked the restart-only maintenance procedure without changing tools, deployed configuration or restart scheduling.

2026-10-10

• Recorded that the deployed routine update-test tooling was exercised successfully through finalization of the October 2026 update cycle.
• Updated the operational workflow record for the hardened Stage 00 and complete-log checks, TreePack restoration behavior, and successful end-to-end use of the revised workflow.

2026-10-05

• Corrected the documented datapack order so mustard-fixes loads before mustard-rules, leaving mustard-rules at the highest priority.
• Documented the self-contained datapack-priority helper, which no longer requires nbtlib or --confirm-server-stopped and relies on the world session lock for live-world protection.

2026-10-01

• Updated the routine maintenance model to seven tools, made host-side server-root paths portable, and documented active-world resolution from server.properties.

2026-09-25

• Added the normal mod-maintenance workflow, artifact-role and .old conventions, five routine tools, intended auditor deployment path, diagnostic-toolbox distinction, and human-review boundary.