@rizzmyrobot/mochi-cli 0.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +202 -0
- package/README.md +334 -0
- package/bin/mochi.mjs +4 -0
- package/dist/index.js +60565 -0
- package/package.json +18 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright [yyyy] [name of copyright owner]
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
package/README.md
ADDED
|
@@ -0,0 +1,334 @@
|
|
|
1
|
+
# Mochi
|
|
2
|
+
|
|
3
|
+
Mochi is an open-source AI-native game controller: one persistent AI gaming
|
|
4
|
+
companion, one durable player memory, and a standard way for compatible games
|
|
5
|
+
to summon the agent through official contracts, APIs, MCP tools, signed wake
|
|
6
|
+
events, legal affordances, and server-side validation.
|
|
7
|
+
|
|
8
|
+
Mochi plays with you, not for you. It can act while you are away, but it stays
|
|
9
|
+
inside the game rules, remembers what matters, and brings you back when the
|
|
10
|
+
moment deserves your hand.
|
|
11
|
+
|
|
12
|
+
## What Mochi Is
|
|
13
|
+
|
|
14
|
+
Mochi is being built for games that explicitly choose to support AI-agent play.
|
|
15
|
+
A compatible game owns the truth: state, secrets, legal actions, validation, and
|
|
16
|
+
outcomes stay server-authoritative. Mochi owns companion continuity, play style,
|
|
17
|
+
legal decisioning, memory proposals, and debriefs. Internally, Mochi is building
|
|
18
|
+
toward a console for AI-native games, but the open-source v0 should not
|
|
19
|
+
overpromise a hosted store or managed console before the controller loop works.
|
|
20
|
+
|
|
21
|
+
The first target ecosystem is:
|
|
22
|
+
|
|
23
|
+
- Prom13us as the first Level 4 agent-native reference game.
|
|
24
|
+
- Rizz My Robot as a second proof for a very different social game loop.
|
|
25
|
+
- Sitrep later, once the protocol can handle faster tactical decisions.
|
|
26
|
+
|
|
27
|
+
The long-term goal is a controller standard that third-party studios can adopt
|
|
28
|
+
without handing Mochi hidden mechanics or asking it to impersonate a human
|
|
29
|
+
player.
|
|
30
|
+
|
|
31
|
+
Studios can start with the
|
|
32
|
+
[`Studio Quickstart`](docs/studios/quickstart.md), which walks from a
|
|
33
|
+
game-owned `mochi-game.json` contract to official reads, one server-validated
|
|
34
|
+
legal intent, signed wakes, and local conformance checks.
|
|
35
|
+
|
|
36
|
+
## What Mochi Is Not
|
|
37
|
+
|
|
38
|
+
Mochi is not:
|
|
39
|
+
|
|
40
|
+
- AI cheating software.
|
|
41
|
+
- A bot that plays arbitrary human games.
|
|
42
|
+
- A screen scraper, input injector, process reader, memory reader, packet
|
|
43
|
+
inspector, aim assistant, or anti-cheat bypass.
|
|
44
|
+
- NPC middleware.
|
|
45
|
+
- A generic "AI plays any game" harness.
|
|
46
|
+
|
|
47
|
+
Mochi should refuse unsupported games and cheating-shaped requests. Future game
|
|
48
|
+
actions must go through explicit game contracts, sanctioned state and affordance
|
|
49
|
+
APIs, signed wake events, legal intent submission, and server-side validation.
|
|
50
|
+
The official unsupported-game refusal policy lives in
|
|
51
|
+
[`docs/policy/unsupported-games.md`](docs/policy/unsupported-games.md).
|
|
52
|
+
|
|
53
|
+
## Why Agent-Native Games Need A Controller
|
|
54
|
+
|
|
55
|
+
Agent-native games are designed around persistent AI players, companions, or
|
|
56
|
+
co-pilots that can safely participate when the human is present or away. That
|
|
57
|
+
needs different infrastructure from ordinary automation:
|
|
58
|
+
|
|
59
|
+
- The game must declare exactly what Mochi may see and do.
|
|
60
|
+
- The game must validate every proposed action.
|
|
61
|
+
- The human must be able to coach, approve, override, and inspect decisions.
|
|
62
|
+
- Memory must survive sessions without turning manual notes into game canon.
|
|
63
|
+
- Debriefs must explain outcomes without leaking hidden mechanics.
|
|
64
|
+
|
|
65
|
+
Mochi exists to make those boundaries normal instead of improvised for every
|
|
66
|
+
game.
|
|
67
|
+
|
|
68
|
+
## Architecture Sketch
|
|
69
|
+
|
|
70
|
+
The v0 runtime shape is an OpenClaw-like daemon and Gateway with
|
|
71
|
+
Telegram-first human coaching and terminal access. Games call Mochi directly
|
|
72
|
+
when something needs attention, and current local proofs exercise parts of that
|
|
73
|
+
path without opening public ingress or claiming production game play.
|
|
74
|
+
|
|
75
|
+
```text
|
|
76
|
+
compatible game
|
|
77
|
+
-> signed wake event
|
|
78
|
+
-> Mochi daemon
|
|
79
|
+
-> fresh game state and legal affordances
|
|
80
|
+
-> policy, model, or human approval route
|
|
81
|
+
-> legal intent or no-op
|
|
82
|
+
-> game server validates outcome
|
|
83
|
+
-> trace, memory proposal, and public-safe debrief
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
Core surfaces in the v0 track:
|
|
87
|
+
|
|
88
|
+
- local or VPS daemon using the same protocol across deployments
|
|
89
|
+
- Telegram as the primary coaching and approval channel, with explicit-config
|
|
90
|
+
live delivery and Bot API polling primitives
|
|
91
|
+
- terminal commands for setup, status, game connection, memory, and doctor checks
|
|
92
|
+
- local workspace files such as `BOOTSTRAP.md`, `IDENTITY.md`, `SOUL.md`,
|
|
93
|
+
`PLAYER.md`, `GAMING_MANIFESTO.md`, and per-game `strategy.md`
|
|
94
|
+
- `mochi-game.json` contracts for game authority
|
|
95
|
+
- durable signed wakes, Gateway run state, replayable checkpoints, provider-safe
|
|
96
|
+
Active Context, model-generation calls, trusted-adapter receipts, and redacted
|
|
97
|
+
debriefs
|
|
98
|
+
|
|
99
|
+
Architecture vocabulary is defined in
|
|
100
|
+
[`docs/architecture/vocabulary.md`](docs/architecture/vocabulary.md): the Mochi
|
|
101
|
+
Agent is the persistent companion; the Mochi Controller Engine is the daemon
|
|
102
|
+
runtime; the Mochi SDK is game-developer helper glue; the Game Connector is
|
|
103
|
+
game-owned integration code; and the Game Server owns truth and validates
|
|
104
|
+
outcomes.
|
|
105
|
+
|
|
106
|
+
Gateway vocabulary is defined in
|
|
107
|
+
[`docs/gateway/overview.md`](docs/gateway/overview.md): Mochi Gateway is the
|
|
108
|
+
planned player-owned local/VPS/game-colocated controller process around one
|
|
109
|
+
Mochi Agent and many compatible game sessions. It is not a consumer multi-agent
|
|
110
|
+
gateway, generic MCP proxy, relay inbox, hosted service, or game-owned
|
|
111
|
+
connector.
|
|
112
|
+
|
|
113
|
+
Markdown identity, memory, and strategy files guide Mochi. Deterministic hooks,
|
|
114
|
+
policy validators, contract checks, approval gates, and server-side validation
|
|
115
|
+
enforce what Mochi may actually do.
|
|
116
|
+
|
|
117
|
+
Protocol interop stays layered: `mochi-game.json` owns game authority, MCP is a
|
|
118
|
+
tool/context transport, AG-UI-style events are for user-visible status, and A2A
|
|
119
|
+
is reserved for later agent-to-agent discovery and coordination.
|
|
120
|
+
|
|
121
|
+
A Mochi agent card gives compatible games a public-safe way to discover an
|
|
122
|
+
instance's supported games, capabilities, modalities, auth requirements,
|
|
123
|
+
budgets, and availability before sending wakes.
|
|
124
|
+
|
|
125
|
+
## Compatibility Levels
|
|
126
|
+
|
|
127
|
+
Mochi compatibility is a ladder:
|
|
128
|
+
|
|
129
|
+
| Level | Name | Meaning |
|
|
130
|
+
| --- | --- | --- |
|
|
131
|
+
| 0 | Documented | The game exposes docs or read-only APIs. Mochi can learn rules but cannot act. |
|
|
132
|
+
| 1 | Legal Actions | The game exposes official state, affordances, and submit-intent endpoints. |
|
|
133
|
+
| 2 | Game Summons | The game can wake Mochi through signed, durable, replay-safe events. |
|
|
134
|
+
| 3 | Companion Loop | The game supports debriefs, coaching, memory deltas, no-op reasons, and takeover. |
|
|
135
|
+
| 4 | Agent-Native | The game design structurally depends on Mochi-like persistent AI players. |
|
|
136
|
+
|
|
137
|
+
Prom13us should become the first Level 4 reference implementation. Rizz My Robot
|
|
138
|
+
should prove the protocol works outside long-running world simulation.
|
|
139
|
+
|
|
140
|
+
## Safety Boundary
|
|
141
|
+
|
|
142
|
+
Mochi-compatible games must be explicit opt-ins. A game contract should define
|
|
143
|
+
auth, game id, contract version, transports, wake reasons, endpoints, MCP tools,
|
|
144
|
+
action affordance schema, redaction rules, issue routing, and anti-cheat
|
|
145
|
+
boundaries.
|
|
146
|
+
|
|
147
|
+
Official Mochi no-ops for games without trusted Mochi-compatible contracts,
|
|
148
|
+
unsupported human games, screen scraping, input injection, hidden-state reads,
|
|
149
|
+
packet inspection, anti-cheat bypass, and terms-of-service evasion. This is a
|
|
150
|
+
public product boundary, not a license restriction on forks.
|
|
151
|
+
|
|
152
|
+
The game remains authoritative for:
|
|
153
|
+
|
|
154
|
+
- canon state
|
|
155
|
+
- hidden mechanics
|
|
156
|
+
- legality checks
|
|
157
|
+
- accepted or rejected outcomes
|
|
158
|
+
- redaction rules
|
|
159
|
+
- security-sensitive report routing
|
|
160
|
+
|
|
161
|
+
Mochi memory edits are not game truth. Manual contract edits must be treated as
|
|
162
|
+
untrusted until revalidated against a trusted signed or fetched copy.
|
|
163
|
+
|
|
164
|
+
## Project Status
|
|
165
|
+
|
|
166
|
+
Mochi is pre-alpha. The repository currently has a Bun + TypeScript monorepo,
|
|
167
|
+
contract schemas, wake storage, policy/memory/workspace primitives, a daemon
|
|
168
|
+
status/readiness surface, a localhost-only dashboard shell with readiness, contract
|
|
169
|
+
trust, tool inspection, replay review, active-context inspection, and memory
|
|
170
|
+
guidance panels, local conformance tooling, provider auth and OpenAI/MiniMax
|
|
171
|
+
model-generation runtime, CLI talk, Gateway conversation runs, provider-planned
|
|
172
|
+
mock-game wake-to-receipt proof, Prom13us and Rizz adapter packages,
|
|
173
|
+
explicit-config live Telegram delivery and Bot API polling primitives, tests,
|
|
174
|
+
and planning docs. The local V0 owner proof lives in
|
|
175
|
+
[`docs/runtime/v0-manual-proof.md`](docs/runtime/v0-manual-proof.md).
|
|
176
|
+
|
|
177
|
+
Mochi still does not publish player packages, host certification, open live HTTP
|
|
178
|
+
ingress by default, expose public dashboard ingress, provide dashboard game
|
|
179
|
+
control panels, run production Prom13us/Rizz play outside compatible-game
|
|
180
|
+
contracts and server-validated proofs, support unsupported games, execute
|
|
181
|
+
arbitrary live MCP tools, provide hosted accounts, or mutate game canon outside
|
|
182
|
+
trusted game-owned validation.
|
|
183
|
+
|
|
184
|
+
Mochi uses the Apache-2.0 license. See `CONTRIBUTING.md`, `SECURITY.md`, and
|
|
185
|
+
`PRIVACY.md` before opening public contributions, reporting vulnerabilities, or
|
|
186
|
+
experimenting with local data.
|
|
187
|
+
|
|
188
|
+
Issue-reporting consent and attribution rules live in
|
|
189
|
+
[`docs/privacy/issue-reporting.md`](docs/privacy/issue-reporting.md). Mochi
|
|
190
|
+
does not silently file issues under the player or use signed-out GitHub filing
|
|
191
|
+
as a default.
|
|
192
|
+
|
|
193
|
+
## Player Install
|
|
194
|
+
|
|
195
|
+
Mochi is pre-alpha, and package publication is not live yet. The public player
|
|
196
|
+
install path is npm/npx, not cloning the repository and running Bun. Until a
|
|
197
|
+
release publishes trusted packages with provenance, treat these commands as the
|
|
198
|
+
install-ready path under test rather than a live registry claim.
|
|
199
|
+
|
|
200
|
+
Because `@mochi/*` npm ownership is not proven, the fallback package scope is
|
|
201
|
+
the current public install target. The intended one-line player install is:
|
|
202
|
+
|
|
203
|
+
```bash
|
|
204
|
+
npm install -g @rizzmyrobot/mochi-cli
|
|
205
|
+
mochi onboard
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
`mochi onboard` is the player first-run command. It shows provider choices,
|
|
209
|
+
including MiniMax OAuth and Codex OAuth, and channel choices, including
|
|
210
|
+
Telegram and Discord. MiniMax OAuth, OpenAI API-key refs, Telegram config,
|
|
211
|
+
workspace seed files, local provider credential refs, and local Telegram token
|
|
212
|
+
refs reuse the existing provider auth, configure, proof workspace seed,
|
|
213
|
+
Telegram, Gateway, and secret-store packages. Codex OAuth is exposed as the
|
|
214
|
+
external `codex login` path until Mochi has a Codex OAuth provider runtime.
|
|
215
|
+
Discord is exposed as a product choice, but it does not accept or store Discord
|
|
216
|
+
bot tokens until a Discord runtime package exists.
|
|
217
|
+
|
|
218
|
+
npx follows the same fallback scope:
|
|
219
|
+
|
|
220
|
+
```bash
|
|
221
|
+
npx @rizzmyrobot/mochi-cli onboard
|
|
222
|
+
npx @rizzmyrobot/mochi-cli --help
|
|
223
|
+
npx @rizzmyrobot/mochi-cli gateway status --dry-run
|
|
224
|
+
npx @rizzmyrobot/mochi-cli tools doctor --workspace-root ~/.mochi/workspace --game mock-game
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
If maintainers later prove the `@mochi/*` npm scope is controlled by the
|
|
228
|
+
project, the same player commands use the preferred package name:
|
|
229
|
+
|
|
230
|
+
```bash
|
|
231
|
+
npm install -g @mochi/cli
|
|
232
|
+
npx @mochi/cli onboard
|
|
233
|
+
npx @mochi/cli gateway status --dry-run
|
|
234
|
+
mochi onboard
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
Current public install `gateway start/status/doctor` commands remain dry-run
|
|
238
|
+
planning proofs. `mochi onboard` may write local workspace seed files, runtime
|
|
239
|
+
config refs, and local secrets only when `--confirm` plus stdin secret flags are
|
|
240
|
+
provided. It does not call providers, run OAuth token exchange, poll Telegram,
|
|
241
|
+
send Telegram messages, connect Discord, connect games, submit production
|
|
242
|
+
intents, or change game canon. The separate credentialed `talk` command can
|
|
243
|
+
call a selected model provider for a local Mochi reply; contributor/runtime docs
|
|
244
|
+
describe the local owner proof for credentialed provider and Telegram
|
|
245
|
+
conversation, and the mock-game proof exercises a fixture provider response
|
|
246
|
+
plus a trusted local adapter receipt.
|
|
247
|
+
|
|
248
|
+
The local laptop Gateway install flow lives in
|
|
249
|
+
[`docs/gateway/local-install.md`](docs/gateway/local-install.md).
|
|
250
|
+
The player onboarding map lives in
|
|
251
|
+
[`docs/onboarding/player.md`](docs/onboarding/player.md).
|
|
252
|
+
|
|
253
|
+
## Game Developer SDK Install
|
|
254
|
+
|
|
255
|
+
Game developers install the current SDK package cone from npm with fallback
|
|
256
|
+
package names. Until the preferred `@mochi/*` scope is proven and published,
|
|
257
|
+
use:
|
|
258
|
+
|
|
259
|
+
```bash
|
|
260
|
+
npm install @rizzmyrobot/mochi-game-sdk @rizzmyrobot/mochi-contracts
|
|
261
|
+
```
|
|
262
|
+
|
|
263
|
+
Preferred `@mochi/*` package names remain a future migration condition, not a
|
|
264
|
+
studio install command, until release docs record maintainer npm-scope control
|
|
265
|
+
and registry proof for the exact preferred package versions.
|
|
266
|
+
|
|
267
|
+
The SDK helps studios expose game-owned contracts, state, affordances, signed
|
|
268
|
+
wakes, legal intent validation, and receipts. It does not transfer game canon
|
|
269
|
+
or hidden mechanics to Mochi.
|
|
270
|
+
The studio onboarding map lives in
|
|
271
|
+
[`docs/onboarding/studio.md`](docs/onboarding/studio.md).
|
|
272
|
+
|
|
273
|
+
## Contributor Setup
|
|
274
|
+
|
|
275
|
+
Contributors use Bun inside the monorepo:
|
|
276
|
+
|
|
277
|
+
```bash
|
|
278
|
+
bun install
|
|
279
|
+
bun run verify
|
|
280
|
+
bun run cli -- status
|
|
281
|
+
bun run daemon
|
|
282
|
+
bun run cli -- dashboard --dry-run
|
|
283
|
+
bun run cli -- dashboard --contract tests/fixtures/contracts/valid-mochi-game.json --dry-run
|
|
284
|
+
bun run cli -- dashboard --trace-db ./decision-traces.sqlite --dry-run
|
|
285
|
+
bun run cli -- dashboard --memory-db ./memory.sqlite --dry-run
|
|
286
|
+
bun run cli -- gateway start --dry-run --foreground
|
|
287
|
+
# optional, requires real owner-supplied provider and Telegram credentials
|
|
288
|
+
bun run cli -- configure provider --workspace-root . --provider openai --model <model> --credential-ref secret:providers/openai/default --credential-stdin
|
|
289
|
+
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
|
|
290
|
+
bun run cli -- provider validate --workspace-root .
|
|
291
|
+
bun run cli -- telegram validate --workspace-root .
|
|
292
|
+
bun run cli -- talk --workspace-root . --game example-arena --message "Hello Mochi"
|
|
293
|
+
bun run cli -- telegram listen --poll-once --workspace-root . --game example-arena
|
|
294
|
+
bun run release:cli-package-dry-run -- --out-dir dist/package-dry-runs/cli --scope fallback
|
|
295
|
+
```
|
|
296
|
+
|
|
297
|
+
Contributor commands only prove the repository shell and local dry-run package
|
|
298
|
+
shape. The credentialed `talk` command can call a selected model provider for a
|
|
299
|
+
local Mochi reply, and the credentialed `telegram listen` command can answer
|
|
300
|
+
owner DMs through the same Gateway conversation handler after local CLI
|
|
301
|
+
configuration. These contributor
|
|
302
|
+
commands do not install a player controller from npm, connect to live games,
|
|
303
|
+
connect to unsupported games, submit intents, or change game canon.
|
|
304
|
+
Mochi does not connect to unsupported games.
|
|
305
|
+
|
|
306
|
+
For the redacted local V0 owner proof, use
|
|
307
|
+
[`docs/runtime/v0-manual-proof.md`](docs/runtime/v0-manual-proof.md). It shows
|
|
308
|
+
the CLI and Telegram transcript fields to capture without leaking provider
|
|
309
|
+
keys, Telegram bot tokens, private prompts, or hidden game state.
|
|
310
|
+
|
|
311
|
+
The current gateway proofs are contributor-only: the mock-game proof exercises
|
|
312
|
+
one local compatible game, and the Prom13us gateway dry-run proves signed wake
|
|
313
|
+
routing, read-only context, no-op output, trace/debrief/audit, and no canon
|
|
314
|
+
write without production Prom13us credentials.
|
|
315
|
+
The contributor onboarding map lives in
|
|
316
|
+
[`docs/onboarding/contributor.md`](docs/onboarding/contributor.md).
|
|
317
|
+
|
|
318
|
+
## Development Plan
|
|
319
|
+
|
|
320
|
+
The saved section-based sprint plan lives at
|
|
321
|
+
[`docs/research/mochi-agent-native-controller-plan.md`](docs/research/mochi-agent-native-controller-plan.md).
|
|
322
|
+
|
|
323
|
+
Early foundation work is intentionally sequenced:
|
|
324
|
+
|
|
325
|
+
1. Repo scaffold.
|
|
326
|
+
2. README product front door and boundary.
|
|
327
|
+
3. Open-source license decision ADR.
|
|
328
|
+
4. `LICENSE` file and SPDX/package metadata.
|
|
329
|
+
5. Package layout and shared TypeScript config.
|
|
330
|
+
6. Test harness and CI commands.
|
|
331
|
+
7. Contribution and security-reporting rules.
|
|
332
|
+
|
|
333
|
+
Each PR should introduce one durable concept, prove it, document it, and avoid
|
|
334
|
+
weakening the anti-cheat boundary.
|
package/bin/mochi.mjs
ADDED