@mytegroupinc/myte-core 0.0.44 → 0.0.45

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.
Files changed (8) hide show
  1. package/README.md +65 -65
  2. package/THIRD_PARTY_NOTICES.md +21 -21
  3. package/TRADEMARKS.md +10 -10
  4. package/cli.js +904 -876
  5. package/lib/mytecody-release-public-key.pem +11 -11
  6. package/lib/mytecody-splash.js +251 -251
  7. package/mytecody-cli.js +2025 -2025
  8. package/package.json +14 -14
package/README.md CHANGED
@@ -12,48 +12,48 @@ This package exists so the public wrapper can stay small and versioned cleanly.
12
12
  ## Requirements
13
13
 
14
14
  - Node `18+`
15
- - `MYTE_API_KEY` for project-scoped commands
16
- - `MYTEAI_API_KEY` for `myte ai`
17
- - `MYTEAI_API_KEY` for `mytecody`
18
- - `git` only when using `query --with-diff`
15
+ - `MYTE_API_KEY` for project-scoped commands
16
+ - `MYTEAI_API_KEY` for `myte ai`
17
+ - `MYTEAI_API_KEY` for `mytecody`
18
+ - `git` only when using `query --with-diff`
19
19
  - No runtime npm dependencies. The CLI uses Node 18+ built-ins for env loading, argument parsing, HTTP, and local context serialization.
20
20
 
21
21
  ## Behavior Summary
22
22
 
23
- - Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
24
- - 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>`.
25
- - `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
26
- - `feedback move|comment|undo|prd-versions|prd-diff|history` calls the project-key Feedback API while leaving lifecycle rules and permissions server-side. `feedback move --feedback-ids` sends one batch move request.
23
+ - Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
24
+ - 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>`.
25
+ - `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
26
+ - `feedback move|comment|undo|prd-versions|prd-diff|history` calls the project-key Feedback API while leaving lifecycle rules and permissions server-side. `feedback move --feedback-ids` sends one batch move request.
27
27
  - `feedback validate|apply` remains available for validation and owner-direct apply paths; live authorization, stale checks, and history stay server-side.
28
28
  - `query --with-diff` requires project repos to be configured for diff collection and fails fast when no matching local project repo can be resolved.
29
- - Public package documentation is intentionally minimal. Internal rollout and design notes are not part of the npm package contract.
30
- - `mytecody` is a model-agnostic MyteCody team launcher. It supports `doctor`,
31
- `doctor --probe-gateway`, `update --dry-run`, and `update`. On first coding
32
- run, it installs the branded MyteCody engine and signed client assets from
33
- the Myte release manifest into a user-local Myte cache after signature/hash
34
- checks. Coding execution requires those assets, a reachable Myte AI Cody
35
- gateway, and `MYTEAI_API_KEY`. Normal coding runs use the branded Codex
36
- harness with Myte context hardening; the experimental controller is not the
37
- default product path.
38
- - `mytecody doctor` reports both the signed MyteCody engine state and this npm
39
- package version. `mytecody update` updates the engine only. Use
40
- `npm install -g myte@latest` to update the launcher and the Myte API CLI
41
- commands shipped by npm.
42
- - The package does not bundle the large MyteCody engine binary or the async
43
- Responses bridge implementation. See `THIRD_PARTY_NOTICES.md` and
44
- `TRADEMARKS.md` for Codex lineage and Myte brand notices.
45
-
46
- ## Agent Usage Contract
47
-
48
- Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant key:
49
-
50
- - Load it from the workspace `.env` or environment. `MYTE_PROJECT_API_KEY` is accepted as a compatibility fallback.
51
- - Call `myte config --json` first when project identity or local repo detection is uncertain.
52
- - Before any live write, create a local approval artifact, show it to the user, and get explicit approval. Use `.md` for comments, human updates, and PRD markdown; use `.yml`/`.yaml` or `.json` for structured mission/feedback decisions and batch writes.
53
- - After approval, rerun the mutation with `--confirm-write --approval-artifact <path>`. Batch artifacts must enumerate every feedback id, mission id, suggestion id, request id, or PRD item.
54
- - Direct HTTP calls with `MYTE_API_KEY` cannot bypass this gate on live project-content mutations. The API returns `428` with agent instructions when approval metadata is missing or mismatched.
55
- - Read/sync/query/validate commands, `--print-context`, and `--dry-run` do not require write approval.
56
- - Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards and mission suggestion thread state.
29
+ - Public package documentation is intentionally minimal. Internal rollout and design notes are not part of the npm package contract.
30
+ - `mytecody` is a model-agnostic MyteCody team launcher. It supports `doctor`,
31
+ `doctor --probe-gateway`, `update --dry-run`, and `update`. On first coding
32
+ run, it installs the branded MyteCody engine and signed client assets from
33
+ the Myte release manifest into a user-local Myte cache after signature/hash
34
+ checks. Coding execution requires those assets, a reachable Myte AI Cody
35
+ gateway, and `MYTEAI_API_KEY`. Normal coding runs use the branded Codex
36
+ harness with Myte context hardening; the experimental controller is not the
37
+ default product path.
38
+ - `mytecody doctor` reports both the signed MyteCody engine state and this npm
39
+ package version. `mytecody update` updates the engine only. Use
40
+ `npm install -g myte@latest` to update the launcher and the Myte API CLI
41
+ commands shipped by npm.
42
+ - The package does not bundle the large MyteCody engine binary or the async
43
+ Responses bridge implementation. See `THIRD_PARTY_NOTICES.md` and
44
+ `TRADEMARKS.md` for Codex lineage and Myte brand notices.
45
+
46
+ ## Agent Usage Contract
47
+
48
+ Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant key:
49
+
50
+ - Load it from the workspace `.env` or environment. `MYTE_PROJECT_API_KEY` is accepted as a compatibility fallback.
51
+ - Call `myte config --json` first when project identity or local repo detection is uncertain.
52
+ - Before any live write, create a local approval artifact, show it to the user, and get explicit approval. Use `.md` for comments, human updates, and PRD markdown; use `.yml`/`.yaml` or `.json` for structured mission/feedback decisions and batch writes.
53
+ - After approval, rerun the mutation with `--confirm-write --approval-artifact <path>`. Batch artifacts must enumerate every feedback id, mission id, suggestion id, request id, or PRD item.
54
+ - Direct HTTP calls with `MYTE_API_KEY` cannot bypass this gate on live project-content mutations. The API returns `428` with agent instructions when approval metadata is missing or mismatched.
55
+ - Read/sync/query/validate commands, `--print-context`, and `--dry-run` do not require write approval.
56
+ - Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards and mission suggestion thread state.
57
57
  - Use `suggestions sync` only when you need to refresh mission review-thread state without refreshing the full board.
58
58
  - Use `query --with-diff` for project-scoped code review, planning, and implementation questions.
59
59
  - Use `create-prd` only with reviewed markdown files. The markdown file body is the PRD document; `description` is only the short board/card summary.
@@ -63,8 +63,8 @@ Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant
63
63
  - Use `suggestions revise` only against an existing `suggestion_id`; do not send `change_type` on revisions because the backend keeps the thread's original type.
64
64
  - Use `suggestions review` for owner/elevated mission-review decisions: `approve`, `request_changes`, or `reject`.
65
65
  - Use `mission archive` for project-key lifecycle archival. Do not send `Archived` through `mission status`; restore archived missions from the web archived-board view.
66
- - Use `feedback move` only when a direct audited state move is intended and include a concrete `--reason`. Use `--feedback-ids` for batch active-state moves or authorized batch archive.
67
- - Use `feedback comment --feedback-id <id> --body-file ./comment.md` for text-only feedback-specific implementation notes. Attachments remain web UI only for this project-key endpoint.
66
+ - Use `feedback move` only when a direct audited state move is intended and include a concrete `--reason`. Use `--feedback-ids` for batch active-state moves or authorized batch archive.
67
+ - Use `feedback comment --feedback-id <id> --body-file ./comment.md` for text-only feedback-specific implementation notes. Attachments remain web UI only for this project-key endpoint.
68
68
  - Do not use the project-key API/CLI to unarchive Feedback. Normal `feedback-sync` excludes archived Feedback; unarchive from the web archived Feedback view.
69
69
  - Use `update-team` when an agent needs to leave a project-level implementation note or verification comment.
70
70
 
@@ -83,12 +83,12 @@ PRD document contract:
83
83
  - Do not wrap the whole PRD in a ` ```markdown ` fence. Do not use raw HTML, inline style blocks, or decorative banners.
84
84
  - PRD identity is explicit: `myte create-prd` creates a PRD asset with PRD metadata. Generic uploaded `.md`, `.docx`, `.pdf`, and `.txt` files remain normal attachments unless explicitly created as PRDs.
85
85
 
86
- Feedback comment support:
87
-
88
- - `feedback-sync` includes existing feedback comment turns in local context.
89
- - Feedback-specific comment creation exists in the web backend at `/api/feedbacks/<feedback_id>/comments`, protected by JWT/project assignment.
90
- - Project-key comment creation is available through `myte feedback comment --feedback-id <id> --body "..."` or `--body-file ./comment.md`.
91
- - The project-key feedback comment endpoint is text-only in this slice and caps content at 500,000 characters. Use the web UI when comment attachments are required.
86
+ Feedback comment support:
87
+
88
+ - `feedback-sync` includes existing feedback comment turns in local context.
89
+ - Feedback-specific comment creation exists in the web backend at `/api/feedbacks/<feedback_id>/comments`, protected by JWT/project assignment.
90
+ - Project-key comment creation is available through `myte feedback comment --feedback-id <id> --body "..."` or `--body-file ./comment.md`.
91
+ - The project-key feedback comment endpoint is text-only in this slice and caps content at 500,000 characters. Use the web UI when comment attachments are required.
92
92
 
93
93
  ## Mission Action Map
94
94
 
@@ -170,10 +170,10 @@ Agent rule: never guess `suggestion_id`. If `mission-ops.yml` is missing or stal
170
170
  | `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Does not mutate live feedback before approval. |
171
171
  | `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Only valid for the original submitter and `needs_changes` requests. |
172
172
  | `feedback reviews` | Lists review requests or fetches one request by `--request-id`. | Read-only; response includes backend permissions. |
173
- | `feedback review` | Approves, rejects, requests changes, or cancels one review request, or a batch with `--request-ids`. | Backend restricts approval/review decisions to Project Owner or elevated delegate for Feedback scope; batch review uses one grouped notification path. |
174
- | `feedback move` | Moves a card or batch of cards across allowed board states directly with an audit event. | `--feedback-ids` sends one batch request. Blocked with `pending_feedback_review` while an active linked review request exists; governed states such as archive/reject/deploy/freeze remain backend-authorized. Project-key unarchive is not supported. |
175
- | `feedback comment` | Creates a text-only comment on one Feedback item. | Backend checks project-key access, owner/assigned permission, idempotency, and the 500,000-character content cap. Attachments remain web UI only. |
176
- | `feedback undo` | Reverses an audited board event when there is no conflict. | Backend validates event ownership/project scope and conflict state. |
173
+ | `feedback review` | Approves, rejects, requests changes, or cancels one review request, or a batch with `--request-ids`. | Backend restricts approval/review decisions to Project Owner or elevated delegate for Feedback scope; batch review uses one grouped notification path. |
174
+ | `feedback move` | Moves a card or batch of cards across allowed board states directly with an audit event. | `--feedback-ids` sends one batch request. Blocked with `pending_feedback_review` while an active linked review request exists; governed states such as archive/reject/deploy/freeze remain backend-authorized. Project-key unarchive is not supported. |
175
+ | `feedback comment` | Creates a text-only comment on one Feedback item. | Backend checks project-key access, owner/assigned permission, idempotency, and the 500,000-character content cap. Attachments remain web UI only. |
176
+ | `feedback undo` | Reverses an audited board event when there is no conflict. | Backend validates event ownership/project scope and conflict state. |
177
177
  | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
178
178
  | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
179
179
  | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
@@ -190,9 +190,9 @@ node ./scripts/feedback-live-full-harness.js --confirm-live --base-url https://a
190
190
 
191
191
  The harness creates five disposable `TEST` feedback items from markdown, verifies batch review and batch board movement, batch archives the disposable items, verifies normal `feedback-sync` excludes archived items, and verifies the project-key surface does not expose Feedback unarchive/restore.
192
192
 
193
- ## Direct Project API Surface
194
-
195
- All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes. Live project-content mutation routes also require write-approval headers; the official CLI supplies them from `--confirm-write --approval-artifact <path>`.
193
+ ## Direct Project API Surface
194
+
195
+ All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes. Live project-content mutation routes also require write-approval headers; the official CLI supplies them from `--confirm-write --approval-artifact <path>`.
196
196
 
197
197
  Read/sync routes:
198
198
 
@@ -207,21 +207,21 @@ Read/sync routes:
207
207
  - `GET /api/project-assistant/feedback/<feedback_id>/events`
208
208
  - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions`
209
209
  - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions/<version_id>/diff`
210
- - `GET /api/project-assistant/suggestions`
211
- - `GET /api/project-assistant/run-qaqc/<batch_id>`
212
- - `POST /api/project-assistant/query`
213
- - `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
214
-
215
- Live project-content mutation routes:
216
-
217
- - `POST /api/project-assistant/run-qaqc`
210
+ - `GET /api/project-assistant/suggestions`
211
+ - `GET /api/project-assistant/run-qaqc/<batch_id>`
212
+ - `POST /api/project-assistant/query`
213
+ - `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
214
+
215
+ Live project-content mutation routes:
216
+
217
+ - `POST /api/project-assistant/run-qaqc`
218
218
  - `POST /api/project-assistant/mission-status-update`
219
219
  - `POST /api/project-assistant/mission-archive`
220
220
  - `POST /api/project-assistant/project-comment`
221
221
  - `POST /api/project-assistant/update-owner`
222
222
  - `POST /api/project-assistant/client-update-drafts`
223
- - `POST /api/project-assistant/create-prd`
224
- - `POST /api/project-assistant/create-prds`
223
+ - `POST /api/project-assistant/create-prd`
224
+ - `POST /api/project-assistant/create-prds`
225
225
  - `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
226
226
  - `POST /api/project-assistant/feedback-review-requests/<request_id>/revise`
227
227
  - `POST /api/project-assistant/feedback/<feedback_id>/refinement/apply`
@@ -229,10 +229,10 @@ Live project-content mutation routes:
229
229
  - `POST /api/project-assistant/feedback-review-requests/batch-review`
230
230
  - `POST /api/project-assistant/feedback-review-requests/<request_id>/request-changes`
231
231
  - `POST /api/project-assistant/feedback-review-requests/<request_id>/cancel`
232
- - `POST /api/project-assistant/feedback/<feedback_id>/board-move`
233
- - `POST /api/project-assistant/feedback/batch-board-move`
234
- - `POST /api/project-assistant/feedback/<feedback_id>/comments`
235
- - `POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo`
232
+ - `POST /api/project-assistant/feedback/<feedback_id>/board-move`
233
+ - `POST /api/project-assistant/feedback/batch-board-move`
234
+ - `POST /api/project-assistant/feedback/<feedback_id>/comments`
235
+ - `POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo`
236
236
  - `POST /api/project-assistant/suggestions`
237
237
  - `POST /api/project-assistant/suggestions/revise`
238
238
  - `POST /api/project-assistant/suggestions/review`
package/THIRD_PARTY_NOTICES.md CHANGED
@@ -1,21 +1,21 @@
1
- # Third-Party Notices
2
-
3
- This package includes the Myte CLI launcher and MyteCody distribution client.
4
-
5
- The branded MyteCody engine installed by the launcher is derived from the
6
- OpenAI Codex open-source project. OpenAI Codex is licensed under the
7
- Apache License, Version 2.0.
8
-
9
- Source lineage tracked for this slice:
10
-
11
- - Project: OpenAI Codex
12
- - Version baseline: `0.139.0`
13
- - License: Apache-2.0
14
- - Upstream: https://github.com/openai/codex
15
-
16
- The MyteCody engine and signed client assets are distributed separately from
17
- this npm package through a Myte release manifest. This package verifies release
18
- artifacts before installing them into the user's Myte-owned local cache.
19
-
20
- Myte names, marks, logos, terminal branding, and product design are not part of
21
- the OpenAI Codex project and remain Myte-owned brand assets.
1
+ # Third-Party Notices
2
+
3
+ This package includes the Myte CLI launcher and MyteCody distribution client.
4
+
5
+ The branded MyteCody engine installed by the launcher is derived from the
6
+ OpenAI Codex open-source project. OpenAI Codex is licensed under the
7
+ Apache License, Version 2.0.
8
+
9
+ Source lineage tracked for this slice:
10
+
11
+ - Project: OpenAI Codex
12
+ - Version baseline: `0.139.0`
13
+ - License: Apache-2.0
14
+ - Upstream: https://github.com/openai/codex
15
+
16
+ The MyteCody engine and signed client assets are distributed separately from
17
+ this npm package through a Myte release manifest. This package verifies release
18
+ artifacts before installing them into the user's Myte-owned local cache.
19
+
20
+ Myte names, marks, logos, terminal branding, and product design are not part of
21
+ the OpenAI Codex project and remain 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.