@mastra/factory 0.2.2-alpha.0 → 0.2.2-alpha.1

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

@@ -1,11 +1,11 @@
 ---
 name: factory-review
-description: Review a pull request for a Factory work item — history and context first, then verdict — and mark the review complete
+description: Review a pull request for a Factory work item — history and context first, then a verdict published on the PR — and mark the review complete
 ---
 
 # Factory Review
 
-Review the pull request behind this Factory work item — build its history and context first, then judge correctness, tests, scope, and pattern-consistency — and finish by posting a verdict handoff and requesting the stage transition.
+Review the pull request behind this Factory work item — build its history and context first, then judge correctness, tests, scope, and pattern-consistency — and finish by publishing the verdict on the PR, posting a verdict handoff, and requesting the stage transition.
 
 You are working in a bound Factory session. Complete the full review in one pass, then make `factory_transition_work_item` your terminal step — one transition request, repeated only if the governed transition rejects it and only with the rejection reason addressed. Never wait for or solicit human input mid-run; every judgment call is yours to resolve.
 
@@ -58,6 +58,13 @@ First, post the **review handoff** as your final message in the conversation. It
 - **Assumptions** — every recorded judgment call from the run.
 - **Open questions** — any decision that genuinely needs a human.
 
+Next, publish the review on the PR itself — this is part of every pass, not something to wait to be asked for. Write the handoff body to a temp file (avoids shell-quoting breakage) and submit a PR review matching the verdict:
+
+- approve → `gh pr review <number> --approve --body-file <file>`
+- request changes → `gh pr review <number> --request-changes --body-file <file>`
+
+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 record the fallback as an assumption.
+
 Then make your terminal `factory_transition_work_item` call. Take the current stage and `expectedRevision` from the `factory-phase` signal. Request `stage: "done"` (review board) **for both verdicts** — the transition marks the review pass complete; what to do about requested changes is the human's call from the handoff.
 
 `rationale` (max 1000 chars) — one or two sentences: review complete, verdict, and the headline reason.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/factory",
-  "version": "0.2.2-alpha.0",
+  "version": "0.2.2-alpha.1",
   "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": {
@@ -50,10 +50,10 @@
     "@octokit/rest": "^22.0.1",
     "hono": "^4.12.8",
     "zod": "^4.3.6",
-    "@mastra/auth-studio": "1.3.2",
-    "@mastra/core": "1.54.0-alpha.0",
-    "@mastra/code-sdk": "1.0.3-alpha.0",
-    "@mastra/auth-workos": "1.6.4"
+    "@mastra/auth-studio": "1.3.3-alpha.0",
+    "@mastra/auth-workos": "1.6.4",
+    "@mastra/code-sdk": "1.0.3-alpha.1",
+    "@mastra/core": "1.54.0-alpha.1"
   },
   "devDependencies": {
     "@types/node": "22.20.1",
@@ -63,9 +63,9 @@
     "typescript-eslint": "^8.57.0",
     "vitest": "4.1.10",
     "@internal/lint": "0.0.117",
-    "@mastra/pg": "1.18.0-alpha.0",
-    "@internal/types-builder": "0.0.92",
-    "@mastra/libsql": "1.18.0-alpha.0"
+    "@mastra/libsql": "1.18.0-alpha.0",
+    "@mastra/pg": "1.18.0-alpha.1",
+    "@internal/types-builder": "0.0.92"
   },
   "engines": {
     "node": ">=22.19.0"