{"id":51626701,"url":"https://github.com/waitdeadai/minmaxing","last_synced_at":"2026-07-13T02:02:15.955Z","repository":{"id":352683198,"uuid":"1216170765","full_name":"waitdeadai/minmaxing","owner":"waitdeadai","description":"The ultimate MiniMax 2.7 Highspeed Claude Code harness - 100 TPS, 204K context, GStack skills, 5-tier memory, 10x productivity.","archived":false,"fork":false,"pushed_at":"2026-05-15T04:25:26.000Z","size":1204,"stargazers_count":5,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-05-15T06:37:00.978Z","etag":null,"topics":["agent","ai-safety","anthropic","claude","claude-code","deep-research","governance","harness","hooks","llm","minimax","opus","workflow"],"latest_commit_sha":null,"homepage":null,"language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/waitdeadai.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":"NOTICE","maintainers":null,"copyright":null,"agents":"AGENTS.md","dco":null,"cla":null}},"created_at":"2026-04-20T16:31:54.000Z","updated_at":"2026-05-15T04:25:33.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/waitdeadai/minmaxing","commit_stats":null,"previous_names":["waitdeadai/minmaxing"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/waitdeadai/minmaxing","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waitdeadai%2Fminmaxing","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waitdeadai%2Fminmaxing/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waitdeadai%2Fminmaxing/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waitdeadai%2Fminmaxing/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/waitdeadai","download_url":"https://codeload.github.com/waitdeadai/minmaxing/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waitdeadai%2Fminmaxing/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":35407393,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-07-13T02:00:06.543Z","response_time":119,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agent","ai-safety","anthropic","claude","claude-code","deep-research","governance","harness","hooks","llm","minimax","opus","workflow"],"created_at":"2026-07-13T02:02:15.034Z","updated_at":"2026-07-13T02:02:15.946Z","avatar_url":"https://github.com/waitdeadai.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# minmaxing\n\n## Install\n\nPick the command that matches the folder.\n\nClean/new folder:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --minimax-key 'YOUR_TOKEN_PLAN_KEY'\n```\n\nExisting project or harness update:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --import-existing --minimax-key 'YOUR_TOKEN_PLAN_KEY'\n```\n\nGet your key from [platform.minimax.io](https://platform.minimax.io).\n\nMiniMax-only mode, when you want Claude Code as the shell but\nMiniMax-M2.7-highspeed for planner, reviewer, executor, and subagent model\nrouting:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --mode minimax --minimax-key 'YOUR_TOKEN_PLAN_KEY'\n```\n\nExisting project or harness update, MiniMax-only:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --import-existing --mode minimax --minimax-key 'YOUR_TOKEN_PLAN_KEY'\n```\n\nSafer interactive token entry for MiniMax-only updates:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --import-existing --mode minimax --prompt-minimax-key\n```\n\nOptional Claude-only suggested install, no MiniMax key:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --mode opussonnet\n```\n\nAfter install, start Claude yourself when you are ready:\n\n```bash\nclaude\n```\n\nThen use the definitive workflow command:\n\n```bash\n/opusworkflow \"build or fix the thing\"\n```\n\nIf you installed with `--mode minimax`, use the same underlying governed\nlifecycle directly:\n\n```bash\n/workflow \"build or fix the thing\"\n```\n\nPower-user Opus-saving route:\n\n```bash\n/sonnetminimax \"build or fix the thing\"\n```\n\nMental model:\n\n- `/opusworkflow` is the product command developers use day to day and the\n  definitive route for this workflow.\n- It requests Opus 4.7 high for planning/review when the account proves\n  that model is available.\n- It runs `/specqa` after `SPEC.md` and before implementation, so the active\n  spec gets SOTA/currentness QA before code starts.\n- It uses MiniMax-M2.7-highspeed from the MiniMax Token Plan as the bounded\n  executor for bulk edits and repair loops.\n- Its default effort is `high`; `xhigh` and `max` are explicit overrides.\n- It must drive to a verified result, partial result, or blocked repair path.\n- `/sonnetminimax` is the explicit fallback/shortcut when you want Sonnet 4.6\n  judgment plus MiniMax-M2.7-highspeed Token Plan execution without spending\n  Opus.\n- MiniMax-only mode is explicit: `--mode minimax` keeps Claude Code as the\n  shell, but routes planner, reviewer, executor, and subagent model env to\n  MiniMax-M2.7-highspeed.\n- `/opusminimax` is the advanced engine underneath. Use it directly only when\n  debugging provider split, packet, repair, or benchmark behavior.\n\n\u003ch1 align=\"center\"\u003e\n  \u003cimg src=\"https://img.shields.io/badge/MiniMax-2.7%20Highspeed-FF6B35?style=for-the-badge\u0026logo=lightning\u0026logoColor=white\" alt=\"MiniMax M2.7 Highspeed\" /\u003e\n  \u003cimg src=\"https://img.shields.io/badge/Claude%20Code-Harness-8B5CF6?style=for-the-badge\u0026logo=claude\u0026logoColor=white\" alt=\"Claude Code\" /\u003e\n  \u003cimg src=\"https://img.shields.io/badge/Speed-100%20TPS-10B981?style=for-the-badge\u0026logo=zap\u0026logoColor=white\" alt=\"100 TPS\" /\u003e\n  \u003cimg src=\"https://img.shields.io/badge/Context-204K%20tokens-3B82F6?style=for-the-badge\u0026logo=data\u0026logoColor=white\" alt=\"204K Context\" /\u003e\n\u003c/h1\u003e\n\n**Delegate execution. Keep judgment. Require evidence.**\n\nSetup adds a governed Claude Code harness where AI researches with an efficacy-first agent budget, audits the codebase, writes a concrete plan and `SPEC.md`, runs Spec QA, implements with clear ownership, and produces evidence before you trust the result.\n\n\u003cp align=\"center\"\u003e\n  \u003ca href=\"https://github.com/waitdeadai/minmaxing/stargazers\"\u003e\u003cimg src=\"https://img.shields.io/github/stars/waitdeadai/minmaxing?style=flat-square\u0026logo=github\" alt=\"Stars\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://github.com/waitdeadai/minmaxing/network/members\"\u003e\u003cimg src=\"https://img.shields.io/github/forks/waitdeadai/minmaxing?style=flat-square\u0026logo=github\" alt=\"Forks\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://github.com/waitdeadai/minmaxing/issues\"\u003e\u003cimg src=\"https://img.shields.io/github/issues/waitdeadai/minmaxing?style=flat-square\u0026logo=github\" alt=\"Issues\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://opensource.org/licenses/Apache-2.0\"\u003e\u003cimg src=\"https://img.shields.io/badge/License-Apache--2.0-green?style=flat-square\" alt=\"License\"\u003e\u003c/a\u003e\n\u003c/p\u003e\n\n---\n\n## Open-Core Boundary\n\nminmaxing is the open-source core for governed AI workflows. The public repo is\nlicensed under Apache-2.0 and includes the harness, skills, rules, AgentFactory\ncontracts, verification patterns, deterministic AgentCloseout physics engine,\nand safe example blueprints.\n\nThe private commercial moat is not included: REVCLI/Revis runtime code,\ncustomer-specific Hermes agents, enterprise connectors, memory seeds, audit\nlogs, operational playbooks, tenant infrastructure, and managed service\ndelivery remain private unless explicitly published later.\n\nRead the operating boundary before packaging or selling anything from this\nrepo:\n\n- [OPEN_CORE_STRATEGY.md](OPEN_CORE_STRATEGY.md)\n  defines what is public, what stays private, and why the moat lives in runtime\n  operation rather than prompt files.\n- [COMMERCIAL.md](COMMERCIAL.md) explains the\n  managed-service boundary and public-claims rules.\n- [SECURITY.md](SECURITY.md) defines safe\n  vulnerability reporting and secret/customer-data handling.\n- [TRADEMARKS.md](TRADEMARKS.md) keeps project\n  names, certification claims, and managed-service branding separate from the\n  Apache-2.0 code license.\n\n## Runtime Governance\n\nUse minmaxing as a governed harness, not as an unverifiable autonomy claim. The\npublic core is safe to validate without secrets:\n\n```bash\nbash scripts/test-harness.sh\nbash scripts/release-check.sh --static-only\n```\n\nRuntime checks are intentionally separate. Authenticated Claude Code smoke tests\nrequire local credentials and must not run by default on public PRs:\n\n```bash\nRUN_CLAUDE_INTEGRATION=1 bash scripts/test-harness.sh\n```\n\nChoose the runtime profile deliberately:\n\n- **Default in this repo:** trusted-local `bypassPermissions` for the operator's\n  solo workflow. This is intentionally fast and intentionally riskier: use it\n  only on a private machine/repo where you accept local command authority.\n- `solo-fast`: tracked example of the same trusted-local speed posture.\n- `team-safe`: shared-work fallback with `acceptEdits`; start from\n  `.claude/settings.team-safe.example.json` for teammates, reviews, clients, or\n  any workspace where automatic tool permission is too much authority.\n- `ci-static`: no-secret static validation for public PRs and release checks.\n- `ci-runtime`: manual authenticated validation through\n  `.github/workflows/harness-runtime.yml`.\n\nThe quickstart is here:\n\n- [docs/runtime-governance-quickstart.md](docs/runtime-governance-quickstart.md)\n\nPublic examples must use dummy data only:\n\n- [examples/dummy-harness-run/](examples/dummy-harness-run/)\n\nThe harness is effective when its gates produce evidence: `SPEC.md`,\nAgent-Native Estimates, parent-verified worker outputs, aggregate verification,\nmemory health/freshness checks, and command-backed closeout.\n\n## Setup Commands\n\nThere are two setup commands and they do different jobs.\n\n- **Clean/new folder:** use this only in an empty folder where minmaxing can\n  become the project scaffold.\n- **Existing project or harness update:** use this inside a real app/repo. It\n  imports or updates harness-owned files only, skips project-file conflicts,\n  preserves `.env`, `README.md`, `SPEC.md`, `taste.md`, `taste.vision`, app\n  code, package files, and `.git`, and records imported file hashes in\n  `.minimaxing/import-manifest.tsv` so future runs can update files it owns.\n\nBoth install commands land on the same simple UX: use `/opusworkflow` for\nnormal work. That means Opus 4.7 high is requested for planning,\nadversarial review, and final ship/no-ship judgment when runtime identity is\nproven, while MiniMax-M2.7-highspeed is the bounded executor for bulk coding\nand repair. It is not a magic guarantee that every external blocker disappears;\nit is a hard closeout discipline: verified result, partial result, or blocked\nrepair path. `/opusminimax` remains the lower-level engine behind that route,\nnot another daily command developers need to choose. The installer configures\nthe ignored local MiniMax executor profile, keeps the Opus planner profile\nprovider-clean, uses the default trusted-local `bypassPermissions` posture, and\nthen exits. Open Claude yourself with `claude` after setup finishes, so install\nfailures, warnings, and conflict messages stay visible.\n\nWhen you explicitly use `--mode minimax`, the installer prepares\n`.claude/settings.local.json` for a MiniMax-only Claude Code session:\n`ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic`,\n`ANTHROPIC_AUTH_TOKEN`, `MINIMAX_API_KEY`, `ANTHROPIC_MODEL`,\n`ANTHROPIC_DEFAULT_OPUS_MODEL`, `ANTHROPIC_DEFAULT_SONNET_MODEL`,\n`ANTHROPIC_DEFAULT_HAIKU_MODEL`, and `CLAUDE_CODE_SUBAGENT_MODEL` all point at\n`MiniMax-M2.7-highspeed`. In that mode, start `claude` yourself and use\n`/workflow \"build or fix the thing\"` so the same governed lifecycle runs under\nthe MiniMax-only local model routing.\n\nInline token commands can land in shell history. That is the intentional\nfast path for trusted solo work; environment-variable, hidden-input, key-file, and explicit\n`--mode minimax|opusworkflow|opusminimax|opussonnet|opusolo` forms are supported in\n`bash setup.sh --help`, but they are not the default path.\n\nIf an earlier install did not detect MiniMax, rerun the existing-project command\nabove from the project root. In `/opusworkflow` split mode, MiniMax is configured\nin the ignored executor profile `.claude/settings.minimax-executor.local.json`;\nit is not automatically added as a user-scope Claude MCP server.\n\nThat's it. Memory system, governed runtime profiles, and 43 skills are\nconfigured.\n\n### Suggested Claude-Only Install\n\nThe standard mode above is still the recommended MiniMax-backed workflow. If\nyou want the whole harness without a MiniMax Token Plan, use the optional\nClaude-only profile:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --mode opussonnet\n```\n\nExisting repo/updater form:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --import-existing --mode opussonnet\n```\n\nThis prepares ignored local profiles for Claude Code `opusplan`, pins\n`claude-opus-4-7` for planning/judgment and `claude-sonnet-4-6` for execution,\nkeeps MiniMax base URLs out of the Claude-only profiles, and leaves the normal\ngovernance hooks, `/workflow` lifecycle, `/introspect`, `/verify`, and\n`bypassPermissions` trusted-local posture in place. After install:\n\n```bash\nclaude\n/opussonnet \"build or fix the thing\"\n```\n\nUse this as a suggested alternative, not the default budget strategy. Runtime\nOpus access still depends on your Claude account state; use `/status` or an\nexplicit runtime check before claiming Opus 4.7 actually planned a run.\n\n### Suggested All-Opus Install\n\nIf you explicitly want Opus 4.7 for planning, execution, Spec QA, adversarial\nreview, and final judgment, use the optional `/opusolo` route:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --mode opusolo\n```\n\nExisting repo/updater form:\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/waitdeadai/minmaxing/main/setup.sh | bash -s -- --import-existing --mode opusolo\n```\n\nAfter install:\n\n```bash\nclaude\n/opusolo \"build or fix the thing\"\n/opusolo \"build or fix the thing\" --effort max\n```\n\n`/opusolo` keeps the same `/opusworkflow` gates and closeout rules. Its default\neffort is `high`; `--effort max` is an explicit highest-effort alias. Runtime\nOpus identity still depends on current Claude account/session proof.\n\nYou can also choose an explicit governed model profile per workflow without\nchanging the default:\n\n```bash\nbash scripts/sonnetminimaxworkflow.sh --task \"build or fix the thing\"\nbash scripts/opusworkflow.sh --task \"build or fix the thing\" --model-profile sonnetminimax --effort max\nbash scripts/opusworkflow.sh --task \"build or fix the thing\" --model-profile sonnet\nbash scripts/opusworkflow.sh --task \"build or fix the thing\" --model-profile opus\nbash scripts/opusworkflow.sh --task \"build or fix the thing\" --model-profile custom --planner-model claude-sonnet-4-6 --executor-model claude-sonnet-4-6\n```\n\n`minimax` remains the default. `sonnetminimax`, `opussonnet`, `opusolo`,\n`sonnet`, `opus`, `default`, and `custom` are explicit operator choices; static\nartifacts record the request, but runtime identity still depends on the current\nClaude Code account/session. `/sonnetminimax` is the short power-user route for\nSonnet 4.6 planning/review plus MiniMax-M2.7-highspeed Token Plan execution;\n`/opussonnet` is the Claude-only Opus+Sonnet route with no MiniMax token.\n\nClaude subscription auth is separate account auth. Run `claude auth login` once\nif this machine is not already logged in; the setup command does not store or\nfake your Claude subscription session.\n\n### Native Claude Code Remote Control\n\nClaude Code has native Remote Control for continuing a local session from\n`claude.ai/code` or the Claude mobile app. In this harness, `/remote-control`\nis a readiness/troubleshooting skill, not the live activator, because the\nproject skill can shadow a native slash command with the same name.\n\nUse this shell command to start the live native Remote Control server:\n\n```bash\nclaude remote-control\n```\n\nFor this trusted-local workspace, an explicit launch is:\n\n```bash\nclaude remote-control --name ultimateminimax --permission-mode bypassPermissions\n```\n\nKeep that process running, then connect from `https://claude.ai/code` or the\nClaude mobile app. This is different from `claude --remote` or Claude Code on\nthe web. Remote Control keeps the Claude Code process running locally, with\nthis repo's hooks, tools, project settings, and trusted-local\n`bypassPermissions` posture. The harness intentionally does not create a custom\nremote server, websocket bridge, or API-key control path.\n\nBefore using it, run the no-secret static doctor:\n\n```bash\nbash scripts/remote-control-doctor.sh --static --json\n```\n\nRemote Control requires claude.ai subscription login. `ANTHROPIC_API_KEY`,\n`CLAUDE_CODE_OAUTH_TOKEN`, third-party provider auth, `DISABLE_TELEMETRY`, and\n`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` can block eligibility, so shared\nproject settings avoid those variables.\n\n### Native Claude Code Agent View\n\nClaude Code Agent View is a local dashboard for background sessions. In this\nharness, `/agent-view` is a readiness/troubleshooting route only. It never opens\nthe live TUI, never dispatches `claude --bg`, and never treats background\nsession rows as verified worker results.\n\nOpen the live native Agent View TUI manually from a shell:\n\n```bash\nclaude agents\n```\n\nBefore using it, run the no-secret static doctor and fixture gate:\n\n```bash\nbash scripts/agent-view-doctor.sh --static --json\nbash scripts/agent-view-smoke.sh --fixtures\n```\n\nAgent View is separate from Remote Control, `/agents`, subagents, agent teams,\n`/parallel`, and `/hive`. Agent View sessions report to the operator; subagents\nreport back to the parent conversation. Agent View may help an operator monitor\nindependent top-level sessions, but it does not satisfy packet DAG, ownership\nmatrix, sidecar, aggregation, `/introspect`, or `/verify` requirements.\n\nThe effectiveness-first use is narrow on purpose: keep the main harness session\nas orchestrator, judge, and verifier; use Agent View sessions only as optional\nindependent evidence lanes; bring results back through artifacts, diffs, PRs,\nor explicit command evidence. Do not measure yield by how many sessions are\nrunning. Measure it by verified evidence per operator minute, reduced blocked\ntime, fewer context switches, and lower rework. If the task is tightly coupled,\ntouches shared files, involves secrets or security-sensitive authority, or needs\none shared reasoning loop, move back to `/opusworkflow`, `/parallel`, or local\nwork instead of forcing Agent View.\n\nStatic readiness requires Claude Code `2.1.139+` and `claude agents --help`\nshowing Agent View/background-session semantics. Background sessions are local,\nconsume quota, stop on sleep or shutdown, and may use `.claude/worktrees/`.\nBecause this repo defaults to trusted-local `bypassPermissions`, unattended\nAgent View usage is high-risk unless the operator intentionally accepts that\nauthority. Shared settings avoid `disableAgentView` and\n`CLAUDE_CODE_DISABLE_AGENT_VIEW`, but no static gate claims live runtime proof.\n\n### Native /goal / Goal Mode\n\nClaude Code `/goal` is a native session-scoped continuation command. In this\nharness, `/goal-mode` is the static readiness and effectiveness route; it never\nsets a live goal, never runs `claude -p`, never starts Remote Control, never\nopens Agent View, and never dispatches `claude --bg`.\n\nUse native `/goal` manually inside Claude Code:\n\n```text\n/goal \u003ccondition\u003e\n/goal\n/goal clear\n```\n\nBefore using it, run the no-secret static doctor and fixture gate:\n\n```bash\nbash scripts/goal-mode-doctor.sh --static --json\nbash scripts/goal-mode-smoke.sh --fixtures\n```\n\nNative `/goal` increases persistence, not correctness. It can keep Claude Code\nworking across turns, but the goal evaluator is not an independent verifier and\ndoes not replace command evidence, parent verification, `/specqa`,\n`/introspect`, `/verify`, release checks, provider identity proof, `/parallel`\naggregation, or CI.\n\nThe safe harness pattern is bounded and evidence-first:\n\n```text\n/goal bash scripts/release-check.sh --static-only exits 0 and git diff --check exits 0, or stop after 6 turns with a blocker summary\n```\n\nGoal Assist is the `/opusworkflow`-adjacent use of this feature: when a\ndeterministic gate has already failed, `/goal-mode` may produce copy-paste\nnative `/goal` text with the failed command, owned scope, forbidden\npaths/actions, transcript evidence, stop bound, blocker fallback, and parent\nverification. It remains suggest-only and never runs `/goal` for the operator.\n\nDo not create `.claude/skills/goal/SKILL.md`; that can shadow or confuse the\nnative Claude Code command. Do not use broad conditions like \"make it\nproduction ready\" or \"fix everything\" unless they include measurable checks,\nstop bounds, forbidden files, and evidence requirements. Because this repo\ndefaults to trusted-local `bypassPermissions`, unattended `/goal` loops in the\nreal repo are high-risk unless the operator explicitly accepts that authority.\n\n**Shared settings are committed on purpose, but they are provider-neutral.** `.claude/settings.json` contains governance hooks, deny rules, and the trusted-local `bypassPermissions` default. This is an explicit operator-speed choice, not a team-safety recommendation. Real credentials and provider identity belong in ignored local files such as `.claude/settings.opusminimax-planner.local.json` and `.claude/settings.minimax-executor.local.json`.\n\n**Fresh repos should start with `/tastebootstrap`.** It asks the 10 kernel questions, writes `taste.md` + `taste.vision`, and gives `/workflow` explicit taste to follow before anything is built.\n\n\u003e **Note:** Setup adds hardware auto-detection to `~/.bashrc` — `MAX_PARALLEL_AGENTS` is set automatically for new Bash sessions that source `~/.bashrc`.\n\n### Windows Setup\n\n**Recommended:** use **WSL 2** for the smoothest experience.\n\nClaude Code officially supports both:\n- **Native Windows + Git Bash**\n- **WSL 2**\n\nminmaxing's installer is Bash-first and updates `~/.bashrc`, so:\n- **WSL 2** is the best fit if your project already lives in Linux tooling\n- **Git Bash** is the best fit if your project lives on native Windows\n\n### Option 1: WSL 2 (recommended)\n\nInstall Claude Code inside WSL, then run minmaxing there too.\n\n1. Install WSL 2 and open your Linux distro.\n2. Install Claude Code inside WSL:\n\n```bash\ncurl -fsSL https://claude.ai/install.sh | bash\n```\n\n3. Move into your project directory inside WSL.\n4. Run the clean/new-folder command or the existing-project/updater command from the top of this README.\n\nIf you use the optional OpenAI Codex plugin in WSL, the same Linux flow applies there too.\n\n### Option 2: Native Windows + Git Bash\n\nClaude Code's official Windows docs say native Windows requires **Git for Windows**. Claude can be launched from PowerShell, CMD, or Git Bash, but this repo's setup script should be run from **Git Bash** because it is a Bash script and writes shell config to `~/.bashrc`.\n\n1. Install **Git for Windows**.\n2. Install Claude Code from **PowerShell**:\n\n```powershell\nirm https://claude.ai/install.ps1 | iex\n```\n\nOr install it with **WinGet**:\n\n```powershell\nwinget install Anthropic.ClaudeCode\n```\n\n3. Install **Python 3.11+** and **uv/uvx**:\n\n```powershell\nwinget install Python.Python.3.11\nwinget install --id=astral-sh.uv -e\n```\n\n4. Open **Git Bash** and run the clean/new-folder command or the existing-project/updater command from the top of this README.\n\n5. Verify Claude Code:\n\n```bash\nclaude --version\nclaude doctor\n```\n\nIf Claude Code cannot find your Git Bash installation, Anthropic documents this setting:\n\n```json\n{\n  \"env\": {\n    \"CLAUDE_CODE_GIT_BASH_PATH\": \"C:\\\\Program Files\\\\Git\\\\bin\\\\bash.exe\"\n  }\n}\n```\n\n### Windows Notes\n\n- Native Windows does **not** support Claude Code sandboxing; WSL 2 does.\n- PowerShell support in Claude Code is rolling out progressively, but minmaxing setup is still Bash-based.\n- If `uvx` is already available, the installer will use it. If not, preinstalling `uv` on Windows avoids shell-specific installer edge cases.\n\n---\n\n## The Problem\n\nAI coding's #1 failure mode: **building the wrong thing**.\n\n```\nWithout minmaxing:\n\"add user auth\"\n→ AI builds something that looks like auth\n→ \"that's not what I wanted\"\n→ AI rebuilds\n→ Hours wasted\n```\n\nWith SPEC-first:\n```\n\"add user auth\"\n→ AI asks: \"What happens when login fails?\"\n→ You: \"show error message\"\n→ AI writes SPEC.md with exact behavior\n→ AI implements to spec\n→ AI verifies against spec\n→ You accept or reject\n```\n\n---\n\n## What Makes minmaxing Different\n\n| This harness | Other harnesses |\n|-------------|----------------|\n| Taste-first: `/workflow` starts from `taste.md` + `taste.vision` | No taste — just \"build X\" |\n| 5-tier memory: captures durable decisions, patterns, and errors when hooks/CLI are healthy | Tabula rasa every session |\n| Central orchestrator: `/workflow` runs research → audit → plan → spec → execute → verify with hard gates | Skills are isolated, no chaining |\n| Health-checked capture: outcomes and reusable lessons can be logged to memory | Manual documentation |\n| SPEC-first: write spec before code | Vague prompts, rebuild loops |\n| Efficacy-first parallelism: use the right number of agents for the task | Sequential one-at-a-time |\n| Independent verification pass with metadata when isolation can be proved | Casual self-checks |\n| Research-first: `/workflow` drafts a plan, runs the repo’s effectiveness-first `deepresearch` `search -\u003e read -\u003e refine` investigation loop, and keeps an inspectable source ledger before planning or edits | AI hallucinates best practices |\n| Surgical diffs: vague requests become verifiable contracts, then every meaningful change needs a changed-line trace to `SPEC.md` | Drive-by refactors, speculative abstractions, and \"while I was here\" churn |\n\n**Taste is the kernel.** `/workflow` starts by checking taste.md and taste.vision. In a fresh repo, define them with `/tastebootstrap` before anything is built.\n\n**Taste is NOT just frontend/aesthetic, and it is not a frontend/backend checklist.** It's the project's operating kernel — design principles, experience direction, interface contracts, observability rules, architecture constraints, code style, intent, non-goals, and values. When `/tastebootstrap` asks its 10 kernel questions, it captures the vision and guardrails that make the whole system coherent.\n\n**Memory is durable when healthy.** minmaxing uses working-state handoffs, flat-file audit notes, and SQLite/FTS5 retrieval so reusable decisions, patterns, and failures can survive beyond one chat. Run `bash scripts/memory.sh health` when memory quality matters.\n\n**Harness quality matters.** The point is not to pretend the model became smarter. The point is to reduce verification debt: force research, write the contract, preserve context, inspect assumptions, and prove the outcome before trust.\n\n---\n\n## Key Features\n\n### Efficacy-First Parallelism\nSpawn up to the hardware-aware ceiling when the task genuinely has bounded,\nindependent packets. Supervisor decomposes tasks, workers execute in parallel,\nsupervisor verifies.\n\n```\nSupervisor (you/AI)\n├── Worker 1 → File A\n├── Worker 2 → File B\n├── Worker 3 → File C\n... (up to 10)\n└── Supervisor verifies all\n```\n\nAuto-detects your hardware: 32GB+ and 8+ cores -\u003e 10 agents, 16GB and 4+ cores -\u003e 6 agents, 8GB and 2+ cores -\u003e 3 agents. For a live profile, run `bash scripts/parallel-capacity.sh --summary`.\n\nThe important part is not hitting the ceiling. The important part is using the smallest agent budget that preserves fresh context, clear ownership, and a shorter critical path.\n\n### Planning Time Awareness\nminmaxing estimates meaningful work in agent-native wall-clock terms before a\nplan or `SPEC.md` is frozen. The required `Agent-Native Estimate` separates\nelapsed agent wall-clock, total agent-hours, human touch time, calendar\nblockers, critical path, and confidence.\n\nHuman-equivalent estimates are allowed only as secondary context. The harness\nmust not say \"6 weeks\" as the main estimate when the real plan is a 24/7\nagent-native DAG with 5 effective lanes, or when the honest answer is\n`blocked/unknown` because credentials, CI, deploy windows, or product decisions\nare missing. Current local capacity evidence comes from\n`bash scripts/parallel-capacity.sh --json`.\n\n### Parallel Mode\n`/parallel` is the dense-work orchestrator. It runs a Parallel Eligibility Audit,\nreads the hardware capacity profile, chooses an execution substrate, writes a\nPacket DAG and Ownership Matrix, inserts Sync Barriers, aggregates Worker Result\nSchema returns, then verifies the aggregate against `SPEC.md`.\n\nExecution substrate selection is explicit:\n- `local` for one tight reasoning loop, shared files, low hardware, or high coordination cost.\n- `subagents` as the default for bounded same-workspace research, audit, implementation, and review packets.\n- `parallel-instances` only for large disjoint work where separate sessions or worktrees materially shorten elapsed time.\n- `agent-teams` only as opt-in experimental behavior when explicitly enabled and fallback is documented.\n\n`/workflow` may auto-consider `/parallel` for dense work, but it downgrades when\nindependent packets, file ownership, host capacity, or verification are weak.\nMain stays orchestrator; workers do not own taste, architecture, SPEC,\nsecurity, registry, or final verification decisions.\n\n### SPEC-First\nFile-changing tasks start with research, code audit, and a concrete plan. `SPEC.md` is the formal contract that comes out of that work, and AI implements to spec.\n\nEven tiny local file-changing tasks should still produce a small `SPEC.md` when you invoke the full `/workflow` contract.\n\n### Spec QA\n`/specqa` is the Spec QA Agent that runs after `SPEC.md` is created or updated and before implementation. It checks requirements quality, measurable success criteria, SOTA 2026/currentness, security and governance risk, verification readiness, and improvement suggestions.\n\nUnder `/opusworkflow`, Spec QA requests an Opus 4.7 high/xhigh reviewer when runtime identity is proven. The harness must not claim Opus 4.7 reviewed a spec unless `/status`, a sentinel, or a durable artifact proves it. When SOTA or other time-sensitive facts matter, Spec QA requires webresearched actual-time data and a source ledger before execution can proceed.\n\n### Plan Mode Auto-Approval\n`/opusworkflow` now records a plan-mode checkpoint before execution. The default `--plan-mode-policy auto` sets `plan_mode.auto_approval.status=auto_approved_when_gates_pass`, which means implementation can start automatically only after the workflow has recorded the research brief, code audit, `/introspect pre-plan` pass, Agent-Native Estimate, `SPEC.md` decision, and `/specqa` execution-allowed decision.\n\nThis is workflow transition approval, not a shortcut. It does not replace native Claude Code Plan Mode, `SPEC.md`, `/specqa`, `/introspect`, `/verify`, runtime model identity proof, or `/visualizeworkflow` human approval. Use `--plan-mode-policy manual` when a human review should be required after the plan checkpoint.\n\n### Surgical Diff Discipline\nminmaxing does not just ask the model to \"be careful.\" It requires the smallest sufficient implementation, no speculative abstractions, no drive-by refactors, and a changed-line trace from meaningful diff hunks back to `SPEC.md`.\n\nThat means vague requests become verifiable contracts before code changes, and unrelated cleanup stays out of the diff unless the spec makes it necessary.\n\n### Active SPEC + Archive\n`SPEC.md` stays as the active contract in the project root so `/verify` and fresh agents always know what to read first.\n\nBefore a new task replaces a non-reused active spec, minmaxing archives the previous one under `.taste/specs/` with a descriptive task/outcome filename. Verified closeout archives the final spec too, deduplicated by content hash, so repeated closeouts do not create noisy copies.\n\n### Independent Verification Pass\nVerification is not a vibe check. `/verify` reads `SPEC.md`, checks every success criterion, records evidence, and now asks the workflow artifact to capture executor/verifier metadata when isolation is known. If the run cannot prove a separate agent/model/workspace, it must say `unknown` instead of pretending.\n\n### Research-First\nAI training data can be stale, and repo context can be incomplete. Current external facts get verified when they materially affect the plan; purely local tasks can justify a local-only research brief instead of doing fake research theater.\n\n`/workflow` now treats a research brief as mandatory for all tasks, with the MiniMax MCP as the preferred source whenever current external facts matter. But the brief is not just a search tally. The workflow now uses the repo’s effectiveness-first `deepresearch` protocol: draft a collaborative research plan, run an iterative search -\u003e read -\u003e refine loop, keep a source ledger, challenge conflicting evidence, and do targeted follow-up research before freezing the plan. It still uses up to `MAX_PARALLEL_AGENTS` tracks, but only when the added tracks are distinct and plan-changing. For a purely local task, it can justify a local-only research brief instead of doing pointless external calls.\n\n### Agent Factory\n`/agentfactory` is a governed workflow for creating Hermes agents, not a prompt template. It uses the same effectiveness-first spine as `/workflow`: taste gate, 12-question intent intake, deepresearch brief, runtime audit, capacity-aware runtime contract, manifest, least-privilege capability stack, Hermes `SPEC.md`, generated agent files, hard-gate introspection, independent verification, registry closeout, and memory integration.\n\nA Hermes agent can operate one workflow, one department lane, or one bounded subsystem. A fleet can operate a larger business process only by composing narrow agents with explicit handoffs, not by giving one agent omnipotent company authority.\n\nAgent Factory writes its own run artifact under `.taste/workflow-runs/*-agentfactory.md` and keeps the durable registry in `hermes-registry.md`. The secondary factory taste contract lives in `hermes-factory.taste.md`. Production status requires `hermes.runtime.json`, `development_host_profile`, `target_runtime_profile`, `host_capacity_profile`, `capacity_binding`, `concurrency_budget`, queue/backpressure behavior, `degrade_policy`, a passing kill-switch test, verifier metadata, source ledger, memory-coherence check, runtime evidence, and registry links to manifest, spec, verify, kill-switch, and runtime artifacts. The local `scripts/parallel-capacity.sh` profile describes the developer machine unless the target runtime is explicitly local; a cloud server, VPS, container host, CI runner, managed workflow runtime, or REVCLI fleet needs its own target runtime capacity evidence before an agent can be marked active. The dedicated `scripts/agentfactory-smoke.sh` stress test keeps the skill from regressing into a checklist by checking negative fixtures such as raw secrets, read-only agents with write actions, missing capacity budgets, untested kill switches, active `operator_exception`, and verifier overclaims.\n\nFor REVCLI/Revis-style products, `/agentfactory` treats Hermes as the role-scoped interaction/runtime shell, REVCLI/Revis as the policy and audit control plane, and Odoo or the configured database as the system of record. The repo includes `REVCLI_HERMES_AGENT_MAP.md` so generated agents map to concrete roles, approval gates, runtime evidence, kill switches, and closed-loop outcomes instead of broad “run the company” authority.\n\n### Permission Mode\n- **Project default:** provider-neutral trusted-local `bypassPermissions` with governance hooks and secret-read denies. Warning: this allows Claude Code to act without normal permission prompts, so use it only where you accept local operator risk.\n- **solo-fast option:** tracked example of the same trusted-local fast profile for personal repos where you want fewer prompts.\n- **Team-safe option:** copy [`.claude/settings.team-safe.example.json`](.claude/settings.team-safe.example.json) to your local settings and keep `defaultMode` at `acceptEdits`.\n- **Definitive workflow command:** use `/opusworkflow` for all ordinary\n  mutating work. It is the product-facing and primary best-results command:\n  Opus 4.7 high plans/reviews when proven available, and\n  MiniMax-M2.7-highspeed Token Plan executes bounded packets. Closeout is\n  verified, partial, or blocked-with-repair.\n- **Model profile override:** add `--model-profile sonnetminimax`, `--model-profile sonnet`, `--model-profile opus`, `--model-profile opussonnet`, `--model-profile default`, or `--model-profile custom --planner-model MODEL --executor-model MODEL` when you intentionally want a different governed model route for that run.\n- **OpusMiniMax engine:** use `/opusminimax` directly only when you need\n  benchmark, repair, provider, or lower-level packet control. It is not the\n  day-to-day command.\n- **SonnetMiniMax profile:** use `/opusworkflow \"task\" --model-profile sonnetminimax --effort max` when you want Sonnet 4.6 planning/review/judgment plus MiniMax-M2.7-highspeed execution. `--effort max` is recorded as requested and maps to Claude CLI `xhigh`; runtime model identity still needs `/status`, sentinel, or artifact proof.\n- **SonnetMiniMax shortcut:** use `/sonnetminimax \"task\"` when Opus is scarce or exhausted and you want the same governed route without remembering the model-profile flags. It defaults to `--effort max`.\n- **OpusSonnet option:** use `/opussonnet` when you want the same governed harness without a MiniMax token, via Claude Code `opusplan` with Opus 4.7 planning and Sonnet 4.6 execution.\n- **OpusSolo option:** use `/opusolo` when you explicitly want Opus 4.7 for planning, execution, Spec QA, adversarial review, and final judgment. It defaults to high effort and accepts `--effort max`.\n- If you want even more guardrails, switch your local Claude session to `plan` before high-risk work.\n\n### OpenAI Codex Plugin\nThis repo now ships a project-scoped Codex config under [`.codex/config.toml`](.codex/config.toml) plus focused Codex agents in [`.codex/agents/`](.codex/agents) so the official OpenAI Claude Code plugin can inherit sane defaults when you use Codex from inside Claude Code.\n\nResearch-backed take:\n- The best plugin for using Codex inside Claude Code is the official OpenAI [`openai/codex-plugin-cc`](https://github.com/openai/codex-plugin-cc).\n- It is explicitly built for Claude Code users, uses your local `codex` CLI plus Codex app server, and picks up user-level or project-level `.codex/config.toml`.\n- It does not force parallelism by itself. OpenAI’s Codex docs say subagents are only spawned when you explicitly ask for them, so effective concurrency comes from your prompt plus the project `max_threads` ceiling.\n- I found no official source saying this official plugin violates OpenAI terms. This is not legal advice, but the repo itself documents Claude Code installation and current OpenAI Terms/Usage Policies do not appear to prohibit this official integration when used compliantly.\n\nWhat this repo config gives Codex:\n- Main Codex default: `gpt-5.5` with `medium` reasoning and detailed reasoning summaries\n- Codex Memories enabled where supported, so useful local context can carry into future Codex sessions\n- Subagent ceiling: `10` via `[agents].max_threads`\n- OpenAI docs MCP: `https://developers.openai.com/mcp`\n- Repo-scoped skill: `.agents/skills/codex-imagegen` for `SPEC.md` image\n  assets that should use Codex subscription/ChatGPT image generation rather\n  than OpenAI API-key billing\n- Focused helper agents:\n  - `repo_explorer`\n  - `reviewer`\n  - `docs_researcher`\n\n### Taste-First (Kernel)\nEvery `/workflow` invocation checks `taste.md` + `taste.vision` before doing anything. In a fresh repo, run `/tastebootstrap` first. `/workflow` is the executor, not the bootstrap interview.\n\n### 5-Tier Memory (Persistent)\nSQLite-backed memory that remembers across sessions:\n- Every session start/end logged (episodic)\n- Decisions, patterns, errors all stored (semantic, procedural, error-solution)\n- Causal graph tracks what caused success/failure\n\n### Compaction-Safe Working State\nLLMs forget because live conversation context is lossy. minmaxing now keeps a compact task handoff in `.minimaxing/state/CURRENT.md` by default.\n\nClaude Code hooks refresh it after each turn, snapshot it before `/compact` or auto-compact, record the compact summary, and rehydrate it on startup, resume, and post-compact. Durable lessons still go to SQLite memory; `CURRENT.md` is only for the active task: files in play, current phase, latest `SPEC.md`, workflow artifact, verification status, and next steps.\n\n### Temporal Anchor\nClaude Code models do not know the present date from pretraining. minmaxing\ninjects a fresh local-system-clock anchor through `.claude/hooks/time-anchor.sh`\nat session start and before each user prompt. The same anchor is written into\n`.minimaxing/state/CURRENT.md` snapshots.\n\nUse it directly when needed:\n\n```bash\nbash scripts/time-anchor.sh text\n```\n\nFor \"today\", \"latest\", \"current\", \"recent\", \"SOTA 2026\", pricing, models,\nprovider behavior, laws, docs, benchmarks, schedules, or news, research must\nresolve dates against that anchor and verify live sources. If live verification\nis not available, the correct answer is `insufficient_data`, stale, or\nunverified, not a confident pretrained-memory claim.\n\n### Central Orchestrator\n`/workflow` owns the full lifecycle inline: taste gate, deep research, code audit, hard-gate introspection, plan, `SPEC.md`, implementation, verification, and closeout. For file-changing tasks it also leaves a workflow artifact under `.taste/workflow-runs/` and archived specs under `.taste/specs/` so the research plan, loop log, source ledger, audit, introspection, plan, and spec trail stay inspectable. Specialist skills still exist, but `/workflow` no longer depends on nested custom-skill chaining to finish the job.\n\n`/digestflow` is the report-informed sibling route. It adds Report Intake before deep research so Gemini, NotebookLM, ChatGPT Deep Research, Perplexity, or similar reports become provisional evidence instead of hidden assumptions.\n\n---\n\n## How the Workflow System Works\n\n### Taste as OS, Skills as System Calls\n\nThink of minmaxing as an operating system:\n\n```\n┌─────────────────────────────────────────────────────┐\n│                    /opusworkflow                    │\n│        (Default Claude judgment + MiniMax execution) │\n│                      /workflow                      │\n│                  (Lifecycle Engine Underneath)       │\n├─────────────────────────────────────────────────────┤\n│  PHASE 0: TASTE CHECK [GATE]  ← taste.md + vision │\n│  PHASE 1: ROUTE                                     │\n│  PHASE 2: DEEP RESEARCH (plan -\u003e search -\u003e read -\u003e refine) │\n│  PHASE 3: CODE AUDIT                               │\n│  PHASE 3.5: INTROSPECT [HARD GATE]                 │\n│  PHASE 4: PLAN                                     │\n│  PHASE 5: SPEC.md                                  │\n│  PHASE 6: EXECUTE                                  │\n│  PHASE 6.5: INTROSPECT [HARD GATE]                 │\n│  PHASE 7: VERIFY                                   │\n│  PHASE 8: CLOSEOUT                                 │\n├─────────────────────────────────────────────────────┤\n│            taste.md + taste.vision                  │\n│                  (Kernel / OS)                     │\n├─────────────────────────────────────────────────────┤\n│  /opusminimax(engine) /digestflow /autoplan       │\n│  /verify /ship /sprint /investigate /memory       │\n│  /audit /council /qa /review /deepresearch        │\n│  /webresearch /browse /introspect /codesearch     │\n│  /overnight /align /agentfactory                 │\n│              (System Calls)                          │\n└─────────────────────────────────────────────────────┘\n```\n\n**Taste is the kernel.** Every operation checks against your taste.md and taste.vision first. If the kernel is missing, stop and define it with `/tastebootstrap` before execution. Taste covers the full project philosophy — design principles, architecture, code style, intent, non-goals, and values.\n\n**Skills are system calls.** Each skill does one thing well. They are still useful directly, but `/opusworkflow` is the default daily entrypoint for mutating work and `/workflow` is responsible for finishing the underlying end-to-end lifecycle itself.\n\n**/opusworkflow is the definitive shell.** It is the default top-level route for normal build/plan work and mutating specialist work: Opus 4.7 high is requested for judgment checkpoints when proven available, and MiniMax-M2.7-highspeed Token Plan handles bounded execution packets. The default plan-mode policy auto-approves the transition to implementation only when research, code audit, `/introspect pre-plan`, Agent-Native Estimate, `SPEC.md`, and `/specqa` pass, recording `auto_approved_when_gates_pass` in the run artifact. Specialist routes are recorded as `inner_contract=workflow|agentfactory|hiveworkflow|parallel|defineicp|digestaste|deepretaste|demo|visualizeworkflow`, and closeout must be verified, partial, or blocked-with-repair. `/sonnetminimax` is the power-user Opus-saving sibling for Sonnet 4.6 judgment plus MiniMax-M2.7-highspeed Token Plan execution; `/opussonnet` is the optional Claude-only sibling for operators who want Opus 4.7 planning plus Sonnet 4.6 execution without MiniMax; `/opusolo` is the explicit all-Opus sibling for operators who want Opus 4.7 to plan, execute, review, and judge.\n\n**/opusminimax is the engine, not the product command.** Use it directly for\nprovider split debugging, packet control, repair mode, or benchmark mode. For\nnormal product work, use `/opusworkflow` and let it call the engine.\n\n**/workflow is the lifecycle underneath.** It routes tasks to the right phase, performs live research, audits the repo, synthesizes the plan, writes `SPEC.md`, executes the work, verifies output, and gates progression. Use it directly when you explicitly want one local supervisor loop or the provider split is unavailable.\n\nInside Phase 2, `/workflow` now follows the repo’s effectiveness-first `deepresearch` protocol instead of a generic search fan-out: it drafts a collaborative research plan, launches only the discovery tracks that matter, reads and refines in loops, records a source ledger including reviewed but not cited sources, pressure-tests conflicting evidence, and runs follow-up research before locking the plan.\n\nBefore research planning for file-changing work, `/workflow` records a compact `## Metacognitive Route` that explains task class, capacity evidence, effective parallel budget, chosen route, evidence required, confidence threshold, and why the full parallel ceiling was or was not used. This is the steering record; it comes before `## Research Brief` and does not satisfy later `/introspect` gates.\n\nBefore confidence is allowed, `/workflow` runs the repo’s hard-gate `/introspect` protocol. It names likely mistakes, checks assumptions, looks for counterexamples, compares implementation against `SPEC.md`, identifies missing verification, downgrades confidence when evidence is weak, and blocks closeout or push when unresolved findings remain.\n\nBefore closeout, `/workflow` also applies surgical diff discipline: smallest sufficient implementation, no speculative abstractions, no drive-by refactors, and a changed-line trace for the meaningful diff. This keeps autonomy from turning into \"helpful\" churn.\n\n### The 4 Execution Paths\n\n| When you say... | /workflow routes to... |\n|-----------------|----------------------|\n| \"build X\", \"implement Y\" | deep research → code audit → plan → `SPEC.md` → implement → verify → closeout |\n| \"fix Z\", \"debug this\" | deep research → code audit → plan → `SPEC.md` when files change → reproduce/fix → verify → closeout |\n| \"explain\" | deep research → inspect → explain |\n| \"refactor\", \"optimize\" | deep research → code audit → plan → `SPEC.md` → implement → verify → closeout |\n| \"audit this\", \"analyze\" | deep research → inspect → findings |\n\n### 5-Tier Memory System\n\nMemory is layered and inspectable, not magic. It captures task state, durable decisions, reusable patterns, error fixes, and causal notes when the hooks and CLI are healthy:\n\n| Tier | What | When |\n|------|------|------|\n| Episodic | Session start/end | Every shell start/exit |\n| Semantic | Decisions \u0026 principles | `/council` decisions, `/align` verdicts |\n| Procedural | Code patterns | `/codesearch` findings, `/sprint` outcomes |\n| Error-Solution | Bugs \u0026 fixes | `/investigate` fixes, `/verify` failures |\n| Graph | Causal chains | What caused success/failure |\n| Commit Log | Git commit summaries | Every `git commit` (auto-summarized) |\n\nMemory uses flat-file audit notes plus SQLite-backed FTS5 search when the Python memory CLI is available. Type `bash scripts/memory.sh health` to see whether the current repo is `healthy`, `degraded`, or `disabled`.\n\n**Commit auto-summarize:** Every `git commit` triggers `commit-summarize.sh` via a git post-commit hook, generating `obsidian/Memory/Stories/commits/{date}-{hash}.md` with structured frontmatter and a brief summary. Also written to SQLite for agent retrieval.\n\n### Working State vs Memory\n\n`.minimaxing/state/CURRENT.md` is the short-lived working state that survives compaction. It is generated by hooks and should be reconciled with live repo state before edits.\n\nSQLite memory is the durable layer for reusable lessons. When a decision, pattern, error fix, or research finding should survive future tasks, log it with `bash scripts/memory.sh add ...` instead of stuffing it into `CURRENT.md`.\n\n---\n\n## From 0 to 100: Fresh Folder\n\n### Step 1: Install\n\nRun the clean/new-folder command from the top of this README.\n\n### Step 2: Define Your Taste\n\nClaude opens at the end of setup. If you closed it, run `claude`.\n\nThen bootstrap the repo kernel:\n\n```\n/tastebootstrap\n```\n\n**What happens:**\n1. `/tastebootstrap` checks taste.md + taste.vision → **don't exist**\n2. `/tastebootstrap` asks the 10 kernel questions\n3. You answer → taste.md + taste.vision are created\n4. The repo is now ready for `/workflow`\n\nThen run:\n\n```\n/workflow \"build a REST API for a todo app\"\n```\n\n### What You Get\n\n- **Workflow Artifact** — `.taste/workflow-runs/...` with research brief, code audit, plan, and verification trail\n- **SPEC.md** — exact specification created from the researched plan\n- **Spec Archive** — `.taste/specs/...` snapshots of completed or superseded specs\n- **Implementation** — parallel agents building simultaneously\n- **Verification** — independent evidence pass against spec, with isolation metadata when known\n- **Closeout** — local completion by default, remote push only when you explicitly ask for it\n- **Memory** — durable lessons logged to 5-tier memory when the health check supports it\n\n### After Bootstrap\n\nYour taste is saved. From then on:\n\n```\n/workflow \"add user authentication\"\n```\n\nNo taste questions. `/workflow` knows your principles, plans, builds, verifies, and finishes the task.\n\n### Integrate Into Existing Project\n\nDrop minmaxing into any codebase:\n\n### Step 1: Install Into Existing Folder\n\n```bash\ncd your-existing-project\n```\n\nThen run the existing-project/updater command from the top of this README.\n\nThis imports or updates minmaxing harness files without overwriting your\nexisting code. If a harness file path already exists and was not previously\nimported by minmaxing, setup leaves it untouched and prints a conflict warning.\n\n### Step 2: Define Taste for This Project\n\nClaude opens at the end of setup. If you closed it, run `claude`.\n\n```\n/tastebootstrap\n```\n\nAnswer the 10 taste questions about your existing project:\n- What are your design principles?\n- What's your intent?\n- What's in/out of scope?\n- What experience, interface, and system rules matter?\n\n### Step 3: Use /workflow on Your Codebase\n\nNow you can use any workflow pattern:\n\n| Command | What it does |\n|---------|--------------|\n| `/workflow \"explain this codebase\"` | Understand what you have |\n| `/workflow \"audit this for security issues\"` | Deep security + quality audit with risk-based parallel coverage |\n| `/workflow \"refactor the auth module\"` | Research → audit → plan → spec → implement → verify |\n| `/workflow \"optimize database queries\"` | Research → audit → plan → spec → implement → verify |\n| `/workflow \"investigate why X is slow\"` | Root-cause debugging with hypothesis testing |\n| `/workflow \"add REST API to existing endpoints\"` | Research-backed spec-first build respecting existing architecture |\n\n### Key Difference: Existing vs New\n\n| Aspect | Fresh Project | Existing Project |\n|--------|--------------|------------------|\n| SPEC.md | Greenfield spec | Required for file-changing work; pure analysis can skip |\n| Taste | Bootstrap fresh | Define from existing code |\n| `/workflow \"build\"` | Full research-backed spec-first flow | Add features, respect existing patterns |\n| `/workflow \"explain\"` | N/A | Understand existing codebase |\n| `/workflow \"audit\"` | N/A | Find issues in existing code |\n| `/workflow \"refactor\"` | N/A | Improve existing implementation |\n\n---\n\n## The 41 Skills\n\n### Definitive Workflow Command\n\nUse `/opusworkflow` for normal file-changing work. You are not choosing\nbetween `/opusworkflow` and `/opusminimax`:\n\n- `/opusworkflow` is the product command and definitive workflow: Opus 4.7\n  high/xhigh planner/reviewer plus MiniMax-M2.7-highspeed executor.\n- `/opusminimax` is the advanced engine: provider split, packets, repair mode,\n  benchmark mode, and low-level debugging.\n- Is `/opusworkflow` better? For humans, yes. It is easier and safer because it\n  wraps the same engine with the normal workflow, budget, evidence, and\n  verification gates.\n- Does it always succeed? It always drives to a truthful outcome: verified,\n  partial, or blocked with the next repair action. It must not fake success.\n\n| Skill | What It Does |\n|-------|-------------|\n| `/tastebootstrap` | **Fresh-repo bootstrap** — asks the 10 kernel questions and writes `taste.md` + `taste.vision` |\n| `/workflow` | **Underlying lifecycle and explicit fallback** — drives research → code audit → plan → Agent-Native Estimate → `SPEC.md` → implement → verify → closeout (supervises an efficacy-first agent budget) |\n| `/opusworkflow` | **Definitive workflow command for mutating work** — Opus 4.7 high planner/reviewer when proven available, plus MiniMax-M2.7-highspeed Token Plan executor; supports `--model-profile sonnetminimax` for Sonnet 4.6 planner/reviewer plus MiniMax execution; auto-approves plan-to-execution only after gates pass; closes as verified, partial, or blocked-with-repair |\n| `/opusminimax` | **Advanced engine behind `/opusworkflow`** — use directly only for provider split, packet, repair, or benchmark debugging |\n| `/sonnetminimax` | **Power-user Opus-saving mode** — Sonnet 4.6 planning/review/judgment plus MiniMax-M2.7-highspeed Token Plan execution, default effort max, same `/opusworkflow` gates |\n| `/opussonnet` | **Optional Claude-only mode** — uses Claude Code `opusplan`, pins Opus 4.7 for planning/judgment and Sonnet 4.6 for execution, no MiniMax token required |\n| `/opusolo` | **Optional all-Opus mode** — pins Opus 4.7 for planning, execution, Spec QA, review, and final judgment; default effort high, optional `--effort max`, no MiniMax token required |\n| `/visualize` | **Taste-to-artifact comprehension check** — creates ignored visual, diagram, prompt, or narrative artifacts without implementation |\n| `/visualizeworkflow` | **Approval-first workflow** — drafts SPEC + visualization, stops at `WAITING_FOR_VISUAL_APPROVAL`, then continues only with `--continue` |\n| `/demo` | **Governed recorded demo pipeline** — produces product recordings with Playwright evidence, bilingual voiceover, captions, manifests, and safety gates |\n| `/digestflow` | **External-report-informed workflow** — digests 1-10 AI research reports as untrusted candidate evidence, then runs the full governed workflow |\n| `/digestaste` | **Research-to-bootstrap text** — digests Deep Research `.md` reports into a sanitized DigesTaste Bootstrap Packet for a new or existing project |\n| `/deepretaste` | **Intent-to-ICP-to-taste bootstrap** — detects product intent, uses `/deepresearch` for taste-driving evidence, defines ICPs, and bootstraps or proposes/applies taste changes through `/tastebootstrap` or `/defineicp` semantics |\n| `/defineicp` | **ICP-to-taste evolution** — defines primary/secondary/anti-ICPs with deepresearch, drafts taste.md + taste.vision changes, and applies only with explicit approval |\n| `/icpweek` | **ICP week-in-the-life stress test** — simulates Monday-Sunday real usage with ideal-user, CTO, and senior product-engineer lenses, then delivers the A-J product diagnosis |\n| `/align` | Validate idea against taste + vision. Gates /workflow on taste mismatch. |\n| `/audit` | Deep codebase audit with risk-based parallelism |\n| `/autoplan` | Generate SPEC.md with parallel execution and Agent-Native Estimate in mind |\n| `/agentfactory` | Create governed runtime-bound Hermes agents with manifest, `hermes.runtime.json`, capability stack, memory seed, verification, registry, and tested kill switch |\n| `/parallel` | Run hardware-aware whole-workflow parallel orchestration with packet DAG, ownership matrix, sync barriers, and aggregate verification |\n| `/metacognition` | Parallel-aware control plane for task routing, evidence-grounded reflection, confidence calibration, and verified learning |\n| `/claudeproduct` | Official-source answers for Claude, Claude Code, Claude.ai, Anthropic API, connectors, plugins, skills, hooks, MCP, subagents, Agent View, native `/goal`, background sessions, and setup |\n| `/remote-control` | Native Claude Code Remote Control route with a static doctor, no custom network control plane, and no API-key auth fallback |\n| `/agent-view` | Native Claude Code Agent View readiness route with a static doctor/smoke, manual `claude agents` launch, and no static runtime-proof claim |\n| `/goal-mode` | Native `/goal` readiness and effectiveness route with a static doctor/smoke, bounded continuation templates, no project `/goal` shadow skill, and no static runtime-proof claim |\n| `/specqa` | Spec QA Agent for every active `SPEC.md`: requirements quality, SOTA/currentness webresearch, Opus 4.7 identity-proof boundary, and improvement suggestions before implementation |\n| `/hive` | Governed multi-agent coordination with role map, blackboard, dissent, synthesis, and verified evidence |\n| `/hiveworkflow` | Full workflow mode for hive-coordinated planning, execution, aggregation, introspection, and verification |\n| `/sprint` | Run an ownership-safe parallel execution wave |\n| `/verify` | Check output against SPEC with an independent evidence pass |\n| `/review` | AI review + you decide |\n| `/qa` | Playwright E2E testing — Pass/Fail only |\n| `/ship` | Pre-ship checklist + rollback plan |\n| `/investigate` | Debug with 3-fix limit |\n| `/overnight` | 8hr session with 30-min checkpoints |\n| `/council` | Multi-perspective analysis |\n| `/deepresearch` | Deep multi-pass investigation with source ledgers and follow-up loops |\n| `/webresearch` | Current web/docs/API verification using the same effectiveness-first method |\n| `/browse` | Backward-compatible alias to `/webresearch` or `/deepresearch` |\n| `/introspect` | Hard-gate self-audit for likely mistakes, assumptions, missing verification, and confidence downgrades |\n| `/codesearch` | Search code by pattern |\n| `/memory` | 5-tier memory system — log decisions, search patterns |\n\n**Parallelism:** All skills that support parallelism treat `MAX_PARALLEL_AGENTS`, Codex `max_threads`, and hardware capacity as ceilings, not targets. `/align` remains single-threaded by design because taste alignment is sequential judgment.\n\n## Smart Autorouting\n\nminmaxing has smart autorouting through `/metacognition` and `/workflow`.\nBefore file-changing work, the harness classifies the task, reads capacity\nevidence, computes the smallest useful budget, and chooses the route with the\nleast coordination overhead that can still improve correctness.\n\nThe routing ladder is:\n\n```text\n/opusworkflow as the definitive workflow command and daily default for mutating build/plan/specialist work\n-\u003e local /workflow when the hybrid provider split is unavailable or explicitly bypassed\n-\u003e /digestaste when a Deep Research .md should become goal/taste bootstrap text before fresh or existing kernel decisions\n-\u003e /deepretaste when product intent, ICP, and taste kernel need a SOTA-2026 research-backed bootstrap or retaste\n-\u003e /defineicp when the product kernel needs ICP research before taste changes\n-\u003e /opusminimax only for advanced engine work: provider split, packet, repair, or benchmark debugging\n-\u003e /sonnetminimax when Opus is scarce/exhausted and the operator wants Sonnet 4.6 judgment plus MiniMax-M2.7-highspeed Token Plan execution\n-\u003e /opusworkflow --model-profile sonnetminimax when the operator wants the explicit flag form of the same route\n-\u003e /opussonnet when the operator explicitly wants the optional Claude-only Opus 4.7 + Sonnet 4.6 route\n-\u003e /opusolo when the operator explicitly wants the optional all-Opus 4.7 route with high effort by default\n-\u003e /parallel when independent execution packets are enough\n-\u003e /claudeproduct for Claude, Claude Code, Claude.ai, API, connector, plugin,\n   skill, hook, MCP, subagent, Agent View, background session, availability,\n   limit, model, or setup questions\n-\u003e /remote-control when the operator wants native Claude Code RC from\n   claude.ai/code or mobile without building a custom control plane\n-\u003e /agent-view when the operator wants native Claude Code Agent View readiness\n   for manual background-session monitoring, not governed packet execution\n-\u003e /goal-mode when the operator wants native /goal readiness, bounded\n   continuation templates, or safety diagnostics without setting a live goal\n-\u003e /specqa after SPEC.md and before implementation when the active spec needs\n   SOTA/currentness, requirements quality, and improvement-suggestion review\n-\u003e /hive for read-only coordination, or /opusworkflow with inner_contract=hiveworkflow\n   when coordinated roles, blackboard state, dissent, synthesis, and mutation\n   materially improve the outcome\n-\u003e blocked when evidence, ownership, capacity, or verification is missing\n```\n\nUse this rule of thumb:\n\n| Pick | When | The Developer Should Expect |\n| --- | --- | --- |\n| `/opusworkflow` | You want the definitive command for ordinary or specialist mutating work: Opus 4.7 high planner/reviewer when proven available, plus MiniMax-M2.7-highspeed Token Plan for bulk implementation. | Primary best-results route while Opus quota is available, one-command split setup, provider doctor, default executor concurrency 1, bounded packets, default effort `high`, `outer_route` + `inner_contract` artifacts, `plan_mode.policy=auto`, `auto_approved_when_gates_pass`, `outcome_policy=verified-partial-or-blocked-with-repair`, parent verification, and no silent PAYG. |\n| `/sonnetminimax` | Opus is scarce or exhausted, but you still want a governed Sonnet 4.6 judgment lane with MiniMax-M2.7-highspeed Token Plan execution. | Same workflow gates as `/opusworkflow`, fixed `model_profile=sonnetminimax`, `executor_provider=minimax`, default `--effort max`, identity claims blocked until proven, and no MiniMax tier/concurrency overclaims. |\n| `/opusworkflow --model-profile sonnetminimax` | You want Sonnet 4.6 for planning, Spec QA/review, adversarial judgment, and final decision work while keeping MiniMax-M2.7-highspeed for bounded execution. | Same workflow gates as `/opusworkflow`, `executor_provider=minimax`, requested Sonnet planner/reviewer, requested MiniMax executor, `--effort max` recorded as `xhigh`, and runtime identity claims blocked until proven. |\n| `/opussonnet` | You want the whole governed harness without MiniMax for a repo, and you are okay spending Claude subscription or extra usage on execution. | `setup.sh --mode opussonnet`, Claude Code `opusplan`, pinned `claude-opus-4-7` + `claude-sonnet-4-6`, no MiniMax base URL, same hooks and workflow gates. |\n| `/opusolo` | You explicitly want Opus for the entire governed run and accept the cost/limit tradeoff. | `setup.sh --mode opusolo`, pinned `claude-opus-4-7` planner/executor/reviewer, default `--effort high`, optional `--effort max`, no MiniMax base URL, same hooks and workflow gates. |\n| `/opusworkflow --model-profile sonnet|opus|default|custom` | You intentionally want Claude Code model freedom for one governed run. | Same workflow artifacts and gates, no MiniMax leakage for Anthropic-only profiles, requested model IDs recorded, and runtime identity claims blocked until proven. |\n| local `/workflow` | Explicit user override, provider split unavailable, one tight reasoning loop, one shared file, unclear ownership, or coordination would slow the work down. | One supervisor does the governed lifecycle and records why the hybrid outer route was not used. |\n| `/digestaste` | You have one or more Deep Research `.md` reports and want bootstrap text for a goal, fresh repo kernel, or existing project retaste. | Report Intake, no-persist report bodies, prompt-injection quarantine, claim/source/conflict ledgers, DigesTaste Bootstrap Packet, `/tastebootstrap` for missing kernels, and `/defineicp` proposal/apply semantics for existing kernels. |\n| `/deepretaste` | You need to detect product intent, define ICPs, and bootstrap or retaste the project kernel from research-backed customer evidence. | `/deepresearch` remains general-purpose; `/deepretaste` uses it only for taste-driving evidence, then routes fresh kernels through `/tastebootstrap` and existing kernels through `/defineicp` proposal/apply semantics. |\n| `/defineicp` | You need to define the ICP or ICPs and tailor `taste.md` / `taste.vision` to that customer profile. | Deepresearch plan, primary/secondary/anti-ICPs, source and claim ledgers, taste patch proposal, explicit apply approval, backups, hashes, validation, and rollback evidence. |\n| `/opusminimax` | You are maintaining the engine itself: provider split, packet control, repair mode, benchmark mode, or low-level routing evidence. | Provider split doctor, Opus planner artifact, MiniMax executor packets, quota-aware concurrency, parent verification, and no benchmark overclaims. |\n| `/claudeproduct` | The question is about Claude, Claude Code, Claude.ai, Anthropic API, connectors, plugins, skills, hooks, MCP, subagents, Agent View, background sessions, availability, limits, models, or setup. | Official Anthropic/Claude docs first, surface separation, source ledger, connector permission/trust caveats, confidence downgrade when current docs are missing. |\n| `/remote-control` | You want to diagnose Claude Code native Remote Control for an already trusted local harness session. | `/remote-control` runs the harness readiness skill; `claude remote-control` starts the live native server; claude.ai subscription login; no custom server; no static runtime-proof claim. |\n| `/agent-view` | You want to diagnose Claude Code native Agent View for manual background-session monitoring. | `/agent-view` runs static readiness checks; `claude agents` starts the live native TUI manually; Claude Code `2.1.139+`; no `claude --bg` automation; no `/parallel` replacement; no static runtime-proof claim. |\n| `/goal-mode` | You want to diagnose Claude Code native `/goal` or write a bounded continuation condition around known checks. | `/goal-mode` runs static readiness checks; native `/goal \u003ccondition\u003e` is typed manually inside Claude Code; no project `/goal` skill; no `claude -p` runtime in static gates; no `/workflow`, `/parallel`, or `/verify` replacement. |\n| `/specqa` | A `SPEC.md` was created, updated, or reused before implementation. | Spec QA Agent checks requirements quality, SOTA 2026/currentness source ledger, critical blockers, Opus 4.7 proof boundary, and concrete improvement suggestions before execution. |\n| `/parallel` | The work splits into independent packets with clear owned files/surfaces and aggregate verification. | Packet DAG, ownership matrix, sync barriers, worker sidecars, `parallel-aggregate`. |\n| `/hive` | The task needs multiple perspectives but may not need a full file-changing workflow: research branches, adversarial review, planning alternatives, risk ranking, or synthesis. | Queen/supervisor, role map, blackboard, dissent/conflict log, evidence-backed synthesis. |\n| `/hiveworkflow` | The entire implementation lifecycle benefits from hive coordination and packet execution: broad audit plus implementation, multi-surface build, high-stakes verification, or agent/fleet design. | Use through `/opusworkflow` by default with `inner_contract=hiveworkflow`, plus hive artifact, `hive-run.json`, optional `/parallel` packets, `hive-aggregate`, `/introspect`, `/verify`. |\n\nDo not pick `/hive` because it sounds more powerful. Pick it when role\nspecialization and dissent improve judgment. Do not pick `/parallel` because\nthere are available lanes. Pick it when disjoint ownership and aggregation make\nthe critical path shorter or the evidence better.\n\nIf both seem possible, default to `/parallel` for execution throughput and to\n`/hive` for judgment breadth. Use `/hiveworkflow` only when the task needs both.\n\n**Metacognitive routing:** `/metacognition` steers work before execution by\nclassifying the task, reading capacity evidence, computing the effective\nparallel budget, naming required evidence, and routing to `/workflow`,\n`/claudeproduct`, `/deepresearch`, `/parallel`, `/hive`, `/hiveworkflow`, `/agentfactory`,\n`/verify`, `/introspect`, or a blocked state. It is upstream steering, not a\nsubstitute for `/introspect`; required introspection triggers still need\nexplicit blocker decisions. It does not depend on raw hidden chain-of-thought\nand it rejects reflection without evidence. Use\n`bash scripts/metacognition-scorecard.sh --fixtures --json` to prove the static\ncontract.\n\n**Claude product knowledge:** `/claudeproduct` answers user and harness\nquestions about Claude product behavior from official current docs. It is the\nright path for \"how do we use X from Claude?\", Claude Code configuration,\nskills, hooks, MCP, subagents, Agent View, background sessions, Claude.ai\nProjects, Artifacts, connectors, Research, web search, API/platform behavior,\navailability, limits, and setup.\nIt separates Claude Code, Claude.ai, Desktop, Mobile, API, and MCP connector\nsurfaces, includes connector permission/trust caveats, and never reads `.env`\nor secrets for product-doc answers. Use\n`bash scripts/claudeproduct-scorecard.sh --fixtures --json` to prove stale\nmemory answers and unsupported Claude claims are rejected.\n\n**Native Remote Control:** in this harness, `/remote-control` runs readiness\nand troubleshooting checks. Start the live native server with\n`claude remote-control`, then connect from `https://claude.ai/code` or mobile.\nUse the native Claude Code feature only; do not add a custom remote server,\nwebsocket bridge, MCP control plane, or API-key fallback. Static harness\nevidence is compatibility evidence, not proof that a live browser or mobile\nsession connected. Use\n`bash scripts/remote-control-doctor.sh --static --json` and\n`bash scripts/remote-control-smoke.sh --fixtures` before blaming the harness.\n\n**Native Agent View:** in this harness, `/agent-view` runs readiness and\ntroubleshooting checks. Start the live native Agent View TUI manually with\n`claude agents`; use `claude --bg`, `claude attach \u003cid\u003e`, `claude logs \u003cid\u003e`,\n`claude stop \u003cid\u003e`, and `claude respawn --all` only as an operator-managed\nClaude Code workflow, not as hidden harness automation. Static evidence is\ncompatibility evidence, not proof that Agent View opened or that a paid account\ncan dispatch background sessions. Use\n`bash scripts/agent-view-doctor.sh --static --json` and\n`bash scripts/agent-view-smoke.sh --fixtures` before changing harness routing.\n\nAgent View is not Remote Control, `/agents`, subagents, agent teams, `/parallel`,\nor `/hive`. It can monitor independent top-level sessions for an operator, but\nit does not replace packet DAGs, ownership matrices, worker sidecars,\naggregation, blackboards, dissent logs, `/introspect`, `/verify`, or parent\nverification. Background sessions are local, quota-consuming, stopped by sleep\nor shutdown, and may use `.claude/worktrees/`; this repo's trusted-local\n`bypassPermissions` default makes unattended use a deliberate operator risk.\n\n**Native /goal / Goal Mode:** in this harness, `/goal-mode` runs readiness and\ntroubleshooting checks for Claude Code native `/goal`. Use `/goal \u003ccondition\u003e`,\n`/goal`, or `/goal clear` manually inside Claude Code; static checks never set a\ngoal, never run `claude -p`, never open Remote Control, never open Agent View,\nand never claim runtime proof. `/goal` is a bounded continuation helper, not\nverification: the evaluator judges surfaced transcript evidence and does not\nrun tools or inspect repo state. Use conditions that name real commands and a\nstop bound, such as `/goal bash scripts/release-check.sh --static-only exits 0\nand git diff --check exits 0, or stop after 6 turns with a blocker summary`.\n\nDo not create `.claude/skills/goal/SKILL.md`. Do not treat `/goal` as\n`/opusworkflow`, `/workflow`, `/parallel`, `/hive`, `/specqa`, `/introspect`,\n`/verify`, release checks, provider identity proof, or CI. Agent View can\nmonitor independent sessions where an operator manually uses `/goal`, but Agent\nView plus `/goal` is still not governed packet execution.\n\n**Spec QA Agent:** `/specqa` runs after `SPEC.md` and before implementation in\nthe governed workflow. It blocks critical spec defects, requires current\nwebresearch source ledgers for SOTA 2026 or time-sensitive claims, writes\n`.taste/specqa/{run_id}/spec-qa.md` plus `spec-qa.json`, and keeps Opus 4.7\nreviewer claims tied to runtime identity proof. Use\n`bash scripts/specqa-smoke.sh --fixtures` to prove the static contract.\n\n**Harness capability map:** `docs/harness-capability-map.md` and\n`docs/harness-capability-map.json` are generated from repo truth surfaces and\nact as the canonical self-lookup index for minmaxing capabilities. They list\nskills, route groups, rules, required script gates, static evals, hooks, and\nCodex surfaces without reading secrets. Regenerate and verify them with\n`bash scripts/harness-capability-map.sh` and\n`bash scripts/harness-capability-map.sh --check`.\n\n**Hive coordination:** `/hive` adds governed multi-agent coordination above\n`/parallel`: a queen/supervisor, capability-based roles, visible blackboard,\ndissent/conflict log, evidence-backed synthesis, and verification. Use\n`/hiveworkflow` only when the whole file-changing lifecycle benefits from that\ncoordination. Hive reuses `/parallel` packet DAGs, ownership matrices,\nsidecars, and aggregation for execution; hive runs also emit\n`.taste/hive/{run_id}/hive-run.json` validated by `artifact-lint` and\n`hive-aggregate`. Consensus never replaces\n`/introspect`, `/verify`, `/workflow`, or command evidence. Use\n`bash scripts/hive-scorecard.sh --fixtures --json` and\n`bash scripts/hive-aggregate.sh --fixtures` to prove the static contract.\n\n**Visualization approval:** `/workflow` stays autonomous. Use `/visualize` when you only want to see the model's understanding, and `/visualizeworkflow` when you want a draft spec plus visual or operational artifact to approve before implementation.\n\n**Codex image generation:** When `SPEC.md` asks for generated or edited raster\nassets, use the repo Codex skill `$codex-imagegen` from\n`.agents/skills/codex-imagegen`. It is intentionally subscription-first:\nCodex/ChatGPT image usage when the current Codex runtime exposes it, no\nOpenAI API keys or API-priced fallbacks unless you explicitly change that\nbilling route. If the runtime cannot generate an image, the harness writes a\nhandoff prompt and marks the asset blocked rather than pretending a file exists.\n\n**Effectiveness gates:** The harness is designed to steer LLMs away from lazy\ncompletion. Claude Code runtime hooks and local smokes reject destructive Bash,\nevidence-free closeout, failed-verification positive closeout, fake source\nledgers, tests-passed claims without command evidence, unverified worker\nclaims, shallow metacognition, stale Claude product answers, unsafe Agent View\nclaims, unsafe `/goal` claims, missing Spec QA, shallow hive consensus, and\nlinear lane-scaling claims. The Stop hook uses Claude Code's intentional\nblocking path: a blocked closeout is repair feedback, not a crash. Positive\ncloseout must cite commands or verification; read-only/audit closeout may cite\nfiles inspected or sources reviewed. \"Tests not run\", \"unverified\", or\nequivalent wording must close as partial/blocked rather than done. The\noverlapping closeout hooks now route through the deterministic\n`agentcloseout-physics` engine under `tools/agentcloseout-physics/`, with rule\npacks and fixtures checked by `bash scripts/agentcloseout-physics-smoke.sh`.\nACSP-CC remains a proposed Claude Code closeout profile; any conformance output\nis self-assessed preflight evidence, not a standard, certification, or adoption\nclaim. Use `bash scripts/harness-scorecard.sh --json`,\n`bash scripts/metacognition-scorecard.sh --fixtures --json`,\n`bash scripts/claudeproduct-scorecard.sh --fixtures --json`,\n`bash scripts/agent-view-smoke.sh --fixtures`,\n`bash scripts/goal-mode-smoke.sh --fixtures`,\n`bash scripts/specqa-smoke.sh --fixtures`,\n`bash scripts/hive-scorecard.sh --fixtures --json`,\n`bash scripts/hook-smoke.sh`, `bash scripts/agentcloseout-physics-smoke.sh`,\n`bash scripts/codex-run-smoke.sh`, and\n`bash scripts/parallel-plan-lint.sh --fixtures` to prove the first-slice gates.\n\n**Artifact sidecars:** Markdown remains the human contract, but machine gates can consume minimal JSON sidecars for agent-native estimates, verification results, and worker results. Validate the local fixtures with `bash scripts/artifact-lint.sh --fixtures`.\n\n**Static harness evals:** `evals/harness/tasks` and `evals/harness/golden` define local no-network eval tasks over the harness gates. Run `bash scripts/harness-eval.sh --json` or `bash scripts/harness-eval-report.sh --run` to score the current harness behavior.\n\n**Run metrics and session insights:** `bash scripts/run-metrics.sh --json` summarizes local workflow/eval/Codex artifacts, and `bash scripts/session-insights.sh --json` flags unhealthy runs. Missing provider cost, token, ACU, or calibration data is reported as `insufficient_data`.\n\n**Runtime hardening:** `bash scripts/runtime-hardening-smoke.sh` proves the\nlocal trace ledger, hook mesh, worktree runner, scenario evals, learning loop,\nand harness doctor without secrets or network access. See\n`docs/runtime-hardening.md` for the operator surface.\n\n**Security profiles:** this repo's default is trusted-local `bypassPermissions` for the operator's solo loop. `solo-fast` documents that posture, `team-safe` is the shared-work fallback, `ci-static` is no-secret static validation, and `ci-runtime` is isolated authenticated validation. Run `bash scripts/security-smoke.sh` after profile changes.\n\n**Release governance:** Public harness work should pass `bash scripts/release-check.sh --static-only`. The static GitHub Actions lane runs without secrets; authenticated runtime checks are isolated in the manual/scheduled runtime lane.\n\n---\n\n## Usage\n\n**The full workflow — one command:**\n```bash\nclaude\n/workflow \"build a REST API for users\"\n```\n\n`/workflow` now owns the whole lifecycle inline: taste check → `deepresearch` / `webresearch` → code audit → plan → `SPEC.md` → implementation → verification → closeout.\n\n**Report-informed workflow:**\n```bash\n/digestflow \"implement auth hardening based on these reports\" ./gemini-report.md ./notebooklm-notes.md\n```\n\n`/digestflow` starts with Report Intake. It treats external AI reports as untrusted candidate evidence, labels imported claims `report-derived`, quarantines prompt-like instructions, records contradictions, and then runs the repo's own deepresearch plus the full workflow before any implementation is trusted.\n\n**Research-to-taste bootstrap text:**\n```bash\n/digestaste \"bootstrap the operating kernel for this roofing ops agent\" ./deepresearch-result.md\n```\n\n`/digestaste` is lighter than `/digestflow`: it turns Deep Research markdown\ninto a sanitized DigesTaste Bootstrap Packet with goal text, claim/source\nledgers, `/tastebootstrap` answers, draft taste text, existing-kernel proposal\nhandling, and verification gaps. It does not run implementation. Fresh kernels\nroute through `/tastebootstrap`; existing kernels route through `/defineicp`\nproposal/apply semantics.\n\n**Direct skill invocation (advanced):**\n```bash\n/autoplan \"build a login system\"   # Generate SPEC.md\n/sprint                            # Execute with ownership-safe parallelism\n/verify                           # Check against spec\n/ship                             # Ship checklist\n```\nDirect invocation skips the orchestrator — use when you know exactly what you need.\n\n## Verification\n\nBefore you trust a setup or a prompt-contract change, run the repo checks:\n\n```bash\nbash scripts/test-harness.sh\n```\n\nIf Claude is authenticated locally, also run the runtime smoke flow:\n\n```bash\nbash scripts/workflow-smoke.sh\n```\n\nThe smoke test validates the real `/workflow` path in a temporary repo and accepts either:\n- a justified local-only research brief for a purely local task\n- or positive MiniMax MCP research when the task depends on current external facts\n\nFor `/opusworkflow`, prove the planner side separately before claiming Opus\nruntime identity:\n\n```bash\nunset ANTHROPIC_API_KEY ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN\nclaude auth login\nbash scripts/opusminimax-doctor.sh --runtime\nclaude --model claude-opus-4-7 --settings .claude/settings.opusminimax-planner.local.json -p 'Reply exactly: OPUSWORKFLOW_AUTH_OK'\n```\n\nCurrent local runtime evidence recorded on 2026-05-06: Claude Pro auth and the\nOpus 4.7 planner sentinel were proven by operator test. MiniMax live executor\npacket runtime remains pending until an explicit tiny executor packet is run.\n\n## Codex in Claude Code\n\n`/codesearch` is the local repo skill for searching code. `/codex:*` is the official OpenAI plugin namespace.\n\n### Install the official plugin\n\nYou can install it from the shell without opening a manual slash-command flow:\n\n```bash\nclaude plugin marketplace add openai/codex-plugin-cc\nclaude plugin install codex@openai-codex\nclaude plugins list\n```\n\nThen open Claude Code and run:\n\n```text\n/codex:setup\n```\n\nIf Codex is not logged in yet:\n\n```bash\ncodex login\n```\n\n### What this repo configures for Codex\n\nOnce the repo is trusted, Codex loads [`.codex/config.toml`](.codex/config.toml):\n\n- `model = \"gpt-5.5\"`\n- `model_reasoning_effort = \"medium\"`\n- `model_reasoning_summary = \"detailed\"`\n- `[agents].max_threads = 10`\n- `openaiDeveloperDocs` MCP for official OpenAI/Codex docs\n\n### Deep-Research examples\n\nThe Codex plugin exposes reviews plus long-running rescue tasks. For comprehensive research-backed planning, `/codex:rescue` is the better fit because it is steerable.\n\n```text\n/codex:rescue --background\nUse subagents up to max_threads for a research-backed plan, but only for bounded independent packets.\nHave repo_explorer map the code paths, docs_researcher verify external APIs and current docs, and reviewer challenge risks and rollback gaps before proposing the plan.\nTask: refactor the auth subsystem without user-visible behavior changes.\n```\n\n```text\n/codex:adversarial-review --background\nChallenge whether this implementation plan is the right one, question hidden assumptions, and look for rollback, race-condition, and test-coverage risks.\n```\n\nNotes:\n- `/codex:review` and `/codex:adversarial-review` are read-only.\n- `/codex:rescue` is the command to use when you want Codex to investigate, plan, and potentially fix.\n- Codex only fans out subagents when you explicitly ask it to.\n- The shared project standard is already `--model gpt-5.5 --effort medium`; use explicit CLI overrides only for temporary one-off experiments.\n\n---\n\n## Requirements\n\n| | |\n|---|---|\n| Claude Code | 2.1+ (`npm install -g @anthropic-ai/claude-code`); Opus 4.7 planner mode expects 2.1.111+ |\n| Python | 3.11+ |\n| MiniMax API Key | [platform.minimax.io](https://platform.minimax.io) |\n| Claude Subscription | Required for subscription-backed Opus planner usage; verify with `claude auth status --text` plus the `OPUSWORKFLOW_AUTH_OK` sentinel |\n| Node.js | 18.18+ if you want the optional OpenAI Codex plugin |\n| Codex Auth | ChatGPT sign-in or OpenAI API key if you want the optional OpenAI Codex plugin |\n\n---\n\n## Auto-Detection\n\nHarness auto-detects your hardware and sets agent pool:\n\n| RAM | Cores | Agents |\n|-----|-------|--------|\n| 32GB+ | 8+ | 10 (default) |\n| 16GB | 4+ | 6 |\n| 8GB | 2+ | 3 |\n\nOverride in your shell or ignored local profile:\n```json\n{\n  \"env\": {\n    \"MAX_PARALLEL_AGENTS\": \"6\"\n  }\n}\n```\n\n---\n\n## Folder Structure\n\n```\nminmaxing/\n├── CLAUDE.md                    # Core instructions (for AI)\n├── README.md                    # This file (for you)\n├── OPEN_CORE_STRATEGY.md         # OSS core vs private moat operating boundary\n├── COMMERCIAL.md                 # Managed-service and enterprise boundary\n├── SECURITY.md                   # Vulnerability reporting and secret handling\n├── TRADEMARKS.md                 # Brand, fork, and certification limits\n├── NOTICE                        # Apache-2.0 attribution notice\n├── setup.sh                     # One-command installer\n├── taste.md                     # Project operating kernel — created by /tastebootstrap\n├── taste.vision                 # Product intent + tradeoff contract — created by /tastebootstrap\n├── AGENTS.md                    # Project instructions for Codex\n├── REVCLI_HERMES_AGENT_MAP.md    # REVCLI/Revis runtime-ready Hermes agent portfolio\n├── .codex/\n│   ├── config.toml             # Project-scoped Codex defaults\n│   └── agents/                 # Codex custom agents for research/review\n├── .agents/\n│   └── skills/\n│       └── codex-imagegen/     # Codex subscription image asset skill\n├── .claude/\n│   ├── settings.json           # Provider-neutral governance config\n│   ├── settings.opusminimax-planner.example.json\n│   ├── settings.minimax-executor.example.json\n│   ├── settings.opusolo.example.json\n│   ├── settings.opussonnet.example.json\n│   ├── settings.sonnet-executor.example.json\n│   ├── hooks/                  # Lifecycle hooks, including working-state rehydration\n│   ├── skills/                 # 43 skills (system calls)\n│   │   ├── workflow/           # Central execution engine\n│   │   ├── opusworkflow/       # One normal Opus + MiniMax product route\n│   │   ├── sonnetminimax/      # Power-user Sonnet + MiniMax Token Plan route\n│   │   ├── opusminimax/        # Advanced provider/packet engine\n│   │   ├── opusolo/            # Optional all-Opus route\n│   │   ├── opussonnet/         # Optional Claude-only Opus + Sonnet route\n│   │   ├── visualize/          # Taste-to-artifact comprehension check\n│   │   ├── visualizeworkflow/  # Approval-first workflow route\n│   │   ├── demo/               # Recorded product demo route\n│   │   ├── digestflow/         # External report intake + governed workflow\n│   │   ├── digestaste/         # Deep Research markdown to bootstrap text\n│   │   ├── deepretaste/        # Intent-to-ICP-to-taste bootstrap/retaste\n│   │   ├── defineicp/          # ICP-to-taste evolution route\n│   │   ├── icpweek/            # ICP week-in-the-life product stress test\n│   │   ├── tastebootstrap/     # Fresh-repo taste bootstrap\n│   │   ├── align/              # Taste gate\n│   │   ├── audit/              # Deep codebase analysis\n│   │   ├── autoplan/           # SPEC.md generator\n│   │   ├── agentfactory/       # Governed Hermes agent generator\n│   │   ├── parallel/           # Hardware-aware workflow parallelizer\n│   │   ├── claudeproduct/      # Official Claude product knowledge router\n│   │   ├── remote-control/     # Native Claude Code Remote Control route\n│   │   ├── agent-view/         # Native Claude Code Agent View readiness route\n│   │   ├── goal-mode/          # Native Claude Code /goal readiness route\n│   │   ├── hive/               # Governed multi-agent coordination\n│   │   ├── hiveworkflow/       # Full hive-coordinated workflow\n│   │   ├── sprint/             # Ownership-safe parallel executor\n│   │   ├── verify/             # SPEC compliance checker\n│   │   ├── ship/               # Pre-ship checklist\n│   │   ├── investigate/        # Root-cause debugging\n│   │   ├── council/            # Multi-perspective synthesis\n│   │   ├── qa/                 # E2E testing\n│   │   ├── review/             # AI review + human sign-off\n│   │   ├── deepresearch/        # Canonical deep investigation\n│   │   ├── webresearch/        # Focused current web research\n│   │   ├── browse/             # Backward-compatible research alias\n│   │   ├── introspect/         # Hard-gate self-audit\n│   │   ├── codesearch/         # Code search\n│   │   ├── memory/             # 5-tier memory skill\n│   │   └── overnight/          # 8hr session with checkpoints\n│   └── rules/                  # Modular rules (spec, pev, quality, etc.)\n├── scripts/\n│   ├── memory.sh               # 5-tier memory CLI\n│   ├── state.sh                # Compaction-safe working state CLI\n│   ├── spec-archive.sh          # Active SPEC.md archive helper\n│   ├── memory-auto.sh           # Session start/end hooks\n│   ├── taste.sh                 # Taste system CLI\n│   ├── start-session.sh         # Session initializer\n│   ├── harness-capability-map.sh # Generated harness capability map\n│   ├── remote-control-doctor.sh # Static native RC readiness doctor\n│   ├── remote-control-smoke.sh # Native RC compatibility smoke gate\n│   ├── agent-view-doctor.sh    # Static native Agent View readiness doctor\n│   ├── agent-view-smoke.sh     # Native Agent View compatibility smoke gate\n│   ├── goal-mode-doctor.sh     # Static native /goal readiness doctor\n│   ├── goal-mode-smoke.sh      # Native /goal compatibility smoke gate\n│   ├── parallel-capacity.sh     # Hardware-aware parallel budget profile\n│   ├── parallel-smoke.sh        # Parallel mode production-contract smoke test\n│   ├── agentfactory-smoke.sh    # Agent Factory production-contract smoke test\n│   └── detect-hardware.sh       # Auto-detect agent pool\n├── memory/                      # Python memory package (SQLite + FTS5)\n│   ├── sqlite_db.py\n│   ├── causal.py                # Causal graph tracking\n│   ├── consolidation.py          # Memory consolidation\n│   └── cli.py                   # Memory CLI entry point\n├── obsidian/Memory/             # Flat-file memory (git-tracked)\n│   ├── Decisions/               # Semantic tier\n│   ├── Patterns/                # Procedural tier\n│   ├── Errors/                  # Error-solution tier\n│   ├── Stories/                 # Graph tier\n│   │   └── commits/            # Commit summaries (auto-generated)\n├── .minimaxing/\n│   └── state/                  # Generated current-task handoff, snapshots, and events\n└── .taste/\n    ├── sessions/                # Episodic tier (daily JSONL)\n    ├── workflow-runs/           # Research/audit/plan/verification artifacts\n    ├── specs/                   # Archived completed or superseded specs\n    └── taste.memory             # Append-only decision log\n```\n\n---\n\n## License\n\nminmaxing is licensed under [Apache-2.0](LICENSE).\n\nThe open-source license covers this public core. It does not grant rights to\nprivate REVCLI/Revis runtime code, customer deployments, customer data,\nproduction credentials, managed-service operations, or project branding beyond\nthe limited trademark language in Apache-2.0. See\n[COMMERCIAL.md](COMMERCIAL.md) and\n[TRADEMARKS.md](TRADEMARKS.md) for the\ncommercial and brand boundary.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwaitdeadai%2Fminmaxing","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwaitdeadai%2Fminmaxing","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwaitdeadai%2Fminmaxing/lists"}