feat(workflow-executor): ai-assisted action forms, ai pre-fills then human submits (PRD-511)

[Scra3]

What

AI-assisted mode of the AI-assisted & Full AI action forms epic (PRD-57), built on PRD-509. "AI-assisted" = the existing AutomatedWithConfirmation mode (no new enum). The executor pre-fills the form server-side then pauses; the front executes natively.

Changes

• Shared AI fill loop (fillFormWithAi) — bounded by max iterations (3) + no-progress detection; re-applies values each pass so dynamic-form change hooks reveal dependent fields; strict "leave empty if unsure" prompt; returns values in fill order so the front replays sequentially. Reused by Full AI (PRD-512).
• Mode branching: formless unchanged; form + Manual → pause, NO AI prefill; form + FullyAutomated → still UnsupportedActionFormError (PRD-512 implements); form + AutomatedWithConfirmation → fill then pause.
• Schema: TriggerAction.executionType accepts Manual and drops .catch (which silently coerced manual → AI-assisted). Regression-tested via the mapper. server-types also accepts Manual.
• Pending payload: pendingData.form = { fields, aiFilledValues: ordered {field,value}[] }.
• Confirmation payload: submittedValues + submissionOutcome (executed | pending-approval). Branch A accepts a pending-approval confirmation with no actionResult and persists outcome + submitted values + AI prefill (audit / downstream-AI context).

Tests

1099 tests pass (48 suites). New: Manual no-prefill, AI-assisted ordered fill (leaves no-context field empty), pending-approval persistence, manual-not-coerced.

Stacked on feature/prd-509-executor-action-form-port.

fixes PRD-511

Note

Add AI-assisted form pre-fill with human review to trigger-action workflow steps

• Adds a Manual execution type to trigger-action steps, which pauses the workflow and presents the form to the user without AI involvement.
• Adds an AutomatedWithConfirmation path for form-bearing actions: the executor runs an iterative AI loop (fillFormWithAi) to pre-fill form fields using workflow context, then pauses for human review before submission.
• FullyAutomated on form-bearing actions is explicitly rejected with UnsupportedActionFormError.
• Extends TriggerActionPendingData and execution result types to carry fields, aiFilledValues, submittedValues, and submissionOutcome (executed | pending-approval).
• The PATCH endpoint now accepts submittedValues and submissionOutcome from the frontend via an extended triggerActionPatchSchema.
• Risk: removing the .catch(AutomatedWithConfirmation) coercion means any existing step definition with an unrecognized executionType will no longer silently fall back.

📊 Macroscope summarized 8a4cc02. 1 file reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[linear-code]

PRD-511

[qltysh]

1 new issue

Tool	Category	Rule	Count
qlty	Structure	Function with high complexity (count = 15): fillFormWithAi	1

[qltysh]

Coverage Impact

Unable to calculate total coverage change because base branch coverage was not found.

Modified Files with Diff Coverage (2)

Rating	File	% Diff	Uncovered Line #s
	...-executor/src/executors/trigger-record-action-step-executor.ts	98.2%	252
	packages/workflow-executor/src/executors/agent-with-log.ts	100.0%
	Total	98.2%

🤖 Increase coverage with AI coding...

In the `feature/prd-511-executor-ai-assisted-forms` branch, add test coverage for this new code:

- `packages/workflow-executor/src/executors/trigger-record-action-step-executor.ts` -- Line 252

🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.

[macroscopeapp]

🟢 Low executors/trigger-record-action-step-executor.ts:202

The isNew check on line 202 uses !== (reference comparison), so when the AI returns a structurally identical object or array value across iterations (same content, different reference), it is treated as "new." This pushes duplicate entries into ordered, inflating the aiFilledValues audit trail and triggering unnecessary sequential replays on the frontend. Consider using a value-based comparison such as JSON.stringify.

Suggested change

	const isNew = accumulator[field] !== value;
	const isNew = JSON.stringify(accumulator[field]) !== JSON.stringify(value);

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @packages/workflow-executor/src/executors/trigger-record-action-step-executor.ts around line 202:

The `isNew` check on line 202 uses `!==` (reference comparison), so when the AI returns a structurally identical object or array value across iterations (same content, different reference), it is treated as "new." This pushes duplicate entries into `ordered`, inflating the `aiFilledValues` audit trail and triggering unnecessary sequential replays on the frontend. Consider using a value-based comparison such as `JSON.stringify`.

Evidence trail:
packages/workflow-executor/src/executors/trigger-record-action-step-executor.ts lines 190-213 (loop with `accumulator[field] !== value` on line 202); lines 244-305 (`askAiToFillForm` returns `Record<string, unknown>`, schema uses `z.unknown()` at line 267); packages/workflow-executor/src/ports/agent-port.ts lines 61-68 (ActionFormField type is `string`, value is `unknown`); packages/workflow-executor/src/adapters/agent-client-agent-port.ts lines 300-311 (field types include 'Enum' and others via `field.getType()`); packages/workflow-executor/src/types/step-execution-data.ts lines 84-89 (AiFilledFormValue interface with `value: unknown`).