myte 0.0.45 → 0.0.46
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/README.md +29 -26
- package/THIRD_PARTY_NOTICES.md +11 -11
- package/TRADEMARKS.md +10 -10
- package/bin/mytecody.js +19 -19
- package/package.json +4 -4
package/README.md
CHANGED
|
@@ -35,8 +35,6 @@ The CLI searches for `.env` in the current folder and then up parent directories
|
|
|
35
35
|
|
|
36
36
|
## Common Commands
|
|
37
37
|
|
|
38
|
-
Live mutation commands require `--confirm-write --approval-artifact <path>` after the local artifact has been shown to and approved by the user.
|
|
39
|
-
|
|
40
38
|
- `npx myte config --json`
|
|
41
39
|
- `npx myte bootstrap`
|
|
42
40
|
- `npx myte sync-qaqc`
|
|
@@ -72,10 +70,9 @@ Live mutation commands require `--confirm-write --approval-artifact <path>` afte
|
|
|
72
70
|
- `npx mytecody update --dry-run`
|
|
73
71
|
- `npx mytecody update`
|
|
74
72
|
|
|
75
|
-
## Behavior
|
|
76
|
-
|
|
77
|
-
- `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write project-scoped local context under `MyteCommandCenter` in the current workspace unless `--output-dir` is provided.
|
|
78
|
-
- Live project-key mutations require explicit user approval before the CLI sends them. Create a local approval artifact, show it to the user, then rerun with `--confirm-write --approval-artifact <path>`.
|
|
73
|
+
## Behavior
|
|
74
|
+
|
|
75
|
+
- `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write project-scoped local context under `MyteCommandCenter` in the current workspace unless `--output-dir` is provided.
|
|
79
76
|
- `bootstrap` writes mission cards and mission suggestion thread state together; agents should run it before looking for mission or suggestion ids.
|
|
80
77
|
- `mission status` is active-state only (`todo`, `in_progress`, `done`). Use `mission archive` for project-key lifecycle archival; restore archived missions from the web archived-board view.
|
|
81
78
|
- `mission status` and `mission archive` refresh local bootstrap + mission-ops state by default after a successful mutation. Use `--no-sync` only when you intentionally want to skip the local refresh.
|
|
@@ -86,12 +83,22 @@ Live mutation commands require `--confirm-write --approval-artifact <path>` afte
|
|
|
86
83
|
- `feedback-sync` excludes archived Feedback from normal `MyteCommandCenter` state. Project-key API/CLI can archive authorized Feedback, but Feedback unarchive/restore is web UI only.
|
|
87
84
|
- `feedback validate|apply` remains available for validation and owner-direct apply paths.
|
|
88
85
|
- `query --with-diff` is stricter than the snapshot commands. It requires project repositories to be configured by the project owner or builder, and it requires at least one matching local project repo to be resolved for diff collection.
|
|
89
|
-
- If diff-scoped repo configuration is missing or no local project repo can be resolved, `query --with-diff` exits with an error instead of silently dropping diff context.
|
|
90
|
-
- Most markdown files are excluded from diff context by default so code and runtime configuration changes dominate the payload. Key instruction files such as `README.md` and `AGENTS.md` remain eligible.
|
|
91
|
-
|
|
92
|
-
##
|
|
93
|
-
|
|
94
|
-
|
|
86
|
+
- If diff-scoped repo configuration is missing or no local project repo can be resolved, `query --with-diff` exits with an error instead of silently dropping diff context.
|
|
87
|
+
- Most markdown files are excluded from diff context by default so code and runtime configuration changes dominate the payload. Key instruction files such as `README.md` and `AGENTS.md` remain eligible.
|
|
88
|
+
|
|
89
|
+
## Live Write Approval
|
|
90
|
+
|
|
91
|
+
All live project-key writes must be approved by the user before the CLI sends them to Myte.
|
|
92
|
+
|
|
93
|
+
- First create a local `.md`, `.yml`, `.yaml`, or `.json` approval artifact that lists the command, every target id, and the proposed change.
|
|
94
|
+
- Show the artifact path and full content or concise complete summary to the user.
|
|
95
|
+
- After explicit approval, rerun the write with `--confirm-write --approval-artifact <path>`.
|
|
96
|
+
- Batch writes must enumerate every feedback id, mission id, suggestion id, request id, or PRD item in the artifact. QAQC batches are capped by the API at 10 mission ids.
|
|
97
|
+
- The API also validates the approval envelope, payload hash, targets, and true batch count, so direct HTTP calls with only the API key are rejected.
|
|
98
|
+
|
|
99
|
+
## Agent Usage Contract
|
|
100
|
+
|
|
101
|
+
Codex, Claude, and other coding agents should use one project-scoped key per workspace:
|
|
95
102
|
|
|
96
103
|
```bash
|
|
97
104
|
MYTE_API_KEY=<project_api_key>
|
|
@@ -104,16 +111,12 @@ Recommended agent flow:
|
|
|
104
111
|
1. Run `myte config --json` to confirm the project, API base, configured repos, and local workspace detection.
|
|
105
112
|
2. Run `myte bootstrap --json`, `myte feedback-sync --json`, or `myte sync-qaqc --json` to hydrate local context under `MyteCommandCenter`. Use `myte suggestions sync --json` only for narrow mission-review refreshes after bootstrap.
|
|
106
113
|
3. Use `myte query "<goal/evidence/ask>" --with-diff` when local code changes matter.
|
|
107
|
-
4.
|
|
108
|
-
5.
|
|
109
|
-
6.
|
|
110
|
-
7.
|
|
111
|
-
8. Use `myte
|
|
112
|
-
9. Use `myte
|
|
113
|
-
10. Use `myte feedback move` only for direct board movement that is intentionally audited, with a clear `--reason`; use `--feedback-ids` for batch moves or batch archive.
|
|
114
|
-
11. Use `myte suggestions create|revise|review` for mission review threads. Valid create `change_type` values are exactly `update` and `create`; revisions keep the existing thread type and must not include `change_type`.
|
|
115
|
-
12. Use `myte mission archive` for project-key mission lifecycle archival. Archive requires Project Owner or elevated delegate capability; restore is web-only from the archived missions board.
|
|
116
|
-
13. Use `myte update-team "<content>"` for project/team comments through `/api/project-assistant/project-comment`, and `myte feedback comment --feedback-id <id> --body-file ./comment.md` for feedback-specific implementation notes.
|
|
114
|
+
4. Use `myte create-prd <file.md>` only after the PRD markdown has been reviewed by a human, then send it with `--confirm-write --approval-artifact <path>`. The file body is the PRD document; `--description` is only the short board/card summary.
|
|
115
|
+
5. Use `myte feedback status|edit|assign|archive` to create reviewable local artifacts, then `feedback submit` and `feedback review` for the owner-review membrane.
|
|
116
|
+
6. Use `myte feedback move` only for direct board movement that is intentionally audited, with a clear `--reason`; use `--feedback-ids` for batch moves or batch archive.
|
|
117
|
+
7. Use `myte suggestions create|revise|review` for mission review threads. Valid create `change_type` values are exactly `update` and `create`; revisions keep the existing thread type and must not include `change_type`.
|
|
118
|
+
8. Use `myte mission archive` for project-key mission lifecycle archival. Archive requires Project Owner or elevated delegate capability; restore is web-only from the archived missions board.
|
|
119
|
+
9. Use `myte update-team "<content>"` for project/team comments through `/api/project-assistant/project-comment`, and `myte feedback comment --feedback-id <id> --body-file ./comment.md` for feedback-specific implementation notes.
|
|
117
120
|
|
|
118
121
|
PRD document contract:
|
|
119
122
|
|
|
@@ -248,7 +251,7 @@ The harness creates five disposable `TEST` feedback items from markdown, verifie
|
|
|
248
251
|
|
|
249
252
|
## Direct Project API Surface
|
|
250
253
|
|
|
251
|
-
All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
|
|
254
|
+
All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
|
|
252
255
|
|
|
253
256
|
Read/sync routes:
|
|
254
257
|
|
|
@@ -265,11 +268,10 @@ Read/sync routes:
|
|
|
265
268
|
- `GET /api/project-assistant/feedback/<feedback_id>/prd/versions/<version_id>/diff`
|
|
266
269
|
- `GET /api/project-assistant/suggestions`
|
|
267
270
|
- `GET /api/project-assistant/run-qaqc/<batch_id>`
|
|
268
|
-
- `POST /api/project-assistant/query`
|
|
269
|
-
- `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
|
|
270
271
|
|
|
271
|
-
|
|
272
|
+
Mutation routes:
|
|
272
273
|
|
|
274
|
+
- `POST /api/project-assistant/query`
|
|
273
275
|
- `POST /api/project-assistant/run-qaqc`
|
|
274
276
|
- `POST /api/project-assistant/mission-status-update`
|
|
275
277
|
- `POST /api/project-assistant/mission-archive`
|
|
@@ -278,6 +280,7 @@ Live project-content mutation routes:
|
|
|
278
280
|
- `POST /api/project-assistant/client-update-drafts`
|
|
279
281
|
- `POST /api/project-assistant/create-prd`
|
|
280
282
|
- `POST /api/project-assistant/create-prds`
|
|
283
|
+
- `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
|
|
281
284
|
- `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
|
|
282
285
|
- `POST /api/project-assistant/feedback-review-requests/<request_id>/revise`
|
|
283
286
|
- `POST /api/project-assistant/feedback/<feedback_id>/refinement/apply`
|
package/THIRD_PARTY_NOTICES.md
CHANGED
|
@@ -1,11 +1,11 @@
|
|
|
1
|
-
# Third-Party Notices
|
|
2
|
-
|
|
3
|
-
The `myte` package exposes the `mytecody` command. The command installs and
|
|
4
|
-
launches a branded MyteCody engine and signed client assets from a Myte release
|
|
5
|
-
manifest.
|
|
6
|
-
|
|
7
|
-
The branded MyteCody engine is derived from the OpenAI Codex open-source
|
|
8
|
-
project, version baseline `0.139.0`, licensed under Apache-2.0.
|
|
9
|
-
|
|
10
|
-
Myte names, marks, logos, terminal branding, and product design are separate
|
|
11
|
-
Myte-owned brand assets.
|
|
1
|
+
# Third-Party Notices
|
|
2
|
+
|
|
3
|
+
The `myte` package exposes the `mytecody` command. The command installs and
|
|
4
|
+
launches a branded MyteCody engine and signed client assets from a Myte release
|
|
5
|
+
manifest.
|
|
6
|
+
|
|
7
|
+
The branded MyteCody engine is derived from the OpenAI Codex open-source
|
|
8
|
+
project, version baseline `0.139.0`, licensed under Apache-2.0.
|
|
9
|
+
|
|
10
|
+
Myte names, marks, logos, terminal branding, and product design are separate
|
|
11
|
+
Myte-owned brand assets.
|
package/TRADEMARKS.md
CHANGED
|
@@ -1,10 +1,10 @@
|
|
|
1
|
-
# Trademarks
|
|
2
|
-
|
|
3
|
-
Myte, Myte AI, MyteCody, "MYTE CODY - Your Tech Your Way", logo assets, terminal
|
|
4
|
-
animation assets, and related product branding are Myte-owned marks and brand
|
|
5
|
-
assets.
|
|
6
|
-
|
|
7
|
-
OpenAI and Codex are trademarks or project names of their respective owners.
|
|
8
|
-
MyteCody uses a Codex-derived open-source engine under the applicable open
|
|
9
|
-
source license, but MyteCody is a Myte product surface and is not presented as
|
|
10
|
-
an official OpenAI product.
|
|
1
|
+
# Trademarks
|
|
2
|
+
|
|
3
|
+
Myte, Myte AI, MyteCody, "MYTE CODY - Your Tech Your Way", logo assets, terminal
|
|
4
|
+
animation assets, and related product branding are Myte-owned marks and brand
|
|
5
|
+
assets.
|
|
6
|
+
|
|
7
|
+
OpenAI and Codex are trademarks or project names of their respective owners.
|
|
8
|
+
MyteCody uses a Codex-derived open-source engine under the applicable open
|
|
9
|
+
source license, but MyteCody is a Myte product surface and is not presented as
|
|
10
|
+
an official OpenAI product.
|
package/bin/mytecody.js
CHANGED
|
@@ -1,19 +1,19 @@
|
|
|
1
|
-
#!/usr/bin/env node
|
|
2
|
-
"use strict";
|
|
3
|
-
|
|
4
|
-
const cody = require("@mytegroupinc/myte-core/mytecody-cli");
|
|
5
|
-
|
|
6
|
-
if (!cody || typeof cody.run !== "function") {
|
|
7
|
-
console.error("mytecody core entrypoint is unavailable.");
|
|
8
|
-
process.exit(1);
|
|
9
|
-
}
|
|
10
|
-
|
|
11
|
-
Promise.resolve(cody.run(process.argv.slice(2))).then(
|
|
12
|
-
(code) => {
|
|
13
|
-
process.exitCode = Number.isInteger(code) ? code : 0;
|
|
14
|
-
},
|
|
15
|
-
(err) => {
|
|
16
|
-
console.error("Unexpected error:", err?.message || err);
|
|
17
|
-
process.exitCode = 1;
|
|
18
|
-
},
|
|
19
|
-
);
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
"use strict";
|
|
3
|
+
|
|
4
|
+
const cody = require("@mytegroupinc/myte-core/mytecody-cli");
|
|
5
|
+
|
|
6
|
+
if (!cody || typeof cody.run !== "function") {
|
|
7
|
+
console.error("mytecody core entrypoint is unavailable.");
|
|
8
|
+
process.exit(1);
|
|
9
|
+
}
|
|
10
|
+
|
|
11
|
+
Promise.resolve(cody.run(process.argv.slice(2))).then(
|
|
12
|
+
(code) => {
|
|
13
|
+
process.exitCode = Number.isInteger(code) ? code : 0;
|
|
14
|
+
},
|
|
15
|
+
(err) => {
|
|
16
|
+
console.error("Unexpected error:", err?.message || err);
|
|
17
|
+
process.exitCode = 1;
|
|
18
|
+
},
|
|
19
|
+
);
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "myte",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.46",
|
|
4
4
|
"description": "Myte developer CLI.",
|
|
5
5
|
"type": "commonjs",
|
|
6
6
|
"license": "MIT",
|
|
@@ -19,6 +19,6 @@
|
|
|
19
19
|
"node": ">=18"
|
|
20
20
|
},
|
|
21
21
|
"dependencies": {
|
|
22
|
-
"@mytegroupinc/myte-core": "0.0.
|
|
23
|
-
}
|
|
24
|
-
}
|
|
22
|
+
"@mytegroupinc/myte-core": "0.0.46"
|
|
23
|
+
}
|
|
24
|
+
}
|