tournierjc · Sep 25, 2026 · Sep 27, 2026 · Sep 27, 2026 · Sep 27, 2026 · Sep 28, 2026
diff --git a/.github/workflows/cli-release.yml b/.github/workflows/cli-release.yml
@@ -179,3 +179,45 @@ jobs:
           GH_REPO: ${{ github.repository }}
           MCODE_RELEASE_DIRECTORY: ${{ runner.temp }}/package
           MCODE_RELEASE_REPORTS: ${{ runner.temp }}/reports
+  # Publishes the single-bin ACP launcher (@minimax-ai/code-acp) in lockstep
+  # with @minimax-ai/code, which the ACP registry runs via `npx ... acp`.
+  # Opt-in: set repo variable MCODE_ACP_PUBLISH=true and secret NPM_TOKEN.
+  publish-acp:
+    needs: [build, publish]
+    if: github.event_name == 'push' && vars.MCODE_ACP_PUBLISH == 'true'
+    permissions:
+      contents: read
+      id-token: write
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+    env:
+      VERSION: ${{ needs.build.outputs.version }}
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+        with:
+          persist-credentials: false
+      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
+        with:
+          node-version: '24'
+          registry-url: 'https://registry.npmjs.org'
+          package-manager-cache: false
+      - name: Wait for @minimax-ai/code at this version on npm
+        shell: bash
+        run: |
+          for _ in $(seq 1 80); do
+            npm view "@minimax-ai/code@$VERSION" version >/dev/null 2>&1 && exit 0
+            sleep 20
+          done
+          echo "@minimax-ai/code@$VERSION not on npm after waiting" >&2; exit 1
+      - name: Stamp and publish @minimax-ai/code-acp
+        working-directory: packages/code-acp
+        shell: bash
+        run: |
+          if npm view "@minimax-ai/code-acp@$VERSION" version >/dev/null 2>&1; then
+            echo "already published"; exit 0
+          fi
+          npm pkg set version="$VERSION" "dependencies.@minimax-ai/code=$VERSION"
+          tag=latest; [[ "$VERSION" == *-* ]] && tag=next
+          npm publish --access public --provenance --tag "$tag"
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
diff --git a/docs/community/groups.md b/docs/community/groups.md
@@ -0,0 +1,87 @@
+# Community groups
+
+This document defines the three community layers, what each layer is for, and the rule for moving
+between them. It is public so that joining a group is a predictable decision rather than a guess.
+
+## Layers
+
+| Layer | Who can join | What belongs there | What does not |
+| --- | --- | --- | --- |
+| Newcomer | Anyone with the group QR code or the Discord link | Install, configuration, first-run usage, frequently asked questions | Unreleased features, internal roadmap, internal test builds |
+| Advanced | Anyone who has opened at least one issue, or who is invited | Architecture discussion, PR intentions, performance findings, design proposals | Internal roadmap, unreleased features |
+| Insider | Invitation only, after signing the external-disclosure rule | Test builds, unreleased features, early feedback | Screenshots of accounts, session identifiers, or unreleased versions |
+
+The three layers are rules first and separate groups second. A new group with fewer than 50 active
+members is not created; the rule applies to the existing group until the volume justifies a split.
+
+## The one entry point
+
+Every layer carries the same pinned card, pointing at the same three places:
+
+1. **Report an issue** — `https://github.com/MiniMax-AI/minimax-code/issues/new/choose`
+2. **Claim a task** — the `good first issue` label:
+   `https://github.com/MiniMax-AI/minimax-code/labels/good%20first%20issue`
+3. **See the on-call rota and the weekly replay** — [Community on-call](oncall.md)
+
+Feedback posted in chat without an issue number is not tracked. If a chat report is not converted into
+an issue within 24 hours, the on-call owner raises it on the reporter's behalf.
+
+## Moving between layers
+
+- **Newcomer → Advanced**: automatic, as soon as the member opens an issue or is invited. There is no
+  application and no approval.
+- **Advanced → Insider**: invitation only. The invite includes the external-disclosure rule below, and
+  the rule is acknowledged before any test build is shared.
+- **Insider → public**: content returns to a public layer only through the formal release notes. Chat
+  history is never the source for external material.
+
+## External-disclosure rule for the Insider layer
+
+Acknowledged by every Insider member before receiving a test build.
+
+1. Test builds, unreleased feature names, and internal version numbers stay in the Insider layer. They
+   are not posted to a public group, a public issue, a screenshot, a blog post, or a video.
+2. Account identifiers, session identifiers, tokens, and customer project content are never shared in
+   any layer. Use synthetic files and dedicated test accounts.
+3. External material about a feature comes from the release notes for a released version, not from a
+   chat log. If a screenshot is needed for a public post, it must be regenerated from a released
+   build.
+4. A leak is reported to the release coordinator immediately, and the affected material is withdrawn
+   as soon as it is identified. Reporting a leak is never held against the reporter.
+
+## What a layer may be used for
+
+| Activity | Newcomer | Advanced | Insider |
+| --- | --- | --- | --- |
+| Install and configuration help | Yes | Yes | Yes |
+| Bug report and question answering | Yes | Yes | Yes |
+| Weekly feedback replay | Yes | Yes | Yes |
+| AMA session (biweekly) | Yes | Yes | Yes |
+| Showcase wall submission | Yes | Yes | Yes |
+| Architecture and design discussion | No | Yes | Yes |
+| Pull request review participation | No | On invitation | Yes |
+| Test build distribution | No | No | Yes |
+
+## Showcase wall
+
+Showcases are collected in `docs/showcase/` and mirrored to a GitHub Discussions category.
+
+- **Threshold:** a showcase must be runnable — a repository, or a prompt that reproduces it, plus the
+  verification command. Screenshots alone are not accepted.
+- **Every showcase produces a task.** Each accepted showcase must yield at least one
+  `good first issue` task, by extracting the step a newcomer could do independently. This is the point
+  of the wall: a showcase that produces no task brings in visitors who find nothing to do.
+- **Low bar by design:** the entry requirement is "post a prompt that runs". A showcase is not a
+  product pitch.
+
+## AMA sessions
+
+Biweekly, 30 minutes: 20 minutes of product questions, 10 minutes walking through live issues.
+
+- **Agenda comes from the queue.** Every question discussed is drawn from the current
+  `needs-triage` queue or a contribution request. The host does not choose topics independently.
+- **Recording and minutes** are archived to the Discussions `AMA` category, with the issue numbers
+  discussed listed in the minutes.
+- **Failure condition:** if three consecutive sessions draw fewer than 30% of registrants, the format
+  changes to a smaller closed-door session over live issues instead of a public AMA. Adding more
+  sessions is not the response.
diff --git a/docs/community/oncall.md b/docs/community/oncall.md
@@ -0,0 +1,156 @@
+# Community on-call and issue SLA
+
+This document defines who watches the community channels, what counts as a response, and how
+feedback is replayed back to reporters. It is a public commitment: anyone reading it should be able
+to predict when they will hear back.
+
+## Scope
+
+The community on-call covers two surfaces:
+
+| Surface | Meaning | Owner |
+| --- | --- | --- |
+| Community chat (Chinese Feishu group, Discord) | User questions, feedback, event coordination | On-call A |
+| GitHub issues (`MiniMax-AI/minimax-code`) | Bug reports, feature requests, contribution requests | On-call B |
+
+These are two different roles and they are staffed by two different people. A single person holding
+both roles cannot cover the 18:00–20:00 window, so that window is explicitly not covered by either
+role.
+
+## Rotation
+
+| Role | Window | Timezone | Coverage |
+| --- | --- | --- | --- |
+| On-call A | Weekdays 10:00–18:00 | Asia/Shanghai | Community chat |
+| On-call B | Daily 09:00, 20:00–23:00, and weekends | Asia/Shanghai | GitHub issues |
+| Uncovered | 18:00–20:00 weekdays | — | Neither role; escalate to the release coordinator |
+
+The rotation is published in the community chat as a pinned card. It is replaced every two weeks.
+
+## Response SLA
+
+**Every open issue must receive a triage action within 48 hours of being opened.** A triage action is
+one of the following, and one of them counts:
+
+- applying a type and product label;
+- asking the reporter for the specific missing information (`needs-info`);
+- linking a duplicate to its original issue;
+- recording a next step in a comment, including a decision to decline with a reason.
+
+A triage action is not a promise to fix or to ship in a release. Classification alone does not commit
+the project to a delivery date, and this distinction is stated in every response so reporters know
+what they are getting.
+
+Anything that has been open for more than 48 hours without any of the above is a SLA breach and is
+listed in the weekly feedback replay.
+
+## Label hygiene
+
+- An issue must not stay on `needs-triage` after it is closed. When closing an issue, remove
+  `needs-triage` in the same action.
+- `needs-triage` counts only open issues. Reporting a `needs-triage` ratio that includes closed
+  issues overstates the backlog; the canonical number is `is:issue is:open label:needs-triage`.
+- When an issue is closed as `duplicate` or `wontfix`, the reason is stated in a comment, per the
+  triage policy in [Maintainers](../maintainers.md).
+
+## Contribution requests
+
+A request for repository access is a request for a decision, and a decision must be communicated.
+Even when the answer is "no", the answer is sent.
+
+- Tag contribution requests with `contribution-request` so the funnel from request to decision is
+  measurable.
+- Respond within 48 hours with one of: approved, declined with a reason, or already completed
+  internally.
+- **When the underlying task is completed internally first, the requester is told explicitly and their
+  fork and branch are still declared valid.** If the internal fix missed anything, the requester is
+  invited to open a fork PR. Silently closing a contribution request because the work was done
+  elsewhere is treated as a SLA breach, not as resolution.
+- Submission of a fork PR does not require collaborator access. Access is a convenience for
+  maintainers, not a precondition for contributing.
+
+## Weekly feedback replay
+
+Every Friday, the on-call owner posts a single message to the community chat summarising the week:
+
+- every issue that received a triage action, with its number and what the action was;
+- every issue that was asked for more information, and what is still needed;
+- every issue that was closed, and why;
+- every open issue that has breached the 48-hour SLA, listed by number.
+
+The replay links issue numbers directly. It exists so that a reporter can see what happened to their
+report without having to ask, and it is the mechanism that keeps feedback from being silently dropped.
+
+## Reply templates
+
+### Triage response
+
+```
+Thanks for the report — received and triaged.
+
+Triage action: <label / needs-info / duplicate / next step recorded>, removed from `needs-triage`.
+
+What we need from you to take this further:
+1. <specific question>
+2. <specific question>
+
+We will reply within 48 hours. This triage action is not a commitment to a release date.
+```
+
+### Contribution request — already completed internally
+
+```
+Thanks for the patch and for following the contribution route. Sorry for the long silence on this
+thread; that was our failure, not yours.
+
+The task you prepared for (#<n>) was completed internally by #<n> and #<n>, so that specific task is no
+longer open.
+
+Your fork and branch are still valid. If you spot anything the internal fix missed or got wrong,
+please open a fork PR — no collaborator access is required to submit a fork PR, and we review it
+within 48 hours. The same applies to any other change you have prepared.
+
+If you would like to pick up a scoped task, the `good first issue` label is the canonical list:
+<label url> — items there are expected to be independently completable, with
+`pnpm verify --profile docs` as the verification command for documentation tasks.
+```
+
+The two sentences that matter here are the second and third paragraphs. Reporting that the work was
+done elsewhere, and then stating that the requester's work is still valid, is what keeps a second
+applicant from being treated the same way. Never write "the task is already done, please resubmit".
+
+### Contribution request — approved
+
+```
+Approved. You now have the requested access.
+
+The change is expected to be scoped in an issue first, then submitted as a PR from your fork.
+Please run the verification command for the profile that covers your change
+(`pnpm verify --profile docs` for documentation) and paste the real command output into the PR
+description. Review target is 48 hours; if you have not heard back by then, ping the on-call owner.
+```
+
+### Security-relevant report
+
+```
+Thank you for the detailed report. This is treated as a safety-priority report and escalated for a
+code-level review.
+
+Please do not post further exploit detail in this public thread. If the reproduction involves a
+pattern that could affect other users, open a private report per SECURITY.md and reference this issue
+number.
+
+We will reply within 48 hours.
+```
+
+## Reporting
+
+The on-call owner reports these numbers weekly to the community chat and to the project maintainers:
+
+| Metric | Definition |
+| --- | --- |
+| 48h triage coverage | share of issues opened in the week that received a triage action within 48 hours |
+| Open `needs-triage` | open issues still carrying `needs-triage` (open scope only) |
+| SLA breaches | issues open for more than 48 hours with no triage action |
+| Zero-reply issues | open issues with no comment at all |
+| Contribution request resolution time | hours from request to a communicated decision |
diff --git a/docs/examples.md b/docs/examples.md
@@ -81,6 +81,17 @@ The provider is stored with no `apiKey` and no `authMode`, and every request to
 
 Providers created by `kcode provider add` are stored under `custom_provider` in the active profile's `config.yaml`. That tree is the supported home for any endpoint other than the official MiniMax API; `minimax_api` is reserved for the official endpoint and keeps its fixed authentication scheme.
 
+Google-compatible endpoints use Pi's native Google adapter. Add the model manually with a base URL ending at the API version (not `/models`):
+
+```bash
+mcode provider add --name "OpenCode Go Gemini" \
+  --base-url https://opencode.ai/inference/go/v1 \
+  --api-format google-generative-ai --model gemini-4-argon-contributor \
+  --api-key-env OPENCODE_API_KEY --use
+```
+
+Google requests use `x-goog-api-key`. Model requests, tool calls and thinking parameters are handled by Pi.
+
 Authentication follows the API format: `openai-completions` and `openai-responses` send `Authorization: Bearer <key>`, and `anthropic-messages` sends the key as `x-api-key`. A relay that expects Bearer authentication on an OpenAI-compatible endpoint therefore needs no extra configuration. If a relay only exposes an Anthropic-compatible endpoint (`/v1/messages`) and requires Bearer authentication, add explicit headers to the provider entry in `config.yaml`:
 
 ```yaml

diff --git a/docs/open-source-status.md b/docs/open-source-status.md
@@ -1,19 +1,19 @@
 # Source status
 
-The current source target is **TUI 0.4.12**. This repository contains the terminal TUI, headless CLI, ACP implementation, and the public distribution tooling around them.
+The current source target is **TUI 0.6.3**. This repository contains the terminal TUI, headless CLI, ACP implementation, and the public distribution tooling around them.
 
 ## Version and evidence baseline
 
 | Concern | Current value | Source of truth |
 | --- | --- | --- |
-| TUI capability version | 0.4.12 | `packages/tui/package.json` |
-| Root workspace version | 0.4.12, aligned with the TUI | Root `package.json` |
-| Published npm observation | `@minimax-ai/code@0.4.12`; npm `latest` was 0.4.12 on 2026-09-18 | Public npm registry |
+| TUI capability version | 0.6.3 | `packages/tui/package.json` |
+| Root workspace version | 0.6.3, aligned with the TUI | Root `package.json` |
+| Published npm observation | `@minimax-ai/code@0.6.9`; npm `latest` was 0.6.9 on 2026-10-13 | Public npm registry |
 | Shared-source baseline | `9b9885e42a3cf1a3df1cfa52a46e4fdb034cfcee` | `release/extraction.json` |
 | Embedded mcode-tools | 0.0.4, extracted from public `@minimax-ai/code@0.3.11` | `scripts/lib/mcode-tools-artifact.mjs` |
 | Historical live-service acceptance and demo | TUI 0.3.11, recorded 2026-09-11 | `docs/verification.md`, `docs/release-audit.md`, `docs/assets/tui-demo.png` |
 
-The product, TUI, and root workspace use the same 0.4.12 version. The embedded tool has its own version. Workspace and local-build manifests remain `private: true` to prevent accidental npm publication. Matching version strings do not prove that this source tree reproduces the published npm tarball.
+The product, TUI, and root workspace use the same 0.6.3 version. The embedded tool has its own version. Workspace and local-build manifests remain `private: true` to prevent accidental npm publication. Matching version strings do not prove that this source tree reproduces the published npm tarball.
 
 ## Source boundary