Add daily logs and templates for project fidelity
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
This commit is contained in:
@@ -0,0 +1,50 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user