elsa-core/specs/012-external-authentication/checklists/requirements.md

Specification Quality Checklist: External Authentication

Purpose: Validate specification completeness and quality before proceeding to planning

Created: 2026-07-24

Revalidated: 2026-07-24 approved revision

Feature: spec.md

Content Quality

• No implementation details dominate the product requirements
• Focused on user value and business needs
• Written for product and technical stakeholders
• All mandatory sections completed

Requirement Completeness

• No [NEEDS CLARIFICATION] markers remain
• Requirements are testable and unambiguous
• Success criteria are measurable
• Success criteria describe observable outcomes
• All acceptance scenarios are defined
• Edge cases are identified
• Scope is clearly bounded
• Dependencies and assumptions identified

Feature Readiness

• All functional requirements have clear acceptance criteria
• User scenarios cover primary flows
• Feature meets measurable outcomes defined in Success Criteria
• Core/server and paired Studio delivery boundaries are explicit

Approved Revision Consistency

• Settings is defined as UI composition/navigation only
• Connections are host-wide in the connected environment without a Deployment Target entity/field
• Record ID versus durable Connection Key responsibilities and full-shadow lifecycle are unambiguous
• OIDC discoveryUrl, gated Advanced trust overrides, immutable deployment-derived callback/confidential client/S256 PKCE/validation, and basic/post authentication are explicit
• Managed and External Secret ownership is explicit
• Archive/restore, Test, and Preview behavior is explicit
• Preferred method never causes automatic redirect
• Per-connection policy, single External User Matcher, ephemeral claims, fallback behavior, and static create-user defaultRoleIds are explicit
• Role deletion is guarded by all database/configuration JIT-policy references, with immutable configuration diagnostics and atomic-or-safe-best-effort editable remediation
• Authentication.UI shell, Settings Connections, and separate Security Links/Sessions ownership are explicit
• Direct OIDC compatibility and staged deprecation are explicit
• Minimal upstream token retention and Elsa-initiated login/logout are explicit
• Claim-permission mapping UI is explicitly outside v1
• Open implementation delta is represented by unchecked T117–T135

Implementation Readiness

• T117–T132 implementation and migration work complete
• T133–T135 verification gates pass

Notes

• The PRD interview resolved the product-level questions, so no clarification markers remain.
• Protocol and security terms such as OpenID Connect and PKCE are behavioral constraints, not implementation prescriptions.
• Exact routes, schemas, storage models, package names, and framework integration belong in the implementation plan.
• The OIDC validation contract, host-wide discovery shape, WebAssembly session behavior, normalized claim/role projection, and shared latest-test observation are explicit and testable.
• Checked historical tasks T001–T116 do not override the open approved-revision tasks.