98 lines
3.4 KiB
Markdown
98 lines
3.4 KiB
Markdown
# Project Context - Fidelity
|
|
|
|
## Overview
|
|
|
|
This workspace supports daily iOS engineering work for Fidelity.
|
|
|
|
The product work happens outside this repository, usually from another machine. This repository exists to preserve context, track communication, and help AI generate accurate output for standups, Mattermost messages, Jira notes, and supervisor updates.
|
|
|
|
---
|
|
|
|
## Fidelity Ecosystem
|
|
|
|
- Fid4 is the main consumer iOS app
|
|
- XFlowSDK powers backend-driven UI flows
|
|
- XFlowViewMaker is an adapter layer under evaluation for removal
|
|
- FTFrameworks contains feature modules such as FTAccountOpen and FTTransfer
|
|
|
|
---
|
|
|
|
## Current Priorities
|
|
|
|
### REST migration
|
|
|
|
- REST is behind a feature flag
|
|
- GraphQL is still the default fallback
|
|
- REST should never be assumed active unless confirmed
|
|
- Migration must preserve behavior while Apollo is deprecated safely
|
|
|
|
### Discourse and AO issues
|
|
|
|
- External reports are often incomplete
|
|
- Many reported issues are not confirmed regressions
|
|
- Some issues reproduce only with authenticated users
|
|
|
|
### Flow debugging
|
|
|
|
- XFlow behavior changes based on backend configuration
|
|
- Entry point affects what the user sees
|
|
- Authentication state affects reproducibility
|
|
|
|
### Testing complexity
|
|
|
|
- Around 15 entry points have been identified at code level
|
|
- Not all entry points are reachable from visible UI
|
|
- Validation often requires exploratory testing
|
|
|
|
## Historical Slack patterns
|
|
|
|
- XFlow SwiftUI migration discussions repeatedly covered Next-button visibility, markdown modal presentation, and custom nav pin/unpin behavior
|
|
- Some historical pipeline failures were traced to Apex/ApexKit or Swift preview macro support in the consuming pipeline, not just XFlow itself
|
|
- Jeff often requested explicit, polished wording for PR descriptions and cross-team messages
|
|
- Historical discussions also surfaced recurring uncertainty around XFlow ownership boundaries versus consumer-app responsibility
|
|
- Cross-team dependency issues sometimes involved security, token access, or external pipeline configuration rather than only iOS code changes
|
|
- Historical AO and consumer bugs often turned out to be service/configuration issues, incomplete reproduction reports, or consuming-app integration issues rather than XFlow regressions
|
|
- Historical integration work repeatedly involved XFlowViewMaker, FTBusiness, FTFrameworks, and Fid4 release/version coupling, especially when validating fixes in real consumer flows
|
|
|
|
---
|
|
|
|
## How This Workspace Is Used
|
|
|
|
This machine is used to:
|
|
|
|
- maintain current project context
|
|
- record findings from work performed elsewhere
|
|
- capture Mattermost communication that changes understanding
|
|
- prepare polished updates for the current manager or stakeholder
|
|
- generate standups with better context coverage
|
|
|
|
This means logs must capture both technical findings and communication context.
|
|
|
|
---
|
|
|
|
## People Context
|
|
|
|
- The current manager role is mapped in `ai/context/people/manager.md`
|
|
- The active people roster lives in `ai/context/people/index.md`
|
|
- Repeatedly relevant named people should have individual files under `ai/context/people/`
|
|
|
|
---
|
|
|
|
## Communication Expectations
|
|
|
|
All important updates should clarify:
|
|
|
|
- whether the flow is authenticated or non-authenticated
|
|
- whether the issue is reproducible
|
|
- whether the report is external behavior or regression
|
|
- whether behavior is present in main
|
|
- what action is needed next
|
|
|
|
Avoid phrases that hide scope, such as:
|
|
|
|
- "same behavior"
|
|
- "looks fixed"
|
|
- "working as expected"
|
|
|
|
Use explicit framing instead.
|