Mochi

Canon status: Current reference.

Mochi is an open-source, avatar-forward AI-native game controller and voice-first desktop companion: one player-owned AI gaming buddy, one durable player memory, and a standard way for compatible games to summon the agent through official contracts, APIs, MCP tools, signed wake events, legal affordances, and server-side validation.

Mochi lives on the owner's desktop while they play. She is quiet in the tray until summoned or a compatible game announces a session, then appears as a small body with a voice-first Perch for conversation, Cards for decisions, and a public-safe Stage for streaming. She plays with you, not for you. By default she is a female-presenting, Gen Z-ish gamer buddy: warm, playful, chat-native, and allowed to use cute streamer energy as seasoning. She can act while you are away, but she stays inside the game rules, remembers what matters, and brings you back when the moment deserves your hand.

The canonical documentation hierarchy, status vocabulary, and conflict rules live in docs/canon/README.md. Active or branch-only work is tracked separately in docs/canon/in-progress.md so planned behavior is not confused with what is available on main.

What Mochi Is

Mochi is being built for games that explicitly choose to support AI-agent play. A compatible game owns the truth: state, secrets, legal actions, validation, and outcomes stay server-authoritative. Mochi owns companion continuity, play style, legal decisioning, memory proposals, and debriefs. Internally, Mochi is building toward a console for AI-native games, but the open-source v0 should not overpromise a hosted store or managed console before the controller loop works.

The current owner-facing compatible-game examples are:

• Prom13us as the first Level 4 agent-native reference game.
• Rizz My Robot as a second proof for a very different social game loop.
• Sitrep as the first tactical command proof, using a fixture-backed adapter, opt-in local HTTP smoke client, and general-plus-soldier roster path.

The long-term goal is a controller standard that third-party studios can adopt without handing Mochi hidden mechanics or asking it to impersonate a human player.

Studios can start with the Studio Quickstart, which walks from a game-owned mochi-game.json contract to official reads, one server-validated legal intent, signed wakes, and local conformance checks.

What Mochi Is Not

Mochi is not:

• AI cheating software.
• A bot that plays arbitrary human games.
• A screen scraper, input injector, process reader, memory reader, packet inspector, aim assistant, or anti-cheat bypass.
• NPC middleware.
• A generic "AI plays any game" harness.

Mochi should refuse unsupported games and cheating-shaped requests. Future game actions must go through explicit game contracts, sanctioned state and affordance APIs, signed wake events, legal intent submission, and server-side validation. The official unsupported-game refusal policy lives in docs/policy/unsupported-games.md.

Desktop Companion

The desktop overlay is the primary owner-facing companion surface. It reuses the existing Mochi Agent, Gateway conversation runtime, memory, commentary renderer, and human-control bridge; it is not a second agent or controller.

• Body: transparent, frameless avatar window with click-through regions.
• Perch: one durable owner conversation stream for text, PTT transcripts, voice replies, and inline cards.
• Cards: owner-control prompts using approve, deny, edit, takeover, and cancel.
• Stage: separate transparent OBS surface containing only public-safe commentary and avatar events.
• Tray: dormant, summon, offline, and session access without stealing focus.

Voice input is push-to-talk only. Speech recognition and speech synthesis are provider-backed Gateway operations; voice-in-transit to those services is disclosed during setup and in the desktop companion privacy boundary. Raw audio is not stored by the overlay. Focus mode silences every companion sound, including her voice, while text remains available in the Perch.

The current repository/build path launches the companion with mochi companion launch after setup. The signed, OS-matched desktop distribution is still release-gated; the overlay is not an npm package. See docs/desktop/companion.md, docs/releases/desktop-qa-runbook.md, and docs/releases/code-signing-procurement.md.

Why Agent-Native Games Need A Controller

Agent-native games are designed around persistent AI players, companions, or co-pilots that can safely participate when the human is present or away. That needs different infrastructure from ordinary automation:

• The game must declare exactly what Mochi may see and do.
• The game must validate every proposed action.
• The human must be able to coach, approve, override, and inspect decisions.
• Memory must survive sessions without turning manual notes into game canon.
• Debriefs and commentary must explain outcomes without leaking hidden mechanics.

Mochi exists to make those boundaries normal instead of improvised for every game.

Architecture Sketch

The v0 runtime shape is a player-owned daemon and Gateway with the desktop companion as the primary owner surface. The localhost dashboard remains the operator shell for readiness, traces, memory guidance, and Gateway control. Telegram is an optional away lane; the CLI remains the operator and proof surface. Games call Mochi directly when something needs attention, and current local proofs exercise parts of that path without opening public ingress or claiming production game play.

compatible game
  -> signed wake event
  -> Mochi daemon
  -> fresh game state and legal affordances
  -> policy, model, or human approval route
  -> legal intent or no-op
  -> game server validates outcome
  -> trace, memory proposal, and public-safe debrief

Core surfaces in the v0 track:

• avatar-forward desktop companion overlay for conversation, voice, cards, presence, and public-safe Stage output
• localhost-only dashboard operator shell for readiness, traces, memory guidance, overlay health, and Gateway control
• Telegram as an optional away and pairing lane, with Discord remaining the Sitrep voice-bridge surface
• local or VPS daemon using the same protocol across deployments
• terminal commands for setup, status, game connection, memory, and doctor checks
• local workspace files such as BOOTSTRAP.md, MOCHI.md, PLAYER.md, MEMORY.md, and per-game strategy.md; legacy companion files remain readable during migration
• mochi-game.json contracts for game authority
• durable signed wakes, Gateway run state, replayable checkpoints, provider-safe Active Context, model-generation calls, trusted-adapter receipts, and redacted debriefs

Architecture vocabulary is defined in docs/architecture/vocabulary.md: the Mochi Agent is the persistent companion; the Mochi Controller Engine is the daemon runtime; the Mochi SDK is game-developer helper glue; the Game Connector is game-owned integration code; and the Game Server owns truth and validates outcomes.

Gateway vocabulary is defined in docs/gateway/overview.md: Mochi Gateway is the player-owned local/VPS/game-colocated controller process around one Mochi Agent and many compatible game sessions. It may coordinate bounded internal child runs for compatible-game subagent lanes and operator/developer verification work, but it is not a consumer multi-agent gateway, generic MCP proxy, relay inbox, hosted service, or game-owned connector.

Markdown identity, memory, and strategy files guide Mochi. Deterministic hooks, policy validators, contract checks, approval gates, and server-side validation enforce what Mochi may actually do.

Protocol interop stays layered: mochi-game.json owns game authority, MCP is a tool/context transport, AG-UI-style events are for user-visible status, and A2A is reserved for later agent-to-agent discovery and coordination.

A Mochi agent card gives compatible games a public-safe way to discover an instance's supported games, capabilities, modalities, auth requirements, budgets, and availability before sending wakes.

Compatibility Levels

Mochi compatibility is a ladder:

Compact level markers: | 0 |, | 1 |, | 2 |, | 3 |, | 4 |.

| Level | Name | Meaning | | ----- | -------------- | --------------------------------------------------------------------------------- | | 0 | Documented | The game exposes docs or read-only APIs. Mochi can learn rules but cannot act. | | 1 | Legal Actions | The game exposes official state, affordances, and submit-intent endpoints. | | 2 | Game Summons | The game can wake Mochi through signed, durable, replay-safe events. | | 3 | Companion Loop | The game supports debriefs, coaching, memory deltas, no-op reasons, and takeover. | | 4 | Agent-Native | The game design structurally depends on Mochi-like persistent AI players. |

Prom13us should become the first Level 4 reference implementation. Rizz My Robot should prove the protocol works outside long-running world simulation. For current self-serve local conformance examples, see examples/compatibility-levels/.

Safety Boundary

Mochi-compatible games must be explicit opt-ins. A game contract should define auth, game id, contract version, transports, wake reasons, endpoints, MCP tools, action affordance schema, redaction rules, issue routing, and anti-cheat boundaries.

Official Mochi no-ops for games without trusted Mochi-compatible contracts, unsupported human games, screen scraping, input injection, hidden-state reads, packet inspection, anti-cheat bypass, and terms-of-service evasion. This is a public product boundary, not a license restriction on forks.

The game remains authoritative for:

• canon state
• hidden mechanics
• legality checks
• accepted or rejected outcomes
• redaction rules
• security-sensitive report routing

Mochi memory edits are not game truth. Manual contract edits must be treated as untrusted until revalidated against a trusted signed or fetched copy.

Project Status

Mochi is pre-alpha. The repository currently has a Bun + TypeScript monorepo, contract schemas, wake storage, policy/memory/workspace primitives, a daemon status/readiness surface, a localhost-only dashboard shell with readiness, contract trust, tool inspection, replay review, active-context inspection, and memory guidance panels, local conformance tooling, provider-neutral auth and model-generation runtime with OpenAI as the active owner route, CLI talk, Gateway conversation runs, provider-planned mock-game wake-to-receipt proof, Prom13us and Rizz adapter packages, explicit-config live Telegram delivery and Bot API polling primitives, tests, canonical commentary-mode planning, and planning docs. The local V0 owner proof lives in docs/runtime/v0-manual-proof.md.

Owner First Run

Run mochi setup first. When the desktop overlay build is installed, launch it with mochi companion launch; the first owner conversation, readiness interview, voice controls, and approval cards belong in the Perch. Use push-to-talk for voice input and keep text as the durable fallback.

Use mochi doctor for the local readiness ladder. It reports overlay connectivity, mic permission, rig assets, voice-key validity, and service liveness when those facts are available, without starting the overlay, calling providers, polling Telegram, or changing game state. The dashboard is the localhost operator shell for deeper inspection; it is not a second conversation surface.

When the owner is away from the desktop, Telegram remains an optional paired lane. Send start interview to the paired bot only when that away lane is configured. The bounded Game Readiness Interview can resume after restarts, reset on owner request, and produce reviewable bootstrap/profile/play-contract proposal bundles. Approved profile decisions write only through the existing checkpointed bootstrap/profile apply path; play-contract decisions stay review-only, and game-patch writes remain blocked until a checkpointed game-patch apply lane exists.

The mock-game onboarding proof may reference the completed Telegram interview with mochi onboard mock-game-proof --confirm --interview-ref <ref>. That ref is owner-context metadata only. It is not game canon, does not change legal moves, and does not give Mochi authority outside the compatible-game contract.

The canonical Telegram commentary-mode plan lives in docs/telegram/commentary-mode.md. It defines co-watching versus away commentary, Telegram draft/final-message semantics, viewer-presence requirements, reply/memory-proposal boundaries, and the implementation PR sequence. Shared CommentaryCandidate and ViewerPresenceSignal schemas now live in @mochi/contracts, with thin game-facing validation helpers in @mochi/game-sdk. The deterministic commentary budget resolver lives in @mochi/policy and applies quiet hours, away-mode filtering, activation notice idempotency, hype bursts, and the one-final-message cadence. The deterministic commentary renderer lives in @mochi/debrief; it turns sendable commentary decisions into local, public-safe text and live-activation notice copy without provider calls. The Gateway commentary Telegram dispatcher now queues that rendered output through the durable outbox and proves fake rich final delivery while keeping draft telemetry ephemeral. The Gateway soft-prompt bridge now turns safe paired Telegram replies to unexpired commentary questions into pending memory patch proposals, without executing commands, submitting game actions, or writing durable memory directly. The Gateway model-written/hybrid commentary renderer now uses bounded provider context only when the owner-selected renderer allows it, records cost posture, falls back deterministically on provider or safety failures, and normalizes sendable model text into the existing commentary Telegram outbox payload. The Prom13us commentary local proof now converts public-safe Prom13us notification debriefs into commentary candidates, resolves live versus away presence, streams ephemeral co-watching draft telemetry, and proves final fake Telegram delivery evidence without live production credentials.

Mochi still does not publish preferred @mochi/* player packages, host certification, open live HTTP ingress by default, expose public dashboard ingress, provide dashboard game control panels, run production Prom13us/Rizz play outside compatible-game contracts and server-validated proofs, support unsupported games, execute arbitrary live MCP tools, provide hosted accounts, or mutate game canon outside trusted game-owned validation.

Mochi uses the Apache-2.0 license. See CONTRIBUTING.md, SECURITY.md, and PRIVACY.md before opening public contributions, reporting vulnerabilities, or experimenting with local data.

Issue-reporting consent and attribution rules live in docs/privacy/issue-reporting.md. Mochi does not silently file issues under the player or use signed-out GitHub filing as a default.

Local repair candidate planning lives in docs/issue-reporting/repair-candidates.md. Runtime workspace edits and source repair are separate lanes. Local profile/memory/config edits tune the owner's Mochi workspace and do not need a GitHub PR. Source-code, package metadata, test, release, and repository changes belong in the maintainer repair lane below: plan/proposal, approved isolated worktree apply, verification ledger, authorization, and a reviewed pull request. A PR is the public source-code/package change record for open-source Mochi, not the mechanism for local personality or memory notes. mochi repair plan --fixture failing-test turns fixture-backed local failure evidence into a redacted mochi.repair.plan RepairCandidate while keeping commandsExecuted: false, networkFiled: false, and codePushed: false. mochi repair proposal --fixture failing-test --workspace-root <repo> converts that evidence into a pending RepairProposal with workspace-relative target files, real target digests, validation commands, rollback notes, maintainer approval, and no current file writes or GitHub side effects. createRepairWorktreePlan() then records an API-only repair worktree plan with origin/main, branch name, sibling worktree path, dirty-checkout policy, cleanup commands, worktreeCreated: false, and codePushed: false. mochi repair apply --proposal <path> --patch <path> --approval-ref <ref> can then consume a maintainer-approved RepairProposal plus a local mochi.repair.patch full-file replacement artifact inside that isolated worktree. It checks approval, branch/base refs, target digests, and dirty WIP, writes only approved source files, returns mochi.repair.apply with a rollback command, and still reports codePushed: false and pullRequestCreated: false. After apply, mochi.repair.verification_report records required validation command metadata with redacted summaries and a local mochi.repair.report_ledger_event; repairs keep canAdvanceToPr: false until every proposal validation command passes and the ledger proof exists. See docs/issue-reporting/repair-verification.md. mochi.repair.github_authorization_dry_run then proves, without a live GitHub call, whether a future repair branch push and PR creation would be authorized by allowed repositories, identity mode, explicit approval, contentsWrite, pullRequestsWrite, base/head refs, labels, and verification ledger proof. It can emit mochi.repair.github_pull_request_intent, but still keeps networkFiled: false, codePushed: false, and pullRequestCreated: false. createOrUpdateRepairGitHubPullRequest() can then create or update the repair PR only after an exact create_or_update_pull_request maintainer approval for the same repository, identity, proposal, base/head branches, title, body digest, labels, and intent digest. It records mochi.repair.github_pull_request_result and mochi.repair.github_pull_request_audit_entry with the PR URL and redacted digest evidence; this live PR step sets networkFiled: true while keeping branchPushed: false, codePushed: false, hosted telemetry false, and no auto-merge. mochi.repair.pr_review_revision lets Mochi convert selected maintainer comments on that repair PR into a new pending RepairProposal revision without expanding authority. It rejects a stale repair branch, keeps pullRequestUpdated: false, and leaves the update gate closed with revision_requires_separate_approval_apply_and_verification until the revision is separately approved, applied, verified, ledgered, and authorized. There is no autonomous comment polling, no CI bypass, and no self-merge. See docs/issue-reporting/repair-github-authorization.md. Review-loop details live in docs/issue-reporting/repair-review-loop.md. self-repair-e2e is the reproducible local proof fixture for the whole bounded source-repair lane: detect, propose, approve, apply, verify, report, mocked PR intent. It records mochi.repair.self_repair_e2e_proof without live PR creation, package update apply, or game-runtime repair. See docs/issue-reporting/self-repair-e2e-proof.md.

Player Install

Mochi is pre-alpha, and the current fallback CLI package is registry-proven in docs/releases/current-cli-package.json and docs/releases/package-provenance.md by trusted publishing plus npm view proof. The public player install path is npm/npx, not cloning the repository and running Bun.

Because @mochi/* npm ownership is not proven, the fallback package scope is the current public install target. The one-line player install is:

npm install -g @rizzmyrobot/mochi-cli
mochi setup

mochi setup is the player first-run command. In an interactive terminal it runs a real guided setup for managed OpenAI/ChatGPT or an explicit OpenAI API key, then offers terminal-only chat, Telegram, or Discord. Setup seeds the proof workspace, writes local runtime config refs, stores local secrets, validates selected Telegram bot tokens with the Bot API getMe check, and prints a concise current setup and next step. Detailed redacted audit output stays behind --format json. Existing MiniMax-era configs are readable, but they enter an explicit migration_required recovery flow. New owners never see MiniMax as an active provider choice, and MiniMax OAuth refresh or credential creation is not part of the owner path. The retained broker and protocol fixtures are operator rollback evidence only. Slack has a shipped opt-in Socket Mode runtime, but it is not a mochi setup selection yet. Non-interactive mochi setup --guide remains a no-write preview for CI, docs, and scripts.

OpenAI API-key refs, Telegram config, workspace seed files, local provider credential refs, and local Telegram token refs reuse the existing provider auth, configure, proof workspace seed, Telegram, Gateway, and secret-store packages. Managed ChatGPT login now has a Mochi-owned, exact-version codex app-server provider lane. Installed Mochi owner chat selects that subscription lane when the connection is ready; signed out, incompatible, or kill-switched connections stop with an explicit recovery message instead of silently spending OpenAI API credits. The lane remains release-gated until the installed package, dual-target desktop, containment, and credentialed product-live proofs in docs/releases/chatgpt-primary-provider.md are current. The external codex login command is not the Mochi provider path. Discord, Slack, and Matrix remain Tier 2 product choices. Discord now has an installed local command runtime with provider-free install, REST, command-registration, Gateway-driver, diagnostic, and guild voice-control proofs, plus an explicit opt-in live guild smoke for maintainers. Default Discord live delivery is still off, Matrix E2EE and ciphertext storage remain deferred for v0, and iMessage and Signal are mocked Tier 3 owner-only local wrappers, not public support channels.

npx follows the same fallback scope:

npx @rizzmyrobot/mochi-cli setup
npx @rizzmyrobot/mochi-cli help
npx @rizzmyrobot/mochi-cli help advanced
npx @rizzmyrobot/mochi-cli gateway status
npx @rizzmyrobot/mochi-cli doctor repair --workspace-root ~/.mochi/workspace --confirm
npx @rizzmyrobot/mochi-cli tools doctor --workspace-root ~/.mochi/workspace --game mock-game

If maintainers later prove the @mochi/* npm scope is controlled by the project, the same player commands use the preferred package name:

npm install -g @mochi/cli
npx @mochi/cli setup
npx @mochi/cli gateway status
mochi setup

Current fallback CLI install gateway start --profile local --foreground can start the proven local live foreground runtime on loopback. gateway status and gateway doctor report not_running when nothing is reachable and probe the configured loopback live service when it is running. Dry-run planning remains available for setup review, and gateway install-service proposal plus gateway install-service apply or gateway install-service --apply can write/remove owner-approved local launchd or gated VPS systemd files without loading or starting them. The guarded apply result carries status and rollback evidence for later hosted-ingress observability gates. proposal review --proposal <path> renders the same reviewed runtime-config or gateway service proposal artifact for terminal owner review before apply, with redacted fields only and no file writes.

Interactive mochi setup may write local workspace seed files, runtime config refs, and local secrets; legacy MiniMax routes enter migration recovery and do not create or refresh credentials. Telegram setup may call only the Bot API getMe validation endpoint. It does not call model providers, poll Telegram, send Telegram messages, connect Discord, connect production games, submit production intents, or change game canon. The separate credentialed talk command can call a selected model provider for a local Mochi reply; contributor/runtime docs describe the local owner proof for credentialed provider and Telegram conversation, and the mock-game proof exercises a fixture provider response plus a trusted local adapter receipt.

When setup is locally broken, mochi doctor repair --confirm runs the narrow self-repair lane. It may create only missing known workspace seed templates and the workspace attestation marker through existing proof primitives. It does not edit source code, install packages, rewrite memory truth, rewrite contracts, apply bootstrap/profile truth, call providers, poll Telegram, start Gateway, connect games, submit intents, or mutate game canon.

The local laptop Gateway install flow lives in docs/gateway/local-install.md. The player onboarding map lives in docs/onboarding/player.md.

mochi proof config-mutation --workspace-root <path> proves the owner-approved local config mutation loop without source-code repair, package updates, GitHub calls, Gateway service changes, provider calls, Telegram polling/sending, game actions, or game-canon mutation. The JSON payload type is mochi.cli.config_mutation_proof; it writes reviewable proposal artifacts, applies them through configure apply, runs configure status, and prints rollback metadata for the local runtime checkpoints. Live credential readiness is still reported separately inside status. configure status also dry-runs profile default adoption and points owners to mochi profile adopt-defaults when local MOCHI.md differs from the current packaged gamer-buddy and AI-native game-purpose defaults.

Game Developer SDK Install

Game developers install the current SDK package cone from npm with fallback package names. Until the preferred @mochi/* scope is proven and published, use:

npm install @rizzmyrobot/mochi-game-sdk @rizzmyrobot/mochi-contracts

Preferred @mochi/* package names remain a future migration condition, not a studio install command, until release docs record maintainer npm-scope control and registry proof for the exact preferred package versions.

The SDK helps studios expose game-owned contracts, state, affordances, signed wakes, legal intent validation, and receipts. It does not transfer game canon or hidden mechanics to Mochi. The studio onboarding map lives in docs/onboarding/studio.md.

Contributor Setup

Contributors use Bun inside the monorepo:

bun install
bun run verify
bun run cli -- status
bun run daemon
bun run cli -- dashboard --dry-run
bun run cli -- dashboard --contract tests/fixtures/contracts/valid-mochi-game.json --dry-run
bun run cli -- dashboard --trace-db ./decision-traces.sqlite --dry-run
bun run cli -- dashboard --memory-db ./memory.sqlite --dry-run
bun run cli -- gateway start --profile local --foreground
# optional, writes local proof artifacts/config/checkpoints under the workspace
bun run cli -- proof config-mutation --workspace-root ~/.mochi/workspace --format json
# optional, requires real owner-supplied provider and Telegram credentials
bun run cli -- configure proposal provider --workspace-root . --provider openai --model <model> --credential-ref secret:providers/openai/default --format json > /tmp/mochi-provider-config-proposal.json
bun run cli -- proposal review --proposal /tmp/mochi-provider-config-proposal.json
bun run cli -- configure apply --proposal /tmp/mochi-provider-config-proposal.json --approval-ref <approval-ref-from-proposal>
bun run cli -- configure proposal telegram --workspace-root . --owner owner-local --telegram-user-id <telegram-user-id> --bot-token-ref os:mochi/telegram/bot-token --format json > /tmp/mochi-telegram-config-proposal.json
bun run cli -- proposal review --proposal /tmp/mochi-telegram-config-proposal.json
bun run cli -- configure apply --proposal /tmp/mochi-telegram-config-proposal.json --approval-ref <approval-ref-from-proposal>
bun run cli -- configure provider --workspace-root . --provider openai --model <model> --credential-ref secret:providers/openai/default --credential-stdin
bun run cli -- configure telegram --workspace-root . --owner owner-local --telegram-user-id <telegram-user-id> --bot-token-ref os:mochi/telegram/bot-token --bot-token-stdin
bun run cli -- provider validate --workspace-root .
bun run cli -- telegram validate --workspace-root .
bun run cli -- talk --workspace-root . --game example-arena --message "Hello Mochi"
bun run cli -- telegram listen --poll-once --workspace-root . --game example-arena
bun run proof:live-owner -- --workspace-root . --game example-arena --skip-telegram
bun run --cwd examples/mock-game gateway-proof
bun run --cwd examples/mock-game vps-ingress-proof
bun run --cwd examples/mock-game relay-inbox-proof
# optional, requires a real local Sitrep V0 server
SITREP_LOCAL_BASE_URL=http://127.0.0.1:3000/mochi/v0/ bun run proof:sitrep-local-smoke
# optional local bearer auth, when Sitrep uses SITREP_MOCHI_V0_TOKEN,
# SITREP_MOCHI_V0_BLUE_TOKEN, or SITREP_MOCHI_V0_RED_TOKEN for the selected side
SITREP_LOCAL_BASE_URL=http://127.0.0.1:3000/mochi/v0/ SITREP_LOCAL_AUTH_TOKEN=dev-secret bun run proof:sitrep-local-smoke
bun run release:cli-package-dry-run -- --out-dir dist/package-dry-runs/cli --scope fallback

Contributor commands only prove the repository shell and local dry-run package shape. The credentialed talk command can call a selected model provider for a local Mochi reply, and the credentialed telegram listen command can answer owner DMs through the same Gateway conversation handler after local CLI configuration. telegram listen --format json includes a runtime object with the CLI package name, version, package scope, and command path; capture it when debugging Telegram so a stale global install is not mistaken for the active checkout. These contributor commands do not install a player controller from npm, connect to live games, connect to unsupported games, submit intents, or change game canon. Mochi does not connect to unsupported games.

For the redacted local V0 owner proof, use docs/runtime/v0-manual-proof.md. It shows the bun run proof:live-owner wrapper plus the CLI and Telegram transcript fields to capture without leaking provider keys, Telegram bot tokens, private prompts, or hidden game state.

The current gateway proofs are contributor-only: the mock-game proof exercises one local compatible game, the Prom13us gateway dry-run proves signed wake routing, read-only context, no-op output, trace/debrief/audit, and no canon write without production Prom13us credentials, and the Sitrep V0 local smoke adapter proves an opt-in real-server submission path through the same HTTP adapter used by the bridge-backed tests. The contributor onboarding map lives in docs/onboarding/contributor.md.

Development Plan

The saved section-based sprint plan lives at docs/research/mochi-agent-native-controller-plan.md.

Early foundation work is intentionally sequenced:

1. Repo scaffold.
2. README product front door and boundary.
3. Open-source license decision ADR.
4. LICENSE file and SPDX/package metadata.
5. Package layout and shared TypeScript config.
6. Test harness and CI commands.
7. Contribution and security-reporting rules.

Each PR should introduce one durable concept, prove it, document it, and avoid weakening the anti-cheat boundary.