docs: correct stale source and npm version references to 0.6.3 / 0.6.9

README.md

@@ -82,7 +82,7 @@ mcode login --region global
 
 Complete sign-in in your browser, then open `mcode` and use `/status` to check your account and `/provider` to choose a model. Run `mcode logout` to sign out.
 
-Token Plan requires an account with available credits. Builds from this repository and the published npm CLI `@minimax-ai/code@0.4.12` default to `~/.minimax` for user data (or `~/.minimax-<profile>` when a profile is selected). `MINIMAX_DATA_DIR` or `MAVIS_DATA_DIR` can override the data directory. The installer's `~/.minimax-code` installation directory is separate from this choice. See [Accounts and data](docs/installation.md#accounts-and-data) before locating or removing configuration and sessions.
+Token Plan requires an account with available credits. Builds from this repository and the published npm CLI `@minimax-ai/code@0.6.9` default to `~/.minimax` for user data (or `~/.minimax-<profile>` when a profile is selected). `MINIMAX_DATA_DIR` or `MAVIS_DATA_DIR` can override the data directory. The installer's `~/.minimax-code` installation directory is separate from this choice. See [Accounts and data](docs/installation.md#accounts-and-data) before locating or removing configuration and sessions.
 
 <details>
 <summary>Use your own API key (BYOK)</summary>
@@ -275,7 +275,7 @@ From the source directory, use `pnpm mcode` in place of `mcode` in the examples
 node /absolute/path/to/minimax-code/dist/cli.js
 ```
 
-This repository targets the **0.4.12 source preview**. Installing the published package and building this checkout are separate paths. Matching versions do not prove identical build provenance; see the [version and evidence baseline](docs/open-source-status.md#version-and-evidence-baseline).
+This repository targets the **0.6.3 source preview**. Installing the published package and building this checkout are separate paths. Matching versions do not prove identical build provenance; see the [version and evidence baseline](docs/open-source-status.md#version-and-evidence-baseline).
 
 ## Documentation and contributing
 

README_ZH.md

@@ -82,7 +82,7 @@ mcode login --region global
 
 在浏览器中完成登录，再启动 `mcode`，通过 `/status` 检查账号、通过 `/provider` 选择模型。退出登录使用 `mcode logout`。
 
-Token Plan 需要账号与可用额度。从本仓库构建的版本与已发布的 npm CLI `@minimax-ai/code@0.4.12` 均默认将用户数据保存在 `~/.minimax`（选择 profile 时为 `~/.minimax-<profile>`）。`MINIMAX_DATA_DIR` 或 `MAVIS_DATA_DIR` 可以覆盖数据目录。安装脚本使用的 `~/.minimax-code` 安装目录与数据目录的选择是两回事。查找或删除配置和会话前，请参阅[账号与数据](docs/installation.md#accounts-and-data)。
+Token Plan 需要账号与可用额度。从本仓库构建的版本与已发布的 npm CLI `@minimax-ai/code@0.6.9` 均默认将用户数据保存在 `~/.minimax`（选择 profile 时为 `~/.minimax-<profile>`）。`MINIMAX_DATA_DIR` 或 `MAVIS_DATA_DIR` 可以覆盖数据目录。安装脚本使用的 `~/.minimax-code` 安装目录与数据目录的选择是两回事。查找或删除配置和会话前，请参阅[账号与数据](docs/installation.md#accounts-and-data)。
 
 <details>
 <summary>使用自己的 API Key（BYOK）</summary>
@@ -272,7 +272,7 @@ pnpm mcode
 node /absolute/path/to/minimax-code/dist/cli.js
 ```
 
-本仓库目标为 **0.4.12 源码预览**。安装已发布的包与构建本仓库是两条独立路径，版本一致不代表构建来源完全相同，详见[版本与证据基线](docs/open-source-status.md#version-and-evidence-baseline)。
+本仓库目标为 **0.6.3 源码预览**。安装已发布的包与构建本仓库是两条独立路径，版本一致不代表构建来源完全相同，详见[版本与证据基线](docs/open-source-status.md#version-and-evidence-baseline)。
 
 ## 文档与贡献
 

SECURITY.md

@@ -12,7 +12,7 @@ Include the affected version, operating system and Node.js version, a minimal re
 
 ## Data and service boundaries
 
-- The active data directory stores login state, provider configuration (including API keys in `config.yaml`), and sessions. Builds from this repository and the published npm CLI `@minimax-ai/code@0.4.12` default to `~/.minimax` (or `~/.minimax-<profile>` when a profile is selected). Environment overrides can select another directory. Follow [Accounts and data](docs/installation.md#accounts-and-data) to identify it; the installer location alone does not identify stored credentials. Restrict local access to every data directory you have used and keep them out of Git, including old profiles. They are not shareable project configuration.
+- The active data directory stores login state, provider configuration (including API keys in `config.yaml`), and sessions. Builds from this repository and the published npm CLI `@minimax-ai/code@0.6.9` default to `~/.minimax` (or `~/.minimax-<profile>` when a profile is selected). Environment overrides can select another directory. Follow [Accounts and data](docs/installation.md#accounts-and-data) to identify it; the installer location alone does not identify stored credentials. Restrict local access to every data directory you have used and keep them out of Git, including old profiles. They are not shareable project configuration.
 - Models, official plugins, connectors, search, media, feedback, and telemetry may contact external services. Those services continue to control authorization and credits; source access does not grant access to accounts or third-party resources.
 - mcode-tools obtains short-lived access tokens through the host's lease broker. Never pass refresh tokens to tool processes.
 - Permissions and sandboxing do not replace review of untrusted plugins, MCP servers, and shell commands. If automatic permission classification is unavailable, retain user confirmation rather than allowing operations by default.

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.

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 |