myte 0.0.54 → 0.0.56

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 +191 -156
  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,162 @@ 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
+ - `npx myte feedback tickets list --feedback-id <id> --json`
70
+ - `npx myte feedback tickets create --feedback-id <id> --file ./tickets.json --dry-run --json`
71
+ - `npx myte feedback tickets update --feedback-id <id> --ticket-ids "<id1,id2>" --status in_progress --confirm-write --approval-artifact ./ticket-update.yml --json`
69
72
  - `npx myte feedback undo --feedback-id <id> --event-id <event_id> --reason "Undo accidental move"`
70
73
  - `npx myte feedback prd-versions --feedback-id <id>`
71
74
  - `npx myte feedback prd-diff --feedback-id <id> --version-id <version_id> --compare-to <base_version_id>`
72
75
  - `npx myte feedback apply --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
73
76
  - `npx myte suggestions sync`
74
77
  - `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`
78
+ - `npx myte query "Summarize the current branch changes" --with-diff --json`
79
+ - `npx myte create-prd ./drafts/auth-prd.md --confirm-write --approval-artifact ./drafts/auth-prd.md`
80
+ - `npx myte create-prd ./drafts/auth-prd.md --assigned-user-email dev@example.com --confirm-write --approval-artifact ./drafts/auth-prd.md`
81
+ - `npx myte create-prd ./drafts/proposal.md ./drafts/harness.md ./drafts/security.md --document-set --confirm-write --approval-artifact ./drafts/approval.md`
82
+ - `npx myte update-team "Backend deploy completed." --confirm-write --approval-artifact ./updates/team.md`
83
+ - `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md --confirm-write --approval-artifact ./updates/owner.md`
84
+ - `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md --confirm-write --approval-artifact ./updates/week-12.md`
82
85
  - `npx mytecody doctor`
83
86
  - `npx mytecody doctor --probe-gateway`
84
87
  - `npx mytecody update --dry-run`
85
88
  - `npx mytecody update`
86
89
 
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
- - Safe transient reads and query polling use bounded retries. Query creation
98
- uses one stable idempotency key across ambiguous retries so a lost response
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.
90
+ ## Behavior
91
+
92
+ - `doctor` performs read-only package, credential-presence, DNS, direct
93
+ TCP/TLS, authenticated config, proxy, and workspace checks. It reports the
94
+ failing layer without printing the API key, proxy URL, request body, or
95
+ response body.
96
+ - Network failures distinguish DNS, TCP, TLS/certificate, timeout, captive
97
+ portal/non-JSON, authentication, authorization, rate-limit, and server
98
+ response failures. Do not disable TLS verification to work around a failed
99
+ diagnostic.
100
+ - Safe transient reads and query polling use bounded retries. Query creation
101
+ uses one stable idempotency key across ambiguous retries so a lost response
102
+ cannot create duplicate inference jobs.
103
+ - Query and QAQC polling honor server `Retry-After` / `next_poll_after_ms`
104
+ guidance and add bounded jitter to prevent synchronized IDE poll bursts.
105
+ - Owner updates are accepted into a durable delivery outbox; a successful CLI
106
+ response means the update was queued, while delivery status remains server-owned.
107
+ - `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
108
  - `bootstrap` writes mission cards and mission suggestion thread state together; agents should run it before looking for mission or suggestion ids.
102
109
  - `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
110
  - `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.
111
+ - `feedback status|edit|assign|archive|refine` writes local review artifacts under `MyteCommandCenter/reviews/feedback`.
112
+ - `feedback submit|revise|comment` are live writes that require `--confirm-write --approval-artifact <path>`.
113
+ - `feedback review|move|undo|apply` are governed writes with backend permission checks but no approval artifact flags.
114
+ - `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate` and `feedback tickets list|validate-create|validate-update` are read/sync/validation commands with no approval artifact flags.
108
115
  - `feedback review --request-ids` sends one backend batch review request with grouped notifications; do not loop single-review calls for batch decisions.
109
116
  - `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
117
  - `feedback comment` creates text-only feedback-specific comments. Attachments remain web UI only for this project-key endpoint.
111
118
  - `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
119
  - `feedback validate|apply` remains available for validation and owner-direct apply paths.
113
120
  - `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.
115
- - 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
-
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
+ - 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.
122
+ - 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.
123
+
124
+ Release certification uses the shipped
125
+ `scripts/project-assistant-live-full-harness.js`. Its default mode is network-free
126
+ and accounts for all 38 project-key routes. Live mode is pinned to GaahField,
127
+ requires explicit mutation flags, exercises concurrent idempotency, and delegates
128
+ cleanup only to the existing exact-ID mission and Feedback harnesses.
129
+ The harness uses the canonical `https://api.myte.dev/api` base and recognizes
130
+ the live project's `Gaahfield MarketPlace` title as the governed GaahField target.
131
+
132
+ ## Approval Artifact Requirements
133
+
134
+ 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>`.
135
+
136
+ | Category | Commands | Artifact |
137
+ | --- | --- | --- |
138
+ | Required | `create-prd`, `update-team`, `update-owner`, `update-client`, `feedback submit`, `feedback revise`, `feedback comment`, `feedback tickets create/update/coverage`, `suggestions create`, `suggestions revise` | Yes |
139
+ | Not required | `run-qaqc`, `mission status`, `mission archive`, `suggestions review`, `feedback review`, `feedback move`, `feedback undo`, `feedback apply` | No |
140
+ | 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 |
141
+
142
+ For required actions:
143
+
144
+ - First create a local `.md`, `.markdown`, `.yml`, `.yaml`, or `.json` approval artifact that lists the command, every target id, and the proposed change.
145
+ - Show the artifact path and full content or a concise complete summary to the user.
146
+ - After explicit approval, rerun the write with `--confirm-write --approval-artifact <path>`.
147
+ - Batch artifacts must enumerate every feedback id, suggestion id, request id, or PRD item.
148
+
149
+ 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.
150
+
151
+ Minimum artifact contents:
152
+
153
+ - `command`: the exact CLI command to run.
154
+ - `targets`: every affected feedback id, request id, suggestion id, mission id, PRD file/client ref, project, or contact id.
155
+ - `proposed_change`: a complete summary of the status, text, PRD, comment, or mission change.
156
+ - `batch_count`: required when one command sends multiple items.
157
+ - `reason` or `approval_note`: why the write is being sent.
158
+
159
+ Batch guidance:
160
+
161
+ - 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.
162
+ - Without `--document-set`, `myte create-prd fileA.md fileB.md ...` preserves
163
+ the existing behavior and creates one independent Feedback item per file.
164
+ - With `--document-set`, one to three Markdown files create one Feedback item
165
+ with ordered, independently readable PRD documents. Each document is
166
+ validated locally against the 250,000-character server contract. The
167
+ approval artifact must list every file/title/client ref and the matching
168
+ document count.
169
+ - 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.
170
+ - 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.
171
+ - `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.
172
+
173
+ 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.
174
+
175
+ ## Agent Usage Contract
176
+
177
+ Codex, Claude, and other coding agents should use one project-scoped key per workspace:
163
178
 
164
179
  ```bash
165
180
  MYTE_API_KEY=<project_api_key>
@@ -170,14 +185,14 @@ The key resolves the project server-side. Agents should not pass `project_id` ma
170
185
  Recommended agent flow:
171
186
 
172
187
  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.
188
+ 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
189
  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.
190
+ 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.
191
+ 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
192
  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`.
193
+ 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
194
  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.
195
+ 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
196
 
182
197
  PRD document contract:
183
198
 
@@ -188,33 +203,41 @@ PRD document contract:
188
203
  - The UI renders the PRD from the stored document text, not from the card description.
189
204
  - 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
205
  - 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.
206
+ - 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
207
  - Document-set uploads preserve the exact source Markdown and also store a
193
208
  normalized rendering copy. Rendering cleanup never silently rewrites the
194
209
  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.
210
+ - Every newly created PRD receives immutable version `1` and a stable primary document id. Creation responses return `active_prd_version_id`, `active_prd_version_number`, and `primary_document_id`, which can be passed directly into `feedback tickets create`.
211
+ - A sub-ticket may link at most 25 PRD documents, and the backend rejects any version/document pair that does not belong to that exact Feedback/PRD before mutation.
212
+
213
+ ## Connectivity Diagnostics
214
+
215
+ Run this before assuming an API key or server failure:
216
+
217
+ ```bash
218
+ myte doctor --json
219
+ ```
220
+
221
+ Interpret the first failed layer:
222
+
223
+ - `dns`: the API hostname could not be resolved.
224
+ - `tcp`: the host resolved but port 443 could not be reached.
225
+ - `tls`: the secure connection was reset or certificate validation failed
226
+ before an HTTP request reached Myte.
227
+ - `http`: Myte or an intermediary returned a status or non-JSON response.
211
228
  - `authentication` / `authorization`: the API received the request and
212
229
  rejected the credential or capability.
213
230
 
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.
231
+ An authorization response with `policy_consent_required` means the key is
232
+ valid, but the user who created it must review and accept the current Myte
233
+ Policy from the mission-board link printed by the CLI. Rotate the key only if
234
+ the API reports authentication failure or revocation; policy acceptance is a
235
+ separate user-governance step.
236
+
237
+ On restricted Wi-Fi, complete any captive-portal login, configure the
238
+ network's supported proxy/VPN, or retry on another network. The CLI honors
239
+ `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`; it never recommends disabling
240
+ certificate verification.
218
241
 
219
242
  Preferred file shape:
220
243
 
@@ -239,7 +262,7 @@ Feedback comments nuance:
239
262
 
240
263
  - `myte feedback-sync` reads existing feedback comment turns and stores them in `MyteCommandCenter/data/feedback.yml`.
241
264
  - 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`.
265
+ - 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
266
  - 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
267
 
245
268
  ## Commands
@@ -251,10 +274,10 @@ Feedback comments nuance:
251
274
  - `mission archive`: archive missions without hard delete
252
275
  - `sync-qaqc`: refresh active mission QAQC context locally
253
276
  - `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
277
+ - `feedback status|edit|assign|archive|refine`: create reviewable local feedback artifacts only
278
+ - `feedback submit|revise|comment`: live Feedback writes requiring `--confirm-write --approval-artifact <path>`
279
+ - `feedback review|move|undo|apply`: governed Feedback writes with no approval artifact flags
280
+ - `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate`: read, sync, or validate Feedback state
258
281
  - `suggestions sync|create|revise|review`: work with mission suggestion workflow state
259
282
  - `query`: ask the project assistant, optionally with local diff context
260
283
  - `ai`: use the Myte AI gateway
@@ -291,12 +314,12 @@ Feedback comments nuance:
291
314
  | --- | --- | --- |
292
315
  | Sync mission cards and review threads | `myte bootstrap --json` | Refreshes `MyteCommandCenter/data/missions/*.yml`, project structure, and `MyteCommandCenter/data/mission-ops.yml`. |
293
316
  | 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. |
317
+ | 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. |
318
+ | 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. |
319
+ | 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`. |
320
+ | 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. |
321
+ | 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. |
322
+ | 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
323
 
301
324
  After `bootstrap`, find ids locally:
302
325
 
@@ -316,18 +339,22 @@ After `bootstrap`, find ids locally:
316
339
  | `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
340
  | `feedback assign` | Creates a local YAML proposal to change assignee. | Goes through review unless applied through owner-direct path. |
318
341
  | `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. |
342
+ | `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. |
343
+ | `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
344
  | `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. |
345
+ | `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. |
346
+ | `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. |
347
+ | `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. |
348
+ | `feedback tickets list` | Lists engineering subtickets linked to one Feedback/PRD. | Read-only and included in `feedback-sync` for IDE discovery. |
349
+ | `feedback tickets create` | Creates one ticket or one JSON/YAML batch. | `--dry-run` validates without mutation; live batches are approval-gated, idempotent, capped at 100 and return receipts. |
350
+ | `feedback tickets update` | Updates one ticket or many `--ticket-ids` in one revision-fenced batch. | The backend validates the whole batch before mutation and returns `409` for stale revisions. |
351
+ | `feedback tickets coverage` | Changes one ticket's coverage for one retained PRD document. | Synchronous, revision-fenced and approval-gated. |
352
+ | `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
353
  | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
327
354
  | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
328
355
  | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
329
356
  | `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`. |
357
+ | `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
358
 
332
359
  Canonical feedback lifecycle states are `frozen`, `todo`, `in_progress`, `in_review`, `completed`, `deployed`, `rejected`, and `archived`.
333
360
 
@@ -339,19 +366,20 @@ npx --package @mytegroupinc/myte-core node ./node_modules/@mytegroupinc/myte-cor
339
366
 
340
367
  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
368
 
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`
369
+ ## Direct Project API Surface
370
+
371
+ All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
372
+
373
+ `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.
374
+
375
+ Read/sync routes:
376
+
377
+ - `GET /api/project-assistant/query/<job_id>`
378
+ - `GET /api/project-assistant/config`
352
379
  - `GET /api/project-assistant/bootstrap`
353
380
  - `GET /api/project-assistant/qaqc-sync`
354
381
  - `GET /api/project-assistant/feedback-sync`
382
+ - `GET /api/project-assistant/feedback/<feedback_id>/tickets`
355
383
  - `GET /api/project-assistant/feedback/<feedback_id>`
356
384
  - `GET /api/project-assistant/feedback/<feedback_id>/refinement/history`
357
385
  - `GET /api/project-assistant/feedback-review-requests`
@@ -384,6 +412,13 @@ Mutation routes:
384
412
  - `POST /api/project-assistant/feedback/<feedback_id>/board-move`
385
413
  - `POST /api/project-assistant/feedback/batch-board-move`
386
414
  - `POST /api/project-assistant/feedback/<feedback_id>/comments`
415
+ - `POST /api/project-assistant/feedback/<feedback_id>/tickets`
416
+ - `POST /api/project-assistant/feedback/<feedback_id>/tickets/batch`
417
+ - `POST /api/project-assistant/feedback/<feedback_id>/tickets/batch/validate`
418
+ - `PATCH /api/project-assistant/feedback/<feedback_id>/tickets/<ticket_id>`
419
+ - `PATCH /api/project-assistant/feedback/<feedback_id>/tickets/batch`
420
+ - `POST /api/project-assistant/feedback/<feedback_id>/tickets/batch-update/validate`
421
+ - `PATCH /api/project-assistant/feedback/<feedback_id>/tickets/<ticket_id>/prd-coverage`
387
422
  - `POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo`
388
423
  - `POST /api/project-assistant/suggestions`
389
424
  - `POST /api/project-assistant/suggestions/revise`
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.56",
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.56"
23
23
  }
24
24
  }