Solid work: the SecretsTable component is clean, accessible (aria-label on table, sr-only status text, focus-visible on tooltip triggers), and the Storybook coverage is thorough with play functions that verify sort order, tooltip content, link targets, and button disabled state. The multi-layer submission blocking (disabled button + formik onSubmit + controller handleSubmit) is the right pattern. The wsResponseId fix is a real correctness improvement applied consistently.

3 P2, 12 P3, 2 Nit, 2 Note. The P2s: auto-create bypasses the new secrets gate, the "account settings" copy misleads every user who sees it, and there is no re-check path after adding a secret via CLI. Most P3s are convergent across multiple reviewers.

The wsResponseId fix is correct and necessary but is a separate concern from the secrets feature. If the secrets feature is reverted, the fix goes with it. Consider extracting it to a separate commit.

"The user sees parameters jump to an intermediate state then back, which is the exact scenario the WorkspaceParametersPage guard was written to prevent." (Knov, on the missing stale-response guard)

site/src/pages/CreateWorkspacePage/CreateWorkspacePage.tsx:248

P2 [DEREM-4] Auto-create path bypasses the new secret requirements check. autoCreateReady checks hasAllRequiredExternalAuth and autoCreateConsented but never checks whether secrets are satisfied. A user (or deep link) hitting ?mode=auto with a template that requires unset secrets submits the build without the frontend gate this PR promises.

The external auth check at lines 255-277 proves the auto-create path is expected to enforce prerequisites. The omission is a gap, not a design boundary.

Could we add && !secretsBlocking (or a similar check on latestResponse?.secret_requirements) to the autoCreateReady condition, and add an auto-mode abandonment block parallel to the external auth one?

(Mafuuu)

🤖

🤖 This review was automatically generated with Coder Agents.