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.