@mastra/factory 0.14.1-alpha.3 → 0.14.1-alpha.4

package/factory-skills/factory-rereview/SKILL.md

@@ -148,6 +148,8 @@ Next, publish the re-review on the PR itself — this is part of every pass, not
 
 If GitHub rejects the review submission (e.g. the token authored the PR and cannot approve or request changes on it), fall back to `gh pr comment <number> --body-file <file>` so the verdict still lands on the PR, and report the fallback under **Verification** — how the verdict was published is an operational outcome, not an assumption.
 
+After publishing, reconcile the verdict label: approve adds `status:auto-approved` and removes `status:changes-requested`; request changes adds `status:changes-requested` and removes `status:auto-approved`.
+
 **Non-blocking follow-ups become a PR, not homework.** After publishing the re-review, if it produced non-blocking findings with concrete mechanical fixes — typos, small hardening, a supplemental test case, doc touch-ups — implement them yourself instead of leaving them as a burden on the author. Supplemental means coverage beyond what the behavior-tested gate required: a test gap that failed that gate is a requested change on the reviewed PR, never follow-up work:
 
 1. Branch from the reviewed PR's current head: `git fetch origin pull/<number>/head && git checkout -b factory/rereview-followups-pr-<number> FETCH_HEAD`.

package/factory-skills/factory-review/SKILL.md

@@ -140,6 +140,8 @@ Next, publish the review on the PR itself — this is part of every pass, not so
 
 If GitHub rejects the review submission (e.g. the token authored the PR and cannot approve or request changes on it), fall back to `gh pr comment <number> --body-file <file>` so the verdict still lands on the PR, and report the fallback under **Verification** — how the verdict was published is an operational outcome, not an assumption.
 
+After publishing, reconcile the verdict label: approve adds `status:auto-approved` and removes `status:changes-requested`; request changes adds `status:changes-requested` and removes `status:auto-approved`.
+
 **Non-blocking follow-ups become a PR, not homework.** After publishing the review, if it produced non-blocking findings with concrete mechanical fixes — typos, small hardening, a supplemental test case, doc touch-ups — implement them yourself instead of leaving them as a burden on the author. Supplemental means coverage beyond what the behavior-tested gate required: a test gap that failed that gate is a requested change on the reviewed PR, never follow-up work:
 
 1. Branch from the reviewed PR's head: `git fetch origin pull/<number>/head && git checkout -b factory/review-followups-pr-<number> FETCH_HEAD`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/factory",
-  "version": "0.14.1-alpha.3",
+  "version": "0.14.1-alpha.4",
   "description": "Mastra Software Factory module: the server core behind the Mastra Software Factory — storage domains, integrations, and surfaces for agent-powered software delivery",
   "type": "module",
   "publishConfig": {
@@ -59,8 +59,8 @@
     "zod": "^4.3.6",
     "@mastra/auth-studio": "1.3.6-alpha.0",
     "@mastra/auth-workos": "1.6.5",
-    "@mastra/code-sdk": "1.7.2-alpha.3",
-    "@mastra/core": "1.67.0-alpha.3",
+    "@mastra/code-sdk": "1.7.2-alpha.4",
+    "@mastra/core": "1.67.0-alpha.4",
     "@mastra/slack": "1.6.3"
   },
   "devDependencies": {
@@ -71,8 +71,8 @@
     "typescript-eslint": "^8.57.0",
     "vitest": "4.1.10",
     "@mastra/libsql": "1.23.0-alpha.2",
-    "@internal/lint": "0.0.132",
     "@mastra/pg": "1.25.0-alpha.1",
+    "@internal/lint": "0.0.132",
     "@internal/types-builder": "0.0.107",
     "@internal/workspace": "0.0.4"
   },