Pillar B Outlook add-in: UAT findings 2026-08-31 (2 pre-existing master bugs fixed, 2 open)

[spaarke-dev]

Live UAT of the deployed Outlook add-in (Success Criterion 7) surfaced 6 issues, root-caused via code + App Insights. Full write-up: projects/email-communication-intelligence-r2/notes/pillar-b-uat-findings-2026-08-31.md.

Fixed (on branch work/email-communication-intelligence-r2; need deploy + master PR)

• ci(deps): bump actions/download-artifact from 4 to 5 #3 Priority mapping (PRE-EXISTING MASTER BUG) — UploadFinalizationWorker wrote sprk_priority=192350001-3 to sprk_emailartifact; valid option set is 100000000-3. Dataverse rejected every EmailArtifact create → email save aborted (no .eml, no SPE file). Affects ALL environments. Fixed c0bd37fdc.
• deps: Bump FluentAssertions from 6.12.0 to 8.7.0 #6 Contacts sync 400 (PRE-EXISTING MASTER BUG) — RecordSyncJob contact $select used parentcustomerid; Web API needs _parentcustomerid_value. Failed the contacts sync every ~15 min (0x80060888). Fixed in 35b12c560.
• ci(deps): bump actions/checkout from 4 to 5 #4 Attachments not becoming child Documents — OfficeJobQueue derived HasAttachments from an unpopulated field; add-in sends SelectedAttachmentFileNames. Fixed cfae9cdc1.
• ci(deps): bump azure/webapps-deploy from 2 to 3 #1 NAA broker redirect — add-in Entra reg lacked the brk-… SPA redirect for the deployed origin; added via az rest. Fold into task 004 / auth-deployment-setup.

Open

• ci(deps): bump actions/setup-dotnet from 4 to 5 #2 Entity search is a server STUB — OfficeService.SearchEntitiesAsync returns GenerateStubResults, never queries Dataverse. Tracked by Replace mock/stub Dataverse implementations with real queries #229. Client wiring now correctly calls the real endpoint, exposing the stub. Needs real FetchXML impl across Matter/Project/Invoice/Account/Contact (security-trimmed, paged, tested).
• deps: Bump coverlet.collector from 6.0.2 to 6.0.4 #5 Email .eml archives never AI-indexed — all archives sprk_searchindexed=false; the upload worker queues AI analysis + RAG indexing, so the failure is downstream. Not yet root-caused.

Related: #229.

[spaarke-dev]

#5/#7 document-profile failure — ROOT-CAUSED (2026-09-01, runtime App Insights capture)

Not the Office save path — a shared AI-orchestration bug.

The profile playbook's "Update Record" node (sprk_playbooknode 0fa4e8db-…) has fieldMappings[].value = "{{output_aiAnalysis.output.sprk_filesummary}}". At runtime the orchestrator string-substitutes the AI summary (long, multi-line) into that JSON value without JSON-escaping the newlines → invalid JSON:

JsonException: '0x0A' is invalid within a JSON string. Path: $.fieldMappings[0].value

→ UpdateRecordNodeExecutor.ParseConfig throws → null → node fails → playbook stops → filesummarystatus=Failed on every document.

Masked because the STORED config is a valid {{template}} (parses fine in a unit test); only the RENDERED config is invalid.

Fix belongs in PlaybookOrchestrationService: the JSON-aware RenderConfigJsonStructurally (R7 Wave 11) should handle this, but this path falls back to flat string substitution (PlaybookOrchestrationService.cs:2284) which corrupts JSON. Ensure JSON-aware rendering (escape values injected into JSON string positions), or make the flat fallback JSON-safe.

Blast radius: any playbook injecting multi-line/quoted content into a node ConfigJson (Insights, Daily Briefing, …). Governed by docs/architecture/SPAARKE-PLAYBOOK-LLM-OUTPUT-PATTERN.md; AI-orchestration-owned. Recommend a focused fix there.

[spaarke-dev]

#7 (document profiling) — fully investigated + documented, 2026-09-01

Root cause empirically confirmed (live Dataverse node-config pull + the App Insights 0x0A path) and written up authoritatively at docs/architecture/DOCUMENT-PROFILE-AND-AI-EXECUTION-MODELS.md (+ .claude/FAILURE-MODES.md AP-10). Summary:

The "Document Profile" playbook (18cf3cc8-…, graph = AI Analysis → Update Record → Deliver-To-Index) fails at the Update Record node (0fa4e8db-…). Its stored config is the Playbook-Builder wrapper format — an outer object whose configJson property is the real config encoded as a JSON string, with fieldMappings[0] = sprk_filesummary (multi-line). The Layer-1 renderer RenderConfigJsonStructurally parses only the outer wrapper (valid JSON) and flat-renders the multi-line summary into the nested string with raw 0x0A, escaping it at the outer level only. UpdateRecordNodeExecutor.ParseConfig then unwraps via GetString() and re-parses the nested string → JsonException: '0x0A' is invalid within a JSON string. Path: $.fieldMappings[0].value → node fails → playbook stops → sprk_filesummarystatus = Failed.

Correction to the earlier note: it is NOT "falls back to flat substitution at PlaybookOrchestrationService.cs:2284." The outer wrapper is valid JSON, so the structural path runs and that fallback never fires. The real defect is a single-level / nested-string blind spot in the structural renderer (a fix aimed at :2284 would miss).

Why it only bites the add-in: document profiling has two spines — a node playbook (Outlook / app-only background path) and a direct Action ACT-011 (wizard + Compose paths). Only the node playbook re-parses config, so only it is exposed; the direct-Action paths are structurally immune.

Fix options (owner to choose — not yet applied; detail in the doc Part 4):

1. (recommended) make Layer 1 wrapper-aware — recurse into a nested JSON-containing-a-template string so newlines escape at the nested level (fixes Update Record / Create Task / Create Notification / Send Email at once);
2. defer substitution to the executor (it already renders mapping.Value at UpdateRecordNodeExecutor.cs:222);
3. (strategic) route the app-only path onto the direct-Action spine and retire the node playbook for this consumer.

Whichever is chosen, add a rendered-config regression test (multi-line + embedded-quote through the wrapper format) — the existing stored-config test cannot catch this.

This comment is investigation + documentation only; the production renderer is unchanged pending the fix decision.

[spaarke-dev]

Fix up in PR #923 (auto-merge enabled).

Both the targeted renderer fix and the strategic convergence landed together:

• Fix 1 — RenderConfigJsonStructurally is now wrapper-aware (recurses into a nested JSON-containing-a-template string so values escape at the nested level). Fixes Update Record / Create Task / Create Notification / Send Email nodes in any playbook.
• Fix 2 — the app-only/Outlook profiling path now runs on the same direct-Action (ADR-043) spine as the wizard + Compose paths (ACT-011 via ActionRunner), removing it from the node-engine re-parse failure class entirely.
• Leftover DIAGNOSTIC logging in UploadFinalizationWorker removed.

Verified: BFF build 0 err/0 warn; 4658 AI-suite tests pass; new rendered-config regression test guards the fix. Full write-up: docs/architecture/DOCUMENT-PROFILE-AND-AI-EXECUTION-MODELS.md.

[spaarke-dev]

✅ Verified in UAT (post-#923 deploy): document profiling now works end-to-end — confirmed in the Outlook→Spaarke capture path AND in the Document Upload wizard regression. sprk_filesummarystatus reaches Completed with an AI-set document type. Finding #7 is resolved.

(A separate issue surfaced during the same regression — the Document Upload wizard's 'Send Email' follow-on step doesn't send — tracked separately.)