david.delagneau
dbc1894e27
- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People." - Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views. - Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation. - Updated scripts and prompts to reflect the new project-knowledge directory structure. - Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps. - Ensured all references in workflows and scripts point to the new project-knowledge paths.
51 lines
2.3 KiB
Markdown
51 lines
2.3 KiB
Markdown
---
|
|
type: workstream
|
|
project: fidelity
|
|
status: active
|
|
systems: [xflowsdk, fid4, cogstore]
|
|
work-items: [pdiap-15765]
|
|
related: [xflow-debugging, flow-page-references]
|
|
updated: 2026-04-16
|
|
tags:
|
|
- workstream
|
|
- fidelity
|
|
---
|
|
# AO And Discourse Issues
|
|
|
|
## Goal
|
|
|
|
Handle externally reported issues without misclassifying scope or over-claiming regression.
|
|
|
|
---
|
|
|
|
## Stable Patterns
|
|
|
|
- AO and Discourse reports are often incomplete or partially reproducible.
|
|
- External reports should be treated as external behavior until verified.
|
|
- Many issues only reproduce with authenticated users or in consumer-specific contexts.
|
|
- Some historical reports turned out to be service/configuration issues, environment issues, or existing behavior rather than new regressions.
|
|
- AO-backed flows still carry older service conventions that can differ from what newer XFlow SwiftUI paths were primarily validated against.
|
|
- In at least some AO validation cases, iOS expected `validations` while older AO payloads could still send fallback-style keys such as `birthDate`.
|
|
|
|
---
|
|
|
|
## Investigation Rules
|
|
|
|
- Always clarify:
|
|
- authenticated vs non-authenticated
|
|
- reproducibility
|
|
- entry point
|
|
- whether the issue exists in main
|
|
- whether the behavior is external, existing, or regression
|
|
- Do not use vague comparison phrases like "same behavior" without scope.
|
|
- For AO consumers, check whether the payload shape reflects older AO service conventions before concluding the issue is purely client-side.
|
|
- If iOS-only behavior appears around validation decoding, compare what AO sends against older fallback handling already present in XFlow, especially when Android appears more permissive.
|
|
|
|
---
|
|
|
|
## Historical Signals From Slack
|
|
|
|
- Historical reports around button visibility, analytics, slot updates, and consumer validation repeatedly required deeper reproduction work before scoping a fix.
|
|
- Slack history shows multiple examples where the original ticket or report was not enough to define the real root cause.
|
|
- Jeff clarified on April 15, 2026 that these fallback validation paths exist largely to accommodate AO flows. AO was the earliest service integration, built around older custom backend tooling and harder-to-change payload conventions, while newer consumer services were primarily built through Slate and aligned more naturally with `validations` during the SwiftUI refactor.
|