From 594676097a03f980bd51f75e9527afa2732afbfb Mon Sep 17 00:00:00 2001 From: BenCodez <17074231+BenCodez@users.noreply.github.com> Date: Sun, 20 Sep 2026 14:22:32 -0600 Subject: [PATCH 1/2] chore: add MEX project memory --- .agents/skills/mex-inbox/.mex-managed.json | 11 +++ .agents/skills/mex-inbox/SKILL.md | 44 ++++++++++ .agents/skills/mex-inbox/agents/openai.yaml | 4 + .../mex-inbox/references/cli-workflows.md | 86 ++++++++++++++++++ .agents/skills/mex-relay/.mex-managed.json | 11 +++ .agents/skills/mex-relay/SKILL.md | 39 ++++++++ .agents/skills/mex-relay/agents/openai.yaml | 4 + .../mex-relay/references/cli-workflows.md | 88 +++++++++++++++++++ .mex/.gitignore | 3 + .mex/AGENTS.md | 25 ++++++ .mex/ROUTER.md | 22 +++++ .mex/SETUP.md | 3 + .mex/SYNC.md | 3 + .mex/config.json | 15 ++++ .mex/context/architecture.md | 18 ++++ .mex/context/conventions.md | 16 ++++ .mex/context/decisions.md | 18 ++++ .mex/context/operations.md | 20 +++++ .mex/context/setup.md | 16 ++++ .mex/context/stack.md | 10 +++ .mex/context/webui.md | 18 ++++ .mex/events/operations.jsonl | 10 +++ .mex/patterns/INDEX.md | 6 ++ .mex/patterns/README.md | 3 + .mex/patterns/configuration-change.md | 16 ++++ .mex/patterns/webui-editor-change.md | 16 ++++ AGENTS.md | 12 +++ 27 files changed, 537 insertions(+) create mode 100644 .agents/skills/mex-inbox/.mex-managed.json create mode 100644 .agents/skills/mex-inbox/SKILL.md create mode 100644 .agents/skills/mex-inbox/agents/openai.yaml create mode 100644 .agents/skills/mex-inbox/references/cli-workflows.md create mode 100644 .agents/skills/mex-relay/.mex-managed.json create mode 100644 .agents/skills/mex-relay/SKILL.md create mode 100644 .agents/skills/mex-relay/agents/openai.yaml create mode 100644 .agents/skills/mex-relay/references/cli-workflows.md create mode 100644 .mex/.gitignore create mode 100644 .mex/AGENTS.md create mode 100644 .mex/ROUTER.md create mode 100644 .mex/SETUP.md create mode 100644 .mex/SYNC.md create mode 100644 .mex/config.json create mode 100644 .mex/context/architecture.md create mode 100644 .mex/context/conventions.md create mode 100644 .mex/context/decisions.md create mode 100644 .mex/context/operations.md create mode 100644 .mex/context/setup.md create mode 100644 .mex/context/stack.md create mode 100644 .mex/context/webui.md create mode 100644 .mex/events/operations.jsonl create mode 100644 .mex/patterns/INDEX.md create mode 100644 .mex/patterns/README.md create mode 100644 .mex/patterns/configuration-change.md create mode 100644 .mex/patterns/webui-editor-change.md diff --git a/.agents/skills/mex-inbox/.mex-managed.json b/.agents/skills/mex-inbox/.mex-managed.json new file mode 100644 index 0000000..64a7433 --- /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 0000000..7ddb707 --- /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 0000000..de50723 --- /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 0000000..c0f9215 --- /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 0000000..20ae02b --- /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 0000000..1593561 --- /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 0000000..9b0e781 --- /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 0000000..89f8122 --- /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 0000000..a2ec937 --- /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 0000000..d5fe254 --- /dev/null +++ b/.mex/AGENTS.md @@ -0,0 +1,25 @@ +--- +name: agents +description: VotingPlugin Control project memory and authority guide. +last_updated: 2026-09-20 +--- + +# VotingPlugin Control memory + +Control is the optional management service for VotingPlugin nodes. Root `AGENTS.md` and `docs/control-management.md` own engineering rules and formal behavior. + +## Authority + +Use current code and tests for current behavior; root `AGENTS.md` and formal contracts/docs for intended rules; reviewed MEX knowledge for rationale and pitfalls; historical Relays for background only. If MEX disagrees with higher-authority evidence, follow that evidence, flag stale memory, and correct or propose a correction through MEX. + +Query MEX when architecture, prior decisions, or known failure modes may help, then inspect current implementation. Skip trivial tasks. MEX's JavaScript graph can assist with WebUI source, but does not prove Java behavior; verify Java directly. + +Use `$mex-inbox` for reviewable durable discoveries, not logs or duplicated rules. Use `$mex-relay` for unfinished substantial work with evidence, blockers, tests, and next actions. Read `ROUTER.md` for task-specific context. + + +## 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 0000000..f8d1d9b --- /dev/null +++ b/.mex/ROUTER.md @@ -0,0 +1,22 @@ +--- +name: router +description: Relevant Control architecture and failure-mode memory. +edges: + - target: patterns/configuration-change.md + condition: when changing configuration operations + - target: patterns/webui-editor-change.md + condition: when changing browser editor state +last_updated: 2026-09-20 +--- + +# Control memory routes + +| Task | Read | +| --- | --- | +| Overall boundary and peer contract | `context/architecture.md` | +| Configuration or revisions | `context/operations.md`, `patterns/configuration-change.md` | +| WebUI state | `context/webui.md` | +| Authentication or persistence | `context/decisions.md` | +| Runtime/build details | `context/stack.md`, `context/setup.md` | + +Load only relevant memory, then verify current Java or JavaScript source, tests, and formal docs. Root `AGENTS.md` remains the workflow guide. diff --git a/.mex/SETUP.md b/.mex/SETUP.md new file mode 100644 index 0000000..2b716a5 --- /dev/null +++ b/.mex/SETUP.md @@ -0,0 +1,3 @@ +# Control MEX setup + +Codex integration uses the official MEX Inbox and Relay skills. This repository's JavaScript WebUI can be navigated with MEX Code Graph; Java server code requires direct inspection. Use `ROUTER.md` for relevant context. No Hub is required for local CLI use. diff --git a/.mex/SYNC.md b/.mex/SYNC.md new file mode 100644 index 0000000..9966839 --- /dev/null +++ b/.mex/SYNC.md @@ -0,0 +1,3 @@ +# Keep Control memory current + +Follow the hierarchy in `.mex/AGENTS.md`. Compare claims with current Java/JavaScript source, tests, and formal contracts. Correct stale entries through a reviewed MEX edit or Inbox proposal. Rebuild the Wiki index after authored changes; do not regenerate generic scaffold prose. diff --git a/.mex/config.json b/.mex/config.json new file mode 100644 index 0000000..4cf71af --- /dev/null +++ b/.mex/config.json @@ -0,0 +1,15 @@ +{ + "setupMode": "code-repo", + "aiTools": [ + "codex" + ], + "scaffold_id": "a507f3b6-f699-469a-a862-5a3b80a0af5f", + "scaffold_name": "VotingPlugin-Control", + "origin": null, + "upstream": null, + "graph": { + "ignore": [ + "target/**" + ] + } +} diff --git a/.mex/context/architecture.md b/.mex/context/architecture.md new file mode 100644 index 0000000..c5d2793 --- /dev/null +++ b/.mex/context/architecture.md @@ -0,0 +1,18 @@ +--- +name: architecture +description: Control and node responsibility boundaries. +triggers: [architecture, connector, enrollment, hosted] +last_updated: 2026-09-20 +mex: + id: mx_01M3074CECX8T3QW4PR0QH6THT + type: architecture + status: promoted + revision: 1 + title: architecture +--- + +# Control boundaries + +Control is a separate service: browsers and automation call its HTTP API, while node connectors initiate outbound requests and pull tasks. Capability acceptance, node session, and task attempt form the compatibility boundary; an older or offline node cannot be treated as a successful participant. VotingPlugin remains usable when Control is absent. Source: root `AGENTS.md`, `docs/control-management.md`, `src/main/java/com/bencodez/votingplugin/control/domain/ConfigurationOperations.java`. + +The WebUI is a dependency-free JavaScript client over the same API. Its graph symbols may help locate client state, but server authorization and durable operation rules live in Java and formal contracts. Hosted Control is supervised by VotingPlugin, but a child process health result does not make Control part of the vote path. Source: `README.md`, `src/main/resources/web/app.js`, root `AGENTS.md`. diff --git a/.mex/context/conventions.md b/.mex/context/conventions.md new file mode 100644 index 0000000..2c1ba9e --- /dev/null +++ b/.mex/context/conventions.md @@ -0,0 +1,16 @@ +--- +name: conventions +description: Pointers to formal Control rules. +triggers: [convention, review] +last_updated: 2026-09-20 +mex: + id: mx_01M3074CG0WGZQBQZKQ4NJAEYF + type: convention + status: promoted + revision: 1 + title: conventions +--- + +# Where rules live + +Root `AGENTS.md` defines safety, tests, and paired protocol workflow. `docs/control-management.md` documents the management contract; VotingPlugin's control-agent contract is the paired node contract. MEX records rationale and failure modes, not a second checklist. diff --git a/.mex/context/decisions.md b/.mex/context/decisions.md new file mode 100644 index 0000000..1e62dc3 --- /dev/null +++ b/.mex/context/decisions.md @@ -0,0 +1,18 @@ +--- +name: decisions +description: Reasons for Control trust and persistence boundaries. +triggers: [decision, security, credential, audit] +last_updated: 2026-09-20 +mex: + id: mx_01M307CW4VJ4K40DCAZPSX9D9K + type: decision + status: promoted + revision: 1 + title: Control trust and persistence decisions +--- + +# Trust and persistence decisions + +Node credentials are bound to exact node IDs; browser sessions and API automation use distinct authentication. A node's advertised capability is insufficient until Control accepts it. Keep secrets and proposed content out of journals/audit; operation history is deliberately less detailed than live results. Source: `README.md`, root `AGENTS.md`, `docs/control-management.md`. + +Configuration snapshots store redacted content with restricted access. The audit log stores bounded metadata and is hash-chained; it is not a configuration-value store. An interrupted operation becomes history-only after restart. These limits reduce secret exposure and prevent stale work from being resumed as if its approval were still live. Source: `src/main/java/com/bencodez/votingplugin/control/domain/ConfigurationSnapshots.java`, `src/main/java/com/bencodez/votingplugin/control/domain/ConfigurationAuditLog.java`, `src/main/java/com/bencodez/votingplugin/control/domain/ConfigurationOperationJournal.java`. diff --git a/.mex/context/operations.md b/.mex/context/operations.md new file mode 100644 index 0000000..1dc9ada --- /dev/null +++ b/.mex/context/operations.md @@ -0,0 +1,20 @@ +--- +name: operations +description: Configuration approval, retry, and partial-result rationale. +triggers: [apply, preview, read, rollback, connector] +last_updated: 2026-09-20 +mex: + id: mx_01M307CW4V7HCFFWZXWT6BXB1N + type: constraint + status: promoted + revision: 1 + title: Configuration operation constraints +--- + +# Configuration operation traps + +READ and PREVIEW are separate from a one-time APPLY approval. Control sends each successful preview's expected node revision with APPLY; the paired VotingPlugin node contract requires rejecting a stale revision. A multi-node operation can contain mixed successes and failures; retrying READ or APPLY targets failed nodes, while a PREVIEW retry needs all original targets and a new approval. A coordinated proxy-method apply needs a new preview because topology may change. Source: `docs/control-management.md` configuration workflow and `src/main/java/com/bencodez/votingplugin/control/domain/ConfigurationOperations.java`. + +Nodes pull leased tasks and return the exact claiming session and attempt. Control's operation journal keeps redacted history across restart, but recovered operations are history-only; recovery does not resume in-flight work. A successful node APPLY must not be repeated just to make a mixed operation look uniform. Source: root `AGENTS.md`, `src/main/java/com/bencodez/votingplugin/control/domain/ConfigurationOperationJournal.java`, `src/test/java/com/bencodez/votingplugin/control/domain/ConfigurationOperationsTest.java`. + +Node-side YAML staging, reload, and rollback are implemented in VotingPlugin. The paired contract there is authoritative for exact node behavior; this repository must preserve the received reload/rollback result rather than infer success from a write response. Source: `docs/control-management.md`, root `AGENTS.md`. diff --git a/.mex/context/setup.md b/.mex/context/setup.md new file mode 100644 index 0000000..8ebb5d3 --- /dev/null +++ b/.mex/context/setup.md @@ -0,0 +1,16 @@ +--- +name: setup +description: MEX use in Control. +triggers: [setup, MEX, graph] +last_updated: 2026-09-20 +mex: + id: mx_01M3074CGEETPW0E69BMX0TV7G + type: guide + status: promoted + revision: 1 + title: setup +--- + +# Local MEX use + +The reviewed Wiki provides architecture and failure context. MEX Code Graph may help navigate JavaScript WebUI functions; Java server claims require source and tests. After memory edits run `mex wiki rebuild-index` and `mex check`. No Hub or external listener is needed for CLI use. diff --git a/.mex/context/stack.md b/.mex/context/stack.md new file mode 100644 index 0000000..505b3dd --- /dev/null +++ b/.mex/context/stack.md @@ -0,0 +1,10 @@ +--- +name: stack +description: Control implementation boundaries. +triggers: [Java, JavaScript, Maven, graph] +last_updated: 2026-09-20 +--- + +# Implementation boundary + +Control is Java 17 with a dependency-free browser client in `src/main/resources/web/app.js`. CI uses `mvn -B clean verify`; root `AGENTS.md` owns full validation details. MEX 0.8.2 can index JavaScript WebUI symbols here but not Java classes, so inspect Java source and tests directly. Source: `pom.xml`, `.github/workflows/maven.yml`, root `AGENTS.md`. diff --git a/.mex/context/webui.md b/.mex/context/webui.md new file mode 100644 index 0000000..fc56cde --- /dev/null +++ b/.mex/context/webui.md @@ -0,0 +1,18 @@ +--- +name: webui +description: Browser state distinctions that affect safe editing. +triggers: [webui, browser, draft, revision] +last_updated: 2026-09-20 +mex: + id: mx_01M307CW4VZSFJ5KKNS6EFNFEB + type: component + status: promoted + revision: 1 + title: WebUI state boundaries +--- + +# WebUI state traps + +For managed files, content presence is independent of string length: a successful empty read or snapshot restore is a valid editor value and can be previewed. Authentication, node, session, or file changes invalidate the applicable editor/approval state, but a file selection or capability change does not necessarily purge the node/session/file-keyed short-lived read cache. PREVIEW still checks a live revision. Dirty drafts require explicit handling when context changes. Source: root `AGENTS.md`, `src/main/resources/web/app.js` (`configurationContentPresent`, `applyAuthenticatedSession`, `updateConfigurationButtons`). + +Browser profiles are local convenience input and do not approve or apply. Snapshots contain redacted read output, not old credentials; restoring one still goes through live preview and single-use approval. Source: `docs/control-management.md`, `src/main/java/com/bencodez/votingplugin/control/domain/ConfigurationSnapshots.java`. diff --git a/.mex/events/operations.jsonl b/.mex/events/operations.jsonl new file mode 100644 index 0000000..a3fbf06 --- /dev/null +++ b/.mex/events/operations.jsonl @@ -0,0 +1,10 @@ +{"v":1,"phase":"intent","opId":"mig_04bdfe68d2f7f9f793ced12eadc3a4027c0b5a64","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CECX8T3QW4PR0QH6THT"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/architecture.md"],"payloadHash":"60e9cb3b8cf14fc598ca64e965b4e9a2e20ef743ac37abc02e2c86cc48103ff5","revisions":[{"entityId":"mx_01M3074CECX8T3QW4PR0QH6THT","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_04bdfe68d2f7f9f793ced12eadc3a4027c0b5a64","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CECX8T3QW4PR0QH6THT"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/architecture.md"],"payloadHash":"60e9cb3b8cf14fc598ca64e965b4e9a2e20ef743ac37abc02e2c86cc48103ff5","revisions":[{"entityId":"mx_01M3074CECX8T3QW4PR0QH6THT","before":0,"after":1}]} +{"v":1,"phase":"intent","opId":"mig_bba7e40030721976170be1e0e46673406f16555f","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CG0WGZQBQZKQ4NJAEYF"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/conventions.md"],"payloadHash":"dea0802d2c6208b2f103f615a1a322ba63f9a35dbddbe82d49988f8ed41f86ae","revisions":[{"entityId":"mx_01M3074CG0WGZQBQZKQ4NJAEYF","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_bba7e40030721976170be1e0e46673406f16555f","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CG0WGZQBQZKQ4NJAEYF"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/conventions.md"],"payloadHash":"dea0802d2c6208b2f103f615a1a322ba63f9a35dbddbe82d49988f8ed41f86ae","revisions":[{"entityId":"mx_01M3074CG0WGZQBQZKQ4NJAEYF","before":0,"after":1}]} +{"v":1,"phase":"intent","opId":"mig_8dba03310a5302a413a7df38e88f6c2de16bc1e0","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CGEETPW0E69BMX0TV7G"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/setup.md"],"payloadHash":"cf355dba2ffc569444242ee5b2fce6dd91e95d47beb012e590e6b8893c2314a4","revisions":[{"entityId":"mx_01M3074CGEETPW0E69BMX0TV7G","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_8dba03310a5302a413a7df38e88f6c2de16bc1e0","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CGEETPW0E69BMX0TV7G"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["context/setup.md"],"payloadHash":"cf355dba2ffc569444242ee5b2fce6dd91e95d47beb012e590e6b8893c2314a4","revisions":[{"entityId":"mx_01M3074CGEETPW0E69BMX0TV7G","before":0,"after":1}]} +{"v":1,"phase":"intent","opId":"mig_ee84a38b2e731ea1288308d571ee620124959808","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CGVDHTY7AZFPZT703VB"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/configuration-change.md"],"payloadHash":"fbf66ad4fe2728cfb515f9bfe00d1aaf6c5465ec921054041f349b002bc9a527","revisions":[{"entityId":"mx_01M3074CGVDHTY7AZFPZT703VB","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_ee84a38b2e731ea1288308d571ee620124959808","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CGVDHTY7AZFPZT703VB"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/configuration-change.md"],"payloadHash":"fbf66ad4fe2728cfb515f9bfe00d1aaf6c5465ec921054041f349b002bc9a527","revisions":[{"entityId":"mx_01M3074CGVDHTY7AZFPZT703VB","before":0,"after":1}]} +{"v":1,"phase":"intent","opId":"mig_2b40e7565a48421d3fae634a9208d2294ef455a9","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CH83ZX5G15W4J13AWC0"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/webui-editor-change.md"],"payloadHash":"77b9918e7a97e5a33770044f42eb0444d06df1d58568de5952c27bd9ff51a48a","revisions":[{"entityId":"mx_01M3074CH83ZX5G15W4J13AWC0","before":0,"after":1}]} +{"v":1,"phase":"complete","opId":"mig_2b40e7565a48421d3fae634a9208d2294ef455a9","type":"create-entry","entityIds":[],"createdIds":["mx_01M3074CH83ZX5G15W4J13AWC0"],"actor":{"kind":"system","id":"mex-migration"},"timestamp":"2026-01-01T00:00:00.000Z","files":["patterns/webui-editor-change.md"],"payloadHash":"77b9918e7a97e5a33770044f42eb0444d06df1d58568de5952c27bd9ff51a48a","revisions":[{"entityId":"mx_01M3074CH83ZX5G15W4J13AWC0","before":0,"after":1}]} diff --git a/.mex/patterns/INDEX.md b/.mex/patterns/INDEX.md new file mode 100644 index 0000000..a6d277f --- /dev/null +++ b/.mex/patterns/INDEX.md @@ -0,0 +1,6 @@ +# Control patterns + +| Pattern | When useful | +| --- | --- | +| [configuration-change.md](configuration-change.md) | Changing READ/PREVIEW/APPLY, retries, or revisions | +| [webui-editor-change.md](webui-editor-change.md) | Changing browser editor or approval state | diff --git a/.mex/patterns/README.md b/.mex/patterns/README.md new file mode 100644 index 0000000..453b5fd --- /dev/null +++ b/.mex/patterns/README.md @@ -0,0 +1,3 @@ +# Control patterns + +These pages preserve task-specific failure modes. Root `AGENTS.md` and formal docs own general workflow. Check pattern claims against current code and tests before use. diff --git a/.mex/patterns/configuration-change.md b/.mex/patterns/configuration-change.md new file mode 100644 index 0000000..d90b1ff --- /dev/null +++ b/.mex/patterns/configuration-change.md @@ -0,0 +1,16 @@ +--- +name: configuration-change +description: Preserve revision-bound, one-time configuration approval and mixed-node semantics. +triggers: [apply, preview, rollback, connector] +last_updated: 2026-09-20 +mex: + id: mx_01M3074CGVDHTY7AZFPZT703VB + type: pattern + status: promoted + revision: 1 + title: configuration-change +--- + +# Configuration change + +Trace Control's operation state, HTTP boundary, node result, and the paired VotingPlugin contract. Check the lost-acknowledgement and mixed-node paths: a successful APPLY is not repeated, a failed target can be retried, and a new PREVIEW requires every original target. Recovered journal entries are history-only. See `context/operations.md` and `src/test/java/com/bencodez/votingplugin/control/domain/ConfigurationOperationsTest.java`. diff --git a/.mex/patterns/webui-editor-change.md b/.mex/patterns/webui-editor-change.md new file mode 100644 index 0000000..3cb6526 --- /dev/null +++ b/.mex/patterns/webui-editor-change.md @@ -0,0 +1,16 @@ +--- +name: webui-editor-change +description: Preserve file content presence and approval invalidation in the browser. +triggers: [webui, editor, empty file, approval] +last_updated: 2026-09-20 +mex: + id: mx_01M3074CH83ZX5G15W4J13AWC0 + type: pattern + status: promoted + revision: 1 + title: webui-editor-change +--- + +# WebUI editor change + +A successful empty file is present content, not a missing read. Trace generation counters, selected node/session/file, dirty draft, and approval invalidation together. A cached read may populate the editor, but PREVIEW still checks the live revision. See `context/webui.md`, `src/main/resources/web/app.js`, and the browser fixtures under `src/test/`. diff --git a/AGENTS.md b/AGENTS.md index 3ee3338..ced5965 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -175,3 +175,15 @@ new Control behavior in production. packet-level or command-by-command delivery trace. - A **diagnostics bundle** is the bounded, redacted inspection result assembled by the WebUI. It deliberately omits raw configuration, logs, player records, credentials, and infrastructure connection details. + + +## 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. + From ad9f42071eea9514409b71395149f1564a689e4e Mon Sep 17 00:00:00 2001 From: BenCodez <17074231+BenCodez@users.noreply.github.com> Date: Sun, 20 Sep 2026 15:08:05 -0600 Subject: [PATCH 2/2] docs: use Inbox-compatible MEX kinds --- .mex/context/operations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.mex/context/operations.md b/.mex/context/operations.md index 1dc9ada..f354814 100644 --- a/.mex/context/operations.md +++ b/.mex/context/operations.md @@ -5,7 +5,7 @@ triggers: [apply, preview, read, rollback, connector] last_updated: 2026-09-20 mex: id: mx_01M307CW4V7HCFFWZXWT6BXB1N - type: constraint + type: component status: promoted revision: 1 title: Configuration operation constraints