myte 0.0.45 → 0.0.47

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 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`
@@ -48,14 +46,14 @@ Live mutation commands require `--confirm-write --approval-artifact <path>` afte
48
46
  - `npx myte feedback assign --feedback-id <id> --user-id <user_id> --reason "Assign to builder"`
49
47
  - `npx myte feedback archive --feedback-id <id> --reason "Superseded"`
50
48
  - `npx myte feedback validate --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
51
- - `npx myte feedback submit --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
52
- - `npx myte feedback reviews --status open`
53
- - `npx myte feedback revise --request-id <id> --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
54
- - `npx myte feedback review --request-id <id> --action approve --reason "Looks correct"`
55
- - `npx myte feedback review --request-ids "<id1,id2>" --action approve --reason "Batch approval"`
56
- - `npx myte feedback move --feedback-id <id> --to-state in_progress --reason "Started"`
57
- - `npx myte feedback move --feedback-ids "<id1,id2>" --to-state in_progress --reason "Batch move"`
58
- - `npx myte feedback comment --feedback-id <id> --body-file ./updates/feedback-comment.md`
49
+ - `npx myte feedback submit --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
50
+ - `npx myte feedback reviews --status open`
51
+ - `npx myte feedback revise --request-id <id> --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
52
+ - `npx myte feedback review --request-id <id> --action approve --reason "Looks correct"`
53
+ - `npx myte feedback review --request-ids "<id1,id2>" --action approve --reason "Batch approval"`
54
+ - `npx myte feedback move --feedback-id <id> --to-state in_progress --reason "Started"`
55
+ - `npx myte feedback move --feedback-ids "<id1,id2>" --to-state in_progress --reason "Batch move"`
56
+ - `npx myte feedback comment --feedback-id <id> --body-file ./updates/feedback-comment.md --confirm-write --approval-artifact ./updates/feedback-comment.md`
59
57
  - `npx myte feedback undo --feedback-id <id> --event-id <event_id> --reason "Undo accidental move"`
60
58
  - `npx myte feedback prd-versions --feedback-id <id>`
61
59
  - `npx myte feedback prd-diff --feedback-id <id> --version-id <version_id> --compare-to <base_version_id>`
@@ -63,35 +61,74 @@ Live mutation commands require `--confirm-write --approval-artifact <path>` afte
63
61
  - `npx myte suggestions sync`
64
62
  - `npx myte mission archive --mission-ids "M001" --reason "Duplicate disposable mission"`
65
63
  - `npx myte query "Summarize the current branch changes" --with-diff`
66
- - `npx myte create-prd ./drafts/auth-prd.md`
67
- - `npx myte update-team "Backend deploy completed."`
68
- - `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md`
69
- - `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md`
64
+ - `npx myte create-prd ./drafts/auth-prd.md --confirm-write --approval-artifact ./drafts/auth-prd.md`
65
+ - `npx myte update-team "Backend deploy completed." --confirm-write --approval-artifact ./updates/team.md`
66
+ - `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md --confirm-write --approval-artifact ./updates/owner.md`
67
+ - `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md --confirm-write --approval-artifact ./updates/week-12.md`
70
68
  - `npx mytecody doctor`
71
69
  - `npx mytecody doctor --probe-gateway`
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.
82
- - `feedback status|edit|assign|archive` writes local review artifacts under `MyteCommandCenter/reviews/feedback`; `feedback submit|revise|reviews|review` routes proposed edits through the backend owner-review membrane.
79
+ - `feedback status|edit|assign|archive|refine` writes local review artifacts under `MyteCommandCenter/reviews/feedback`.
80
+ - `feedback submit|revise|comment` are live writes that require `--confirm-write --approval-artifact <path>`.
81
+ - `feedback review|move|undo|apply` are governed writes with backend permission checks but no approval artifact flags.
82
+ - `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate` are read/sync/validation commands with no approval artifact flags.
83
83
  - `feedback review --request-ids` sends one backend batch review request with grouped notifications; do not loop single-review calls for batch decisions.
84
84
  - `feedback move|comment|undo|prd-versions|prd-diff|history` calls the project-key Feedback API while authorization, stale snapshot checks, allowed transitions, and history remain enforced by the backend. `feedback move --feedback-ids` sends one batch board move request.
85
85
  - `feedback comment` creates text-only feedback-specific comments. Attachments remain web UI only for this project-key endpoint.
86
86
  - `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
87
  - `feedback validate|apply` remains available for validation and owner-direct apply paths.
88
88
  - `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
- ## Agent Usage Contract
93
-
94
- Codex, Claude, and other coding agents should use one project-scoped key per workspace:
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
+ ## Approval Artifact Requirements
93
+
94
+ Only selected project-key writes require a local approval artifact. The CLI adds `write_approval` metadata only when the command is in the required set and the caller supplies `--confirm-write --approval-artifact <path>`.
95
+
96
+ | Category | Commands | Artifact |
97
+ | --- | --- | --- |
98
+ | Required | `create-prd`, `update-team`, `update-owner`, `update-client`, `feedback submit`, `feedback revise`, `feedback comment`, `suggestions create`, `suggestions revise` | Yes |
99
+ | Not required | `run-qaqc`, `mission status`, `mission archive`, `suggestions review`, `feedback review`, `feedback move`, `feedback undo`, `feedback apply` | No |
100
+ | Never required | `config`, `query`, `bootstrap`, `sync-qaqc`, `feedback-sync`, `suggestions sync`, `feedback get/history/reviews/prd-versions/prd-diff/validate`, local feedback draft commands | No |
101
+
102
+ For required actions:
103
+
104
+ - First create a local `.md`, `.markdown`, `.yml`, `.yaml`, or `.json` approval artifact that lists the command, every target id, and the proposed change.
105
+ - Show the artifact path and full content or a concise complete summary to the user.
106
+ - After explicit approval, rerun the write with `--confirm-write --approval-artifact <path>`.
107
+ - Batch artifacts must enumerate every feedback id, suggestion id, request id, or PRD item.
108
+
109
+ In plain language, the artifact is the human-reviewed record of the exact write the agent is about to send. It is not a permission grant and it does not bypass project owner/delegate checks, idempotency, stale-state guards, validation, or audit. It tells the API that a human approved this payload.
110
+
111
+ Minimum artifact contents:
112
+
113
+ - `command`: the exact CLI command to run.
114
+ - `targets`: every affected feedback id, request id, suggestion id, mission id, PRD file/client ref, project, or contact id.
115
+ - `proposed_change`: a complete summary of the status, text, PRD, comment, or mission change.
116
+ - `batch_count`: required when one command sends multiple items.
117
+ - `reason` or `approval_note`: why the write is being sent.
118
+
119
+ Batch guidance:
120
+
121
+ - Mission edit/create batches use `myte suggestions create` or `myte suggestions revise`. The artifact must list each item. For edits include `change_type: update`, the existing `mission_id`, and changed fields. For new missions include `change_type: create`, title, description, and acceptance details. For revisions include each `suggestion_id` and expected revision.
122
+ - PRD batches use one `myte create-prd fileA.md fileB.md ...`; the artifact must list each PRD file/title/client ref and `batch_count` must match the number of PRD items.
123
+ - Feedback submit/revise/comment artifacts are usually the same YAML or markdown file being submitted. If the command uses inline text or stdin, create a separate approval memo with the feedback id or request id and exact content.
124
+ - Team, owner, and client update artifacts should name the audience and include the exact message body or a complete summary. Client updates should include target contact ids when used.
125
+ - `feedback review --request-ids`, `feedback move --feedback-ids`, `mission status --mission-ids`, `mission archive --mission-ids`, and `run-qaqc --mission-ids` are batched governed writes, but they are marked `Not required` and should not receive approval artifact flags.
126
+
127
+ For actions marked `Not required`, call the command directly. The backend still enforces project-key authentication, idempotency, owner/delegate capability rules, stale-state guards, validation, rate limits, and audit history.
128
+
129
+ ## Agent Usage Contract
130
+
131
+ Codex, Claude, and other coding agents should use one project-scoped key per workspace:
95
132
 
96
133
  ```bash
97
134
  MYTE_API_KEY=<project_api_key>
@@ -102,18 +139,14 @@ The key resolves the project server-side. Agents should not pass `project_id` ma
102
139
  Recommended agent flow:
103
140
 
104
141
  1. Run `myte config --json` to confirm the project, API base, configured repos, and local workspace detection.
105
- 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.
142
+ 2. Run `myte bootstrap --json`, `myte feedback-sync --json`, or `myte sync-qaqc --json` to hydrate local context under `MyteCommandCenter`. `bootstrap` also writes `MyteCommandCenter/AgentsMyteAPI.md`, the local action matrix agents should consult before mutating Myte state. Use `myte suggestions sync --json` only for narrow mission-review refreshes after bootstrap.
106
143
  3. Use `myte query "<goal/evidence/ask>" --with-diff` when local code changes matter.
107
- 4. 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.
108
- 5. 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.
109
- 6. 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.
110
- 7. Read/sync/query/validate commands, `--print-context`, and `--dry-run` do not require write approval.
111
- 8. Use `myte create-prd <file.md>` only after the PRD markdown has been reviewed by a human. The file body is the PRD document; `--description` is only the short board/card summary.
112
- 9. Use `myte feedback status|edit|assign|archive` to create reviewable local artifacts, then `feedback submit` and `feedback review` for the owner-review membrane.
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.
144
+ 4. Use `myte create-prd <file.md> --confirm-write --approval-artifact <path>` only after the PRD markdown has been reviewed by a human. The file body is the PRD document; `--description` is only the short board/card summary.
145
+ 5. Use `myte feedback status|edit|assign|archive|refine` to create reviewable local artifacts. `feedback submit` and `feedback revise` require an approval artifact; `feedback review` does not because the backend owner/delegate review membrane is the approval control.
146
+ 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.
147
+ 7. Use `myte suggestions create|revise|review` for mission review threads. `suggestions create` and `suggestions revise` require an approval artifact; `suggestions review` does not because the backend Project Owner/elevated-delegate decision is the approval control. Valid create `change_type` values are exactly `update` and `create`; revisions keep the existing thread type and must not include `change_type`.
148
+ 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.
149
+ 9. Use `myte update-team "<content>" --confirm-write --approval-artifact <path>` for project/team comments through `/api/project-assistant/project-comment`, and `myte feedback comment --feedback-id <id> --body-file ./comment.md --confirm-write --approval-artifact ./comment.md` for feedback-specific implementation notes.
117
150
 
118
151
  PRD document contract:
119
152
 
@@ -149,7 +182,7 @@ Feedback comments nuance:
149
182
 
150
183
  - `myte feedback-sync` reads existing feedback comment turns and stores them in `MyteCommandCenter/data/feedback.yml`.
151
184
  - The web product supports feedback-specific comment create/fetch through JWT-authenticated `/api/feedbacks/<feedback_id>/comments`.
152
- - The project-key npm CLI supports `myte feedback comment --feedback-id <id> --body "..."` and `--body-file ./comment.md`.
185
+ - The project-key npm CLI supports `myte feedback comment --feedback-id <id> --body "..." --confirm-write --approval-artifact ./comment.md` and `--body-file ./comment.md --confirm-write --approval-artifact ./comment.md`.
153
186
  - Project-key feedback comments are text-only in this slice and cap content at 500,000 characters. Use the web UI when attachments are required.
154
187
 
155
188
  ## Commands
@@ -161,7 +194,10 @@ Feedback comments nuance:
161
194
  - `mission archive`: archive missions without hard delete
162
195
  - `sync-qaqc`: refresh active mission QAQC context locally
163
196
  - `feedback-sync`: refresh feedback and PRD context locally
164
- - `feedback status|edit|assign|archive|submit|revise|reviews|review|move|comment|undo|prd-versions|prd-diff|validate|apply|history|get`: create reviewable feedback artifacts and operate the governed Feedback API
197
+ - `feedback status|edit|assign|archive|refine`: create reviewable local feedback artifacts only
198
+ - `feedback submit|revise|comment`: live Feedback writes requiring `--confirm-write --approval-artifact <path>`
199
+ - `feedback review|move|undo|apply`: governed Feedback writes with no approval artifact flags
200
+ - `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate`: read, sync, or validate Feedback state
165
201
  - `suggestions sync|create|revise|review`: work with mission suggestion workflow state
166
202
  - `query`: ask the project assistant, optionally with local diff context
167
203
  - `ai`: use the Myte AI gateway
@@ -198,12 +234,12 @@ Feedback comments nuance:
198
234
  | --- | --- | --- |
199
235
  | Sync mission cards and review threads | `myte bootstrap --json` | Refreshes `MyteCommandCenter/data/missions/*.yml`, project structure, and `MyteCommandCenter/data/mission-ops.yml`. |
200
236
  | Sync only mission review threads | `myte suggestions sync --json` | Narrow refresh for `mission-ops.yml` after bootstrap or a mutation. |
201
- | Suggest edit to existing mission | `myte suggestions create` with `change_type: update` and `mission_id` | Creates or appends to an active review thread; live mission is unchanged until approval. |
202
- | Suggest new mission | `myte suggestions create` with `change_type: create` | Requires `change_set.title` and `change_set.description`; mission card is created only after approval. |
203
- | Revise a suggestion | `myte suggestions revise` with `suggestion_id` | Adds another revision to the same thread. Do not include `change_type`. |
204
- | Review a suggestion | `myte suggestions review` with `review_action: approve|request_changes|reject` | Project Owner or elevated mission-review delegate required. |
205
- | Update mission status | `myte mission status --mission-ids "M001" --status todo|in_progress|done` | Active status update only; refreshes local bootstrap + mission-ops by default. |
206
- | Archive mission | `myte mission archive --mission-ids "M001" --reason "..."` | Project Owner or elevated delegate required. Keeps the mission record, hides it from normal board/bootstrap state, and refreshes local bootstrap + mission-ops by default. |
237
+ | Suggest edit to existing mission | `myte suggestions create --file ./create.yml --confirm-write --approval-artifact ./create.yml` with `change_type: update` and `mission_id` | Creates or appends to an active review thread; live mission is unchanged until approval. |
238
+ | Suggest new mission | `myte suggestions create --file ./create.yml --confirm-write --approval-artifact ./create.yml` with `change_type: create` | Requires `change_set.title` and `change_set.description`; mission card is created only after approval. |
239
+ | Revise a suggestion | `myte suggestions revise --file ./revise.yml --confirm-write --approval-artifact ./revise.yml` with `suggestion_id` | Adds another revision to the same thread. Do not include `change_type`. |
240
+ | Review a suggestion | `myte suggestions review` with `review_action: approve|request_changes|reject` | Project Owner or elevated mission-review delegate required; no approval artifact required. |
241
+ | Update mission status | `myte mission status --mission-ids "M001" --status todo|in_progress|done` | Active status update only; no approval artifact required; refreshes local bootstrap + mission-ops by default. |
242
+ | Archive mission | `myte mission archive --mission-ids "M001" --reason "..."` | Project Owner or elevated delegate required; no approval artifact required. Keeps the mission record, hides it from normal board/bootstrap state, and refreshes local bootstrap + mission-ops by default. |
207
243
 
208
244
  After `bootstrap`, find ids locally:
209
245
 
@@ -223,18 +259,18 @@ After `bootstrap`, find ids locally:
223
259
  | `feedback edit` / `feedback refine` | Creates a local YAML proposal for title, description/body, priority, due date, tags, or notes. | Content changes go through owner-review membrane. |
224
260
  | `feedback assign` | Creates a local YAML proposal to change assignee. | Goes through review unless applied through owner-direct path. |
225
261
  | `feedback archive` | Creates a local YAML proposal to archive. | Archive is governed by backend owner/delegate capability. |
226
- | `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Does not mutate live feedback before approval. |
227
- | `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Only valid for the original submitter and `needs_changes` requests. |
262
+ | `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Requires `--confirm-write --approval-artifact <path>`; does not mutate live feedback before approval. |
263
+ | `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Requires `--confirm-write --approval-artifact <path>`; only valid for the original submitter and `needs_changes` requests. |
228
264
  | `feedback reviews` | Lists review requests or fetches one request by `--request-id`. | Read-only; response includes backend permissions. |
229
- | `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. |
230
- | `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. |
231
- | `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. |
232
- | `feedback undo` | Reverses an audited board event when there is no conflict. | Backend validates event ownership/project scope and conflict state. |
265
+ | `feedback review` | Approves, rejects, requests changes, or cancels one review request, or a batch with `--request-ids`. | No approval artifact required; backend restricts approval/review decisions to Project Owner or elevated delegate for Feedback scope; batch review uses one grouped notification path. |
266
+ | `feedback move` | Moves a card or batch of cards across allowed board states directly with an audit event. | No approval artifact required. `--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. |
267
+ | `feedback comment` | Creates a text-only comment on one Feedback item. | Requires `--confirm-write --approval-artifact <path>`; backend checks project-key access, owner/assigned permission, idempotency, and the 500,000-character content cap. Attachments remain web UI only. |
268
+ | `feedback undo` | Reverses an audited board event when there is no conflict. | No approval artifact required; backend validates event ownership/project scope and conflict state. |
233
269
  | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
234
270
  | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
235
271
  | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
236
272
  | `feedback validate` | Sends an artifact to backend validation without mutation. | Useful before submit or owner-direct apply. |
237
- | `feedback apply` | Applies an artifact through the owner-direct/emergency path. | Not the normal collaborator flow; normal flow is `submit` -> `review`. |
273
+ | `feedback apply` | Applies an artifact through the owner-direct/emergency path. | No approval artifact required; not the normal collaborator flow; normal flow is `submit` -> `review`. |
238
274
 
239
275
  Canonical feedback lifecycle states are `frozen`, `todo`, `in_progress`, `in_review`, `completed`, `deployed`, `rejected`, and `archived`.
240
276
 
@@ -246,13 +282,16 @@ npx --package @mytegroupinc/myte-core node ./node_modules/@mytegroupinc/myte-cor
246
282
 
247
283
  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.
248
284
 
249
- ## Direct Project API Surface
250
-
251
- 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>`.
252
-
253
- Read/sync routes:
254
-
255
- - `GET /api/project-assistant/config`
285
+ ## Direct Project API Surface
286
+
287
+ All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
288
+
289
+ `myte ai` is separate from this project-scoped surface. It uses `MYTEAI_API_KEY` and calls `POST https://api.myte.ai/v1/chat/completions`, or `${MYTEAI_API_BASE}/v1/chat/completions` when that base is configured.
290
+
291
+ Read/sync routes:
292
+
293
+ - `GET /api/project-assistant/query/<job_id>`
294
+ - `GET /api/project-assistant/config`
256
295
  - `GET /api/project-assistant/bootstrap`
257
296
  - `GET /api/project-assistant/qaqc-sync`
258
297
  - `GET /api/project-assistant/feedback-sync`
@@ -265,11 +304,10 @@ Read/sync routes:
265
304
  - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions/<version_id>/diff`
266
305
  - `GET /api/project-assistant/suggestions`
267
306
  - `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
307
 
271
- Live project-content mutation routes:
308
+ Mutation routes:
272
309
 
310
+ - `POST /api/project-assistant/query`
273
311
  - `POST /api/project-assistant/run-qaqc`
274
312
  - `POST /api/project-assistant/mission-status-update`
275
313
  - `POST /api/project-assistant/mission-archive`
@@ -278,6 +316,7 @@ Live project-content mutation routes:
278
316
  - `POST /api/project-assistant/client-update-drafts`
279
317
  - `POST /api/project-assistant/create-prd`
280
318
  - `POST /api/project-assistant/create-prds`
319
+ - `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
281
320
  - `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
282
321
  - `POST /api/project-assistant/feedback-review-requests/<request_id>/revise`
283
322
  - `POST /api/project-assistant/feedback/<feedback_id>/refinement/apply`
@@ -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.45",
3
+ "version": "0.0.47",
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.45"
23
- }
24
- }
22
+ "@mytegroupinc/myte-core": "0.0.47"
23
+ }
24
+ }