myte 0.0.46 → 0.0.49

package/README.md

@@ -19,23 +19,34 @@ No install:
 
 - `npx myte@latest ...`
 
-`npm install myte` does not add `myte` to your shell `PATH`. Use `npx myte` or `npm exec myte -- ...` unless you installed globally.
-
-## Requirements
-
-- Node `18+`
+`npm install myte` does not add `myte` to your shell `PATH`. Use `npx myte` or `npm exec myte -- ...` unless you installed globally.
+
+The npm line `added N packages` is a dependency-graph count, not a count of
+files or Myte features. The public `myte` package is a small command wrapper,
+`@mytegroupinc/myte-core` contains the CLI implementation, and `undici`
+provides portable proxy support. A fresh `0.0.48` install therefore normally
+contains three graph nodes; npm may report fewer on an update when dependencies
+are already present or deduplicated. Run `myte info` or
+`myte --version --verbose` to inspect the exact topology.
+
+## Requirements
+
+- Node `18.17+`
 - macOS, Linux, or Windows
 - `MYTE_API_KEY=<project_api_key>` in your shell or workspace `.env`
 - `MYTEAI_API_KEY=<inference_api_key>` only for `myte ai`
 - `MYTEAI_API_KEY=<inference_api_key>` for `mytecody`
 - `git` in `PATH` only for `query --with-diff`
-- No runtime npm dependencies beyond the Myte packages themselves.
+- Standard `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` variables are honored
+  through the core transport dependency.
 
 The CLI searches for `.env` in the current folder and then up parent directories.
 
 ## Common Commands
 
-- `npx myte config --json`
+- `npx myte config --json`
+- `npx myte doctor --json`
+- `npx myte info`
 - `npx myte bootstrap`
 - `npx myte sync-qaqc`
 - `npx myte feedback-sync`
@@ -46,25 +57,26 @@ The CLI searches for `.env` in the current folder and then up parent directories
 - `npx myte feedback assign --feedback-id <id> --user-id <user_id> --reason "Assign to builder"`
 - `npx myte feedback archive --feedback-id <id> --reason "Superseded"`
 - `npx myte feedback validate --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
-- `npx myte feedback submit --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
-- `npx myte feedback reviews --status open`
-- `npx myte feedback revise --request-id <id> --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
-- `npx myte feedback review --request-id <id> --action approve --reason "Looks correct"`
-- `npx myte feedback review --request-ids "<id1,id2>" --action approve --reason "Batch approval"`
-- `npx myte feedback move --feedback-id <id> --to-state in_progress --reason "Started"`
-- `npx myte feedback move --feedback-ids "<id1,id2>" --to-state in_progress --reason "Batch move"`
-- `npx myte feedback comment --feedback-id <id> --body-file ./updates/feedback-comment.md`
+- `npx myte feedback submit --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
+- `npx myte feedback reviews --status open`
+- `npx myte feedback revise --request-id <id> --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml --confirm-write --approval-artifact ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
+- `npx myte feedback review --request-id <id> --action approve --reason "Looks correct"`
+- `npx myte feedback review --request-ids "<id1,id2>" --action approve --reason "Batch approval"`
+- `npx myte feedback move --feedback-id <id> --to-state in_progress --reason "Started"`
+- `npx myte feedback move --feedback-ids "<id1,id2>" --to-state in_progress --reason "Batch move"`
+- `npx myte feedback comment --feedback-id <id> --body-file ./updates/feedback-comment.md --confirm-write --approval-artifact ./updates/feedback-comment.md`
 - `npx myte feedback undo --feedback-id <id> --event-id <event_id> --reason "Undo accidental move"`
 - `npx myte feedback prd-versions --feedback-id <id>`
 - `npx myte feedback prd-diff --feedback-id <id> --version-id <version_id> --compare-to <base_version_id>`
 - `npx myte feedback apply --file ./MyteCommandCenter/reviews/feedback/<id>-edit.yml`
 - `npx myte suggestions sync`
 - `npx myte mission archive --mission-ids "M001" --reason "Duplicate disposable mission"`
-- `npx myte query "Summarize the current branch changes" --with-diff`
-- `npx myte create-prd ./drafts/auth-prd.md`
-- `npx myte update-team "Backend deploy completed."`
-- `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md`
-- `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md`
+- `npx myte query "Summarize the current branch changes" --with-diff --json`
+- `npx myte create-prd ./drafts/auth-prd.md --confirm-write --approval-artifact ./drafts/auth-prd.md`
+- `npx myte create-prd ./drafts/proposal.md ./drafts/harness.md ./drafts/security.md --document-set --confirm-write --approval-artifact ./drafts/approval.md`
+- `npx myte update-team "Backend deploy completed." --confirm-write --approval-artifact ./updates/team.md`
+- `npx myte update-owner --subject "QAQC progress" --body-file ./updates/owner.md --confirm-write --approval-artifact ./updates/owner.md`
+- `npx myte update-client --subject "Weekly client update" --body-file ./updates/week-12.md --confirm-write --approval-artifact ./updates/week-12.md`
 - `npx mytecody doctor`
 - `npx mytecody doctor --probe-gateway`
 - `npx mytecody update --dry-run`
@@ -72,11 +84,25 @@ The CLI searches for `.env` in the current folder and then up parent directories
 
 ## Behavior
 
+- `doctor` performs read-only package, credential-presence, DNS, direct
+  TCP/TLS, authenticated config, proxy, and workspace checks. It reports the
+  failing layer without printing the API key, proxy URL, request body, or
+  response body.
+- Network failures distinguish DNS, TCP, TLS/certificate, timeout, captive
+  portal/non-JSON, authentication, authorization, rate-limit, and server
+  response failures. Do not disable TLS verification to work around a failed
+  diagnostic.
+- Safe transient reads and query polling use bounded retries. Query creation
+  uses one stable idempotency key across ambiguous retries so a lost response
+  cannot create duplicate inference jobs.
 - `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write project-scoped local context under `MyteCommandCenter` in the current workspace unless `--output-dir` is provided.
 - `bootstrap` writes mission cards and mission suggestion thread state together; agents should run it before looking for mission or suggestion ids.
 - `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.
 - `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.
-- `feedback status|edit|assign|archive` writes local review artifacts under `MyteCommandCenter/reviews/feedback`; `feedback submit|revise|reviews|review` routes proposed edits through the backend owner-review membrane.
+- `feedback status|edit|assign|archive|refine` writes local review artifacts under `MyteCommandCenter/reviews/feedback`.
+- `feedback submit|revise|comment` are live writes that require `--confirm-write --approval-artifact <path>`.
+- `feedback review|move|undo|apply` are governed writes with backend permission checks but no approval artifact flags.
+- `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate` are read/sync/validation commands with no approval artifact flags.
 - `feedback review --request-ids` sends one backend batch review request with grouped notifications; do not loop single-review calls for batch decisions.
 - `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.
 - `feedback comment` creates text-only feedback-specific comments. Attachments remain web UI only for this project-key endpoint.
@@ -86,15 +112,48 @@ The CLI searches for `.env` in the current folder and then up parent directories
 - 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.
 - 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.
 
-## Live Write Approval
+## Approval Artifact Requirements
+
+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>`.
+
+| Category | Commands | Artifact |
+| --- | --- | --- |
+| Required | `create-prd`, `update-team`, `update-owner`, `update-client`, `feedback submit`, `feedback revise`, `feedback comment`, `suggestions create`, `suggestions revise` | Yes |
+| Not required | `run-qaqc`, `mission status`, `mission archive`, `suggestions review`, `feedback review`, `feedback move`, `feedback undo`, `feedback apply` | No |
+| 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 |
 
-All live project-key writes must be approved by the user before the CLI sends them to Myte.
+For required actions:
 
-- First create a local `.md`, `.yml`, `.yaml`, or `.json` approval artifact that lists the command, every target id, and the proposed change.
-- Show the artifact path and full content or concise complete summary to the user.
+- First create a local `.md`, `.markdown`, `.yml`, `.yaml`, or `.json` approval artifact that lists the command, every target id, and the proposed change.
+- Show the artifact path and full content or a concise complete summary to the user.
 - After explicit approval, rerun the write with `--confirm-write --approval-artifact <path>`.
-- Batch writes must enumerate every feedback id, mission id, suggestion id, request id, or PRD item in the artifact. QAQC batches are capped by the API at 10 mission ids.
-- The API also validates the approval envelope, payload hash, targets, and true batch count, so direct HTTP calls with only the API key are rejected.
+- Batch artifacts must enumerate every feedback id, suggestion id, request id, or PRD item.
+
+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.
+
+Minimum artifact contents:
+
+- `command`: the exact CLI command to run.
+- `targets`: every affected feedback id, request id, suggestion id, mission id, PRD file/client ref, project, or contact id.
+- `proposed_change`: a complete summary of the status, text, PRD, comment, or mission change.
+- `batch_count`: required when one command sends multiple items.
+- `reason` or `approval_note`: why the write is being sent.
+
+Batch guidance:
+
+- 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.
+- Without `--document-set`, `myte create-prd fileA.md fileB.md ...` preserves
+  the existing behavior and creates one independent Feedback item per file.
+- With `--document-set`, one to three Markdown files create one Feedback item
+  with ordered, independently readable PRD documents. Each document is
+  validated locally against the 250,000-character server contract. The
+  approval artifact must list every file/title/client ref and the matching
+  document count.
+- 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.
+- 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.
+- `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.
+
+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.
 
 ## Agent Usage Contract
 
@@ -109,14 +168,14 @@ The key resolves the project server-side. Agents should not pass `project_id` ma
 Recommended agent flow:
 
 1. Run `myte config --json` to confirm the project, API base, configured repos, and local workspace detection.
-2. Run `myte bootstrap --json`, `myte feedback-sync --json`, or `myte sync-qaqc --json` to hydrate local context under `MyteCommandCenter`. Use `myte suggestions sync --json` only for narrow mission-review refreshes after bootstrap.
+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.
 3. Use `myte query "<goal/evidence/ask>" --with-diff` when local code changes matter.
-4. Use `myte create-prd <file.md>` only after the PRD markdown has been reviewed by a human, then send it with `--confirm-write --approval-artifact <path>`. The file body is the PRD document; `--description` is only the short board/card summary.
-5. Use `myte feedback status|edit|assign|archive` to create reviewable local artifacts, then `feedback submit` and `feedback review` for the owner-review membrane.
+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.
+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.
 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.
-7. Use `myte suggestions create|revise|review` for mission review threads. Valid create `change_type` values are exactly `update` and `create`; revisions keep the existing thread type and must not include `change_type`.
+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`.
 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.
-9. Use `myte update-team "<content>"` for project/team comments through `/api/project-assistant/project-comment`, and `myte feedback comment --feedback-id <id> --body-file ./comment.md` for feedback-specific implementation notes.
+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.
 
 PRD document contract:
 
@@ -127,7 +186,33 @@ PRD document contract:
 - The UI renders the PRD from the stored document text, not from the card description.
 - 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.
 - Do not wrap the whole PRD in a ` ```markdown ` fence. Do not use raw HTML, inline style blocks, or decorative banners.
-- 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.
+- 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.
+- Document-set uploads preserve the exact source Markdown and also store a
+  normalized rendering copy. Rendering cleanup never silently rewrites the
+  approved source.
+
+## Connectivity Diagnostics
+
+Run this before assuming an API key or server failure:
+
+```bash
+myte doctor --json
+```
+
+Interpret the first failed layer:
+
+- `dns`: the API hostname could not be resolved.
+- `tcp`: the host resolved but port 443 could not be reached.
+- `tls`: the secure connection was reset or certificate validation failed
+  before an HTTP request reached Myte.
+- `http`: Myte or an intermediary returned a status or non-JSON response.
+- `authentication` / `authorization`: the API received the request and
+  rejected the credential or capability.
+
+On restricted Wi-Fi, complete any captive-portal login, configure the
+network's supported proxy/VPN, or retry on another network. The CLI honors
+`HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`; it never recommends disabling
+certificate verification.
 
 Preferred file shape:
 
@@ -152,7 +237,7 @@ Feedback comments nuance:
 
 - `myte feedback-sync` reads existing feedback comment turns and stores them in `MyteCommandCenter/data/feedback.yml`.
 - The web product supports feedback-specific comment create/fetch through JWT-authenticated `/api/feedbacks/<feedback_id>/comments`.
-- The project-key npm CLI supports `myte feedback comment --feedback-id <id> --body "..."` and `--body-file ./comment.md`.
+- 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`.
 - 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.
 
 ## Commands
@@ -164,7 +249,10 @@ Feedback comments nuance:
 - `mission archive`: archive missions without hard delete
 - `sync-qaqc`: refresh active mission QAQC context locally
 - `feedback-sync`: refresh feedback and PRD context locally
-- `feedback status|edit|assign|archive|submit|revise|reviews|review|move|comment|undo|prd-versions|prd-diff|validate|apply|history|get`: create reviewable feedback artifacts and operate the governed Feedback API
+- `feedback status|edit|assign|archive|refine`: create reviewable local feedback artifacts only
+- `feedback submit|revise|comment`: live Feedback writes requiring `--confirm-write --approval-artifact <path>`
+- `feedback review|move|undo|apply`: governed Feedback writes with no approval artifact flags
+- `feedback-sync|get|history|reviews|prd-versions|prd-diff|validate`: read, sync, or validate Feedback state
 - `suggestions sync|create|revise|review`: work with mission suggestion workflow state
 - `query`: ask the project assistant, optionally with local diff context
 - `ai`: use the Myte AI gateway
@@ -201,12 +289,12 @@ Feedback comments nuance:
 | --- | --- | --- |
 | Sync mission cards and review threads | `myte bootstrap --json` | Refreshes `MyteCommandCenter/data/missions/*.yml`, project structure, and `MyteCommandCenter/data/mission-ops.yml`. |
 | Sync only mission review threads | `myte suggestions sync --json` | Narrow refresh for `mission-ops.yml` after bootstrap or a mutation. |
-| Suggest edit to existing mission | `myte suggestions create` with `change_type: update` and `mission_id` | Creates or appends to an active review thread; live mission is unchanged until approval. |
-| Suggest new mission | `myte suggestions create` with `change_type: create` | Requires `change_set.title` and `change_set.description`; mission card is created only after approval. |
-| Revise a suggestion | `myte suggestions revise` with `suggestion_id` | Adds another revision to the same thread. Do not include `change_type`. |
-| Review a suggestion | `myte suggestions review` with `review_action: approve|request_changes|reject` | Project Owner or elevated mission-review delegate required. |
-| Update mission status | `myte mission status --mission-ids "M001" --status todo|in_progress|done` | Active status update only; refreshes local bootstrap + mission-ops by default. |
-| Archive mission | `myte mission archive --mission-ids "M001" --reason "..."` | Project Owner or elevated delegate required. Keeps the mission record, hides it from normal board/bootstrap state, and refreshes local bootstrap + mission-ops by default. |
+| 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. |
+| 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. |
+| 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`. |
+| 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. |
+| 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. |
+| 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. |
 
 After `bootstrap`, find ids locally:
 
@@ -226,18 +314,18 @@ After `bootstrap`, find ids locally:
 | `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. |
 | `feedback assign` | Creates a local YAML proposal to change assignee. | Goes through review unless applied through owner-direct path. |
 | `feedback archive` | Creates a local YAML proposal to archive. | Archive is governed by backend owner/delegate capability. |
-| `feedback submit` | Sends a local proposal artifact to the backend as a review request. | Does not mutate live feedback before approval. |
-| `feedback revise` | Resubmits the original submitter's request after `request_changes`. | Only valid for the original submitter and `needs_changes` requests. |
+| `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. |
+| `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. |
 | `feedback reviews` | Lists review requests or fetches one request by `--request-id`. | Read-only; response includes backend permissions. |
-| `feedback review` | Approves, rejects, requests changes, or cancels one review request, or a batch with `--request-ids`. | Backend restricts approval/review decisions to Project Owner or elevated delegate for Feedback scope; batch review uses one grouped notification path. |
-| `feedback move` | Moves a card or batch of cards across allowed board states directly with an audit event. | `--feedback-ids` sends one batch request. Blocked with `pending_feedback_review` while an active linked review request exists; governed states such as archive/reject/deploy/freeze remain backend-authorized. Project-key unarchive is not supported. |
-| `feedback comment` | Creates a text-only comment on one Feedback item. | Backend checks project-key access, owner/assigned permission, idempotency, and the 500,000-character content cap. Attachments remain web UI only. |
-| `feedback undo` | Reverses an audited board event when there is no conflict. | Backend validates event ownership/project scope and conflict state. |
+| `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. |
+| `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. |
+| `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. |
+| `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. |
 | `feedback prd-versions` | Lists retained PRD baselines/revisions for a feedback item. | Read-only; old S3 objects are retained by reference. |
 | `feedback prd-diff` | Fetches backend-generated text diff for PRD versions. | Read-only; backend controls version access. |
 | `feedback history` | Lists audited feedback board/refinement events. | Read-only; backend checks project access. |
 | `feedback validate` | Sends an artifact to backend validation without mutation. | Useful before submit or owner-direct apply. |
-| `feedback apply` | Applies an artifact through the owner-direct/emergency path. | Not the normal collaborator flow; normal flow is `submit` -> `review`. |
+| `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`. |
 
 Canonical feedback lifecycle states are `frozen`, `todo`, `in_progress`, `in_review`, `completed`, `deployed`, `rejected`, and `archived`.
 
@@ -249,13 +337,16 @@ npx --package @mytegroupinc/myte-core node ./node_modules/@mytegroupinc/myte-cor
 
 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.
 
-## Direct Project API Surface
-
-All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
-
-Read/sync routes:
-
-- `GET /api/project-assistant/config`
+## Direct Project API Surface
+
+All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes.
+
+`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.
+
+Read/sync routes:
+
+- `GET /api/project-assistant/query/<job_id>`
+- `GET /api/project-assistant/config`
 - `GET /api/project-assistant/bootstrap`
 - `GET /api/project-assistant/qaqc-sync`
 - `GET /api/project-assistant/feedback-sync`

package/package.json

@@ -1,24 +1,28 @@
 {
   "name": "myte",
-  "version": "0.0.46",
+  "version": "0.0.49",
   "description": "Myte developer CLI.",
   "type": "commonjs",
   "license": "MIT",
   "files": [
-    "README.md",
-    "THIRD_PARTY_NOTICES.md",
-    "TRADEMARKS.md",
-    "bin",
-    "package.json"
+    "README.md",
+    "THIRD_PARTY_NOTICES.md",
+    "TRADEMARKS.md",
+    "bin",
+    "scripts",
+    "package.json"
   ],
-  "bin": {
-    "myte": "bin/myte.js",
-    "mytecody": "bin/mytecody.js"
-  },
-  "engines": {
-    "node": ">=18"
+  "bin": {
+    "myte": "bin/myte.js",
+    "mytecody": "bin/mytecody.js"
+  },
+  "scripts": {
+    "postinstall": "node scripts/postinstall.js"
+  },
+  "engines": {
+    "node": ">=18.17"
   },
   "dependencies": {
-    "@mytegroupinc/myte-core": "0.0.46"
+    "@mytegroupinc/myte-core": "0.0.49"
   }
 }

package/scripts/postinstall.js

@@ -0,0 +1,8 @@
+#!/usr/bin/env node
+
+console.log([
+  "Myte CLI installed successfully.",
+  "Included: myte and mytecody commands, the Myte API client, and portable proxy support.",
+  "The MyteCody engine and client assets are downloaded on first `mytecody` coding run.",
+  "Run `myte --help` to get started.",
+].join("\n"));