Checklist builder placement
The workspace exposes23 parts. Place eyebrow/title/subtitle/manage-templates-action/new-template-action/start-checklist-action independently. Grouped header omits already placed controls.
Place target-filter/status-filter/filter-action separately; their native form owner survives outside the form. Omitted fields remain in a fallback form. Paging uses submitted filters and exposes page-size/previous-action/page-status/next-action, with a maximum of 100 rows.
The existing form/template manager remains available even in action-only layouts. List-only layouts retain selected detail as fallback. Native permission and revision decisions remain authoritative.
Source/local synthetic proof only; publication and routed-tenant verification remain held. Run IDs are not canonical record IDs and are not published as shared selections.

Use recordFrom to follow another workspace's selected canonical record. The list, filter recovery and start form stay bound to that exact target. A missing, cleared, ambiguous or self-follow selection cannot cause an unfiltered read. Start rejects a tampered target. Foreign-target list/detail responses are rejected. No new APIs or tenant authority are introduced. Template management/signoff still use the existing server permissions; an editor without workflow.manage can receive its native denial.

Checklist details now expose 16 independent pieces (39 total): back-action, run-status, run-title, target-title, target-location, progress, request-signoff-action, approval-status, cancellation, items, target-favorite, template-name, run-created, run-updated, run-revision and heading. Grouped heading/detail omit separately placed pieces. A custom detail layout takes over the native detail fallback; retain items/cancellation/approval-status where the workflow needs them. With only list parts placed the native detail remains available. Actions reuse exact native run revisions and permissions; target-favorite uses the canonical parent record. Proof upload wraps inside narrow cards and item status stays compact on mobile. Local synthetic proof is not tenant deployment acceptance.

Checklist list accepts custom child layouts. Ten row parts (49 total) expose row-open, row-title, row-target, row-location, row-status, row-progress, row-template, row-updated, row-revision and row-target-favorite. Values come from the current secured run row; row-open uses checklistRunId, favorite uses targetRecordId. Nested workspaces clear row identity. Native empty/loading/error/form recovery remains; no children keeps the native list. No new API or permission bypass.

Checklist start now exposes nine independent pieces (58 total): start-heading, start-template-status, start-create-template-action, start-record-query, start-find-records-action, start-target, start-template, start-title and start-submit-action. They share one native form owner even across custom columns. The grouped form fills omitted pieces. A followed record stays in the owner as a fixed hidden target, with tampering rejected; no separate target choice is invented. Native empty-template recovery, denial draft retention and pending request protection remain.

Reusable Checklist template forms expose nine pieces (67 total): template-form-heading, template-item-count, template-remove-action, template-form-name, template-form-description, template-form-items, template-add-item-action, template-save-action and template-cancel-action. External controls belong to one native owner, including required item fields. Read-only/pending controls remain disabled and stale saves retain draft values. Clearing an item key requires an explicit replacement instead of silently inventing a new one. Existing template removal keeps existing runs.

Checklist template-form-items accepts a custom repeated layout with eight item parts (75 total): template-item-position, key, title, instructions, response-type, evidence, required and remove-action (all with template-item- prefix). Each row retains the native controlled draft and form ownership. Removing a row preserves the other rows and renumbers sort order. Nested Checklist modules clear the outer item context. No children preserves the grouped editor.

Checklist templates accepts a custom repeated layout with six row parts plus templates-heading (82 total): template-row-open, name, description, item-count, updated and status. Actions use the secured returned template identity, not block-provided IDs. Empty and failed reads preserve the native recovery controls; nested modules clear the outer row context.

Checklist items accepts a custom repeated layout with fourteen parts (96 total): item-title, required, status, instructions, response, save-action, revision, response-type, proof-heading, proof-list, proof-file, proof-kind, proof-caption and proof-upload-action (all with item- prefix). Each item retains separate native save/upload form owners, exact item revision and canonical upload parent. Omitted controls stay in native forms. Pending/read-only controls are disabled; failed saves preserve drafts and successful refreshes advance revision.

Checklist item-proof-list accepts custom repeated proof cards with eight parts (104 total): proof-kind, file-name, caption, content-type, size, added-by, created and remove-action. Each action uses the returned evidence identity and the native confirmation lifecycle; it detaches evidence while retaining its underlying file. Unknown/read-only/busy actions are rejected, cancellation makes no request, failed removal retains the proof and nested workspaces clear its context.
