myte 0.0.44 → 0.0.45

package/README.md

@@ -25,19 +25,19 @@ No install:
 
 - Node `18+`
 - 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.
+- `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.
 
 The CLI searches for `.env` in the current folder and then up parent directories.
 
-## Common Commands
-
-Live mutation commands require `--confirm-write --approval-artifact <path>` after the local artifact has been shown to and approved by the user.
-
-- `npx myte config --json`
+## Common Commands
+
+Live mutation commands require `--confirm-write --approval-artifact <path>` after the local artifact has been shown to and approved by the user.
+
+- `npx myte config --json`
 - `npx myte bootstrap`
 - `npx myte sync-qaqc`
 - `npx myte feedback-sync`
@@ -51,12 +51,12 @@ Live mutation commands require `--confirm-write --approval-artifact <path>` afte
 - `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 undo --feedback-id <id> --event-id <event_id> --reason "Undo accidental move"`
+- `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 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`
@@ -65,24 +65,24 @@ Live mutation commands require `--confirm-write --approval-artifact <path>` afte
 - `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 mytecody doctor`
-- `npx mytecody doctor --probe-gateway`
-- `npx mytecody update --dry-run`
-- `npx mytecody update`
-
-## Behavior
-
-- `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write project-scoped local context under `MyteCommandCenter` in the current workspace unless `--output-dir` is provided.
-- Live project-key mutations require explicit user approval before the CLI sends them. Create a local approval artifact, show it to the user, then rerun with `--confirm-write --approval-artifact <path>`.
-- `bootstrap` writes mission cards and mission suggestion thread state together; agents should run it before looking for mission or suggestion ids.
+- `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 mytecody doctor`
+- `npx mytecody doctor --probe-gateway`
+- `npx mytecody update --dry-run`
+- `npx mytecody update`
+
+## Behavior
+
+- `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write project-scoped local context under `MyteCommandCenter` in the current workspace unless `--output-dir` is provided.
+- Live project-key mutations require explicit user approval before the CLI sends them. Create a local approval artifact, show it to the user, then rerun with `--confirm-write --approval-artifact <path>`.
+- `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 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.
+- `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.
 - `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.
 - `feedback validate|apply` remains available for validation and owner-direct apply paths.
 - `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.
@@ -99,21 +99,21 @@ MYTE_API_KEY=<project_api_key>
 
 The key resolves the project server-side. Agents should not pass `project_id` manually for normal CLI commands, and they should not call account-scoped web/JWT endpoints with this key.
 
-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.
-3. Use `myte query "<goal/evidence/ask>" --with-diff` when local code changes matter.
-4. Before any live write, create a local approval artifact, show it to the user, and get explicit approval. Use `.md` for comments, human updates, and PRD markdown; use `.yml`/`.yaml` or `.json` for structured mission/feedback decisions and batch writes.
-5. After approval, rerun the mutation with `--confirm-write --approval-artifact <path>`. Batch artifacts must enumerate every feedback id, mission id, suggestion id, request id, or PRD item.
-6. Direct HTTP calls with `MYTE_API_KEY` cannot bypass this gate on live project-content mutations. The API returns `428` with agent instructions when approval metadata is missing or mismatched.
-7. Read/sync/query/validate commands, `--print-context`, and `--dry-run` do not require write approval.
-8. Use `myte create-prd <file.md>` only after the PRD markdown has been reviewed by a human. The file body is the PRD document; `--description` is only the short board/card summary.
-9. Use `myte feedback status|edit|assign|archive` to create reviewable local artifacts, then `feedback submit` and `feedback review` for the owner-review membrane.
-10. Use `myte feedback move` only for direct board movement that is intentionally audited, with a clear `--reason`; use `--feedback-ids` for batch moves or batch archive.
-11. Use `myte suggestions create|revise|review` for mission review threads. Valid create `change_type` values are exactly `update` and `create`; revisions keep the existing thread type and must not include `change_type`.
-12. Use `myte mission archive` for project-key mission lifecycle archival. Archive requires Project Owner or elevated delegate capability; restore is web-only from the archived missions board.
-13. Use `myte update-team "<content>"` for project/team comments through `/api/project-assistant/project-comment`, and `myte feedback comment --feedback-id <id> --body-file ./comment.md` for feedback-specific implementation notes.
+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.
+3. Use `myte query "<goal/evidence/ask>" --with-diff` when local code changes matter.
+4. Before any live write, create a local approval artifact, show it to the user, and get explicit approval. Use `.md` for comments, human updates, and PRD markdown; use `.yml`/`.yaml` or `.json` for structured mission/feedback decisions and batch writes.
+5. After approval, rerun the mutation with `--confirm-write --approval-artifact <path>`. Batch artifacts must enumerate every feedback id, mission id, suggestion id, request id, or PRD item.
+6. Direct HTTP calls with `MYTE_API_KEY` cannot bypass this gate on live project-content mutations. The API returns `428` with agent instructions when approval metadata is missing or mismatched.
+7. Read/sync/query/validate commands, `--print-context`, and `--dry-run` do not require write approval.
+8. Use `myte create-prd <file.md>` only after the PRD markdown has been reviewed by a human. The file body is the PRD document; `--description` is only the short board/card summary.
+9. Use `myte feedback status|edit|assign|archive` to create reviewable local artifacts, then `feedback submit` and `feedback review` for the owner-review membrane.
+10. Use `myte feedback move` only for direct board movement that is intentionally audited, with a clear `--reason`; use `--feedback-ids` for batch moves or batch archive.
+11. Use `myte suggestions create|revise|review` for mission review threads. Valid create `change_type` values are exactly `update` and `create`; revisions keep the existing thread type and must not include `change_type`.
+12. Use `myte mission archive` for project-key mission lifecycle archival. Archive requires Project Owner or elevated delegate capability; restore is web-only from the archived missions board.
+13. Use `myte update-team "<content>"` for project/team comments through `/api/project-assistant/project-comment`, and `myte feedback comment --feedback-id <id> --body-file ./comment.md` for feedback-specific implementation notes.
 
 PRD document contract:
 
@@ -145,12 +145,12 @@ Preferred file shape:
 Full PRD content goes here.
 ````
 
-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`.
-- 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.
+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`.
+- 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
 
@@ -161,36 +161,36 @@ 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|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
 - `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
-- `mytecody`: MyteCody team launcher installed by this package. It supports
-  `doctor`, `doctor --probe-gateway`, `update --dry-run`, and `update`.
-  On first coding run, it installs the branded MyteCody engine and signed
-  client assets from the Myte release manifest into a user-local Myte cache
-  after signature/hash checks. Coding execution requires those assets, a
-  reachable Myte AI Cody gateway, and `MYTEAI_API_KEY`. Normal coding runs use
-  the branded Codex harness with Myte context hardening; the experimental
-  controller is not the default product path.
-- `mytecody doctor` reports both the signed MyteCody engine state and this npm
-  package version. `mytecody update` updates the engine only. Use
-  `npm install -g myte@latest` to update the launcher and the Myte API CLI
-  commands shipped by npm.
-- `create-prd`: upload deterministic PRD markdown as the stored renderable PRD document; use `description` only as the short card summary
+- `ai`: use the Myte AI gateway
+- `mytecody`: MyteCody team launcher installed by this package. It supports
+  `doctor`, `doctor --probe-gateway`, `update --dry-run`, and `update`.
+  On first coding run, it installs the branded MyteCody engine and signed
+  client assets from the Myte release manifest into a user-local Myte cache
+  after signature/hash checks. Coding execution requires those assets, a
+  reachable Myte AI Cody gateway, and `MYTEAI_API_KEY`. Normal coding runs use
+  the branded Codex harness with Myte context hardening; the experimental
+  controller is not the default product path.
+- `mytecody doctor` reports both the signed MyteCody engine state and this npm
+  package version. `mytecody update` updates the engine only. Use
+  `npm install -g myte@latest` to update the launcher and the Myte API CLI
+  commands shipped by npm.
+- `create-prd`: upload deterministic PRD markdown as the stored renderable PRD document; use `description` only as the short card summary
 - `update-team`, `update-owner`, `update-client`: send project updates through the project-key surface
 
 ## Notes
 
-- The package ships the CLI only. Internal rollout notes, validation logs, and project-specific operating docs are not part of the public npm contract.
-- The package does not bundle the large MyteCody engine binary or the async
-  Responses bridge implementation. The `mytecody` launcher installs or updates
-  signed engine/client assets through the Myte release manifest.
-- `mytecody update` is intentionally engine-scoped. npm package updates use
-  `npm install -g myte@latest`.
-- The public `myte` package is the supported entrypoint. The scoped `@mytegroupinc/myte-core` package is the implementation dependency used by the wrapper.
-- See `THIRD_PARTY_NOTICES.md` and `TRADEMARKS.md` for Codex lineage and Myte
-  brand notices.
+- The package ships the CLI only. Internal rollout notes, validation logs, and project-specific operating docs are not part of the public npm contract.
+- The package does not bundle the large MyteCody engine binary or the async
+  Responses bridge implementation. The `mytecody` launcher installs or updates
+  signed engine/client assets through the Myte release manifest.
+- `mytecody update` is intentionally engine-scoped. npm package updates use
+  `npm install -g myte@latest`.
+- The public `myte` package is the supported entrypoint. The scoped `@mytegroupinc/myte-core` package is the implementation dependency used by the wrapper.
+- See `THIRD_PARTY_NOTICES.md` and `TRADEMARKS.md` for Codex lineage and Myte
+  brand notices.
 
 ## Mission Action Map
 
@@ -226,10 +226,10 @@ After `bootstrap`, find ids locally:
 | `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 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`. | 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 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. |
@@ -248,7 +248,7 @@ The harness creates five disposable `TEST` feedback items from markdown, verifie
 
 ## Direct Project API Surface
 
-All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes. Live project-content mutation routes also require write-approval headers; the official CLI supplies them from `--confirm-write --approval-artifact <path>`.
+All routes use `Authorization: Bearer <MYTE_API_KEY>`. The CLI adds idempotency and client-session headers on mutation routes. Live project-content mutation routes also require write-approval headers; the official CLI supplies them from `--confirm-write --approval-artifact <path>`.
 
 Read/sync routes:
 
@@ -263,32 +263,32 @@ Read/sync routes:
 - `GET /api/project-assistant/feedback/<feedback_id>/events`
 - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions`
 - `GET /api/project-assistant/feedback/<feedback_id>/prd/versions/<version_id>/diff`
-- `GET /api/project-assistant/suggestions`
-- `GET /api/project-assistant/run-qaqc/<batch_id>`
-- `POST /api/project-assistant/query`
-- `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
-
-Live project-content mutation routes:
-
-- `POST /api/project-assistant/run-qaqc`
+- `GET /api/project-assistant/suggestions`
+- `GET /api/project-assistant/run-qaqc/<batch_id>`
+- `POST /api/project-assistant/query`
+- `POST /api/project-assistant/feedback/<feedback_id>/refinement/validate`
+
+Live project-content mutation routes:
+
+- `POST /api/project-assistant/run-qaqc`
 - `POST /api/project-assistant/mission-status-update`
 - `POST /api/project-assistant/mission-archive`
 - `POST /api/project-assistant/project-comment`
 - `POST /api/project-assistant/update-owner`
 - `POST /api/project-assistant/client-update-drafts`
-- `POST /api/project-assistant/create-prd`
-- `POST /api/project-assistant/create-prds`
-- `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
+- `POST /api/project-assistant/create-prd`
+- `POST /api/project-assistant/create-prds`
+- `POST /api/project-assistant/feedback/<feedback_id>/refinement/requests`
 - `POST /api/project-assistant/feedback-review-requests/<request_id>/revise`
 - `POST /api/project-assistant/feedback/<feedback_id>/refinement/apply`
 - `POST /api/project-assistant/feedback-review-requests/<request_id>/review`
 - `POST /api/project-assistant/feedback-review-requests/batch-review`
 - `POST /api/project-assistant/feedback-review-requests/<request_id>/request-changes`
 - `POST /api/project-assistant/feedback-review-requests/<request_id>/cancel`
-- `POST /api/project-assistant/feedback/<feedback_id>/board-move`
-- `POST /api/project-assistant/feedback/batch-board-move`
-- `POST /api/project-assistant/feedback/<feedback_id>/comments`
-- `POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo`
+- `POST /api/project-assistant/feedback/<feedback_id>/board-move`
+- `POST /api/project-assistant/feedback/batch-board-move`
+- `POST /api/project-assistant/feedback/<feedback_id>/comments`
+- `POST /api/project-assistant/feedback/<feedback_id>/events/<event_id>/undo`
 - `POST /api/project-assistant/suggestions`
 - `POST /api/project-assistant/suggestions/revise`
 - `POST /api/project-assistant/suggestions/review`

package/THIRD_PARTY_NOTICES.md

@@ -1,11 +1,11 @@
-# Third-Party Notices
-
-The `myte` package exposes the `mytecody` command. The command installs and
-launches a branded MyteCody engine and signed client assets from a Myte release
-manifest.
-
-The branded MyteCody engine is derived from the OpenAI Codex open-source
-project, version baseline `0.139.0`, licensed under Apache-2.0.
-
-Myte names, marks, logos, terminal branding, and product design are separate
-Myte-owned brand assets.
+# Third-Party Notices
+
+The `myte` package exposes the `mytecody` command. The command installs and
+launches a branded MyteCody engine and signed client assets from a Myte release
+manifest.
+
+The branded MyteCody engine is derived from the OpenAI Codex open-source
+project, version baseline `0.139.0`, licensed under Apache-2.0.
+
+Myte names, marks, logos, terminal branding, and product design are separate
+Myte-owned brand assets.

package/TRADEMARKS.md

@@ -1,10 +1,10 @@
-# Trademarks
-
-Myte, Myte AI, MyteCody, "MYTE CODY - Your Tech Your Way", logo assets, terminal
-animation assets, and related product branding are Myte-owned marks and brand
-assets.
-
-OpenAI and Codex are trademarks or project names of their respective owners.
-MyteCody uses a Codex-derived open-source engine under the applicable open
-source license, but MyteCody is a Myte product surface and is not presented as
-an official OpenAI product.
+# Trademarks
+
+Myte, Myte AI, MyteCody, "MYTE CODY - Your Tech Your Way", logo assets, terminal
+animation assets, and related product branding are Myte-owned marks and brand
+assets.
+
+OpenAI and Codex are trademarks or project names of their respective owners.
+MyteCody uses a Codex-derived open-source engine under the applicable open
+source license, but MyteCody is a Myte product surface and is not presented as
+an official OpenAI product.

package/bin/mytecody.js

@@ -1,19 +1,19 @@
-#!/usr/bin/env node
-"use strict";
-
-const cody = require("@mytegroupinc/myte-core/mytecody-cli");
-
-if (!cody || typeof cody.run !== "function") {
-  console.error("mytecody core entrypoint is unavailable.");
-  process.exit(1);
-}
-
-Promise.resolve(cody.run(process.argv.slice(2))).then(
-  (code) => {
-    process.exitCode = Number.isInteger(code) ? code : 0;
-  },
-  (err) => {
-    console.error("Unexpected error:", err?.message || err);
-    process.exitCode = 1;
-  },
-);
+#!/usr/bin/env node
+"use strict";
+
+const cody = require("@mytegroupinc/myte-core/mytecody-cli");
+
+if (!cody || typeof cody.run !== "function") {
+  console.error("mytecody core entrypoint is unavailable.");
+  process.exit(1);
+}
+
+Promise.resolve(cody.run(process.argv.slice(2))).then(
+  (code) => {
+    process.exitCode = Number.isInteger(code) ? code : 0;
+  },
+  (err) => {
+    console.error("Unexpected error:", err?.message || err);
+    process.exitCode = 1;
+  },
+);

package/package.json

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