myte 0.0.53 → 0.0.55

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 (5) hide show
  1. package/README.md +166 -155
  2. package/THIRD_PARTY_NOTICES.md +11 -11
  3. package/TRADEMARKS.md +10 -10
  4. package/bin/mytecody.js +19 -19
  5. package/package.json +13 -13
package/README.md CHANGED
@@ -19,34 +19,34 @@ No install:
19
19
 
20
20
  - `npx myte@latest ...`
21
21
 
22
- `npm install myte` does not add `myte` to your shell `PATH`. Use `npx myte` or `npm exec myte -- ...` unless you installed globally.
23
-
24
- The npm line `added N packages` is a dependency-graph count, not a count of
25
- files or Myte features. The public `myte` package is a small command wrapper,
26
- `@mytegroupinc/myte-core` contains the CLI implementation, and `undici`
27
- provides portable proxy support. A fresh install therefore normally contains
28
- three graph nodes; npm may report fewer on an update when dependencies are
29
- already present or deduplicated. Run `myte info` or
30
- `myte --version --verbose` to inspect the exact topology.
31
-
32
- ## Requirements
33
-
34
- - Node `18.17+`
22
+ `npm install myte` does not add `myte` to your shell `PATH`. Use `npx myte` or `npm exec myte -- ...` unless you installed globally.
23
+
24
+ The npm line `added N packages` is a dependency-graph count, not a count of
25
+ files or Myte features. The public `myte` package is a small command wrapper,
26
+ `@mytegroupinc/myte-core` contains the CLI implementation, and `undici`
27
+ provides portable proxy support. A fresh install therefore normally contains
28
+ three graph nodes; npm may report fewer on an update when dependencies are
29
+ already present or deduplicated. Run `myte info` or
30
+ `myte --version --verbose` to inspect the exact topology.
31
+
32
+ ## Requirements
33
+
34
+ - Node `18.17+`
35
35
  - macOS, Linux, or Windows
36
36
  - `MYTE_API_KEY=<project_api_key>` in your shell or workspace `.env`
37
37
  - `MYTEAI_API_KEY=<inference_api_key>` only for `myte ai`
38
38
  - `MYTEAI_API_KEY=<inference_api_key>` for `mytecody`
39
39
  - `git` in `PATH` only for `query --with-diff`
40
- - Standard `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` variables are honored
41
- through the core transport dependency.
40
+ - Standard `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` variables are honored
41
+ through the core transport dependency.
42
42
 
43
43
  The CLI searches for `.env` in the current folder and then up parent directories.
44
44
 
45
45
  ## Common Commands
46
46
 
47
- - `npx myte config --json`
48
- - `npx myte doctor --json`
49
- - `npx myte info`
47
+ - `npx myte config --json`
48
+ - `npx myte doctor --json`
49
+ - `npx myte info`
50
50
  - `npx myte bootstrap`
51
51
  - `npx myte sync-qaqc`
52
52
  - `npx myte feedback-sync`
@@ -54,111 +54,122 @@ The CLI searches for `.env` in the current folder and then up parent directories
54
54
  - `npx myte feedback history --feedback-id <id>`
55
55
  - `npx myte feedback status --feedback-id <id> --status in_review --reason "Ready for review"`
56
56
  - `npx myte feedback edit --feedback-id <id> --title "Updated title" --feedback-text "Updated body" --reason "Clarify scope"`
57
+ - `npx myte feedback document-add --feedback-id <id> --prd-file ./docs/linked-addendum.md --title "Linked PRD addendum" --reason "Extend governed Feedback context"`
57
58
  - `npx myte feedback assign --feedback-id <id> --user-id <user_id> --reason "Assign to builder"`
58
59
  - `npx myte feedback archive --feedback-id <id> --reason "Superseded"`
59
60
  - `npx myte feedback validate --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
60
- - `npx myte feedback submit --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
61
- - `npx myte feedback reviews --status open`
62
- - `npx myte feedback revise --request-id <id> --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
63
- - `npx myte feedback review --request-id <id> --action approve --reason "Looks correct"`
64
- - `npx myte feedback review --request-ids "<id1,id2>" --action approve --reason "Batch approval"`
65
- - `npx myte feedback move --feedback-id <id> --to-state in_progress --reason "Started"`
66
- - `npx myte feedback move --feedback-ids "<id1,id2>" --to-state in_progress --reason "Batch move"`
67
- - `npx myte feedback comment --feedback-id <id> --body-file ./updates/feedback-comment.md --confirm-write --approval-artifact ./updates/feedback-comment.md`
61
+ - `npx myte feedback submit --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
62
+ - `npx myte feedback reviews --status open`
63
+ - `npx myte feedback revise --request-id <id> --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
64
+ - `npx myte feedback review --request-id <id> --action approve --reason "Looks correct"`
65
+ - `npx myte feedback review --request-ids "<id1,id2>" --action approve --reason "Batch approval"`
66
+ - `npx myte feedback move --feedback-id <id> --to-state in_progress --reason "Started"`
67
+ - `npx myte feedback move --feedback-ids "<id1,id2>" --to-state in_progress --reason "Batch move"`
68
+ - `npx myte feedback comment --feedback-id <id> --body-file ./updates/feedback-comment.md --confirm-write --approval-artifact ./updates/feedback-comment.md`
68
69
  - `npx myte feedback undo --feedback-id <id> --event-id <event_id> --reason "Undo accidental move"`
69
70
  - `npx myte feedback prd-versions --feedback-id <id>`
70
71
  - `npx myte feedback prd-diff --feedback-id <id> --version-id <version_id> --compare-to <base_version_id>`
71
72
  - `npx myte feedback apply --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
72
73
  - `npx myte suggestions sync`
73
74
  - `npx myte mission archive --mission-ids "M001" --reason "Duplicate disposable mission"`
74
- - `npx myte query "Summarize the current branch changes" --with-diff --json`
75
- - `npx myte create-prd ./drafts/auth-prd.md --confirm-write --approval-artifact ./drafts/auth-prd.md`
76
- - `npx myte create-prd ./drafts/auth-prd.md --assigned-user-email dev@example.com --confirm-write --approval-artifact ./drafts/auth-prd.md`
77
- - `npx myte create-prd ./drafts/proposal.md ./drafts/harness.md ./drafts/security.md --document-set --confirm-write --approval-artifact ./drafts/approval.md`
78
- - `npx myte update-team "Backend deploy completed." --confirm-write --approval-artifact ./updates/team.md`
79
- - `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md --confirm-write --approval-artifact ./updates/owner.md`
80
- - `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md --confirm-write --approval-artifact ./updates/week-12.md`
75
+ - `npx myte query "Summarize the current branch changes" --with-diff --json`
76
+ - `npx myte create-prd ./drafts/auth-prd.md --confirm-write --approval-artifact ./drafts/auth-prd.md`
77
+ - `npx myte create-prd ./drafts/auth-prd.md --assigned-user-email dev@example.com --confirm-write --approval-artifact ./drafts/auth-prd.md`
78
+ - `npx myte create-prd ./drafts/proposal.md ./drafts/harness.md ./drafts/security.md --document-set --confirm-write --approval-artifact ./drafts/approval.md`
79
+ - `npx myte update-team "Backend deploy completed." --confirm-write --approval-artifact ./updates/team.md`
80
+ - `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md --confirm-write --approval-artifact ./updates/owner.md`
81
+ - `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md --confirm-write --approval-artifact ./updates/week-12.md`
81
82
  - `npx mytecody doctor`
82
83
  - `npx mytecody doctor --probe-gateway`
83
84
  - `npx mytecody update --dry-run`
84
85
  - `npx mytecody update`
85
86
 
86
- ## Behavior
87
-
88
- - `doctor` performs read-only package, credential-presence, DNS, direct
89
- TCP/TLS, authenticated config, proxy, and workspace checks. It reports the
90
- failing layer without printing the API key, proxy URL, request body, or
91
- response body.
92
- - Network failures distinguish DNS, TCP, TLS/certificate, timeout, captive
93
- portal/non-JSON, authentication, authorization, rate-limit, and server
94
- response failures. Do not disable TLS verification to work around a failed
95
- diagnostic.
87
+ ## Behavior
88
+
89
+ - `doctor` performs read-only package, credential-presence, DNS, direct
90
+ TCP/TLS, authenticated config, proxy, and workspace checks. It reports the
91
+ failing layer without printing the API key, proxy URL, request body, or
92
+ response body.
93
+ - Network failures distinguish DNS, TCP, TLS/certificate, timeout, captive
94
+ portal/non-JSON, authentication, authorization, rate-limit, and server
95
+ response failures. Do not disable TLS verification to work around a failed
96
+ diagnostic.
96
97
  - Safe transient reads and query polling use bounded retries. Query creation
97
98
  uses one stable idempotency key across ambiguous retries so a lost response
98
99
  cannot create duplicate inference jobs.
99
- - `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write project-scoped local context under `MyteCommandCenter` in the current workspace unless `--output-dir` is provided.
100
+ - Query and QAQC polling honor server `Retry-After` / `next_poll_after_ms`
101
+ guidance and add bounded jitter to prevent synchronized IDE poll bursts.
102
+ - Owner updates are accepted into a durable delivery outbox; a successful CLI
103
+ response means the update was queued, while delivery status remains server-owned.
104
+ - `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write project-scoped local context under `MyteCommandCenter` in the current workspace unless `--output-dir` is provided.
100
105
  - `bootstrap` writes mission cards and mission suggestion thread state together; agents should run it before looking for mission or suggestion ids.
101
106
  - `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.
102
107
  - `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.
103
- - `feedback status|edit|assign|archive|refine` writes local review artifacts under `MyteCommandCenter/reviews/feedback`.
104
- - `feedback submit|revise|comment` are live writes that require `--confirm-write --approval-artifact <path>`.
105
- - `feedback review|move|undo|apply` are governed writes with backend permission checks but no approval artifact flags.
106
- - `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate` are read/sync/validation commands with no approval artifact flags.
108
+ - `feedback status|edit|assign|archive|refine` writes local review artifacts under `MyteCommandCenter/reviews/feedback`.
109
+ - `feedback submit|revise|comment` are live writes that require `--confirm-write --approval-artifact <path>`.
110
+ - `feedback review|move|undo|apply` are governed writes with backend permission checks but no approval artifact flags.
111
+ - `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate` are read/sync/validation commands with no approval artifact flags.
107
112
  - `feedback review --request-ids` sends one backend batch review request with grouped notifications; do not loop single-review calls for batch decisions.
108
113
  - `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.
109
114
  - `feedback comment` creates text-only feedback-specific comments. Attachments remain web UI only for this project-key endpoint.
110
115
  - `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.
111
116
  - `feedback validate|apply` remains available for validation and owner-direct apply paths.
112
117
  - `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.
113
- - 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.
118
+ - 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.
114
119
  - 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.
115
120
 
116
- ## Approval Artifact Requirements
117
-
118
- 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>`.
119
-
120
- | Category | Commands | Artifact |
121
- | --- | --- | --- |
122
- | Required | `create-prd`, `update-team`, `update-owner`, `update-client`, `feedback submit`, `feedback revise`, `feedback comment`, `suggestions create`, `suggestions revise` | Yes |
123
- | Not required | `run-qaqc`, `mission status`, `mission archive`, `suggestions review`, `feedback review`, `feedback move`, `feedback undo`, `feedback apply` | No |
124
- | 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 |
125
-
126
- For required actions:
127
-
128
- - First create a local `.md`, `.markdown`, `.yml`, `.yaml`, or `.json` approval artifact that lists the command, every target id, and the proposed change.
129
- - Show the artifact path and full content or a concise complete summary to the user.
130
- - After explicit approval, rerun the write with `--confirm-write --approval-artifact <path>`.
131
- - Batch artifacts must enumerate every feedback id, suggestion id, request id, or PRD item.
132
-
133
- 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.
134
-
135
- Minimum artifact contents:
136
-
137
- - `command`: the exact CLI command to run.
138
- - `targets`: every affected feedback id, request id, suggestion id, mission id, PRD file/client ref, project, or contact id.
139
- - `proposed_change`: a complete summary of the status, text, PRD, comment, or mission change.
140
- - `batch_count`: required when one command sends multiple items.
141
- - `reason` or `approval_note`: why the write is being sent.
142
-
143
- Batch guidance:
144
-
145
- - 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.
146
- - Without `--document-set`, `myte create-prd fileA.md fileB.md ...` preserves
147
- the existing behavior and creates one independent Feedback item per file.
148
- - With `--document-set`, one to three Markdown files create one Feedback item
149
- with ordered, independently readable PRD documents. Each document is
150
- validated locally against the 250,000-character server contract. The
151
- approval artifact must list every file/title/client ref and the matching
152
- document count.
153
- - 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.
154
- - 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.
155
- - `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.
156
-
157
- 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.
158
-
159
- ## Agent Usage Contract
160
-
161
- Codex, Claude, and other coding agents should use one project-scoped key per workspace:
121
+ Release certification uses the shipped
122
+ `scripts/project-assistant-live-full-harness.js`. Its default mode is network-free
123
+ and accounts for all 38 project-key routes. Live mode is pinned to GaahField,
124
+ requires explicit mutation flags, exercises concurrent idempotency, and delegates
125
+ cleanup only to the existing exact-ID mission and Feedback harnesses.
126
+
127
+ ## Approval Artifact Requirements
128
+
129
+ 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>`.
130
+
131
+ | Category | Commands | Artifact |
132
+ | --- | --- | --- |
133
+ | Required | `create-prd`, `update-team`, `update-owner`, `update-client`, `feedback submit`, `feedback revise`, `feedback comment`, `suggestions create`, `suggestions revise` | Yes |
134
+ | Not required | `run-qaqc`, `mission status`, `mission archive`, `suggestions review`, `feedback review`, `feedback move`, `feedback undo`, `feedback apply` | No |
135
+ | 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 |
136
+
137
+ For required actions:
138
+
139
+ - First create a local `.md`, `.markdown`, `.yml`, `.yaml`, or `.json` approval artifact that lists the command, every target id, and the proposed change.
140
+ - Show the artifact path and full content or a concise complete summary to the user.
141
+ - After explicit approval, rerun the write with `--confirm-write --approval-artifact <path>`.
142
+ - Batch artifacts must enumerate every feedback id, suggestion id, request id, or PRD item.
143
+
144
+ 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.
145
+
146
+ Minimum artifact contents:
147
+
148
+ - `command`: the exact CLI command to run.
149
+ - `targets`: every affected feedback id, request id, suggestion id, mission id, PRD file/client ref, project, or contact id.
150
+ - `proposed_change`: a complete summary of the status, text, PRD, comment, or mission change.
151
+ - `batch_count`: required when one command sends multiple items.
152
+ - `reason` or `approval_note`: why the write is being sent.
153
+
154
+ Batch guidance:
155
+
156
+ - 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.
157
+ - Without `--document-set`, `myte create-prd fileA.md fileB.md ...` preserves
158
+ the existing behavior and creates one independent Feedback item per file.
159
+ - With `--document-set`, one to three Markdown files create one Feedback item
160
+ with ordered, independently readable PRD documents. Each document is
161
+ validated locally against the 250,000-character server contract. The
162
+ approval artifact must list every file/title/client ref and the matching
163
+ document count.
164
+ - 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.
165
+ - 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.
166
+ - `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.
167
+
168
+ 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.
169
+
170
+ ## Agent Usage Contract
171
+
172
+ Codex, Claude, and other coding agents should use one project-scoped key per workspace:
162
173
 
163
174
  ```bash
164
175
  MYTE_API_KEY=<project_api_key>
@@ -169,14 +180,14 @@ The key resolves the project server-side. Agents should not pass `project_id` ma
169
180
  Recommended agent flow:
170
181
 
171
182
  1. Run `myte config --json` to confirm the project, API base, configured repos, and local workspace detection.
172
- 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.
183
+ 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.
173
184
  3. Use `myte query "<goal/evidence/ask>" --with-diff` when local code changes matter.
174
- 4. Use `myte create-prd <file.md> --confirm-write --approval-artifact <path>` only after the PRD markdown has been reviewed by a human. Add `--document-set` for one parent with up to three ordered documents. Without that flag, multiple files remain independent PRDs. The file body is the PRD document; `--description` is only the short board/card summary. New PRDs are unassigned by default; add `--assigned-user-id <id>` or `--assigned-user-email <exact-email>` to assign an eligible project user atomically during creation.
175
- 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.
185
+ 4. Use `myte create-prd <file.md> --confirm-write --approval-artifact <path>` only after the PRD markdown has been reviewed by a human. Add `--document-set` for one parent with up to three ordered documents. Without that flag, multiple files remain independent PRDs. The file body is the PRD document; `--description` is only the short board/card summary. New PRDs are unassigned by default; add `--assigned-user-id <id>` or `--assigned-user-email <exact-email>` to assign an eligible project user atomically during creation.
186
+ 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.
176
187
  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.
177
- 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`.
188
+ 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`.
178
189
  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.
179
- 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.
190
+ 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.
180
191
 
181
192
  PRD document contract:
182
193
 
@@ -187,33 +198,33 @@ PRD document contract:
187
198
  - The UI renders the PRD from the stored document text, not from the card description.
188
199
  - Renderer-friendly PRDs should use one `# Title`, `##` sections, concise paragraphs, bullets, GitHub tables/checklists where useful, and fenced code blocks only for real code/config.
189
200
  - Do not wrap the whole PRD in a ` ```markdown ` fence. Do not use raw HTML, inline style blocks, or decorative banners.
190
- - 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.
191
- - Document-set uploads preserve the exact source Markdown and also store a
192
- normalized rendering copy. Rendering cleanup never silently rewrites the
193
- approved source.
194
-
195
- ## Connectivity Diagnostics
196
-
197
- Run this before assuming an API key or server failure:
198
-
199
- ```bash
200
- myte doctor --json
201
- ```
202
-
203
- Interpret the first failed layer:
204
-
205
- - `dns`: the API hostname could not be resolved.
206
- - `tcp`: the host resolved but port 443 could not be reached.
207
- - `tls`: the secure connection was reset or certificate validation failed
208
- before an HTTP request reached Myte.
209
- - `http`: Myte or an intermediary returned a status or non-JSON response.
210
- - `authentication` / `authorization`: the API received the request and
211
- rejected the credential or capability.
212
-
213
- On restricted Wi-Fi, complete any captive-portal login, configure the
214
- network's supported proxy/VPN, or retry on another network. The CLI honors
215
- `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`; it never recommends disabling
216
- certificate verification.
201
+ - 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.
202
+ - Document-set uploads preserve the exact source Markdown and also store a
203
+ normalized rendering copy. Rendering cleanup never silently rewrites the
204
+ approved source.
205
+
206
+ ## Connectivity Diagnostics
207
+
208
+ Run this before assuming an API key or server failure:
209
+
210
+ ```bash
211
+ myte doctor --json
212
+ ```
213
+
214
+ Interpret the first failed layer:
215
+
216
+ - `dns`: the API hostname could not be resolved.
217
+ - `tcp`: the host resolved but port 443 could not be reached.
218
+ - `tls`: the secure connection was reset or certificate validation failed
219
+ before an HTTP request reached Myte.
220
+ - `http`: Myte or an intermediary returned a status or non-JSON response.
221
+ - `authentication` / `authorization`: the API received the request and
222
+ rejected the credential or capability.
223
+
224
+ On restricted Wi-Fi, complete any captive-portal login, configure the
225
+ network's supported proxy/VPN, or retry on another network. The CLI honors
226
+ `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`; it never recommends disabling
227
+ certificate verification.
217
228
 
218
229
  Preferred file shape:
219
230
 
@@ -238,7 +249,7 @@ Feedback comments nuance:
238
249
 
239
250
  - `myte feedback-sync` reads existing feedback comment turns and stores them in `MyteCommandCenter/data/feedback.yml`.
240
251
  - The web product supports feedback-specific comment create/fetch through JWT-authenticated `/api/feedbacks/<feedback_id>/comments`.
241
- - 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`.
252
+ - 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`.
242
253
  - 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.
243
254
 
244
255
  ## Commands
@@ -250,10 +261,10 @@ Feedback comments nuance:
250
261
  - `mission archive`: archive missions without hard delete
251
262
  - `sync-qaqc`: refresh active mission QAQC context locally
252
263
  - `feedback-sync`: refresh feedback and PRD context locally
253
- - `feedback status|edit|assign|archive|refine`: create reviewable local feedback artifacts only
254
- - `feedback submit|revise|comment`: live Feedback writes requiring `--confirm-write --approval-artifact <path>`
255
- - `feedback review|move|undo|apply`: governed Feedback writes with no approval artifact flags
256
- - `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate`: read, sync, or validate Feedback state
264
+ - `feedback status|edit|assign|archive|refine`: create reviewable local feedback artifacts only
265
+ - `feedback submit|revise|comment`: live Feedback writes requiring `--confirm-write --approval-artifact <path>`
266
+ - `feedback review|move|undo|apply`: governed Feedback writes with no approval artifact flags
267
+ - `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate`: read, sync, or validate Feedback state
257
268
  - `suggestions sync|create|revise|review`: work with mission suggestion workflow state
258
269
  - `query`: ask the project assistant, optionally with local diff context
259
270
  - `ai`: use the Myte AI gateway
@@ -290,12 +301,12 @@ Feedback comments nuance:
290
301
  | --- | --- | --- |
291
302
  | Sync mission cards and review threads | `myte bootstrap --json` | Refreshes `MyteCommandCenter/data/missions/*.yml`, project structure, and `MyteCommandCenter/data/mission-ops.yml`. |
292
303
  | Sync only mission review threads | `myte suggestions sync --json` | Narrow refresh for `mission-ops.yml` after bootstrap or a mutation. |
293
- | 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. |
294
- | 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. |
295
- | 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`. |
296
- | 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. |
297
- | 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. |
298
- | 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. |
304
+ | 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. |
305
+ | 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. |
306
+ | 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`. |
307
+ | 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. |
308
+ | 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. |
309
+ | 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. |
299
310
 
300
311
  After `bootstrap`, find ids locally:
301
312
 
@@ -315,18 +326,18 @@ After `bootstrap`, find ids locally:
315
326
  | `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. |
316
327
  | `feedback assign` | Creates a local YAML proposal to change assignee. | Goes through review unless applied through owner-direct path. |
317
328
  | `feedback archive` | Creates a local YAML proposal to archive. | Archive is governed by backend owner/delegate capability. |
318
- | `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. |
319
- | `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. |
329
+ | `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. |
330
+ | `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. |
320
331
  | `feedback reviews` | Lists review requests or fetches one request by `--request-id`. | Read-only; response includes backend permissions. |
321
- | `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. |
322
- | `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. |
323
- | `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. |
324
- | `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. |
332
+ | `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. |
333
+ | `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. |
334
+ | `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. |
335
+ | `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. |
325
336
  | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
326
337
  | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
327
338
  | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
328
339
  | `feedback validate` | Sends an artifact to backend validation without mutation. | Useful before submit or owner-direct apply. |
329
- | `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`. |
340
+ | `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`. |
330
341
 
331
342
  Canonical feedback lifecycle states are `frozen`, `todo`, `in_progress`, `in_review`, `completed`, `deployed`, `rejected`, and `archived`.
332
343
 
@@ -338,16 +349,16 @@ npx --package @mytegroupinc/myte-core node ./node_modules/@mytegroupinc/myte-cor
338
349
 
339
350
  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.
340
351
 
341
- ## Direct Project API Surface
342
-
343
- All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
344
-
345
- `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.
346
-
347
- Read/sync routes:
348
-
349
- - `GET /api/project-assistant/query/<job_id>`
350
- - `GET /api/project-assistant/config`
352
+ ## Direct Project API Surface
353
+
354
+ All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
355
+
356
+ `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.
357
+
358
+ Read/sync routes:
359
+
360
+ - `GET /api/project-assistant/query/<job_id>`
361
+ - `GET /api/project-assistant/config`
351
362
  - `GET /api/project-assistant/bootstrap`
352
363
  - `GET /api/project-assistant/qaqc-sync`
353
364
  - `GET /api/project-assistant/feedback-sync`
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,24 +1,24 @@
1
1
  {
2
2
  "name": "myte",
3
- "version": "0.0.53",
3
+ "version": "0.0.55",
4
4
  "description": "Myte developer CLI.",
5
5
  "type": "commonjs",
6
6
  "license": "MIT",
7
7
  "files": [
8
- "README.md",
9
- "THIRD_PARTY_NOTICES.md",
10
- "TRADEMARKS.md",
11
- "bin",
12
- "package.json"
8
+ "README.md",
9
+ "THIRD_PARTY_NOTICES.md",
10
+ "TRADEMARKS.md",
11
+ "bin",
12
+ "package.json"
13
13
  ],
14
- "bin": {
15
- "myte": "bin/myte.js",
16
- "mytecody": "bin/mytecody.js"
17
- },
18
- "engines": {
19
- "node": ">=18.17"
14
+ "bin": {
15
+ "myte": "bin/myte.js",
16
+ "mytecody": "bin/mytecody.js"
17
+ },
18
+ "engines": {
19
+ "node": ">=18.17"
20
20
  },
21
21
  "dependencies": {
22
- "@mytegroupinc/myte-core": "0.0.53"
22
+ "@mytegroupinc/myte-core": "0.0.55"
23
23
  }
24
24
  }