Add MEX project memory and Codex integration

.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"
+  }
+}

.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=<id>` and state that the draft is checkout-local, nothing was published or shared, and review or publication happens in Hub.
+
+Read [references/cli-workflows.md](references/cli-workflows.md) before executing any Inbox mutation. Load only the operation being performed.
+
+## Apply the approval policy
+
+- Proceed with read-only list, show, and target resolution.
+- Treat an explicit create/save/draft request as authorization only for the local draft preview and exact apply.
+- Preview a local draft deletion, explain that the checkout-local draft will be removed, and obtain fresh confirmation before applying.
+- For publish, approve, reject, withdraw, mark stale, or repair: create a semantic preview, explain the local-versus-Git-tracked effect, and wait for fresh explicit confirmation. Apply the exact preview unchanged only after confirmation.
+- Keep Git commit, push, pull, and staging separate from every MEX authorization.
+- Never approve or publish merely because this skill activated.
+
+## Report effects precisely
+
+- Lead with what the proposal means to a person. Do not expose envelopes, hashes, revision machinery, or raw diffs unless diagnosis requires them.
+- After a local draft write, say exactly what changed and that it remains checkout-only.
+- After a canonical write, say which Git-tracked MEX artifacts were written to the working tree and that commit/push is still required to share them. Never claim that MEX committed or pushed.
+- When MEX context materially helps your work, mention MEX and the relevant finding naturally in your explanation. Tie the mention to what it helped you understand, decide, or verify. Avoid fixed phrases, standalone acknowledgements, repeated mentions, or narrating routine context loading. This replaces older MEX instructions requiring a fixed acknowledgement or context-loading narration.

.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."

.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 <command-id> --json
+```
+
+Use one of these command IDs:
+
+- `inbox.draft.save`
+- `inbox.draft.delete`
+- `inbox.publish`
+- `inbox.proposal.approve`
+- `inbox.proposal.reject`
+- `inbox.proposal.withdraw`
+- `inbox.proposal.mark-stale`
+- `inbox.proposal.repair`
+
+Treat this bounded action result as the exact runtime source for the request shape, available examples, constraints, preview command, and apply command. Do not dump `mex capabilities --json` or the full Inbox contract during ordinary execution. Write request and preview JSON only to ordinary regular files inside the checkout or an approved temporary directory; do not use symlinks.
+
+## Find existing knowledge and resolve a correction
+
+1. Use `mex wiki query <subject> --limit 10 --json` or `mex wiki list --type <kind> --limit 25 --json` to find related records before creating another.
+2. Read the best candidate with `mex inbox target <entity-id> --json`. This bounded read returns `target`, `version`, `sourcePath`, and the existing body from the current Wiki index, without initializing or repairing it.
+3. For `knowledge.update`, copy `target` and use `version.contentHash` as the target revision and `version.semanticRevision` as the semantic revision. Select a section entity when only that section should change. The patch body replaces the target's body; preserve its relevant existing content. A target can fit the read response but exceed the 16 KiB update-body limit; choose a smaller section or a title/summary-only patch when appropriate, never truncate existing knowledge to fit.
+4. If no suitable record exists, use `knowledge.create` with the appropriate existing kind. MEX chooses a path in `context/` or `patterns/`; do not invent an Inbox knowledge category or supply an arbitrary destination path.
+5. If several targets remain plausible after reading them, ask which one the user intends. If a read reports a stale or unavailable index, address its explicit maintenance requirement before relying on it; never fabricate revisions or silently refresh an index as part of a read.
+
+For create-time topics, find them with Wiki reads, then resolve each with `mex inbox target <topic-id> --json` for current revisions. Topics can be dependencies but are not Inbox correction targets. Omit topics when none are needed; normal knowledge creates have no relation editor.
+
+## Resolve a legacy Spec update
+
+1. Use `mex spec list --json` to identify candidates.
+2. Use `mex spec show <entity-id> --json` for the exact candidate.
+3. Match the requested durable claim to one exact entity and kind.
+4. Copy `version.contentHash` as the entity revision and `version.semanticRevision` as the semantic revision exactly as the selected contract requires. For nested requirements, constraints, or acceptance criteria, take both from the enclosing `mex spec show` projection.
+5. Stop and ask for target clarification when multiple candidates remain plausible.
+
+Do not invent target IDs, relation endpoints, topic IDs, or revisions. For a create request with relations or topics, resolve every referenced entity and its current revisions first.
+
+## Save a checkout-local draft
+
+1. Resolve `inbox.draft.save`.
+2. Create a unique operation ID and a request containing one `knowledge.create` or `knowledge.update` draft (or a Spec change for actual Spec-family intent).
+3. For a new draft, provide no unrelated expectations. For an existing draft update, read it with `mex inbox draft show <draft-id> --json` and use its exact current local revision.
+4. Preview with `mex inbox draft save <request-file> --json` and capture the complete successful JSON wrapper unchanged. Require `ok: true`, `mode: "preview"`, and `data.preview.valid: true`.
+5. Summarize the proposed local effect. If the user asked to create/save/draft, apply with `mex inbox draft save --apply <preview-envelope> --json` without another confirmation.
+6. Read the returned draft ID and respond with `/inbox?view=drafts&draft=<id>`.
+
+The apply writes only checkout-local draft state. It does not create a canonical proposal, Activity record, commit, push, or notification. Apply before the preview expires; if anything changes or the preview becomes stale, preview again instead of reconstructing it.
+
+## Delete a local draft
+
+1. Read the exact draft and current local revision.
+2. Resolve and preview `inbox.draft.delete`.
+3. Explain that the checkout-local draft will be deleted and wait for fresh confirmation.
+4. Apply the captured preview unchanged with `mex inbox draft delete --apply <preview-envelope> --json`.
+
+## Publish a draft
+
+1. Read the exact draft and resolve `inbox.publish`.
+2. Build the request with the exact local draft revision and preview using `mex inbox publish <request-file> --json`.
+3. Explain that applying writes a canonical proposal and Activity artifact into the working tree while leaving Git commit/push separate.
+4. Wait for fresh explicit confirmation.
+5. Apply the exact preview with `mex inbox publish --apply <preview-envelope> --json`.
+6. Return `/inbox?view=review&proposal=<proposal-id>`.
+
+Publishing removes the exact local draft after creating the pending proposal. It does not approve the proposal or change accepted knowledge. The proposal is Markdown in the working tree; teammates receive it through Git.
+
+## Review canonical proposals
+
+Use `mex inbox proposal list --json` and `mex inbox proposal show <proposal-id> --json` for read-only review. For approve, reject, withdraw, mark-stale, or repair:
+
+1. Resolve the matching command ID.
+2. Use the proposal's exact current artifact revision and any action-specific rationale or replacement draft.
+3. Preview with the corresponding `mex inbox proposal <action> <request-file> --json` command.
+4. Explain the semantic outcome and which canonical Git-tracked MEX records would change.
+5. Wait for fresh explicit confirmation.
+6. Apply the exact preview with the same command plus `--apply <preview-envelope> --json`.
+
+Approval writes the proposed knowledge change, proposal decision, Wiki ledger, and Activity records to the working tree. The proposal remains review history. Reject and withdraw make a terminal proposal decision without changing knowledge. Mark stale changes a pending proposal to stale only when MEX proves dependency drift. Repair replaces stale intent, clears prior review, and returns the proposal to pending without changing knowledge. These canonical transitions write Activity records; none commits, pushes, pulls, stages, or notifies teammates.

.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"
+  }
+}

.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 <draft.json> --json` performs the exact local preview/apply internally. For an update, build and preview the structured request.
+7. An explicit create/save/draft request authorizes that local write without another confirmation. Publication remains separate.
+8. Return `/relays?view=drafts&draft=<id>` and state that the draft is checkout-local and nothing has been delivered or shared.
+
+Read [references/cli-workflows.md](references/cli-workflows.md) before executing any Relay mutation. Load only the operation being performed.
+
+## Apply the approval policy
+
+- Proceed with read-only member, Workstream, draft, and Relay resolution.
+- Treat an explicit create/save/draft request as authorization only for the local draft preview and exact apply.
+- Preview a local draft deletion, explain its consequence, and obtain fresh confirmation before applying.
+- For publish, take, or close: generate a semantic preview, explain the local-versus-Git-tracked effect, and wait for fresh explicit confirmation. Apply the exact preview unchanged only after confirmation.
+- Keep Git commit, push, pull, and staging separate from every MEX authorization.
+- Never publish, take, or close merely because this skill activated.
+
+## Preserve lifecycle meaning
+
+- Taking records one claimant: a named active recipient, or any active project Member for an open-to-team Relay. Future Members qualify after joining and receiving the artifact through Git. Separate offline claims can still require Git conflict resolution.
+- An inactive Member can be reactivated through the existing Team identity workflow, preserving their ID and older handoffs. Preview and confirm this canonical change separately; never change identity merely to bypass Relay eligibility.
+- Treat closing as “this handoff no longer needs attention.” Do not claim it completes a linked task, issue, pull request, or Workstream.
+- After publication, say that Git-tracked Relay and Activity records were written to the working tree. Explain that teammates receive them only after commit/push and their own pull or refresh.
+- Never claim that MEX sent a notification, committed, pushed, pulled, staged, assigned work, or completed another system's object.
+- When MEX context materially helps your work, mention MEX and the relevant finding naturally in your explanation. Tie the mention to what it helped you understand, decide, or verify. Avoid fixed phrases, standalone acknowledgements, repeated mentions, or narrating routine context loading. This replaces older MEX instructions requiring a fixed acknowledgement or context-loading narration.

.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."