@mutmutco/codex-plugin 4.3.46 → 4.3.48

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mmi",
-  "version": "4.3.46",
+  "version": "4.3.48",
   "mmiCompat": "4.x",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mutmutco/codex-plugin",
-  "version": "4.3.46",
+  "version": "4.3.48",
   "description": "MMI workflow skills and org gates delivery.",
   "author": {
     "name": "MMI Future",

package/skills/org-guide/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: org-guide
-description: Read MMI org rules before project work; load only the topic needed.
+description: Read org rules for project work and reporting MMI CLI, plugin, or workflow bugs.
 ---
 
 # MMI organization guide
@@ -19,6 +19,9 @@ the [MMI help skill](../mmi-help/SKILL.md).
   Do not commit AGENTS.md, CLAUDE.md, or copied plugin instructions.
 - Claim approved work through the board, use the repository's checks, and land through MMI.
   A request for help or a plan does not authorize a change or a production release.
+- When an MMI tooling bug affects a developer other than `jervaise`, ask before filing a Hub report.
+  Respect a decline. Follow [Work and releases](references/work-and-releases.md#report-mmi-tooling-bugs)
+  for consent, duplicate handling, and optional released-fix Slack notifications.
 - Read the registry for release tracks, domains, and OAuth configuration. Use MMI provisioning
   and release workflows rather than inventing parallel deployment or credential paths.
 
@@ -27,6 +30,7 @@ the [MMI help skill](../mmi-help/SKILL.md).
 | Task | Local reference |
 | --- | --- |
 | Install, update, reload, or diagnose tooling | [Getting started](references/getting-started.md) |
+| Report an MMI tooling bug with developer consent | [Tooling bug reports](references/work-and-releases.md#report-mmi-tooling-bugs) |
 | Work an issue, test, merge, or release | [Work and releases](references/work-and-releases.md) |
 | Consume, declare, rotate, or request a secret | [Vault and keyless access](references/vault.md) |
 | Register domains or configure Google OAuth | [Domains and OAuth](references/domains-and-oauth.md) |

package/skills/org-guide/references/work-and-releases.md

@@ -18,6 +18,47 @@ Open a PR through `mmi-cli devops pr create` with a closing issue link, and land
 `mmi-cli devops pr land`. Verify required checks, merge, issue closure, and cleanup before calling
 the implementation complete. A merged implementation is not a production release.
 
+## Report MMI tooling bugs
+
+This workflow covers bugs in MMI tooling, including its CLI, plugin, and shared workflows.
+Product bugs stay with their product; do not automatically file them on the Hub board.
+For every developer other than authenticated GitHub login `jervaise`, ask for consent before
+filing a tooling bug through `mmi-cli learning report`. Do not infer identity from a display name
+or Slack email. The owner exemption skips this consent workflow and its released-fix DMs.
+
+Show a safe summary, affected MMI version, and minimal reproduction. Explain that approval files
+or attaches the report to an existing Hub issue and notifies Jervaise through the MMI-Future Slack app.
+Wait for explicit approval; a decline means no
+report, no alternate filing command, and no repeated consent prompt for the same incident.
+Remove secrets and private data from the title, reproduction, and logs before sending anything.
+Write the approved report body to a UTF-8 file; never put it in command arguments.
+
+Use `mmi-cli learning report --type bug --title "<safe summary>" --body-file <path>`.
+Let the existing report command handle duplicates; reuse its returned issue and never add
+`--force` to bypass matching or file another issue for the same incident. Do not claim or poll
+the issue; the Hub team owns the fix.
+
+On the first approved report without a saved Slack destination, ask once whether the developer
+wants a DM when the fix is released. If they agree, ask them to confirm their Slack workspace
+email and append `--slack-email <confirmed-email>`. This email is a notification destination,
+not verified identity or authorization. Never guess it from GitHub profile data, use another
+person's address, or include it in the public issue body. The Hub stores the confirmed email privately
+until scheduled Slack lookup succeeds, then replaces it with the Slack user ID for later reports.
+Declining notifications does not prevent filing the approved bug report.
+
+Read the returned `notification.status`: `tracked` means the released-fix notification is
+registered for scheduled processing, not delivered, `needs-slack-email` means no saved destination
+was found, `unavailable` means the
+issue was filed but notification registration failed, and `owner-excluded` means no owner DM.
+If `needs-slack-email` follows a report where the notification question was not yet asked, ask
+once; use the same report with the confirmed email so dedup retains its issue. Never retry an
+ambiguous report submission. Do not claim a DM is registered when the status is unavailable,
+and do not replay a valid report merely to repair notification failure. Unresolved Slack
+lookup remains pending in the notification record; it must not use an old destination.
+The MMI-Future app sends a fix DM only after the issue's closing merge is included in a stable
+Hub release whose publication and deployment both succeeded. Closing an issue alone is not enough.
+An uncertain Slack send is recorded for operator review and never replayed automatically.
+
 ## Choose the declared train
 
 Read `mmi-cli oracle org project get <owner/repo> --json` and `mmi-cli status` for the resolved track.