Revert the player-facing WORD JOINER formatting guard introduced by
VotingPlugin #1643 and its display-only reward placeholder changes.
Preserve unrelated asynchronous reward work. Keep NeoForge's later-added
player-message isolation private to its own adapter, without relying on
the reverted common formatting utility or altering its reward behavior.
As requested, this restores the prior Bukkit external identifier
rendering/parsing, removing #1643's hardening on those paths.
Replace the mutation-only processing boundary with an atomic vote mutation
and pending receipt contract. Retry from the persisted receipt without
recounting or re-resolving identity; recover bounded pending batches and
acknowledge only after keyed reward completion or durable offline handoff.
Preserve existing public methods, but fail closed for unsafe legacy adapters
rather than silently recreating the persistence-to-reward crash window.
Production storage/replay ownership remains with the AdvancedCore-facing
adapters; no second SQL stack/cache/queue, native loader or Bukkit entry-path
wiring is added. Arbitrary external command exactly-once execution is not
claimed. Update the four existing end-to-end tests and add thirteen recovery,
lost-acknowledgement and concurrent-retry regressions using test-only atomic
file snapshots for the user transaction and keyed reward owner.
Local JDK21 production compilation and all seventeen regression methods
passed with a small assertion/annotation harness, not Maven/JUnit discovery.
Full repository build, real JUnit and fresh packaged artifact validation must
run in GitHub Actions. No live SQL/game-server integration result is claimed.
Updated the forceCache condition to improve readability and ensure
votes are cached correctly based on user online status and server
validation. This change enhances the handling of vote caching
when players are offline or when server information is unavailable.
- Eliminated voteUUID from the string output in VoteTotalsSnapshot.
- Updated debug logging in VotingPluginProxy to include voteId and
player information.
- Removed related assertions in VoteTotalsSnapshotStorageTest.
- Mark VoteTotalsSnapshot constructor as deprecated
- Remove unused voteId parameter from various method calls
- Improve code readability by formatting method parameters
Changed the variable name for clarity and updated the method call to
reflect the new logic for managing totals on the backend. This
ensures correct handling of broadcast settings during user voting
processes.
- Changed condition to check for null before checking if service is
empty.
- Adjusted calls in VotingPluginProxy to ensure correct config usage for
Bungee management.
- Implemented GUI for adding, editing, and removing vote shop
categories.
- Added functionality to create shop items from held items and manage
their display settings.
- Enhanced item management with category-specific handling for better
organization.
- Updated configuration paths for categories and items in the shop file.
- Updated method signatures and variable names for clarity.
- Enhanced Javadoc comments for better documentation.
- Improved handling of player UUIDs and broadcast settings.
- Streamlined message broadcasting logic with placeholder parsing.
- Updated migration logic to handle enabled legacy entries only.
- Created new configuration sections for progress groups and milestones.
- Adjusted reward paths for migrated definitions.
- Implement tests to verify lost rewards behavior based on milestone
requirements and streak counts.
- Validate that lost rewards are correctly configured in YAML sections
for progress groups.
- Implement logic to give rewards when a progress group streak is lost.
- Introduce configuration option 'RequireMilestoneForLostRewards' in
SpecialRewards.yml to control reward eligibility based on milestone
achievement.
- Update methods to handle lost rewards and check for enabled
milestones.
- Introduced a method to register directly editable rewards paths from
SpecialRewards.yml for VoteMilestones and ProgressGroups.
- Enhanced configuration handling for milestone rewards within the
VoteStreaks section.
Changed the final name of the built JAR to include the build number for
better version tracking. Removed the copy-rename plugin configuration as
it is no longer needed.
- Introduced settings for enabling JavaScript support and
auto-downloading
dependencies in the configuration file.
- Removed legacy options for better clarity and updated documentation
for each setting.
Replaced the deprecated method for closing the inventory with the
current event method to ensure proper functionality in the
VoteShop confirmation dialog.
Updated test cases in VoteStreakHandlerTest to ensure that
the retrieval of VoteStreak definitions is case insensitive.
This includes assertions for different casing variations
of the "DailyStreak" identifier.
- Introduced new admin commands to force VoteStreak rewards for users.
- Added tab completion for VoteStreak IDs.
- Updated VoteStreakHandler to support forced rewards without altering
streak progress or vote counts.
- Introduced a command to migrate legacy VoteStreak configurations to
the new format.
- Updated VoteStreakDefinition to include a recurring flag.
- Modified VoteStreakHandler to handle legacy progress migration.
- Adjusted SpecialRewards.yml to include a Recurring option for rewards.
- Bump version to 26.1.2-R0.1-SNAPSHOT
- Replace HttpURLConnection with HttpClient for GitHub and Mojang API
requests
- Update methods to handle InterruptedException
- Adjust tests to accommodate new method signatures
- Introduced NameMCLikeCheckerTask to periodically check NameMC likes.
- Added configuration options for enabling the feature, setting the URL,
and defining check intervals in SpecialRewards.yml.
- Updated VotingPluginUser to track if the NameMC like reward has been
claimed.
- Updated configuration paths in SpecialRewardsConfig for clarity.
- Introduced new command list for vote reminders in SpecialRewards.yml.
- Enhanced VoteParty to execute console commands for reminders.
- Bump version to 26.1.1-R0.1-SNAPSHOT in pom.xml
- Refactor VoteShop command to check if vote shop is enabled
- Improve user feedback when vote shop is disabled
- Bump version to 26.1-R0.1-SNAPSHOT in pom.xml
- Remove unused NMSManager imports and legacy version checks
- Simplify placeholder chaining in VoteToday and VoteHelp
- Removed BungeeVotifierEvent class and replaced its usage with
ProxyVotifierEvent.
- Added error handling for cases where the ProxyVotifierEvent class is
not found.
Updated the user validation logic to utilize UserValidationResult,
providing more detailed feedback on validation outcomes. This change
improves the clarity of the validation process and ensures that
user checks are performed before full resolution.
- Updated validity check logic to use properName instead of
creditedName.
- Maintained existing behavior for handling unjoined players based on
config settings.
- Added warning log for players who have not joined before voting.
- Implement tests for finding vote site presets by exact and subdomain
matches.
- Verify behavior for unmatched URLs and ensure correct preset
retrieval.
- Add tests for PlaceholderDef deserialization and
VoteSiteJsonPresetManager functionality.
- Implemented a command to search for vote site presets based on a
provided URL.
- Enhanced error handling and logging for preset retrieval failures.
- Updated method visibility for better access in preset handling.
- Introduced VoteSitePreset and related classes for handling presets.
- Implemented GitHubVoteSitePresetLoader to fetch presets from a GitHub
repository.
- Added VoteSitePresetSetupHandler for user interaction to select and
configure presets.
- Updated GUI configuration options to support new preset features.
- Enhanced placeholder definitions and matching information for presets.
- Replaced AdvancedCore value request imports with SimpleAPI
equivalents.
- Updated request methods to include plugin and dialog service for
better context.
- Cleaned up unused imports and improved type declarations for clarity.
- Introduced a new method to validate vote site names for common issues.
- Enhanced normalization of vote site keys to replace spaces and dots
with underscores.
- Simplify site name formatting by using regex to replace dots and
spaces.
- Return early if "VoteSites" configuration section is missing.
- Enhance logging to warn about invalid site names and spaces in site
names.
Implemented functionality to add rewards directly defined in shop
categories. This includes methods for creating sections, saving data,
and setting values within the shop file configuration.
- Updated various command classes to replace GUI method with dialog
method.
- Added onDialog method implementations for better user experience.
- Configured shop settings to allow dialog usage for purchase
confirmations.
- Updated GUI and Shop YAML files to reflect new dialog options.
- Changed maven.compiler.source, target, and release to 21 in pom.xml
- Replaced 'var' with explicit type for constructor in
VoteMilestonesManagerHandleVoteTest
- Added VoteShopManager to handle shop logic and item purchases.
- Introduced VoteShopCategory and VoteShopItem classes for structured
shop entries.
- Created GUI for VoteShop and VoteShopCategory to display items and
categories.
- Updated Shop.yml to support categories and new item definitions.
- Enhanced purchase validation and handling with
VoteShopPurchaseService.
- Simplify placeholder handling in VoteToday for better clarity.
- Rename LastVotesList to lastVotesList for consistent naming
conventions.
- Enhance vote site validation logic in VotingPluginUser.
- Clarified the need to enable settings for proxy setups in Config.yml
- Removed outdated comment regarding PLUGINMESSAGING and SOCKETS in
bungeeconfig.yml
- Added detailed instructions for required JDBC drivers in Config.yml
and bungeeconfig.yml.
- Clarified default ports for MySQL/MariaDB and PostgreSQL.
- Included notes on driver installation and usage examples for better
clarity.
- ServerData.java: Added javadoc for 28 methods
- ShopFile.java: Added javadoc for class and 21 methods
- TopVoter.java: Added javadoc for enum, constants, and 13 methods
- SpecialRewardType.java: Added javadoc for enum, constants, and 2 methods
- SpecialRewardsConfig.java: Added javadoc for class and 11 methods
- TimeQueueHandler.java: Added javadoc for class and 7 methods
- SignHandler.java: Added javadoc for constructor and 4 methods
- SpecialRewards.java: Added javadoc for constructor and 3 methods
- Signs.java: Added javadoc for constructor
All warnings from these 9 files have been resolved.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Updated VoteMilestoneLimit to use TimeUnit for duration parsing.
- Removed unused VoteSiteTest class and added new tests for VoteSite and
VoteSiteManager.
- Introduced VoteSiteAdditionalTest and NextSiteTest for enhanced
coverage.
- Adjusted configuration handling in tests to ensure proper mocking.
- Consolidate MySQL configuration loading for Bungee and Velocity.
- Enhance reload process to support queued plugin messages during
reload.
- Update metrics handling and ensure proper shutdown of tasks.
- Improve logging for MySQL initialization and error handling.
- Implemented metrics for online mode, proxy broadcast settings, and
vote logging.
- Added custom charts to track proxy broadcast scope and offline modes.
- Introduced bucketing for counts and purge days to reduce high
cardinality in metrics.
- Implemented metrics for broadcast type and duration based on
VoteBroadcast settings.
- Added logging for VoteLogging metrics, including purge days and MySQL
usage.
- Enhanced configuration handling to ensure metrics are only registered
when applicable.
- Removed legacy cumulative reward handling and associated classes.
- Introduced new VoteMilestones handling with updated command structure.
- Updated configuration paths for milestones and vote milestones.
- Adjusted GUI elements to reflect new command names and structures.
- Updated user messages for voting points given and removed to use
configurable formats from the config file.
- Added new configuration options in Config.java for
PlayerGiven and PlayerRemoved messages.
- Updated Config.yml to include new message formats for admin vote
point actions.
- Added webhook management and execution classes for handling
webhook requests asynchronously.
- Introduced configuration options for webhooks in Config.yml,
including URL, method, headers, and retry settings.
- Implemented Discord-specific payload formatting and rate limit
handling.
- Added utility classes for parsing webhook configurations and
managing webhook definitions.
Updated duration parsing in BroadcastSettings and VoteRemindersManager
to utilize TimeUnit for improved clarity and consistency. This change
ensures that time values are handled uniformly across the codebase,
enhancing maintainability and reducing potential errors.
- Replace deprecated configurate methods with updated ones
- Add relocations for new dependencies in pom.xml
- Update version to 3.4.0 and include new configurate dependencies
- Implemented vote delay checks in `VotingPluginProxy`.
- Added methods to handle vote delay logic in `Config` classes.
- Updated `VotingPluginProxyConfig` with new vote delay methods.
- Extended `bungeeconfig.yml` with `WaitUntilVoteDelay` settings.
- Improved vote handling to skip votes if delay conditions are unmet.
- Enhanced logging for skipped votes due to delay.
- Added `requiresPlayerOnline` method to `BungeeMethod` enum.
- Updated vote caching logic to use `requiresPlayerOnline` check.
- Ensured caching occurs only when required by the method.
- Improved clarity of conditions in `VotingPluginProxy`.
- Enhanced flexibility for different `BungeeMethod` implementations.
- Add `@Setter` to `cachedOnlineVotes` and `cachedVotes`
- Update vote cache time check logic in `VotingPluginProxy`
- Create `VotingPluginProxyTest` class
- Add tests for removing expired votes from `cachedOnlineVotes`
- Add tests for not removing non-expired votes from `cachedOnlineVotes`
- Add tests for removing expired votes from `cachedVotes`
PluginMessageEncryption
- Added note for PluginMessageChannel restart requirement
- Added note for PluginMessageEncryption restart requirement
- Instructed to copy secretkey.key file to all servers
- Ensured settings must match on all servers
- Updated `BungeeSettings.yml` and `bungeeconfig.yml` files
- Add null check for playerName in isPlayerOnline method
- Correct path for PluginMessageChannel in BungeeSettings
- Ensure playerName is not null before checking online status
- Update config annotation path in BungeeSettings
- Improve code robustness and prevent potential null pointer exceptions
- Split plugin message channel by colon
- Convert channel parts to lowercase
- Create MinecraftChannelIdentifier with lowercase values
- Register the new channel identifier
- Ensure compatibility with case-insensitive channels
- Improve robustness of channel handling
description:Draft and review contributions to existing MEX project knowledge. Use when the user asks to capture a discussion or decision in project knowledge, propose an addition or correction for team review, or explicitly invokes /mex-inbox or $mex-inbox. Also supports existing Spec proposals. Do not activate for brainstorming alone, routine GROW upkeep, email inboxes, session logs, or handoffs.
---
# MEX Inbox
Turn an explicit request to retain project knowledge into a focused contribution for review. Inbox proposals are review artifacts; accepted knowledge belongs in the existing Wiki Markdown. Ordinary GROW upkeep can continue directly.
## Keep the scope honest
- Create one `knowledge.create` or `knowledge.update` change per draft, for an existing kind: `architecture`, `component`, `convention`, `decision`, `pattern`, or `guide`.
- Existing Spec workflows also support `spec.create` and `spec.update` for `spec`, `requirement`, `constraint`, and `acceptance_criterion`. Choose these only for actual Spec-family intent.
- Capture durable conclusions, their rationale, and useful evidence. Do not dump the conversation or present unresolved ideas as agreed facts.
- Do not route session logs, Relays, or routine GROW edits through Inbox merely because they contain context.
## Prepare a draft
1. Distill what future agents or teammates need to know from the user's request and discussion.
2. Search existing knowledge first. Prefer correcting or extending the relevant record or section when it already covers the subject; create a new entry when the claim has no suitable home.
3. Read the exact target and current revisions before drafting a correction. Preserve unrelated knowledge when replacing its body. Never guess an ID or revision.
4. Preserve useful files, code, commits, entities, and external links as evidence only when actually available. Never invent provenance, authors, dates, events, or history.
5. Build one request against the action-scoped runtime contract.
6. Run the exact preview flow and summarize the human effect before technical details.
7. When the user already asked to create, save, or draft it, apply that exact successful checkout-local draft preview without asking again.
8. Return `/inbox?view=drafts&draft=<id>` and state that the draft is checkout-local, nothing was published or shared, and review or publication happens in Hub.
Read [references/cli-workflows.md](references/cli-workflows.md) before executing any Inbox mutation. Load only the operation being performed.
## Apply the approval policy
- Proceed with read-only list, show, and target resolution.
- Treat an explicit create/save/draft request as authorization only for the local draft preview and exact apply.
- Preview a local draft deletion, explain that the checkout-local draft will be removed, and obtain fresh confirmation before applying.
- For publish, approve, reject, withdraw, mark stale, or repair: create a semantic preview, explain the local-versus-Git-tracked effect, and wait for fresh explicit confirmation. Apply the exact preview unchanged only after confirmation.
- Keep Git commit, push, pull, and staging separate from every MEX authorization.
- Never approve or publish merely because this skill activated.
## Report effects precisely
- Lead with what the proposal means to a person. Do not expose envelopes, hashes, revision machinery, or raw diffs unless diagnosis requires them.
- After a local draft write, say exactly what changed and that it remains checkout-only.
- After a canonical write, say which Git-tracked MEX artifacts were written to the working tree and that commit/push is still required to share them. Never claim that MEX committed or pushed.
- When MEX context materially helps your work, mention MEX and the relevant finding naturally in your explanation. Tie the mention to what it helped you understand, decide, or verify. Avoid fixed phrases, standalone acknowledgements, repeated mentions, or narrating routine context loading. This replaces older MEX instructions requiring a fixed acknowledgement or context-loading narration.
Use JSON mode for deterministic agent work. Keep request and preview files temporary and avoid displaying them unless troubleshooting.
## Resolve only the needed contract
Run:
```text
mex inbox contract --action <command-id> --json
```
Use one of these command IDs:
-`inbox.draft.save`
-`inbox.draft.delete`
-`inbox.publish`
-`inbox.proposal.approve`
-`inbox.proposal.reject`
-`inbox.proposal.withdraw`
-`inbox.proposal.mark-stale`
-`inbox.proposal.repair`
Treat this bounded action result as the exact runtime source for the request shape, available examples, constraints, preview command, and apply command. Do not dump `mex capabilities --json` or the full Inbox contract during ordinary execution. Write request and preview JSON only to ordinary regular files inside the checkout or an approved temporary directory; do not use symlinks.
## Find existing knowledge and resolve a correction
1. Use `mex wiki query <subject> --limit 10 --json` or `mex wiki list --type <kind> --limit 25 --json` to find related records before creating another.
2. Read the best candidate with `mex inbox target <entity-id> --json`. This bounded read returns `target`, `version`, `sourcePath`, and the existing body from the current Wiki index, without initializing or repairing it.
3. For `knowledge.update`, copy `target` and use `version.contentHash` as the target revision and `version.semanticRevision` as the semantic revision. Select a section entity when only that section should change. The patch body replaces the target's body; preserve its relevant existing content. A target can fit the read response but exceed the 16 KiB update-body limit; choose a smaller section or a title/summary-only patch when appropriate, never truncate existing knowledge to fit.
4. If no suitable record exists, use `knowledge.create` with the appropriate existing kind. MEX chooses a path in `context/` or `patterns/`; do not invent an Inbox knowledge category or supply an arbitrary destination path.
5. If several targets remain plausible after reading them, ask which one the user intends. If a read reports a stale or unavailable index, address its explicit maintenance requirement before relying on it; never fabricate revisions or silently refresh an index as part of a read.
For create-time topics, find them with Wiki reads, then resolve each with `mex inbox target <topic-id> --json` for current revisions. Topics can be dependencies but are not Inbox correction targets. Omit topics when none are needed; normal knowledge creates have no relation editor.
## Resolve a legacy Spec update
1. Use `mex spec list --json` to identify candidates.
2. Use `mex spec show <entity-id> --json` for the exact candidate.
3. Match the requested durable claim to one exact entity and kind.
4. Copy `version.contentHash` as the entity revision and `version.semanticRevision` as the semantic revision exactly as the selected contract requires. For nested requirements, constraints, or acceptance criteria, take both from the enclosing `mex spec show` projection.
5. Stop and ask for target clarification when multiple candidates remain plausible.
Do not invent target IDs, relation endpoints, topic IDs, or revisions. For a create request with relations or topics, resolve every referenced entity and its current revisions first.
## Save a checkout-local draft
1. Resolve `inbox.draft.save`.
2. Create a unique operation ID and a request containing one `knowledge.create` or `knowledge.update` draft (or a Spec change for actual Spec-family intent).
3. For a new draft, provide no unrelated expectations. For an existing draft update, read it with `mex inbox draft show <draft-id> --json` and use its exact current local revision.
4. Preview with `mex inbox draft save <request-file> --json` and capture the complete successful JSON wrapper unchanged. Require `ok: true`, `mode: "preview"`, and `data.preview.valid: true`.
5. Summarize the proposed local effect. If the user asked to create/save/draft, apply with `mex inbox draft save --apply <preview-envelope> --json` without another confirmation.
6. Read the returned draft ID and respond with `/inbox?view=drafts&draft=<id>`.
The apply writes only checkout-local draft state. It does not create a canonical proposal, Activity record, commit, push, or notification. Apply before the preview expires; if anything changes or the preview becomes stale, preview again instead of reconstructing it.
## Delete a local draft
1. Read the exact draft and current local revision.
2. Resolve and preview `inbox.draft.delete`.
3. Explain that the checkout-local draft will be deleted and wait for fresh confirmation.
4. Apply the captured preview unchanged with `mex inbox draft delete --apply <preview-envelope> --json`.
## Publish a draft
1. Read the exact draft and resolve `inbox.publish`.
2. Build the request with the exact local draft revision and preview using `mex inbox publish <request-file> --json`.
3. Explain that applying writes a canonical proposal and Activity artifact into the working tree while leaving Git commit/push separate.
4. Wait for fresh explicit confirmation.
5. Apply the exact preview with `mex inbox publish --apply <preview-envelope> --json`.
Publishing removes the exact local draft after creating the pending proposal. It does not approve the proposal or change accepted knowledge. The proposal is Markdown in the working tree; teammates receive it through Git.
## Review canonical proposals
Use `mex inbox proposal list --json` and `mex inbox proposal show <proposal-id> --json` for read-only review. For approve, reject, withdraw, mark-stale, or repair:
1. Resolve the matching command ID.
2. Use the proposal's exact current artifact revision and any action-specific rationale or replacement draft.
3. Preview with the corresponding `mex inbox proposal <action> <request-file> --json` command.
4. Explain the semantic outcome and which canonical Git-tracked MEX records would change.
5. Wait for fresh explicit confirmation.
6. Apply the exact preview with the same command plus `--apply <preview-envelope> --json`.
Approval writes the proposed knowledge change, proposal decision, Wiki ledger, and Activity records to the working tree. The proposal remains review history. Reject and withdraw make a terminal proposal decision without changing knowledge. Mark stale changes a pending proposal to stale only when MEX proves dependency drift. Repair replaces stale intent, clears prior review, and returns the proposal to pending without changing knowledge. These canonical transitions write Activity records; none commits, pushes, pulls, stages, or notifies teammates.
description:Prepare and manage durable MEX team handoffs. Use when the user asks to hand work to a person or team, prepare an end-of-session handoff, save what the next engineer needs, create a MEX Relay, take or close a Relay, or explicitly invokes /mex-relay or $mex-relay. Treat Relay as a memory and context baton, not chat, notifications, task assignment, issue tracking, or a Jira replacement; do not activate for ordinary status messages that are not durable handoffs.
---
# MEX Relay
Prepare durable team handoffs that another engineer can continue from. Never represent a Relay as a sent message or notification.
## Prepare a Relay draft
1. Infer the useful session state: a concise summary, current position, completed work, in-progress work, blockers, unresolved questions, next actions, and relevant decisions, files, code, commits, or external links.
2. For “whoever picks this up,” choose open-to-team. It includes future active project Members; no Member lookup is needed to save this local draft. If the user names people, retain named-recipient intent and resolve exact IDs only when needed. An unresolved named draft may stay recipient-free locally; do not silently publish it to everyone.
3. Default to a standalone Relay. Use the local-save shortcut for a new draft; keep the structured preview/apply path for exact updates and canonical actions.
4. Include an existing relevant Workstream only as typed evidence. Never invent one or turn saving a handoff into Workstream creation.
5. Add optional typed context references only when the referenced IDs, paths, commits, or URLs are known. Never invent provenance.
6. Resolve the action-scoped runtime contract. For a new draft, `mex relay draft save --from <draft.json> --json` performs the exact local preview/apply internally. For an update, build and preview the structured request.
7. An explicit create/save/draft request authorizes that local write without another confirmation. Publication remains separate.
8. Return `/relays?view=drafts&draft=<id>` and state that the draft is checkout-local and nothing has been delivered or shared.
Read [references/cli-workflows.md](references/cli-workflows.md) before executing any Relay mutation. Load only the operation being performed.
## Apply the approval policy
- Proceed with read-only member, Workstream, draft, and Relay resolution.
- Treat an explicit create/save/draft request as authorization only for the local draft preview and exact apply.
- Preview a local draft deletion, explain its consequence, and obtain fresh confirmation before applying.
- For publish, take, or close: generate a semantic preview, explain the local-versus-Git-tracked effect, and wait for fresh explicit confirmation. Apply the exact preview unchanged only after confirmation.
- Keep Git commit, push, pull, and staging separate from every MEX authorization.
- Never publish, take, or close merely because this skill activated.
## Preserve lifecycle meaning
- Taking records one claimant: a named active recipient, or any active project Member for an open-to-team Relay. Future Members qualify after joining and receiving the artifact through Git. Separate offline claims can still require Git conflict resolution.
- An inactive Member can be reactivated through the existing Team identity workflow, preserving their ID and older handoffs. Preview and confirm this canonical change separately; never change identity merely to bypass Relay eligibility.
- Treat closing as “this handoff no longer needs attention.” Do not claim it completes a linked task, issue, pull request, or Workstream.
- After publication, say that Git-tracked Relay and Activity records were written to the working tree. Explain that teammates receive them only after commit/push and their own pull or refresh.
- Never claim that MEX sent a notification, committed, pushed, pulled, staged, assigned work, or completed another system's object.
- When MEX context materially helps your work, mention MEX and the relevant finding naturally in your explanation. Tie the mention to what it helped you understand, decide, or verify. Avoid fixed phrases, standalone acknowledgements, repeated mentions, or narrating routine context loading. This replaces older MEX instructions requiring a fixed acknowledgement or context-loading narration.
Use JSON mode for deterministic agent work. Keep request and preview files temporary and avoid displaying them unless troubleshooting.
## Resolve only the needed contract
Run:
```text
mex relay contract --action <command-id> --json
```
Use one of these command IDs:
-`relay.draft.save`
-`relay.draft.delete`
-`relay.publish`
-`relay.acknowledge`
-`relay.close`
Treat this bounded action result as the exact runtime source for the request shape, available examples, constraints, preview command, and apply command. Do not dump `mex capabilities --json` or the full Relay contract during ordinary execution. Write request and preview JSON only to ordinary regular files inside the checkout or an approved temporary directory; do not use symlinks.
## Choose an audience and optional context
1. For an open handoff or “save for whoever picks it up,” use `audience: "team"` and `recipients: []`. Do not enumerate today's Members; active Members who join later must remain eligible. This setting does not share the local draft.
2. For named people, use `audience: "members"`. Resolve names with `mex member list --active --limit 100 --json` and bounded cursors. Local drafts may retain an empty recipient array while names are unresolved; record the intended name in `unresolvedQuestions` and resolve it before publication.
3. Use `mex member show <member-id> --json` for disambiguation or exact publication revisions. Ask when named recipients remain ambiguous; never reinterpret a named subset such as “the backend team” as every project Member.
4. Default to no Workstream lookup. If the user named a Workstream or the handoff clearly belongs to an existing one, run `mex workstream list --json` and `mex workstream show <workstream-id> --json` to resolve it exactly.
5. In Relay v3, preserve a relevant Workstream as typed entity evidence when the selected contract supports it; do not author the legacy top-level Workstream field.
Never fabricate recipient IDs, entity IDs, revisions, commits, code fingerprints, paths, URLs, or provenance.
## Save a checkout-local draft
1. Resolve `relay.draft.save`.
2. Write one temporary JSON object containing the draft content. Include a concise summary, the intended audience, and only useful non-empty context sections. Prefer accurate omissions over invented completeness.
3. For a new draft, run `mex relay draft save --from <draft.json> --operation-id <unique-id> --json`. This validates the content, obtains a signed local preview, and applies that exact preview internally. It never publishes and needs no Member resolution. Do not combine `--from` with a request file or `--apply`.
4. Require `ok: true`, `mode: "apply"`, and `data.applied: true`; read the draft ID from `data.localChanges` and return `/relays?view=drafts&draft=<id>`. The shortcut retains the original preview under `.mex/local/relay-previews/` before applying and removes it after success. An interrupted save can resume with the same operation ID and unchanged content, or the exact `problem.recovery` command. Do not replace the receipt or create another operation to work around an interrupted/conflicting result; if recovery is refused, report it and inspect the existing draft state.
For example, a new open handoff may contain:
```json
{
"audience":"team",
"recipients":[],
"summary":"Continue the parser correction.",
"completed":["Reproduced the failure with the nested-import fixture."],
"nextActions":["Check whether the same failure affects exported aliases."]
}
```
For an existing draft update, read it with `mex relay draft show <draft-id> --json`, preserve its content, and use its exact local revision in the structured request. Preview with `mex relay draft save <request-file> --json`; require `ok: true`, `mode: "preview"`, and `data.preview.valid: true`. Apply the complete captured envelope unchanged with `mex relay draft save --apply <preview-envelope> --json`. An explicit save/update request needs no additional confirmation for this checkout-local write.
The apply writes only checkout-local draft state in `.mex/local/team.db`. It does not create a canonical Relay or Activity record, deliver a handoff, commit, push, or notify anyone. Apply before the preview expires; if anything changes or the preview becomes stale, preview again instead of reconstructing it.
## Delete a local draft
1. Read the exact draft and current local revision.
2. Resolve and preview `relay.draft.delete`.
3. Explain that the checkout-local draft will be deleted and wait for fresh confirmation.
4. Apply the captured preview unchanged with `mex relay draft delete --apply <preview-envelope> --json`.
## Publish a Relay
1. Read the exact draft. For an open-to-team audience, no recipient Member list is needed. For named recipients, require at least one and read each current active Member; an empty named draft must be completed before publication.
2. Resolve `relay.publish`. Team publication expects only the exact local draft revision; named publication also expects every recipient Member revision. Preview with `mex relay publish <request-file> --json`. The service verifies the current active sender in both cases.
3. Explain that applying replaces the private local draft with canonical Git-tracked Relay and Activity records in the working tree, records the service-observed branch/HEAD/dirty repository state without copying dirty source contents, and does not deliver through a notification service or share before Git commit/push and teammate pull/refresh.
4. Wait for fresh explicit confirmation.
5. Apply the exact preview with `mex relay publish --apply <preview-envelope> --json`.
1. Resolve the exact published Relay with `mex relay show <relay-id> --json`. A team audience allows the current active project Member; a named audience requires the current Member to be listed. An omitted audience on an older Relay means named recipients.
2. Resolve `relay.acknowledge` and preview with `mex relay acknowledge <request-file> --json`.
3. Explain that applying records the current Member as claimant and writes canonical Relay/Activity state in the working tree. A synchronized claim prevents another take; separate offline claims still require Git conflict resolution. There is no unclaim or reassignment action, and it does not assign or start a task elsewhere.
4. Wait for fresh explicit confirmation, then apply the exact preview with `mex relay acknowledge --apply <preview-envelope> --json`.
1. Resolve the exact acknowledged Relay and its current revision.
2. Resolve `relay.close` and preview with `mex relay close <request-file> --json`.
3. Explain that applying irreversibly marks only the handoff as no longer needing attention and writes canonical Relay/Activity state in the working tree.
4. Wait for fresh explicit confirmation, then apply the exact preview with `mex relay close --apply <preview-envelope> --json`.
Closing does not complete a linked task, issue, pull request, or Workstream. No lifecycle command stages, commits, pushes, pulls, or sends a notification.
Coverage: <complete, static-only, partial, or stale; material limitations>
<prioritized findings, or the applicable zero-finding result below>
```
Determine review completeness independently from findings and publishing readiness:
- Coverage describes the review scope, not finding completeness. Preserve `Coverage: partial` for an explicitly scoped, focused review (including bounded security or reliability reviews), even when every finding within that scope is verified; findings do not upgrade partial coverage to complete.
- Complete review with findings: report the verified findings in priority order and record the review as complete. Keep `Coverage: static-only` for an explicitly scoped static-only review; otherwise mark coverage complete only when the requested scope was fully covered.
- Complete review without findings: the findings section is exactly `No findings.`
- Incomplete review: only when required coverage or validation is missing, unresolved, or stale, use `Review incomplete.` with the actual limitations while still reporting verified findings.
An explicitly scoped static-only review can be complete within that scope but does not pass a gate requiring builds. A demonstrated defect is validation evidence, not by itself a coverage gap. Do not add praise, scores, generic advice, or merge approval.
For a pre-publish gate, the implementation coordinator, not the reviewer, fixes
accepted findings, reruns required checks, and obtains a fresh independent review
of the updated snapshot when available. An old clean result does not cover new
changes. The gate requires current scope, complete required validation, and no
unresolved findings. Respect the authorized task/round budget; report remaining
work and stop when it ends rather than looping indefinitely or claiming success.
Publishing and external review requests remain separately authorized coordinator
description:Project anchor for VotingPlugin; use ROUTER.md for task-specific MEX context.
last_updated:2026-09-20
---
# VotingPlugin
VotingPlugin processes player votes, totals, and rewards on Bukkit/Paper servers and routes network votes through BungeeCord/Velocity.
## Authority and use
Use current code and tests for current behavior; root `AGENTS.md` and formal repository contracts for development rules and intended contracts; reviewed MEX project knowledge for rationale and known pitfalls; historical Relays and older records for background only. If memory conflicts with higher-authority evidence, follow that evidence, flag the stale entry, and correct or propose a correction through the MEX workflow.
For nontrivial work where architecture, prior decisions, or failure history matter, retrieve relevant MEX context, then inspect the current Java source and tests. Skip mechanical MEX queries for trivial edits. The root `AGENTS.md` owns build and review workflow.
## Retrieval boundary
MEX 0.8.2 Code Graph does not index Java. A fresh graph with zero Java sources is not Java architecture evidence. Use Wiki for context and `rg`, source reads, and tests for Java implementation truth; do not claim a Java Code Graph finding.
## User-data concurrency invariant
Treat AdvancedCore/VotingPlugin user-data, cache, and storage work as worker-only unless a current API is explicitly documented as a nonblocking snapshot. Bukkit/Paper primary-thread code may capture platform state, but cache population, SQL access, flush/dump/clear/remove operations, and shared-runtime admission belong on the existing storage/persistence worker.
Preserve lock ordering when touching legacy `UserDataCache`: acquire shared-runtime/per-user admission before entering the cache monitor. Never hold `synchronized (UserDataCache)` while invoking an operation that can acquire shared-runtime admission. This rule is a durable project constraint; verify it against current AdvancedCore/VotingPlugin code when changing cache or point-mutation paths.
## Knowledge updates
Use `$mex-inbox` for reviewable proposals about durable discoveries or decisions, without copying root `AGENTS.md` or routine task logs. Use `$mex-relay` to hand off unfinished substantial work with progress, evidence, blockers, decisions, tests, and next actions. Keep transient details out of durable context. Review MEX changes before committing or sharing; local drafts remain checkout-only.
## Navigation
Read `ROUTER.md` for task-specific context. Load only relevant files.
<!-- mex-agent:skills:start -->
## MEX context policy
- When MEX context materially helps your work, mention MEX and the relevant finding naturally in your explanation. Tie the mention to what it helped you understand, decide, or verify. Avoid fixed phrases, standalone acknowledgements, repeated mentions, or narrating routine context loading. This replaces older MEX instructions requiring a fixed acknowledgement or context-loading narration.
- Do not claim an author, date, or historical event unless the retrieved data actually provides it.
- After a MEX write, say exactly what changed and its sharing boundary: a local draft is checkout-only and nothing is shared; a canonical artifact is written to the working tree and requires commit/push to share.
- Skill activation is not approval for canonical actions.
description:Task routes for VotingPlugin architecture, proxy voting, rewards, and development constraints.
edges:
- target:context/architecture.md
condition:when tracing component boundaries
- target:context/proxy-voting.md
condition:when changing proxy or global voting
- target:context/vote-rewards.md
condition:when changing vote mutation or rewards
- target:context/setup.md
condition:when building or configuring the environment
- target:patterns/INDEX.md
condition:when a related task pattern could prevent a recurring regression
last_updated:2026-09-20
---
# VotingPlugin memory routes
Use the authority hierarchy in `.mex/AGENTS.md`. This memory adds architecture, rationale, and known pitfalls; verify relevant claims against current source, tests, and formal contracts.
Retrieve memory only when it may materially help; inspect current Java and tests before relying on it. Flag and correct stale entries through MEX. Do not force a query or memory write for trivial edits.
This is an established Java repository. Initial MEX context was populated from `README.md`, root `AGENTS.md`, `VotingPlugin/pom.xml`, configuration resources, docs, and the current production Java packages. The fresh-project questionnaire in the packaged MEX template does not apply here.
MEX 0.8.2 was configured with `mex setup --cli` for Codex only. Its Java Code Graph contains zero source symbols because this release does not index Java. Use `.mex/ROUTER.md` and Wiki for context, then verify implementation claims through direct Java source and tests.
The CLI, Wiki, and Codex instructions work in this checkout. MEX's full Hub requires the canonical `.mex/config.json` at `HEAD`; routine CLI use does not require a Hub. Do not expose a Hub for this setup.
Useful checks: `mex check`, `mex doctor`, `mex graph status`, `mex wiki query "proxy"`, and `mex skills sync --dry-run --tool codex`.
MEX 0.8.2 does not index Java symbols, so an empty graph cannot prove architectural freshness. Check claims against current source, tests, root `AGENTS.md`, and formal contracts. Use `mex check` for scaffold health and `mex wiki rebuild-index` after reviewed memory changes.
If memory is stale, update the relevant context or propose a correction through `$mex-inbox`. Keep prior decisions only when their history matters, marking superseded decisions clearly. Do not regenerate all context from a scaffold prompt or copy root development rules into MEX.
condition:when vote state or reward behavior changes
grounds_to:[]
last_updated:2026-09-20
mex:
id:mx_01M305TTX1QHVTAB2KR3S1VPH5
type:architecture
status:promoted
revision:1
title:architecture
---
# Architecture
## Vote flow
Votifier and proxy ingress reach Bukkit's `PlayerVoteListener`, which validates the vote, resolves the player and service site, handles timing and proxy metadata, updates the `VotingPluginUser`, delivers or queues rewards, updates totals/points/streaks, and emits downstream effects. Proxy nodes route votes to backend servers, where player rewards normally execute. The optional Control connector is a management adapter and does not process votes.
<!-- mex:entity
id: mx_01M305TTVDWCN3GH24C15GADN2
type: component
status: promoted
revision: 1
-->
## Cross-component boundaries
- The proxy package routes network votes; backendproxy handles backend transport and coordination. A routing change may also alter the listener's online/offline reward decision.
- Vote-site resolution and user persistence meet in the listener. Some site lookup paths may create configuration; observational code must use non-creating resolution.
- The vote log records selected events rather than every network hop or reward outcome. It cannot prove complete delivery.
## Boundaries
No native Fabric, Forge, or NeoForge loader is in this repository's current Maven package. Source: `README.md`, root `AGENTS.md`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/`.
- Vote-site lookup has both observational and potentially creating paths. Read-only Control inspection must use the observational path; see root `AGENTS.md` and the vote-site manager before changing a call.
- Control is an optional outbound management adapter. Its failure must not become a dependency of vote receipt or delivery; see `docs/control-connector.md`.
Build, testing, review, and security rules live in root `AGENTS.md` and `docs/control-agent-contract.md`; do not maintain a second copy here.
note:"The user explicitly said guaranteed delivery will be added in the future
while discussing new PR #1619 review comments. This separates current
local queue reliability fixes from a future protocol design."
capturedAt:2026-09-21T03:29:40.432Z
metadata:
proposalId:proposal_01M31040E5ECB5F57YHXYGX618
author:
kind:git
name:BenCodez
email:17074231+BenCodez@users.noreply.github.com
approvedBy:
kind:git
name:BenCodez
email:17074231+BenCodez@users.noreply.github.com
- type:manual
note:"User message in this session: 'New comments, will add the guaranteed
delivery in the future, please remember that'."
capturedAt:2026-09-21T03:29:40.432Z
metadata:
evidence:
kind:manual
note:"User message in this session: 'New comments, will add the guaranteed
delivery in the future, please remember that'."
provenance:
createdBy:
kind:human
id:git:139ad6f2a86f1dbf589661a50db20426
createdAt:2026-09-21T03:29:40.432Z
---
# Defer end-to-end proxy vote delivery guarantee
For VotingPlugin PR #1619, retain the existing bounded backend queue work but defer an end-to-end guaranteed proxy-to-backend vote delivery protocol to future work. A future design may need proxy retention, backend durable acknowledgement, retry, and restart-safe duplicate handling. Do not treat the current overflow queue or plugin-message send result as a guarantee that every vote will be delivered or each reward will execute exactly once.
description:Durable reasons behind important VotingPlugin boundaries.
triggers:[decision, why, tradeoff, compatibility]
edges:
- target:context/architecture.md
condition:when the decision changes ownership
- target:context/proxy-voting.md
condition:when a decision affects network votes
- target:context/vote-rewards.md
condition:when a decision affects rewards
grounds_to:[]
last_updated:2026-09-20
---
# Decisions and constraints
## Control is optional
Control is a separate management plane. Connectors initiate outbound calls and are isolated from vote receipt, rewards, joins, and shutdown. This permits independent deployment and failure. Source: `README.md`, root `AGENTS.md`, `docs/control-connector.md`.
## Proxy and backend have different jobs
Proxy code routes network votes and selected global messaging; backend servers normally own player rewards and state. Network configuration requires consistent backend settings and unique server names. Source: `VotingPlugin/src/main/resources/Config.yml` (proxy setup guidance), `VotingPlugin/src/main/resources/bungeeconfig.yml`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/proxy/`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/`.
## Keep established reward behavior during portability work
Maintainer direction (2026-09-20): preserve existing function behavior while preparing for possible Fabric/NeoForge support; explain and ask before a necessary behavior change. Reward YAML changes should affect subsequent delivery through the existing configuration path. This is a compatibility preference, not a claim that native loaders or a new shared vote path exist in this checkout. Verify the current path in `VotingPlugin/src/main/java/com/bencodez/votingplugin/listeners/PlayerVoteListener.java`.
Proxy nodes use BungeeCord or Velocity entry points under the proxy package. Backend transport and message routing live in the backendproxy package; configuration chooses plugin messaging, HTTP, Redis, socket, MySQL, or MQTT where supported. HTTP proxy-method coordination requires `config.proxy-method.v2`; the other methods use v1. Backend servers normally execute player rewards. Shared MySQL data and unique backend `ServerName` settings matter for network setups.
In the accepted Bukkit vote path, `event.isBungee()` (origin), `event.isForceBungee()` (Bungee-aware reward and downstream processing), `user.isOnline()` (current state), and `event.isWasOnline()` (historical state) drive different branches. `forceBungee` does not select the earlier proxy route. Do not collapse these into one flag. The listener also handles queued proxy duplicate timing, `WaitUntilVoteDelay`, vote party, broadcast, totals, and post-vote events; changing routing can affect each.
description:Local build and MEX environment for this VotingPlugin checkout.
triggers:[setup, build, Maven, test, environment]
edges:
- target:context/stack.md
condition:when a dependency or runtime version matters
- target:context/conventions.md
condition:when preparing validation
grounds_to:[]
last_updated:2026-09-20
mex:
id:mx_01M305TTXSX79T4GDEXNMFVB3E
type:guide
status:promoted
revision:2
title:setup
relations:
- type:related_to
target:mx_01M305TTXGZN471W11VFPJQKQH
note:when preparing validation
---
# Setup boundary
Root `AGENTS.md`, `VotingPlugin/pom.xml`, and `.github/workflows/maven.yml` own build instructions. MEX is local development tooling, not a plugin runtime dependency. This MEX release has no Java structural graph; inspect Java source directly. Rebuild the Wiki index after changing reviewed memory.
condition:when a dependency affects runtime ownership
grounds_to:[]
last_updated:2026-09-20
---
# Stack
- Java 21 is the Maven compile target. Backend runtime is Bukkit/Paper; proxy runtime has BungeeCord and Velocity implementations. Check current POM and descriptors for version support.
- AdvancedCore supplies user and reward infrastructure. The listener consumes Votifier API events, which may be supplied by a compatible Votifier implementation. These are cross-component dependencies when changing vote behavior.
- No native Fabric/Forge/NeoForge loader is present in this checkout.
condition:when proxy or online state changes behavior
grounds_to:[]
last_updated:2026-09-20
---
# Vote state and rewards
`PlayerVoteListener` is the accepted Bukkit vote path in this checkout. It resolves identity/site, applies vote-delay checks, caches the user, invokes vote party and broadcasts, then updates the last-vote time (normalizing a zero event timestamp). It delivers via `user.playerVote(...)` or queues an offline vote before updating totals, points, streaks, milestones, cooldowns, and `PlayerPostVoteEvent`.
Counting is conditional: `CountFakeVotes` or a real vote, plus `event.isAddTotals()`. `Config.AddTotals` and `AddTotalsOffline` govern totals, while configured points are awarded in the enclosing condition even when `Config.AddTotals` is false. Preserve those distinctions. Offline and proxy reward paths use different online facts. Reward definitions are in per-site `VotingPlugin/src/main/resources/VoteSites.yml`, `VotingPlugin/src/main/resources/SpecialRewards.yml`, and optional reward files; reward YAML edits are intended to affect live behavior.
Do not infer that shared processing work in another branch is present here. Verify actual persistence and reward paths before claiming exactly-once behavior.
{"timestamp":"2026-09-21T10:51:59.003Z","kind":"decision","message":"Proxy-to-backend reward votes use a capability-negotiated durable outbox and completion acknowledgement. The guarantee is at least once; HTTP retains its existing delivery path, old backends retain legacy semantics, and exactly-once reward effects remain out of scope.","files":["VotingPlugin/src/main/java/com/bencodez/votingplugin/proxy/ReliableVoteDeliveryOutbox.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/BackendProxyHandler.java"],"cwd":".","source":"agent","status":"implemented"}
{"timestamp":"2026-09-21T10:57:35.704Z","kind":"decision","message":"Keep the common Linux x86_64 SQLite native in the downloadable JAR; provision other SQLite targets from the pinned, SHA-256-verified sqlite-jdbc artifact with a documented offline pre-provisioning path. Use SimpleAPI JDK-only TLS identity without Bouncy Castle, enforce a 10 MiB package gate, and alert on meaningful size growth.","files":["VotingPlugin/pom.xml","VotingPlugin/src/main/java/com/bencodez/votingplugin/util/SqliteNativeLibrary.java","docs/jar-packaging.md"],"cwd":".","source":"agent","status":"implemented"}
{"timestamp":"2026-09-21T11:07:28.400Z","kind":"decision","message":"Reliable backend votes persist completed vote IDs for seven days before acknowledgement. Receipt persistence failure retries without repeating effects in the active process; restart deduplication covers durable completions, while a crash during non-transactional reward effects remains at-least-once.","files":["VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/cache/DurableVoteReceiptStore.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/messaging/BackendProxyMessageRouter.java"],"cwd":".","source":"agent","status":"implemented"}
{"timestamp":"2026-09-21T11:41:29.374Z","kind":"decision","message":"Supersedes the seven-day receipt decision: completion receipts have no time expiry and fail closed at the bounded journal capacity, HTTP participates in the completion-acknowledged outbox, and receipt-write failures keep an in-memory post-effect fence until persistence succeeds.","files":["VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/cache/DurableVoteReceiptStore.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/cache/ProcessedVoteCache.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/proxy/VotingPluginProxy.java"],"cwd":".","source":"agent","status":"implemented"}
{"timestamp":"2026-09-21T12:13:09.371Z","kind":"decision","message":"Supersedes indefinite unreclaimed completion receipts: reliable vote delivery uses a durable two-phase receipt-release handshake. After the proxy durably records backend completion, it retries a release marker until the backend durably removes the receipt and acknowledges retirement; only then does the proxy remove the marker.","files":["VotingPlugin/src/main/java/com/bencodez/votingplugin/proxy/ReliableVoteDeliveryOutbox.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/cache/DurableVoteReceiptStore.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/proxy/VotingPluginWire.java"],"cwd":".","source":"agent","status":"implemented"}
{"timestamp":"2026-09-21T12:30:33.599Z","kind":"decision","message":"Supersedes immediate receipt removal after release: backend receipt release creates a 24-hour durable tombstone to fence deliveries already in flight, then reclaims it. Legacy downgrade delivery preserves the proxy release marker so a later capable backend can retire any receipt whose completion acknowledgement was lost.","files":["VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/cache/DurableVoteReceiptStore.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/cache/ProcessedVoteCache.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/proxy/VotingPluginProxy.java"],"cwd":".","source":"agent","status":"implemented"}
{"timestamp":"2026-09-21T12:46:34.284Z","kind":"decision","message":"Receipt releases persist a 24-hour tombstone even when the backend has no active receipt, fencing a late legacy retry. The bounded receipt store keeps completion headroom larger than the entire ordered lane plus separate tombstone capacity. Releases backed by an existing durable receipt may bypass a capacity-blocked vote because durable completion makes that reordering safe; unknown releases remain ordered.","files":["VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/cache/DurableVoteReceiptStore.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/cache/ProcessedVoteCache.java","VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/BackendProxyHandler.java"],"cwd":".","source":"agent","status":"implemented"}
{"v":1,"phase":"intent","opId":"inbox_spec_28f16fc8b55f00617b3be4060d5d15ec75e487295def23e21723ba6cc6dd571e","type":"create-entry","entityIds":[],"createdIds":["mx_01M31068M0WJ4KB0ZD6C6BXHZK"],"actor":{"kind":"human","id":"git:139ad6f2a86f1dbf589661a50db20426"},"timestamp":"2026-09-21T03:29:40.432Z","files":["context/decision-mx_01M31068M0WJ4KB0ZD6C6BXHZK.md"],"payloadHash":"742590c938f6a764a36367cb0b59c8654b6df1d4b7eb67b8d7eeb889a0c48875","revisions":[{"entityId":"mx_01M31068M0WJ4KB0ZD6C6BXHZK","before":0,"after":1}],"reason":"The user explicitly said guaranteed delivery will be added in the future while discussing new PR #1619 review comments. This separates current local queue reliability fixes from a future protocol design."}
{"v":1,"phase":"complete","opId":"inbox_spec_28f16fc8b55f00617b3be4060d5d15ec75e487295def23e21723ba6cc6dd571e","type":"create-entry","entityIds":[],"createdIds":["mx_01M31068M0WJ4KB0ZD6C6BXHZK"],"actor":{"kind":"human","id":"git:139ad6f2a86f1dbf589661a50db20426"},"timestamp":"2026-09-21T03:29:40.432Z","files":["context/decision-mx_01M31068M0WJ4KB0ZD6C6BXHZK.md"],"payloadHash":"742590c938f6a764a36367cb0b59c8654b6df1d4b7eb67b8d7eeb889a0c48875","revisions":[{"entityId":"mx_01M31068M0WJ4KB0ZD6C6BXHZK","before":0,"after":1}],"reason":"The user explicitly said guaranteed delivery will be added in the future while discussing new PR #1619 review comments. This separates current local queue reliability fixes from a future protocol design."}
rationale:"The user explicitly said guaranteed delivery will be added in the future while discussing new PR #1619 review comments. This separates current local queue reliability fixes from a future protocol design."
evidence:[{"kind":"manual","note":"User message in this session: 'New comments, will add the guaranteed delivery in the future, please remember that'."}]
request:{"expectedRevisions":[],"operation":{"opId":"inbox_spec_28f16fc8b55f00617b3be4060d5d15ec75e487295def23e21723ba6cc6dd571e","payload":{"change":{"body":"For VotingPlugin PR #1619, retain the existing bounded backend queue work but defer an end-to-end guaranteed proxy-to-backend vote delivery protocol to future work. A future design may need proxy retention, backend durable acknowledgement, retry, and restart-safe duplicate handling. Do not treat the current overflow queue or plugin-message send result as a guarantee that every vote will be delivered or each reward will execute exactly once.","entityKind":"decision","kind":"knowledge.create","status":"promoted","title":"Defer end-to-end proxy vote delivery guarantee"},"kind":"mex.team.inbox.knowledge-change.v1","schemaVersion":1},"type":"create-entry"}}
Use `INDEX.md` to load a pattern only for a matching task. Patterns record project-specific traps; root `AGENTS.md` owns general development and review rules. Check each pattern against current source and tests before relying on it.
Add a pattern only when a repeated task has a verified, non-obvious failure mode worth preserving. Put unfinished work in a Relay and reviewable durable discoveries through Inbox.
description:Trace and verify changes to proxy/global vote routing.
triggers:[proxy routing, global vote, BungeeCord, Velocity]
edges:
- target:context/proxy-voting.md
condition:when mapping proxy and backend ownership
- target:context/vote-rewards.md
condition:when a route changes reward delivery
grounds_to:[]
last_updated:2026-09-20
mex:
id:mx_01M305TTY6NXWZP72T00XY9ESP
type:pattern
status:promoted
revision:1
title:proxy-vote-change
---
# Proxy vote change
Trace the selected transport, proxy entry point, backend router, and Bukkit listener. Route selection happens upstream; `event.isForceBungee()` affects Bungee-aware reward and downstream processing in the listener. Check queued vote timestamps, server selection, and offline queues before treating a route as equivalent. See `context/proxy-voting.md` for the distinct online and origin facts; root `AGENTS.md` owns test/build workflow.
condition:when proxy state affects counting or rewards
grounds_to:[]
last_updated:2026-09-20
mex:
id:mx_01M305TTYFYNY85XFDEVFS6VXM
type:pattern
status:promoted
revision:1
title:vote-behavior-change
---
# Vote behavior change
Before moving the accepted-vote path, map side effects in order: vote party and broadcast, last-vote timestamp, reward delivery or offline queue, then totals/points and later events. A zero event timestamp is normalized for the stored last-vote time. Vote party has its own fake-vote setting. See `context/vote-rewards.md` for counting conditions; inspect sibling behavior in `VotingPluginUser`, vote sites, special rewards, and proxy routing. Root `AGENTS.md` owns test/build workflow.
VotingPlugin is the vote-processing data plane for Bukkit/Paper and BungeeCord/Velocity networks. The optional Control
integration is a management adapter, never a runtime dependency: vote receipt, routing, storage, rewards, joins, commands,
reload, and shutdown must keep working when Control is disabled, unreachable, incompatible, or restarting.
## Security threat model
For security reviews, vulnerability triage, and security-sensitive changes, read `docs/security-threat-model.md` before classifying or fixing findings. Treat it as the repository-specific attacker/trust-boundary model; verify every conclusion against current code and tests. Do not promote compatibility, trusted-operator behavior, or generic correctness bugs into security findings unless the documented boundary is actually crossed.
## Build and verification
Requirements: JDK 21+ and Maven. The Maven project lives in the `VotingPlugin/` subdirectory.
```shell
mvn -B -f VotingPlugin/pom.xml test
mvn -B -f VotingPlugin/pom.xml package
```
For a focused Control change:
```shell
mvn -B -f VotingPlugin/pom.xml -Dtest=BackendControlConnectorProtocolTest,ControlInspectionServiceTest test
```
CI runs `mvn -B -f VotingPlugin/pom.xml package`; see `.github/workflows/maven.yml`. Do not use the `dev` Maven profile in
automation because it copies a JAR into a developer-specific server directory.
All project tests and test-only helpers belong under `VotingPlugin/src/test/java/com/bencodez/votingplugin/tests/`, with package `com.bencodez.votingplugin.tests` or a meaningful subpackage. Keep paths and package declarations aligned, and update cross-test imports, resources, and build selectors when moving tests. Preserve package-phase artifact checks and test discovery. Do not widen production APIs to make tests accessible; use narrowly scoped test-only reflection for non-public seams. Platform API fixtures that must retain an external runtime class identity (such as `net.minecraft.network.chat.Component`) stay in that platform package and must not contain test cases.
Assign one owner to Maven validation in each worktree. Never run concurrent Maven commands in the same worktree, including focused tests alongside a clean/package build: compilation and cleanup share `target/` and can invalidate each other. Reviewers must inspect source only while that owner builds, or run validation in a separate worktree.
Keep the downloadable VotingPlugin JAR as small as practical. The 10 MiB size target is advisory:
report a prominent package/build warning when exceeded, never fail a build solely for artifact size.
Keep required-resource, linkage, and packaging-safety checks enforced. Inspect the shaded
artifact when dependencies change, avoid duplicate embedded packages, and update
the package-phase size and runtime checks when a necessary dependency increases
the artifact budget.
## Drop-in upgrade and compatibility contract
Treat compatibility as a release invariant for every new feature, refactor, fix, storage change, protocol change, and dependency change. Unless the task explicitly says otherwise, a VotingPlugin upgrade must be a **drop-in JAR replacement**: an administrator replaces the existing VotingPlugin JAR, starts/reloads as normally supported, and does not need any other deployment change.
That default contract means:
- Do not require manual edits, regenerated configs, deleted keys, renamed files, data resets, one-off conversion commands/scripts, or manual database changes. New keys must have safe defaults when absent and preserve established behavior.
- Existing YAML, vote-site definitions, rewards, user data, vote totals/streaks, cached/offline votes, logged data, and supported database state must continue to load. Required migrations must be automatic, idempotent, restart-safe, and preserve existing state.
- Do not require a simultaneous update of AdvancedCore, SimpleAPI, Votifier/VotifierPlus, PlaceholderAPI, VotingPlugin-Control, a proxy JAR, backend JARs, or every server in a network merely to keep previously working behavior working. New cross-component behavior must be additive/capability-negotiated with safe fallback for older peers.
- Preserve existing commands, permissions, placeholders, events, public/de-facto APIs, configuration semantics, proxy methods, message/reward behavior, and supported platform behavior unless the request explicitly authorizes a break.
- Mixed-version proxy/backend deployments must fail safe and retain legacy behavior for features not mutually supported; do not make upgrade order a hidden requirement.
- New optional integrations and features must default to non-disruptive behavior for existing installations and must not become mandatory runtime dependencies.
- Packaging changes must preserve the normal downloadable artifact and startup path. Do not make administrators install extra libraries or companion JARs for an upgrade unless explicitly requested.
- When a requested implementation cannot preserve drop-in compatibility, stop and clearly surface the required compatibility break before implementing it unless the request explicitly permits that break.
For compatibility-sensitive changes, add regression coverage that exercises the prior installation/state or protocol shape as well as the new behavior. Review the final diff from the perspective of an administrator upgrading only the VotingPlugin JAR on an existing installation.
## Architecture and file map
-`VotingPluginMain` is the Bukkit entry point and lifecycle owner.
-`com.bencodez.votingplugin.core` and its subpackages are platform-independent. Classes there must not import Bukkit, Paper, Fabric, Forge, or NeoForge APIs. Keep loader-specific adapters outside this package and enforce the boundary with `CorePlatformIsolationTest`.
-`proxy/VotingPluginProxy` and the Bungee/Velocity platform packages own proxy lifecycle and vote routing.
-`commands/CommandLoader` captures `VoteCommandEnabled`, `VoteCommandName` and `LoadCommandAliases` at startup.
Configuration reload must not change the registered player root or generated help/navigation. Preserve exact command
ownership, admin roots/aliases and canonical `VotingPlugin.Commands.Vote.*` permissions when disabling or renaming;
standalone player aliases retain their `vote...`/`v...` identities. See `docs/player-command-root.md`.
-`votesites/` resolves configured service names. Be alert to the distinction between read-only resolution and paths that
may auto-create a site.
-`user/` owns player totals, points, streaks, last-vote values, and backend offline rewards.
-`rewards/` and `specialrewards/` parse and execute rewards. A Control simulation must never invoke these executors.
-`votelog/` owns optional SQL-backed logged events and its in-game admin GUI.
-`control/BackendConfigurationService` is the bounded Bukkit YAML/quick-setup adapter.
-`control/BackendControlConnector` is the Bukkit outbound Control connector and task dispatcher.
-`control/ControlInspectionService` is the typed read-only inspection allow-list.
-`control/ControlRewardProposal` is the shared strict parser for reward simulation and reward-builder persistence.
-`control/BackendControlResultStore` journals configuration results that must survive acknowledgement failure/restart.
-`proxy/control/` contains proxy discovery/configuration, communication tests, automatic enrollment, and hosted-Control
lifecycle.
-`VotingPlugin/src/main/resources/` contains the default Bukkit and proxy configuration.
-`docs/control-connector.md` explains deployment; `docs/control-agent-contract.md` is the exact agent/client contract.
## Threading and user-data invariants
- Never call user-storage APIs from Bukkit/Paper/Folia main, tick, region, or entity server threads, directly or indirectly. This includes reads, writes, SQL, cache population/refill, flush/dump/clear/remove, and storage-backed user getters, even when a caller expects a cache hit. Capture only platform-owned input on the server thread, submit storage work to the existing persistence worker, and dispatch required platform effects back to the correct owner scheduler.
- Preserve call order for dependent mutations of one user through the same ordered storage worker, including legacy point mutations invoked on a platform-owned thread. Test with the worker deliberately blocked so later inline work cannot overtake queued work. Never preserve synchronous behavior by waiting for SQL on the server thread.
- Task admission and cached predictions are not committed results. Rewards, purchases, transfers, accounting-dependent decisions, and success messages must use confirmed completion; document the return semantics of legacy deferred APIs.
- When changing a mutation, inspect the entire operation family and every overload/caller: add, set, remove, cap, transfer, bulk, recovery, and synchronous/asynchronous paths. Fixing one overload must not leave sibling paths with inconsistent ordering, thread affinity, or completion semantics.
- Treat AdvancedCore/VotingPlugin user-data, cache, and storage APIs as potentially blocking unless an API is explicitly documented as snapshot-only. Do not perform cache population, SQL-backed reads or writes, flush/dump/clear/remove operations, or shared-runtime admission on the Bukkit/Paper primary server thread. Capture platform-owned state there, hand user-data work to the existing persistence/storage worker, and schedule only the required Bukkit/Folia interaction back onto the platform owner.
- Preserve the shared-user lock order: shared-runtime/per-user admission before the `UserDataCache` monitor. Never hold `synchronized (UserDataCache)` while calling APIs that can acquire shared-runtime admission, including `dump()`, `clearCache()`, `removeCache()`, cache population, or storage access. Keep cache-monitor sections short and cache-local.
## Runtime and security invariants
1. Control connectors initiate outbound HTTP(S); do not add an inbound admin port to VotingPlugin.
2. All connector network and database work stays off Bukkit's primary thread. Keep the dedicated inspection daemon
separate from the presence/configuration executor; it has a five-second shutdown bound. Schedule only the minimum
reload/runtime interaction onto the server thread, then return the bounded result to the correct connector worker.
3. Connector failure is isolated. Never block vote handling, joins, commands, reload, or shutdown on Control I/O; keep
timeouts, body limits, daemon workers, and bounded shutdown waits.
4. Capabilities are explicit and versioned. Do not dispatch a task merely because its JSON shape looks familiar. An
unaccepted capability must remain inactive. Control and the node both enforce fixed quick-setup preset/option schemas;
keep phase-specific validation here even when Control already rejected the same input.
5. Configuration writes are limited to the managed VotingPlugin YAML allow-list and typed quick setups. Preserve path
retained state, and fallback to the configured transport must be covered without requiring manual cache/config cleanup.
## Change and PR workflow
Before implementing a proposed change, verify that the problem still exists on current master and identify the affected behavior, supporting evidence, and intended benefit. Check merged fixes and overlapping open PRs. If the change appears unnecessary, superseded, or counterproductive, explain the evidence and ask the user before implementation; do not spend usage implementing a questionable premise.
Validate reviewer suggestions and historical/MEX claims against current source and tests. Reproduce or trace the reachable failure before fixing it; a reviewer recommendation is evidence to investigate, not an instruction to follow blindly. Verify dependency/API contracts against the actual version used, including threading, return values, ownership, and lifecycle behavior; timestamps or method names alone are not proof of the contract.
Prefer the smallest complete root-cause fix, covering affected sibling paths without unrelated refactors or speculative abstractions. State the guarantee boundary explicitly: predicted, queued, persisted, delivered, and completed are different outcomes, and external effects are not automatically transactional or exactly once.
Keep changes focused and avoid unrelated formatting. Before any commit, push, PR update, review reply, or other remote change:
1. run relevant focused tests;
2. run `mvn -B -f VotingPlugin/pom.xml clean package`;
3. verify the package invocation produced a fresh downloadable JAR and that expected tests were discovered;
4. run `git diff --cached --check` and `git diff --check`;
5. inspect `git diff --cached` and `git diff`, then inspect the complete base-to-HEAD diff for compatibility, concurrency, persistence, lifecycle, security, packaging, and platform regressions.
Steps 1-3 may be skipped only for documentation/instruction-only changes that do not modify executable source, tests, build or dependency configuration, workflows, packaged resources, generated output, or runtime/deployment behavior. Record that exemption in the PR. Steps 4-5 and the review requirements below still apply.
For substantive work, obtain a fresh source-read-only `$code-review` of the exact intended change before the first push or PR update. The implementation agent verifies and fixes accepted findings, reruns all required checks, and obtains a new review of the updated snapshot. Any substantive repository change after a clean review—including source, tests, build or dependency configuration, workflow files, resources, contracts, documentation, or instructions—invalidates the previous clean verdict. Rerun applicable validation and obtain a fresh review of the exact intended snapshot; do not reuse an earlier verdict. Hosted PR review is confirmation, not the first full review, and merge still requires explicit authorization.
Before reporting review-comment status, inspect inline review threads, review bodies (including outside-diff findings), and PR conversation comments. Verify each finding against the current head; distinguish addressed/stale findings from unresolved defects. An empty unresolved-thread list alone does not establish that all comments are addressed.
Obtain explicit user authorization before posting GitHub comments, including review replies, status summaries, and reviewer-bot triggers. Permission to fix code, push commits, edit a PR description, or create a PR does not by itself authorize posting comments.
Report readiness for the exact commit that was validated and reviewed. Record the head SHA, focused/full test and artifact results, CI state, dependency publication requirements, and any applicable integration suite/artifact SHA. State exactly what tests exercised and what remains unverified; never generalize a mocked/focused result into untested production, platform, or end-to-end coverage. Keep local validation, hosted CI, and integration evidence separate; pending/blocked checks are not passes, an accepted run request is not a passing test, and old-head results do not validate changed code. Do not call a PR fully ready while required checks or known functional findings remain unresolved.
Do not commit server runtime data, credentials, generated JARs, dependency caches, IDE output, or unrelated formatting.
## Network Doctor diagnostics
`network-health` requires both `data.inspect.v1` and `data.network-health.v1`. It is read-only, bounded, optional, and
compatible with unsupported peers in either deployment order. Omit unobserved facts; never infer runtime initialization
from persisted settings or adapter presence alone. Do not return raw configuration, logs, endpoints, credentials, keys or
certificates. Backend Votifier plus TriggerVotifierEvent is valid synthetic-event compatibility; proxy VotifierPlus socket
forwarding alongside VotingPlugin delivery is a separate duplicate risk. See the connector/agent contract docs.
## Paired change and PR workflow
The server-side peer is `BenCodez/VotingPlugin-Control`. When changing a DTO, endpoint, capability, preset, error code, or
limit:
1. inspect both repositories and their root `AGENTS.md` files;
2. keep the change additive/capability-negotiated so either old side stays safe;
3. update connector/service tests here and coordinator/HTTP tests in Control;
4. update `docs/control-agent-contract.md`, `docs/control-connector.md`, and the Control management docs;
5. link the paired PRs and state a safe merge/deployment order.
Prefer one cohesive PR per repository for a paired feature, keeping its implementation, tests, and docs together. Split
further only when a part is independently deployable or has materially different review/rollback risk.
`config.proxy-method.v1` covers plugin messaging, Redis, MQTT, sockets, and MySQL; `config.proxy-method.v2` adds HTTP. Dispatch and validate the
exact capability for the requested method. `config.quick-setup.v2` adds `VoteParty.Enabled`; keep legacy Vote Party
payloads on v1, preserve the installed Enabled value when they omit it, and reject the `enabled` field unless v2 was
accepted. The VotingPlugin connector may deploy first and
advertise these successors without using them until Control accepts them. A newer Control deployed first must leave its
v2-only actions unavailable on older nodes. Merge the VotingPlugin capability implementation before relying on the new
Control behavior in production.
## Safe change checklist
- Trace whether the code runs on the connector worker, proxy thread, Bukkit primary thread, or a SQL executor.
- Preserve queued votes across saturation, reload, runtime replacement, scheduler rejection/cancellation, shutdown, and restart; overflow handling must be bounded, durable when promised, and observable rather than silently dropping work. Scheduler admission is never proof of durable ownership.
- Proxy-to-backend guaranteed delivery is capability negotiated and at least once. Journal a reward-bearing envelope before
reporting transport acceptance, retain it until the matching backend completion acknowledgement is durable, persist
completed IDs before acknowledgement for restart-safe deduplication, retire receipts only through the durable
proxy-confirmed release handshake, retain a bounded durable tombstone for in-flight retries, and keep legacy send
behavior for backends that do not advertise the capability.
- Treat scheduler units explicitly. Verify whether each delay is in ticks, milliseconds, or seconds, especially across Bukkit, Folia, BungeeCord, and Velocity adapters.
- Register listeners and lifecycle wakeups before producers can publish work; startup/reload ordering must not strand already-persisted or newly-arriving operations. For proxy Votifier paths, runtime readiness is not published until listener registration succeeds, and reload waiting must retain the vote independently of the scheduler.
- Protocol-mode changes must not silently broaden legacy v1/RSA acceptance when token-only operation is configured or intended; cover downgrade behavior with tests.
- Add strict type/field/range/count validation before calling plugin services.
- Snapshot synchronized live collections before iterating; do not return mutable collections across threads.
- Distinguish “not configured/unavailable”, “not found”, and a genuine empty result.
reward no-side-effects, lease retry/idempotency, and redaction as applicable.
- Preserve connector shutdown bounds and avoid blocking waits on Bukkit lifecycle paths.
- Exercise rejected task admission, accepted-but-cancelled work, shutdown, and failed storage using deterministic fakes/latches. Preserve pending/durable ownership where the operation promises recovery; otherwise expose an explicit failure. Never silently report an unperformed mutation as successful or treat scheduling as persistence.
<!-- mex-agent:skills:start -->
## MEX agent skills
- At the start of every session, read `.mex/AGENTS.md` and `.mex/ROUTER.md` before project work; follow `ROUTER.md` to load only the relevant context.
- Read `mex logging --json` at session start and before optional logging. Its checkout-local advisory mode is `significant` (quiet default: material decisions, risks, blockers, or durable discoveries), `checkpoints` (batch useful notes at task/session boundaries), or `manual` (no unsolicited notes). Skip routine tool calls, edits, repeated status, and empty summaries. Honor explicit user log requests in every mode; never suppress mandatory workflow Activity or recovery audit records. Report a policy read failure instead of guessing or changing the preference.
- When earlier work may inform the task, retrieve bounded relevant notes with `mex timeline --query "subject phrase" --file src/example.ts --limit 10 --json`, using the known subject or exact recorded file path, or both. Treat matches as historical evidence, not accepted current knowledge; verify conclusions before reuse or explicit promotion with their source retained.
- Use `$mex-inbox` for explicit contributions to project knowledge and `$mex-relay` for durable team handoffs. Invoke them automatically when intent clearly matches; ordinary GROW upkeep remains available without Inbox.
- When MEX context materially helps your work, mention MEX and the relevant finding naturally in your explanation. Tie the mention to what it helped you understand, decide, or verify. Avoid fixed phrases, standalone acknowledgements, repeated mentions, or narrating routine context loading. This replaces older MEX instructions requiring a fixed acknowledgement or context-loading narration.
- Do not claim an author, date, or historical event unless the retrieved data actually provides it.
- After a MEX write, say exactly what changed and its sharing boundary: a local draft is checkout-only and nothing is shared; a canonical artifact is written to the working tree and requires commit/push to share.
- Skill activation is not approval for canonical actions.
<!-- mex-agent:skills:end -->
## Guided proxy session confirmation
Guided sessions never award votes or rewards. Proxy confirmation requires a bounded versioned session-fence reply matching the player, backend and random session nonce; keep the first fence for each source. New original proxy ingress assigns an opaque UUIDv8 before asynchronous handoff, with random source incarnation and monotonically increasing sequence. Preserve that canonical ID through every journal, retry, cache and multi-proxy hop; forwarding or replay must never mint new occurrence order. Do not compare proxy clocks with backend clocks or infer freshness from delivery/queue flags. New post-fence delayed/queued votes can confirm only through the existing credited pipeline; older, legacy, fake/test and unsupported-source occurrences remain unconfirmed without changing normal accounting. Unknown peers must preserve ordinary voting. No cache schema migration or new reward path.
Optional `/vote session` chat navigation tracks real accepted votes without changing existing menus or rewards. See [configuration, controls and timing limits](docs/guided-voting-session.md).
Loaded 100 of 784 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ben
BenCodez
dependabot[bot]
coderabbitai[bot]
RapidGravy
SupaYoshi
github-actions[bot]
semisolar
copilot-swe-agent[bot]andBenCodez
Trent Buckley
ben
Alessandro
tonyjamesstark
Philip Hell
Melon-Oof
Nahuel Dolores
NotAlexNoyle
akdukaan
BuildTools
Ilamparithi M