@mutmutco/opencode-mmi 2.56.0 → 2.57.0

package/skills/release/SKILL.md

@@ -182,24 +182,20 @@ Rejected → stop (nothing released).
 
 ## Step 4 — GitHub Release + start prod deploy (non-blocking)
 
-For `tenant-container` repos, publish the GitHub Release, dispatch the central tenant deploy, and dispatch
-the release-scoped wiki refresh (release events never leave the releasing repo, so the keeper must be
-dispatched centrally — #759):
+For `tenant-container` repos, publish the GitHub Release and dispatch the central tenant deploy. Repo-owned
+wiki publication is a separate explicit step only when the release task asks for it or the user authorizes it.
 ```bash
 gh release create "vX.Y.0" --target main --generate-notes --latest
 gh workflow run tenant-deploy.yml --repo mutmutco/MMI-Hub \
   -f slug={slug} -f repo={owner}/{repo} -f ref=main -f stage=main
-gh workflow run cursor-agents.yml --repo mutmutco/MMI-Hub \
-  -f agent=wiki-keeper -f only_repo={owner}/{repo}   # wiki-keeper, scoped to the released repo
 gh run watch "$(gh run list --workflow tenant-deploy.yml --limit 1 --json databaseId -q '.[0].databaseId')" \
   --exit-status   # the central prod-deploy run — run this in the BACKGROUND (Bash run_in_background)
 ```
 
 For `hub-serverless` (MMI-Hub), publish the GitHub Release but do **not** dispatch `tenant-deploy.yml` or
-`cursor-agents.yml`: the release event auto-fires `deploy.yml` for prod, `publish.yml` for the plugin/CLI
-package, and `cursor-agents.yml` for the Hub-scoped wiki refresh. A missing `DEPLOY#main` registry row for
-MMI-Hub is expected, not a tenant stack repair task. Watch/report the release-triggered `deploy.yml` and
-`publish.yml` runs instead.
+repo wiki publication: the release event auto-fires `deploy.yml` for prod and `publish.yml` for the
+plugin/CLI package. A missing `DEPLOY#main` registry row for MMI-Hub is expected, not a tenant stack repair
+task. Watch/report the release-triggered `deploy.yml` and `publish.yml` runs instead.
 
 For other direct-track repos, the train dispatches nothing centrally: a `registry-publish` repo's release
 event fires its own `publish.yml` (npm / plugin marketplace); a `solo-container` repo deploys via its own

package/skills/stage/SKILL.md

@@ -62,7 +62,7 @@ All stage artifacts (build output, screenshots, Playwright traces, local DB file
 — never tracked.
 
 A local stage is bound to the worktree that started it. Concurrent worktrees on one machine each keep
-their own stage on separate ports — you do not need to stop one before starting another. Saga continuity
+their own stage on separate ports — you do not need to stop one before starting another. For `jervaise`, saga continuity
 keys on branch; use a distinct North Star slug per parallel grind or feature. Stage JSON/state records
 the starting `cwd` plus git branch/commit when available.
 

package/skills/overlord/references/codex-fugu-preflight.md

@@ -1,25 +0,0 @@
-# Codex/Fugu Preflight
-
-Before servant launch:
-
-- Detect `codex`.
-- Detect `codex-fugu`.
-- Check `codex --version`.
-- Check `codex-fugu --status`.
-- Detect stale deployed target after Codex update.
-- Detect missing API key by name only, unless local Codex auth evidence exists; never print values.
-- Detect missing `fugu-ultra`.
-- Detect native Windows Codex receiving Git Bash `/c/Users/...` paths.
-- Verify `--model fugu-ultra` launches the Ultra route.
-
-If Fugu is missing, stale, or misconfigured:
-
-- Print human-readable setup/update steps.
-- Preserve repair backup paths.
-- Do not launch partial servants.
-- Treat PowerShell-discoverable `.ps1`/`.cmd` wrappers as valid on Windows; Node subprocess probes may need the shell adapter to resolve them.
-
-Terminal compatibility warnings:
-
-- Treat `TERM=dumb` as a compatibility warning, not proof of Fugu failure.
-- Translate internal warnings into human-facing startup phases.

package/skills/overlord/references/opencode-fugu-engine.md

@@ -1,104 +0,0 @@
-# OpenCode Fugu engine
-
-OpenCode is the preferred Fugu engine when it is installed and exposes the required models.
-
-## Preflight
-
-Before servant launch, verify:
-
-- `opencode` is on PATH
-- `opencode --version` returns a version
-- `opencode models` lists `sakana/fugu` and `sakana/fugu-ultra`
-- `opencode run -m sakana/fugu --format json "ACK probe"` emits parseable JSON events
-- the event stream includes a session id, text, step start/finish, and a finish reason
-
-Fail closed if any required fact is missing.
-
-## Session-backed servants
-
-Start or resume servants through session ids.
-
-Use normal servants with:
-
-```text
-opencode run --session <session-id> -m sakana/fugu --format json <message>
-```
-
-Use the Ultra servant with:
-
-```text
-opencode run --session <session-id> -m sakana/fugu-ultra --format json <message>
-```
-
-Record these facts in the run registry:
-
-- `engine`
-- `provider`
-- `model`
-- `opencodeSessionId`
-- `opencodeVersion`
-- `eventJournalPath`
-- `lastEventAt`
-- `lastMessageCompletedAt`
-
-## Mailbox lifecycle
-
-A mailbox message is not complete when text is written.
-
-Track:
-
-- `queuedAt`
-- `startedAt`
-- `completedAt`
-- `failedAt`
-- `ackText`
-- `responseText`
-- `eventJournalPath`
-
-`send` returns success only after a servant response is captured or a bounded failure is recorded.
-
-## Ledger and artifacts
-
-Append servant outputs to:
-
-```text
-tmp/overlord/<runId>/ledger.jsonl
-```
-
-Artifact records are references, not side channels:
-
-- `artifactId`
-- `ownerSlotId`
-- `kind`
-- `version`
-- `path`
-- `status`
-- `dependsOn`
-
-The coordinator routes artifact refs between servants.
-
-Servants do not directly own PRs, merges, releases, browser sessions, Playwright, shared stage servers, or cross-servant worktrees.
-
-## Liveness
-
-Use JSON events as liveness signals.
-
-Distinguish:
-
-- idle
-- running
-- blocked
-- failed
-- lost
-
-A ready servant that receives work but produces no non-TUI output before the bounded handoff interval is `stalled-after-delivery`.
-
-A message pasted into a composer but not submitted is `delivery-stuck-composer`.
-
-## Stop and resume
-
-Stop only exact run-owned OpenCode resources.
-
-Prefer headless `opencode run --session` calls so fewer live PTYs need process ownership.
-
-Resume from registry session ids, event journals, and the ledger.