ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
3a3de045ba
TenantAtlas/specs/014-enrollment-autopilot/checklists/requirements.md
ahmido 6a1809fbe9 014-enrollment-autopilot (#20) 
This PR completes Feature 014 (Enrollment & Autopilot).

Adds normalization for:
Autopilot deployment profiles (windowsAutopilotDeploymentProfile)
Enrollment Status Page / ESP (windowsEnrollmentStatusPage)
Enrollment Restrictions (enrollmentRestriction, restore remains preview-only)
Improves settings readability:
Autopilot OOBE settings are expanded into readable key/value entries
Enrollment restriction platform restrictions are shown as explicit fields (with sensible defaults)
Array/list values render as badges (avoids Blade rendering crashes on non-string values)
Fixes enrollment configuration type collisions during sync:
Canonical type resolution prevents enrollmentRestriction from “claiming” ESP items
Safe reclassification updates existing wrong rows instead of skipping
Enhances reclassification command:
Can detect ESP even if a policy has no local versions (fetches snapshot from Graph)
Dry-run by default; apply with --write
Tests

Added/updated unit + Filament feature tests for normalization and UI rendering.
Preview-only enforcement for enrollment restrictions is covered.
Targeted test suite and Pint are green.

Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local>
Reviewed-on: #20
2026-01-02 11:59:21 +00:00

1.2 KiB
Raw Blame History

Specification Quality Checklist: Enrollment & Autopilot

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-01-01 Feature: spec.md

Content Quality

  • No implementation details (languages, frameworks, APIs)
  • Focused on user value and business needs
  • Written for non-technical stakeholders
  • All mandatory sections completed

Requirement Completeness

  • No [NEEDS CLARIFICATION] markers remain
  • Requirements are testable and unambiguous
  • Success criteria are measurable
  • Success criteria are technology-agnostic (no implementation details)
  • 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
  • No implementation details leak into specification

Notes

  • Assumptions: Restore behavior for enrollment restrictions remains preview-only until a separate product decision explicitly enables it.