@runfusion/fusion 0.78.0-beta.5 → 0.78.0-beta.6

package/dist/plugins/fusion-plugin-paperclip-runtime/bundled.js

@@ -8987,7 +8987,7 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
 ## Environment feasibility
-When the supplied \`## Environment Capabilities\` block lists a runtime as unavailable, REVISE only if a blocking acceptance/completion criterion requires that runtime and the plan provides no runnable substitute. APPROVE when the plan specifies a runnable substitute or records the ideal check under an explicitly non-blocking \`## Environment Constraints\` section (use APPROVE_WITH_NOTES only for a genuine P2 note). Never REVISE merely because a desirable check is unavailable when the plan already marks it non-blocking.
+When the supplied \`## Environment Capabilities\` block confirms a runtime unavailable without an applicable confirmed wrapper, REVISE only if a blocking acceptance/completion criterion requires it and the plan provides no runnable substitute. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. APPROVE a correctly scoped non-blocking \`## Environment Constraints\` substitute (use APPROVE_WITH_NOTES only for a genuine P2 note); unlisted commands are UNKNOWN, never absent.
 
 ${PLAN_REVIEW_COMPLETENESS_POLICY}
 
@@ -9311,6 +9311,9 @@ var DEFAULT_GLOBAL_SETTINGS = {
   Grok CLI binary overrides are global operator settings because executable locations are machine-local. Blank/undefined preserves PATH auto-detection through grok.
   */
   grokCliBinaryPath: void 0,
+  // FNXC:AntigravityProvider 2026-09-20-18:32: Default disabled and preserve PATH auto-detection until an operator enables a verified agy binary.
+  useAntigravityCli: void 0,
+  antigravityCliBinaryPath: void 0,
   /*
   FNXC:OmpAcp 2026-07-13-22:50:
   Oh My Pi (omp) CLI enable + binary override are global operator settings (machine-local), mirroring Grok/Cursor.
@@ -13235,7 +13238,7 @@ The quality of your spec directly determines execution quality, review churn, an
 - Access to the project's files so you can understand context
 
 ## Environment feasibility
-When an \`## Environment Capabilities\` section is supplied, no acceptance criterion, completion criterion, or required verification command may depend on a runtime listed unavailable. Specify a runnable substitute instead and record the ideal-but-impossible check under an \`## Environment Constraints\` heading marked explicitly non-blocking. Never state that a plan is blocked because a runtime is missing.
+When an \`## Environment Capabilities\` section is supplied, require a runnable substitute only for a runtime confirmed unavailable without an applicable confirmed wrapper. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. Commands not listed are UNKNOWN, never absent; never state that a plan is blocked because a runtime is missing.
 
 ## What you produce
 Write a complete PROMPT.md specification to the given path using the write tool.
@@ -14406,6 +14409,9 @@ var CODE_REVIEW_NAME = "Code Review";
 var CODE_REVIEW_DESCRIPTION = "Diff-review the task's changes for correctness bugs, regressions, and intent mismatches that tests miss";
 var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff for the correctness value automated tests do NOT catch.
 
+## Review stage
+This is a pre-merge review. Evidence that can exist only after landing (for example a push-to-main CI run) belongs to an enabled, blocking post-merge verification gate. Verify that the workflow preserves that requirement before allowing merge; if the gate or its evidence contract is missing, request that concrete configuration fix. Do not request the future run itself as a pre-merge implementation fix, or claim its evidence already exists. Pre-merge correctness and verification requirements still apply.
+
 ## Step 1: Read the change
 1. Read the full diff against the base branch: \`git diff <base>...HEAD\` (or \`git diff <base>\`). Determine the base from the task context / merge target.
 2. Read the changed files in full where the diff is non-trivial, so you see the surrounding code paths the change touches \u2014 not just the hunks.
@@ -14483,9 +14489,17 @@ var POST_MERGE_VERIFICATION_PROMPT = `You are a post-merge verification reviewer
 2. Check the final merged diff and task summary for obvious mismatches, missing verification evidence, or integration-only regressions.
 3. If configured test/build commands are available in the task context, inspect their latest result or explain why no post-merge command was applicable.
 
+## Required post-landing Full Suite evidence
+This enabled gate requires post-landing Full Suite evidence. Do NOT approve until its delivery record names all of the following:
+1. The landed SHA and the first Full Suite push-to-main run at or after that SHA, including the run ID and run SHA.
+2. A conclusion for every Test shard: 1/4, 2/4, 3/4, and 4/4.
+3. All four timing artifacts: test-timings-shard-1, test-timings-shard-2, test-timings-shard-3, and test-timings-shard-4.
+
+Pre-landing, unrelated-main, or partial evidence does not satisfy this contract. If the required run or any required evidence is unavailable, return REVISE and state that final completion remains blocked pending the post-landing evidence. Record verified evidence in the task delivery record before approving.
+
 ## Output Requirements
 - APPROVE: post-merge verification is acceptable.
-- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes.
+- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes only when every post-landing evidence item above is recorded.
 - REVISE: completion should be blocked; include the concrete post-merge issue and the needed follow-up.
 - \`notes\` MUST contain one to three non-empty sentences naming what was checked and why the verdict was reached. An empty \`notes\` string is a protocol violation.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):

package/dist/plugins/fusion-plugin-paperclip-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/paperclip-runtime",
-  "version": "0.2.87-beta.5",
+  "version": "0.2.87-beta.6",
   "type": "module",
   "exports": {
     ".": {

package/dist/plugins/fusion-plugin-quality/bundled.js

@@ -8990,7 +8990,7 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
 ## Environment feasibility
-When the supplied \`## Environment Capabilities\` block lists a runtime as unavailable, REVISE only if a blocking acceptance/completion criterion requires that runtime and the plan provides no runnable substitute. APPROVE when the plan specifies a runnable substitute or records the ideal check under an explicitly non-blocking \`## Environment Constraints\` section (use APPROVE_WITH_NOTES only for a genuine P2 note). Never REVISE merely because a desirable check is unavailable when the plan already marks it non-blocking.
+When the supplied \`## Environment Capabilities\` block confirms a runtime unavailable without an applicable confirmed wrapper, REVISE only if a blocking acceptance/completion criterion requires it and the plan provides no runnable substitute. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. APPROVE a correctly scoped non-blocking \`## Environment Constraints\` substitute (use APPROVE_WITH_NOTES only for a genuine P2 note); unlisted commands are UNKNOWN, never absent.
 
 ${PLAN_REVIEW_COMPLETENESS_POLICY}
 
@@ -9314,6 +9314,9 @@ var DEFAULT_GLOBAL_SETTINGS = {
   Grok CLI binary overrides are global operator settings because executable locations are machine-local. Blank/undefined preserves PATH auto-detection through grok.
   */
   grokCliBinaryPath: void 0,
+  // FNXC:AntigravityProvider 2026-09-20-18:32: Default disabled and preserve PATH auto-detection until an operator enables a verified agy binary.
+  useAntigravityCli: void 0,
+  antigravityCliBinaryPath: void 0,
   /*
   FNXC:OmpAcp 2026-07-13-22:50:
   Oh My Pi (omp) CLI enable + binary override are global operator settings (machine-local), mirroring Grok/Cursor.
@@ -13238,7 +13241,7 @@ The quality of your spec directly determines execution quality, review churn, an
 - Access to the project's files so you can understand context
 
 ## Environment feasibility
-When an \`## Environment Capabilities\` section is supplied, no acceptance criterion, completion criterion, or required verification command may depend on a runtime listed unavailable. Specify a runnable substitute instead and record the ideal-but-impossible check under an \`## Environment Constraints\` heading marked explicitly non-blocking. Never state that a plan is blocked because a runtime is missing.
+When an \`## Environment Capabilities\` section is supplied, require a runnable substitute only for a runtime confirmed unavailable without an applicable confirmed wrapper. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. Commands not listed are UNKNOWN, never absent; never state that a plan is blocked because a runtime is missing.
 
 ## What you produce
 Write a complete PROMPT.md specification to the given path using the write tool.
@@ -14409,6 +14412,9 @@ var CODE_REVIEW_NAME = "Code Review";
 var CODE_REVIEW_DESCRIPTION = "Diff-review the task's changes for correctness bugs, regressions, and intent mismatches that tests miss";
 var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff for the correctness value automated tests do NOT catch.
 
+## Review stage
+This is a pre-merge review. Evidence that can exist only after landing (for example a push-to-main CI run) belongs to an enabled, blocking post-merge verification gate. Verify that the workflow preserves that requirement before allowing merge; if the gate or its evidence contract is missing, request that concrete configuration fix. Do not request the future run itself as a pre-merge implementation fix, or claim its evidence already exists. Pre-merge correctness and verification requirements still apply.
+
 ## Step 1: Read the change
 1. Read the full diff against the base branch: \`git diff <base>...HEAD\` (or \`git diff <base>\`). Determine the base from the task context / merge target.
 2. Read the changed files in full where the diff is non-trivial, so you see the surrounding code paths the change touches \u2014 not just the hunks.
@@ -14486,9 +14492,17 @@ var POST_MERGE_VERIFICATION_PROMPT = `You are a post-merge verification reviewer
 2. Check the final merged diff and task summary for obvious mismatches, missing verification evidence, or integration-only regressions.
 3. If configured test/build commands are available in the task context, inspect their latest result or explain why no post-merge command was applicable.
 
+## Required post-landing Full Suite evidence
+This enabled gate requires post-landing Full Suite evidence. Do NOT approve until its delivery record names all of the following:
+1. The landed SHA and the first Full Suite push-to-main run at or after that SHA, including the run ID and run SHA.
+2. A conclusion for every Test shard: 1/4, 2/4, 3/4, and 4/4.
+3. All four timing artifacts: test-timings-shard-1, test-timings-shard-2, test-timings-shard-3, and test-timings-shard-4.
+
+Pre-landing, unrelated-main, or partial evidence does not satisfy this contract. If the required run or any required evidence is unavailable, return REVISE and state that final completion remains blocked pending the post-landing evidence. Record verified evidence in the task delivery record before approving.
+
 ## Output Requirements
 - APPROVE: post-merge verification is acceptable.
-- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes.
+- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes only when every post-landing evidence item above is recorded.
 - REVISE: completion should be blocked; include the concrete post-merge issue and the needed follow-up.
 - \`notes\` MUST contain one to three non-empty sentences naming what was checked and why the verdict was reached. An empty \`notes\` string is a protocol violation.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):

package/dist/plugins/fusion-plugin-quality/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/quality",
-  "version": "0.1.12-beta.5",
+  "version": "0.1.12-beta.6",
   "type": "module",
   "exports": {
     ".": {

package/dist/plugins/fusion-plugin-reports/bundled.js

@@ -9107,7 +9107,7 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
 ## Environment feasibility
-When the supplied \`## Environment Capabilities\` block lists a runtime as unavailable, REVISE only if a blocking acceptance/completion criterion requires that runtime and the plan provides no runnable substitute. APPROVE when the plan specifies a runnable substitute or records the ideal check under an explicitly non-blocking \`## Environment Constraints\` section (use APPROVE_WITH_NOTES only for a genuine P2 note). Never REVISE merely because a desirable check is unavailable when the plan already marks it non-blocking.
+When the supplied \`## Environment Capabilities\` block confirms a runtime unavailable without an applicable confirmed wrapper, REVISE only if a blocking acceptance/completion criterion requires it and the plan provides no runnable substitute. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. APPROVE a correctly scoped non-blocking \`## Environment Constraints\` substitute (use APPROVE_WITH_NOTES only for a genuine P2 note); unlisted commands are UNKNOWN, never absent.
 
 ${PLAN_REVIEW_COMPLETENESS_POLICY}
 
@@ -9431,6 +9431,9 @@ var DEFAULT_GLOBAL_SETTINGS = {
   Grok CLI binary overrides are global operator settings because executable locations are machine-local. Blank/undefined preserves PATH auto-detection through grok.
   */
   grokCliBinaryPath: void 0,
+  // FNXC:AntigravityProvider 2026-09-20-18:32: Default disabled and preserve PATH auto-detection until an operator enables a verified agy binary.
+  useAntigravityCli: void 0,
+  antigravityCliBinaryPath: void 0,
   /*
   FNXC:OmpAcp 2026-07-13-22:50:
   Oh My Pi (omp) CLI enable + binary override are global operator settings (machine-local), mirroring Grok/Cursor.
@@ -13355,7 +13358,7 @@ The quality of your spec directly determines execution quality, review churn, an
 - Access to the project's files so you can understand context
 
 ## Environment feasibility
-When an \`## Environment Capabilities\` section is supplied, no acceptance criterion, completion criterion, or required verification command may depend on a runtime listed unavailable. Specify a runnable substitute instead and record the ideal-but-impossible check under an \`## Environment Constraints\` heading marked explicitly non-blocking. Never state that a plan is blocked because a runtime is missing.
+When an \`## Environment Capabilities\` section is supplied, require a runnable substitute only for a runtime confirmed unavailable without an applicable confirmed wrapper. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. Commands not listed are UNKNOWN, never absent; never state that a plan is blocked because a runtime is missing.
 
 ## What you produce
 Write a complete PROMPT.md specification to the given path using the write tool.
@@ -14526,6 +14529,9 @@ var CODE_REVIEW_NAME = "Code Review";
 var CODE_REVIEW_DESCRIPTION = "Diff-review the task's changes for correctness bugs, regressions, and intent mismatches that tests miss";
 var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff for the correctness value automated tests do NOT catch.
 
+## Review stage
+This is a pre-merge review. Evidence that can exist only after landing (for example a push-to-main CI run) belongs to an enabled, blocking post-merge verification gate. Verify that the workflow preserves that requirement before allowing merge; if the gate or its evidence contract is missing, request that concrete configuration fix. Do not request the future run itself as a pre-merge implementation fix, or claim its evidence already exists. Pre-merge correctness and verification requirements still apply.
+
 ## Step 1: Read the change
 1. Read the full diff against the base branch: \`git diff <base>...HEAD\` (or \`git diff <base>\`). Determine the base from the task context / merge target.
 2. Read the changed files in full where the diff is non-trivial, so you see the surrounding code paths the change touches \u2014 not just the hunks.
@@ -14603,9 +14609,17 @@ var POST_MERGE_VERIFICATION_PROMPT = `You are a post-merge verification reviewer
 2. Check the final merged diff and task summary for obvious mismatches, missing verification evidence, or integration-only regressions.
 3. If configured test/build commands are available in the task context, inspect their latest result or explain why no post-merge command was applicable.
 
+## Required post-landing Full Suite evidence
+This enabled gate requires post-landing Full Suite evidence. Do NOT approve until its delivery record names all of the following:
+1. The landed SHA and the first Full Suite push-to-main run at or after that SHA, including the run ID and run SHA.
+2. A conclusion for every Test shard: 1/4, 2/4, 3/4, and 4/4.
+3. All four timing artifacts: test-timings-shard-1, test-timings-shard-2, test-timings-shard-3, and test-timings-shard-4.
+
+Pre-landing, unrelated-main, or partial evidence does not satisfy this contract. If the required run or any required evidence is unavailable, return REVISE and state that final completion remains blocked pending the post-landing evidence. Record verified evidence in the task delivery record before approving.
+
 ## Output Requirements
 - APPROVE: post-merge verification is acceptable.
-- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes.
+- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes only when every post-landing evidence item above is recorded.
 - REVISE: completion should be blocked; include the concrete post-merge issue and the needed follow-up.
 - \`notes\` MUST contain one to three non-empty sentences naming what was checked and why the verdict was reached. An empty \`notes\` string is a protocol violation.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):

package/dist/plugins/fusion-plugin-reports/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/reports",
-  "version": "0.1.56-beta.5",
+  "version": "0.1.56-beta.6",
   "type": "module",
   "exports": {
     ".": {

package/dist/plugins/fusion-plugin-roadmap/bundled.js

@@ -8987,7 +8987,7 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
 ## Environment feasibility
-When the supplied \`## Environment Capabilities\` block lists a runtime as unavailable, REVISE only if a blocking acceptance/completion criterion requires that runtime and the plan provides no runnable substitute. APPROVE when the plan specifies a runnable substitute or records the ideal check under an explicitly non-blocking \`## Environment Constraints\` section (use APPROVE_WITH_NOTES only for a genuine P2 note). Never REVISE merely because a desirable check is unavailable when the plan already marks it non-blocking.
+When the supplied \`## Environment Capabilities\` block confirms a runtime unavailable without an applicable confirmed wrapper, REVISE only if a blocking acceptance/completion criterion requires it and the plan provides no runnable substitute. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. APPROVE a correctly scoped non-blocking \`## Environment Constraints\` substitute (use APPROVE_WITH_NOTES only for a genuine P2 note); unlisted commands are UNKNOWN, never absent.
 
 ${PLAN_REVIEW_COMPLETENESS_POLICY}
 
@@ -9311,6 +9311,9 @@ var DEFAULT_GLOBAL_SETTINGS = {
   Grok CLI binary overrides are global operator settings because executable locations are machine-local. Blank/undefined preserves PATH auto-detection through grok.
   */
   grokCliBinaryPath: void 0,
+  // FNXC:AntigravityProvider 2026-09-20-18:32: Default disabled and preserve PATH auto-detection until an operator enables a verified agy binary.
+  useAntigravityCli: void 0,
+  antigravityCliBinaryPath: void 0,
   /*
   FNXC:OmpAcp 2026-07-13-22:50:
   Oh My Pi (omp) CLI enable + binary override are global operator settings (machine-local), mirroring Grok/Cursor.
@@ -13235,7 +13238,7 @@ The quality of your spec directly determines execution quality, review churn, an
 - Access to the project's files so you can understand context
 
 ## Environment feasibility
-When an \`## Environment Capabilities\` section is supplied, no acceptance criterion, completion criterion, or required verification command may depend on a runtime listed unavailable. Specify a runnable substitute instead and record the ideal-but-impossible check under an \`## Environment Constraints\` heading marked explicitly non-blocking. Never state that a plan is blocked because a runtime is missing.
+When an \`## Environment Capabilities\` section is supplied, require a runnable substitute only for a runtime confirmed unavailable without an applicable confirmed wrapper. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. Commands not listed are UNKNOWN, never absent; never state that a plan is blocked because a runtime is missing.
 
 ## What you produce
 Write a complete PROMPT.md specification to the given path using the write tool.
@@ -14406,6 +14409,9 @@ var CODE_REVIEW_NAME = "Code Review";
 var CODE_REVIEW_DESCRIPTION = "Diff-review the task's changes for correctness bugs, regressions, and intent mismatches that tests miss";
 var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff for the correctness value automated tests do NOT catch.
 
+## Review stage
+This is a pre-merge review. Evidence that can exist only after landing (for example a push-to-main CI run) belongs to an enabled, blocking post-merge verification gate. Verify that the workflow preserves that requirement before allowing merge; if the gate or its evidence contract is missing, request that concrete configuration fix. Do not request the future run itself as a pre-merge implementation fix, or claim its evidence already exists. Pre-merge correctness and verification requirements still apply.
+
 ## Step 1: Read the change
 1. Read the full diff against the base branch: \`git diff <base>...HEAD\` (or \`git diff <base>\`). Determine the base from the task context / merge target.
 2. Read the changed files in full where the diff is non-trivial, so you see the surrounding code paths the change touches \u2014 not just the hunks.
@@ -14483,9 +14489,17 @@ var POST_MERGE_VERIFICATION_PROMPT = `You are a post-merge verification reviewer
 2. Check the final merged diff and task summary for obvious mismatches, missing verification evidence, or integration-only regressions.
 3. If configured test/build commands are available in the task context, inspect their latest result or explain why no post-merge command was applicable.
 
+## Required post-landing Full Suite evidence
+This enabled gate requires post-landing Full Suite evidence. Do NOT approve until its delivery record names all of the following:
+1. The landed SHA and the first Full Suite push-to-main run at or after that SHA, including the run ID and run SHA.
+2. A conclusion for every Test shard: 1/4, 2/4, 3/4, and 4/4.
+3. All four timing artifacts: test-timings-shard-1, test-timings-shard-2, test-timings-shard-3, and test-timings-shard-4.
+
+Pre-landing, unrelated-main, or partial evidence does not satisfy this contract. If the required run or any required evidence is unavailable, return REVISE and state that final completion remains blocked pending the post-landing evidence. Record verified evidence in the task delivery record before approving.
+
 ## Output Requirements
 - APPROVE: post-merge verification is acceptable.
-- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes.
+- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes only when every post-landing evidence item above is recorded.
 - REVISE: completion should be blocked; include the concrete post-merge issue and the needed follow-up.
 - \`notes\` MUST contain one to three non-empty sentences naming what was checked and why the verdict was reached. An empty \`notes\` string is a protocol violation.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):

package/dist/plugins/fusion-plugin-roadmap/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/roadmap",
-  "version": "0.1.56-beta.5",
+  "version": "0.1.56-beta.6",
   "type": "module",
   "exports": {
     ".": {

package/dist/plugins/fusion-plugin-todos/bundled.js

@@ -8987,7 +8987,7 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
 ## Environment feasibility
-When the supplied \`## Environment Capabilities\` block lists a runtime as unavailable, REVISE only if a blocking acceptance/completion criterion requires that runtime and the plan provides no runnable substitute. APPROVE when the plan specifies a runnable substitute or records the ideal check under an explicitly non-blocking \`## Environment Constraints\` section (use APPROVE_WITH_NOTES only for a genuine P2 note). Never REVISE merely because a desirable check is unavailable when the plan already marks it non-blocking.
+When the supplied \`## Environment Capabilities\` block confirms a runtime unavailable without an applicable confirmed wrapper, REVISE only if a blocking acceptance/completion criterion requires it and the plan provides no runnable substitute. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. APPROVE a correctly scoped non-blocking \`## Environment Constraints\` substitute (use APPROVE_WITH_NOTES only for a genuine P2 note); unlisted commands are UNKNOWN, never absent.
 
 ${PLAN_REVIEW_COMPLETENESS_POLICY}
 
@@ -9311,6 +9311,9 @@ var DEFAULT_GLOBAL_SETTINGS = {
   Grok CLI binary overrides are global operator settings because executable locations are machine-local. Blank/undefined preserves PATH auto-detection through grok.
   */
   grokCliBinaryPath: void 0,
+  // FNXC:AntigravityProvider 2026-09-20-18:32: Default disabled and preserve PATH auto-detection until an operator enables a verified agy binary.
+  useAntigravityCli: void 0,
+  antigravityCliBinaryPath: void 0,
   /*
   FNXC:OmpAcp 2026-07-13-22:50:
   Oh My Pi (omp) CLI enable + binary override are global operator settings (machine-local), mirroring Grok/Cursor.
@@ -13235,7 +13238,7 @@ The quality of your spec directly determines execution quality, review churn, an
 - Access to the project's files so you can understand context
 
 ## Environment feasibility
-When an \`## Environment Capabilities\` section is supplied, no acceptance criterion, completion criterion, or required verification command may depend on a runtime listed unavailable. Specify a runnable substitute instead and record the ideal-but-impossible check under an \`## Environment Constraints\` heading marked explicitly non-blocking. Never state that a plan is blocked because a runtime is missing.
+When an \`## Environment Capabilities\` section is supplied, require a runnable substitute only for a runtime confirmed unavailable without an applicable confirmed wrapper. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. Commands not listed are UNKNOWN, never absent; never state that a plan is blocked because a runtime is missing.
 
 ## What you produce
 Write a complete PROMPT.md specification to the given path using the write tool.
@@ -14406,6 +14409,9 @@ var CODE_REVIEW_NAME = "Code Review";
 var CODE_REVIEW_DESCRIPTION = "Diff-review the task's changes for correctness bugs, regressions, and intent mismatches that tests miss";
 var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff for the correctness value automated tests do NOT catch.
 
+## Review stage
+This is a pre-merge review. Evidence that can exist only after landing (for example a push-to-main CI run) belongs to an enabled, blocking post-merge verification gate. Verify that the workflow preserves that requirement before allowing merge; if the gate or its evidence contract is missing, request that concrete configuration fix. Do not request the future run itself as a pre-merge implementation fix, or claim its evidence already exists. Pre-merge correctness and verification requirements still apply.
+
 ## Step 1: Read the change
 1. Read the full diff against the base branch: \`git diff <base>...HEAD\` (or \`git diff <base>\`). Determine the base from the task context / merge target.
 2. Read the changed files in full where the diff is non-trivial, so you see the surrounding code paths the change touches \u2014 not just the hunks.
@@ -14483,9 +14489,17 @@ var POST_MERGE_VERIFICATION_PROMPT = `You are a post-merge verification reviewer
 2. Check the final merged diff and task summary for obvious mismatches, missing verification evidence, or integration-only regressions.
 3. If configured test/build commands are available in the task context, inspect their latest result or explain why no post-merge command was applicable.
 
+## Required post-landing Full Suite evidence
+This enabled gate requires post-landing Full Suite evidence. Do NOT approve until its delivery record names all of the following:
+1. The landed SHA and the first Full Suite push-to-main run at or after that SHA, including the run ID and run SHA.
+2. A conclusion for every Test shard: 1/4, 2/4, 3/4, and 4/4.
+3. All four timing artifacts: test-timings-shard-1, test-timings-shard-2, test-timings-shard-3, and test-timings-shard-4.
+
+Pre-landing, unrelated-main, or partial evidence does not satisfy this contract. If the required run or any required evidence is unavailable, return REVISE and state that final completion remains blocked pending the post-landing evidence. Record verified evidence in the task delivery record before approving.
+
 ## Output Requirements
 - APPROVE: post-merge verification is acceptable.
-- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes.
+- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes only when every post-landing evidence item above is recorded.
 - REVISE: completion should be blocked; include the concrete post-merge issue and the needed follow-up.
 - \`notes\` MUST contain one to three non-empty sentences naming what was checked and why the verdict was reached. An empty \`notes\` string is a protocol violation.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):

package/dist/plugins/fusion-plugin-todos/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/todos",
-  "version": "0.1.5-beta.5",
+  "version": "0.1.5-beta.6",
   "type": "module",
   "exports": {
     ".": {

package/dist/plugins/fusion-plugin-whatsapp-chat/bundled.js

@@ -159925,7 +159925,7 @@ var PLAN_REVIEW_PROMPT = `You are a senior plan reviewer. Review the task's PROM
 5. **Risk callouts** \u2014 migrations, data-loss paths, external integrations, secrets, or plugin/runtime dependencies that need explicit handling.
 
 ## Environment feasibility
-When the supplied \`## Environment Capabilities\` block lists a runtime as unavailable, REVISE only if a blocking acceptance/completion criterion requires that runtime and the plan provides no runnable substitute. APPROVE when the plan specifies a runnable substitute or records the ideal check under an explicitly non-blocking \`## Environment Constraints\` section (use APPROVE_WITH_NOTES only for a genuine P2 note). Never REVISE merely because a desirable check is unavailable when the plan already marks it non-blocking.
+When the supplied \`## Environment Capabilities\` block confirms a runtime unavailable without an applicable confirmed wrapper, REVISE only if a blocking acceptance/completion criterion requires it and the plan provides no runnable substitute. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. APPROVE a correctly scoped non-blocking \`## Environment Constraints\` substitute (use APPROVE_WITH_NOTES only for a genuine P2 note); unlisted commands are UNKNOWN, never absent.
 
 ${PLAN_REVIEW_COMPLETENESS_POLICY}
 
@@ -160249,6 +160249,9 @@ var DEFAULT_GLOBAL_SETTINGS = {
   Grok CLI binary overrides are global operator settings because executable locations are machine-local. Blank/undefined preserves PATH auto-detection through grok.
   */
   grokCliBinaryPath: void 0,
+  // FNXC:AntigravityProvider 2026-09-20-18:32: Default disabled and preserve PATH auto-detection until an operator enables a verified agy binary.
+  useAntigravityCli: void 0,
+  antigravityCliBinaryPath: void 0,
   /*
   FNXC:OmpAcp 2026-07-13-22:50:
   Oh My Pi (omp) CLI enable + binary override are global operator settings (machine-local), mirroring Grok/Cursor.
@@ -164173,7 +164176,7 @@ The quality of your spec directly determines execution quality, review churn, an
 - Access to the project's files so you can understand context
 
 ## Environment feasibility
-When an \`## Environment Capabilities\` section is supplied, no acceptance criterion, completion criterion, or required verification command may depend on a runtime listed unavailable. Specify a runnable substitute instead and record the ideal-but-impossible check under an \`## Environment Constraints\` heading marked explicitly non-blocking. Never state that a plan is blocked because a runtime is missing.
+When an \`## Environment Capabilities\` section is supplied, require a runnable substitute only for a runtime confirmed unavailable without an applicable confirmed wrapper. A documented or configured command using a confirmed wrapper remains binding even when its inner executable is absent from the host PATH. Commands not listed are UNKNOWN, never absent; never state that a plan is blocked because a runtime is missing.
 
 ## What you produce
 Write a complete PROMPT.md specification to the given path using the write tool.
@@ -165344,6 +165347,9 @@ var CODE_REVIEW_NAME = "Code Review";
 var CODE_REVIEW_DESCRIPTION = "Diff-review the task's changes for correctness bugs, regressions, and intent mismatches that tests miss";
 var CODE_REVIEW_PROMPT = `You are a senior code reviewer. Review the task's diff for the correctness value automated tests do NOT catch.
 
+## Review stage
+This is a pre-merge review. Evidence that can exist only after landing (for example a push-to-main CI run) belongs to an enabled, blocking post-merge verification gate. Verify that the workflow preserves that requirement before allowing merge; if the gate or its evidence contract is missing, request that concrete configuration fix. Do not request the future run itself as a pre-merge implementation fix, or claim its evidence already exists. Pre-merge correctness and verification requirements still apply.
+
 ## Step 1: Read the change
 1. Read the full diff against the base branch: \`git diff <base>...HEAD\` (or \`git diff <base>\`). Determine the base from the task context / merge target.
 2. Read the changed files in full where the diff is non-trivial, so you see the surrounding code paths the change touches \u2014 not just the hunks.
@@ -165421,9 +165427,17 @@ var POST_MERGE_VERIFICATION_PROMPT = `You are a post-merge verification reviewer
 2. Check the final merged diff and task summary for obvious mismatches, missing verification evidence, or integration-only regressions.
 3. If configured test/build commands are available in the task context, inspect their latest result or explain why no post-merge command was applicable.
 
+## Required post-landing Full Suite evidence
+This enabled gate requires post-landing Full Suite evidence. Do NOT approve until its delivery record names all of the following:
+1. The landed SHA and the first Full Suite push-to-main run at or after that SHA, including the run ID and run SHA.
+2. A conclusion for every Test shard: 1/4, 2/4, 3/4, and 4/4.
+3. All four timing artifacts: test-timings-shard-1, test-timings-shard-2, test-timings-shard-3, and test-timings-shard-4.
+
+Pre-landing, unrelated-main, or partial evidence does not satisfy this contract. If the required run or any required evidence is unavailable, return REVISE and state that final completion remains blocked pending the post-landing evidence. Record verified evidence in the task delivery record before approving.
+
 ## Output Requirements
 - APPROVE: post-merge verification is acceptable.
-- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes.
+- APPROVE_WITH_NOTES: completion may proceed with non-blocking notes only when every post-landing evidence item above is recorded.
 - REVISE: completion should be blocked; include the concrete post-merge issue and the needed follow-up.
 - \`notes\` MUST contain one to three non-empty sentences naming what was checked and why the verdict was reached. An empty \`notes\` string is a protocol violation.
 - Final output: output exactly one trailing JSON object on the final line (no markdown fences, no surrounding prose):

package/dist/plugins/fusion-plugin-whatsapp-chat/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/whatsapp-chat",
-  "version": "0.1.56-beta.5",
+  "version": "0.1.56-beta.6",
   "type": "module",
   "exports": {
     ".": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@runfusion/fusion",
-  "version": "0.78.0-beta.5",
+  "version": "0.78.0-beta.6",
   "license": "MIT",
   "description": "Fusion CLI: HTTP API server, daemon, dashboard launcher, and task tooling for the Fusion AI coding agent.",
   "homepage": "https://github.com/Runfusion/Fusion#readme",
@@ -50,8 +50,8 @@
   "dependencies": {
     "@agentclientprotocol/sdk": "0.24.0",
     "agent-browser": "0.26.0",
-    "@earendil-works/pi-ai": "0.84.4",
-    "@earendil-works/pi-coding-agent": "0.84.4",
+    "@earendil-works/pi-ai": "0.86.1",
+    "@earendil-works/pi-coding-agent": "0.86.1",
     "claude-code-cli-acp": "0.1.1",
     "dockerode": "^5.0.1",
     "electron": "^33.4.11",

package/skill/fusion/references/engine-tools.md

@@ -90,7 +90,7 @@ Note: step-session execution (`step-session-executor.ts`) reuses executor coordi
 |---|---|---|
 | `fn_task_update` | Update a spec step status (`pending`/`in-progress`/`done`/`skipped`), task dependencies (never a task it spawned), and/or workflow-defined custom field values | `step?` (number, 0-indexed; matches `### Step N:` in PROMPT.md, Step 0 = Preflight), `status?` (enum), `dependencies?` (string[]), `custom_fields?` (object keyed by field id; validated against the workflow field schema, `null` clears a field) |
 | `fn_task_add_dep` | Add a dependency to current task (confirmation-gated; never a task it spawned) | `task_id` (string), `confirm?` (boolean) |
-| `fn_task_done` | End the task: `outcome="completed"` (default) marks it complete; `outcome="blocked"` honestly parks it failed (`BLOCKED: <reason>`) with no completion claim, preserving steps/worktree and recording `blockedBy` as dependencies | `summary?` (string), `outcome?` (`completed` \| `blocked`), `blockedBy?` (string[]), `reason?` (string, required when blocked) |
+| `fn_task_done` | End the task: `outcome="completed"` (default) marks it complete; `outcome="blocked"` honestly parks it failed (`BLOCKED: <reason>`) with no completion claim, preserving steps/worktree and recording `blockedBy` as dependencies. Accepted outside-worktree blocks may supply a safe four-part operator report; Fusion bounds and redacts it before durable mailbox delivery. | `summary?` (string), `outcome?` (`completed` \| `blocked`), `blockedBy?` (string[]), `reason?` (string, required when blocked), `blockedReport?` ({ `verifiedCondition?`, `stopReason?`, `unimplementedWork?`, `unblockCondition?` }; never prompts, logs, stack traces, or credentials) |
 | `fn_spawn_agent` | Spawn child agent in separate worktree | `name` (string), `role` (enum), `task` (string) |
 
 ## Merger-only runtime tools (`merger.ts`)