ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
c49acba7cd
TenantAtlas/specs/423-security-compliance-readiness-pack/tasks.md
Ahmed Darrazi c49acba7cd
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m20s
Details
feat: complete spec 423 security compliance readiness pack
2026-06-30 13:57:10 +02:00

14 KiB
Raw Blame History

Tasks: Spec 423 - Security and Compliance Readiness Pack

Input: spec.md, plan.md, user-provided Spec 423 draft Prerequisites: Completed read-only Specs 414, 415, 417, 418, 419, 420, 421, and 422; existing Coverage v2 registry/read model; existing Security and Compliance registry rows; existing Sail/Pest platform test workflow.

Scope Reminder: Implement compare/render/readiness over existing content-backed Coverage v2 evidence only. Do not add restore/apply, certification, legal attestation, customer-facing output, Review Pack output, new capture/source contracts, routes, navigation, dashboards, migrations, tables, live provider calls, or a Security/Purview mini-platform.

Phase 1: Preflight and Evidence Gate

  • T001 Record branch, HEAD, dirty state, activated skills, hard-gate status, and implementation start timestamp in specs/423-security-compliance-readiness-pack/implementation-report.md.
  • T002 Verify specs/414-tcm-first-coverage-core-cutover/, specs/415-generic-content-backed-capture/, and specs/417-canonical-identity-engine/ through specs/422-exchange-teams-comparable-renderable-pack/ are treated as read-only dependency context; record no completed-spec rewrites in implementation-report.md.
  • T003 Inspect existing Security and Compliance registry rows in apps/platform/app/Services/TenantConfiguration/ResourceTypeRegistry.php and apps/platform/app/Services/TenantConfiguration/SupportedScopeResolver.php; record canonical keys, aliases, restore tier, and risk posture in implementation-report.md.
  • T004 Build the evidence-promotion matrix for retentionCompliancePolicy, labelPolicy, dlpCompliancePolicy, autoSensitivityLabelPolicy, protectionAlert, and complianceTag from existing Coverage v2 evidence/test fixtures; mark each type promote, defer_missing_evidence, defer_missing_tests, or defer_out_of_scope.
  • T005 Stop and amend spec.md/plan.md before runtime implementation if any promoted type needs a new source contract, capture contract, migration, live provider call, route/navigation, customer output, restore/apply behavior, or completed-spec rewrite.

Phase 2: Tests First - Mandatory Type Normalization

  • T006 Add failing unit coverage for deterministic retentionCompliancePolicy normalization in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceComparablePayloadNormalizerTest.php.
  • T007 Add failing unit coverage for deterministic labelPolicy normalization in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceComparablePayloadNormalizerTest.php.
  • T008 Add failing unit coverage for deterministic dlpCompliancePolicy normalization in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceComparablePayloadNormalizerTest.php.
  • T009 Add failing unit coverage proving volatile fields are ignored and sensitive fields are redacted for mandatory types in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceComparablePayloadNormalizerTest.php.
  • T010 Add failing unit coverage proving unsupported or high-risk fields produce unsupported_field or manual_review_required instead of raw output in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceComparablePayloadNormalizerTest.php.

Phase 3: Tests First - Compare, Render, and Readiness

  • T011 Add failing unit coverage for compare labels added, removed, changed, unchanged, ignored_volatile, redacted, unsupported_field, and manual_review_required in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceCoverageComparatorTest.php.
  • T012 Add failing unit coverage for derived importance labels critical, important, informational, and manual_review_required in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceCoverageComparatorTest.php.
  • T013 Add failing field-level materiality coverage for FR-423-010 in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceCoverageComparatorTest.php, proving retention duration/disposition/scope/state, DLP mode/actions/rules/scope, label publication/default/mandatory behavior, and evidence-backed optional auto-label/alert/compliance-tag material fields are never downgraded to informational.
  • T014 Add failing unit coverage for operator-safe render summaries in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceRenderableSummaryBuilderTest.php.
  • T015 Add failing unit coverage proving render summaries hide raw JSON, provider responses, secrets, fingerprints, mail/chat/file/case content, DLP incident content, and security incident content in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceRenderableSummaryBuilderTest.php.
  • T016 Add failing unit coverage for readiness states readiness_not_assessed, readiness_ready_for_operator_review, readiness_requires_manual_review, readiness_blocked_identity, readiness_blocked_evidence, readiness_blocked_permission, and readiness_blocked_unsupported in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceReadinessEvaluatorTest.php.
  • T017 Add failing unit coverage proving readiness never implies restore-ready, certification-ready, legal-ready, customer-ready, or support for Microsoft tenant writes in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceReadinessEvaluatorTest.php.

Phase 4: Tests First - Claim Guard, Authorization, and No Remote Work

  • T018 Add failing Claim Guard tests allowing only scoped internal/operator comparable/renderable/readiness wording for selected Security and Compliance evidence in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceClaimGuardTest.php.
  • T019 Add failing Claim Guard tests blocking restore-ready, apply-ready, certified, legal/regulatory, customer-facing, Review Pack, broad Security and Compliance, broad Purview, and 100 percent coverage claims in apps/platform/tests/Unit/Support/TenantConfiguration/Spec423SecurityComplianceClaimGuardTest.php.
  • T020 Add failing feature tests proving wrong-workspace/non-member access is deny-as-not-found and missing read capability is 403 in apps/platform/tests/Feature/TenantConfiguration/Spec423SecurityComplianceCoverageAuthorizationTest.php.
  • T021 Add failing feature tests proving provider connection, managed environment, and workspace scope are enforced without tenant_id ownership in apps/platform/tests/Feature/TenantConfiguration/Spec423SecurityComplianceCoverageAuthorizationTest.php.
  • T022 Add failing feature/unit tests proving compare/render/readiness performs no Graph, TCM, HTTP, provider, Microsoft docs, or remote network calls in apps/platform/tests/Feature/TenantConfiguration/Spec423SecurityComplianceCoverageReadinessTest.php.

Phase 5: Implement Typed Security and Compliance Helpers

  • T023 Create the smallest repo-conventional typed normalizer for selected Security and Compliance payloads in apps/platform/app/Services/TenantConfiguration/SecurityComplianceComparablePayloadNormalizer.php.
  • T024 Implement mandatory type field allowlists, volatile-field dropping, stable value shaping, and redaction handoff in apps/platform/app/Services/TenantConfiguration/SecurityComplianceComparablePayloadNormalizer.php.
  • T025 Implement deterministic compare behavior in apps/platform/app/Services/TenantConfiguration/SecurityComplianceCoverageComparator.php.
  • T026 Implement operator-safe render summaries in apps/platform/app/Services/TenantConfiguration/SecurityComplianceRenderableSummaryBuilder.php.
  • T027 Implement bounded readiness/manual-review derivation in apps/platform/app/Services/TenantConfiguration/SecurityComplianceReadinessEvaluator.php or the repo-equivalent local helper if sibling naming dictates a different structure.
  • T028 Reuse existing CoveragePayloadRedactor.php behavior; extend it only if focused tests prove Security/Compliance-sensitive values are not already covered.

Phase 6: Integrate with Coverage v2 Read Model and Claims

  • T029 Wire selected Security/Compliance helper dispatch into apps/platform/app/Services/TenantConfiguration/CoverageV2ReadinessReadModel.php using the existing Entra/Exchange/Teams pattern and without a new generic registry/framework unless implementation evidence proves it is necessary.
  • T030 Update apps/platform/app/Services/TenantConfiguration/ClaimGuard.php so scoped internal/operator Security/Compliance comparable/renderable/readiness claims are allowed and prohibited claims are blocked.
  • T031 Ensure selected type promotion respects the evidence-promotion matrix: unsupported optional types remain deferred and explain why in implementation-report.md.
  • T032 Confirm existing registry and supported-scope metadata remain conservative: selected Security/Compliance types stay non-restorable and no restore/apply action becomes reachable.

Phase 7: Optional Type Promotion Gate

  • T033 Promote autoSensitivityLabelPolicy only if existing content-backed evidence and focused tests prove normalization, compare, render, readiness, redaction, Claim Guard, RBAC, and no-remote behavior.
  • T034 Promote protectionAlert only if existing content-backed evidence and focused tests prove default-visible summaries never expose security incident details or sensitive alert payloads.
  • T035 Promote complianceTag only if existing content-backed evidence and focused tests prove label/tag summaries remain operator-safe and non-certifying.
  • T036 Defer any optional type that lacks evidence, test coverage, or bounded semantics; document the reason in implementation-report.md instead of widening scope.

Phase 8: Product Surface and Browser Proof

  • T037 If rendered output changes, run a focused browser smoke against the existing Coverage v2 readiness/inspect surface and verify decision-first summary, diagnostics-second detail, raw/support gating, no customer/legal/certification/restore wording, and no overlapping/incoherent UI.
  • T038 N/A - rendered Coverage v2 output changed, so focused browser proof was recorded under T037 instead of N/A - no rendered UI surface changed.
  • T039 Record Human Product Sanity result in implementation-report.md: an internal operator can decide manual-review need without raw payloads and without overclaim.
  • T040 Update docs/ui-ux-enterprise-audit/ coverage artifacts only if implementation changes runtime UI files, routes, navigation, page structure, actions, or panel/provider surface.

Phase 9: Validation and Close-Out

  • T041 Run cd apps/platform && ./vendor/bin/sail artisan test --filter=Spec423 and record the result in implementation-report.md.
  • T042 Run focused Claim Guard validation, e.g. cd apps/platform && ./vendor/bin/sail artisan test --filter=ClaimGuard, and record the result in implementation-report.md.
  • T043 Run the existing narrow Coverage v2 affected tests identified during implementation and record commands/results in implementation-report.md.
  • T044 Run formatting/static validation used by the repo for touched PHP files and record commands/results in implementation-report.md.
  • T045 Confirm no migration, env var, queue, scheduler, storage, or asset deployment step was introduced; if any was introduced, amend plan.md before close-out.
  • T046 Confirm Livewire v4 compliance, panel provider registration location (apps/platform/bootstrap/providers.php), global search posture, destructive/high-impact action posture, asset strategy, deployment impact, and Product Surface Contract close-out fields in implementation-report.md.
  • T047 Confirm no tenant_id ownership, no raw role-string checks, no completed-spec rewrites, no remote calls, no customer output, no certification/legal/restore/apply claims, and no Security/Purview mini-platform.

Dependencies and Ordering

  • T001-T005 must complete before runtime implementation.
  • T006-T022 should be written before implementation where practical; if repo helpers require small fixture discovery first, document the deviation in implementation-report.md.
  • T023-T028 depend on the relevant failing unit tests.
  • T029-T032 depend on core helper behavior.
  • T033-T036 are optional and may be skipped with documented defer reasons.
  • T037-T040 depend on whether rendered output changes.
  • T041-T047 are close-out tasks and must not be completed before implementation validation.

Parallel Work Opportunities

  • T006-T010 can be split by mandatory resource type.
  • T011-T017 can be split by compare/render/readiness helper.
  • T018-T019 can run in parallel with T020-T022.
  • T023-T028 can proceed in parallel after test contracts are clear, but one reviewer should keep Claim Guard wording aligned with readiness semantics.
  • T037-T040 can run after the read model wiring is stable.

Implementation Guardrails

  • Keep fake payload fixtures minimal and local to Spec 423 tests.
  • Use existing service/test naming conventions from sibling TenantConfiguration code.
  • Prefer direct concrete helpers over a new registry, factory, interface, or orchestration pipeline.
  • Do not introduce persisted states, enums, tables, migrations, routes, navigation entries, dashboards, actions, or assets without stopping to amend the spec/plan.
  • Do not rewrite completed specs to retrofit close-out wording.
  • Do not use live Microsoft Graph, TCM, Purview, Security and Compliance, Microsoft docs, or HTTP calls in tests or runtime render/compare/readiness paths.

Completion Definition

  • Spec, plan, tasks, checklist, implementation report, and implementation agree on promoted/deferred types.
  • Mandatory selected evidence types have deterministic normalization, compare, render, readiness, redaction, Claim Guard, RBAC, and no-remote proof.
  • Optional types are either fully proven or explicitly deferred.
  • Product Surface proof or exact N/A proof is recorded.
  • Deployment impact is assessed as none or amended before merge.