diff --git a/.agents/skills/mex-inbox/.mex-managed.json b/.agents/skills/mex-inbox/.mex-managed.json new file mode 100644 index 000000000..64a743385 --- /dev/null +++ b/.agents/skills/mex-inbox/.mex-managed.json @@ -0,0 +1,11 @@ +{ + "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" + } +} diff --git a/.agents/skills/mex-inbox/SKILL.md b/.agents/skills/mex-inbox/SKILL.md new file mode 100644 index 000000000..7ddb707cf --- /dev/null +++ b/.agents/skills/mex-inbox/SKILL.md @@ -0,0 +1,44 @@ +--- +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=` 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. diff --git a/.agents/skills/mex-inbox/agents/openai.yaml b/.agents/skills/mex-inbox/agents/openai.yaml new file mode 100644 index 000000000..de507237c --- /dev/null +++ b/.agents/skills/mex-inbox/agents/openai.yaml @@ -0,0 +1,4 @@ +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." diff --git a/.agents/skills/mex-inbox/references/cli-workflows.md b/.agents/skills/mex-inbox/references/cli-workflows.md new file mode 100644 index 000000000..c0f9215d8 --- /dev/null +++ b/.agents/skills/mex-inbox/references/cli-workflows.md @@ -0,0 +1,86 @@ +# 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 --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 --limit 10 --json` or `mex wiki list --type --limit 25 --json` to find related records before creating another. +2. Read the best candidate with `mex inbox target --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 --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 --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 --json` and use its exact current local revision. +4. Preview with `mex inbox draft save --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 --json` without another confirmation. +6. Read the returned draft ID and respond with `/inbox?view=drafts&draft=`. + +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 --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 --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 --json`. +6. Return `/inbox?view=review&proposal=`. + +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 --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 --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 --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. diff --git a/.agents/skills/mex-relay/.mex-managed.json b/.agents/skills/mex-relay/.mex-managed.json new file mode 100644 index 000000000..20ae02b7e --- /dev/null +++ b/.agents/skills/mex-relay/.mex-managed.json @@ -0,0 +1,11 @@ +{ + "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" + } +} diff --git a/.agents/skills/mex-relay/SKILL.md b/.agents/skills/mex-relay/SKILL.md new file mode 100644 index 000000000..15935610a --- /dev/null +++ b/.agents/skills/mex-relay/SKILL.md @@ -0,0 +1,39 @@ +--- +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 --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=` 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. diff --git a/.agents/skills/mex-relay/agents/openai.yaml b/.agents/skills/mex-relay/agents/openai.yaml new file mode 100644 index 000000000..9b0e781d0 --- /dev/null +++ b/.agents/skills/mex-relay/agents/openai.yaml @@ -0,0 +1,4 @@ +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." diff --git a/.agents/skills/mex-relay/references/cli-workflows.md b/.agents/skills/mex-relay/references/cli-workflows.md new file mode 100644 index 000000000..89f812276 --- /dev/null +++ b/.agents/skills/mex-relay/references/cli-workflows.md @@ -0,0 +1,88 @@ +# 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 --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 --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 --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 --operation-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=`. 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 --json`, preserve its content, and use its exact local revision in the structured request. Preview with `mex relay draft save --json`; require `ok: true`, `mode: "preview"`, and `data.preview.valid: true`. Apply the complete captured envelope unchanged with `mex relay draft save --apply --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 --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 --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 --json`. +6. Return `/relays?view=sent&state=open&relay=`. + +## Take a Relay + +1. Resolve the exact published Relay with `mex relay show --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 --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 --json`. +5. Return `/relays?view=mine&state=open&relay=`. + +## Close a Relay + +1. Resolve the exact acknowledged Relay and its current revision. +2. Resolve `relay.close` and preview with `mex relay close --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 --json`. +5. Return `/relays?view=all&state=closed&relay=`. + +Closing does not complete a linked task, issue, pull request, or Workstream. No lifecycle command stages, commits, pushes, pulls, or sends a notification. diff --git a/.mex/.gitignore b/.mex/.gitignore new file mode 100644 index 000000000..a2ec937c6 --- /dev/null +++ b/.mex/.gitignore @@ -0,0 +1,3 @@ +graph.db* +wiki.db* +local/ diff --git a/.mex/AGENTS.md b/.mex/AGENTS.md new file mode 100644 index 000000000..a61c9af5c --- /dev/null +++ b/.mex/AGENTS.md @@ -0,0 +1,17 @@ +--- +name: agents +description: AdvancedCore MEX authority and retrieval boundary. +last_updated: 2026-09-20 +--- + +# AdvancedCore memory + +Root `AGENTS.md` contains the source hierarchy and MEX use guidance. This Wiki keeps context about user/cache, storage, reward, and compatibility boundaries. Read only relevant pages from `ROUTER.md`. Verify every claim against current Java/tests; MEX 0.8.2 has no Java structural graph. + + +## 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. + diff --git a/.mex/ROUTER.md b/.mex/ROUTER.md new file mode 100644 index 000000000..021210405 --- /dev/null +++ b/.mex/ROUTER.md @@ -0,0 +1,22 @@ +--- +name: router +description: AdvancedCore durable knowledge routes. +edges: + - target: patterns/user-storage-change.md + condition: when changing user persistence + - target: patterns/reward-queue-change.md + condition: when changing queued reward resolution +last_updated: 2026-09-20 +--- + +# AdvancedCore memory routes + +| Task | Read | +| --- | --- | +| Shared API/platform ownership | `context/architecture.md`, `context/stack.md` | +| User/cache/SQL persistence | `context/storage.md`, `patterns/user-storage-change.md` | +| Rewards or queue restoration | `context/rewards.md`, `patterns/reward-queue-change.md` | +| Why current limitations matter | `context/decisions.md` | +| Build or MEX environment | `context/setup.md` | + +Root `AGENTS.md` owns authority and use guidance. Inspect current Java/tests after relevant MEX retrieval. diff --git a/.mex/SETUP.md b/.mex/SETUP.md new file mode 100644 index 000000000..6ff9d4f62 --- /dev/null +++ b/.mex/SETUP.md @@ -0,0 +1,3 @@ +# AdvancedCore MEX setup + +Codex uses the official MEX Inbox and Relay skills. This Java repository has no structural Java Code Graph in MEX 0.8.2. Use Wiki context, then current Java source and tests. diff --git a/.mex/SYNC.md b/.mex/SYNC.md new file mode 100644 index 000000000..dd8371c27 --- /dev/null +++ b/.mex/SYNC.md @@ -0,0 +1,3 @@ +# Keep AdvancedCore memory current + +Follow root `AGENTS.md` authority rules. Check remembered storage and reward claims against source/tests before use. Correct stale entries through reviewed MEX edits or Inbox; rebuild the Wiki index after changes. diff --git a/.mex/config.json b/.mex/config.json new file mode 100644 index 000000000..0fe65b9f6 --- /dev/null +++ b/.mex/config.json @@ -0,0 +1,10 @@ +{ + "setupMode": "code-repo", + "aiTools": [ + "codex" + ], + "scaffold_id": "b2369e6e-a7ad-49d5-84af-a2a04252d236", + "scaffold_name": "AdvancedCore", + "origin": null, + "upstream": null +} diff --git a/.mex/context/architecture.md b/.mex/context/architecture.md new file mode 100644 index 000000000..292543b35 --- /dev/null +++ b/.mex/context/architecture.md @@ -0,0 +1,18 @@ +--- +name: architecture +description: AdvancedCore library ownership boundaries. +triggers: [architecture, API, user, reward] +last_updated: 2026-09-20 +mex: + id: mx_01M30783X7XRSR3B5HENZVSXAJ + type: architecture + status: promoted + revision: 1 + title: architecture +--- + +# Library boundaries + +AdvancedCore provides user data/cache, reward construction and dispatch, compatibility helpers, and platform integrations consumed by plugins including VotingPlugin. Legacy/public surfaces remain in `api/user` and `api/rewards`; newer shared contracts live under `core/user` and `core/reward`. Those shared contracts coexist with Bukkit adapters rather than replacing every legacy path. Source: `AdvancedCore/src/main/java/com/bencodez/advancedcore/api/user/`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/core/user/`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/core/reward/`. + +Bukkit-specific reward dispatch and scheduling still exist. The shared orchestrator sequences configured work through injected platform and durability adapters; inspect the actual adapter before assuming a stronger delivery guarantee. Source: `AdvancedCore/src/main/java/com/bencodez/advancedcore/api/rewards/RewardExecutor.java`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/core/reward/SharedRewardOrchestrator.java`. diff --git a/.mex/context/conventions.md b/.mex/context/conventions.md new file mode 100644 index 000000000..dcf63df2f --- /dev/null +++ b/.mex/context/conventions.md @@ -0,0 +1,16 @@ +--- +name: conventions +description: Where current rules and contracts reside. +triggers: [convention, testing] +last_updated: 2026-09-20 +mex: + id: mx_01M30783YGZSBKFZQFH186Q7BN + type: convention + status: promoted + revision: 1 + title: conventions +--- + +# Rule ownership + +Repository guidance is in root `AGENTS.md`. `README.md`, `AdvancedCore/pom.xml`, CI, and tests describe current build and public behavior. MEX stores unusual constraints, not generic Java/Maven or code-review checklists. diff --git a/.mex/context/decisions.md b/.mex/context/decisions.md new file mode 100644 index 000000000..2a85b17d1 --- /dev/null +++ b/.mex/context/decisions.md @@ -0,0 +1,18 @@ +--- +name: decisions +description: Compatibility constraints for downstream consumers. +triggers: [decision, compatibility, migration] +last_updated: 2026-09-20 +mex: + id: mx_01M307CW4VNVXE8YM59FVJJCNG + type: decision + status: promoted + revision: 1 + title: AdvancedCore compatibility decisions +--- + +# Compatibility decisions + +AdvancedCore is shaded/consumed by VotingPlugin. Public user/reward changes affect its vote path even when this repository's own tests pass; check the current consumer source and dependency version before changing a contract. Source: `AdvancedCore/pom.xml`, root `AGENTS.md`. + +New queued reward references encode normal versus generated provenance. Legacy bare names have no marker: resolver precedence favors a registered/direct reward before generated fallback when names collide. This compatibility behavior does not establish exactly-once execution. Source: `AdvancedCore/src/main/java/com/bencodez/advancedcore/api/rewards/RewardExecutor.java`, `AdvancedCore/src/test/java/com/bencodez/advancedcore/tests/rewards/QueuedGeneratedRewardDispatchTest.java`. diff --git a/.mex/context/rewards.md b/.mex/context/rewards.md new file mode 100644 index 000000000..882e8d9d8 --- /dev/null +++ b/.mex/context/rewards.md @@ -0,0 +1,18 @@ +--- +name: rewards +description: Reward execution and persisted queue provenance. +triggers: [reward, queue, generated, snapshot] +last_updated: 2026-09-20 +mex: + id: mx_01M307CW4VJTMDNFXVDRE3SS1A + type: component + status: promoted + revision: 1 + title: Reward queue boundary +--- + +# Reward boundaries + +`RewardExecutor` initializes online state, schedules reward execution off the Bukkit primary thread when needed, and resolves persisted queue references at delivery time. Explicit queue references distinguish generated files from normal named rewards; older entries first prefer a registered reward or direct handle, then try generated resolution. This preserves legacy queue provenance and current YAML-defined reward lookup. Source: `AdvancedCore/src/main/java/com/bencodez/advancedcore/api/rewards/RewardExecutor.java`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/api/user/PersistedQueueReference.java`. + +`SharedRewardOrchestrator` sequences a plan through requirements, durable decision/progress, deferral, native action, and checkpoint callbacks. The caller supplies `SharedRewardDurability` and platform actions. The action completes before the progress checkpoint; without an idempotent native action/adapter, a crash in that window can replay it. Do not infer exactly-once delivery from the orchestration interface. The legacy offline queue now claims occurrences, serializes per-user replay, and retains/restores failed entries; inspect its checkpoint and acknowledgement paths separately. Source: `AdvancedCore/src/main/java/com/bencodez/advancedcore/core/reward/SharedRewardOrchestrator.java`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/core/reward/SharedRewardDurability.java`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/api/user/AdvancedCoreUser.java`. diff --git a/.mex/context/setup.md b/.mex/context/setup.md new file mode 100644 index 000000000..2d27de244 --- /dev/null +++ b/.mex/context/setup.md @@ -0,0 +1,16 @@ +--- +name: setup +description: MEX use for AdvancedCore. +triggers: [setup, MEX, graph] +last_updated: 2026-09-20 +mex: + id: mx_01M30783YVMXD07R9PNSMFCZ0F + type: guide + status: promoted + revision: 1 + title: setup +--- + +# MEX use + +Use Wiki for architecture and history, Java source/tests for implementation truth. Run `mex wiki rebuild-index` after memory changes and `mex check` for scaffold health. The local CLI does not need a Hub. diff --git a/.mex/context/stack.md b/.mex/context/stack.md new file mode 100644 index 000000000..397e4f366 --- /dev/null +++ b/.mex/context/stack.md @@ -0,0 +1,10 @@ +--- +name: stack +description: Current AdvancedCore build/platform boundary. +triggers: [Java, Maven, Bukkit, proxy] +last_updated: 2026-09-20 +--- + +# Build/runtime boundary + +This checkout compiles for Java 21 from `AdvancedCore/pom.xml`; CI runs its Maven package goal. The POM includes Bukkit/Spigot, BungeeCord, and Velocity APIs. Dependency and version details should be read from the current POM, not frozen in MEX. MEX 0.8.2 indexes no Java symbols here. Source: `AdvancedCore/pom.xml`, `.github/workflows/maven.yml`. diff --git a/.mex/context/storage.md b/.mex/context/storage.md new file mode 100644 index 000000000..d45f1d450 --- /dev/null +++ b/.mex/context/storage.md @@ -0,0 +1,18 @@ +--- +name: storage +description: Current user cache and persistence semantics and limits. +triggers: [storage, cache, SQL, persistence] +last_updated: 2026-09-20 +mex: + id: mx_01M307CW4V8D4NK2BM9GH4VY2R + type: component + status: promoted + revision: 1 + title: User and storage boundary +--- + +# User and storage boundary + +Ordinary cached writes and the explicit atomic transaction are distinct paths. `UserDataCache.addChange` can publish before its queued persistence; a suppressed storage exception must not be mistaken for a durable acknowledgement. For caller-owned SQL records, `UserDataManager.withAtomicUserTransaction` enters the shared runtime, flushes queued cache work, and reconciles the committed snapshot. Initial values are row prerequisites; operation-specific mutations belong inside the callback. Source: `AdvancedCore/src/main/java/com/bencodez/advancedcore/api/user/usercache/UserDataCache.java`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/api/user/usercache/UserDataManager.java`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/core/user/runtime/SharedUserDataRuntime.java`. + +`SqlUserStorage.transaction` exposes a bounded callback with a locked user row and one backend-owned JDBC connection. The scope can read/write user values and access caller-owned SQL tables within the same commit; callers must not commit, close, change auto-commit, or retain the connection. This boundary does not supply a unique operation key, retry policy, or reward acknowledgement by itself. Blocking use belongs on a storage worker. Source: `AdvancedCore/src/main/java/com/bencodez/advancedcore/core/user/storage/SqlUserStorage.java`, `AdvancedCore/src/main/java/com/bencodez/advancedcore/core/user/storage/sql/JdbcSqlUserStorage.java`. diff --git a/.mex/events/operations.jsonl b/.mex/events/operations.jsonl new file mode 100644 index 000000000..fdec76623 --- /dev/null +++ b/.mex/events/operations.jsonl @@ -0,0 +1,10 @@ +{"v":1,"phase":"intent","opId":"mig_04bdfe68d2f7f9f793ced12eadc3a4027c0b5a64","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783X7XRSR3B5HENZVSXAJ"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/architecture.md"],"payloadHash":"60e9cb3b8cf14fc598ca64e965b4e9a2e20ef743ac37abc02e2c86cc48103ff5","revisions":[{"entityId":"mx_01M30783X7XRSR3B5HENZVSXAJ","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_04bdfe68d2f7f9f793ced12eadc3a4027c0b5a64","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783X7XRSR3B5HENZVSXAJ"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/architecture.md"],"payloadHash":"60e9cb3b8cf14fc598ca64e965b4e9a2e20ef743ac37abc02e2c86cc48103ff5","revisions":[{"entityId":"mx_01M30783X7XRSR3B5HENZVSXAJ","before":0,"after":1}]} +{"v":1,"phase":"intent","opId":"mig_bba7e40030721976170be1e0e46673406f16555f","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783YGZSBKFZQFH186Q7BN"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/conventions.md"],"payloadHash":"dea0802d2c6208b2f103f615a1a322ba63f9a35dbddbe82d49988f8ed41f86ae","revisions":[{"entityId":"mx_01M30783YGZSBKFZQFH186Q7BN","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_bba7e40030721976170be1e0e46673406f16555f","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783YGZSBKFZQFH186Q7BN"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/conventions.md"],"payloadHash":"dea0802d2c6208b2f103f615a1a322ba63f9a35dbddbe82d49988f8ed41f86ae","revisions":[{"entityId":"mx_01M30783YGZSBKFZQFH186Q7BN","before":0,"after":1}]} +{"v":1,"phase":"intent","opId":"mig_8dba03310a5302a413a7df38e88f6c2de16bc1e0","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783YVMXD07R9PNSMFCZ0F"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/setup.md"],"payloadHash":"cf355dba2ffc569444242ee5b2fce6dd91e95d47beb012e590e6b8893c2314a4","revisions":[{"entityId":"mx_01M30783YVMXD07R9PNSMFCZ0F","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_8dba03310a5302a413a7df38e88f6c2de16bc1e0","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783YVMXD07R9PNSMFCZ0F"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/setup.md"],"payloadHash":"cf355dba2ffc569444242ee5b2fce6dd91e95d47beb012e590e6b8893c2314a4","revisions":[{"entityId":"mx_01M30783YVMXD07R9PNSMFCZ0F","before":0,"after":1}]} +{"v":1,"phase":"intent","opId":"mig_cc04f1fee47c054c0c16e513ddfd6f0cc8eee0d8","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783Z5PYF08WAWW4ANAERJ"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/reward-queue-change.md"],"payloadHash":"1072a9121ee524d2455683ec981fcd93140be76ed20022a550a39cfeeb80551e","revisions":[{"entityId":"mx_01M30783Z5PYF08WAWW4ANAERJ","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_cc04f1fee47c054c0c16e513ddfd6f0cc8eee0d8","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783Z5PYF08WAWW4ANAERJ"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/reward-queue-change.md"],"payloadHash":"1072a9121ee524d2455683ec981fcd93140be76ed20022a550a39cfeeb80551e","revisions":[{"entityId":"mx_01M30783Z5PYF08WAWW4ANAERJ","before":0,"after":1}]} +{"v":1,"phase":"intent","opId":"mig_f55a8ecd21474000a175ad7778297c2f28674334","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783ZG1EDMVDQEA2XMH875"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/user-storage-change.md"],"payloadHash":"e44262574c07d9269b4c926c807a6bad692b5983ba739f6fe24abea618c717c1","revisions":[{"entityId":"mx_01M30783ZG1EDMVDQEA2XMH875","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_f55a8ecd21474000a175ad7778297c2f28674334","type":"create-entry","entityIds":[],"createdIds":["mx_01M30783ZG1EDMVDQEA2XMH875"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/user-storage-change.md"],"payloadHash":"e44262574c07d9269b4c926c807a6bad692b5983ba739f6fe24abea618c717c1","revisions":[{"entityId":"mx_01M30783ZG1EDMVDQEA2XMH875","before":0,"after":1}]} diff --git a/.mex/patterns/INDEX.md b/.mex/patterns/INDEX.md new file mode 100644 index 000000000..62c311795 --- /dev/null +++ b/.mex/patterns/INDEX.md @@ -0,0 +1,6 @@ +# AdvancedCore patterns + +| Pattern | When useful | +| --- | --- | +| [user-storage-change.md](user-storage-change.md) | Changing cache, SQL, or user lifecycle behavior | +| [reward-queue-change.md](reward-queue-change.md) | Changing queued reward resolution or replay | diff --git a/.mex/patterns/README.md b/.mex/patterns/README.md new file mode 100644 index 000000000..c585805c2 --- /dev/null +++ b/.mex/patterns/README.md @@ -0,0 +1,3 @@ +# AdvancedCore patterns + +These pages preserve non-obvious failure paths. Verify them against current code/tests. Formal rules stay in the repository and workspace instructions. diff --git a/.mex/patterns/reward-queue-change.md b/.mex/patterns/reward-queue-change.md new file mode 100644 index 000000000..cd987c048 --- /dev/null +++ b/.mex/patterns/reward-queue-change.md @@ -0,0 +1,16 @@ +--- +name: reward-queue-change +description: Preserve normal/generated reward provenance on queue delivery. +triggers: [reward, queue, generated] +last_updated: 2026-09-20 +mex: + id: mx_01M30783Z5PYF08WAWW4ANAERJ + type: pattern + status: promoted + revision: 1 + title: reward-queue-change +--- + +# Queued reward change + +Trace how the queue reference is written, restored, resolved, and dispatched. Test normal named, generated-file, legacy bare-name, and registered/generated name-collision cases. Include occurrence claims, checkpoint persistence, and failure recovery when changing replay. Keep the delivery claim narrower than the actual action and checkpoint contract. See `context/rewards.md` and `AdvancedCore/src/test/java/com/bencodez/advancedcore/tests/rewards/QueuedGeneratedRewardDispatchTest.java`. diff --git a/.mex/patterns/user-storage-change.md b/.mex/patterns/user-storage-change.md new file mode 100644 index 000000000..dad684b0b --- /dev/null +++ b/.mex/patterns/user-storage-change.md @@ -0,0 +1,16 @@ +--- +name: user-storage-change +description: Check cache publication against persistence behavior. +triggers: [storage, cache, SQL] +last_updated: 2026-09-20 +mex: + id: mx_01M30783ZG1EDMVDQEA2XMH875 + type: pattern + status: promoted + revision: 1 + title: user-storage-change +--- + +# User storage change + +Trace ordinary cache mutation/flush separately from `withAtomicUserTransaction`, including SQL failure, retry, cache reconciliation, and shutdown. Caller-owned records can share the explicit JDBC transaction, but uniqueness and retry remain caller responsibilities. See `context/storage.md` and `AdvancedCore/src/test/java/com/bencodez/advancedcore/tests/user/`. diff --git a/AGENTS.md b/AGENTS.md index 753ccc17c..589a2dcf7 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -69,3 +69,19 @@ Keep changes focused and avoid formatting churn. Before any commit, push, PR upd 5. inspect the complete base-to-HEAD diff for compatibility, concurrency, persistence, lifecycle, security, and packaging regressions. For substantive work, obtain a fresh source-read-only review. The implementation agent verifies and fixes accepted findings, reruns validation, and obtains a new review of the updated snapshot. Do not reuse an earlier clean verdict after changes, and do not merge without explicit authorization. + +## MEX project memory + +For substantial tasks where architecture, compatibility, or prior failures matter, retrieve relevant MEX context, then verify it against current Java/tests and formal contracts. Use current code/tests first, this guide and formal docs second, reviewed MEX knowledge third, and historical Relays last. Correct stale memory; skip MEX for trivial edits. MEX 0.8.2 does not index Java here. Use `$mex-inbox` for durable findings and `$mex-relay` for substantial unfinished handoffs. + + +## 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. +