Role: SharePoint fidelity researcher (read-only). Find how on-prem SharePoint makes a failed or stalled workflow visible: workflow status Error Occurred, the Workflow History list, the task list, alerts. Map it reuse-first onto SPICE parts (EventReceiver, Alert, Issues list on the Governance hub, WorkflowHistory) for GOV.5: a seat harness posts start and finish, and a dead-lettered task becomes an Issue on Compliance. Deliver in TaskOutcome: the SharePoint names, the SPICE parts that already carry them, and the smallest cycle spec.
Outcome (spice-sp-fidelity-researcher, 2026-09-30): Real SP: SPWorkflowStatus incl. 'Error Occurred'; the Workflow History list (WorkflowHistory content type, SPWorkflow.CreateHistoryEvent(outcome<=255,description,otherData), event types WorkflowStarted/Completed/Cancelled/Error/TaskCreated/TaskCompleted, viewed at /Lists/Workflow History/allitems.aspx); Alerts (SPAlertTemplate, Immediate/Daily/Weekly); Task Status vocabulary Not Started/In Progress/Completed/Deferred/Waiting on someone else (0x0108). SPICE already has the dead-letter half wired: Field.TaskState (SPICE.Web/Config/Parts.xml:5127) carries SP's five Task states verbatim incl. Deferred; tools/spice-worker/worker.py:190 already sets Status=Deferred + '[dead-letter after N attempts]' into TaskOutcome after 3 failed rounds - SPICE's Error-Occurred analogue, just not surfaced anywhere. Reuse-first map: ContentType.Issue + ListTemplate.Issues (Parts.xml:6112) on /sites/Compliance (the Governance hub, Setting Governance=06|/sites/Compliance); Alert.HealthIssueOpened (Parts.xml:5143, List=Issues, Department=Hub, EventType=Add) ALREADY notifies the operator on any new Issue there - zero new part; Skill.HealthReview/Workflow.WatchdogReview/Schedule.WatchdogReview/Board.Health read 'open fault Issues' via KnowledgeRef OpenIssues (ListView('Issues')) - SP's Workflow History + Health Analyzer already fused and live. TaskComments relay (SPWAY.2f): Field.TaskComments (SPICE.Apps.Erp.Tp/Parts.Tp.xml:54, AppendOnly=true) is generically consumed by ItemUpdateService.cs:102-117 (any ContentType with an AppendOnly FieldRef gets stamped accumulation for free) but today only referenced by ContentType.ProjectTask, one direction (source->seat via ProjectTaskDelegationListener.RelayComment). SMALLEST CYCLE: (1) XML-only - add <FieldRef Id='Field.TaskComments' Required='false'/> to ContentType.CrewTask (reuses the existing FieldDefinition verbatim, no new part, no ask-first). (2) worker.py - reuse set_task's existing tool_update_list_item call, add field-TaskComments alongside field-Status on claim (start line) and on both finish branches (finish/dead-letter line) - a kwarg, not a new call. (3) On the dead-letter branch only, ONE more call: tool_add_list_item site=Compliance list=Issues ContentType.Issue (Title/Body/IssueReporter=seat, Department=Hub so Alert.HealthIssueOpened fires automatically) - the harness already knows this fact with certainty, so routing it through a declarative EventReceiver+Skill (an LLM re-deriving a fact already known) is not reuse-first, it is a cost regression; the existing Alert + Watchdog KnowledgeRef ARE the 'rules are data' half, already built. (4) Test: extend worker.py's self_test() (existing t0/t1/t2 assert-based scenarios, worker.py:211+ fake HTTP harness) with a t3: 3 failed attempts -> assert an Issues AddListItem POST fired with the right fields and TaskComments carries start+dead-letter lines. RISKS: KB.SharePointFidelityGapSurvey (Parts.xml ~5120, Tag sharepoint-fidelity) claims 'EventReceiver Event=ItemUpdated validates and never fires' - VERIFIED STALE: EventReceiverDispatcher.cs:64 (comment 'SPF.7') + ItemUpdatedFanout.cs:35 show OnItemUpdatedAsync IS dispatched and IS the live mechanism SPWAY.2f's relay already depends on - flag that KB row for correction, do not re-cite it forward. Field.TaskComments as a second FieldRef target is a normal many-to-one SAF shape (Field.Body is reused the same way); place it after Field.TaskOutcome, before <Transitions> to match ContentType.ProjectTask's own ordering. DO NOT BORROW: a dedicated Workflow History LIST - IAuditLog (V13.5, one row per EventReceiver fire) already gives a durable trail per the gap survey's own 'already better or equal' list; a second history list would duplicate it for no gain.