myte 0.0.54 → 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 +167 -157
  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,147 +19,157 @@ 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`
53
53
  - `npx myte feedback get --feedback-id <id>`
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
- - `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"`
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"`
58
58
  - `npx myte feedback assign --feedback-id <id> --user-id <user_id> --reason "Assign to builder"`
59
59
  - `npx myte feedback archive --feedback-id <id> --reason "Superseded"`
60
60
  - `npx myte feedback validate --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
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`
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`
69
69
  - `npx myte feedback undo --feedback-id <id> --event-id <event_id> --reason "Undo accidental move"`
70
70
  - `npx myte feedback prd-versions --feedback-id <id>`
71
71
  - `npx myte feedback prd-diff --feedback-id <id> --version-id <version_id> --compare-to <base_version_id>`
72
72
  - `npx myte feedback apply --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
73
73
  - `npx myte suggestions sync`
74
74
  - `npx myte mission archive --mission-ids "M001" --reason "Duplicate disposable mission"`
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`
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`
82
82
  - `npx mytecody doctor`
83
83
  - `npx mytecody doctor --probe-gateway`
84
84
  - `npx mytecody update --dry-run`
85
85
  - `npx mytecody update`
86
86
 
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.
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.
97
97
  - Safe transient reads and query polling use bounded retries. Query creation
98
98
  uses one stable idempotency key across ambiguous retries so a lost response
99
99
  cannot create duplicate inference jobs.
100
- - `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.
101
105
  - `bootstrap` writes mission cards and mission suggestion thread state together; agents should run it before looking for mission or suggestion ids.
102
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.
103
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.
104
- - `feedback status|edit|assign|archive|refine` writes local review artifacts under `MyteCommandCenter/reviews/feedback`.
105
- - `feedback submit|revise|comment` are live writes that require `--confirm-write --approval-artifact <path>`.
106
- - `feedback review|move|undo|apply` are governed writes with backend permission checks but no approval artifact flags.
107
- - `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.
108
112
  - `feedback review --request-ids` sends one backend batch review request with grouped notifications; do not loop single-review calls for batch decisions.
109
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.
110
114
  - `feedback comment` creates text-only feedback-specific comments. Attachments remain web UI only for this project-key endpoint.
111
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.
112
116
  - `feedback validate|apply` remains available for validation and owner-direct apply paths.
113
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.
114
- - 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.
115
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.
116
120
 
117
- ## Approval Artifact Requirements
118
-
119
- 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>`.
120
-
121
- | Category | Commands | Artifact |
122
- | --- | --- | --- |
123
- | Required | `create-prd`, `update-team`, `update-owner`, `update-client`, `feedback submit`, `feedback revise`, `feedback comment`, `suggestions create`, `suggestions revise` | Yes |
124
- | Not required | `run-qaqc`, `mission status`, `mission archive`, `suggestions review`, `feedback review`, `feedback move`, `feedback undo`, `feedback apply` | No |
125
- | 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 |
126
-
127
- For required actions:
128
-
129
- - First create a local `.md`, `.markdown`, `.yml`, `.yaml`, or `.json` approval artifact that lists the command, every target id, and the proposed change.
130
- - Show the artifact path and full content or a concise complete summary to the user.
131
- - After explicit approval, rerun the write with `--confirm-write --approval-artifact <path>`.
132
- - Batch artifacts must enumerate every feedback id, suggestion id, request id, or PRD item.
133
-
134
- 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.
135
-
136
- Minimum artifact contents:
137
-
138
- - `command`: the exact CLI command to run.
139
- - `targets`: every affected feedback id, request id, suggestion id, mission id, PRD file/client ref, project, or contact id.
140
- - `proposed_change`: a complete summary of the status, text, PRD, comment, or mission change.
141
- - `batch_count`: required when one command sends multiple items.
142
- - `reason` or `approval_note`: why the write is being sent.
143
-
144
- Batch guidance:
145
-
146
- - 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.
147
- - Without `--document-set`, `myte create-prd fileA.md fileB.md ...` preserves
148
- the existing behavior and creates one independent Feedback item per file.
149
- - With `--document-set`, one to three Markdown files create one Feedback item
150
- with ordered, independently readable PRD documents. Each document is
151
- validated locally against the 250,000-character server contract. The
152
- approval artifact must list every file/title/client ref and the matching
153
- document count.
154
- - 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.
155
- - 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.
156
- - `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.
157
-
158
- 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.
159
-
160
- ## Agent Usage Contract
161
-
162
- 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:
163
173
 
164
174
  ```bash
165
175
  MYTE_API_KEY=<project_api_key>
@@ -170,14 +180,14 @@ The key resolves the project server-side. Agents should not pass `project_id` ma
170
180
  Recommended agent flow:
171
181
 
172
182
  1. Run `myte config --json` to confirm the project, API base, configured repos, and local workspace detection.
173
- 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.
174
184
  3. Use `myte query "<goal/evidence/ask>" --with-diff` when local code changes matter.
175
- 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.
176
- 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.
177
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.
178
- 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`.
179
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.
180
- 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.
181
191
 
182
192
  PRD document contract:
183
193
 
@@ -188,33 +198,33 @@ PRD document contract:
188
198
  - The UI renders the PRD from the stored document text, not from the card description.
189
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.
190
200
  - Do not wrap the whole PRD in a ` ```markdown ` fence. Do not use raw HTML, inline style blocks, or decorative banners.
191
- - 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.
192
- - Document-set uploads preserve the exact source Markdown and also store a
193
- normalized rendering copy. Rendering cleanup never silently rewrites the
194
- approved source.
195
-
196
- ## Connectivity Diagnostics
197
-
198
- Run this before assuming an API key or server failure:
199
-
200
- ```bash
201
- myte doctor --json
202
- ```
203
-
204
- Interpret the first failed layer:
205
-
206
- - `dns`: the API hostname could not be resolved.
207
- - `tcp`: the host resolved but port 443 could not be reached.
208
- - `tls`: the secure connection was reset or certificate validation failed
209
- before an HTTP request reached Myte.
210
- - `http`: Myte or an intermediary returned a status or non-JSON response.
211
- - `authentication` / `authorization`: the API received the request and
212
- rejected the credential or capability.
213
-
214
- On restricted Wi-Fi, complete any captive-portal login, configure the
215
- network's supported proxy/VPN, or retry on another network. The CLI honors
216
- `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`; it never recommends disabling
217
- 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.
218
228
 
219
229
  Preferred file shape:
220
230
 
@@ -239,7 +249,7 @@ Feedback comments nuance:
239
249
 
240
250
  - `myte feedback-sync` reads existing feedback comment turns and stores them in `MyteCommandCenter/data/feedback.yml`.
241
251
  - The web product supports feedback-specific comment create/fetch through JWT-authenticated `/api/feedbacks/<feedback_id>/comments`.
242
- - 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`.
243
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.
244
254
 
245
255
  ## Commands
@@ -251,10 +261,10 @@ Feedback comments nuance:
251
261
  - `mission archive`: archive missions without hard delete
252
262
  - `sync-qaqc`: refresh active mission QAQC context locally
253
263
  - `feedback-sync`: refresh feedback and PRD context locally
254
- - `feedback status|edit|assign|archive|refine`: create reviewable local feedback artifacts only
255
- - `feedback submit|revise|comment`: live Feedback writes requiring `--confirm-write --approval-artifact <path>`
256
- - `feedback review|move|undo|apply`: governed Feedback writes with no approval artifact flags
257
- - `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
258
268
  - `suggestions sync|create|revise|review`: work with mission suggestion workflow state
259
269
  - `query`: ask the project assistant, optionally with local diff context
260
270
  - `ai`: use the Myte AI gateway
@@ -291,12 +301,12 @@ Feedback comments nuance:
291
301
  | --- | --- | --- |
292
302
  | Sync mission cards and review threads | `myte bootstrap --json` | Refreshes `MyteCommandCenter/data/missions/*.yml`, project structure, and `MyteCommandCenter/data/mission-ops.yml`. |
293
303
  | Sync only mission review threads | `myte suggestions sync --json` | Narrow refresh for `mission-ops.yml` after bootstrap or a mutation. |
294
- | 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. |
295
- | 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. |
296
- | 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`. |
297
- | 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. |
298
- | 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. |
299
- | 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. |
300
310
 
301
311
  After `bootstrap`, find ids locally:
302
312
 
@@ -316,18 +326,18 @@ After `bootstrap`, find ids locally:
316
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. |
317
327
  | `feedback assign` | Creates a local YAML proposal to change assignee. | Goes through review unless applied through owner-direct path. |
318
328
  | `feedback archive` | Creates a local YAML proposal to archive. | Archive is governed by backend owner/delegate capability. |
319
- | `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. |
320
- | `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. |
321
331
  | `feedback reviews` | Lists review requests or fetches one request by `--request-id`. | Read-only; response includes backend permissions. |
322
- | `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. |
323
- | `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. |
324
- | `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. |
325
- | `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. |
326
336
  | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
327
337
  | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
328
338
  | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
329
339
  | `feedback validate` | Sends an artifact to backend validation without mutation. | Useful before submit or owner-direct apply. |
330
- | `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`. |
331
341
 
332
342
  Canonical feedback lifecycle states are `frozen`, `todo`, `in_progress`, `in_review`, `completed`, `deployed`, `rejected`, and `archived`.
333
343
 
@@ -339,16 +349,16 @@ npx --package @mytegroupinc/myte-core node ./node_modules/@mytegroupinc/myte-cor
339
349
 
340
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.
341
351
 
342
- ## Direct Project API Surface
343
-
344
- All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
345
-
346
- `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.
347
-
348
- Read/sync routes:
349
-
350
- - `GET /api/project-assistant/query/<job_id>`
351
- - `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`
352
362
  - `GET /api/project-assistant/bootstrap`
353
363
  - `GET /api/project-assistant/qaqc-sync`
354
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.54",
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.54"
22
+ "@mytegroupinc/myte-core": "0.0.55"
23
23
  }
24
24
  }