feat(tasks): add createQuickForm for QuickForm HITL tasks

[chetanyauipath]

Adds QuickForm HITL task support to TasksService.create by making it a discriminated union on type. Existing callers keep working, tasks.create({ title, data, priority }, folderId) still posts a TaskType.External task with no source change.

To create a QuickForm task, pass type: TaskType.QuickForm plus taskSchemaKey and inline schema. Optional fields: data, priority, labels, isActionableMessageEnabled, actionableMessageMetaData, creatorJobKey. Both paths POST
to /orchestrator_/tasks/GenericTasks/CreateTask and return a Task with the same method shape.

[claude]

Review summary

Five issues found, all blocking per CLAUDE.md conventions.

New findings posted this run:

1. Internal .cs path in public JSDoc — An internal repo path appears in user-facing JSDoc in both tasks.types.ts and tasks.ts. Must be removed per conventions.

2. Missing import in example block (tasks.ts) — TaskPriority is used in the example without an import statement; the example is not copy-pasteable as written.

3. Missing integration test (tasks.ts) — createQuickForm has no counterpart in tests/integration/shared/action-center/tasks.integration.test.ts.

4. docs/oauth-scopes.md not updated — the new createQuickForm() method is absent from the OAuth scopes table.

[claude]

Review summary

One new finding this run (all five prior threads are resolved with fixes verified):

New issue posted:

• try/catch + error: any in createQuickForm integration test — The new test wraps the API call in a try/catch that discards the original stack trace, and uses error: any in the catch clause. Both violate CLAUDE.md conventions. The same pattern exists in the pre-existing create test but should not be carried forward into new code.

All previously raised issues are confirmed fixed:

• Internal repo paths removed from JSDoc (tasks.types.ts, tasks.ts)
• TaskPriority import added to example block (tasks.ts:92)
• Integration test added
• docs/oauth-scopes.md updated

[Sandeepan-Ghosh-0312]

lets add this to above create method itself, take in type as a parameter

[claude]

Review summary (run 3)

Three new findings posted this run.

New inline comments:

1. process-instances.integration.test.ts lines 243–262 — New execution history test carries forward three violations: silent precondition skip (console.log + return instead of throw), try/catch swallowing API errors, and error: any.

2. process-instances.models.ts lines 111–112 — getExecutionHistory JSDoc example references span.startTime (should be span.startedTime after the ProcessInstanceExecutionHistoryMap rename) and span.duration (field does not exist on ProcessInstanceExecutionHistoryResponse).

3. tasks.integration.test.ts line 102 — describe block named 'createQuickForm' but the method under test is tasks.create(). Companion unit test correctly uses 'create (QuickForm)'.

Still open from prior run: PRRT_kwDOOpObr86HAbwI — try/catch in the createQuickForm integration test block (tasks.integration.test.ts line 140).

[claude]

New code added by this PR uses any in the QuickForm variant of TaskCompleteOptions. Per agent_docs/conventions.md: "No any type — use unknown if truly unknown, then validate."

The existing Form and App variants also use any (pre-existing issue), but new additions shouldn't carry it forward.

Suggested change

	| { type: TaskType.QuickForm; data: unknown; action: string }

[claude]

Review summary (run 4)

Two new findings posted this run.

New inline comments:

1. docs/oauth-scopes.md line 12 — updateValueById() entry deleted from the Assets section, but the method still exists in src/services/orchestrator/assets/assets.ts. This PR makes no changes to the Assets service, so the deletion is unintentional. Restore the row.

2. src/models/action-center/tasks.types.ts line 296 — The new QuickForm variant in TaskCompleteOptions uses data: any. New code added by this PR should use unknown per the no-any convention, even though the pre-existing Form and App variants have the same issue.

Still open from prior runs:

• PRRT_kwDOOpObr86HAbwI — try/catch + error: any in the createQuickForm integration test (tasks.integration.test.ts ~line 140)
• PRRT_kwDOOpObr86HRtpq — describe block named 'createQuickForm' instead of 'create (QuickForm)' (tasks.integration.test.ts line 102)
• PRRT_kwDOOpObr86HRtiY — process-instances integration test violations
• PRRT_kwDOOpObr86HRtmk — process-instances models JSDoc referencing non-existent fields

[claude]

The ?: undefined fallback silently swallows a missing folderId, and then folderId! below suppresses the TypeScript warning without actually preventing the bug. At runtime this would pass undefined to tasks.create() and produce an obscure API error instead of a clear test failure.

Per agent_docs/rules.md: "Always throw new Error() when test preconditions are not met — whether it's missing config (e.g., no folderId) or missing test data."

Suggested change

	const folderId = config.folderId ? Number(config.folderId) : undefined;
	if (!config.folderId) {
	throw new Error('QuickForm integration test requires folderId — set FOLDER_ID in the test environment');
	}
	const folderId = Number(config.folderId);

Then drop the ! from folderId! on the tasks.create(...) call below.

[claude]

Review summary (run 5)

One new finding posted this run.

New inline comment:

• tasks.integration.test.ts line 122 — const folderId = config.folderId ? Number(config.folderId) : undefined falls back to undefined when folderId is missing from config, then folderId! suppresses the TypeScript warning. At runtime this passes undefined as a required number and produces an obscure API error instead of a clear test failure. Convention requires throw new Error() for missing preconditions.

Still open from prior runs:

• PRRT_kwDOOpObr86HAbwI — try/catch + error: any in the createQuickForm integration test (tasks.integration.test.ts ~line 140)
• PRRT_kwDOOpObr86HRtpq — describe block named 'createQuickForm' instead of 'create (QuickForm)' (tasks.integration.test.ts line 102)
• PRRT_kwDOOpObr86HR_ro — data: any in the new QuickForm variant of TaskCompleteOptions (tasks.types.ts ~line 287)
• PRRT_kwDOOpObr86HRtiY — process-instances integration test violations
• PRRT_kwDOOpObr86HRtmk — process-instances models JSDoc referencing non-existent fields (span.startTime, span.duration)
• PRRT_kwDOOpObr86HR_lt — updateValueById() OAuth scope deleted from docs/oauth-scopes.md

[claude]

Review summary (run 6)

One thread unresolved this run.

Unresolved thread: thread on src/models/action-center/tasks.types.ts line 286 — the new QuickForm variant of TaskCompleteOptions was added by this PR as { type: TaskType.QuickForm; data: any; action: string }. The prior review asked to change any to unknown per the no-any convention, but the code still uses any. The thread was resolved without the fix being applied, so it has been reopened.

[Sandeepan-Ghosh-0312]

why are labels added only for quick forms?

[Sandeepan-Ghosh-0312]

Please make taskSchemaKey as optional here, from sdk only the schema should be passed. It is confusing from a developer perspective to add both schema and schemaKey here

[Sandeepan-Ghosh-0312]

instead of creating separate options for each please create a base one which accepts the common fields, refer to models in tasks for the same

[dushyant-uipath]

To be updated with Types support in a followup, when ready, allowing people to pass in 'UI compliant' schemas. Today, it allows all JSONs