@mytegroupinc/myte-core 0.0.44 → 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.
Files changed (3) hide show
  1. package/README.md +64 -60
  2. package/cli.js +814 -943
  3. package/package.json +14 -14
package/README.md CHANGED
@@ -12,48 +12,52 @@ 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
- ## Behavior Summary
22
-
21
+ ## Behavior Summary
22
+
23
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.
24
+ - `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
25
+ - `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
26
  - `feedback validate|apply` remains available for validation and owner-direct apply paths; live authorization, stale checks, and history stay server-side.
28
27
  - `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.
28
+ - Public package documentation is intentionally minimal. Internal rollout and design notes are not part of the npm package contract.
29
+ - `mytecody` is a model-agnostic MyteCody team launcher. It supports `doctor`,
30
+ `doctor --probe-gateway`, `update --dry-run`, and `update`. On first coding
31
+ run, it installs the branded MyteCody engine and signed client assets from
32
+ the Myte release manifest into a user-local Myte cache after signature/hash
33
+ checks. Coding execution requires those assets, a reachable Myte AI Cody
34
+ gateway, and `MYTEAI_API_KEY`. Normal coding runs use the branded Codex
35
+ harness with Myte context hardening; the experimental controller is not the
36
+ default product path.
38
37
  - `mytecody doctor` reports both the signed MyteCody engine state and this npm
39
38
  package version. `mytecody update` updates the engine only. Use
40
39
  `npm install -g myte@latest` to update the launcher and the Myte API CLI
41
40
  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
41
 
46
- ## Agent Usage Contract
47
-
48
- Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant key:
42
+ ## Live Write Approval
43
+
44
+ Project-key write commands add a server-validated approval envelope only after the caller supplies `--confirm-write --approval-artifact <path>`.
49
45
 
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.
46
+ - The approval artifact must be a local `.md`, `.yml`, `.yaml`, or `.json` file shown to and approved by the user.
47
+ - The artifact must list the exact operation, proposed change, and every target id or PRD item.
48
+ - Batch writes must enumerate every item and the CLI sends the matching batch count to the API.
49
+ - The API validates the payload hash after stripping transport metadata, so direct HTTP writes with only the API key do not bypass approval.
50
+ - The package does not bundle the large MyteCody engine binary or the async
51
+ Responses bridge implementation. See `THIRD_PARTY_NOTICES.md` and
52
+ `TRADEMARKS.md` for Codex lineage and Myte brand notices.
53
+
54
+ ## Agent Usage Contract
55
+
56
+ Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant key:
57
+
58
+ - Load it from the workspace `.env` or environment. `MYTE_PROJECT_API_KEY` is accepted as a compatibility fallback.
59
+ - Call `myte config --json` first when project identity or local repo detection is uncertain.
60
+ - Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards and mission suggestion thread state.
57
61
  - Use `suggestions sync` only when you need to refresh mission review-thread state without refreshing the full board.
58
62
  - Use `query --with-diff` for project-scoped code review, planning, and implementation questions.
59
63
  - 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 +67,8 @@ Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant
63
67
  - 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
68
  - Use `suggestions review` for owner/elevated mission-review decisions: `approve`, `request_changes`, or `reject`.
65
69
  - 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.
70
+ - 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.
71
+ - 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
72
  - 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
73
  - Use `update-team` when an agent needs to leave a project-level implementation note or verification comment.
70
74
 
@@ -83,12 +87,12 @@ PRD document contract:
83
87
  - Do not wrap the whole PRD in a ` ```markdown ` fence. Do not use raw HTML, inline style blocks, or decorative banners.
84
88
  - 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
89
 
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.
90
+ Feedback comment support:
91
+
92
+ - `feedback-sync` includes existing feedback comment turns in local context.
93
+ - Feedback-specific comment creation exists in the web backend at `/api/feedbacks/<feedback_id>/comments`, protected by JWT/project assignment.
94
+ - Project-key comment creation is available through `myte feedback comment --feedback-id <id> --body "..."` or `--body-file ./comment.md`.
95
+ - 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
96
 
93
97
  ## Mission Action Map
94
98
 
@@ -170,10 +174,10 @@ Agent rule: never guess `suggestion_id`. If `mission-ops.yml` is missing or stal
170
174
  | `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Does not mutate live feedback before approval. |
171
175
  | `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Only valid for the original submitter and `needs_changes` requests. |
172
176
  | `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. |
177
+ | `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. |
178
+ | `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. |
179
+ | `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. |
180
+ | `feedback undo` | Reverses an audited board event when there is no conflict. | Backend validates event ownership/project scope and conflict state. |
177
181
  | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
178
182
  | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
179
183
  | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
@@ -190,9 +194,9 @@ node ./scripts/feedback-live-full-harness.js --confirm-live --base-url https://a
190
194
 
191
195
  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
196
 
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>`.
197
+ ## Direct Project API Surface
198
+
199
+ All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
196
200
 
197
201
  Read/sync routes:
198
202
 
@@ -207,21 +211,21 @@ Read/sync routes:
207
211
  - `GET /api/project-assistant/feedback/<feedback_id>/events`
208
212
  - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions`
209
213
  - `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`
214
+ - `GET /api/project-assistant/suggestions`
215
+ - `GET /api/project-assistant/run-qaqc/<batch_id>`
216
+
217
+ Mutation routes:
218
+
219
+ - `POST /api/project-assistant/query`
220
+ - `POST /api/project-assistant/run-qaqc`
218
221
  - `POST /api/project-assistant/mission-status-update`
219
222
  - `POST /api/project-assistant/mission-archive`
220
223
  - `POST /api/project-assistant/project-comment`
221
224
  - `POST /api/project-assistant/update-owner`
222
225
  - `POST /api/project-assistant/client-update-drafts`
223
- - `POST /api/project-assistant/create-prd`
224
- - `POST /api/project-assistant/create-prds`
226
+ - `POST /api/project-assistant/create-prd`
227
+ - `POST /api/project-assistant/create-prds`
228
+ - `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
225
229
  - `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
226
230
  - `POST /api/project-assistant/feedback-review-requests/<request_id>/revise`
227
231
  - `POST /api/project-assistant/feedback/<feedback_id>/refinement/apply`
@@ -229,10 +233,10 @@ Live project-content mutation routes:
229
233
  - `POST /api/project-assistant/feedback-review-requests/batch-review`
230
234
  - `POST /api/project-assistant/feedback-review-requests/<request_id>/request-changes`
231
235
  - `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`
236
+ - `POST /api/project-assistant/feedback/<feedback_id>/board-move`
237
+ - `POST /api/project-assistant/feedback/batch-board-move`
238
+ - `POST /api/project-assistant/feedback/<feedback_id>/comments`
239
+ - `POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo`
236
240
  - `POST /api/project-assistant/suggestions`
237
241
  - `POST /api/project-assistant/suggestions/revise`
238
242
  - `POST /api/project-assistant/suggestions/review`