@mytegroupinc/myte-core 0.0.43 → 0.0.44

package/README.md

@@ -20,8 +20,9 @@ This package exists so the public wrapper can stay small and versioned cleanly.
 
 ## Behavior Summary
 
-- Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
-- `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
+- Snapshot-style commands such as `bootstrap`, `sync-qaqc`, `feedback-sync`, and `suggestions sync` write local `MyteCommandCenter` data.
+- 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>`.
+- `feedback status|edit|assign|archive` writes reviewable local YAML artifacts; `feedback submit|revise|reviews|review` routes them through the backend owner-review membrane.
 - `feedback move|comment|undo|prd-versions|prd-diff|history` calls the project-key Feedback API while leaving lifecycle rules and permissions server-side. `feedback move --feedback-ids` sends one batch move request.
 - `feedback validate|apply` remains available for validation and owner-direct apply paths; live authorization, stale checks, and history stay server-side.
 - `query --with-diff` requires project repos to be configured for diff collection and fails fast when no matching local project repo can be resolved.
@@ -44,11 +45,15 @@ This package exists so the public wrapper can stay small and versioned cleanly.
 
 ## Agent Usage Contract
 
-Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant key:
-
-- Load it from the workspace `.env` or environment. `MYTE_PROJECT_API_KEY` is accepted as a compatibility fallback.
-- Call `myte config --json` first when project identity or local repo detection is uncertain.
-- Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards and mission suggestion thread state.
+Coding agents should treat `MYTE_API_KEY` as a project-scoped Project Assistant key:
+
+- Load it from the workspace `.env` or environment. `MYTE_PROJECT_API_KEY` is accepted as a compatibility fallback.
+- Call `myte config --json` first when project identity or local repo detection is uncertain.
+- 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.
+- 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.
+- 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.
+- Read/sync/query/validate commands, `--print-context`, and `--dry-run` do not require write approval.
+- Hydrate mission context with `bootstrap` first instead of scraping the web UI. `bootstrap` writes mission cards and mission suggestion thread state.
 - Use `suggestions sync` only when you need to refresh mission review-thread state without refreshing the full board.
 - Use `query --with-diff` for project-scoped code review, planning, and implementation questions.
 - Use `create-prd` only with reviewed markdown files. The markdown file body is the PRD document; `description` is only the short board/card summary.
@@ -185,9 +190,9 @@ node ./scripts/feedback-live-full-harness.js --confirm-live --base-url https://a
 
 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.
+## 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>`.
 
 Read/sync routes:
 
@@ -202,21 +207,21 @@ 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/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`