Compare commits

..

4 Commits

Author SHA1 Message Date
Ahmed Darrazi
7077898412 Merge remote-tracking branch 'origin/dev' into 245-customer-health-score 2026-04-27 14:22:20 +02:00
Ahmed Darrazi
324ee45e64 feat(customer-health): add detail decision card and update attention widget link (spec 245)
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m3s
2026-04-27 10:26:00 +02:00
Ahmed Darrazi
f05857c276 Merge remote-tracking branch 'origin/dev' into platform-dev 2026-04-27 02:13:30 +02:00
Ahmed Darrazi
9f5d3293c5 Merge remote-tracking branch 'origin/dev' into platform-dev 2026-04-26 22:53:42 +02:00
22 changed files with 51 additions and 2385 deletions

View File

@ -6,7 +6,6 @@
use App\Filament\Resources\OperationRunResource;
use App\Models\OperationRun;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use App\Services\Audit\WorkspaceAuditLogger;
@ -31,7 +30,6 @@
use App\Support\RestoreSafety\RestoreSafetyCopy;
use App\Support\Rbac\UiEnforcement;
use App\Support\SupportDiagnostics\SupportDiagnosticBundleBuilder;
use App\Support\SupportRequests\SupportRequestSubmissionService;
use App\Support\Tenants\ReferencedTenantLifecyclePresentation;
use App\Support\Tenants\TenantInteractionLane;
use App\Support\Tenants\TenantOperabilityQuestion;
@ -42,10 +40,6 @@
use App\Support\Ui\OperatorExplanation\OperatorExplanationPattern;
use Filament\Actions\Action;
use Filament\Actions\ActionGroup;
use Filament\Forms\Components\Placeholder;
use Filament\Forms\Components\Select;
use Filament\Forms\Components\TextInput;
use Filament\Forms\Components\Textarea;
use Filament\Notifications\Notification;
use Filament\Pages\Page;
use Filament\Schemas\Components\EmbeddedSchema;
@ -147,6 +141,10 @@ protected function getHeaderActions(): array
? OperationRunLinks::tenantlessView($this->run, $navigationContext)
: OperationRunLinks::index());
if (isset($this->run)) {
$actions[] = $this->openSupportDiagnosticsAction();
}
if (! isset($this->run)) {
return $actions;
}
@ -169,14 +167,6 @@ protected function getHeaderActions(): array
->color('gray');
}
$actions[] = ActionGroup::make([
$this->openSupportDiagnosticsAction(),
$this->requestSupportAction(),
])
->label('More')
->icon('heroicon-o-ellipsis-horizontal')
->color('gray');
$actions[] = $this->resumeCaptureAction();
return $actions;
@ -238,6 +228,8 @@ private function openSupportDiagnosticsAction(): Action
$action = Action::make('openSupportDiagnostics')
->label('Open support diagnostics')
->icon('heroicon-o-lifebuoy')
->iconButton()
->tooltip('Open support diagnostics')
->color('gray')
->record($this->run)
->modal()
@ -259,85 +251,39 @@ private function openSupportDiagnosticsAction(): Action
->apply();
}
public function authorizeOperationRunSupportRequest(): void
{
$this->resolveRunTenantForCapability(Capabilities::SUPPORT_REQUESTS_CREATE);
}
private function requestSupportAction(): Action
{
$action = Action::make('requestSupport')
->label('Request support')
->icon('heroicon-o-paper-airplane')
->record($this->run)
->slideOver()
->stickyModalHeader()
->modalHeading('Request support')
->modalDescription('Share a concise summary and TenantAtlas will attach redacted context from the current run.')
->modalSubmitActionLabel('Submit support request')
->form([
Placeholder::make('primary_context')
->label('Primary context')
->content(fn (): string => OperationRunLinks::identifier($this->run))
->columnSpanFull(),
Placeholder::make('included_context')
->label('Included context')
->content(fn (): string => $this->operationSupportRequestAttachmentSummary())
->columnSpanFull(),
Select::make('severity')
->label('Severity')
->options(SupportRequest::severityOptions())
->default(SupportRequest::SEVERITY_NORMAL)
->required()
->native(false),
TextInput::make('summary')
->label('Summary')
->required()
->columnSpanFull(),
Textarea::make('reproduction_notes')
->label('Reproduction notes')
->rows(4)
->columnSpanFull(),
TextInput::make('contact_name')
->label('Contact name')
->default(fn (): ?string => $this->resolveViewerActor()->name),
TextInput::make('contact_email')
->label('Contact email')
->email()
->default(fn (): ?string => $this->resolveViewerActor()->email),
])
->action(function (array $data): void {
$actor = $this->resolveViewerActor();
$supportRequest = app(SupportRequestSubmissionService::class)->submitForOperationRun($this->run, $actor, $data);
Notification::make()
->title('Support request submitted')
->body('Reference '.$supportRequest->internal_reference)
->success()
->send();
});
return UiEnforcement::forAction($action)
->requireCapability(Capabilities::SUPPORT_REQUESTS_CREATE)
->apply();
}
/**
* @return array<string, mixed>
*/
public function operationRunSupportDiagnosticBundle(): array
{
$user = $this->resolveViewerActor();
$tenant = $this->resolveRunTenantForCapability(Capabilities::SUPPORT_DIAGNOSTICS_VIEW);
$user = auth()->user();
$tenant = $this->supportDiagnosticsTenant();
if (! $user instanceof User || ! $tenant instanceof Tenant) {
abort(404);
}
$resolver = app(CapabilityResolver::class);
if (! $resolver->isMember($user, $tenant)) {
abort(404);
}
if (! $resolver->can($user, $tenant, Capabilities::SUPPORT_DIAGNOSTICS_VIEW)) {
abort(403);
}
return app(SupportDiagnosticBundleBuilder::class)->forOperationRun($this->run, $user);
}
private function auditOperationSupportDiagnosticsOpen(): void
{
$user = $this->resolveViewerActor();
$tenant = $this->resolveRunTenantForCapability(Capabilities::SUPPORT_DIAGNOSTICS_VIEW);
$user = auth()->user();
$tenant = $this->supportDiagnosticsTenant();
if (! $user instanceof User || ! $tenant instanceof Tenant) {
abort(404);
}
$this->recordSupportDiagnosticsOpened(
tenant: $tenant,
@ -361,59 +307,6 @@ private function supportDiagnosticsTenant(): ?Tenant
return $this->run->loadMissing('tenant')->tenant;
}
private function resolveViewerActor(): User
{
$user = auth()->user();
if (! $user instanceof User) {
abort(403);
}
return $user;
}
private function resolveRunTenantForCapability(string $capability): Tenant
{
$tenant = $this->supportDiagnosticsTenant();
$user = $this->resolveViewerActor();
if (! $tenant instanceof Tenant) {
abort(404);
}
$resolver = app(CapabilityResolver::class);
if (! $resolver->isMember($user, $tenant)) {
abort(404);
}
if (! $resolver->can($user, $tenant, $capability)) {
abort(403);
}
return $tenant;
}
private function operationSupportRequestAttachmentSummary(): string
{
$tenant = $this->supportDiagnosticsTenant();
$user = auth()->user();
if (! $tenant instanceof Tenant || ! $user instanceof User) {
return 'Only canonical redacted run context will be attached.';
}
$resolver = app(CapabilityResolver::class);
if (! $resolver->isMember($user, $tenant)) {
return 'Only canonical redacted run context will be attached.';
}
return $resolver->can($user, $tenant, Capabilities::SUPPORT_DIAGNOSTICS_VIEW)
? 'A redacted diagnostic snapshot and the canonical run context will be attached.'
: 'Only the canonical redacted run context will be attached because you cannot view support diagnostics.';
}
/**
* @param array<string, mixed> $bundle
*/

View File

@ -11,7 +11,6 @@
use App\Filament\Widgets\Dashboard\RecentDriftFindings;
use App\Filament\Widgets\Dashboard\RecentOperations;
use App\Filament\Widgets\Dashboard\RecoveryReadiness;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use App\Services\Audit\WorkspaceAuditLogger;
@ -21,14 +20,8 @@
use App\Support\ProductTelemetry\ProductUsageEventCatalog;
use App\Support\Rbac\UiEnforcement;
use App\Support\SupportDiagnostics\SupportDiagnosticBundleBuilder;
use App\Support\SupportRequests\SupportRequestSubmissionService;
use Filament\Actions\Action;
use Filament\Facades\Filament;
use Filament\Forms\Components\Placeholder;
use Filament\Forms\Components\Select;
use Filament\Forms\Components\TextInput;
use Filament\Forms\Components\Textarea;
use Filament\Notifications\Notification;
use Filament\Pages\Dashboard;
use Filament\Widgets\Widget;
use Filament\Widgets\WidgetConfiguration;
@ -77,72 +70,10 @@ public function getColumns(): int|array
protected function getHeaderActions(): array
{
return [
$this->requestSupportAction(),
$this->openSupportDiagnosticsAction(),
];
}
public function authorizeTenantSupportRequest(): void
{
$this->resolveCurrentTenantForCapability(Capabilities::SUPPORT_REQUESTS_CREATE);
}
private function requestSupportAction(): Action
{
$action = Action::make('requestSupport')
->label('Request support')
->icon('heroicon-o-paper-airplane')
->color('gray')
->slideOver()
->stickyModalHeader()
->modalHeading('Request support')
->modalDescription('Share a concise summary and TenantAtlas will attach redacted context from existing records.')
->modalSubmitActionLabel('Submit request')
->form([
Placeholder::make('included_context')
->label('Included context')
->content(fn (): string => $this->tenantSupportRequestAttachmentSummary())
->columnSpanFull(),
Select::make('severity')
->label('Severity')
->options(SupportRequest::severityOptions())
->default(SupportRequest::SEVERITY_NORMAL)
->required()
->native(false),
TextInput::make('summary')
->label('Summary')
->required()
->columnSpanFull(),
Textarea::make('reproduction_notes')
->label('Reproduction notes')
->rows(4)
->columnSpanFull(),
TextInput::make('contact_name')
->label('Contact name')
->default(fn (): ?string => $this->resolveDashboardActor()->name),
TextInput::make('contact_email')
->label('Contact email')
->email()
->default(fn (): ?string => $this->resolveDashboardActor()->email),
])
->action(function (array $data): void {
$actor = $this->resolveDashboardActor();
$tenant = $this->resolveCurrentTenantForCapability(Capabilities::SUPPORT_REQUESTS_CREATE);
$supportRequest = app(SupportRequestSubmissionService::class)->submitForTenant($tenant, $actor, $data);
Notification::make()
->title('Support request submitted')
->body('Reference '.$supportRequest->internal_reference)
->success()
->send();
});
return UiEnforcement::forAction($action)
->requireCapability(Capabilities::SUPPORT_REQUESTS_CREATE)
->apply();
}
private function openSupportDiagnosticsAction(): Action
{
$action = Action::make('openSupportDiagnostics')
@ -173,16 +104,34 @@ private function openSupportDiagnosticsAction(): Action
*/
public function tenantSupportDiagnosticBundle(): array
{
$user = $this->resolveDashboardActor();
$tenant = $this->resolveCurrentTenantForCapability(Capabilities::SUPPORT_DIAGNOSTICS_VIEW);
$user = auth()->user();
$tenant = Filament::getTenant();
if (! $user instanceof User || ! $tenant instanceof Tenant) {
abort(404);
}
$resolver = app(CapabilityResolver::class);
if (! $resolver->isMember($user, $tenant)) {
abort(404);
}
if (! $resolver->can($user, $tenant, Capabilities::SUPPORT_DIAGNOSTICS_VIEW)) {
abort(403);
}
return app(SupportDiagnosticBundleBuilder::class)->forTenant($tenant, $user);
}
private function auditTenantSupportDiagnosticsOpen(): void
{
$user = $this->resolveDashboardActor();
$tenant = $this->resolveCurrentTenantForCapability(Capabilities::SUPPORT_DIAGNOSTICS_VIEW);
$user = auth()->user();
$tenant = Filament::getTenant();
if (! $user instanceof User || ! $tenant instanceof Tenant) {
abort(404);
}
$this->recordSupportDiagnosticsOpened(
tenant: $tenant,
@ -223,57 +172,4 @@ private function recordSupportDiagnosticsOpened(Tenant $tenant, array $bundle, U
$this->supportDiagnosticsAuditKeys[] = $auditKey;
}
private function resolveDashboardActor(): User
{
$user = auth()->user();
if (! $user instanceof User) {
abort(404);
}
return $user;
}
private function resolveCurrentTenantForCapability(string $capability): Tenant
{
$user = $this->resolveDashboardActor();
$tenant = Filament::getTenant();
if (! $tenant instanceof Tenant) {
abort(404);
}
$resolver = app(CapabilityResolver::class);
if (! $resolver->isMember($user, $tenant)) {
abort(404);
}
if (! $resolver->can($user, $tenant, $capability)) {
abort(403);
}
return $tenant;
}
private function tenantSupportRequestAttachmentSummary(): string
{
$tenant = Filament::getTenant();
$user = auth()->user();
if (! $tenant instanceof Tenant || ! $user instanceof User) {
return 'Only canonical redacted tenant context will be attached.';
}
$resolver = app(CapabilityResolver::class);
if (! $resolver->isMember($user, $tenant)) {
return 'Only canonical redacted tenant context will be attached.';
}
return $resolver->can($user, $tenant, Capabilities::SUPPORT_DIAGNOSTICS_VIEW)
? 'A redacted diagnostic snapshot and the canonical tenant context will be attached.'
: 'Only the canonical redacted tenant context will be attached because you cannot view support diagnostics.';
}
}

View File

@ -1,121 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Models;
use App\Support\Concerns\DerivesWorkspaceIdFromTenant;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;
class SupportRequest extends Model
{
use DerivesWorkspaceIdFromTenant;
/** @use HasFactory<\Database\Factories\SupportRequestFactory> */
use HasFactory;
public const string PRIMARY_CONTEXT_TENANT = 'tenant';
public const string PRIMARY_CONTEXT_OPERATION_RUN = 'operation_run';
public const string ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED = 'diagnostic_snapshot_attached';
public const string ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY = 'canonical_context_only';
public const string SEVERITY_LOW = 'low';
public const string SEVERITY_NORMAL = 'normal';
public const string SEVERITY_HIGH = 'high';
public const string SEVERITY_BLOCKING = 'blocking';
protected $guarded = [];
/**
* @return array<string, string>
*/
protected function casts(): array
{
return [
'context_envelope' => 'array',
];
}
/**
* @return array<string, string>
*/
public static function severityOptions(): array
{
return [
self::SEVERITY_LOW => 'Low',
self::SEVERITY_NORMAL => 'Normal',
self::SEVERITY_HIGH => 'High',
self::SEVERITY_BLOCKING => 'Blocking',
];
}
/**
* @return list<string>
*/
public static function severityValues(): array
{
return array_keys(self::severityOptions());
}
/**
* @return list<string>
*/
public static function primaryContextTypes(): array
{
return [
self::PRIMARY_CONTEXT_TENANT,
self::PRIMARY_CONTEXT_OPERATION_RUN,
];
}
/**
* @return list<string>
*/
public static function attachmentModes(): array
{
return [
self::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED,
self::ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY,
];
}
/**
* @return BelongsTo<Workspace, $this>
*/
public function workspace(): BelongsTo
{
return $this->belongsTo(Workspace::class);
}
/**
* @return BelongsTo<Tenant, $this>
*/
public function tenant(): BelongsTo
{
return $this->belongsTo(Tenant::class);
}
/**
* @return BelongsTo<OperationRun, $this>
*/
public function operationRun(): BelongsTo
{
return $this->belongsTo(OperationRun::class);
}
/**
* @return BelongsTo<User, $this>
*/
public function initiator(): BelongsTo
{
return $this->belongsTo(User::class, 'initiated_by_user_id');
}
}

View File

@ -4,10 +4,9 @@
namespace App\Services\Audit;
use App\Models\Tenant;
use App\Models\OperationRun;
use App\Models\PlatformUser;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use App\Models\Workspace;
use App\Support\Audit\AuditActionId;
@ -15,7 +14,6 @@
use App\Support\Audit\AuditActorType;
use App\Support\Audit\AuditTargetSnapshot;
use Carbon\CarbonImmutable;
use InvalidArgumentException;
class WorkspaceAuditLogger
{
@ -138,39 +136,4 @@ public function logSupportDiagnosticsOpened(
tenant: $tenant,
);
}
public function logSupportRequestCreated(
SupportRequest $supportRequest,
User|PlatformUser|null $actor = null,
): \App\Models\AuditLog {
$supportRequest->loadMissing(['tenant.workspace']);
$tenant = $supportRequest->tenant;
if (! $tenant instanceof Tenant) {
throw new InvalidArgumentException('Support requests must belong to a tenant.');
}
return $this->log(
workspace: $tenant->workspace,
action: AuditActionId::SupportRequestCreated,
context: [
'internal_reference' => $supportRequest->internal_reference,
'primary_context_type' => $supportRequest->primary_context_type,
'primary_context_id' => $supportRequest->primary_context_type === SupportRequest::PRIMARY_CONTEXT_OPERATION_RUN
? (string) $supportRequest->operation_run_id
: (string) $tenant->getKey(),
'attachment_mode' => $supportRequest->attachment_mode,
'redaction_mode' => (string) data_get($supportRequest->context_envelope, 'redaction_mode', 'default_redacted'),
],
actor: $actor,
status: 'success',
resourceType: 'support_request',
resourceId: (string) $supportRequest->getKey(),
targetLabel: $supportRequest->internal_reference,
summary: 'Support request created for '.$supportRequest->internal_reference,
operationRunId: $supportRequest->operation_run_id !== null ? (int) $supportRequest->operation_run_id : null,
tenant: $tenant,
);
}
}

View File

@ -20,7 +20,6 @@ class RoleCapabilityMap
Capabilities::TENANT_DELETE,
Capabilities::TENANT_SYNC,
Capabilities::SUPPORT_DIAGNOSTICS_VIEW,
Capabilities::SUPPORT_REQUESTS_CREATE,
Capabilities::TENANT_INVENTORY_SYNC_RUN,
Capabilities::TENANT_FINDINGS_VIEW,
Capabilities::TENANT_FINDINGS_TRIAGE,
@ -66,7 +65,6 @@ class RoleCapabilityMap
Capabilities::TENANT_MANAGE,
Capabilities::TENANT_SYNC,
Capabilities::SUPPORT_DIAGNOSTICS_VIEW,
Capabilities::SUPPORT_REQUESTS_CREATE,
Capabilities::TENANT_INVENTORY_SYNC_RUN,
Capabilities::TENANT_FINDINGS_VIEW,
Capabilities::TENANT_FINDINGS_TRIAGE,
@ -108,7 +106,6 @@ class RoleCapabilityMap
Capabilities::TENANT_VIEW,
Capabilities::TENANT_SYNC,
Capabilities::SUPPORT_DIAGNOSTICS_VIEW,
Capabilities::SUPPORT_REQUESTS_CREATE,
Capabilities::TENANT_INVENTORY_SYNC_RUN,
Capabilities::TENANT_FINDINGS_VIEW,
Capabilities::TENANT_FINDINGS_TRIAGE,

View File

@ -100,7 +100,6 @@ enum AuditActionId: string
case TenantTriageReviewMarkedFollowUpNeeded = 'tenant_triage_review.marked_follow_up_needed';
case SupportDiagnosticsOpened = 'support_diagnostics.opened';
case SupportRequestCreated = 'support_request.created';
case OperationalControlPaused = 'operational_control.paused';
case OperationalControlUpdated = 'operational_control.updated';
case OperationalControlResumed = 'operational_control.resumed';
@ -242,7 +241,6 @@ private static function labels(): array
self::TenantTriageReviewMarkedReviewed->value => 'Triage review marked reviewed',
self::TenantTriageReviewMarkedFollowUpNeeded->value => 'Triage review marked follow-up needed',
self::SupportDiagnosticsOpened->value => 'Support diagnostics opened',
self::SupportRequestCreated->value => 'Support request created',
self::OperationalControlPaused->value => 'Operational control paused',
self::OperationalControlUpdated->value => 'Operational control updated',
self::OperationalControlResumed->value => 'Operational control resumed',
@ -329,7 +327,6 @@ private static function summaries(): array
self::TenantReviewExported->value => 'Tenant review exported',
self::TenantReviewSuccessorCreated->value => 'Tenant review next cycle created',
self::SupportDiagnosticsOpened->value => 'Support diagnostics opened',
self::SupportRequestCreated->value => 'Support request created',
self::OperationalControlPaused->value => 'Operational control paused',
self::OperationalControlUpdated->value => 'Operational control updated',
self::OperationalControlResumed->value => 'Operational control resumed',

View File

@ -72,9 +72,6 @@ class Capabilities
// Support diagnostics
public const SUPPORT_DIAGNOSTICS_VIEW = 'support_diagnostics.view';
// Support requests
public const SUPPORT_REQUESTS_CREATE = 'support_requests.create';
// Inventory
public const TENANT_INVENTORY_SYNC_RUN = 'tenant_inventory_sync.run';

View File

@ -1,129 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Support\SupportRequests;
use App\Models\OperationRun;
use App\Models\Tenant;
use App\Models\User;
use App\Support\SupportDiagnostics\SupportDiagnosticBundleBuilder;
final class SupportRequestContextBuilder
{
public const ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED = 'diagnostic_snapshot_attached';
public const ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY = 'canonical_context_only';
public function __construct(
private readonly SupportDiagnosticBundleBuilder $supportDiagnosticBundleBuilder,
) {}
/**
* @return array<string, mixed>
*/
public function forTenant(Tenant $tenant, User $actor, bool $attachDiagnosticSnapshot): array
{
return $this->buildEnvelope(
bundle: $this->supportDiagnosticBundleBuilder->forTenant($tenant, $actor),
attachDiagnosticSnapshot: $attachDiagnosticSnapshot,
);
}
/**
* @return array<string, mixed>
*/
public function forOperationRun(OperationRun $run, User $actor, bool $attachDiagnosticSnapshot): array
{
return $this->buildEnvelope(
bundle: $this->supportDiagnosticBundleBuilder->forOperationRun($run, $actor),
attachDiagnosticSnapshot: $attachDiagnosticSnapshot,
);
}
/**
* @param array<string, mixed> $bundle
* @return array<string, mixed>
*/
private function buildEnvelope(array $bundle, bool $attachDiagnosticSnapshot): array
{
$attachmentMode = $attachDiagnosticSnapshot
? self::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED
: self::ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY;
return [
'schema_version' => 1,
'generated_from' => 'support_diagnostics_bundle',
'attachment_mode' => $attachmentMode,
'redaction_mode' => (string) data_get($bundle, 'redaction.mode', 'default_redacted'),
'primary_context' => [
'type' => (string) data_get($bundle, 'context.type'),
'workspace_id' => data_get($bundle, 'context.workspace_id'),
'tenant_id' => data_get($bundle, 'context.tenant_id'),
'operation_run_id' => data_get($bundle, 'context.operation_run_id'),
'workspace_label' => data_get($bundle, 'context.workspace_label'),
'tenant_label' => data_get($bundle, 'context.tenant_label'),
],
'canonical_context' => [
'headline' => (string) data_get($bundle, 'summary.headline', data_get($bundle, 'headline')),
'dominant_issue' => (string) data_get($bundle, 'summary.dominant_issue', data_get($bundle, 'dominant_issue')),
'freshness_state' => (string) data_get($bundle, 'freshness_state'),
'completeness_note' => data_get($bundle, 'summary.completeness_note'),
'redaction_note' => data_get($bundle, 'summary.redaction_note'),
'context' => data_get($bundle, 'context', []),
'tenant' => data_get($bundle, 'tenant'),
'operation_run' => data_get($bundle, 'operation_run'),
'sections' => $this->canonicalSections($bundle),
'notes' => is_array($bundle['notes'] ?? null)
? array_values($bundle['notes'])
: [],
],
'diagnostic_snapshot' => $attachDiagnosticSnapshot
? [
'contextual_help' => data_get($bundle, 'contextual_help'),
'sections' => is_array($bundle['sections'] ?? null)
? array_values($bundle['sections'])
: [],
'redaction' => is_array($bundle['redaction'] ?? null)
? $bundle['redaction']
: [],
'notes' => is_array($bundle['notes'] ?? null)
? array_values($bundle['notes'])
: [],
]
: null,
'omissions' => $attachDiagnosticSnapshot
? []
: [[
'type' => 'diagnostic_snapshot',
'reason' => 'omitted_without_support_diagnostics_view',
'message' => 'Redacted diagnostic evidence was omitted because the creator could not view support diagnostics.',
]],
];
}
/**
* @param array<string, mixed> $bundle
* @return list<array<string, mixed>>
*/
private function canonicalSections(array $bundle): array
{
if (! is_array($bundle['sections'] ?? null)) {
return [];
}
return array_values(array_map(
static fn (array $section): array => [
'key' => (string) ($section['key'] ?? ''),
'label' => (string) ($section['label'] ?? ''),
'availability' => (string) ($section['availability'] ?? 'missing'),
'summary' => (string) ($section['summary'] ?? ''),
'freshness_note' => $section['freshness_note'] ?? null,
'references' => is_array($section['references'] ?? null)
? array_values($section['references'])
: [],
],
$bundle['sections'],
));
}
}

View File

@ -1,15 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Support\SupportRequests;
use Illuminate\Support\Str;
final class SupportRequestReferenceGenerator
{
public function generate(): string
{
return 'SR-'.strtoupper((string) Str::ulid());
}
}

View File

@ -1,186 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Support\SupportRequests;
use App\Models\OperationRun;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use App\Services\Audit\WorkspaceAuditLogger;
use App\Services\Auth\CapabilityResolver;
use App\Support\Auth\Capabilities;
use Illuminate\Validation\Rule;
use Illuminate\Validation\ValidationException;
final class SupportRequestSubmissionService
{
public function __construct(
private readonly CapabilityResolver $capabilityResolver,
private readonly SupportRequestContextBuilder $supportRequestContextBuilder,
private readonly SupportRequestReferenceGenerator $supportRequestReferenceGenerator,
private readonly WorkspaceAuditLogger $workspaceAuditLogger,
) {}
/**
* @param array<string, mixed> $data
*/
public function submitForTenant(Tenant $tenant, User $actor, array $data): SupportRequest
{
$this->authorizeCreation($tenant, $actor);
return $this->submit(
tenant: $tenant,
actor: $actor,
data: $data,
primaryContextType: SupportRequest::PRIMARY_CONTEXT_TENANT,
operationRun: null,
);
}
/**
* @param array<string, mixed> $data
*/
public function submitForOperationRun(OperationRun $run, User $actor, array $data): SupportRequest
{
$run->loadMissing('tenant.workspace');
$tenant = $run->tenant;
if (! $tenant instanceof Tenant) {
abort(404);
}
$this->authorizeCreation($tenant, $actor);
return $this->submit(
tenant: $tenant,
actor: $actor,
data: $data,
primaryContextType: SupportRequest::PRIMARY_CONTEXT_OPERATION_RUN,
operationRun: $run,
);
}
private function authorizeCreation(Tenant $tenant, User $actor): void
{
if (! $this->capabilityResolver->isMember($actor, $tenant)) {
abort(404);
}
if (! $this->capabilityResolver->can($actor, $tenant, Capabilities::SUPPORT_REQUESTS_CREATE)) {
abort(403);
}
}
/**
* @param array<string, mixed> $data
*/
private function submit(
Tenant $tenant,
User $actor,
array $data,
string $primaryContextType,
?OperationRun $operationRun,
): SupportRequest {
$validated = $this->validate($data);
$attachDiagnosticSnapshot = $this->capabilityResolver->can($actor, $tenant, Capabilities::SUPPORT_DIAGNOSTICS_VIEW);
$contextEnvelope = $operationRun instanceof OperationRun
? $this->supportRequestContextBuilder->forOperationRun($operationRun, $actor, $attachDiagnosticSnapshot)
: $this->supportRequestContextBuilder->forTenant($tenant, $actor, $attachDiagnosticSnapshot);
$contactName = $validated['contact_name'] ?? $this->normalizeNullableString($actor->name) ?? $this->normalizeNullableString($actor->email);
$contactEmail = $validated['contact_email'] ?? $this->normalizeNullableString($actor->email);
$connection = SupportRequest::query()->getModel()->getConnection();
return $connection->transaction(function () use (
$actor,
$contactEmail,
$contactName,
$contextEnvelope,
$operationRun,
$primaryContextType,
$tenant,
$validated,
): SupportRequest {
$supportRequest = SupportRequest::query()->create([
'workspace_id' => (int) $tenant->workspace_id,
'tenant_id' => (int) $tenant->getKey(),
'operation_run_id' => $operationRun instanceof OperationRun ? (int) $operationRun->getKey() : null,
'initiated_by_user_id' => (int) $actor->getKey(),
'internal_reference' => $this->supportRequestReferenceGenerator->generate(),
'primary_context_type' => $primaryContextType,
'attachment_mode' => (string) data_get($contextEnvelope, 'attachment_mode', SupportRequest::ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY),
'severity' => $validated['severity'],
'summary' => $validated['summary'],
'reproduction_notes' => $validated['reproduction_notes'],
'contact_name' => $contactName,
'contact_email' => $contactEmail,
'context_envelope' => $contextEnvelope,
]);
$supportRequest->loadMissing(['tenant.workspace']);
$this->workspaceAuditLogger->logSupportRequestCreated($supportRequest, $actor);
return $supportRequest;
});
}
/**
* @param array<string, mixed> $data
* @return array{
* severity: string,
* summary: string,
* reproduction_notes: ?string,
* contact_name: ?string,
* contact_email: ?string,
* }
*/
private function validate(array $data): array
{
$validated = validator(
[
'severity' => $data['severity'] ?? SupportRequest::SEVERITY_NORMAL,
'summary' => $data['summary'] ?? null,
'reproduction_notes' => $data['reproduction_notes'] ?? null,
'contact_name' => $data['contact_name'] ?? null,
'contact_email' => $data['contact_email'] ?? null,
],
[
'severity' => ['required', 'string', Rule::in(SupportRequest::severityValues())],
'summary' => ['required', 'string'],
'reproduction_notes' => ['nullable', 'string'],
'contact_name' => ['nullable', 'string'],
'contact_email' => ['nullable', 'email'],
],
)->validate();
$validated['summary'] = trim((string) $validated['summary']);
if ($validated['summary'] === '') {
throw ValidationException::withMessages([
'summary' => 'The summary field is required.',
]);
}
$validated['reproduction_notes'] = $this->normalizeNullableString($validated['reproduction_notes'] ?? null);
$validated['contact_name'] = $this->normalizeNullableString($validated['contact_name'] ?? null);
$validated['contact_email'] = $this->normalizeNullableString($validated['contact_email'] ?? null);
return $validated;
}
private function normalizeNullableString(mixed $value): ?string
{
if (! is_string($value)) {
return null;
}
$normalized = trim($value);
return $normalized === '' ? null : $normalized;
}
}

View File

@ -1,98 +0,0 @@
<?php
declare(strict_types=1);
namespace Database\Factories;
use App\Models\OperationRun;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use Illuminate\Database\Eloquent\Factories\Factory;
use Illuminate\Support\Str;
/**
* @extends \Illuminate\Database\Eloquent\Factories\Factory<\App\Models\SupportRequest>
*/
class SupportRequestFactory extends Factory
{
protected $model = SupportRequest::class;
/**
* Define the model's default state.
*
* @return array<string, mixed>
*/
public function definition(): array
{
return [
'tenant_id' => Tenant::factory(),
'initiated_by_user_id' => User::factory(),
'internal_reference' => 'SR-'.strtoupper((string) Str::ulid()),
'primary_context_type' => SupportRequest::PRIMARY_CONTEXT_TENANT,
'attachment_mode' => SupportRequest::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED,
'severity' => SupportRequest::SEVERITY_NORMAL,
'summary' => fake()->sentence(),
'reproduction_notes' => fake()->optional()->paragraph(),
'contact_name' => fake()->name(),
'contact_email' => fake()->safeEmail(),
'context_envelope' => [
'schema_version' => 1,
'generated_from' => 'factory',
'attachment_mode' => SupportRequest::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED,
'primary_context' => [
'type' => SupportRequest::PRIMARY_CONTEXT_TENANT,
],
'canonical_context' => [
'sections' => [],
],
'diagnostic_snapshot' => [
'sections' => [],
],
'omissions' => [],
],
];
}
public function canonicalContextOnly(): static
{
return $this->state(fn (array $attributes): array => [
'attachment_mode' => SupportRequest::ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY,
'context_envelope' => array_replace_recursive($attributes['context_envelope'] ?? [], [
'attachment_mode' => SupportRequest::ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY,
'diagnostic_snapshot' => null,
'omissions' => [[
'type' => 'diagnostic_snapshot',
'reason' => 'omitted_without_support_diagnostics_view',
]],
]),
]);
}
public function forOperationRun(OperationRun $operationRun): static
{
return $this->state(fn (): array => [
'tenant_id' => (int) $operationRun->tenant_id,
'workspace_id' => (int) $operationRun->workspace_id,
'operation_run_id' => (int) $operationRun->getKey(),
'primary_context_type' => SupportRequest::PRIMARY_CONTEXT_OPERATION_RUN,
'context_envelope' => [
'schema_version' => 1,
'generated_from' => 'factory',
'attachment_mode' => SupportRequest::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED,
'primary_context' => [
'type' => SupportRequest::PRIMARY_CONTEXT_OPERATION_RUN,
'tenant_id' => (int) $operationRun->tenant_id,
'operation_run_id' => (int) $operationRun->getKey(),
],
'canonical_context' => [
'sections' => [],
],
'diagnostic_snapshot' => [
'sections' => [],
],
'omissions' => [],
],
]);
}
}

View File

@ -1,46 +0,0 @@
<?php
declare(strict_types=1);
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
return new class extends Migration
{
/**
* Run the migrations.
*/
public function up(): void
{
Schema::create('support_requests', function (Blueprint $table): void {
$table->id();
$table->foreignId('workspace_id')->constrained('workspaces')->cascadeOnDelete();
$table->foreignId('tenant_id')->constrained('tenants')->cascadeOnDelete();
$table->foreignId('operation_run_id')->nullable()->constrained('operation_runs')->nullOnDelete();
$table->foreignId('initiated_by_user_id')->nullable()->constrained('users')->nullOnDelete();
$table->string('internal_reference')->unique();
$table->string('primary_context_type');
$table->string('attachment_mode');
$table->string('severity');
$table->text('summary');
$table->text('reproduction_notes')->nullable();
$table->string('contact_name')->nullable();
$table->string('contact_email')->nullable();
$table->jsonb('context_envelope')->default('{}');
$table->timestamps();
$table->index(['workspace_id', 'tenant_id']);
$table->index(['tenant_id', 'created_at']);
$table->index(['operation_run_id', 'created_at']);
});
}
/**
* Reverse the migrations.
*/
public function down(): void
{
Schema::dropIfExists('support_requests');
}
};

View File

@ -1,166 +0,0 @@
<?php
declare(strict_types=1);
use App\Filament\Pages\Operations\TenantlessOperationRunViewer;
use App\Models\OperationRun;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use App\Models\Workspace;
use App\Models\WorkspaceMembership;
use App\Support\OperationRunLinks;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\OperationRunType;
use App\Support\Workspaces\WorkspaceContext;
use Filament\Actions\Action;
use Filament\Actions\ActionGroup;
use Filament\Facades\Filament;
use Livewire\Livewire;
uses(\Illuminate\Foundation\Testing\RefreshDatabase::class);
function operationSupportRequestComponent(User $user, OperationRun $run): \Livewire\Features\SupportTesting\Testable
{
test()->actingAs($user);
Filament::setTenant(null, true);
session()->put(WorkspaceContext::SESSION_KEY, (int) $run->workspace_id);
return Livewire::actingAs($user)->test(TenantlessOperationRunViewer::class, ['run' => $run]);
}
function operationSupportRequestHeaderActions(\Livewire\Features\SupportTesting\Testable $component): array
{
$instance = $component->instance();
if ($instance->getCachedHeaderActions() === []) {
$instance->cacheInteractsWithHeaderActions();
}
return $instance->getCachedHeaderActions();
}
function operationSupportRequestHeaderPrimaryNames(\Livewire\Features\SupportTesting\Testable $component): array
{
return collect(operationSupportRequestHeaderActions($component))
->reject(static fn ($action): bool => $action instanceof ActionGroup)
->map(static fn ($action): ?string => $action instanceof Action ? $action->getName() : null)
->filter()
->values()
->all();
}
function operationSupportRequestHeaderMoreActionNames(\Livewire\Features\SupportTesting\Testable $component): array
{
$moreGroup = collect(operationSupportRequestHeaderActions($component))
->first(static fn ($action): bool => $action instanceof ActionGroup && $action->getLabel() === 'More');
return collect($moreGroup?->getActions() ?? [])
->map(static fn ($action): ?string => $action instanceof Action ? $action->getName() : null)
->filter()
->values()
->all();
}
function operationSupportRequestHeaderMoreAction(\Livewire\Features\SupportTesting\Testable $component, string $name): ?Action
{
$moreGroup = collect(operationSupportRequestHeaderActions($component))
->first(static fn ($action): bool => $action instanceof ActionGroup && $action->getLabel() === 'More');
$action = collect($moreGroup?->getActions() ?? [])
->first(static fn ($action): bool => $action instanceof Action && $action->getName() === $name);
return $action instanceof Action ? $action : null;
}
it('creates a run-scoped support request from the tenantless operation viewer', function (): void {
$tenant = Tenant::factory()->create(['name' => 'Contoso Support Tenant']);
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'operator');
$run = OperationRun::factory()
->forTenant($tenant)
->create([
'type' => OperationRunType::BaselineCompare->value,
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Failed->value,
'summary_counts' => [
'total' => 0,
'processed' => 0,
],
'failure_summary' => [[
'message' => 'Run failed after provider validation.',
]],
'completed_at' => now()->subMinutes(10),
]);
$component = operationSupportRequestComponent($user, $run);
expect(operationSupportRequestHeaderPrimaryNames($component))
->not->toContain('openSupportDiagnostics')
->not->toContain('requestSupport')
->and(operationSupportRequestHeaderMoreActionNames($component))
->toEqualCanonicalizing(['openSupportDiagnostics', 'requestSupport'])
->and(operationSupportRequestHeaderMoreAction($component, 'openSupportDiagnostics')?->isIconButton())
->toBeFalse();
$component
->assertActionVisible('openSupportDiagnostics')
->assertActionEnabled('openSupportDiagnostics')
->assertActionVisible('requestSupport')
->assertActionEnabled('requestSupport')
->assertActionExists('requestSupport', fn (Action $action): bool => $action->getLabel() === 'Request support')
->mountAction('requestSupport')
->setActionData([
'severity' => SupportRequest::SEVERITY_BLOCKING,
'summary' => 'This failed operation needs support escalation.',
'reproduction_notes' => 'Open the canonical run detail and submit the request from the grouped secondary action.',
])
->callMountedAction()
->assertHasNoActionErrors()
->assertNotified('Support request submitted');
$supportRequest = SupportRequest::query()->sole();
expect($supportRequest->internal_reference)->toMatch('/^SR-[0-9A-HJKMNP-TV-Z]{26}$/')
->and($supportRequest->workspace_id)->toBe((int) $tenant->workspace_id)
->and($supportRequest->tenant_id)->toBe((int) $tenant->getKey())
->and($supportRequest->initiated_by_user_id)->toBe((int) $user->getKey())
->and($supportRequest->primary_context_type)->toBe(SupportRequest::PRIMARY_CONTEXT_OPERATION_RUN)
->and($supportRequest->operation_run_id)->toBe((int) $run->getKey())
->and($supportRequest->attachment_mode)->toBe(SupportRequest::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED)
->and($supportRequest->severity)->toBe(SupportRequest::SEVERITY_BLOCKING)
->and($supportRequest->summary)->toBe('This failed operation needs support escalation.')
->and(data_get($supportRequest->context_envelope, 'primary_context.type'))->toBe('operation_run')
->and(data_get($supportRequest->context_envelope, 'primary_context.operation_run_id'))->toBe((int) $run->getKey())
->and(data_get($supportRequest->context_envelope, 'diagnostic_snapshot'))->toBeArray();
});
it('keeps tenantless operation detail deny-as-not-found for workspace members without tenant entitlement', function (): void {
$workspace = Workspace::factory()->create();
$tenant = Tenant::factory()->create([
'workspace_id' => (int) $workspace->getKey(),
]);
$user = User::factory()->create();
WorkspaceMembership::factory()->create([
'workspace_id' => (int) $workspace->getKey(),
'user_id' => (int) $user->getKey(),
'role' => 'owner',
]);
$run = OperationRun::factory()->create([
'tenant_id' => (int) $tenant->getKey(),
'workspace_id' => (int) $workspace->getKey(),
'type' => OperationRunType::BaselineCompare->value,
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Succeeded->value,
'completed_at' => now(),
]);
$this->actingAs($user)
->withSession([WorkspaceContext::SESSION_KEY => (int) $workspace->getKey()])
->get(route('admin.operations.view', ['run' => (int) $run->getKey()]))
->assertNotFound();
});

View File

@ -1,204 +0,0 @@
<?php
declare(strict_types=1);
use App\Filament\Pages\Operations\TenantlessOperationRunViewer;
use App\Filament\Pages\TenantDashboard;
use App\Models\AuditLog;
use App\Models\OperationRun;
use App\Models\ProviderConnection;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use App\Support\Audit\AuditActionId;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\OperationRunType;
use App\Support\Providers\ProviderReasonCodes;
use App\Support\Providers\ProviderVerificationStatus;
use App\Support\Workspaces\WorkspaceContext;
use Filament\Facades\Filament;
use Livewire\Livewire;
uses(\Illuminate\Foundation\Testing\RefreshDatabase::class);
function supportRequestAuditTenantComponent(User $user, Tenant $tenant): \Livewire\Features\SupportTesting\Testable
{
test()->actingAs($user);
session()->put(WorkspaceContext::SESSION_KEY, (int) $tenant->workspace_id);
setTenantPanelContext($tenant);
return Livewire::actingAs($user)->test(TenantDashboard::class);
}
function supportRequestAuditOperationComponent(User $user, OperationRun $run): \Livewire\Features\SupportTesting\Testable
{
test()->actingAs($user);
Filament::setTenant(null, true);
session()->put(WorkspaceContext::SESSION_KEY, (int) $run->workspace_id);
return Livewire::actingAs($user)->test(TenantlessOperationRunViewer::class, ['run' => $run]);
}
it('records a redacted audit entry for tenant-scoped support requests', function (): void {
$tenant = Tenant::factory()->create(['name' => 'Audit Support Tenant']);
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'owner');
ProviderConnection::factory()
->withCredential()
->create([
'tenant_id' => (int) $tenant->getKey(),
'workspace_id' => (int) $tenant->workspace_id,
'display_name' => 'Audit Microsoft connection',
'verification_status' => ProviderVerificationStatus::Blocked->value,
'last_error_reason_code' => ProviderReasonCodes::ProviderPermissionMissing,
'last_error_message' => 'tenant-provider-secret',
]);
supportRequestAuditTenantComponent($user, $tenant)
->mountAction('requestSupport')
->setActionData([
'severity' => SupportRequest::SEVERITY_HIGH,
'summary' => 'Need tenant support audit proof.',
])
->callMountedAction()
->assertHasNoActionErrors();
$supportRequest = SupportRequest::query()->sole();
$audit = AuditLog::query()
->where('action', AuditActionId::SupportRequestCreated->value)
->latest('id')
->first();
expect($audit)->not->toBeNull()
->and($audit?->workspace_id)->toBe((int) $tenant->workspace_id)
->and($audit?->tenant_id)->toBe((int) $tenant->getKey())
->and($audit?->resource_type)->toBe('support_request')
->and($audit?->resource_id)->toBe((string) $supportRequest->getKey())
->and($audit?->target_label)->toBe($supportRequest->internal_reference)
->and($audit?->operation_run_id)->toBeNull()
->and(data_get($audit?->metadata, 'internal_reference'))->toBe($supportRequest->internal_reference)
->and(data_get($audit?->metadata, 'primary_context_type'))->toBe(SupportRequest::PRIMARY_CONTEXT_TENANT)
->and(data_get($audit?->metadata, 'primary_context_id'))->toBe((string) $tenant->getKey())
->and(data_get($audit?->metadata, 'attachment_mode'))->toBe(SupportRequest::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED)
->and(data_get($audit?->metadata, 'redaction_mode'))->toBe('default_redacted')
->and((string) json_encode($audit?->metadata))->not->toContain('tenant-provider-secret');
});
it('records a redacted audit entry for run-scoped support requests', function (): void {
$tenant = Tenant::factory()->create();
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'operator');
$run = OperationRun::factory()->create([
'tenant_id' => (int) $tenant->getKey(),
'workspace_id' => (int) $tenant->workspace_id,
'type' => OperationRunType::BaselineCompare->value,
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Failed->value,
'summary_counts' => [
'total' => 0,
'processed' => 0,
],
'context' => [
'raw_response_body' => 'run-provider-secret',
],
'failure_summary' => [[
'message' => 'Run failed after provider validation.',
]],
'completed_at' => now(),
]);
supportRequestAuditOperationComponent($user, $run)
->mountAction('requestSupport')
->setActionData([
'severity' => SupportRequest::SEVERITY_BLOCKING,
'summary' => 'Need run support audit proof.',
])
->callMountedAction()
->assertHasNoActionErrors();
$supportRequest = SupportRequest::query()->sole();
$audit = AuditLog::query()
->where('action', AuditActionId::SupportRequestCreated->value)
->latest('id')
->first();
expect($audit)->not->toBeNull()
->and($audit?->workspace_id)->toBe((int) $tenant->workspace_id)
->and($audit?->tenant_id)->toBe((int) $tenant->getKey())
->and($audit?->resource_type)->toBe('support_request')
->and($audit?->resource_id)->toBe((string) $supportRequest->getKey())
->and($audit?->target_label)->toBe($supportRequest->internal_reference)
->and($audit?->operation_run_id)->toBe((int) $run->getKey())
->and(data_get($audit?->metadata, 'internal_reference'))->toBe($supportRequest->internal_reference)
->and(data_get($audit?->metadata, 'primary_context_type'))->toBe(SupportRequest::PRIMARY_CONTEXT_OPERATION_RUN)
->and(data_get($audit?->metadata, 'primary_context_id'))->toBe((string) $run->getKey())
->and(data_get($audit?->metadata, 'attachment_mode'))->toBe(SupportRequest::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED)
->and(data_get($audit?->metadata, 'redaction_mode'))->toBe('default_redacted')
->and((string) json_encode($audit?->metadata))->not->toContain('run-provider-secret');
});
it('creates distinct support references for duplicate submissions without outbound http or operation-run side effects', function (): void {
$tenant = Tenant::factory()->create();
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'operator');
$run = OperationRun::factory()->create([
'tenant_id' => (int) $tenant->getKey(),
'workspace_id' => (int) $tenant->workspace_id,
'type' => OperationRunType::BaselineCompare->value,
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Failed->value,
'summary_counts' => [
'total' => 0,
'processed' => 0,
],
'failure_summary' => [[
'message' => 'Run failed after provider validation.',
]],
'completed_at' => now(),
]);
$component = supportRequestAuditOperationComponent($user, $run);
$existingRunCount = OperationRun::query()->count();
assertNoOutboundHttp(function () use ($component): void {
$component
->mountAction('requestSupport')
->setActionData([
'severity' => SupportRequest::SEVERITY_HIGH,
'summary' => 'Duplicate run support request.',
])
->callMountedAction()
->assertHasNoActionErrors()
->mountAction('requestSupport')
->setActionData([
'severity' => SupportRequest::SEVERITY_HIGH,
'summary' => 'Duplicate run support request.',
])
->callMountedAction()
->assertHasNoActionErrors();
});
$supportRequests = SupportRequest::query()
->orderBy('id')
->get();
$auditReferences = AuditLog::query()
->where('action', AuditActionId::SupportRequestCreated->value)
->orderBy('id')
->pluck('target_label');
expect($supportRequests)->toHaveCount(2)
->and($supportRequests->pluck('summary')->all())->toBe([
'Duplicate run support request.',
'Duplicate run support request.',
])
->and($supportRequests->pluck('internal_reference')->unique())->toHaveCount(2)
->and($supportRequests->pluck('operation_run_id')->unique()->all())->toBe([(int) $run->getKey()])
->and($auditReferences->all())->toBe($supportRequests->pluck('internal_reference')->all())
->and(OperationRun::query()->count())->toBe($existingRunCount)
->and($run->fresh()?->status)->toBe(OperationRunStatus::Completed->value)
->and($run->fresh()?->outcome)->toBe(OperationRunOutcome::Failed->value);
});

View File

@ -1,75 +0,0 @@
<?php
declare(strict_types=1);
use App\Filament\Pages\Operations\TenantlessOperationRunViewer;
use App\Filament\Pages\TenantDashboard;
use App\Models\OperationRun;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\OperationRunType;
use App\Support\Workspaces\WorkspaceContext;
use Filament\Facades\Filament;
use Livewire\Livewire;
uses(\Illuminate\Foundation\Testing\RefreshDatabase::class);
function supportRequestAuthorizationTenantComponent(User $user, Tenant $tenant): \Livewire\Features\SupportTesting\Testable
{
test()->actingAs($user);
session()->put(WorkspaceContext::SESSION_KEY, (int) $tenant->workspace_id);
setTenantPanelContext($tenant);
return Livewire::actingAs($user)->test(TenantDashboard::class);
}
function supportRequestAuthorizationOperationComponent(User $user, OperationRun $run): \Livewire\Features\SupportTesting\Testable
{
test()->actingAs($user);
Filament::setTenant(null, true);
session()->put(WorkspaceContext::SESSION_KEY, (int) $run->workspace_id);
return Livewire::actingAs($user)->test(TenantlessOperationRunViewer::class, ['run' => $run]);
}
it('returns forbidden for entitled tenant members without support request capability', function (): void {
$tenant = Tenant::factory()->create();
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'readonly');
supportRequestAuthorizationTenantComponent($user, $tenant)
->assertActionVisible('requestSupport')
->assertActionDisabled('requestSupport')
->call('authorizeTenantSupportRequest')
->assertForbidden();
expect(SupportRequest::query()->count())->toBe(0);
});
it('returns forbidden for entitled run viewers without support request capability', function (): void {
$tenant = Tenant::factory()->create();
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'readonly');
$run = OperationRun::factory()->create([
'tenant_id' => (int) $tenant->getKey(),
'workspace_id' => (int) $tenant->workspace_id,
'type' => OperationRunType::BaselineCompare->value,
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Succeeded->value,
'summary_counts' => [
'total' => 0,
'processed' => 0,
],
'completed_at' => now(),
]);
supportRequestAuthorizationOperationComponent($user, $run)
->assertActionVisible('requestSupport')
->assertActionDisabled('requestSupport')
->call('authorizeOperationRunSupportRequest')
->assertForbidden();
expect(SupportRequest::query()->count())->toBe(0);
});

View File

@ -1,137 +0,0 @@
<?php
declare(strict_types=1);
use App\Filament\Pages\TenantDashboard;
use App\Models\SupportRequest;
use App\Models\Tenant;
use App\Models\User;
use App\Models\WorkspaceMembership;
use App\Services\Auth\CapabilityResolver;
use App\Support\Auth\Capabilities;
use App\Support\Workspaces\WorkspaceContext;
use Filament\Actions\Action;
use Livewire\Livewire;
use function Pest\Laravel\mock;
uses(\Illuminate\Foundation\Testing\RefreshDatabase::class);
function tenantSupportRequestComponent(User $user, Tenant $tenant): \Livewire\Features\SupportTesting\Testable
{
test()->actingAs($user);
session()->put(WorkspaceContext::SESSION_KEY, (int) $tenant->workspace_id);
setTenantPanelContext($tenant);
return Livewire::actingAs($user)->test(TenantDashboard::class);
}
it('creates a tenant support request from the dashboard', function (): void {
$tenant = Tenant::factory()->create(['name' => 'Contoso Support Tenant']);
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'owner');
tenantSupportRequestComponent($user, $tenant)
->assertActionVisible('requestSupport')
->assertActionEnabled('requestSupport')
->assertActionExists('requestSupport', fn (Action $action): bool => $action->getLabel() === 'Request support')
->mountAction('requestSupport')
->setActionData([
'severity' => SupportRequest::SEVERITY_HIGH,
'summary' => 'Policy sync failed after the latest tenant refresh.',
'reproduction_notes' => 'Open the tenant dashboard after a failed sync and request support from the header action.',
'contact_name' => 'Ops On Call',
'contact_email' => 'ops@example.test',
])
->callMountedAction()
->assertHasNoActionErrors()
->assertNotified('Support request submitted');
$supportRequest = SupportRequest::query()->sole();
expect($supportRequest->internal_reference)->toMatch('/^SR-[0-9A-HJKMNP-TV-Z]{26}$/')
->and($supportRequest->workspace_id)->toBe((int) $tenant->workspace_id)
->and($supportRequest->tenant_id)->toBe((int) $tenant->getKey())
->and($supportRequest->initiated_by_user_id)->toBe((int) $user->getKey())
->and($supportRequest->primary_context_type)->toBe(SupportRequest::PRIMARY_CONTEXT_TENANT)
->and($supportRequest->operation_run_id)->toBeNull()
->and($supportRequest->attachment_mode)->toBe(SupportRequest::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED)
->and($supportRequest->severity)->toBe(SupportRequest::SEVERITY_HIGH)
->and($supportRequest->summary)->toBe('Policy sync failed after the latest tenant refresh.')
->and($supportRequest->reproduction_notes)->toContain('failed sync')
->and($supportRequest->contact_name)->toBe('Ops On Call')
->and($supportRequest->contact_email)->toBe('ops@example.test')
->and(data_get($supportRequest->context_envelope, 'primary_context.type'))->toBe('tenant')
->and(data_get($supportRequest->context_envelope, 'primary_context.tenant_id'))->toBe((int) $tenant->getKey())
->and(data_get($supportRequest->context_envelope, 'diagnostic_snapshot'))->toBeArray();
});
it('stores canonical context only when the creator cannot view support diagnostics', function (): void {
$tenant = Tenant::factory()->create();
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'owner');
mock(CapabilityResolver::class, function ($mock) use ($tenant): void {
$mock->shouldReceive('primeMemberships')->andReturnNull();
$mock->shouldReceive('isMember')
->andReturnUsing(static fn ($user, Tenant $resolvedTenant): bool => (int) $resolvedTenant->getKey() === (int) $tenant->getKey());
$mock->shouldReceive('can')
->andReturnUsing(static function ($user, Tenant $resolvedTenant, string $capability) use ($tenant): bool {
expect((int) $resolvedTenant->getKey())->toBe((int) $tenant->getKey());
return match ($capability) {
Capabilities::SUPPORT_REQUESTS_CREATE => true,
Capabilities::SUPPORT_DIAGNOSTICS_VIEW => false,
default => true,
};
});
});
tenantSupportRequestComponent($user, $tenant)
->assertActionVisible('requestSupport')
->assertActionEnabled('requestSupport')
->mountAction('requestSupport')
->setActionData([
'summary' => 'Need help reviewing the latest tenant support context.',
])
->callMountedAction()
->assertHasNoActionErrors()
->assertNotified('Support request submitted');
$supportRequest = SupportRequest::query()->sole();
expect($supportRequest->severity)->toBe(SupportRequest::SEVERITY_NORMAL)
->and($supportRequest->contact_name)->toBe($user->name)
->and($supportRequest->contact_email)->toBe($user->email)
->and($supportRequest->attachment_mode)->toBe(SupportRequest::ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY)
->and(data_get($supportRequest->context_envelope, 'diagnostic_snapshot'))->toBeNull()
->and(data_get($supportRequest->context_envelope, 'omissions.0.reason'))->toBe('omitted_without_support_diagnostics_view');
});
it('keeps tenant dashboard support requests deny-as-not-found for workspace members without tenant entitlement', function (): void {
$tenant = Tenant::factory()->create();
$user = User::factory()->create();
WorkspaceMembership::factory()->create([
'workspace_id' => (int) $tenant->workspace_id,
'user_id' => (int) $user->getKey(),
'role' => 'operator',
]);
$this->actingAs($user)
->withSession([WorkspaceContext::SESSION_KEY => (int) $tenant->workspace_id])
->get(TenantDashboard::getUrl(panel: 'tenant', tenant: $tenant))
->assertNotFound();
});
it('returns forbidden for entitled tenant members without support request capability', function (): void {
$tenant = Tenant::factory()->create();
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'readonly');
tenantSupportRequestComponent($user, $tenant)
->assertActionVisible('requestSupport')
->assertActionDisabled('requestSupport')
->call('authorizeTenantSupportRequest')
->assertForbidden();
expect(SupportRequest::query()->count())->toBe(0);
});

View File

@ -1,130 +0,0 @@
<?php
declare(strict_types=1);
use App\Models\AuditLog;
use App\Models\OperationRun;
use App\Models\ProviderConnection;
use App\Models\StoredReport;
use App\Models\Tenant;
use App\Support\OperationRunOutcome;
use App\Support\OperationRunStatus;
use App\Support\OperationRunType;
use App\Support\Providers\ProviderReasonCodes;
use App\Support\Providers\ProviderVerificationStatus;
use App\Support\SupportRequests\SupportRequestContextBuilder;
use Illuminate\Foundation\Testing\RefreshDatabase;
uses(RefreshDatabase::class);
it('builds deterministic canonical context with omission markers when diagnostics are not attached', function (): void {
$tenant = Tenant::factory()->create(['name' => 'Omission Tenant']);
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'operator');
$builder = app(SupportRequestContextBuilder::class);
$first = $builder->forTenant($tenant, $user, false);
$second = $builder->forTenant($tenant->fresh(), $user, false);
$sections = collect($first['canonical_context']['sections'])->keyBy('key');
expect($first)
->toEqual($second)
->and($first['attachment_mode'])
->toBe(SupportRequestContextBuilder::ATTACHMENT_MODE_CANONICAL_CONTEXT_ONLY)
->and($first['diagnostic_snapshot'])
->toBeNull()
->and(data_get($first, 'primary_context.type'))
->toBe('tenant')
->and(data_get($first, 'omissions.0.reason'))
->toBe('omitted_without_support_diagnostics_view')
->and(data_get($sections->get('provider_connection'), 'references.0.label'))
->toBe('Provider connection not observed')
->and(data_get($sections->get('operation_context'), 'references.0.label'))
->toBe('Operation not yet observed')
->and(data_get($sections->get('audit_history'), 'references.0.label'))
->toBe('Audit event not yet observed');
});
it('attaches a redacted diagnostic snapshot without raw payload content', function (): void {
$tenant = Tenant::factory()->create(['name' => 'Redaction Tenant']);
[$user, $tenant] = createUserWithTenant(tenant: $tenant, role: 'operator');
$connection = ProviderConnection::factory()
->withCredential()
->create([
'tenant_id' => (int) $tenant->getKey(),
'workspace_id' => (int) $tenant->workspace_id,
'display_name' => 'Redaction Connection',
'verification_status' => ProviderVerificationStatus::Blocked->value,
'last_error_reason_code' => ProviderReasonCodes::ProviderPermissionMissing,
'last_error_message' => 'raw-provider-secret-message',
'last_health_check_at' => now()->subMinutes(15),
]);
$run = OperationRun::factory()
->forTenant($tenant)
->create([
'type' => OperationRunType::BaselineCompare->value,
'status' => OperationRunStatus::Completed->value,
'outcome' => OperationRunOutcome::Failed->value,
'summary_counts' => [
'total' => 0,
'processed' => 0,
],
'context' => [
'provider_connection_id' => (int) $connection->getKey(),
'raw_response_body' => 'secret-provider-body',
],
'failure_summary' => [[
'message' => 'Run failed after provider validation.',
]],
'completed_at' => now()->subMinutes(10),
]);
StoredReport::factory()->create([
'tenant_id' => (int) $tenant->getKey(),
'workspace_id' => (int) $tenant->workspace_id,
'report_type' => StoredReport::REPORT_TYPE_PERMISSION_POSTURE,
'payload' => [
'raw_response_body' => 'stored-report-secret-body',
],
]);
AuditLog::query()->create([
'workspace_id' => (int) $tenant->workspace_id,
'tenant_id' => (int) $tenant->getKey(),
'operation_run_id' => (int) $run->getKey(),
'action' => 'operation.failed',
'resource_type' => 'operation_run',
'resource_id' => (string) $run->getKey(),
'target_label' => 'Operation #'.$run->getKey(),
'metadata' => [
'raw_response_body' => 'audit-secret-body',
],
'outcome' => 'success',
'recorded_at' => now()->subMinutes(5),
]);
$builder = app(SupportRequestContextBuilder::class);
$envelope = $builder->forOperationRun($run, $user, true);
$encoded = json_encode($envelope, JSON_THROW_ON_ERROR);
expect($envelope['attachment_mode'])
->toBe(SupportRequestContextBuilder::ATTACHMENT_MODE_DIAGNOSTIC_SNAPSHOT_ATTACHED)
->and(data_get($envelope, 'primary_context.type'))
->toBe('operation_run')
->and(data_get($envelope, 'primary_context.operation_run_id'))
->toBe((int) $run->getKey())
->and(data_get($envelope, 'diagnostic_snapshot.redaction.mode'))
->toBe('default_redacted')
->and(data_get($envelope, 'diagnostic_snapshot.sections.0.key'))
->toBe('overview')
->and($encoded)
->not->toContain('raw-provider-secret-message')
->and($encoded)
->not->toContain('secret-provider-body')
->and($encoded)
->not->toContain('stored-report-secret-body')
->and($encoded)
->not->toContain('audit-secret-body');
});

View File

@ -1,19 +0,0 @@
<?php
declare(strict_types=1);
use App\Support\SupportRequests\SupportRequestReferenceGenerator;
it('generates unique uppercase support references', function (): void {
$generator = new SupportRequestReferenceGenerator();
$first = $generator->generate();
$second = $generator->generate();
expect($first)
->toMatch('/^SR-[0-9A-HJKMNP-TV-Z]{26}$/')
->and($second)
->toMatch('/^SR-[0-9A-HJKMNP-TV-Z]{26}$/')
->and($first)
->not->toBe($second);
});

View File

@ -1,59 +0,0 @@
# Specification Quality Checklist: In-App Support Request with Context
**Purpose**: Validate specification completeness and implementation readiness before the feature moves into the implementation loop
**Created**: 2026-04-27
**Feature**: [spec.md](../spec.md)
## Content Quality
- [x] Business value and operator outcomes stay explicit
- [x] The first slice is bounded to two existing support-aware entry surfaces plus one internal support reference only
- [x] Runtime-governance sections are present for an implementation-ready package
- [x] All mandatory sections are completed
## Requirement Completeness
- [x] No `[NEEDS CLARIFICATION]` markers remain
- [x] Requirements are testable and unambiguous
- [x] Acceptance scenarios are defined for the primary user journeys
- [x] Edge cases are identified, including reduced-attachment mode and missing related records
- [x] Scope is clearly bounded away from external ticketing, support inboxes, request lifecycle workflow, and customer-facing portals
- [x] Dependencies and assumptions are identified
## Feature Readiness
- [x] The first slice is small enough for a bounded implementation loop
- [x] The plan identifies concrete repo surfaces likely to change
- [x] The tasks are ordered, testable, and grouped by user story
- [x] Foundational work includes the persisted truth, capability gate, audit path, and shared context builder before surface wiring
- [x] No unresolved product question blocks safe implementation of the first slice
## Governance Readiness
- [x] New persisted support-request truth is explicitly justified and bounded
- [x] `SupportRequest` ownership is explicit as tenant-owned, with required not-null `workspace_id` and `tenant_id`
- [x] Support-request context remains provider-neutral and redaction-aware
- [x] Existing `/admin` authorization and tenant-safe 404 versus 403 boundaries remain authoritative
- [x] Operator-facing surface changes include the required UI contract sections and action matrix
- [x] External ticketing, status workflow, and support inbox surfaces are explicitly deferred
- [x] Livewire v4 compliance, unchanged provider registration location, no global-search changes, no destructive-action additions, and no asset-strategy changes are explicit in the package
## Test Governance Review
- [x] Lane fit stays in focused unit plus feature validation only and matches the plan
- [x] Fixture and helper growth stays local to the `SupportRequests` test namespace
- [x] No browser or heavy-governance family is introduced implicitly
- [x] Minimal validation commands are explicit in both the plan and the task list
- [x] The active feature PR close-out entry remains `Guardrail`
## Review Outcome
- [x] Review outcome class: `documentation-required-exception`
- [x] Workflow outcome: `document-in-feature`
- [x] Final note location: active feature PR close-out entry `Guardrail`
## Notes
- This checklist completes the implementation-ready package alongside `spec.md`, `plan.md`, and `tasks.md`.
- The active slice stops at structured request creation and internal reference generation. Any later ticket-provider adapter or lifecycle management remains a separate feature.
- Guardrail close-out: focused unit and feature validation passed, live browser smoke passed on both approved entry points, the tenant dashboard exemption remained bounded to two support-aware actions, and no provider-registration, global-search, destructive-action, or asset-strategy changes were introduced.

View File

@ -1,226 +0,0 @@
# Implementation Plan: In-App Support Request with Context
**Branch**: `246-support-request-context` | **Date**: 2026-04-27 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/spec.md`
**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/spec.md`
## Summary
- Add one bounded `SupportRequest` product truth that captures structured support intake from two existing support-aware surfaces: the tenant dashboard and the canonical operation detail viewer.
- Reuse the existing support-diagnostics bundle to attach a redacted, machine-readable context envelope when the creator is allowed to view diagnostics, and fall back to a safe canonical reference set when they are not.
- Keep the slice synchronous, Livewire v4-compatible, Filament v5-native, and free of external ticket adapters, `OperationRun` side effects, global-search changes, destructive actions, or asset changes.
## Technical Context
**Language/Version**: PHP 8.4 (Laravel 12)
**Primary Dependencies**: Laravel 12 + Filament v5 + Livewire v4 + Pest; existing `SupportDiagnosticBundleBuilder`, `WorkspaceAuditLogger`, `UiEnforcement`, `CapabilityResolver`, and canonical tenant/run support surfaces
**Storage**: PostgreSQL tenant-owned `support_requests` table with required not-null `workspace_id` and `tenant_id`, plus immutable redacted context JSON
**Testing**: Pest unit + feature tests
**Validation Lanes**: fast-feedback, confidence
**Target Platform**: Sail-backed Laravel admin panel under `/admin`
**Project Type**: web
**Performance Goals**: create the support request synchronously inside ordinary admin-request latency with no outbound HTTP and no background jobs
**Constraints**: no external ticketing provider, no support inbox or resource, no new system panel, no raw payload persistence, no `OperationRun`, and no asset changes
**Scale/Scope**: one migration, one model and factory, one bounded support-request context builder or submission service, one generated reference path, two header actions, and focused unit plus feature proof only
## First-Slice Request Contract
The first slice is locked to the following request shape:
1. **Primary contexts**: `tenant` and `operation_run` only
2. **Required submitted fields**: severity, summary, creator identity, workspace, tenant, primary context
3. **Severity values**:
- `low` = Low
- `normal` = Normal (default)
- `high` = High
- `blocking` = Blocking
4. **Optional submitted fields**: reproduction notes, contact name, contact email, attached diagnostic snapshot when allowed
5. **Attachment modes**:
- `diagnostic_snapshot_attached` when the creator also passes `support_diagnostics.view`
- `canonical_context_only` when the creator can create the request but cannot attach support diagnostics
6. **Duplicate submissions**: repeated submits are intentionally allowed in v1 and must always create a fresh support request row plus a fresh internal support reference with no hidden merge or dedupe behavior
7. **Returned reference**: one immutable internal support reference shown back immediately in success feedback, formatted as `SR-<ULID>`
Any support inbox, lifecycle state machine, external ticket reference, file upload, or customer-facing support portal is deferred by design.
## UI / Surface Guardrail Plan
- **Guardrail scope**: changed surfaces
- **Native vs custom classification summary**: native Filament + shared support primitives
- **Shared-family relevance**: header actions, support capture, support diagnostics, audit feedback
- **State layers in scope**: page, detail, action form
- **Audience modes in scope**: operator-MSP, support-platform
- **Decision/diagnostic/raw hierarchy plan**: decision-first form, diagnostics-second, support-raw omitted from persistence
- **Raw/support gating plan**: capability-gated attachment, raw payloads never persisted
- **One-primary-action / duplicate-truth control**: the request form keeps one dominant action, `Submit support request`, and reuses the support-diagnostics bundle summary instead of introducing local case language. On the operation detail page, both support actions (`Open support diagnostics`, `Request support`) stay grouped in secondary placement under `More`.
- **Handling modes by drift class or surface**: review-mandatory
- **Repository-signal treatment**: review-mandatory
- **Special surface test profiles**: standard-native-filament, monitoring-state-page
- **Required tests or manual smoke**: functional-core, state-contract
- **Exception path and spread control**: existing tenant dashboard action-surface exemption remains bounded to the two support-aware actions only
- **Active feature PR close-out entry**: Guardrail
## Shared Pattern & System Fit
- **Cross-cutting feature marker**: yes
- **Systems touched**: `App\Filament\Pages\TenantDashboard`, `App\Filament\Pages\Operations\TenantlessOperationRunViewer`, `App\Support\SupportDiagnostics\SupportDiagnosticBundleBuilder`, `App\Support\Auth\Capabilities`, `App\Services\Auth\RoleCapabilityMap`, and `App\Services\Audit\WorkspaceAuditLogger`
- **Shared abstractions reused**: support-diagnostics bundle composition, existing capability gating through `UiEnforcement`, existing audit-log writing, and the current support-aware tenant and run action surfaces
- **New abstraction introduced? why?**: one bounded `SupportRequestContextBuilder` or `SupportRequestSubmissionService` is justified because the slice needs one canonical place to shape immutable request context and reference generation without duplicating tenant/run logic
- **Why the existing abstraction was sufficient or insufficient**: the existing abstractions are sufficient for safe context and audit patterns, but insufficient for persisted support-request truth and immutable reference generation
- **Bounded deviation / spread control**: no ticket-provider adapter, no support queue, no page-local context builders, and no second support-summary vocabulary
## OperationRun UX Impact
- **Touches OperationRun start/completion/link UX?**: no
- **Central contract reused**: N/A
- **Delegated UX behaviors**: N/A
- **Surface-owned behavior kept local**: the run-context action reads the current run only as request context
- **Queued DB-notification policy**: N/A
- **Terminal notification path**: N/A
- **Exception path**: none
## Provider Boundary & Portability Fit
- **Shared provider/platform boundary touched?**: yes
- **Provider-owned seams**: translated provider reasons and provider-connection state already carried by the support-diagnostics bundle
- **Platform-core seams**: support request record, support reference, severity, primary context labels, attachment mode
- **Neutral platform terms / contracts preserved**: support request, support reference, attached context, redacted diagnostic snapshot, canonical reference set
- **Retained provider-specific semantics and why**: provider-specific reasons remain inside the redacted support-diagnostics bundle because they are already modeled as provider-owned evidence
- **Bounded extraction or follow-up path**: external ticketing remains a follow-up spec and must consume the neutral support-request truth instead of reshaping provider-specific evidence inline
## Constitution Check
*GATE: Must pass before implementation begins. Re-check after design changes.*
- Inventory-first / snapshots-second: PASS - the request stores immutable submitted context and does not replace canonical diagnostic truth
- Read/write separation: PASS - the action form is the pre-submit preview surface, creation is explicit, and the write is audited and tested
- Graph contract path: PASS - no new Graph calls are introduced
- Deterministic capabilities: PASS - capability derivation stays in the canonical registry and role map
- RBAC-UX / workspace isolation / tenant isolation: PASS - the feature remains on `/admin`, keeps non-member and non-entitled access as 404, and uses tenant-safe action surfaces only
- Global search rule: PASS - no resource or global-search change is introduced
- Run observability / Ops UX: PASS - request creation is DB-only and intentionally creates no `OperationRun`
- Proportionality / `PROP-001`, `ABSTR-001`, `PERSIST-001`, `STATE-001`, `BLOAT-001`: PASS - one persisted request truth and one small severity family are justified by structured support intake and no narrower path preserves immutable request context
- Shared pattern reuse / `XCUT-001`: PASS - support-diagnostics and audit seams are reused explicitly
- Provider boundary / `PROV-001`: PASS - provider-specific semantics stay inside the existing redacted bundle only
- Filament-native UI / `UI-FIL-001`: PASS - the slice uses native Filament action forms only
- Livewire v4 / Filament v5 compliance: PASS - the plan stays entirely within the current Filament v5 + Livewire v4 stack
- Provider registration location: PASS - no provider registration changes are introduced; Laravel 11+ provider registration remains in `bootstrap/providers.php`
- Destructive actions: PASS - none added, so no `->requiresConfirmation()` path is introduced here
- Asset strategy: PASS - no new assets are required, so deployment behavior for `cd apps/platform && php artisan filament:assets` remains unchanged
- Test governance / `TEST-GOV-001`: PASS - proof remains in narrow unit plus feature lanes only
## Test Governance Check
- **Test purpose / classification by changed surface**: Unit for context-shape and internal-reference rules; Feature for tenant and run action behavior, authorization, and audit
- **Affected validation lanes**: fast-feedback, confidence
- **Why this lane mix is the narrowest sufficient proof**: the feature is server-driven, synchronous, and action-form based; browser automation would only duplicate behavior already provable through unit and Filament feature tests
- **Narrowest proving command(s)**:
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/SupportRequests/SupportRequestContextBuilderTest.php tests/Unit/Support/SupportRequests/SupportRequestReferenceTest.php`
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/SupportRequests/TenantSupportRequestActionTest.php tests/Feature/SupportRequests/OperationRunSupportRequestActionTest.php tests/Feature/SupportRequests/SupportRequestAuthorizationTest.php tests/Feature/SupportRequests/SupportRequestAuditTest.php`
- **Fixture / helper / factory / seed / context cost risks**: add one `SupportRequest` factory; reuse existing workspace, tenant, run, provider, finding, report, review, and audit fixtures; keep support-request helpers local to the feature namespace
- **Expensive defaults or shared helper growth introduced?**: no
- **Heavy-family additions, promotions, or visibility changes**: none
- **Surface-class relief / special coverage rule**: standard-native-filament relief applies to the tenant action; the operation detail action keeps the monitoring-state-page contract already established on the viewer
- **Closing validation and reviewer handoff**: reviewers should re-run the listed unit and feature commands, verify immutable context persistence, verify 404 versus 403 boundaries, and verify that no outbound HTTP or `OperationRun` side effect occurs
- **Budget / baseline / trend follow-up**: none expected beyond ordinary feature-local upkeep
- **Review-stop questions**: did implementation add an outbound adapter, a request status workflow, a support inbox, or raw diagnostic persistence; did it broaden entry points beyond the two approved surfaces?
- **Escalation path**: `reject-or-split` if the slice expands into external sync, a support queue, or lifecycle management
- **Active feature PR close-out entry**: Guardrail
- **Why no dedicated follow-up spec is needed**: the planned cost stays local to support-request creation; only external ticketing or request-lifecycle expansion would justify a follow-up spec
## Project Structure
### Documentation (this feature)
```text
specs/246-support-request-context/
├── checklists/
│ └── requirements.md
├── spec.md
├── plan.md
└── tasks.md
```
### Source Code (repository root)
```text
apps/platform/
├── app/
│ ├── Filament/
│ │ └── Pages/
│ │ ├── Operations/
│ │ │ └── TenantlessOperationRunViewer.php
│ │ └── TenantDashboard.php
│ ├── Models/
│ │ └── SupportRequest.php
│ ├── Services/
│ │ ├── Audit/WorkspaceAuditLogger.php
│ │ └── Auth/RoleCapabilityMap.php
│ └── Support/
│ ├── Audit/AuditActionId.php
│ ├── Auth/Capabilities.php
│ ├── SupportDiagnostics/SupportDiagnosticBundleBuilder.php
│ └── SupportRequests/
│ ├── SupportRequestContextBuilder.php
│ └── SupportRequestReferenceGenerator.php
├── database/
│ ├── factories/SupportRequestFactory.php
│ └── migrations/
└── tests/
├── Feature/SupportRequests/
│ ├── OperationRunSupportRequestActionTest.php
│ ├── SupportRequestAuditTest.php
│ ├── SupportRequestAuthorizationTest.php
│ └── TenantSupportRequestActionTest.php
└── Unit/Support/SupportRequests/
├── SupportRequestContextBuilderTest.php
└── SupportRequestReferenceTest.php
```
**Structure Decision**: Single Laravel application. The implementation adds one bounded support-request model plus one small support namespace and reuses existing tenant and run surfaces.
## Complexity Tracking
No additional constitution violations are required. The new persisted support-request truth and small severity family are already justified in the proportionality review and remain bounded to the first slice.
## Proportionality Review
- **Current operator problem**: support intake still starts outside structured product context even though the product can already explain the current tenant or run problem safely
- **Existing structure is insufficient because**: support diagnostics is read-only and cannot provide an immutable, auditable support request or internal support reference
- **Narrowest correct implementation**: one immutable `SupportRequest` record plus one bounded context builder that reuses existing support diagnostics when allowed
- **Ownership cost**: migration, model, factory, capability, audit action, bounded support-request support namespace, and focused tests
- **Alternative intentionally rejected**: outbound-only ticket adapters, a multi-provider helpdesk registry, and a request status workflow were rejected because no concrete second use case or provider foundation exists yet
- **Why this is current-release truth**: the support-request record is directly useful now even without external sync because it preserves structured intake, returns a support reference, and captures immutable context
## Rollout & Risk Controls
- Start on exactly two existing surfaces only: the tenant dashboard and the canonical operation detail viewer
- Keep request truth immutable after creation; lifecycle management is explicitly out of scope
- Persist only redacted context JSON; raw payloads, secrets, and unrestricted provider bodies remain excluded
- Keep the reference internal-only in v1; external ticket references are deferred until a later ticketing spec exists
- Reuse the existing support-diagnostics capability when attaching diagnostics so the feature can safely support reduced attachment mode without creating a second diagnostic access path
## Implementation Outline
- Add the `SupportRequest` model, migration, and factory as the new persisted support-intake truth
- Add `support_requests.create` to the canonical capability registry and role map
- Add a bounded support-request context builder plus internal reference generator that can build tenant-context and run-context envelopes from the existing support-diagnostics bundle and canonical references
- Add an audit action identifier and `WorkspaceAuditLogger` path for support-request creation
- Add `Request support` action forms to `TenantDashboard` and `TenantlessOperationRunViewer`
- Return the generated support reference in success feedback and keep the action synchronous and DB-only
## Implementation Phases
1. **Foundation**: migration, model, factory, capability, audit action, internal reference generation, and shared context builder
2. **Tenant entry point**: tenant dashboard action, reduced-attachment logic, tenant-context feature proof
3. **Run entry point**: canonical operation detail action, entitled-tenant resolution, run-context feature proof
4. **Safety hardening**: immutable context persistence, authorization edge cases, audit proof, and no-side-effect verification
## Guardrail Close-Out
- Livewire v4 compliance remained unchanged and the feature shipped through native Filament v5 action forms only.
- Provider registration location stayed unchanged; Laravel 11+ provider registration remains in `bootstrap/providers.php`.
- No global-search behavior changed because no resource or global-search surface was introduced.
- No destructive action was added, so no new confirmation flow was required.
- No asset strategy changed; deployment remains unchanged, including `cd apps/platform && php artisan filament:assets` when registered Filament assets are present elsewhere.
- Browser smoke confirmed both approved entry points on the live app: the tenant dashboard visible `Request support` action and the tenantless operation viewer grouped `More` > `Request support` action both submitted successfully and returned `Support request submitted` with `Reference SR-...`.
- The tenant dashboard action-surface exception stayed bounded to the existing support-aware pair (`Request support`, `Open support diagnostics`), while the operation viewer kept both support actions grouped under `More` to avoid competing with its primary navigation and utility actions.

View File

@ -1,281 +0,0 @@
# Feature Specification: In-App Support Request with Context
**Feature Branch**: `246-support-request-context`
**Created**: 2026-04-27
**Status**: Ready for implementation
**Input**: User description: "Promote the roadmap-fit candidate In-App Support Request with Context as a narrow, implementation-ready slice that adds structured support-request creation from existing support-aware product surfaces. The slice should reuse Support Diagnostic Pack, product knowledge, existing tenant and operation context resolution, and audit patterns to capture one support request with redacted diagnostic references and operator-entered severity/message fields, without building a full helpdesk, ticket sync engine, or CRM workflow."
## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
- **Problem**: Generic support email or an external ticket link discards the most important product context at the moment help is requested: workspace, tenant, current run, related findings, recent reports, review artifacts, and the current diagnostic state.
- **Today's failure**: Operators must manually copy context from several product surfaces into an ad hoc support note, which creates avoidable back-and-forth, invites oversharing of raw diagnostics, and leaves no reliable internal support reference inside TenantPilot.
- **User-visible improvement**: A tenant-scoped or run-scoped operator can submit one structured support request from the current product surface, capture severity plus summary and note fields, attach safe context automatically, and immediately receive an internal support reference.
- **Smallest enterprise-capable version**: Add one immutable internal `SupportRequest` record with a generated reference, two first-slice entry actions on existing tenant and run surfaces, automatic canonical context attachment, optional redacted support-diagnostic snapshot attachment when the creator is allowed to view it, and audit logging for request creation.
- **Explicit non-goals**: No full helpdesk product, no support inbox or triage board, no two-way ticket sync, no SLA engine, no file-upload pipeline, no customer-facing portal, no AI support bot, no background notification workflow, and no external ticket provider coupling in v1.
- **Permanent complexity imported**: One new persisted `SupportRequest` truth, one small support-request severity family, one bounded context-builder path, one generated internal reference format, one new tenant capability, two read-only context-aware create actions, and focused unit plus feature coverage.
- **Why now**: The repo already has the support-diagnostics bundle, contextual help, tenant and run context resolution, and audit seams. This is the narrowest next slice that turns those support foundations into structured intake instead of leaving support creation as manual copy-paste.
- **Why not local**: A page-local note field, mailto link, or generic modal would still duplicate context assembly, drift redaction behavior, and lose canonical references. The support request needs one reusable capture contract because both tenant and run surfaces already depend on the same support truth.
- **Approval class**: Workflow Compression
- **Red flags triggered**: New persistence, new severity semantics, and multi-surface workflow touchpoint. Defense: the slice stores one immutable request record only, avoids status workflow or external sync, and is limited to two already support-aware surfaces that can reuse the existing diagnostic bundle.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 1 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | **Gesamt: 10/12**
- **Decision**: approve
## Spec Scope Fields *(mandatory)*
- **Scope**: workspace, tenant
- **Primary Routes**:
- `/admin/t/{tenant}` existing tenant dashboard as the first tenant-context support-request entry point
- `/admin/operations/{run}` existing canonical operation detail surface as the first run-context support-request entry point
- **Data Ownership**: `support_requests` becomes new tenant-owned product truth with required `workspace_id` and `tenant_id`, both stored as not-null fields. `workspace_id` is still derived from the tenant relationship for correctness, but it remains persisted because tenant-owned truth in this repo carries both anchors. Canonical source truth for attached references remains on existing `Tenant`, `OperationRun`, `ProviderConnection`, `Finding`, `StoredReport`, `TenantReview`, `ReviewPack`, and `AuditLog` records. Any attached support-diagnostic snapshot is a redacted immutable capture owned by the support request, not a replacement for those source records.
- **RBAC**: Workspace membership and tenant entitlement remain mandatory. A new tenant-role capability `support_requests.create` gates request creation. When a request includes the redacted support-diagnostic snapshot, the creator must also pass the existing `support_diagnostics.view` check; otherwise the request stores only the safe canonical context reference set and an explicit note that diagnostic evidence was omitted.
For canonical-view specs, the spec MUST define:
- **Default filter behavior when tenant-context is active**: N/A - the first slice adds contextual create actions only and does not introduce a support-request registry page.
- **Explicit entitlement checks preventing cross-tenant leakage**: Non-members and non-entitled users receive 404 semantics before any tenant-owned context is assembled. The operation entry point is in scope only when the run resolves to an entitled tenant.
## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*
- **Cross-cutting feature?**: yes
- **Interaction class(es)**: header actions, contextual support capture, success notifications, support-safe context summaries, audit events
- **Systems touched**: existing tenant dashboard and canonical operation detail action surfaces, the support-diagnostics bundle builder, contextual-help content, tenant capability mapping, and workspace audit logging
- **Existing pattern(s) to extend**: existing support-diagnostics entry points, existing Filament header action patterns, existing support-diagnostics redaction rules, and existing audit logging conventions
- **Shared contract / presenter / builder / renderer to reuse**: `SupportDiagnosticBundleBuilder`, `WorkspaceAuditLogger`, existing contextual-help resolver or catalog patterns where copy is needed, and existing support-safe route and label vocabulary already used on tenant and run surfaces
- **Why the existing shared path is sufficient or insufficient**: The current shared support paths already produce deterministic, redacted context and the right canonical references. They are insufficient because the product still lacks a persisted support-request truth and a structured create flow that can capture that context safely.
- **Allowed deviation and why**: One bounded `SupportRequests` support namespace is allowed to assemble immutable request context and generate an internal support reference. No generic ticket adapter, no local page-only context mappers, and no second support-summary dialect are allowed.
- **Consistency impact**: `Request support`, `Support reference`, redaction wording, severity labels, and attached-context copy must remain consistent across tenant and run entry points so the same support concept is visible regardless of where the request originates.
- **Review focus**: Reviewers must verify that context capture reuses the shared support-diagnostics bundle rather than rebuilding record selection locally, and that no raw provider payloads or unrestricted diagnostics are persisted in the request.
## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*
- **Touches OperationRun start/completion/link UX?**: no
- **Shared OperationRun UX contract/layer reused**: N/A
- **Delegated start/completion UX behaviors**: N/A
- **Local surface-owned behavior that remains**: The run-context request action reads the current run as context only; it does not queue, resume, or complete any `OperationRun`.
- **Queued DB-notification policy**: N/A
- **Terminal notification path**: N/A
- **Exception required?**: none
## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*
- **Shared provider/platform boundary touched?**: yes
- **Boundary classification**: mixed
- **Seams affected**: provider-connection health excerpts that may appear inside an attached redacted support-diagnostic snapshot, provider-owned reason translation, and support-request context labels
- **Neutral platform terms preserved or introduced**: support request, support reference, primary context, attached context, redacted diagnostic snapshot, canonical reference set
- **Provider-specific semantics retained and why**: Microsoft-specific provider errors or consent states remain provider-owned diagnostic inputs and may only appear through the already redacted support-diagnostics bundle.
- **Why this does not deepen provider coupling accidentally**: The new request record stores provider-neutral context metadata plus canonical references. Provider-specific semantics enter only through the existing support-diagnostics bundle, which is already bounded and redacted.
- **Follow-up path**: Later PSA or ticketing integration remains a separate follow-up spec and must consume the neutral support-request truth instead of reshaping it.
## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
|---|---|---|---|---|---|---|
| Tenant dashboard request support action | yes | Native Filament + shared support primitives | header actions, support capture, support diagnostics | page, action, form | yes | Existing tenant dashboard action-surface exemption remains; this slice adds one bounded create action beside the current support-diagnostics action |
| Canonical operation detail request support action | yes | Native Filament + shared support primitives | header actions, monitoring-state diagnostics, support capture | detail, action, form | no | Extends an already support-aware operation surface instead of creating a new support page |
## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*
| Surface | Decision Role | Human-in-the-loop Moment | Immediately Visible for First Decision | On-Demand Detail / Evidence | Why This Is Primary or Why Not | Workflow Alignment | Attention-load Reduction |
|---|---|---|---|---|---|---|---|
| Tenant dashboard request support action | Secondary Context Surface | The operator decides the current tenant issue needs escalation or structured support intake | Tenant identity, context summary, severity selection, message fields, and whether redacted diagnostics will be attached | Redacted support diagnostics and canonical related records remain secondary evidence | Not primary because support creation follows tenant troubleshooting rather than replacing it | Follows tenant troubleshooting and escalation | Eliminates manual copy-paste from provider, run, findings, and audit surfaces |
| Canonical operation detail request support action | Secondary Context Surface | The operator is already inspecting one run and decides support intake should begin from that run context | Run identity, context summary, severity selection, message fields, and whether redacted diagnostics will be attached | Redacted support diagnostics and canonical related records remain secondary evidence | Not primary because the main work is still understanding and acting on the run | Follows monitoring drill-in workflow | Removes ad hoc support notes that would otherwise rebuild run context manually |
## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*
| Surface | Audience Modes In Scope | Decision-First Default-Visible Content | Operator Diagnostics | Support / Raw Evidence | One Dominant Next Action | Hidden / Gated By Default | Duplicate-Truth Prevention |
|---|---|---|---|---|---|---|---|
| Tenant dashboard request support action | operator-MSP, support-platform | Scope summary, severity, message fields, contact defaults, attachment note, redaction note | Existing support-diagnostics bundle and canonical links | Raw payloads and unrestricted provider diagnostics are never stored here | `Submit support request` | Diagnostic snapshot attachment is omitted unless `support_diagnostics.view` is allowed | The action reuses the shared support-diagnostics bundle summary instead of restating provider or run truth locally |
| Canonical operation detail request support action | operator-MSP, support-platform | Run identity, severity, message fields, contact defaults, attachment note, redaction note | Existing run-context support diagnostics and canonical links | Raw payloads and unrestricted provider diagnostics are never stored here | `Submit support request` | Diagnostic snapshot attachment is omitted unless `support_diagnostics.view` is allowed | The action reuses the shared run-context support summary instead of inventing a second run explanation path |
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
| Surface | Action Surface Class | Surface Type | Likely Next Operator Action | Primary Inspect/Open Model | Row Click | Secondary Actions Placement | Destructive Actions Placement | Canonical Collection Route | Canonical Detail Route | Scope Signals | Canonical Noun | Critical Truth Visible by Default | Exception Type / Justification |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard request support action | Dashboard / Overview / Actions | Tenant support escalation entry point | Submit a structured support request | Explicit header action opens a slide-over or modal form | forbidden | Existing support diagnostics remains a neighboring secondary action | none | `/admin/t/{tenant}` | `/admin/t/{tenant}` | Active workspace, active tenant, and attached-context note | Support request / Support reference | Primary context, required message fields, severity, and redaction note | dashboard_exception - existing tenant dashboard action-surface exemption remains bounded and read-only apart from the create mutation |
| Canonical operation detail request support action | Record / Detail / Actions | Run-centered support escalation entry point | Submit a structured support request from the current run | Existing detail page plus grouped secondary support actions | forbidden | `Open support diagnostics` and `Request support` are grouped together under the detail action group | none | `/admin/operations` | `/admin/operations/{run}` | Workspace context, entitled tenant context, and operation identifier | Support request / Support reference | Primary run context, required summary fields, severity, and redaction note | none |
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
| Surface | Primary Persona | Decision / Operator Action Supported | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|---|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard request support action | Workspace manager or support-capable tenant operator | Submit one tenant-scoped support request with safe context | Dashboard action + contextual form | How do I ask for help on this tenant without manually rebuilding the case? | Tenant label, severity, summary, reproduction-notes field, contact defaults, context-attachment note, redaction note | Full support diagnostics stay on the neighboring support-diagnostics action and canonical linked pages | support-request severity, attachment completeness | TenantPilot only | Submit support request | none |
| Canonical operation detail request support action | Workspace manager or support-capable operator | Submit one run-scoped support request with safe context | Detail action + contextual form | How do I escalate this run with the right context and without copying raw diagnostics? | Operation identifier, severity, summary, reproduction-notes field, contact defaults, context-attachment note, redaction note | Full support diagnostics stay on the neighboring support-diagnostics action and canonical linked pages | support-request severity, attachment completeness | TenantPilot only | Submit support request | none |
## Proportionality Review *(mandatory when structural complexity is introduced)*
- **New source of truth?**: yes
- **New persisted entity/table/artifact?**: yes
- **New abstraction?**: yes
- **New enum/state/reason family?**: yes - one bounded support-request severity family
- **New cross-domain UI framework/taxonomy?**: no
- **Current operator problem**: The product can already explain support context, but it still cannot capture a structured support request at the moment the operator needs help.
- **Existing structure is insufficient because**: Support diagnostics is read-only and generic support channels lose context. Without a persisted request record, there is no internal support reference or safe immutable request payload.
- **Narrowest correct implementation**: Add one immutable `SupportRequest` truth with a small severity family and one bounded context-builder path that reuses the existing support-diagnostics bundle when allowed.
- **Ownership cost**: One migration, one model and factory, one support-request context builder or submission service, one capability, one audit action, and focused unit plus feature coverage.
- **Alternative intentionally rejected**: Outbound-only ticket adapters and a broader helpdesk workflow were rejected because the repo has no concrete ticket-provider foundation yet and the first release does not need a support queue, lifecycle engine, or external sync.
- **Release truth**: current-release truth
### Compatibility posture
This feature assumes a pre-production environment.
Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.
Canonical replacement is preferred over preservation.
## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
- **Test purpose / classification**: Unit, Feature
- **Validation lane(s)**: fast-feedback, confidence
- **Why this classification and these lanes are sufficient**: Unit tests can prove internal reference generation, immutable context-shape rules, and redaction-aware attachment behavior. Feature tests can prove tenant and run entry actions, 404 versus 403 boundaries, persisted request creation, and audit logging without browser automation.
- **New or expanded test families**: One focused `SupportRequests` unit family and a small set of tenant plus run feature tests
- **Fixture / helper cost impact**: Moderate. Reuse existing workspace, tenant, run, provider, finding, stored-report, review, audit, and support-diagnostics fixtures. Add one `SupportRequest` factory and keep helpers local to the support-request test namespace.
- **Heavy-family visibility / justification**: none
- **Special surface test profile**: standard-native-filament, monitoring-state-page
- **Standard-native relief or required special coverage**: Ordinary Filament feature coverage is sufficient for the tenant dashboard action. The run-context action must also preserve the canonical monitoring-state-page constraints already used on the existing operation viewer.
- **Reviewer handoff**: Reviewers must confirm that request creation persists only redacted context, never triggers outbound HTTP or a new `OperationRun`, returns the internal support reference in success feedback, and keeps non-member access as 404.
- **Budget / baseline / trend impact**: Low-to-moderate increase in narrow unit plus feature coverage only
- **Escalation needed**: none
- **Active feature PR close-out entry**: Guardrail
- **Planned validation commands**:
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/SupportRequests/SupportRequestContextBuilderTest.php tests/Unit/Support/SupportRequests/SupportRequestReferenceTest.php`
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/SupportRequests/TenantSupportRequestActionTest.php tests/Feature/SupportRequests/OperationRunSupportRequestActionTest.php tests/Feature/SupportRequests/SupportRequestAuthorizationTest.php tests/Feature/SupportRequests/SupportRequestAuditTest.php`
## Support-Request Severity Contract
The first slice uses one fixed severity family and does not infer or automate downstream workflow from it.
| Stored Value | UI Label | Meaning In V1 |
|---|---|---|
| `low` | Low | Question or minor issue; work can continue and no current blocker exists |
| `normal` | Normal | Ordinary support needed; work can continue with friction |
| `high` | High | Time-sensitive issue or material degradation that needs prompt attention |
| `blocking` | Blocking | Current work cannot proceed or access is effectively blocked |
Validation rules for v1:
- Exactly one severity value is required on every support request.
- The action form defaults to `normal` unless the operator selects a different value.
- Severity affects persisted request truth and UI labels only in v1; it does not start a queue, SLA, or notification workflow.
## Internal Support Reference Contract
- Every created support request receives a reference formatted as `SR-<ULID>`.
- The `SR-` prefix is fixed and uppercase in v1.
- The ULID portion is uppercase, generated once at creation time, and remains immutable afterward.
- Success feedback and audit context must show the exact stored value rather than reformatting it locally.
## User Scenarios & Testing *(mandatory)*
### User Story 1 - Submit a tenant-scoped support request with safe context (Priority: P1)
As a workspace manager or support-capable tenant operator, I want to request support from the current tenant surface so I do not have to manually rebuild the case.
**Why this priority**: Tenant-context support intake is the broadest first-response path and benefits immediately from the existing support-diagnostics foundation.
**Independent Test**: Seed a tenant with provider, run, finding, review, report, and audit truth, submit a support request from the tenant dashboard, and verify that the request is persisted with an internal reference and only safe attached context.
**Acceptance Scenarios**:
1. **Given** an entitled operator opens the tenant dashboard for a tenant with current support context, **When** they submit a support request with severity and summary, **Then** the system creates one immutable support request with a generated internal reference, tenant and workspace context, and canonical references to the current case.
2. **Given** the creator also has `support_diagnostics.view`, **When** they submit the tenant-scoped request, **Then** the request stores the redacted support-diagnostics snapshot or reference set instead of requiring manual copy-paste.
3. **Given** the creator lacks `support_diagnostics.view` but still has `support_requests.create`, **When** they submit the request, **Then** the request stores the safe canonical context set only and records that diagnostic evidence was omitted.
---
### User Story 2 - Submit a run-scoped support request from monitoring (Priority: P1)
As an operator already inspecting one run, I want to request support from the canonical run detail surface so the support request starts from the exact failing or degraded run.
**Why this priority**: A large share of support work starts from one run, and the operation viewer already has the right support-aware context and authorization boundaries.
**Independent Test**: Seed a failed or degraded run with related canonical truth, submit a support request from the operation viewer, and verify that the saved request is run-scoped, tenant-safe, and auditable.
**Acceptance Scenarios**:
1. **Given** an entitled operator is viewing a run that resolves to an entitled tenant, **When** they submit a support request from that run surface, **Then** the system persists one immutable support request whose primary context is that run and whose canonical references stay tenant-safe.
2. **Given** the run does not resolve to an entitled tenant for the current user, **When** they try to create a run-scoped support request, **Then** the system responds as not found and does not reveal whether additional support context exists.
---
### User Story 3 - Keep support intake redacted, auditable, and bounded (Priority: P2)
As the product owner, I want the first support-request slice to stay immutable and provider-neutral so it can be trusted and extended later without accidentally becoming a helpdesk framework.
**Why this priority**: Structured intake adds value only if it stays safe, deterministic, and free of premature helpdesk complexity.
**Independent Test**: Verify that repeated request creation uses the same reference format and context-shape rules, that audit entries are written, and that no outbound helpdesk work or `OperationRun` side effects occur.
**Acceptance Scenarios**:
1. **Given** the same authorized tenant or run input and the same creator capability set, **When** a support request is generated, **Then** the attached context shape follows the same deterministic rules every time.
2. **Given** support request creation succeeds, **When** the request is persisted, **Then** an audit entry records the actor, primary context, internal reference, and redaction mode without storing raw provider payloads.
3. **Given** an operator submits the same issue twice, **When** both requests are accepted, **Then** each submission receives its own immutable internal reference because v1 intentionally does not deduplicate or merge requests.
### Edge Cases
- A tenant may have no provider connection, no recent run, or no active findings. The support request must still persist with explicit `missing` or `not observed` context markers rather than failing or inventing placeholder truth.
- A run may reference related records that have since been deleted or are no longer accessible. The saved request must keep safe missing or inaccessible markers without leaking details from those records.
- A creator may have `support_requests.create` without `support_diagnostics.view`. The request must still be creatable with the reduced safe context set and explicit omission semantics.
- Context may change after request creation. The request must preserve the immutable submitted context snapshot or reference envelope and must not silently mutate with later diagnostic state.
## Requirements *(mandatory)*
**Constitution alignment (required):** This feature introduces a DB-only write and no new Microsoft Graph calls, no scheduled work, and no queued workflow. Because the request is security-relevant and intentionally skips `OperationRun`, successful request creation MUST write an `AuditLog` entry with redacted metadata.
**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This feature introduces one new persisted support-request truth, one bounded support-request context builder or submission service, and one small support-request severity family because existing support diagnostics is read-only and generic ticket links lose context. A narrower solution is insufficient because it would still fail to preserve immutable submitted context or return a trustworthy in-product support reference.
**Constitution alignment (XCUT-001):** Support-request capture MUST extend the existing support-diagnostics bundle and audit paths rather than duplicating page-local context assembly or provider wording.
**Constitution alignment (PROV-001):** The support-request model and labels remain provider-neutral. Provider-specific semantics may appear only inside the already redacted support-diagnostic snapshot when that attachment is allowed.
**Constitution alignment (TEST-GOV-001):** Proof stays in focused unit plus feature lanes only. Browser and heavy-governance lanes are out of scope for the first slice.
**Constitution alignment (OPS-UX / OPS-UX-START-001):** No new `OperationRun` is created, resumed, or linked as a started workflow. Request creation is a synchronous DB-only support action.
**Constitution alignment (RBAC-UX):** The affected authorization plane is the tenant-admin `/admin` plane. Non-members and non-entitled users receive 404. Entitled members lacking `support_requests.create` receive 403. The run-context action must only render after the viewer resolves an entitled tenant scope.
**Constitution alignment (UI-FIL-001):** The feature must use native Filament actions and action forms. No custom standalone support page or ad hoc support form shell is allowed in v1.
**Constitution alignment (UI-NAMING-001):** Primary operator labels remain `Request support` and `Support reference`. Implementation-first terms such as payload snapshot, JSON blob, or ticket adapter must not appear in the primary UI.
**Constitution alignment (DECIDE-001 / OPSURF-001):** The affected surfaces remain secondary context surfaces. Support creation must not compete with the primary tenant or operation investigation workflow and must not expose raw diagnostics by default.
### Functional Requirements
- **FR-246-001 Entry points**: The system MUST allow support-request creation from exactly two first-slice contexts: the existing tenant dashboard and the existing canonical operation detail surface.
- **FR-246-002 Immutable internal reference**: Every created support request MUST receive a generated internal support reference that is unique, stable, and shown back to the creator immediately after submission.
- **FR-246-003 Captured fields**: A support request MUST capture workspace, tenant, initiating user, primary context type, optional run reference when applicable, severity chosen from `low`, `normal`, `high`, or `blocking`, a required summary field, optional reproduction notes, and optional contact name and contact email defaults derived from the creator.
- **FR-246-004 Canonical context attachment**: The request MUST automatically attach the safe canonical context set for the current tenant or run instead of requiring manual copy-paste of record identifiers.
- **FR-246-005 Diagnostic snapshot attachment**: When the creator can view support diagnostics for the current scope, the request MUST attach a redacted support-diagnostic snapshot or structured reference envelope derived from the existing bundle contract.
- **FR-246-006 Reduced attachment mode**: When the creator cannot view support diagnostics but can create a support request, the request MUST omit the diagnostic snapshot and persist only the safe canonical context set together with an explicit omission marker.
- **FR-246-007 Authorization boundaries**: Non-members and non-entitled users MUST receive 404 semantics. Entitled users lacking `support_requests.create` MUST receive 403. Cross-tenant or unrelated run context MUST never attach accidentally.
- **FR-246-008 No external dependency**: The first slice MUST NOT require an external ticket provider, outbound HTTP call, or external ticket reference to create a support request.
- **FR-246-009 Auditability**: Support-request creation MUST write an audit event that records the actor, support reference, primary context, attachment mode, and redaction mode without storing excluded raw payload content.
- **FR-246-010 Provider-safe persistence**: Persisted support-request context MUST NOT include raw provider payloads, secrets, tokens, or unrestricted diagnostic bodies.
- **FR-246-011 Immutability**: The first slice MUST treat the support request as immutable after creation. No edit, status workflow, reopen, or merge behavior may be introduced in v1.
- **FR-246-012 Duplicate submissions**: The first slice MUST allow repeated submissions and create a new internal support reference each time rather than attempting hidden deduplication or merge logic.
- **FR-246-013 Machine-readable context**: The attached context envelope MUST remain machine-readable and deterministic so later ticketing or AI-assisted follow-up can reuse it without redefining support-request truth.
## UI Action Matrix *(mandatory when Filament is changed)*
| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
|---|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard support actions | `App\Filament\Pages\TenantDashboard` | Existing `Open support diagnostics` plus new `Request support` | n/a | none | none | none added | `Request support` on the tenant dashboard action surface only | action-form submit plus cancel | yes | Existing tenant dashboard exemption remains bounded to two support-aware actions only |
| Canonical operation detail support actions | `App\Filament\Pages\Operations\TenantlessOperationRunViewer` | `Open support diagnostics` and `Request support` are grouped under `More` | Existing operation detail page remains the primary inspect model | none | none | n/a | Both support actions are grouped under the run detail action group instead of competing with the page's primary navigation and utility actions | action-form submit plus cancel | yes | Keeps support tooling secondary on the detail page while preserving structured escalation and diagnostics access |
### Key Entities *(include if feature involves data)*
- **SupportRequest**: The new immutable product truth that records one submitted support intake event together with its generated internal reference and safe attached context.
- **SupportRequest Context Envelope**: The redacted, machine-readable set of canonical references and optional diagnostic snapshot attached to a support request.
- **Support Reference**: The generated internal identifier shown back to the creator immediately after submission.
- **Attachment Mode**: The persisted marker that distinguishes between `diagnostic_snapshot_attached` and `canonical_context_only` based on creator capability and safe context rules.
## Success Criteria *(mandatory)*
### Measurable Outcomes
- **SC-246-001**: A support request created from either approved surface is persisted with a unique internal support reference and the expected primary context every time in focused feature coverage.
- **SC-246-002**: Focused authorization tests prove that unrelated tenant or run context cannot be attached accidentally and that 404 versus 403 boundaries remain correct.
- **SC-246-003**: Focused audit tests prove that support-request creation writes one redacted audit event and performs no outbound HTTP or `OperationRun` side effect.
- **SC-246-004**: Focused unit coverage proves that the attached context envelope remains deterministic and excludes raw provider payload content.

View File

@ -1,185 +0,0 @@
---
description: "Task list for In-App Support Request with Context"
---
# Tasks: In-App Support Request with Context
**Input**: Design documents from `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/`
**Prerequisites**: `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/plan.md` (required), `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/spec.md` (required), `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/checklists/requirements.md` (required)
**Tests (TEST-GOV-001)**: REQUIRED (Pest) for all runtime behavior changes in this slice. Keep proof in focused unit plus feature lanes only.
**Operations**: This slice must not create, queue, resume, or complete an `OperationRun`. Support-request creation stays DB-only and audited.
**RBAC**: Workspace membership, tenant entitlement, and `support_requests.create` remain authoritative. `support_diagnostics.view` controls only whether the redacted diagnostic snapshot can be attached.
**Organization**: Tasks are grouped by user story so tenant-context creation, run-context creation, and safety hardening remain independently verifiable once the shared foundation exists.
## Phase 1: Setup (Shared Infrastructure)
**Purpose**: Lock the first-slice scope and verify the existing support-aware seams before runtime edits begin.
- [x] T001 Review the first-slice scope, attachment modes, and validation commands in `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/spec.md`, `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/plan.md`, and `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/checklists/requirements.md`
- [x] T002 [P] Verify the current tenant dashboard, canonical operation detail viewer, support-diagnostics bundle builder, tenant capability map, and workspace audit logger seams that this slice must reuse in `apps/platform/app/Filament/Pages/TenantDashboard.php`, `apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php`, `apps/platform/app/Support/SupportDiagnostics/SupportDiagnosticBundleBuilder.php`, `apps/platform/app/Support/Auth/Capabilities.php`, `apps/platform/app/Services/Auth/RoleCapabilityMap.php`, and `apps/platform/app/Services/Audit/WorkspaceAuditLogger.php`
---
## Phase 2: Foundational (Blocking Prerequisites)
**Purpose**: Add the persisted support-request truth and shared capture path required by both entry contexts before surface wiring begins.
**Critical**: No user story work should start until this phase is complete.
- [x] T003 Create the tenant-owned `support_requests` migration, model, and factory with required not-null `workspace_id` and `tenant_id`, immutable internal reference, primary context type, severity constrained to `low`, `normal`, `high`, or `blocking`, required summary, optional reproduction notes, optional contact name and contact email, creator metadata, and redacted context JSON in `apps/platform/database/migrations/`, `apps/platform/app/Models/SupportRequest.php`, and `apps/platform/database/factories/SupportRequestFactory.php`
- [x] T004 [P] Register `support_requests.create` in the canonical tenant capability registry and tenant role map without widening system-plane access in `apps/platform/app/Support/Auth/Capabilities.php` and `apps/platform/app/Services/Auth/RoleCapabilityMap.php`
- [x] T005 [P] Add the bounded support-request context builder and internal reference generator in `apps/platform/app/Support/SupportRequests/SupportRequestContextBuilder.php` and `apps/platform/app/Support/SupportRequests/SupportRequestReferenceGenerator.php`, reusing `SupportDiagnosticBundleBuilder` for attachment-mode decisions and machine-readable context shaping while emitting `SR-<ULID>` references only
- [x] T006 [P] Add the support-request audit action identifier and workspace audit logger path for redacted request-creation metadata in `apps/platform/app/Support/Audit/AuditActionId.php` and `apps/platform/app/Services/Audit/WorkspaceAuditLogger.php`
**Checkpoint**: Foundation ready - both entry contexts can create the same immutable support-request truth through one shared capture path.
---
## Phase 3: User Story 1 - Submit A Tenant-Scoped Support Request (Priority: P1) 🎯 MVP
**Goal**: An entitled operator can request support from the tenant dashboard without manually rebuilding the current case.
**Independent Test**: Seed a tenant with provider, run, finding, review, report, and audit truth, submit a request from the tenant dashboard, and verify persisted request context plus returned internal reference.
### Tests for User Story 1
- [x] T007 [P] [US1] Add tenant-context feature coverage for created support reference, persisted tenant primary context, persisted severity and optional reproduction/contact fields, reduced-attachment mode, and `404` versus `403` semantics in `apps/platform/tests/Feature/SupportRequests/TenantSupportRequestActionTest.php`
### Implementation for User Story 1
- [x] T008 [US1] Add the native Filament `Request support` action form to `apps/platform/app/Filament/Pages/TenantDashboard.php` with required severity and summary fields, optional reproduction notes, contact name and contact email defaults, attachment summary, and success notification carrying the internal support reference
- [x] T009 [US1] Implement tenant-context request capture in `apps/platform/app/Support/SupportRequests/SupportRequestContextBuilder.php` so the request stores canonical tenant references and attaches the redacted support-diagnostics snapshot only when allowed
- [x] T010 [US1] Ensure tenant-context submission persists the explicit `canonical_context_only` attachment mode instead of blocking the request when diagnostic attachment is unavailable
**Checkpoint**: User Story 1 is independently functional when a tenant-context request can be submitted safely and the creator receives a stable internal support reference.
---
## Phase 4: User Story 2 - Submit A Run-Scoped Support Request (Priority: P1)
**Goal**: An entitled operator already inspecting one run can request support directly from the canonical operation detail surface.
**Independent Test**: Seed a failed or degraded run with related context, submit a support request from the operation viewer, and verify the saved request uses the run as primary context without breaking the viewer contract.
### Tests for User Story 2
- [x] T011 [P] [US2] Add run-context feature coverage for entitled-tenant resolution, persisted run primary context, persisted severity and optional reproduction/contact fields, reduced-attachment mode, and canonical viewer authorization boundaries in `apps/platform/tests/Feature/SupportRequests/OperationRunSupportRequestActionTest.php`
### Implementation for User Story 2
- [x] T012 [US2] Add the native Filament operation-viewer support actions in grouped secondary header placement on `apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php`, keeping both `Open support diagnostics` and `Request support` under `More` so they stay secondary to the viewer's primary navigation and utility actions
- [x] T013 [US2] Implement run-context request capture through the shared support-request context builder so the request uses the current run plus entitled tenant context only after authorization has resolved safely
- [x] T014 [US2] Keep run-context request copy and attachment wording aligned with the existing operation viewer and support-diagnostics vocabulary rather than introducing a second run-summary dialect
**Checkpoint**: User Story 2 is independently functional when the operation viewer can create the same support-request truth with run-centered context and correct tenant-safe boundaries.
---
## Phase 5: User Story 3 - Keep Support Intake Redacted, Auditable, And Bounded (Priority: P2)
**Goal**: The same authorized input always produces the same safe context shape and the feature stays free of ticket-provider, lifecycle, and `OperationRun` sprawl.
**Independent Test**: Verify deterministic context-envelope generation, correct attachment modes, correct audit logging, and absence of outbound HTTP or `OperationRun` side effects.
### Tests for User Story 3
- [x] T015 [P] [US3] Add unit coverage for deterministic context-envelope generation, explicit `missing` and inaccessible markers, internal support-reference formatting, and the absence of raw provider payload content in persisted context envelopes in `apps/platform/tests/Unit/Support/SupportRequests/SupportRequestContextBuilderTest.php` and `apps/platform/tests/Unit/Support/SupportRequests/SupportRequestReferenceTest.php`
- [x] T016 [P] [US3] Add shared feature coverage for authorization boundaries and attachment-mode behavior in `apps/platform/tests/Feature/SupportRequests/SupportRequestAuthorizationTest.php`
- [x] T017 [P] [US3] Add feature coverage for support-request audit entries, duplicate submissions creating two distinct records and support references, and the absence of outbound HTTP or `OperationRun` side effects in `apps/platform/tests/Feature/SupportRequests/SupportRequestAuditTest.php`
### Implementation for User Story 3
- [x] T018 [US3] Finalize immutable persistence rules, explicit omission markers, explicit `missing` and inaccessible related-record markers, explicit exclusion of raw provider payload content from persisted context, and redacted audit payload shape in `apps/platform/app/Models/SupportRequest.php`, `apps/platform/app/Support/SupportRequests/SupportRequestContextBuilder.php`, `apps/platform/app/Support/SupportRequests/SupportRequestReferenceGenerator.php`, `apps/platform/app/Support/Audit/AuditActionId.php`, and `apps/platform/app/Services/Audit/WorkspaceAuditLogger.php`
- [x] T019 [US3] Ensure the first slice introduces no edit flow, status workflow, external ticket reference, or support inbox surface while completing the create path on the two approved surfaces only
**Checkpoint**: User Story 3 is independently functional when support-request creation is deterministic, redacted, audited, and still bounded to the v1 create-only contract.
---
## Phase 6: Polish & Cross-Cutting Concerns
**Purpose**: Align wording, formatting, and the final validation suite before implementation close-out.
- [x] T020 [P] Confirm that `Request support`, `Support reference`, attachment-mode copy, omission markers, and redaction notes stay aligned across `apps/platform/app/Support/SupportRequests/`, `apps/platform/app/Filament/Pages/TenantDashboard.php`, and `apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php`
- [x] T021 Run formatting on touched platform files with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
- [x] T022 Run the focused unit validation suite with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/SupportRequests/SupportRequestContextBuilderTest.php tests/Unit/Support/SupportRequests/SupportRequestReferenceTest.php`
- [x] T023 Run the focused feature validation suite with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/SupportRequests/TenantSupportRequestActionTest.php tests/Feature/SupportRequests/OperationRunSupportRequestActionTest.php tests/Feature/SupportRequests/SupportRequestAuthorizationTest.php tests/Feature/SupportRequests/SupportRequestAuditTest.php`
- [x] T024 Record the final guardrail close-out and any bounded `document-in-feature` note for attachment-mode wording or tenant-dashboard exemption handling in `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/plan.md` and `/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/246-support-request-context/checklists/requirements.md`
---
## Dependencies & Execution Order
### Phase Dependencies
- Phase 1 starts immediately.
- Phase 2 depends on Phase 1 and blocks all user stories.
- Phase 3 depends on Phase 2 and establishes the MVP tenant-context request flow.
- Phase 4 depends on Phase 2 and is safest after Phase 3 because both stories extend the same shared support-request capture path.
- Phase 5 depends on Phase 3 and Phase 4 because deterministic attachment, authorization, and audit behavior must cover both approved contexts.
- Phase 6 depends on every implemented story.
### User Story Dependencies
- US1 is the MVP and first independently shippable increment.
- US2 is independently testable but shares the same support-request capture path, so merge order should favor US1 first.
- US3 depends on both P1 stories because deterministic context and audit proof must cover the shared request contract across both contexts.
### Within Each User Story
- Write the listed Pest coverage first and ensure it fails before implementation.
- Complete shared capture-path changes before the final surface wiring pass when both are required.
- Re-run the narrowest affected unit or feature suite after each story checkpoint before moving to the next story.
---
## Parallel Opportunities
### Phase 1
- T001 and T002 can run in parallel if one person confirms the feature package while another confirms the existing support-aware code seams.
### Phase 2
- T004 and T006 can run in parallel after T003 and T005 define the persisted support-request truth and shared capture shape.
### User Story 1
- T007 can start before runtime edits.
- T008 and T009 can overlap once the shared capture path exists.
### User Story 2
- T011 can start before runtime edits.
- T012 and T013 can overlap once the shared capture path exists.
### User Story 3
- T015, T016, and T017 can run in parallel.
- T018 and T019 should stay sequential because both finalize the shared persistence and guardrail boundaries.
---
## Implementation Strategy
### MVP First
1. Complete Phase 1.
2. Complete Phase 2.
3. Complete Phase 3 (US1).
4. Re-run the tenant-context suite and stop for review.
### Incremental Delivery
1. Deliver US1 to compress tenant-context support intake first.
2. Add US2 so the same request truth can start from the canonical run detail surface.
3. Add US3 to harden deterministic context, authorization, and audit behavior while keeping the slice bounded.
### Team Strategy
1. Finish Phase 2 together before splitting work.
2. Parallelize test authoring inside each story.
3. Sequence merges carefully around `apps/platform/app/Support/SupportRequests/SupportRequestContextBuilder.php`, because every story extends the same shared capture path.