@runfusion/fusion 0.77.0-beta.4 → 0.77.0-beta.6

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

@@ -5835,6 +5835,7 @@ var tasks = projectSchema.table("tasks", {
   mergerModelId: text("merger_model_id"),
   mergerThinkingLevel: text("merger_thinking_level"),
   mergeRetries: integer("merge_retries"),
+  aiMergeReviewReconciliation: text("ai_merge_review_reconciliation"),
   workflowStepRetries: integer("workflow_step_retries"),
   resumeLimboCount: integer("resume_limbo_count").default(0),
   graphResumeRetryCount: integer("graph_resume_retry_count").default(0),
@@ -5957,7 +5958,8 @@ var tasks = projectSchema.table("tasks", {
   sourceIssueClosedAt: text("source_issue_closed_at"),
   mergeDetails: jsonb("merge_details"),
   workspaceWorktrees: jsonb("workspace_worktrees"),
-  breakIntoSubtasks: integer("break_into_subtasks").default(0),
+  // FNXC:RepositoryScope 2026-08-20-23:07: explicit task intent must survive PostgreSQL reads independently of acquired worktrees.
+  repositoryScope: jsonb("repository_scope"),
   noCommitsExpected: integer("no_commits_expected").default(0),
   enabledWorkflowSteps: jsonb("enabled_workflow_steps").default([]),
   modifiedFiles: jsonb("modified_files").default([]),
@@ -8277,7 +8279,8 @@ var centralActivityLog = centralSchema.table("central_activity_log", {
   foreignKey({ columns: [t.projectId], foreignColumns: [projects.id] }).onDelete("cascade"),
   index("idxActivityLogTimestamp").on(t.timestamp),
   index("idxActivityLogType").on(t.type),
-  index("idxActivityLogProjectId").on(t.projectId)
+  index("idxActivityLogProjectId").on(t.projectId),
+  index("idxCentralActivityLogTaskIdTimestamp").on(t.taskId, t.timestamp)
 ]);
 var centralSettings = centralSchema.table("central_settings", {
   id: integer("id").primaryKey(),
@@ -8985,6 +8988,15 @@ var DEFAULT_GLOBAL_SETTINGS = {
   opt in before Fusion replaces its own binary and bounces the process under them.
   */
   autoUpdateAndRestart: false,
+  /*
+  FNXC:UpdateAutomation 2026-08-21-02:17:
+  Fresh installations require separate opt-ins for unattended installation and
+  restart. The legacy combined switch remains false and is only a fallback for
+  older persisted settings.
+  */
+  /* FNXC:UpdateAutomation 2026-08-21-02:48: Keep these schema keys unset because defaults merge into effective settings and `undefined` is distinct from explicit false. */
+  autoUpdateEnabled: void 0,
+  autoRestartAfterUpdate: void 0,
   autoReloadOnVersionChange: true,
   githubTrackingDefaultRepo: void 0,
   reportRoadmapDedupeEnabled: void 0,
@@ -8995,6 +9007,13 @@ var DEFAULT_GLOBAL_SETTINGS = {
   gitlabApiBaseUrl: void 0,
   gitlabAuthToken: void 0,
   gitlabAuthTokenType: void 0,
+  jiraEnabled: void 0,
+  jiraBaseUrl: void 0,
+  jiraApiBaseUrl: void 0,
+  jiraAuthEmail: void 0,
+  jiraAuthTokenSecretKey: void 0,
+  jiraAuthTokenSecretScope: void 0,
+  jiraBranchNameTemplate: void 0,
   modelOnboardingComplete: void 0,
   useClaudeCli: void 0,
   useDroidCli: void 0,
@@ -9485,6 +9504,13 @@ var DEFAULT_PROJECT_SETTINGS = {
   gitlabApiBaseUrl: void 0,
   gitlabAuthToken: void 0,
   gitlabAuthTokenType: void 0,
+  jiraEnabled: void 0,
+  jiraBaseUrl: void 0,
+  jiraApiBaseUrl: void 0,
+  jiraAuthEmail: void 0,
+  jiraAuthTokenSecretKey: void 0,
+  jiraAuthTokenSecretScope: void 0,
+  jiraBranchNameTemplate: void 0,
   gitlabCommentOnDone: false,
   gitlabCommentTemplate: void 0,
   gitlabCloseSourceIssueOnDone: false,
@@ -12289,17 +12315,6 @@ var BUILTIN_MOVED_WORKFLOW_SETTINGS = [
   }
 ];
 var BUILTIN_TRIAGE_POLICY_SETTINGS = [
-  {
-    id: "triageProactiveSubtaskSplittingEnabled",
-    name: "Triage proactive subtask splitting",
-    type: "boolean",
-    default: true,
-    /*
-     * FNXC:TriagePolicy 2026-07-04-00:00:
-     * Operators need a workflow/project policy switch that disables automatic large-task splitting without weakening explicit `breakIntoSubtasks: true` requests. Keep the default enabled to preserve existing triage behavior for workflows that have no stored override.
-     */
-    description: "Enable automatic large-task splitting guidance during triage. Turn off to split only when breakIntoSubtasks is explicitly requested."
-  },
   {
     id: "triageSizeSmallMaxHours",
     name: "Triage size S max hours",
@@ -12321,48 +12336,6 @@ var BUILTIN_TRIAGE_POLICY_SETTINGS = [
     default: 8,
     description: "Upper hour boundary for Size L triage guidance; larger work should split as XL."
   },
-  {
-    id: "triageSubtaskStepThreshold",
-    name: "Triage subtask step threshold",
-    type: "number",
-    default: 7,
-    description: "Implementation-step count above which triage should consider splitting an M/L task."
-  },
-  {
-    id: "triageSubtaskLargeStepSignal",
-    name: "Triage large-step signal",
-    type: "number",
-    default: 9,
-    description: "Planned step count that is a broad-scope decomposition signal for Size L tasks."
-  },
-  {
-    id: "triageSubtaskAdditiveStepSignal",
-    name: "Triage additive step signal",
-    type: "number",
-    default: 12,
-    description: "Implementation-step count that independently signals possible partitioning."
-  },
-  {
-    id: "triageSubtaskPackageThreshold",
-    name: "Triage package/module threshold",
-    type: "number",
-    default: 3,
-    description: "Distinct package/module count above which triage should consider splitting coherent M/L work."
-  },
-  {
-    id: "triageSubtaskFileScopeThreshold",
-    name: "Triage file-scope threshold",
-    type: "number",
-    default: 20,
-    description: "File Scope entry count that signals broad work likely needing partitioning."
-  },
-  {
-    id: "triageSubtaskRemediationBatchThreshold",
-    name: "Triage remediation batch threshold",
-    type: "number",
-    default: 30,
-    description: "Quantified remediation batch size that strongly signals subsystem partitioning."
-  },
   {
     id: "triageNoCommitsDecisionVerbs",
     name: "Triage no-commits decision verbs",
@@ -13147,20 +13120,12 @@ When you plan to list a task in the \`## Dependencies\` section, first call \`fn
 Use what you learn \u2014 file scope, APIs, patterns, completion criteria \u2014 to make the new spec accurate: reference the right paths, avoid conflicting assumptions, and describe what the dependency must deliver before this task starts.
 If the dependency task has no PROMPT.md yet (not yet specified), note that in the Dependencies section.
 
-## Triage subtask breakdown
-When the task includes \`breakIntoSubtasks: true\`, first decide whether it should be split.
-
-- Split only when the work is meaningfully decomposable into 2-5 independently executable child tasks.
-- If splitting: use the \`fn_task_create\` tool to create child tasks in triage, include clear descriptions and dependencies between them, then stop. Do NOT write a PROMPT.md for the parent task.
-- **CRITICAL \u2014 subtask dependencies:** the parent task is deleted once all subtasks are created. \`dependencies\` on a new subtask may ONLY reference sibling subtasks you have created earlier in this same split (or unrelated existing tasks). **Never depend on the parent task's id.** If a child conceptually "waits for the parent's remaining work", create a sibling subtask that does that work and depend on the sibling instead. The \`fn_task_create\` tool will reject parent-id dependencies with an error.
-- If not splitting: proceed with a normal PROMPT.md specification.
-
-## Proactive Subtask Breakdown for M/L Tasks
+## One-task planning
 <!--
-FNXC:TriagePolicy 2026-07-04-00:00:
-Workflow policy can disable proactive oversized-task splitting for operators who want triage to keep large tasks whole by default. Explicit user-requested \`breakIntoSubtasks: true\` remains governed by the mandatory breakdown section above and must not be weakened by this toggle.
+FNXC:TriagePlanning 2026-08-20-17:42:
+Complexity never authorizes replacing a requested task with child tasks. Preserve the original task ID, dependencies, and documents; write one complete, detailed PROMPT.md with focused steps, realistic scope, risks, and quality gates.
 -->
-{{triageProactiveSubtaskSplittingEnabled}}
+Create independent follow-up tasks only when they are genuinely separate work, never as an automatic decomposition of the task being planned.
 
 ## Triage tools
 You have these extra tools during triage:
@@ -13219,7 +13184,7 @@ This bullet is the planning-side half of the artifact-pipeline contract; keep it
 -->
 - For tasks with a visible UI surface or whose deliverable is visual/media (wireframes, mockups, designs, diagrams, screenshots, screen recordings, HTML prototypes, PDF exports), include an explicit step or checkbox instructing the executor to save each deliverable to disk and register it via \`fn_artifact_register\` (images via \`type="image", path=...\`; recordings via \`type="video", path=...\`; HTML mockups via \`type="document", mimeType="text/html"\` for live gallery previews; PDFs via \`type="document", mimeType="application/pdf", path=...\`) so it appears in the dashboard Artifacts gallery
 - Include a "Do NOT" section with project-appropriate guardrails
-- Size assessment: S (<{{triageSizeSmallMaxHours}}h), M ({{triageSizeSmallMaxHours}}-{{triageSizeMediumMaxHours}}h), L ({{triageSizeMediumMaxHours}}-{{triageSizeLargeMaxHours}}h). Split if XL ({{triageSizeLargeMaxHours}}h+)
+- Size assessment: S (<{{triageSizeSmallMaxHours}}h), M ({{triageSizeSmallMaxHours}}-{{triageSizeMediumMaxHours}}h), L ({{triageSizeMediumMaxHours}}-{{triageSizeLargeMaxHours}}h+). Keep every requested task as one detailed plan regardless of size.
 - Review level scoring: Blast radius (0-2), Pattern novelty (0-2), Security (0-2), Reversibility (0-2)
   - 0-1 \u2192 Level 0, 2-3 \u2192 Level 1, 4-5 \u2192 Level 2, 6-8 \u2192 Level 3
 
@@ -13234,11 +13199,11 @@ FNXC:WorkflowRouting 2026-06-22-17:24:
 Standard triage must not infer workflow changes from task type. Agents preserve the project default unless the user names or explicitly requests a workflow, or the agent created the task; no-commit decisions use the header marker without automatic workflow selection.
 -->
 ## Workflow Routing
-- Keep the project default workflow (\`{{triageDefaultWorkflowId}}\`) unless the user explicitly requested a specific workflow for this task or subtask, or you created that task yourself.
+- Keep the project default workflow (\`{{triageDefaultWorkflowId}}\`) unless the user explicitly requested a specific workflow for this task, or you created that task yourself.
 - Do NOT call \`fn_workflow_select\` or pass \`workflow_id\` to \`fn_task_create\` just because a task looks like investigation, audit, research, operational routing/coordination, decision-only work, or standard coding work.
 - When you create a task via \`fn_task_create\` or \`fn_delegate_task\`, you may select that created task's workflow with \`workflow_id\` at create time or \`fn_workflow_select\` afterward; do not move a task you did not create unless the user asked.
 - For decision-only tasks ({{triageNoCommitsDecisionVerbs}}) or other no-code tasks, set \`**No commits expected:** true\` in the PROMPT.md header when the no-commits criteria above are met; this is a header marker only and does not select \`{{triageDecisionOnlyWorkflowId}}\` or any custom investigation workflow by itself.
-- If the user explicitly asks for a workflow, call \`fn_workflow_list\` to discover valid IDs, then use \`fn_workflow_select\` to set the workflow on the current task or pass \`workflow_id\` to \`fn_task_create\` when creating a requested subtask.
+- If the user explicitly asks for a workflow, call \`fn_workflow_list\` to discover valid IDs, then use \`fn_workflow_select\` to set the workflow on the current task or pass \`workflow_id\` to \`fn_task_create\` when creating requested independent work.
 
 ## Plan Review
 
@@ -13385,45 +13350,12 @@ Concrete examples:
 - **Documentation completeness:** [Must Update / Check If Affected sections present?]
 - **Dangling task-document references:** [No \`.fusion/tasks/<id>/<file>\` path is cited in Context, Steps, or File Scope unless the file exists or is explicitly created as a \`(new)\` artifact in this spec. References to nonexistent task-local artifacts are a blocking REVISE.]
 - **Sizing & review level:** [Size and review level appropriate for the work?]
-- **Subtask breakdown:** [Only flag genuinely oversized specs (12+ implementation steps, OR 5+ truly independent deliverables that could ship separately). Do NOT flag a coherent vertical change just because it touches multiple packages. When borderline, prefer leaving the task whole.]
 - **User comment coverage:** [Were all user comments addressed? Every user comment must be reflected in the spec \u2014 missing coverage is a blocking REVISE]
 
 ### Suggestions
 - [Optional improvements, not blocking]
 \`\`\`
 
-## Spec Review \u2014 Undersplit Task Detection
-
-When reviewing specs, assess whether the task should have been broken into subtasks. The bar for splitting is high \u2014 most tasks should remain whole. Coordination overhead (worktrees, dependency wiring, merge sequencing) is real, so splitting must clearly pay for itself.
-
-**Default position:** do NOT flag undersplit. Reach for it only when the spec is genuinely oversized.
-
-**Flag as REVISE only when ALL of the following are true:**
-- The spec has 12+ implementation steps, OR contains 5+ clearly independent deliverables that could be shipped separately by different people
-- The deliverables are NOT a coherent vertical change (a single feature touching core + dashboard + tests is coherent \u2014 do not split it)
-- Splitting would produce children that each have \u22654 steps and a clearly distinct scope
-
-If the spec is borderline (under those thresholds, or arguable), put your splitting suggestion in the **Suggestions** section instead of REVISE \u2014 the planner can take it or leave it.
-
-**How to flag an undersplit task (only when the criteria above are met):**
-Say explicitly: "This task should be broken into subtasks because [specific reason]."
-Recommend the number of child tasks (2-5) and what each should cover.
-Instruct the planner to:
-1. Use the \`fn_task_create\` tool to create 2\u20135 child tasks from the oversized spec
-2. Do NOT write a parent PROMPT.md \u2014 the parent will be closed automatically after children are created
-   (Not write a parent PROMPT.md is also unacceptable.)
-3. Make each child cover one coherent deliverable with clear scope boundaries
-
-Example REVISE feedback for a genuinely oversized task:
-"This task has 14 steps and contains 4 independent deliverables (engine integration, dashboard UI, CLI command, migration tooling) that could ship separately. Use fn_task_create to split into: (1) engine logic, (2) dashboard UI, (3) CLI integration, (4) migration tooling. Do not write a parent PROMPT."
-
-**Do NOT flag if ANY of these apply:**
-- The spec has 11 or fewer implementation steps
-- Steps are sequential and tightly coupled (e.g., a pipeline where each step depends on the previous)
-- The task is a vertical change touching multiple packages for one coherent feature (typical in this monorepo)
-- The task is a bug fix, regardless of how many files it touches
-- Splitting would create coordination overhead that exceeds the benefit
-
 ## Plan Granularity
 
 When reviewing plans, assess whether the approach achieves the step's OUTCOMES \u2014
@@ -13725,7 +13657,6 @@ submissions to a high bar for correctness, security, and maintainability.
 - **Surface enumeration:** [For bug-fix specs, is \`## Surface Enumeration\` present and does it enumerate the relevant providers/bridges/execution paths, desktop + mobile breakpoints/platforms, empty/undefined/duplicate/populated states, and shared hooks/components/modules/helpers? Missing or incomplete coverage is a blocking REVISE.]
 - **Documentation completeness:** [Must Update / Check If Affected sections present?]
 - **Sizing & review level:** [Size and review level appropriate for the work?]
-- **Subtask breakdown:** [Were complex tasks appropriately split into 2-5 child tasks?]
 - **User comment coverage:** [Were all user comments addressed? Every user comment must be reflected in the spec \u2014 missing coverage is a blocking REVISE]
 - **Security considerations:** [Are security-sensitive areas identified and addressed?]
 - **Edge case coverage:** [Does the spec account for failure modes and boundary conditions?]

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

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/grok-runtime",
-  "version": "0.2.14-beta.4",
+  "version": "0.2.14-beta.6",
   "type": "module",
   "exports": {
     ".": {

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

@@ -5838,6 +5838,7 @@ var tasks = projectSchema.table("tasks", {
   mergerModelId: text("merger_model_id"),
   mergerThinkingLevel: text("merger_thinking_level"),
   mergeRetries: integer("merge_retries"),
+  aiMergeReviewReconciliation: text("ai_merge_review_reconciliation"),
   workflowStepRetries: integer("workflow_step_retries"),
   resumeLimboCount: integer("resume_limbo_count").default(0),
   graphResumeRetryCount: integer("graph_resume_retry_count").default(0),
@@ -5960,7 +5961,8 @@ var tasks = projectSchema.table("tasks", {
   sourceIssueClosedAt: text("source_issue_closed_at"),
   mergeDetails: jsonb("merge_details"),
   workspaceWorktrees: jsonb("workspace_worktrees"),
-  breakIntoSubtasks: integer("break_into_subtasks").default(0),
+  // FNXC:RepositoryScope 2026-08-20-23:07: explicit task intent must survive PostgreSQL reads independently of acquired worktrees.
+  repositoryScope: jsonb("repository_scope"),
   noCommitsExpected: integer("no_commits_expected").default(0),
   enabledWorkflowSteps: jsonb("enabled_workflow_steps").default([]),
   modifiedFiles: jsonb("modified_files").default([]),
@@ -8280,7 +8282,8 @@ var centralActivityLog = centralSchema.table("central_activity_log", {
   foreignKey({ columns: [t.projectId], foreignColumns: [projects.id] }).onDelete("cascade"),
   index("idxActivityLogTimestamp").on(t.timestamp),
   index("idxActivityLogType").on(t.type),
-  index("idxActivityLogProjectId").on(t.projectId)
+  index("idxActivityLogProjectId").on(t.projectId),
+  index("idxCentralActivityLogTaskIdTimestamp").on(t.taskId, t.timestamp)
 ]);
 var centralSettings = centralSchema.table("central_settings", {
   id: integer("id").primaryKey(),
@@ -8988,6 +8991,15 @@ var DEFAULT_GLOBAL_SETTINGS = {
   opt in before Fusion replaces its own binary and bounces the process under them.
   */
   autoUpdateAndRestart: false,
+  /*
+  FNXC:UpdateAutomation 2026-08-21-02:17:
+  Fresh installations require separate opt-ins for unattended installation and
+  restart. The legacy combined switch remains false and is only a fallback for
+  older persisted settings.
+  */
+  /* FNXC:UpdateAutomation 2026-08-21-02:48: Keep these schema keys unset because defaults merge into effective settings and `undefined` is distinct from explicit false. */
+  autoUpdateEnabled: void 0,
+  autoRestartAfterUpdate: void 0,
   autoReloadOnVersionChange: true,
   githubTrackingDefaultRepo: void 0,
   reportRoadmapDedupeEnabled: void 0,
@@ -8998,6 +9010,13 @@ var DEFAULT_GLOBAL_SETTINGS = {
   gitlabApiBaseUrl: void 0,
   gitlabAuthToken: void 0,
   gitlabAuthTokenType: void 0,
+  jiraEnabled: void 0,
+  jiraBaseUrl: void 0,
+  jiraApiBaseUrl: void 0,
+  jiraAuthEmail: void 0,
+  jiraAuthTokenSecretKey: void 0,
+  jiraAuthTokenSecretScope: void 0,
+  jiraBranchNameTemplate: void 0,
   modelOnboardingComplete: void 0,
   useClaudeCli: void 0,
   useDroidCli: void 0,
@@ -9488,6 +9507,13 @@ var DEFAULT_PROJECT_SETTINGS = {
   gitlabApiBaseUrl: void 0,
   gitlabAuthToken: void 0,
   gitlabAuthTokenType: void 0,
+  jiraEnabled: void 0,
+  jiraBaseUrl: void 0,
+  jiraApiBaseUrl: void 0,
+  jiraAuthEmail: void 0,
+  jiraAuthTokenSecretKey: void 0,
+  jiraAuthTokenSecretScope: void 0,
+  jiraBranchNameTemplate: void 0,
   gitlabCommentOnDone: false,
   gitlabCommentTemplate: void 0,
   gitlabCloseSourceIssueOnDone: false,
@@ -12284,17 +12310,6 @@ var BUILTIN_MOVED_WORKFLOW_SETTINGS = [
   }
 ];
 var BUILTIN_TRIAGE_POLICY_SETTINGS = [
-  {
-    id: "triageProactiveSubtaskSplittingEnabled",
-    name: "Triage proactive subtask splitting",
-    type: "boolean",
-    default: true,
-    /*
-     * FNXC:TriagePolicy 2026-07-04-00:00:
-     * Operators need a workflow/project policy switch that disables automatic large-task splitting without weakening explicit `breakIntoSubtasks: true` requests. Keep the default enabled to preserve existing triage behavior for workflows that have no stored override.
-     */
-    description: "Enable automatic large-task splitting guidance during triage. Turn off to split only when breakIntoSubtasks is explicitly requested."
-  },
   {
     id: "triageSizeSmallMaxHours",
     name: "Triage size S max hours",
@@ -12316,48 +12331,6 @@ var BUILTIN_TRIAGE_POLICY_SETTINGS = [
     default: 8,
     description: "Upper hour boundary for Size L triage guidance; larger work should split as XL."
   },
-  {
-    id: "triageSubtaskStepThreshold",
-    name: "Triage subtask step threshold",
-    type: "number",
-    default: 7,
-    description: "Implementation-step count above which triage should consider splitting an M/L task."
-  },
-  {
-    id: "triageSubtaskLargeStepSignal",
-    name: "Triage large-step signal",
-    type: "number",
-    default: 9,
-    description: "Planned step count that is a broad-scope decomposition signal for Size L tasks."
-  },
-  {
-    id: "triageSubtaskAdditiveStepSignal",
-    name: "Triage additive step signal",
-    type: "number",
-    default: 12,
-    description: "Implementation-step count that independently signals possible partitioning."
-  },
-  {
-    id: "triageSubtaskPackageThreshold",
-    name: "Triage package/module threshold",
-    type: "number",
-    default: 3,
-    description: "Distinct package/module count above which triage should consider splitting coherent M/L work."
-  },
-  {
-    id: "triageSubtaskFileScopeThreshold",
-    name: "Triage file-scope threshold",
-    type: "number",
-    default: 20,
-    description: "File Scope entry count that signals broad work likely needing partitioning."
-  },
-  {
-    id: "triageSubtaskRemediationBatchThreshold",
-    name: "Triage remediation batch threshold",
-    type: "number",
-    default: 30,
-    description: "Quantified remediation batch size that strongly signals subsystem partitioning."
-  },
   {
     id: "triageNoCommitsDecisionVerbs",
     name: "Triage no-commits decision verbs",
@@ -13142,20 +13115,12 @@ When you plan to list a task in the \`## Dependencies\` section, first call \`fn
 Use what you learn \u2014 file scope, APIs, patterns, completion criteria \u2014 to make the new spec accurate: reference the right paths, avoid conflicting assumptions, and describe what the dependency must deliver before this task starts.
 If the dependency task has no PROMPT.md yet (not yet specified), note that in the Dependencies section.
 
-## Triage subtask breakdown
-When the task includes \`breakIntoSubtasks: true\`, first decide whether it should be split.
-
-- Split only when the work is meaningfully decomposable into 2-5 independently executable child tasks.
-- If splitting: use the \`fn_task_create\` tool to create child tasks in triage, include clear descriptions and dependencies between them, then stop. Do NOT write a PROMPT.md for the parent task.
-- **CRITICAL \u2014 subtask dependencies:** the parent task is deleted once all subtasks are created. \`dependencies\` on a new subtask may ONLY reference sibling subtasks you have created earlier in this same split (or unrelated existing tasks). **Never depend on the parent task's id.** If a child conceptually "waits for the parent's remaining work", create a sibling subtask that does that work and depend on the sibling instead. The \`fn_task_create\` tool will reject parent-id dependencies with an error.
-- If not splitting: proceed with a normal PROMPT.md specification.
-
-## Proactive Subtask Breakdown for M/L Tasks
+## One-task planning
 <!--
-FNXC:TriagePolicy 2026-07-04-00:00:
-Workflow policy can disable proactive oversized-task splitting for operators who want triage to keep large tasks whole by default. Explicit user-requested \`breakIntoSubtasks: true\` remains governed by the mandatory breakdown section above and must not be weakened by this toggle.
+FNXC:TriagePlanning 2026-08-20-17:42:
+Complexity never authorizes replacing a requested task with child tasks. Preserve the original task ID, dependencies, and documents; write one complete, detailed PROMPT.md with focused steps, realistic scope, risks, and quality gates.
 -->
-{{triageProactiveSubtaskSplittingEnabled}}
+Create independent follow-up tasks only when they are genuinely separate work, never as an automatic decomposition of the task being planned.
 
 ## Triage tools
 You have these extra tools during triage:
@@ -13214,7 +13179,7 @@ This bullet is the planning-side half of the artifact-pipeline contract; keep it
 -->
 - For tasks with a visible UI surface or whose deliverable is visual/media (wireframes, mockups, designs, diagrams, screenshots, screen recordings, HTML prototypes, PDF exports), include an explicit step or checkbox instructing the executor to save each deliverable to disk and register it via \`fn_artifact_register\` (images via \`type="image", path=...\`; recordings via \`type="video", path=...\`; HTML mockups via \`type="document", mimeType="text/html"\` for live gallery previews; PDFs via \`type="document", mimeType="application/pdf", path=...\`) so it appears in the dashboard Artifacts gallery
 - Include a "Do NOT" section with project-appropriate guardrails
-- Size assessment: S (<{{triageSizeSmallMaxHours}}h), M ({{triageSizeSmallMaxHours}}-{{triageSizeMediumMaxHours}}h), L ({{triageSizeMediumMaxHours}}-{{triageSizeLargeMaxHours}}h). Split if XL ({{triageSizeLargeMaxHours}}h+)
+- Size assessment: S (<{{triageSizeSmallMaxHours}}h), M ({{triageSizeSmallMaxHours}}-{{triageSizeMediumMaxHours}}h), L ({{triageSizeMediumMaxHours}}-{{triageSizeLargeMaxHours}}h+). Keep every requested task as one detailed plan regardless of size.
 - Review level scoring: Blast radius (0-2), Pattern novelty (0-2), Security (0-2), Reversibility (0-2)
   - 0-1 \u2192 Level 0, 2-3 \u2192 Level 1, 4-5 \u2192 Level 2, 6-8 \u2192 Level 3
 
@@ -13229,11 +13194,11 @@ FNXC:WorkflowRouting 2026-06-22-17:24:
 Standard triage must not infer workflow changes from task type. Agents preserve the project default unless the user names or explicitly requests a workflow, or the agent created the task; no-commit decisions use the header marker without automatic workflow selection.
 -->
 ## Workflow Routing
-- Keep the project default workflow (\`{{triageDefaultWorkflowId}}\`) unless the user explicitly requested a specific workflow for this task or subtask, or you created that task yourself.
+- Keep the project default workflow (\`{{triageDefaultWorkflowId}}\`) unless the user explicitly requested a specific workflow for this task, or you created that task yourself.
 - Do NOT call \`fn_workflow_select\` or pass \`workflow_id\` to \`fn_task_create\` just because a task looks like investigation, audit, research, operational routing/coordination, decision-only work, or standard coding work.
 - When you create a task via \`fn_task_create\` or \`fn_delegate_task\`, you may select that created task's workflow with \`workflow_id\` at create time or \`fn_workflow_select\` afterward; do not move a task you did not create unless the user asked.
 - For decision-only tasks ({{triageNoCommitsDecisionVerbs}}) or other no-code tasks, set \`**No commits expected:** true\` in the PROMPT.md header when the no-commits criteria above are met; this is a header marker only and does not select \`{{triageDecisionOnlyWorkflowId}}\` or any custom investigation workflow by itself.
-- If the user explicitly asks for a workflow, call \`fn_workflow_list\` to discover valid IDs, then use \`fn_workflow_select\` to set the workflow on the current task or pass \`workflow_id\` to \`fn_task_create\` when creating a requested subtask.
+- If the user explicitly asks for a workflow, call \`fn_workflow_list\` to discover valid IDs, then use \`fn_workflow_select\` to set the workflow on the current task or pass \`workflow_id\` to \`fn_task_create\` when creating requested independent work.
 
 ## Plan Review
 
@@ -13380,45 +13345,12 @@ Concrete examples:
 - **Documentation completeness:** [Must Update / Check If Affected sections present?]
 - **Dangling task-document references:** [No \`.fusion/tasks/<id>/<file>\` path is cited in Context, Steps, or File Scope unless the file exists or is explicitly created as a \`(new)\` artifact in this spec. References to nonexistent task-local artifacts are a blocking REVISE.]
 - **Sizing & review level:** [Size and review level appropriate for the work?]
-- **Subtask breakdown:** [Only flag genuinely oversized specs (12+ implementation steps, OR 5+ truly independent deliverables that could ship separately). Do NOT flag a coherent vertical change just because it touches multiple packages. When borderline, prefer leaving the task whole.]
 - **User comment coverage:** [Were all user comments addressed? Every user comment must be reflected in the spec \u2014 missing coverage is a blocking REVISE]
 
 ### Suggestions
 - [Optional improvements, not blocking]
 \`\`\`
 
-## Spec Review \u2014 Undersplit Task Detection
-
-When reviewing specs, assess whether the task should have been broken into subtasks. The bar for splitting is high \u2014 most tasks should remain whole. Coordination overhead (worktrees, dependency wiring, merge sequencing) is real, so splitting must clearly pay for itself.
-
-**Default position:** do NOT flag undersplit. Reach for it only when the spec is genuinely oversized.
-
-**Flag as REVISE only when ALL of the following are true:**
-- The spec has 12+ implementation steps, OR contains 5+ clearly independent deliverables that could be shipped separately by different people
-- The deliverables are NOT a coherent vertical change (a single feature touching core + dashboard + tests is coherent \u2014 do not split it)
-- Splitting would produce children that each have \u22654 steps and a clearly distinct scope
-
-If the spec is borderline (under those thresholds, or arguable), put your splitting suggestion in the **Suggestions** section instead of REVISE \u2014 the planner can take it or leave it.
-
-**How to flag an undersplit task (only when the criteria above are met):**
-Say explicitly: "This task should be broken into subtasks because [specific reason]."
-Recommend the number of child tasks (2-5) and what each should cover.
-Instruct the planner to:
-1. Use the \`fn_task_create\` tool to create 2\u20135 child tasks from the oversized spec
-2. Do NOT write a parent PROMPT.md \u2014 the parent will be closed automatically after children are created
-   (Not write a parent PROMPT.md is also unacceptable.)
-3. Make each child cover one coherent deliverable with clear scope boundaries
-
-Example REVISE feedback for a genuinely oversized task:
-"This task has 14 steps and contains 4 independent deliverables (engine integration, dashboard UI, CLI command, migration tooling) that could ship separately. Use fn_task_create to split into: (1) engine logic, (2) dashboard UI, (3) CLI integration, (4) migration tooling. Do not write a parent PROMPT."
-
-**Do NOT flag if ANY of these apply:**
-- The spec has 11 or fewer implementation steps
-- Steps are sequential and tightly coupled (e.g., a pipeline where each step depends on the previous)
-- The task is a vertical change touching multiple packages for one coherent feature (typical in this monorepo)
-- The task is a bug fix, regardless of how many files it touches
-- Splitting would create coordination overhead that exceeds the benefit
-
 ## Plan Granularity
 
 When reviewing plans, assess whether the approach achieves the step's OUTCOMES \u2014
@@ -13720,7 +13652,6 @@ submissions to a high bar for correctness, security, and maintainability.
 - **Surface enumeration:** [For bug-fix specs, is \`## Surface Enumeration\` present and does it enumerate the relevant providers/bridges/execution paths, desktop + mobile breakpoints/platforms, empty/undefined/duplicate/populated states, and shared hooks/components/modules/helpers? Missing or incomplete coverage is a blocking REVISE.]
 - **Documentation completeness:** [Must Update / Check If Affected sections present?]
 - **Sizing & review level:** [Size and review level appropriate for the work?]
-- **Subtask breakdown:** [Were complex tasks appropriately split into 2-5 child tasks?]
 - **User comment coverage:** [Were all user comments addressed? Every user comment must be reflected in the spec \u2014 missing coverage is a blocking REVISE]
 - **Security considerations:** [Are security-sensitive areas identified and addressed?]
 - **Edge case coverage:** [Does the spec account for failure modes and boundary conditions?]

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

@@ -1,6 +1,6 @@
 {
   "name": "@fusion-plugin-examples/hermes-runtime",
-  "version": "0.2.86-beta.4",
+  "version": "0.2.86-beta.6",
   "type": "module",
   "exports": {
     ".": {