# Purpur Carry

Purpur Carry is a Purpur 26.3 plugin for native animal and Villager carrying on SoMC. The approved behavior is specified in the [SoMC OKF wiki](https://git.garvis.dev/dmg/somc-okf/src/branch/main/projects/purpur-carry/index.md).

## Requirements

- Purpur 26.3 build 2651
- Java 25 or newer
- Node.js 20 or newer for release-tool verification

## Build

```bash
./gradlew clean check jar
```

The command compiles with fatal warnings, runs Java domain/adapter/distribution tests, the checksum-pinned Purpur event/command suite, and TypeScript release-tool tests, then writes `build/libs/purpur-carry-<version>.jar`. Purpur is compile-only and is not bundled. The pinned runtime is extracted in patch-only mode; tests do not start a server, open a port, create a world, or accept the EULA.

## Carrying

Players with the default-true `purpurcarry.use` permission can hold an ordinary Lead and sneak-right-click one eligible live non-hostile animal or Villager. Owned tameables accept only their owner; hostile mobs, bosses, Wandering Traders, leashed entities, existing vehicles/passengers, and unavailable participants are rejected without replacing their native interaction.

A successful action uses the same live entity as the player's one native passenger. The Lead is reusable and unchanged. Right-clicking air or a block with a main-hand Lead requests native release. Native placement, motion, falling, damage, suffocation, and environmental hazards remain authoritative; Carry does not serialize, clone, rescue-teleport, eject, grant invulnerability, or rewrite entity state.

Disconnects, deaths/removals, accepted teleports/portal transitions, carrier vehicle entry, native dismounts, and plugin disable reconcile only the owned relationship. Native cancellation is respected, and refused dismounts are reported instead of forced. `/carry` and `/carry help` explain the controls and hazards; completion suggests only `help` to permitted senders.

## Releases

Gitea Actions verifies the exact public source revision. Pull requests validate conventional commits; main-branch conventional commits drive semantic releases. Publication uses the repository-scoped `RELEASE_TOKEN` only through an in-memory Git credential helper and authenticated request headers inside the release process, never command arguments. A release is published only after the exact versioned JAR has passed the complete verification suite and uploaded successfully through a draft transaction.

A source release is not installation or deployment approval. GitOps preparation and production release use the separately gated workspace runbooks.