Release MEX 0.8.1

.agents/skills/mex-inbox/.mex-managed.json

@@ -2,10 +2,10 @@
   "schemaVersion": 1,
   "owner": "mex-agent",
   "skill": "mex-inbox",
-  "packageVersion": "0.8.0",
+  "packageVersion": "0.8.1",
   "files": {
-    "SKILL.md": "ec0e61b45c9f2e2d70074bd613c0d294dd4d88ec73964e6187f0ac8d51de1505",
-    "agents/openai.yaml": "4dbdf205a76ba17d9fd8984c8d546b1d6628f0e135bbaf0c16c773f8fa6fc765",
-    "references/cli-workflows.md": "5147aa68c8fea7a96dd5c569c23570238e2a32a46655fd14267e31a7c5d12c30"
+    "SKILL.md": "39cf595ac48203bf49ea2e273ea1c1c25e7ebbf4616c68596cd8e1c08eaf2738",
+    "agents/openai.yaml": "12a2827fe257c303d926122e4bb590910abd660e6451550a1db68a48037b4402",
+    "references/cli-workflows.md": "6c91905cc69d8ea47080630ee1551bf1a61ec33605fff01463d4a2ad71f497c6"
   }
 }

.agents/skills/mex-inbox/SKILL.md

@@ -1,24 +1,24 @@
 ---
 name: mex-inbox
-description: Prepare and manage governed MEX Inbox proposals for durable Spec-family knowledge. Use when the user clearly asks to capture, create, save, or draft a MEX product Spec, requirement, constraint, acceptance criterion, or durable product-spec decision for team review, or explicitly invokes /mex-inbox or $mex-inbox. Do not use for email inboxes, generic notes, vague brainstorming, OpenAPI or test specs mentioned only by the word "spec," architecture pages, conventions, patterns, Workstreams, Relays, arbitrary Wiki pages, or generic memory.
+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
 
-Prepare governed Spec-memory proposals. Treat Inbox as a proposal workflow, not email and not a general Wiki mutation system.
+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 exactly one `spec.create` or `spec.update` change per draft.
-- Support only `spec`, `requirement`, `constraint`, and `acceptance_criterion` entities.
-- Reject unsupported durable knowledge honestly. Do not silently translate architecture, conventions, patterns, Workstreams, Relays, or arbitrary Wiki pages into Specs.
-- Require a clear durable claim. Do not capture unresolved brainstorming as team memory.
+- 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 the durable knowledge, rationale, and useful evidence from the conversation.
-2. Decide whether it creates a new Spec-family entity or updates an existing exact entity.
-3. For an update, resolve the canonical target and current revisions before drafting. Never guess an ID or revision.
+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.
@@ -41,4 +41,4 @@ Read [references/cli-workflows.md](references/cli-workflows.md) before executing
 - 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 affects the answer, add one concise acknowledgement: `MEX context used: <specific records/files/entities consulted>.`
+- 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

@@ -1,4 +1,4 @@
 interface:
   display_name: "MEX Inbox"
-  short_description: "Draft governed MEX Spec proposals"
-  default_prompt: "Use $mex-inbox to draft this durable requirement for MEX team review."
+  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

@@ -23,7 +23,17 @@ Use one of these command IDs:
 
 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.
 
-## Resolve a Spec update
+## 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.
@@ -36,7 +46,7 @@ Do not invent target IDs, relation endpoints, topic IDs, or revisions. For a cre
 ## Save a checkout-local draft
 
 1. Resolve `inbox.draft.save`.
-2. Create a unique operation ID and a request containing one `spec.create` or `spec.update` draft.
+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.
@@ -60,7 +70,7 @@ The apply writes only checkout-local draft state. It does not create a canonical
 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 write the requested Spec change.
+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
 
@@ -73,4 +83,4 @@ Use `mex inbox proposal list --json` and `mex inbox proposal show <proposal-id>
 5. Wait for fresh explicit confirmation.
 6. Apply the exact preview with the same command plus `--apply <preview-envelope> --json`.
 
-Approval writes the proposed Spec-family entity change, proposal decision, Wiki ledger, and Activity records to the working tree. Reject and withdraw make a terminal proposal decision without changing the Spec. 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 the Spec. These canonical transitions write Activity records; none commits, pushes, pulls, stages, or notifies teammates.
+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

@@ -2,10 +2,10 @@
   "schemaVersion": 1,
   "owner": "mex-agent",
   "skill": "mex-relay",
-  "packageVersion": "0.8.0",
+  "packageVersion": "0.8.1",
   "files": {
-    "SKILL.md": "70fa6eb782225f6357b0046ea9449e80095e6c01bc5e960886a2f60fad7e3f25",
+    "SKILL.md": "186d1d19c4b513f4b98ee27bf0259744d1ef79ffc758676484596cfe498aa502",
     "agents/openai.yaml": "9c2e9c2e34d60ec0f4d07089b07d9e49a6c8210c2a3e277593c15a2635f03076",
-    "references/cli-workflows.md": "98be305e6d941acdd5caa7697317c963343bb62ddcc25af8e129d0af1ea0aaa8"
+    "references/cli-workflows.md": "56b6e74129cdc6ddb5121480b03e01fd2f1f65b7b8c0b7899552a4a217d48cf5"
   }
 }

.agents/skills/mex-relay/SKILL.md

@@ -10,12 +10,12 @@ Prepare durable team handoffs that another engineer can continue from. Never rep
 ## 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. Resolve intended recipients against active MEX Members. Never fabricate member IDs.
-3. Default to a standalone Relay.
-4. Include a Workstream only when a real, relevant Workstream already exists. Preserve it as supported typed context; never invent one or turn Relay creation into Workstream creation.
+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. Build one request against the action-scoped runtime contract and run the exact preview.
-7. When the user already asked to create, save, or draft the handoff, apply that exact checkout-local draft preview without another confirmation.
+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.
@@ -31,8 +31,9 @@ Read [references/cli-workflows.md](references/cli-workflows.md) before executing
 
 ## Preserve lifecycle meaning
 
-- Treat taking as the explicit canonical acknowledge action by an intended recipient.
+- 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 affects the answer, add one concise acknowledgement: `MEX context used: <specific records/files/entities consulted>.`
+- 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.