mirror of
https://github.com/BenCodez/VotingPlugin.git
synced 2026-11-12 20:22:04 -05:00
Compare commits
2
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 BenCodez
|
add80a7425 | ||
|
BenCodez
|
114c69c4ff |
No files matched your search
@@ -1,11 +0,0 @@
|
||||
{
|
||||
"schemaVersion": 1,
|
||||
"owner": "mex-agent",
|
||||
"skill": "mex-inbox",
|
||||
"packageVersion": "0.8.2",
|
||||
"files": {
|
||||
"SKILL.md": "39cf595ac48203bf49ea2e273ea1c1c25e7ebbf4616c68596cd8e1c08eaf2738",
|
||||
"agents/openai.yaml": "12a2827fe257c303d926122e4bb590910abd660e6451550a1db68a48037b4402",
|
||||
"references/cli-workflows.md": "6c91905cc69d8ea47080630ee1551bf1a61ec33605fff01463d4a2ad71f497c6"
|
||||
}
|
||||
}
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
name: mex-inbox
|
||||
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.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "MEX Inbox"
|
||||
short_description: "Propose additions to project knowledge"
|
||||
default_prompt: "Use $mex-inbox to capture what we decided as a contribution to this project's knowledge."
|
||||
@@ -1,86 +0,0 @@
|
||||
# Inbox CLI workflows
|
||||
|
||||
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`.
|
||||
6. Return `/inbox?view=review&proposal=<proposal-id>`.
|
||||
|
||||
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.
|
||||
@@ -1,11 +0,0 @@
|
||||
{
|
||||
"schemaVersion": 1,
|
||||
"owner": "mex-agent",
|
||||
"skill": "mex-relay",
|
||||
"packageVersion": "0.8.2",
|
||||
"files": {
|
||||
"SKILL.md": "186d1d19c4b513f4b98ee27bf0259744d1ef79ffc758676484596cfe498aa502",
|
||||
"agents/openai.yaml": "9c2e9c2e34d60ec0f4d07089b07d9e49a6c8210c2a3e277593c15a2635f03076",
|
||||
"references/cli-workflows.md": "56b6e74129cdc6ddb5121480b03e01fd2f1f65b7b8c0b7899552a4a217d48cf5"
|
||||
}
|
||||
}
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
name: mex-relay
|
||||
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.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "MEX Relay"
|
||||
short_description: "Prepare durable MEX team handoffs"
|
||||
default_prompt: "Use $mex-relay to prepare a durable handoff for the next engineer."
|
||||
@@ -1,88 +0,0 @@
|
||||
# Relay CLI workflows
|
||||
|
||||
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`.
|
||||
6. Return `/relays?view=sent&state=open&relay=<relay-id>`.
|
||||
|
||||
## Take a Relay
|
||||
|
||||
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`.
|
||||
5. Return `/relays?view=mine&state=open&relay=<relay-id>`.
|
||||
|
||||
## Close a Relay
|
||||
|
||||
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`.
|
||||
5. Return `/relays?view=all&state=closed&relay=<relay-id>`.
|
||||
|
||||
Closing does not complete a linked task, issue, pull request, or Workstream. No lifecycle command stages, commits, pushes, pulls, or sends a notification.
|
||||
@@ -1,3 +0,0 @@
|
||||
graph.db*
|
||||
wiki.db*
|
||||
local/
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
name: agents
|
||||
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.
|
||||
<!-- mex-agent:skills:end -->
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
name: router
|
||||
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.
|
||||
|
||||
## Current state
|
||||
|
||||
- Working: Bukkit/Paper vote handling, BungeeCord/Velocity proxy routing, configurable vote sites/rewards, optional outbound Control integration. Sources: `VotingPlugin/src/main/java/com/bencodez/votingplugin/`, `README.md`.
|
||||
- Graph limitation: MEX 0.8.2 indexes no Java symbols. Use Wiki search and direct Java source inspection.
|
||||
|
||||
## Route only when relevant
|
||||
|
||||
| Task | Context |
|
||||
| --- | --- |
|
||||
| Architecture or package ownership | `context/architecture.md` |
|
||||
| Proxy/global vote handling | `context/proxy-voting.md`, then [proxy vote pattern](patterns/proxy-vote-change.md) |
|
||||
| Proxy delivery guarantees | `context/decision-mx_01M31068M0WJ4KB0ZD6C6BXHZK.md` |
|
||||
| Vote mutation, totals, or rewards | `context/vote-rewards.md`, then [vote behavior pattern](patterns/vote-behavior-change.md) |
|
||||
| Libraries and supported platforms | `context/stack.md` |
|
||||
| Build/environment | `context/setup.md` |
|
||||
| Why an unusual boundary exists | `context/decisions.md` |
|
||||
| Unusual implementation convention | `context/conventions.md` |
|
||||
|
||||
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.
|
||||
@@ -1,9 +0,0 @@
|
||||
# MEX setup for this VotingPlugin checkout
|
||||
|
||||
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`.
|
||||
@@ -1,5 +0,0 @@
|
||||
# Keeping VotingPlugin memory current
|
||||
|
||||
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.
|
||||
@@ -1,10 +0,0 @@
|
||||
{
|
||||
"setupMode": "code-repo",
|
||||
"aiTools": [
|
||||
"codex"
|
||||
],
|
||||
"scaffold_id": "054c39c7-d95c-449e-bdad-6ff84f6d3ebd",
|
||||
"scaffold_name": "VotingPlugin",
|
||||
"origin": null,
|
||||
"upstream": null
|
||||
}
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
name: architecture
|
||||
description: VotingPlugin's runtime boundaries and vote flow.
|
||||
triggers: [architecture, vote flow, module boundaries]
|
||||
edges:
|
||||
- target: context/proxy-voting.md
|
||||
condition: when a vote crosses proxy and backend
|
||||
- target: context/vote-rewards.md
|
||||
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/`.
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
name: conventions
|
||||
description: Established VotingPlugin engineering and verification rules.
|
||||
triggers: [conventions, code review, implementation, test]
|
||||
edges:
|
||||
- target: context/architecture.md
|
||||
condition: when finding the owner of a change
|
||||
- target: context/vote-rewards.md
|
||||
condition: when a change affects vote behavior
|
||||
grounds_to: []
|
||||
last_updated: 2026-09-20
|
||||
mex:
|
||||
id: mx_01M305TTXGZN471W11VFPJQKQH
|
||||
type: convention
|
||||
status: promoted
|
||||
revision: 2
|
||||
title: conventions
|
||||
relations:
|
||||
- type: related_to
|
||||
target: mx_01M305TTX1QHVTAB2KR3S1VPH5
|
||||
note: when finding the owner of a change
|
||||
---
|
||||
|
||||
# Conventions that need context
|
||||
|
||||
- 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.
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
mex:
|
||||
id: mx_01M31068M0WJ4KB0ZD6C6BXHZK
|
||||
type: decision
|
||||
status: promoted
|
||||
revision: 1
|
||||
title: Defer end-to-end proxy vote delivery guarantee
|
||||
sources:
|
||||
- type: document
|
||||
ref: .mex/inbox/proposal_01M31040E5ECB5F57YHXYGX618.md
|
||||
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.
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
name: decisions
|
||||
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`.
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
name: proxy-voting
|
||||
description: Proxy/global vote routing and state distinctions.
|
||||
triggers: [proxy, global vote, BungeeCord, Velocity, wasOnline, routing]
|
||||
edges:
|
||||
- target: context/architecture.md
|
||||
condition: when tracing ownership between nodes
|
||||
- target: context/vote-rewards.md
|
||||
condition: when proxy metadata affects reward delivery
|
||||
grounds_to: []
|
||||
last_updated: 2026-09-20
|
||||
---
|
||||
|
||||
# Proxy and global voting
|
||||
|
||||
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.
|
||||
|
||||
Sources: `VotingPlugin/src/main/resources/Config.yml` (proxy guidance), `VotingPlugin/src/main/resources/bungeeconfig.yml`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/listeners/PlayerVoteListener.java`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/proxy/`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/`.
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
name: setup
|
||||
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.
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
name: stack
|
||||
description: Runtime, build, and dependency facts for VotingPlugin.
|
||||
triggers: [Java, Maven, Bukkit, Paper, Velocity, BungeeCord, dependency]
|
||||
edges:
|
||||
- target: context/setup.md
|
||||
condition: when installing or building
|
||||
- target: context/architecture.md
|
||||
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.
|
||||
|
||||
Sources: `VotingPlugin/pom.xml`, `VotingPlugin/src/main/resources/Config.yml`, `VotingPlugin/src/main/resources/bungeeconfig.yml`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/transport/`.
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
name: vote-rewards
|
||||
description: Vote mutation, totals, reward, and offline-delivery compatibility.
|
||||
triggers: [reward, totals, points, offline vote, vote streak, VoteParty]
|
||||
edges:
|
||||
- target: context/architecture.md
|
||||
condition: when locating the vote or reward owner
|
||||
- target: context/proxy-voting.md
|
||||
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.
|
||||
|
||||
Sources: `VotingPlugin/src/main/java/com/bencodez/votingplugin/listeners/PlayerVoteListener.java`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/user/VotingPluginUser.java`, `VotingPlugin/src/main/resources/Config.yml`.
|
||||
@@ -1,11 +0,0 @@
|
||||
---
|
||||
schema_version: 2
|
||||
id: "event_01M31040CS7129A1X8DZECNCZK"
|
||||
timestamp: "2026-09-21T03:28:26.521Z"
|
||||
actor: {"email":"17074231+BenCodez@users.noreply.github.com","kind":"git","name":"BenCodez"}
|
||||
action: "inbox.published"
|
||||
origin: {"kind":"workflow","operation":"inbox.publish"}
|
||||
label: "Defer end-to-end proxy vote delivery guarantee"
|
||||
subjects: [{"entity":{"id":"proposal_01M31040E5ECB5F57YHXYGX618","kind":"proposal"},"kind":"entity"}]
|
||||
repo_state: {"branch":"codex/pr1619-comments","dirty":false,"head":"37b610aad3094080b3282689ad2fc0d2bb8fa45d","observedAt":"2026-09-21T03:28:26.529Z"}
|
||||
---
|
||||
@@ -1,11 +0,0 @@
|
||||
---
|
||||
schema_version: 2
|
||||
id: "event_01M31068JGH5JBVJR4ZDC7TBXN"
|
||||
timestamp: "2026-09-21T03:29:40.432Z"
|
||||
actor: {"email":"17074231+BenCodez@users.noreply.github.com","kind":"git","name":"BenCodez"}
|
||||
action: "inbox.approved"
|
||||
origin: {"kind":"workflow","operation":"inbox.approve"}
|
||||
label: "Defer end-to-end proxy vote delivery guarantee"
|
||||
subjects: [{"entity":{"id":"proposal_01M31040E5ECB5F57YHXYGX618","kind":"proposal"},"kind":"entity"},{"entity":{"id":"mx_01M31068M0WJ4KB0ZD6C6BXHZK","kind":"decision"},"kind":"entity"}]
|
||||
repo_state: {"branch":"codex/pr1619-comments","dirty":true,"head":"37b610aad3094080b3282689ad2fc0d2bb8fa45d","observedAt":"2026-09-21T03:29:40.440Z"}
|
||||
---
|
||||
@@ -1,7 +0,0 @@
|
||||
{"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"}
|
||||
@@ -1,18 +0,0 @@
|
||||
{"v":1,"phase":"intent","opId":"mig_cabe95b226ccf7cde3af8516b56acf274014b473","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTVDWCN3GH24C15GADN2"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/architecture.md"],"payloadHash":"286d7621e415c1ec61509384e7551086c0b585e1dfe3de71a6dc23f8499b3dd2","revisions":[{"entityId":"mx_01M305TTVDWCN3GH24C15GADN2","before":0,"after":1}]}
|
||||
{"v":1,"phase":"complete","opId":"mig_cabe95b226ccf7cde3af8516b56acf274014b473","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTVDWCN3GH24C15GADN2"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/architecture.md"],"payloadHash":"286d7621e415c1ec61509384e7551086c0b585e1dfe3de71a6dc23f8499b3dd2","revisions":[{"entityId":"mx_01M305TTVDWCN3GH24C15GADN2","before":0,"after":1}]}
|
||||
{"v":1,"phase":"intent","opId":"mig_04bdfe68d2f7f9f793ced12eadc3a4027c0b5a64","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTX1QHVTAB2KR3S1VPH5"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/architecture.md"],"payloadHash":"60e9cb3b8cf14fc598ca64e965b4e9a2e20ef743ac37abc02e2c86cc48103ff5","revisions":[{"entityId":"mx_01M305TTX1QHVTAB2KR3S1VPH5","before":0,"after":1}]}
|
||||
{"v":1,"phase":"complete","opId":"mig_04bdfe68d2f7f9f793ced12eadc3a4027c0b5a64","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTX1QHVTAB2KR3S1VPH5"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/architecture.md"],"payloadHash":"60e9cb3b8cf14fc598ca64e965b4e9a2e20ef743ac37abc02e2c86cc48103ff5","revisions":[{"entityId":"mx_01M305TTX1QHVTAB2KR3S1VPH5","before":0,"after":1}]}
|
||||
{"v":1,"phase":"intent","opId":"mig_bba7e40030721976170be1e0e46673406f16555f","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTXGZN471W11VFPJQKQH"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/conventions.md"],"payloadHash":"dea0802d2c6208b2f103f615a1a322ba63f9a35dbddbe82d49988f8ed41f86ae","revisions":[{"entityId":"mx_01M305TTXGZN471W11VFPJQKQH","before":0,"after":1}]}
|
||||
{"v":1,"phase":"complete","opId":"mig_bba7e40030721976170be1e0e46673406f16555f","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTXGZN471W11VFPJQKQH"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/conventions.md"],"payloadHash":"dea0802d2c6208b2f103f615a1a322ba63f9a35dbddbe82d49988f8ed41f86ae","revisions":[{"entityId":"mx_01M305TTXGZN471W11VFPJQKQH","before":0,"after":1}]}
|
||||
{"v":1,"phase":"intent","opId":"mig_8dba03310a5302a413a7df38e88f6c2de16bc1e0","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTXSX79T4GDEXNMFVB3E"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/setup.md"],"payloadHash":"cf355dba2ffc569444242ee5b2fce6dd91e95d47beb012e590e6b8893c2314a4","revisions":[{"entityId":"mx_01M305TTXSX79T4GDEXNMFVB3E","before":0,"after":1}]}
|
||||
{"v":1,"phase":"complete","opId":"mig_8dba03310a5302a413a7df38e88f6c2de16bc1e0","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTXSX79T4GDEXNMFVB3E"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/setup.md"],"payloadHash":"cf355dba2ffc569444242ee5b2fce6dd91e95d47beb012e590e6b8893c2314a4","revisions":[{"entityId":"mx_01M305TTXSX79T4GDEXNMFVB3E","before":0,"after":1}]}
|
||||
{"v":1,"phase":"intent","opId":"mig_8e05280db06fec1f3e853ee787db16a146e8d9d3","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTY6NXWZP72T00XY9ESP"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/proxy-vote-change.md"],"payloadHash":"42006b04153f6c1f1ec3959ccf87960e26689c0b1f0e1728e1c98bd1c2c40699","revisions":[{"entityId":"mx_01M305TTY6NXWZP72T00XY9ESP","before":0,"after":1}]}
|
||||
{"v":1,"phase":"complete","opId":"mig_8e05280db06fec1f3e853ee787db16a146e8d9d3","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTY6NXWZP72T00XY9ESP"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/proxy-vote-change.md"],"payloadHash":"42006b04153f6c1f1ec3959ccf87960e26689c0b1f0e1728e1c98bd1c2c40699","revisions":[{"entityId":"mx_01M305TTY6NXWZP72T00XY9ESP","before":0,"after":1}]}
|
||||
{"v":1,"phase":"intent","opId":"mig_efc33097f7bc4550f829fd1a257d913379502a26","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTYFYNY85XFDEVFS6VXM"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/vote-behavior-change.md"],"payloadHash":"a541fa410e6a976cae8973438ee2919c83c4fb493fc51b61eaa7f0f068c04ea9","revisions":[{"entityId":"mx_01M305TTYFYNY85XFDEVFS6VXM","before":0,"after":1}]}
|
||||
{"v":1,"phase":"complete","opId":"mig_efc33097f7bc4550f829fd1a257d913379502a26","type":"create-entry","entityIds":[],"createdIds":["mx_01M305TTYFYNY85XFDEVFS6VXM"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/vote-behavior-change.md"],"payloadHash":"a541fa410e6a976cae8973438ee2919c83c4fb493fc51b61eaa7f0f068c04ea9","revisions":[{"entityId":"mx_01M305TTYFYNY85XFDEVFS6VXM","before":0,"after":1}]}
|
||||
{"v":1,"phase":"intent","opId":"mig_3055f0ee57741e4f76d11d3905d58cf2ea55677f","type":"add-relation","entityIds":["mx_01M305TTXGZN471W11VFPJQKQH"],"createdIds":[],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/conventions.md"],"payloadHash":"798770ef1f12752d5cdb2faca4a6657b7bf31b8fc29a3e36cac7a985d231074e","revisions":[{"entityId":"mx_01M305TTXGZN471W11VFPJQKQH","before":1,"after":2}]}
|
||||
{"v":1,"phase":"complete","opId":"mig_3055f0ee57741e4f76d11d3905d58cf2ea55677f","type":"add-relation","entityIds":["mx_01M305TTXGZN471W11VFPJQKQH"],"createdIds":[],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/conventions.md"],"payloadHash":"798770ef1f12752d5cdb2faca4a6657b7bf31b8fc29a3e36cac7a985d231074e","revisions":[{"entityId":"mx_01M305TTXGZN471W11VFPJQKQH","before":1,"after":2}]}
|
||||
{"v":1,"phase":"intent","opId":"mig_abd4b29a2420249bd155970f9fb94d516e380c85","type":"add-relation","entityIds":["mx_01M305TTXSX79T4GDEXNMFVB3E"],"createdIds":[],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/setup.md"],"payloadHash":"270b121758752ad2995d9d210c5242c588bc042284f665f72e6012fcc3696cb9","revisions":[{"entityId":"mx_01M305TTXSX79T4GDEXNMFVB3E","before":1,"after":2}]}
|
||||
{"v":1,"phase":"complete","opId":"mig_abd4b29a2420249bd155970f9fb94d516e380c85","type":"add-relation","entityIds":["mx_01M305TTXSX79T4GDEXNMFVB3E"],"createdIds":[],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/setup.md"],"payloadHash":"270b121758752ad2995d9d210c5242c588bc042284f665f72e6012fcc3696cb9","revisions":[{"entityId":"mx_01M305TTXSX79T4GDEXNMFVB3E","before":1,"after":2}]}
|
||||
{"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."}
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
schema_version: 1
|
||||
id: "proposal_01M31040E5ECB5F57YHXYGX618"
|
||||
state: "approved"
|
||||
author: {"email":"17074231+BenCodez@users.noreply.github.com","kind":"git","name":"BenCodez"}
|
||||
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"}}
|
||||
target_revisions: []
|
||||
reviewer: {"email":"17074231+BenCodez@users.noreply.github.com","kind":"git","name":"BenCodez"}
|
||||
reviewed_at: "2026-09-21T03:29:40.432Z"
|
||||
---
|
||||
@@ -1,8 +0,0 @@
|
||||
# Pattern Index
|
||||
|
||||
Use these only when the task matches; routine edits need no pattern load.
|
||||
|
||||
| Pattern | Use when |
|
||||
| --- | --- |
|
||||
| [proxy-vote-change.md](proxy-vote-change.md) | Changing proxy/global vote routing or transport |
|
||||
| [vote-behavior-change.md](vote-behavior-change.md) | Changing Bukkit vote mutation, totals, points, or rewards |
|
||||
@@ -1,5 +0,0 @@
|
||||
# VotingPlugin patterns
|
||||
|
||||
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.
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
name: proxy-vote-change
|
||||
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.
|
||||
|
||||
Source: `VotingPlugin/src/main/java/com/bencodez/votingplugin/proxy/`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/backendproxy/`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/listeners/PlayerVoteListener.java`.
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
name: vote-behavior-change
|
||||
description: Preserve production vote and reward behavior during changes.
|
||||
triggers: [vote listener, totals, points, offline reward, vote site, reward]
|
||||
edges:
|
||||
- target: context/vote-rewards.md
|
||||
condition: when mapping vote mutation and delivery
|
||||
- target: context/proxy-voting.md
|
||||
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.
|
||||
|
||||
Source: `VotingPlugin/src/main/java/com/bencodez/votingplugin/listeners/PlayerVoteListener.java`, `VotingPlugin/src/main/java/com/bencodez/votingplugin/user/VotingPluginUser.java`, root `AGENTS.md`.
|
||||
@@ -349,10 +349,10 @@ Control behavior in production.
|
||||
|
||||
<!-- 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.
|
||||
- At the start of every session, use the configured project knowledge reader to verify the private MEX projection, then read its `.mex/AGENTS.md` and `.mex/ROUTER.md` and follow the router for relevant context. Run knowledge queries in that projection; read checkout-local drafts and preferences in the writable workspace when applicable. Report an unavailable reader rather than substituting another project's memory.
|
||||
- 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.
|
||||
- Read `.agents/skills/mex-inbox/SKILL.md` and `.agents/skills/mex-relay/SKILL.md` from this project's entry in the verified private knowledge archive. Perform MEX writes only through a supported writable project workspace and its publication workflow, never in the read-only projection; report an unavailable workspace.
|
||||
- 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.
|
||||
|
||||
Reference in new issue
Block a user