TenantAtlas/specs/248-private-ai-policy-foundation/tasks.md
Ahmed Darrazi 6383f205a1
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m3s
chore: commit all changes (automated) 2026-04-27T21:17:40Z
2026-04-27 23:17:40 +02:00

20 KiB

description
Task list for Private AI Execution & Policy Foundation

Tasks: Private AI Execution & Policy Foundation

Input: Design documents from /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/
Prerequisites: /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/plan.md (required), /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/spec.md (required), /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/research.md, /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/data-model.md, /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/contracts/private-ai-governance.openapi.yaml, /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/quickstart.md

Tests: REQUIRED (Pest) for runtime behavior changes. Keep proof in focused Unit and Feature lanes, plus one architecture guard, using the targeted Sail commands captured in the feature artifacts.
Operations: No new OperationRun, queue, retry, monitoring page, or result ledger is introduced. This slice remains DB-backed settings, operational-control, and audit work only.
RBAC: Existing workspace settings authorization and platform ops-control authorization remain authoritative. Non-members or wrong-plane actors keep 404 deny-as-not-found semantics where applicable; members missing the required capability receive 403.
Provider Boundary: AI trust vocabulary stays platform-core and vendor-neutral (AI use case, provider class, data classification). external_public remains blocked in v1.
Organization: Tasks are grouped by user story so workspace AI policy, governed decision enforcement, and operational-stop controls remain independently testable once the shared foundation exists.

Test Governance Checklist

  • Lane assignment stays Unit plus Feature and remains the narrowest sufficient proof for the changed behavior.
  • New or changed tests stay in apps/platform/tests/Unit/Support/Ai/, apps/platform/tests/Feature/SettingsFoundation/, apps/platform/tests/Feature/OperationalControls/, apps/platform/tests/Feature/System/OpsControls/, and apps/platform/tests/Feature/Guards/ only; no browser or heavy-governance lane is added.
  • Shared helpers, factories, fixtures, and context defaults stay cheap by default; do not add provider emulators, queue scaffolding, or seeded AI history.
  • Planned validation commands cover workspace settings, governed AI decision logic, audit metadata, operational controls, and the no-direct-provider guard without widening scope.
  • The declared surface test profile remains standard-native-filament because the slice only extends existing workspace settings and system controls pages.
  • Any deferred public-provider execution, result persistence, budgeting, or queued AI follow-up resolves as document-in-feature or follow-up-spec, not as hidden scope growth.

Phase 1: Setup (Shared Context)

Purpose: Confirm the bounded first slice, repo seams, and reviewer stop conditions before runtime implementation begins.

  • T001 Review the bounded slice, explicit non-goals, approved use cases, validation lanes, and guardrail expectations in /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/spec.md, /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/plan.md, /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/research.md, /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/data-model.md, /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/contracts/private-ai-governance.openapi.yaml, and /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/quickstart.md
  • T002 [P] Confirm the existing workspace settings persistence, resolver, and audit seams that this slice must reuse in apps/platform/app/Filament/Pages/Settings/WorkspaceSettings.php, apps/platform/app/Support/Settings/SettingsRegistry.php, apps/platform/app/Services/Settings/SettingsResolver.php, apps/platform/app/Services/Settings/SettingsWriter.php, apps/platform/app/Support/Audit/AuditActionId.php, and apps/platform/app/Services/Audit/WorkspaceAuditLogger.php
  • T003 [P] Confirm the existing operational-control, platform authorization, and guard-test seams that this slice must extend in apps/platform/app/Filament/System/Pages/Ops/Controls.php, apps/platform/app/Support/OperationalControls/OperationalControlCatalog.php, apps/platform/app/Support/OperationalControls/OperationalControlEvaluator.php, apps/platform/app/Support/Auth/Capabilities.php, apps/platform/app/Support/Auth/PlatformCapabilities.php, apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsManageTest.php, apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsViewOnlyTest.php, apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsNonMemberNotFoundTest.php, apps/platform/tests/Feature/OperationalControls/OperationalControlAuthorizationSemanticsTest.php, and apps/platform/tests/Feature/System/OpsControls/OperationalControlManagementTest.php

Phase 2: Foundational (Blocking Prerequisites)

Purpose: Add the shared AI policy, decision, audit, and operational-stop primitives that every user story depends on.

Critical: No user story work should begin until this phase is complete.

  • T004 [P] Add the ai.policy_mode setting definition, allowed values, system default, and resolver plumbing in apps/platform/app/Support/Settings/SettingsRegistry.php and apps/platform/app/Services/Settings/SettingsResolver.php
  • T005 [P] Create the bounded AI support namespace for policy modes, provider classes, data classifications, and request/decision value objects under apps/platform/app/Support/Ai/
  • T006 Implement the code-owned approved-use-case catalog locked to product_knowledge.answer_draft and support_diagnostics.summary_draft in apps/platform/app/Support/Ai/AiUseCaseCatalog.php and companion definition files under apps/platform/app/Support/Ai/
  • T007 Implement the governed AI execution boundary so host-surface authorization stays a caller-side precondition, then evaluate ai.execution, workspace policy, use-case registration, provider class, and data-classification allowance in apps/platform/app/Support/Ai/GovernedAiExecutionBoundary.php
  • T008 [P] Add the bounded AI decision audit action and metadata-shaping support without prompt, source-payload, or output persistence in apps/platform/app/Support/Audit/AuditActionId.php, apps/platform/app/Services/Audit/WorkspaceAuditLogger.php, and apps/platform/app/Support/Ai/
  • T009 [P] Add the ai.execution operational-control definition and evaluator lookup path in apps/platform/app/Support/OperationalControls/OperationalControlCatalog.php and apps/platform/app/Support/OperationalControls/OperationalControlEvaluator.php

Checkpoint: Shared workspace policy, governed AI decision, audit metadata, and runtime stop primitives exist; user stories can now proceed independently.


Phase 3: User Story 1 - Set Workspace AI Posture Once (Priority: P1) MVP

Goal: Let a workspace owner or manager set one explicit workspace AI posture on the existing settings surface before any later AI-assisted workflow is added.

Independent Test: Open /admin/settings/workspace, save disabled and private_only, verify the resolved explanation and approved-use-case summary update on the existing settings page, and confirm authorized and unauthorized actors still get the expected settings semantics.

Tests for User Story 1

  • T010 [P] [US1] Add feature coverage for saving, resetting, and rendering the workspace AI policy section on the existing settings page in apps/platform/tests/Feature/SettingsFoundation/WorkspaceAiPolicySettingsTest.php
  • T011 [P] [US1] Extend positive and negative workspace-settings authorization coverage so non-members stay 404, members without manage capability stay 403, and authorized managers can mutate ai.policy_mode in apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsManageTest.php, apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsViewOnlyTest.php, and apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsNonMemberNotFoundTest.php
  • T012 [P] [US1] Extend workspace-settings audit coverage for AI policy mode updates and resets in apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsAuditTest.php

Implementation for User Story 1

  • T013 [US1] Add the Workspace AI policy section, approved use-case summary, allowed provider-class summary, and blocked data-class explanation to apps/platform/app/Filament/Pages/Settings/WorkspaceSettings.php
  • T014 [US1] Persist ai.policy_mode through the existing audited settings stack in apps/platform/app/Support/Settings/SettingsRegistry.php, apps/platform/app/Services/Settings/SettingsResolver.php, and apps/platform/app/Services/Settings/SettingsWriter.php
  • T015 [US1] Keep page-level save and reset behavior, helper text, and default-visible policy explanation derived from the central AI catalog instead of page-local strings in apps/platform/app/Filament/Pages/Settings/WorkspaceSettings.php and apps/platform/app/Support/Ai/

Checkpoint: User Story 1 is independently functional when the workspace settings page owns one explicit AI posture with correct audit and authorization behavior.


Phase 4: User Story 2 - Block Unsafe AI Requests Before Provider Resolution (Priority: P1)

Goal: Force every in-scope AI request through one governed allow-or-block decision so unregistered use cases, blocked trust classes, and blocked data classifications never reach provider resolution.

Independent Test: Exercise the governed AI boundary with approved and blocked request combinations, verify allowed private-only requests use only approved source families, and prove blocked requests never resolve a provider call.

Tests for User Story 2

  • T016 [P] [US2] Add unit coverage for the approved-use-case catalog and declared provider-class and data-classification rules in apps/platform/tests/Unit/Support/Ai/AiUseCaseCatalogTest.php
  • T017 [P] [US2] Add unit coverage for boundary precedence across missing workspace context, unregistered use cases, blocked provider classes, blocked data classifications, disabled, private_only, and allowed private-only requests in apps/platform/tests/Unit/Support/Ai/GovernedAiExecutionBoundaryTest.php
  • T018 [P] [US2] Add unit coverage for AI decision audit metadata shape and explicit exclusion of prompt text, raw source payloads, raw provider payloads, and output text in apps/platform/tests/Unit/Support/Ai/AiDecisionAuditMetadataTest.php
  • T019 [P] [US2] Add architecture-guard coverage that no direct AI provider call or vendor-specific runtime entry appears outside the governed boundary in apps/platform/tests/Feature/Guards/NoDirectAiProviderBypassTest.php

Implementation for User Story 2

  • T020 [US2] Finalize the governed request and decision contract plus no-provider-resolution behavior inside apps/platform/app/Support/Ai/GovernedAiExecutionBoundary.php and its request/decision collaborators under apps/platform/app/Support/Ai/
  • T021 [US2] Expose only approved source-family inputs for product_knowledge.answer_draft and support_diagnostics.summary_draft from apps/platform/app/Support/ProductKnowledge/ContextualHelpResolver.php and apps/platform/app/Support/SupportDiagnostics/SupportDiagnosticBundleBuilder.php without adding customer-facing AI UI, public-provider execution, or result persistence
  • T022 [US2] Route governed AI decision evaluation through the existing audit pipeline with stable allow-or-block metadata and no prompt/output persistence in apps/platform/app/Support/Audit/AuditActionId.php, apps/platform/app/Services/Audit/WorkspaceAuditLogger.php, and apps/platform/app/Support/Ai/

Checkpoint: User Story 2 is independently functional when the central AI boundary blocks unsafe requests before provider resolution and records bounded audit metadata only.


Phase 5: User Story 3 - Pause All AI Execution Centrally During An Incident (Priority: P2)

Goal: Let a platform operator pause and resume new AI execution from the existing system operational-controls surface without introducing a second AI admin console.

Independent Test: Pause ai.execution on /system/ops/controls, verify an otherwise valid governed AI request blocks with the operational-control reason, then resume the control and verify normal policy evaluation resumes.

Tests for User Story 3

  • T023 [P] [US3] Add feature coverage for pausing and resuming ai.execution on the existing controls page, including confirmation-backed state changes and visible control history, in apps/platform/tests/Feature/System/OpsControls/AiExecutionOperationalControlTest.php and apps/platform/tests/Feature/System/OpsControls/OperationalControlManagementTest.php
  • T024 [P] [US3] Extend positive and negative platform authorization coverage so platform.access_system_panel plus platform.ops.controls.manage remain authoritative for ai.execution pause/resume in apps/platform/tests/Feature/OperationalControls/OperationalControlAuthorizationSemanticsTest.php
  • T025 [P] [US3] Extend governed-boundary coverage so an active ai.execution control blocks otherwise valid requests until the control is resumed in apps/platform/tests/Unit/Support/Ai/GovernedAiExecutionBoundaryTest.php

Implementation for User Story 3

  • T026 [US3] Add the ai.execution control definition, operator-facing label, global-only scope, and evaluator lookup semantics in apps/platform/app/Support/OperationalControls/OperationalControlCatalog.php and apps/platform/app/Support/OperationalControls/OperationalControlEvaluator.php
  • T027 [US3] Add the AI execution control card plus confirmation-protected Pause AI execution and Resume AI execution actions to the existing system controls surface in apps/platform/app/Filament/System/Pages/Ops/Controls.php
  • T028 [US3] Keep operational-control copy, blocked-reason vocabulary, and control-history presentation aligned across apps/platform/app/Filament/System/Pages/Ops/Controls.php and apps/platform/app/Support/Ai/GovernedAiExecutionBoundary.php without introducing a new AI capability string or system AI console

Checkpoint: User Story 3 is independently functional when the existing system controls page can pause and resume new AI execution and the boundary honors that stop immediately for new requests.


Phase 6: Polish & Cross-Cutting Concerns

Purpose: Finish narrow validation, formatting, and reviewer close-out without widening scope.

  • T029 [P] Run the focused unit validation commands recorded in /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/plan.md and /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/quickstart.md for apps/platform/tests/Unit/Support/Ai/AiUseCaseCatalogTest.php, apps/platform/tests/Unit/Support/Ai/AiDecisionAuditMetadataTest.php, and apps/platform/tests/Unit/Support/Ai/GovernedAiExecutionBoundaryTest.php
  • T030 [P] Run the focused workspace-settings validation commands recorded in /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/plan.md and /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/quickstart.md for apps/platform/tests/Feature/SettingsFoundation/WorkspaceAiPolicySettingsTest.php, apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsManageTest.php, apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsViewOnlyTest.php, apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsNonMemberNotFoundTest.php, and apps/platform/tests/Feature/SettingsFoundation/WorkspaceSettingsAuditTest.php
  • T031 [P] Run the focused system-control and architecture-guard validation commands recorded in /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/plan.md and /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/quickstart.md for apps/platform/tests/Feature/System/OpsControls/AiExecutionOperationalControlTest.php, apps/platform/tests/Feature/System/OpsControls/OperationalControlManagementTest.php, apps/platform/tests/Feature/OperationalControls/OperationalControlAuthorizationSemanticsTest.php, and apps/platform/tests/Feature/Guards/NoDirectAiProviderBypassTest.php
  • T032 Run dirty-only formatting for touched platform files through apps/platform/vendor/bin/sail using the Pint command recorded in /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/quickstart.md
  • T033 Record the TEST-GOV-001 outcome, guardrail close-out, and any document-in-feature or follow-up-spec deferrals for public-provider execution, result persistence, budgeting, or queued AI work in /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/plan.md and /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/248-private-ai-policy-foundation/quickstart.md

Dependencies & Execution Order

Phase Dependencies

  • Phase 1 (Setup): no dependencies; start immediately.
  • Phase 2 (Foundational): depends on Phase 1 and blocks all user stories.
  • Phase 3 (US1): depends on Phase 2 and establishes the workspace-owned policy truth.
  • Phase 4 (US2): depends on Phase 2 and should ship with US1 because policy without a governed boundary would create false confidence.
  • Phase 5 (US3): depends on Phase 2 and is safest after US2 because the boundary must already honor ai.execution for the system control to be meaningful.
  • Phase 6 (Polish): depends on all desired user stories being complete.

User Story Dependencies

  • US1 (P1): independently testable after Phase 2, but not safe to ship alone.
  • US2 (P1): independently testable after Phase 2 and must pair with US1 for a safe MVP.
  • US3 (P2): independently testable after Phase 2, but depends on the governed boundary from US2 to prove runtime stop behavior.

Within Each User Story

  • Write the listed Pest coverage first and make it fail for the intended behavior gap.
  • Complete shared service enforcement before wiring the corresponding Filament surface.
  • Re-run the narrowest affected validation command after each story checkpoint before moving to the next story.

Parallel Execution Examples

User Story 1

  • T010, T011, and T012 can run in parallel before runtime edits begin.
  • After test scaffolding exists, T013 and T014 can proceed in parallel because the page wiring and settings-stack persistence touch different files; T015 should follow both.

User Story 2

  • T016, T017, T018, and T019 can run in parallel because they cover separate unit and guard files.
  • After T020 settles the governed contract, T021 and T022 can proceed in parallel because source-family helpers and audit plumbing live on separate seams.

User Story 3

  • T023, T024, and T025 can run in parallel before implementation starts.
  • T026 should land before T027, and T028 should follow both so control-surface wording and boundary reason vocabulary stay consistent.

Implementation Strategy

Suggested MVP Scope

  • MVP = US1 + US2 together. Workspace policy alone is not safe to ship because the spec explicitly requires the governed boundary that enforces the policy before any provider resolution can occur.

Incremental Delivery

  1. Complete Phase 1 and Phase 2.
  2. Deliver US1 and US2 together, then validate the settings-backed policy plus governed boundary behavior.
  3. Deliver US3 to add the runtime stop on the existing system controls surface.
  4. Finish with narrow validation, formatting, and feature-level close-out in Phase 6.

Team Strategy

  1. Finish Phase 2 together before splitting story work.
  2. Parallelize test authoring inside each story first.
  3. Serialize merges around apps/platform/app/Support/Ai/ and apps/platform/app/Filament/System/Pages/Ops/Controls.php, because those seams are shared by multiple story tasks.