myte 0.0.42 → 0.0.44

package/README.md

@@ -33,9 +33,11 @@ No install:
 
 The CLI searches for `.env` in the current folder and then up parent directories.
 
-## Common Commands
-
-- `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`
@@ -70,10 +72,11 @@ The CLI searches for `.env` in the current folder and then up parent directories
 - `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.
-- `bootstrap` writes mission cards and mission suggestion thread state together; agents should run it before looking for mission or suggestion ids.
+## 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.
@@ -96,17 +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. 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.
-5. Use `myte feedback status|edit|assign|archive` to create reviewable local artifacts, then `feedback submit` and `feedback review` for the owner-review membrane.
-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`.
-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.
+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:
 
@@ -163,7 +170,9 @@ Feedback comments nuance:
   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`.
+  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
@@ -239,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.
+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:
 
@@ -254,22 +263,22 @@ 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>`
-
-Mutation routes:
-
-- `POST /api/project-assistant/query`
-- `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/validate`
-- `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`

package/bin/myte.js

@@ -1,4 +1,4 @@
-#!/usr/bin/env node
+#!/usr/bin/env node
 const core = require("@mytegroupinc/myte-core/cli");
 
 if (!core || typeof core.main !== "function") {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "myte",
-  "version": "0.0.42",
+  "version": "0.0.44",
   "description": "Myte developer CLI.",
   "type": "commonjs",
   "license": "MIT",
@@ -19,6 +19,6 @@
     "node": ">=18"
   },
   "dependencies": {
-    "@mytegroupinc/myte-core": "0.0.42"
+    "@mytegroupinc/myte-core": "0.0.44"
   }
 }