ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects 1 Releases Wiki Activity
61feb48d8a
TenantAtlas/specs/256-external-support-desk-handoff/checklists/requirements.md
ahmido 7b394918ce
Some checks failed
Main Confidence / confidence (push) Failing after 1m48s
Details
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m43s
Details
chore(platform): merge platform-dev into dev (#302) 
Integrates latest TenantPilot platform changes from `platform-dev` into `dev`.

This PR was created by agent on user request; do not merge automatically.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #302
2026-04-29 20:53:36 +00:00

7.8 KiB
Raw Blame History

Preparation Review Checklist: External Support Desk / PSA Handoff

Purpose: Validate the prepared support-handoff package against the repo's guardrail, support-truth, provider-boundary, scoped-visibility, and close-out workflow requirements before implementation
Created: 2026-04-29
Feature: spec.md

Applicability And Low-Impact Gate

  • CHK001 The package explicitly treats this as an operator-facing extension on two existing support-aware actions, so the low-impact N/A path is not used.
  • CHK002 The spec, plan, tasks, and supporting artifacts carry the same bounded slice: existing SupportRequest truth stays authoritative, visibility stays on the current tenant or run support contexts only, handoff remains one-way, one configured target is allowed, and the close-out target remains Guardrail / Exception / Smoke Coverage.

Native, Shared-Family, And State Ownership

  • CHK003 The primary surfaces remain native Filament actions on TenantDashboard and TenantlessOperationRunViewer instead of a support-request resource, support queue, helpdesk shell, or standalone external-desk page.
  • CHK004 Shared support families remain shared: the internal SR-... support request stays the canonical truth, the latest handoff summary stays attached to the same two support actions, and the package does not invent a parallel support history or ticket-register surface.
  • CHK005 Page, detail, action-form, and persisted state owners are named once: support_requests is the only planned persisted truth, while the tenant and run pages own only current-context presentation and submit-time form state.
  • CHK006 The likely next operator action and primary inspect/open model stay coherent: the operator uses the existing Request support action, chooses one handoff mode inside that form, and does not branch into a second workflow family.

Shared Pattern Reuse

  • CHK007 Cross-cutting interaction classes are explicit, and the shared reuse path is named once through SupportRequestSubmissionService, SupportRequestContextBuilder, SupportRequestReferenceGenerator, WorkspaceAuditLogger, UiEnforcement, and the existing support-aware action surfaces.
  • CHK008 The package extends existing shared paths where they are sufficient, and the only allowed deviation is one concrete provider-owned handoff service plus one tiny latest-summary read helper if implementation proves it necessary, not a generic helpdesk registry or page-local HTTP path.
  • CHK009 The package does not create a parallel operator UX language; Request support, Support reference, External ticket, Create external ticket, Link existing ticket, and TenantPilot only versus TenantPilot + external support desk stay consistent across tenant, run, notification, and audit wording.

OperationRun Start UX Contract

  • CHK019 The package explicitly states that the run surface uses the current OperationRun only as support context and does not create, queue, deduplicate, resume, block, complete, or deep-link to a run workflow as part of the handoff slice.
  • CHK020 Run-specific workflow contracts stay on the existing canonical run page; queued toast/link/browser-event/dedupe behavior is not reintroduced locally for support handoff.
  • CHK021 No queued DB notification or terminal-notification path is added because the slice stays synchronous inside the current support-request submit path.
  • CHK022 No OperationRun exception is required in the preparation package; if implementation later adds retries, queueing, or run-orchestration semantics, that must be recorded as out-of-scope drift in the active close-out entry.

Provider Boundary And Vocabulary

  • CHK010 Provider-specific semantics stay behind one concrete provider-owned handoff service and one preconfigured target-resolution seam; the planned persisted truth stays neutral on SupportRequest with handoff mode, external reference, external URL, and bounded failure summary only.
  • CHK011 No retained provider-specific shared boundary or second-target abstraction is introduced; multi-provider support, target-management UI, and broader ITSM or helpdesk modeling remain follow-up-spec work only.

Signals, Exceptions, And Test Depth

  • CHK012 The triggered repository signal is explicitly handled as review-mandatory: the package adds a new provider seam and new persisted fields, but it does so on the existing support-request truth without hidden queue, resource, or support-framework drift.
  • CHK013 One bounded contract exception is explicit in the preparation package: Spec 256 allows exactly one synchronous finalization write on the same SupportRequest row after internal creation, limited to external handoff fields only. Any wider mutability, retry orchestration, or support-history spread must still be documented in the active feature close-out entry instead of becoming silent scope growth.
  • CHK014 The required surface test profile is explicit: standard-native-filament for the tenant dashboard action, monitoring-state-page for the run action, and focused Unit plus Feature proof for handoff branching, scoped summary reuse, authorization, and audit behavior.
  • CHK015 The chosen lane mix is the narrowest honest proof for this slice: focused Pest unit plus feature coverage with narrow manual smoke after implementation, and no implicit browser-only, global-search, or new resource coverage obligation is invented.

Audience-Aware Disclosure And Decision Hierarchy

  • CHK023 Default-visible content stays decision-first: current support context, one handoff-mode decision, one latest bounded handoff summary, and one submit action remain primary.
  • CHK024 The package keeps raw/provider-heavy material out of default-visible truth: no raw payloads, credentials, provider response bodies, assignee or SLA fields, retry status, or cross-scope lookup shortcuts are allowed into the support-request row or default UI copy.
  • CHK025 Exactly one dominant next action remains primary: Submit support request; external create or link is modeled as a form choice, not as a competing primary action or second workflow entry point.
  • CHK026 Duplicate visible truth is avoided by naming one internal support reference and one latest context-scoped handoff summary instead of introducing a ticket history block, queue summary, or separate support register surface.
  • CHK027 Support or raw detail stays hidden or provider-owned, and latest handoff visibility remains bounded to the same entitled tenant or current run context with the existing 404 versus 403 rules.

Review Outcome

  • CHK016 Review outcome class: acceptable-special-case
  • CHK017 Workflow outcome: keep
  • CHK018 The final note location is explicit: the active feature PR close-out entry Guardrail / Exception / Smoke Coverage should record target-prerequisite status, any bounded implementation exception, and the final proof or smoke outcome.

Notes

  • This checklist validates the preparation package only: spec.md, plan.md, tasks.md, research.md, data-model.md, quickstart.md, and the conceptual contract. It does not claim application code exists.
  • The slice remains bounded to the existing support-request truth and the two existing support-aware actions only. No support-request resource, support queue, helpdesk framework, global-search surface, or OperationRun workflow is approved by this package.
  • Preparation note: the package now makes the single-target resolution seam explicit through apps/platform/config/support_desk.php and keeps workspace settings UI, per-workspace target management, second-target support, and retry or relink orchestration as later follow-up scope.
  • Preparation note: Spec 256 explicitly narrows Spec 246 immutability for one synchronous handoff-finalization write only; no broader edit, reopen, merge, or lifecycle workflow is approved by this package.