Refactor workspace structure and documentation
- Deleted obsolete files: obsidian-vault.md, onboarding.md, workspace-model.md - Updated opencode.json to remove references to deleted files. - Revised profile.md to clarify the status of legacy paths and communication evidence. - Adjusted prompts to reflect new file paths and improve clarity. - Enhanced daily logs with focus, work-items, and blockers properties. - Updated work-item notes to include systems, workstreams, people, and related properties. - Improved context maintenance guidelines to ensure accurate and durable project knowledge. - Refined base filters to exclude template files and ensure only relevant notes are displayed. - Updated daily templates to ensure proper formatting and consistency. - Modified workflows to align with the new vault structure and improve context synchronization.
This commit is contained in:
136
ai/AGENTS.md
136
ai/AGENTS.md
@@ -1,136 +0,0 @@
|
||||
# AGENTS.md
|
||||
|
||||
## Role
|
||||
|
||||
Senior iOS engineer supporting Fidelity from a companion AI workspace.
|
||||
|
||||
This workspace is used to maintain context, organize communication, and draft accurate updates while the main implementation work happens on a different machine.
|
||||
|
||||
The reusable operating model lives in `core/`. Fidelity is the active project profile in `profiles/fidelity/`.
|
||||
|
||||
The canonical clean knowledge base now lives in `vault/`. Legacy `ai/` and `knowledge/` paths remain as compatibility references during migration.
|
||||
|
||||
---
|
||||
|
||||
## Primary Responsibilities
|
||||
|
||||
- Keep project context current
|
||||
- Convert Mattermost communication into structured notes
|
||||
- Draft standups and manager updates
|
||||
- Improve technical messages before sending them to the current manager or stakeholder
|
||||
- Translate rough notes into concise US English without changing meaning
|
||||
|
||||
---
|
||||
|
||||
## Fidelity Context
|
||||
|
||||
- REST migration is replacing GraphQL over time
|
||||
- REST is behind a feature flag
|
||||
- GraphQL remains fallback
|
||||
- XFlow is backend-driven
|
||||
- Discourse and AO issues are often incomplete or ambiguous
|
||||
|
||||
---
|
||||
|
||||
## Communication Style
|
||||
|
||||
Always structure technical updates as:
|
||||
|
||||
1. Context
|
||||
2. Observation
|
||||
3. Action
|
||||
|
||||
When drafting messages for a manager or stakeholder:
|
||||
|
||||
- be concise
|
||||
- be specific
|
||||
- avoid vague comparisons
|
||||
- make status and scope explicit
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- Do not imply code changes were made from this workspace unless explicitly stated
|
||||
- Treat this repository as a context and communication layer, not the product codebase
|
||||
- Always clarify authenticated vs non-authenticated behavior
|
||||
- Do not assume REST is default
|
||||
- Separate external issues from regressions
|
||||
- State reproducibility clearly
|
||||
- If the user provides rough Spanish notes, translate them into natural US English
|
||||
- Preserve technical meaning when polishing communication
|
||||
|
||||
---
|
||||
|
||||
## Context Maintenance
|
||||
|
||||
- Treat workspace files as persistent memory, not just reference notes
|
||||
- Treat `vault/` as canonical memory when a vault equivalent exists
|
||||
- Treat `core/` as project-independent workspace logic and keep Fidelity-specific facts in profile/context files
|
||||
- Treat Obsidian as an optional navigation layer over the same Markdown files, not as a separate source of truth
|
||||
- Do not treat `vault/.obsidian/workspace*.json`, plugin caches, or local Obsidian layout changes as project memory
|
||||
- Prefer generic `AIW_*` integration variables for new tooling while preserving `FIDELITY_*` fallbacks for compatibility
|
||||
- Before answering prompts about current work, verify `vault/01-current/current-work.md` and the latest relevant daily note in `vault/06-daily/`
|
||||
- Before answering architecture, process, or historical questions, check the relevant file under `vault/03-context/systems/`, `vault/03-context/workstreams/`, or `vault/03-context/process/`
|
||||
- Before answering Swift, SwiftUI, iOS architecture, testing, or debugging questions, check `vault/03-context/ios/` and use the project-local iOS skills when available
|
||||
- Before generating a prompt for another AI or GitHub Copilot, check `vault/03-context/process/ai-to-ai-prompting.md` and make the prompt self-contained
|
||||
- If `ai/inbox/mattermost-latest.md` exists, check it before answering prompts about current status, standups, or supervisor communication
|
||||
- If the user asks for the latest/last/recent Mattermost message, the latest message from Jeff/current manager, or what someone just said, synchronize Mattermost first and then answer from the refreshed inbox
|
||||
- If automatic refresh is uncertain, use the explicit latest-message flow: run the Mattermost sync command, then answer from refreshed output only
|
||||
- Treat all meaningful user prompts as potential memory updates, not only explicit sync commands
|
||||
- Treat meaningful user corrections about workspace behavior as tool-maintenance inputs, not only as notes. If a correction affects a command, prompt, agent, skill, or knowledge rule, update that linked file directly.
|
||||
- If a Mattermost sync or other context-ingestion step fails, do not update `vault/06-daily/`, `vault/01-current/`, or stable context files based on that failure
|
||||
- Do not record missing dependencies, failed sync attempts, or missing inbox files as project facts unless the user explicitly asks to track the operational issue
|
||||
- Auto-promote Mattermost content when it is clearly project-relevant, explicit, and high-confidence
|
||||
- Auto-promote direct user-provided project facts when they are clearly project-relevant, explicit, and useful for future sessions
|
||||
- Default promotion target is `vault/06-daily/YYYY-MM-DD.md`
|
||||
- Promote to `vault/01-current/current-work.md` only when the fact changes the active work window
|
||||
- Maintain `vault/02-work-items/` as the canonical memory for active Jira-linked work and keep `vault/01-current/work-items.md` as the quick summary layer
|
||||
- Promote to `vault/03-context/project.md` only when the fact is durable beyond the current work window
|
||||
- Use `vault/03-context/project.md` as the overview only; put system-specific, workstream-specific, and process-specific durable context in the corresponding subdirectory
|
||||
- Maintain `vault/04-people/` when repeated names, roles, or stakeholder relationships become useful for future sessions
|
||||
- Update existing memory when the new information is a correction, clarification, or refinement of something already stored
|
||||
- Prefer updating stable project context over appending generic operational summaries
|
||||
- Do not leave reusable behavior rules only in daily logs. Promote them to the prompt, command, agent, skill, or process file that controls future behavior.
|
||||
- Do not create daily log entries for tooling activity, sync status, or generic chat noise
|
||||
- For Swift/iOS best-practice answers, distinguish current Apple guidance from project-safe recommendations when Fidelity constraints may change the answer
|
||||
- For Copilot prompts, include only relevant context, tell Copilot what to inspect, and state constraints, non-goals, expected output, and validation
|
||||
- Do not ask the user what should be promoted after a successful sync unless multiple conflicting interpretations are equally plausible
|
||||
- When the user shares relevant new information, update today's log if the information belongs to the daily record
|
||||
- When the user corrects or changes stable context, update the canonical file directly:
|
||||
- `vault/01-current/current-work.md` for current focus or active concerns
|
||||
- `vault/03-context/project.md` for durable project knowledge
|
||||
- `vault/04-people/manager.md` for communication preferences
|
||||
- `vault/04-people/index.md` for active roster mapping
|
||||
- `vault/04-people/<person>.md` for person-specific context
|
||||
- `vault/05-decisions/*.md` for confirmed decisions
|
||||
- If the new fact changes how this workspace should operate, update the linked tool surface as well:
|
||||
- `.opencode/commands/*.md` for slash-command behavior
|
||||
- `prompts/*.md` for reusable output templates
|
||||
- `.opencode/agents/*.md` and `ai/AGENTS.md` for default agent behavior
|
||||
- `.opencode/skills/*/SKILL.md` for specialized workflows
|
||||
- `vault/00-start/*.md` or `vault/03-context/process/*.md` for durable process rules
|
||||
- Prefer updating stale context over leaving conflicting statements in different files
|
||||
- If context is still uncertain, record it in the daily log rather than promoting it to a stable context file
|
||||
|
||||
---
|
||||
|
||||
## Default Turn Behavior
|
||||
|
||||
For day-to-day prompts in this workspace:
|
||||
|
||||
1. Verify the latest relevant context.
|
||||
2. Decide whether the prompt introduces new durable information.
|
||||
3. Update the workspace when needed, whether the source is a normal prompt, a sync, or a drafting conversation, but never from a failed sync or failed tool run.
|
||||
4. Then answer using the refreshed context.
|
||||
|
||||
---
|
||||
|
||||
## Output
|
||||
|
||||
Outputs should be:
|
||||
|
||||
- clear
|
||||
- concise
|
||||
- actionable
|
||||
- manager-ready
|
||||
@@ -1,38 +0,0 @@
|
||||
# Discourse Issues Handling
|
||||
|
||||
## Context
|
||||
|
||||
External reports from AO testing or Discourse may:
|
||||
|
||||
- already exist in main
|
||||
- be partially reproducible
|
||||
- depend on authentication
|
||||
- reflect backend behavior rather than a new regression
|
||||
|
||||
---
|
||||
|
||||
## Decision
|
||||
|
||||
Treat incoming reports as external issues until scope is confirmed.
|
||||
|
||||
---
|
||||
|
||||
## Validation Rules
|
||||
|
||||
Always confirm:
|
||||
|
||||
- reproducibility
|
||||
- environment
|
||||
- auth state
|
||||
- entry point
|
||||
- whether the issue exists in main
|
||||
|
||||
---
|
||||
|
||||
## Communication Rule
|
||||
|
||||
Do not say a report is a regression until comparison has been validated.
|
||||
|
||||
Preferred framing:
|
||||
|
||||
"Investigating external report. Scope, auth state, and reproducibility still being confirmed."
|
||||
@@ -1,30 +0,0 @@
|
||||
# REST vs GraphQL
|
||||
|
||||
## Decision
|
||||
|
||||
Deprecate GraphQL and migrate to REST progressively.
|
||||
|
||||
---
|
||||
|
||||
## Constraints
|
||||
|
||||
- REST is behind a feature flag
|
||||
- GraphQL remains fallback
|
||||
- Behavior parity matters during migration
|
||||
|
||||
---
|
||||
|
||||
## Communication Rule
|
||||
|
||||
When reporting findings:
|
||||
|
||||
- state whether REST was confirmed enabled
|
||||
- avoid implying REST is the default path
|
||||
- call out when behavior may still come from GraphQL fallback
|
||||
|
||||
---
|
||||
|
||||
## Follow-up
|
||||
|
||||
- Remove Apollo when migration is safe
|
||||
- Retire GraphQL-specific tests only after parity is confirmed
|
||||
@@ -1,70 +0,0 @@
|
||||
# Context Index
|
||||
|
||||
## Goal
|
||||
|
||||
Keep stable Fidelity context organized by domain so the agent can load the right information quickly.
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
### `project.md`
|
||||
|
||||
High-level overview of the workspace, current Fidelity scope, and where durable context lives.
|
||||
|
||||
### `systems/`
|
||||
|
||||
Stable context about core product components and how they relate:
|
||||
|
||||
- [systems/fid4.md](./systems/fid4.md)
|
||||
- [systems/xflowsdk.md](./systems/xflowsdk.md)
|
||||
- [systems/xflowviewmaker.md](./systems/xflowviewmaker.md)
|
||||
- [systems/ftframeworks.md](./systems/ftframeworks.md)
|
||||
|
||||
### `ios/`
|
||||
|
||||
Swift and iOS best-practice context for programming questions:
|
||||
|
||||
- [ios/index.md](./ios/index.md)
|
||||
- [ios/current-practices.md](./ios/current-practices.md)
|
||||
- [ios/project-swift-guidance.md](./ios/project-swift-guidance.md)
|
||||
|
||||
### `workstreams/`
|
||||
|
||||
Durable context about recurring streams of work and investigation:
|
||||
|
||||
- [workstreams/rest-migration.md](./workstreams/rest-migration.md)
|
||||
- [workstreams/ao-discourse.md](./workstreams/ao-discourse.md)
|
||||
- [workstreams/xflow-debugging.md](./workstreams/xflow-debugging.md)
|
||||
- [workstreams/xflow-swiftui-migration.md](./workstreams/xflow-swiftui-migration.md)
|
||||
- [workstreams/consumer-integration.md](./workstreams/consumer-integration.md)
|
||||
- [workstreams/flow-page-references.md](./workstreams/flow-page-references.md)
|
||||
|
||||
### `process/`
|
||||
|
||||
Rules and expectations for how work should be communicated and maintained:
|
||||
|
||||
- [process/communication.md](./process/communication.md)
|
||||
- [process/jira-story-rules.md](./process/jira-story-rules.md)
|
||||
- [process/context-maintenance.md](./process/context-maintenance.md)
|
||||
|
||||
### `people/`
|
||||
|
||||
Named people, role mapping, and collaboration context:
|
||||
|
||||
- [people/index.md](./people/index.md)
|
||||
- [people/manager.md](./people/manager.md)
|
||||
|
||||
### `decisions/`
|
||||
|
||||
Confirmed technical or product decisions with ongoing impact.
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
- Load `project.md` and this index first.
|
||||
- Open `systems/` when the question is about architecture, ownership, or integration.
|
||||
- Open `ios/` when the question is about Swift, SwiftUI, iOS architecture, testing, concurrency, or debugging.
|
||||
- Open `workstreams/` when the question is about current priorities, debugging themes, or historical project patterns.
|
||||
- Open `process/` when drafting messages, standups, Jira notes, or deciding how to update memory.
|
||||
@@ -1,62 +0,0 @@
|
||||
# Current iOS And Swift Practices
|
||||
|
||||
## Goal
|
||||
|
||||
Keep Swift/iOS answers modern without turning the workspace into stale API documentation.
|
||||
|
||||
---
|
||||
|
||||
## Currentness Rule
|
||||
|
||||
For version-sensitive recommendations, verify against official sources before presenting as current best practice.
|
||||
|
||||
Prefer:
|
||||
|
||||
- Apple Developer Documentation
|
||||
- Swift.org / docs.swift.org
|
||||
- official WWDC materials when API behavior or migration guidance matters
|
||||
|
||||
Avoid relying only on memory for:
|
||||
|
||||
- newest SwiftUI APIs
|
||||
- Observation / data-flow migration guidance
|
||||
- Swift Testing availability or migration advice
|
||||
- Swift concurrency behavior
|
||||
- Xcode or iOS version-specific recommendations
|
||||
|
||||
---
|
||||
|
||||
## Stable Defaults
|
||||
|
||||
- Prefer simple, testable Swift over clever abstractions.
|
||||
- Prefer structured concurrency over ad-hoc callback or detached-task patterns when the deployment target and codebase support it.
|
||||
- Keep UI state changes on the main actor.
|
||||
- Avoid recommending new APIs until deployment target and project constraints are known.
|
||||
- For SwiftUI, separate pure view composition from side effects and navigation/workflow coordination.
|
||||
- For testing, use the framework already adopted by the codebase unless the user explicitly asks about migration.
|
||||
|
||||
---
|
||||
|
||||
## Testing Guidance
|
||||
|
||||
- Apple positions Swift Testing as a modern option for unit tests in Xcode 16 and later.
|
||||
- XCTest remains relevant, especially for UI tests, performance tests, and existing test suites.
|
||||
- Do not recommend wholesale migration from XCTest unless the project constraints support it.
|
||||
|
||||
---
|
||||
|
||||
## SwiftUI Guidance
|
||||
|
||||
- Observation can be adopted incrementally; do not assume a project can immediately replace all `ObservableObject` usage.
|
||||
- In SwiftUI code review, focus on data ownership, lifecycle, invalidation scope, navigation boundaries, and side effects.
|
||||
- Avoid introducing `@StateObject`, `@ObservedObject`, `@State`, or `@Observable` recommendations without first identifying ownership and deployment constraints.
|
||||
|
||||
---
|
||||
|
||||
## Source Anchors
|
||||
|
||||
- SwiftUI documentation: `https://developer.apple.com/documentation/swiftui`
|
||||
- Observation migration: `https://developer.apple.com/documentation/swiftui/migrating-from-the-observable-object-protocol-to-the-observable-macro`
|
||||
- Swift Testing: `https://developer.apple.com/documentation/testing`
|
||||
- XCTest: `https://developer.apple.com/documentation/xctest`
|
||||
- Swift language: `https://developer.apple.com/swift/`
|
||||
@@ -1,23 +0,0 @@
|
||||
# iOS And Swift Context
|
||||
|
||||
## Goal
|
||||
|
||||
Help the agent answer Swift and iOS programming questions with current best practices while still respecting Fidelity/XFlow project constraints.
|
||||
|
||||
---
|
||||
|
||||
## Files
|
||||
|
||||
- [current-practices.md](./current-practices.md)
|
||||
Rules for staying current with Apple and Swift best practices.
|
||||
|
||||
- [project-swift-guidance.md](./project-swift-guidance.md)
|
||||
Fidelity-specific guidance for applying Swift/iOS advice in this workspace.
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
- Use these files before answering Swift, SwiftUI, iOS architecture, testing, concurrency, or debugging questions.
|
||||
- When a recommendation depends on current Apple APIs, prefer official Apple or Swift documentation before making strong claims.
|
||||
- Keep project constraints visible: XFlow is backend-driven, Fid4 is consumer validation, and REST/GraphQL migration constraints may affect architecture.
|
||||
@@ -1,37 +0,0 @@
|
||||
# Project Swift Guidance
|
||||
|
||||
## Goal
|
||||
|
||||
Apply Swift/iOS advice in a way that fits Fidelity's XFlow, Fid4, XFlowViewMaker, and FTFrameworks environment.
|
||||
|
||||
---
|
||||
|
||||
## Fidelity-Specific Constraints
|
||||
|
||||
- XFlow is backend-driven; UI behavior may be service/configuration driven, not purely local Swift code.
|
||||
- Fid4 is the real consumer validation target for many issues.
|
||||
- XFlowViewMaker and FTFrameworks can affect whether a fix is visible in Fid4.
|
||||
- REST migration constraints still matter; do not assume REST is active by default.
|
||||
- Some work happens behind feature flags, especially risky consumer-impact changes.
|
||||
|
||||
---
|
||||
|
||||
## SwiftUI / XFlow Priorities
|
||||
|
||||
- Treat modal presentation, dismissal sequencing, and lifecycle boundaries as high-risk areas.
|
||||
- Be careful when removing UIKit bridges such as `UIHostingController`; preserve consumer behavior and rollout safety.
|
||||
- When discussing SwiftUI architecture, include how the change affects:
|
||||
- backend-driven flow rendering
|
||||
- consumer app integration
|
||||
- feature flags
|
||||
- validation in Fid4
|
||||
- UIKit/SwiftUI parity
|
||||
|
||||
---
|
||||
|
||||
## Answering Rules
|
||||
|
||||
- If the user asks a general Swift question, answer generally but include a Fidelity/XFlow note when relevant.
|
||||
- If the user asks about a code change, separate modern best practice from what is safe for the current project.
|
||||
- If codebase constraints are unknown, say what must be confirmed: deployment target, Xcode version, module ownership, feature flag path, and consumer validation path.
|
||||
- For manager-ready explanations, connect the technical recommendation to scope, risk, and validation.
|
||||
@@ -1,19 +0,0 @@
|
||||
# People Context
|
||||
|
||||
Store reusable human context here.
|
||||
|
||||
Use this directory for:
|
||||
|
||||
- who is who
|
||||
- current role ownership
|
||||
- communication preferences
|
||||
- recurring stakeholders
|
||||
- stable relationship between people and project work
|
||||
|
||||
Guidelines:
|
||||
|
||||
- use one file per named person when that person matters repeatedly
|
||||
- keep `manager.md` as the role mapping for the current active manager
|
||||
- keep `index.md` as the quick roster for the active project
|
||||
- do not put secrets here
|
||||
- do not invent roles; use qualifiers when uncertain
|
||||
@@ -1,24 +0,0 @@
|
||||
# Aylwing Olivas
|
||||
|
||||
## Role
|
||||
|
||||
Repeated Fidelity collaborator visible across multiple historical Slack channels.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Appears in technical discussions about XFlow, SwiftUI limitations, navigation architecture, and dependency risk
|
||||
- Surfaces cross-team constraints such as security or token access issues affecting pipeline work
|
||||
- Frequently adds architectural framing rather than only status updates
|
||||
- Often reframes implementation problems at the architecture/system-design level rather than the ticket level
|
||||
- Repeatedly advised on state machines, navigation architecture, off-screen rendering, and long-term maintainability tradeoffs
|
||||
- Common escalation point when the team needs a technical sounding board or higher-level design critique
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Aylwing as a useful source for higher-level technical framing and dependency risk context
|
||||
- Treat Aylwing as a strong reviewer for architecture direction, refactor scope, and risk framing
|
||||
- If future context clarifies the formal team or title, update this file directly
|
||||
@@ -1,21 +0,0 @@
|
||||
# Bruce Meeks
|
||||
|
||||
## Role
|
||||
|
||||
Repeated Fidelity collaborator in XFlow-related work.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Reviewed and approved XFlow work repeatedly in historical threads
|
||||
- Sometimes covered XFlow iOS issues while others were unavailable
|
||||
- Later context suggests Bruce primarily worked on Android while still remaining a useful cross-platform contact
|
||||
- Relevant in release coordination, PR review, and parity discussions between iOS and Android
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Bruce as a useful source for cross-platform context and historical PR/review state
|
||||
- If future context clarifies the formal role/team, update this file directly
|
||||
@@ -1,23 +0,0 @@
|
||||
# David Delagneau
|
||||
|
||||
## Role
|
||||
|
||||
Repeated Fidelity collaborator in historical Slack threads.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Appears heavily in pipeline, Jenkins, SonarQube, test-reporting, and release-process work
|
||||
- Later historical activity also includes Sparta SDK proof-of-concept implementation and framework setup work
|
||||
- Often provides implementation updates, process notes, and operational debugging context to Jeff
|
||||
- Frequently handled CI/CD, Jenkins, reporting, and repo/setup tasks while Norman focused on SDK and consumer debugging
|
||||
- Later archive activity shows him taking lead on SpartaSDK setup, JSON decoding, and repo/bootstrap work
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat David as a relevant source for CI/CD, release-process, and framework-setup context
|
||||
- Treat David as especially relevant for Jenkins, SonarQube, Pod/repo setup, and Sparta SDK bootstrapping context
|
||||
- If future context clarifies the formal role or team, update this file directly
|
||||
@@ -1,23 +0,0 @@
|
||||
# Derian Cordoba
|
||||
|
||||
## Role
|
||||
|
||||
Historical Fidelity collaborator in project support discussions.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Appears in historical pipeline, Jenkins, and documentation conversations
|
||||
- Helped document pipeline work and supported notification/credential troubleshooting
|
||||
- Collaboration signal is real but current formal role remains unclear from the archive
|
||||
- Often paired with David on CI/CD and notification-related work
|
||||
- Showed up when the team needed operational documentation, release-process notes, or pipeline triage support
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Derian as a relevant collaborator for historical pipeline/debugging context
|
||||
- Treat Derian as most relevant for historical CI/CD coordination and documentation support
|
||||
- If future context clarifies the formal role or team, update this file directly
|
||||
@@ -1,24 +0,0 @@
|
||||
# Erik Reynolds
|
||||
|
||||
## Role
|
||||
|
||||
Historical Fidelity collaborator in XFlow-related discussions.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Appears in discussions about XFlow manager behavior, consumer-vs-framework boundaries, and migration constraints
|
||||
- Raises implementation and sizing concerns in architecture-heavy conversations
|
||||
- Often comments on where responsibility lies between XFlow and consuming teams
|
||||
- Deep archive signal suggests strong familiarity with XFlow and Apex internals, especially ownership boundaries and migration tradeoffs
|
||||
- Often challenged weak assumptions about architecture, sizing, and framework responsibilities
|
||||
- Useful source when deciding whether a problem belongs in XFlow, Apex, or the consumer app
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Erik as a relevant source when historical context touches XFlow ownership boundaries or migration difficulty
|
||||
- Treat Erik as a high-signal source for framework architecture and responsibility boundaries
|
||||
- If future context clarifies the formal role or team, update this file directly
|
||||
@@ -1,25 +0,0 @@
|
||||
# Gurram Santosh
|
||||
|
||||
## Role
|
||||
|
||||
Project-related contact involved in issue discussions.
|
||||
|
||||
The exact formal role is not yet confirmed in workspace memory.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Repeatedly appears in AO-related testing, screenshot validation, and issue verification conversations
|
||||
- Often serves as a consumer-side validator or reporter when the team needs confirmation that a fix worked in their environment
|
||||
- Relevant when tracking whether an issue still reproduces, whether a release build contains a fix, or whether additional consumer validation is needed
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
If future communication makes Santosh's role explicit, update this file with:
|
||||
|
||||
- team or function
|
||||
- relationship to Fidelity work
|
||||
- whether the person is a reporter, tester, partner, or stakeholder
|
||||
@@ -1,53 +0,0 @@
|
||||
# People Index
|
||||
|
||||
## Active Roles
|
||||
|
||||
- Manager: [jeff-dewitte.md](./jeff-dewitte.md)
|
||||
|
||||
## Known People
|
||||
|
||||
- [jeff-dewitte.md](./jeff-dewitte.md)
|
||||
Current direct manager for the active Fidelity project; repeated communication gatekeeper and scope shaper in historical XFlow work.
|
||||
|
||||
- [norman-arauz.md](./norman-arauz.md)
|
||||
Frequent XFlow collaborator in historical Slack threads; primary implementer/investigator across SwiftUI, AO/Fid4 bugs, and release work.
|
||||
|
||||
- [david-delagneau.md](./david-delagneau.md)
|
||||
Repeated historical collaborator on pipeline, CI/CD, and Sparta/SwiftUI proof-of-concept work, especially around Jenkins, reporting, and framework setup.
|
||||
|
||||
- [bruce-meeks.md](./bruce-meeks.md)
|
||||
Repeated XFlow collaborator who often reviewed PRs, covered iOS work during absences, and later shifted primarily toward Android.
|
||||
|
||||
- [jason-mandozzi.md](./jason-mandozzi.md)
|
||||
Repeated collaborator tied to XFlowViewMaker, FTPlanning/Fid4 integration, release support, and major architectural transitions.
|
||||
|
||||
- [aylwing-olivas.md](./aylwing-olivas.md)
|
||||
Repeated historical collaborator who surfaces architectural concerns, SwiftUI constraints, and cross-team dependency risks.
|
||||
|
||||
- [erik-reynolds.md](./erik-reynolds.md)
|
||||
Historical collaborator focused on XFlow manager behavior, integration boundaries, migration effort sizing, and framework responsibility boundaries.
|
||||
|
||||
- [gurram-santosh.md](./gurram-santosh.md)
|
||||
AO-related contact who often validates fixes or confirms whether issues still reproduce in consumer environments.
|
||||
|
||||
- [raj-sundararaj.md](./raj-sundararaj.md)
|
||||
Repeated collaborator involved in AO issue triage, release coordination, and backlog/story management around XFlow work.
|
||||
|
||||
- [quy-mai.md](./quy-mai.md)
|
||||
Scrum/contact point who repeatedly managed backlog state, points, and closure expectations for Fidelity work.
|
||||
|
||||
- [tim-longfield.md](./tim-longfield.md)
|
||||
FTPlanning-side contact relevant when issues crossed from XFlow into consumer-framework ownership.
|
||||
|
||||
- [derian-cordoba.md](./derian-cordoba.md)
|
||||
Historical collaborator in pipeline and documentation work, especially around CI/CD support and operational notes.
|
||||
|
||||
## Usage
|
||||
|
||||
When a person appears repeatedly in project communication, create or update their file here so the agent can reuse:
|
||||
|
||||
- name
|
||||
- role
|
||||
- relationship to the project
|
||||
- communication expectations
|
||||
- important context about how they influence work
|
||||
@@ -1,21 +0,0 @@
|
||||
# Jason Mandozzi
|
||||
|
||||
## Role
|
||||
|
||||
Repeated Fidelity collaborator in XFlow and consumer-integration work.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Closely associated with XFlowViewMaker, Fid4/FTPlanning integration, and release/version work
|
||||
- Frequently authored or owned implementation branches later reviewed by others
|
||||
- Showed up repeatedly in architecture, eventing, navigation, and consumer-facing integration discussions
|
||||
- Often served as an important source of context on historical implementation choices inside XFlow and related consumer flows
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Jason as a high-signal source for XFlowViewMaker and consumer integration history
|
||||
- If future context clarifies the formal role/team, update this file directly
|
||||
@@ -1,64 +0,0 @@
|
||||
# Jeff DeWitte
|
||||
|
||||
## Role
|
||||
|
||||
Current direct manager for the active Fidelity project.
|
||||
|
||||
---
|
||||
|
||||
## Historical Collaboration Pattern
|
||||
|
||||
- Repeatedly acted as reporting manager, reviewer, and communication gatekeeper across multi-year XFlow work
|
||||
- Frequently rewrote PR descriptions, Jira updates, and cross-team messages before they were sent
|
||||
- Regularly redirected work based on release risk, consumer pressure, or manager/stakeholder expectations
|
||||
- Often pushed for explicit distinction between framework bugs, consumer bugs, service issues, and scope creep
|
||||
|
||||
---
|
||||
|
||||
## Communication Requirements
|
||||
|
||||
- Native US English
|
||||
- Prefers clear, concise updates
|
||||
- Needs accurate scope, not vague reassurance
|
||||
- Frequently asks for precise reproducibility, auth context, and regression scope
|
||||
|
||||
---
|
||||
|
||||
## What Good Updates Include
|
||||
|
||||
1. Context
|
||||
2. Observation
|
||||
3. Action
|
||||
|
||||
Good updates usually clarify:
|
||||
|
||||
- what issue or task is being discussed
|
||||
- whether the behavior is reproducible
|
||||
- whether auth state matters
|
||||
- whether this looks like an external issue or a regression
|
||||
- what the next step is
|
||||
|
||||
---
|
||||
|
||||
## Influence On Work
|
||||
|
||||
- Story titles, points, and scope discussions with Jeff are often worth remembering
|
||||
- Jeff approvals can change what belongs in current state or work-item memory
|
||||
- Jeff feedback is often a signal to tighten wording before communicating externally
|
||||
- Jeff often asks for evidence, reproduction detail, and exact next action before approving external communication
|
||||
- If a draft is still ambiguous, Jeff may prefer to rewrite it directly so the external version is unambiguous and does not generate avoidable follow-up
|
||||
|
||||
---
|
||||
|
||||
## Repeated Coaching / Expectations
|
||||
|
||||
- Test in the closest real consumer environment first when the issue is consumer-specific; use sample app mainly to rule ownership in or out
|
||||
- Do not open or socialize a PR as "ready" until the issue is fully resolved and no obvious follow-up bug has been introduced
|
||||
- Separate current-ticket scope from unrelated preexisting bugs; do not blur them in standups or status updates
|
||||
- Be explicit about environment, branch/build/version, account, flow entry point, and repro steps before concluding where a bug belongs
|
||||
- When blocked, keep reducing uncertainty with other available evidence sources instead of waiting passively
|
||||
- Fast admin/process actions matter: update Jira/status/comments promptly when others are visibly waiting on them
|
||||
- Prefer evidence-heavy communication: screenshots, videos, exact error text, branch/version, and direct comparisons to main/web/UIKit/Fid4 when relevant
|
||||
- Use polished native-sounding English for external-facing comments; avoid sending rough wording when a cleaner version is easy to produce
|
||||
- When a consumer issue may actually belong to another team/framework, document the finding clearly and route ownership instead of carrying it indefinitely in XFlow
|
||||
- For cross-team status messages, make the sequence of events extremely explicit so the reader can tell what was the original issue, what changed, what XFlow changed, and what remains a separate service-side issue
|
||||
@@ -1,30 +0,0 @@
|
||||
# Manager
|
||||
|
||||
## Current Holder
|
||||
|
||||
- Name: Jeff DeWitte
|
||||
- Profile: [jeff-dewitte.md](./jeff-dewitte.md)
|
||||
|
||||
---
|
||||
|
||||
## Role
|
||||
|
||||
Direct supervisor or primary reporting manager for the active project.
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
This file maps the current project role to the actual person.
|
||||
|
||||
If the active manager changes in a future project, update this file to point to the new person while preserving their person-specific profile separately.
|
||||
|
||||
---
|
||||
|
||||
## Default Communication Requirements
|
||||
|
||||
- Clear written English
|
||||
- Concise updates
|
||||
- Explicit scope
|
||||
- No vague reassurance
|
||||
- Useful next action when relevant
|
||||
@@ -1,22 +0,0 @@
|
||||
# Norman Arauz
|
||||
|
||||
## Role
|
||||
|
||||
Frequent Fidelity/XFlow engineer collaborator in historical Slack threads.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Repeated day-to-day implementer/investigator across XFlow SwiftUI, AO/Fid4 bugs, version bumps, analytics, and pipeline debugging
|
||||
- Often coordinated with Jeff on scope, descriptions, approvals, and manager-ready wording
|
||||
- Frequently investigated consumer-reported issues directly in Fid4 and sample-app parity checks
|
||||
- Often produced detailed technical findings first, then asked Jeff to polish or approve external wording
|
||||
- Exact formal role may need confirmation if used outside workspace memory
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Norman as a strong source for historical implementation detail, reproduction findings, and release-process context
|
||||
- If later communication clarifies the formal team/title, update this file directly
|
||||
@@ -1,21 +0,0 @@
|
||||
# Quy Mai
|
||||
|
||||
## Role
|
||||
|
||||
Confirmed Scrum Master / contact point repeatedly involved in backlog and process management.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Repeatedly asked for clearer Jira/state management, points, and backlog hygiene
|
||||
- Often confirmed whether work should remain in backlog, be canceled, or be reframed as separate stories
|
||||
- Relevant for sprint structure, story cleanup, and expectation-setting around what counts as production or release-priority work
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Quy as an important source for process expectations, backlog cleanup, and story framing
|
||||
- When drafting notes or prompts, refer to Quy as Scrum Master rather than a generic stakeholder
|
||||
- If future context clarifies the formal title/team, update this file directly
|
||||
@@ -1,20 +0,0 @@
|
||||
# Raj Sundararaj
|
||||
|
||||
## Role
|
||||
|
||||
Repeated Fidelity collaborator involved in project coordination and active issue triage.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Repeatedly surfaced or assigned XFlow/AO issues and asked for current status
|
||||
- Involved in release coordination, validation follow-up, and backlog movement
|
||||
- Relevant when the team needed to align issue ownership, repro state, or urgency with consumer-side expectations
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Raj as a useful contact for issue routing, AO coordination, and release follow-up
|
||||
- If future context clarifies the formal role/team, update this file directly
|
||||
@@ -1,20 +0,0 @@
|
||||
# Tim Longfield
|
||||
|
||||
## Role
|
||||
|
||||
FTPlanning-side collaborator relevant to cross-framework issue ownership.
|
||||
|
||||
---
|
||||
|
||||
## Known Context
|
||||
|
||||
- Appeared when issues first thought to be XFlow bugs were traced into FTPlanning
|
||||
- Relevant contact for whether a transfer/add-money bug belonged to FTPlanning instead of XFlow
|
||||
- Useful when a consumer-side framework fix was needed before XFlow could close validation work
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Treat Tim as a relevant contact for FTPlanning-owned fixes and cross-team validation
|
||||
- If future context clarifies the formal role/team, update this file directly
|
||||
@@ -1,69 +0,0 @@
|
||||
# AI-To-AI Prompting
|
||||
|
||||
## Goal
|
||||
|
||||
Generate prompts that can be sent to another AI assistant on the Fidelity development machine, especially GitHub Copilot.
|
||||
|
||||
---
|
||||
|
||||
## Operating Assumption
|
||||
|
||||
This workspace does not contain the product codebase. The target AI has access to the Fidelity codebase on another machine.
|
||||
|
||||
Therefore prompts must:
|
||||
|
||||
- include only the relevant project context from this workspace
|
||||
- tell the target AI what files/modules to inspect
|
||||
- ask for a concrete output
|
||||
- specify constraints and non-goals
|
||||
- avoid pretending the target AI already has this workspace memory
|
||||
|
||||
---
|
||||
|
||||
## Prompt Structure
|
||||
|
||||
Use this structure by default:
|
||||
|
||||
1. Role
|
||||
2. Project context
|
||||
3. Current task
|
||||
4. Relevant ticket/context
|
||||
5. Files/modules to inspect
|
||||
6. Constraints
|
||||
7. Expected output
|
||||
8. Validation requirements
|
||||
|
||||
---
|
||||
|
||||
## Prompt Quality Rules
|
||||
|
||||
- Prefer precise task framing over long background dumps.
|
||||
- Include Jira ID and title when the work maps to a ticket.
|
||||
- Include current constraints such as REST feature flag, GraphQL fallback, auth state, backend-driven behavior, and consumer validation when relevant.
|
||||
- Ask the target AI to inspect code before proposing changes.
|
||||
- Ask for a plan first when the implementation scope is uncertain.
|
||||
- Ask for code changes only when the desired write scope is clear.
|
||||
- Include "Do not assume REST is active by default" for REST migration tasks.
|
||||
- Include "Separate external issue from regression" for AO/Discourse issues.
|
||||
- Include "Validate against Fid4/consumer path when needed" for XFlow integration tasks.
|
||||
|
||||
---
|
||||
|
||||
## Bad Prompt Pattern
|
||||
|
||||
"Fix this issue in XFlow."
|
||||
|
||||
Why bad:
|
||||
|
||||
- no entry point
|
||||
- no auth state
|
||||
- no expected behavior
|
||||
- no ticket context
|
||||
- no validation path
|
||||
- no scope boundary
|
||||
|
||||
---
|
||||
|
||||
## Good Prompt Pattern
|
||||
|
||||
"You are working in the Fidelity iOS codebase. Inspect the XFlowSDK and XFlowViewMaker integration path for `PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`. First identify where XFlow currently exposes SwiftUI through `UIHostingController`, where XFlowViewMaker consumes it, and what feature flag protects the migration path. Do not change code yet. Return a concise plan with affected files, risks, consumer validation needs in Fid4/FTTransfer, and any questions that block implementation."
|
||||
@@ -1,40 +0,0 @@
|
||||
# Communication Rules
|
||||
|
||||
## Goal
|
||||
|
||||
Make technical communication precise enough for manager updates, Jira notes, standups, and cross-team messages.
|
||||
|
||||
---
|
||||
|
||||
## Required Structure
|
||||
|
||||
When the format fits, prefer:
|
||||
|
||||
1. Context
|
||||
2. Observation
|
||||
3. Action
|
||||
|
||||
---
|
||||
|
||||
## Fidelity-Specific Rules
|
||||
|
||||
- Always clarify authenticated vs non-authenticated when behavior depends on it.
|
||||
- Always separate external issues from regressions.
|
||||
- Always state reproducibility and scope.
|
||||
- For standups, report the previous workday context, not blindly the prior calendar day.
|
||||
- On Mondays, use Friday's work context unless a later prior day has Mattermost activity.
|
||||
- If the previous calendar day has no project activity because of weekend, holiday, or OOO, use the latest prior day with Mattermost activity.
|
||||
- For standups, when a Jira item has multiple concrete updates, use one top-level `JIRA-ID - Title` bullet and indented markdown sub-bullets instead of repeating the same Jira line.
|
||||
- When a flow/page shorthand could be ambiguous, prefer the real flow identifier and page name from `ai/context/workstreams/flow-page-references.md`.
|
||||
- Avoid vague phrasing such as:
|
||||
- "same behavior"
|
||||
- "looks fixed"
|
||||
- "working as expected"
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Jeff repeatedly requested polished, explicit wording for PR descriptions, story descriptions, and cross-team messages.
|
||||
- Historical Slack threads show that message quality changed how quickly stories were approved or understood.
|
||||
- Explicit language mattered most when communicating root cause, ownership boundaries, or whether a report was a confirmed regression.
|
||||
@@ -1,37 +0,0 @@
|
||||
# Context Maintenance
|
||||
|
||||
## Goal
|
||||
|
||||
Keep this workspace useful as living memory instead of a pile of disconnected notes.
|
||||
|
||||
---
|
||||
|
||||
## Stable Rules
|
||||
|
||||
- Update canonical context when a durable fact changes.
|
||||
- Prefer correcting stale context over appending contradictory notes.
|
||||
- Use the smallest correct destination:
|
||||
- `ai/logs/YYYY-MM-DD.md` for daily progress and evolving findings
|
||||
- `ai/state/current.md` for near-term active work
|
||||
- `ai/work-items/*.md` for canonical Jira-linked active work
|
||||
- `ai/state/work-items.md` for the compact active-work summary
|
||||
- `ai/context/` for durable project knowledge
|
||||
- `ai/context/people/` for named person context
|
||||
- `.opencode/commands/`, `prompts/`, `.opencode/agents/`, `.opencode/skills/`, or `knowledge/` for reusable behavior rules that control how the workspace responds
|
||||
|
||||
---
|
||||
|
||||
## Ingestion Rules
|
||||
|
||||
- Treat Mattermost, Slack history, and direct prompts as potential memory sources.
|
||||
- Do not promote failed syncs or tooling errors as project facts.
|
||||
- Promote repeated durable patterns from historical archives into stable context when confidence is high.
|
||||
- Keep old status-only details archive-only unless they still change current understanding.
|
||||
- Treat user corrections about command output, prompt structure, memory handling, or agent behavior as inputs to the operational surface, not just as daily notes.
|
||||
|
||||
---
|
||||
|
||||
## Curation Rule
|
||||
|
||||
- If a new stable context file is added, keep `project.md` and `index.md` aligned so future sessions can discover it quickly.
|
||||
- If a new rule affects a slash command or reusable prompt, update that command or prompt directly so the behavior changes on the next run.
|
||||
@@ -1,18 +0,0 @@
|
||||
# Process Index
|
||||
|
||||
## Stable Process Guides
|
||||
|
||||
- [communication.md](./communication.md)
|
||||
How to frame technical updates and external communication.
|
||||
|
||||
- [ai-to-ai-prompting.md](./ai-to-ai-prompting.md)
|
||||
How to generate prompts for GitHub Copilot or another AI on the Fidelity development machine.
|
||||
|
||||
- [jira-story-rules.md](./jira-story-rules.md)
|
||||
How to create or reference stories with the right scope and precision.
|
||||
|
||||
- [context-maintenance.md](./context-maintenance.md)
|
||||
How this workspace should be kept current as living memory.
|
||||
|
||||
- [pull-requests.md](./pull-requests.md)
|
||||
PR template and framing notes for repositories such as `xflow-for-ios`.
|
||||
@@ -1,30 +0,0 @@
|
||||
# Jira Story Rules
|
||||
|
||||
## Goal
|
||||
|
||||
Keep Jira updates precise enough that the story reflects the real problem and remains easy to reference later.
|
||||
|
||||
---
|
||||
|
||||
## Stable Rules
|
||||
|
||||
- Preserve Jira ID and explicit title whenever available.
|
||||
- Prefer story wording that describes the real contract or behavior gap, not only the first symptom.
|
||||
- Include authenticated-state or environment qualifiers when they materially affect scope.
|
||||
- Validate consumer behavior before finalizing scope when the issue depends on Fid4 or flagship.
|
||||
|
||||
---
|
||||
|
||||
## Story-Creation Guidance
|
||||
|
||||
- Create or refine the story after the reproduction path is understood well enough to avoid mis-scoping.
|
||||
- Include points and scope only after the work has been framed clearly.
|
||||
- If the issue crosses SDK, adapter, FT modules, and consumer app boundaries, the story should say so.
|
||||
- If a bug is external or not yet confirmed as regression, avoid writing the ticket as if the root cause is already proven.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Historical Slack threads repeatedly show Jeff refining titles and descriptions before stories were created or shared.
|
||||
- Several story discussions centered on making the wording reflect deeper SwiftUI, lifecycle, or integration issues rather than surface symptoms alone.
|
||||
@@ -1,34 +0,0 @@
|
||||
# Pull Requests
|
||||
|
||||
## xflow-for-ios PR Template
|
||||
|
||||
The `xflow-for-ios` repo PR form uses this structure:
|
||||
|
||||
- `## What`
|
||||
- What does the PR do?
|
||||
- Is it a bug fix, new feature, refactor, or something else?
|
||||
- `## Why`
|
||||
- Why this PR is needed?
|
||||
- `## How`
|
||||
- How is it doing what it does?
|
||||
- How to test, how to integrate, any relevant compromises, etc.?
|
||||
- `### Changes details`
|
||||
- bullet list such as `Detail one`, `Detail two`
|
||||
- `## Missed anything?`
|
||||
- checklist including:
|
||||
- explained the purpose of the PR
|
||||
- self-reviewed the PR
|
||||
- added or updated test cases
|
||||
- informed of breaking changes, testing, and migrations if applicable
|
||||
- updated documentation if applicable
|
||||
- attached screenshots if applicable
|
||||
- resolved SwiftLint warnings introduced by the commit
|
||||
|
||||
## Current Small-Fix Example
|
||||
|
||||
For the April 15, 2026 iOS validation fallback fix, the code change is a one-line update in `XFlowViewAdapterRepresentable.swift` for `.apxDateSelect`:
|
||||
|
||||
- before: only `validationDictionary?["validations"]`
|
||||
- after: `validationDictionary?["validations"] ?? validationDictionary?["birthDate"]`
|
||||
|
||||
This should be framed as a small compatibility bug fix for AO-style payloads, not as a broader Android-parity refactor.
|
||||
@@ -1,64 +0,0 @@
|
||||
# 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
|
||||
- Cogstore is the configuration publishing/version-tracking platform used to inspect which flow-definition versions are live in QA or Production
|
||||
|
||||
---
|
||||
|
||||
## Stable Context Map
|
||||
|
||||
- Core systems live under:
|
||||
- `ai/context/systems/`
|
||||
- Durable workstreams live under:
|
||||
- `ai/context/workstreams/`
|
||||
- Stable communication and maintenance rules live under:
|
||||
- `ai/context/process/`
|
||||
- Named people and role mapping live under:
|
||||
- `ai/context/people/`
|
||||
|
||||
The Slack archive has already been curated into those files so the agent does not need to rediscover the same patterns from raw history every session.
|
||||
|
||||
---
|
||||
|
||||
## Current Priorities
|
||||
|
||||
- REST migration is replacing GraphQL over time, but REST is still behind a feature flag
|
||||
- AO and Discourse issues require careful classification because many are incomplete, external, or auth-dependent
|
||||
- XFlow debugging remains dynamic because behavior changes by entry point, authentication state, backend configuration, and consumer integration
|
||||
- Consumer validation often depends on Fid4, FT modules, and version propagation, not just SDK behavior
|
||||
|
||||
---
|
||||
|
||||
## Workspace Use
|
||||
|
||||
This machine is used to:
|
||||
|
||||
- maintain current project context
|
||||
- record findings from work performed elsewhere
|
||||
- capture communication that changes technical understanding
|
||||
- prepare polished updates for the current manager or stakeholder
|
||||
- generate standups with better context coverage
|
||||
|
||||
This means the context files should hold durable engineering knowledge, while `ai/logs/` and `ai/state/` hold the moving day-to-day view.
|
||||
|
||||
---
|
||||
|
||||
## First Files To Read
|
||||
|
||||
- `ai/context/index.md`
|
||||
- `ai/context/workstreams/index.md`
|
||||
- `ai/context/process/communication.md`
|
||||
- `ai/context/people/index.md`
|
||||
@@ -1,23 +0,0 @@
|
||||
# Cogstore
|
||||
|
||||
## Role
|
||||
|
||||
Cogstore is an important Fidelity platform used to manage and publish many flow configuration definitions, each with its own independent version history.
|
||||
|
||||
---
|
||||
|
||||
## Confirmed Context
|
||||
|
||||
- In the Fidelity flow-config workflow, Cogstore is used to modify and publish individual flow definitions.
|
||||
- Cogstore tracks versions per flow definition rather than as one single platform-wide version.
|
||||
- Cogstore can be used to compare changes between flow-definition versions, similar to a Git-style diff.
|
||||
- Cogstore can be used to check which version of a specific flow definition is published in environments such as QA and Production, including who published it and when.
|
||||
- On April 16, 2026, David used Cogstore to confirm that the relevant flow-definition change tied to Rashmi's service-side update was present in QA as version `0.0.142`, while Production was still on `0.0.133`.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- Jeff indicated on April 15, 2026 that Slate had been used by newer consumer services during the SwiftUI refactor, but is now believed to be decommissioned.
|
||||
- Because service/configuration changes can be environment-specific and versioned per flow, Cogstore should be checked before concluding that a payload/config change is live in Production.
|
||||
- Flow IDs are not guaranteed to exist in both Cogstore and Slate. When tracing a specific flow definition, confirm which configuration system actually owns that flow instead of assuming the same ID will appear in both places.
|
||||
@@ -1,30 +0,0 @@
|
||||
# Fid4
|
||||
|
||||
## Role
|
||||
|
||||
Fid4 is the main Fidelity consumer iOS app and the most important environment for validating real integration behavior.
|
||||
|
||||
---
|
||||
|
||||
## Durable Context
|
||||
|
||||
- Fid4 is the newer flagship-style app and is heavily SwiftUI-based.
|
||||
- Validation in Fid4 often reveals issues that do not appear in XFlowSDK isolation or sample apps.
|
||||
- Historical Slack context shows that some tickets were incorrectly scoped until behavior was checked in Fid4 or flagship.
|
||||
- Real consumer testing in Fid4 matters for modal presentation, validation messaging, and backend-driven flow behavior.
|
||||
|
||||
---
|
||||
|
||||
## Validation Implications
|
||||
|
||||
- If an issue depends on real flow behavior, do not assume XFlow-only validation is sufficient.
|
||||
- When a story touches presentation, entry points, or consumer behavior, check whether Fid4 is required to confirm scope.
|
||||
- Build or startup instability in Fid4 can slow validation and should be treated as a practical investigation constraint.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Fid4 was repeatedly referenced as the right place to verify SwiftUI/XFlow bugs before finalizing scope.
|
||||
- Historical work included modal-on-modal presentation issues, goal/date validation behavior, and consumer-facing eventing questions.
|
||||
- Some XFlow tickets needed rework because the original spike or story had not been validated in flagship/Fid4.
|
||||
@@ -1,32 +0,0 @@
|
||||
# FTFrameworks
|
||||
|
||||
## Role
|
||||
|
||||
FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTransfer, and related libraries that mediate how XFlow changes reach Fid4.
|
||||
|
||||
---
|
||||
|
||||
## Durable Context
|
||||
|
||||
- FTFrameworks is often part of the real validation and release chain, not just a downstream detail.
|
||||
- Historical Slack context shows pinned FT module versions repeatedly blocking adoption of newer XFlow or XFlowViewMaker changes in Fid4.
|
||||
- Changes to XFlow often needed corresponding FTAccountOpen or FTTransfer updates before end-to-end testing was realistic.
|
||||
|
||||
---
|
||||
|
||||
## Validation And Release Implications
|
||||
|
||||
- If Fid4 does not reflect the expected XFlow fix, check FT module versions before concluding the SDK change failed.
|
||||
- Version movement can require a chain such as:
|
||||
- XFlowSDK
|
||||
- XFlowViewMaker
|
||||
- FTAccountOpen / FTTransfer
|
||||
- Fid4
|
||||
- Test failures or publishing issues in FT modules can delay consumer validation even when the core XFlow change is ready.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- FTAccountOpen and FTTransfer were repeatedly mentioned in version bump and release coordination work.
|
||||
- Historical messages also tied FTFrameworks to FTAuth and MFA-related stories, showing that dependency understanding matters when sizing or scoping work.
|
||||
@@ -1,27 +0,0 @@
|
||||
# Systems Index
|
||||
|
||||
## Core Components
|
||||
|
||||
- [fid4.md](./fid4.md)
|
||||
Consumer app and the most important real-world validation environment.
|
||||
|
||||
- [xflowsdk.md](./xflowsdk.md)
|
||||
Backend-driven flow engine and the center of most Fidelity behavior analysis.
|
||||
|
||||
- [xflowviewmaker.md](./xflowviewmaker.md)
|
||||
Adapter layer historically involved in version bumps, release coupling, and removal evaluation.
|
||||
|
||||
- [ftframeworks.md](./ftframeworks.md)
|
||||
Consumer-side feature modules that often mediate whether XFlow changes can be validated in Fid4.
|
||||
|
||||
- [cogstore.md](./cogstore.md)
|
||||
Flow-configuration publishing and version-comparison platform used to verify what is live in QA/Production.
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Start with `xflowsdk.md` for backend-driven behavior questions.
|
||||
- Start with `fid4.md` or `ftframeworks.md` for consumer validation and release flow questions.
|
||||
- Open `xflowviewmaker.md` when the question involves version bumps, transitional architecture, or pipeline friction.
|
||||
- Open `cogstore.md` when the question involves published flow-definition versions, config diffs, or whether a service/config change is live in QA vs Production.
|
||||
@@ -1,39 +0,0 @@
|
||||
# XFlowSDK
|
||||
|
||||
## Role
|
||||
|
||||
XFlowSDK is the backend-driven UI engine that renders Fidelity flows from service-provided configuration.
|
||||
|
||||
---
|
||||
|
||||
## Durable Context
|
||||
|
||||
- XFlow behavior depends on backend rules, entry point, and authentication state.
|
||||
- SwiftUI migration work introduced recurring behavior questions that were not just visual; many were contract or lifecycle issues.
|
||||
- Historical Slack patterns show recurring topics around:
|
||||
- component type expansion in SwiftUI
|
||||
- Next-button visibility rules
|
||||
- markdown link handling and analytics
|
||||
- modal presentation and dismissal sequencing
|
||||
- consumer-vs-framework ownership boundaries
|
||||
|
||||
---
|
||||
|
||||
## Debugging Implications
|
||||
|
||||
- Do not treat XFlow output as static UI; backend configuration can change the result.
|
||||
- When behavior differs across environments, check whether the issue is:
|
||||
- service/configuration driven
|
||||
- auth-state driven
|
||||
- entry-point driven
|
||||
- consumer-integration driven
|
||||
- Some apparent XFlow regressions historically turned out to be consumer, pipeline, or environment issues.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- SwiftUI behavior repeatedly needed parity work beyond UIKit assumptions.
|
||||
- Next-button visibility logic required using the full set of service parameters, not only label text.
|
||||
- Modal, delegate, and lifecycle sequencing became recurring themes in pure SwiftUI environments.
|
||||
- XFlow work often had to be validated through consumer repositories, not only inside the SDK.
|
||||
@@ -1,29 +0,0 @@
|
||||
# XFlowViewMaker
|
||||
|
||||
## Role
|
||||
|
||||
XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework integration. It is under evaluation for reduction or removal.
|
||||
|
||||
---
|
||||
|
||||
## Durable Context
|
||||
|
||||
- Historical release work often required bumping XFlowViewMaker alongside XFlowSDK before consumer validation was possible.
|
||||
- XFlowViewMaker was a recurring source of coupling between XFlow changes and Fid4 or flagship rollout.
|
||||
- Historical Slack evidence shows that version bumps through XFlowViewMaker were often blocked by external pipeline or dependency issues rather than pure feature regressions.
|
||||
|
||||
---
|
||||
|
||||
## Integration Implications
|
||||
|
||||
- When a fix exists in XFlowSDK but is not visible in consumer validation, check whether XFlowViewMaker or downstream pinned versions are blocking adoption.
|
||||
- If the issue involves version propagation into Fid4, treat XFlowViewMaker as part of the release path unless direct-consumption work has replaced it.
|
||||
- Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- XFlowViewMaker version bumps into flagship frequently surfaced `PreviewMacros.SwiftUI`, Apex, or pipeline compatibility issues.
|
||||
- Historical context shows growing pressure to reduce XFlowViewMaker-specific indirection and move toward simpler consumer paths.
|
||||
- Slack history also shows that tutorials and release steps around XFlowViewMaker were easy to misunderstand, which made version propagation a repeated risk.
|
||||
@@ -1,38 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,36 +0,0 @@
|
||||
# Consumer Integration And Release
|
||||
|
||||
## Goal
|
||||
|
||||
Capture the durable release and validation path between XFlow changes and real consumer behavior.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- End-to-end validation often requires more than an SDK change.
|
||||
- Historical Slack evidence shows repeated coupling across:
|
||||
- XFlowSDK
|
||||
- XFlowViewMaker
|
||||
- FTFrameworks modules
|
||||
- Fid4 / flagship
|
||||
- Version pins, publishing delays, and consumer build issues can block validation even when the original code change is ready.
|
||||
|
||||
---
|
||||
|
||||
## Investigation Rules
|
||||
|
||||
- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.
|
||||
- Separate these failure modes:
|
||||
- SDK bug
|
||||
- adapter/version propagation issue
|
||||
- FT module publish/test issue
|
||||
- consumer app setup or pipeline issue
|
||||
- Consumer validation constraints should shape story scope and estimates because they can dominate the real effort.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Version bump work repeatedly involved XFlowViewMaker, FTAccountOpen, and FTTransfer.
|
||||
- Some rollout problems involved Jenkins, Apex/ApexKit, preview macro compatibility, or secret/token access rather than the product behavior under investigation.
|
||||
@@ -1,25 +0,0 @@
|
||||
# Flow And Page References
|
||||
|
||||
## Goal
|
||||
|
||||
Keep recurring flow names, page names, and shorthand references aligned so debugging notes and external updates do not drift into ambiguous wording.
|
||||
|
||||
---
|
||||
|
||||
## Current Mappings
|
||||
|
||||
- `HybridYouthAccountOpening`
|
||||
- This is the real flow identifier when David refers to the Youth flow in recent AO validation discussions.
|
||||
- The relevant page in this flow is `TeenIdentityCheck`.
|
||||
|
||||
- `HybridBrokerageAccountOpening`
|
||||
- This is the separate authenticated flow discussed alongside the Youth issue.
|
||||
- The relevant page in this flow is `JointIdentityCheck`.
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
- When drafting updates, prefer the real flow identifier if there is any risk that shorthand like `Youth flow` or `HybridBrokerage` could be misunderstood.
|
||||
- When a shorthand is still useful for readability, keep the real flow ID available somewhere in the same session context.
|
||||
- Capture additional stable flow/page mappings here when they come up repeatedly in debugging, standups, Jira comments, or consumer communication.
|
||||
@@ -1,29 +0,0 @@
|
||||
# Workstreams Index
|
||||
|
||||
## Active Durable Workstreams
|
||||
|
||||
- [rest-migration.md](./rest-migration.md)
|
||||
GraphQL deprecation and REST rollout constraints.
|
||||
|
||||
- [ao-discourse.md](./ao-discourse.md)
|
||||
External issue intake, ambiguity, and authenticated-only reproduction patterns.
|
||||
|
||||
- [xflow-debugging.md](./xflow-debugging.md)
|
||||
How to reason about backend-driven flows and dynamic behavior.
|
||||
|
||||
- [xflow-swiftui-migration.md](./xflow-swiftui-migration.md)
|
||||
Historical SwiftUI transition themes that still shape XFlow work.
|
||||
|
||||
- [consumer-integration.md](./consumer-integration.md)
|
||||
Release and validation coupling across XFlow, XFlowViewMaker, FT modules, and Fid4.
|
||||
|
||||
- [flow-page-references.md](./flow-page-references.md)
|
||||
Stable mapping between shorthand flow references and their real flow/page identifiers.
|
||||
|
||||
---
|
||||
|
||||
## Guidance
|
||||
|
||||
- Open `ao-discourse.md` before classifying external bug reports.
|
||||
- Open `xflow-debugging.md` for reproduction and investigation framing.
|
||||
- Open `consumer-integration.md` when the work depends on release propagation or validation in consumer apps.
|
||||
@@ -1,32 +0,0 @@
|
||||
# REST Migration
|
||||
|
||||
## Goal
|
||||
|
||||
Deprecate GraphQL and Apollo safely while preserving behavior through REST-backed flows.
|
||||
|
||||
---
|
||||
|
||||
## Stable Constraints
|
||||
|
||||
- REST is behind a feature flag.
|
||||
- GraphQL remains the default fallback unless confirmed otherwise.
|
||||
- REST should never be assumed active by default.
|
||||
- Migration work must preserve behavior parity before removing Apollo-related code.
|
||||
|
||||
---
|
||||
|
||||
## What Matters In Practice
|
||||
|
||||
- Validation must clarify whether the tested path is actually using REST or still falling back to GraphQL.
|
||||
- Story scope should distinguish:
|
||||
- transport migration work
|
||||
- feature-flag cleanup
|
||||
- tests and mocks tied to Apollo/GraphQL
|
||||
- Communication should avoid implying the migration is complete before the fallback path is removed.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Historical Slack evidence around release and dependency work reinforces that transport or dependency changes often require consumer validation, not just local SDK changes.
|
||||
- Some dependency and pipeline issues complicated migration-related rollout even when the technical change itself was understood.
|
||||
@@ -1,39 +0,0 @@
|
||||
# XFlow Debugging
|
||||
|
||||
## Goal
|
||||
|
||||
Debug backend-driven flows without losing track of dynamic dependencies or misclassifying integration behavior.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- XFlow screens are backend-driven, so UI can change without local code changes.
|
||||
- Reproduction depends on:
|
||||
- entry point
|
||||
- authentication state
|
||||
- backend configuration
|
||||
- consumer integration path
|
||||
- Not all entry points are reachable from visible UI; some require exploratory validation.
|
||||
|
||||
---
|
||||
|
||||
## Investigation Rules
|
||||
|
||||
- Confirm the entry point before comparing behavior.
|
||||
- Separate service-driven behavior from client regressions.
|
||||
- Confirm whether the issue reproduces in:
|
||||
- sample app
|
||||
- XFlow-only environment
|
||||
- Fid4 / flagship
|
||||
- authenticated vs non-authenticated state
|
||||
- If a fix appears correct in the SDK but not in consumer validation, inspect the release chain before reopening root cause assumptions.
|
||||
- When validating service/configuration changes, check the active flow-definition version in Cogstore before assuming a change is live in QA or Production.
|
||||
- Do not assume a flow ID will exist in both Cogstore and Slate; verify which config system actually owns the flow you are inspecting.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Historical debugging covered Next-button visibility, markdown modal analytics, modal presentation, slot updates, and SwiftUI lifecycle behavior.
|
||||
- Multiple pipeline or dependency problems looked like XFlow issues until the build chain or consumer integration path was inspected more carefully.
|
||||
@@ -1,35 +0,0 @@
|
||||
# XFlow SwiftUI Migration
|
||||
|
||||
## Goal
|
||||
|
||||
Track the durable behavior patterns introduced while moving XFlow from older assumptions toward a more complete SwiftUI implementation.
|
||||
|
||||
---
|
||||
|
||||
## Stable Themes
|
||||
|
||||
- SwiftUI migration was not just a UI rewrite; it exposed contract, lifecycle, and parity gaps.
|
||||
- Historical Slack evidence repeatedly referenced:
|
||||
- component type expansion beyond simple string assumptions
|
||||
- Next-button visibility rules driven by full service parameters
|
||||
- markdown link handling and analytics integration
|
||||
- navigation and modal behavior in pure SwiftUI environments
|
||||
- dismissal delegate lifecycle sequencing
|
||||
|
||||
---
|
||||
|
||||
## What Matters Now
|
||||
|
||||
- When a SwiftUI issue appears, check whether the missing behavior is:
|
||||
- parity with UIKit behavior
|
||||
- an incomplete service contract interpretation
|
||||
- a lifecycle sequencing problem
|
||||
- a consumer presentation constraint in Fid4
|
||||
- Do not assume a visual issue is only cosmetic; several historical SwiftUI bugs changed flow behavior materially.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Jeff and Norman repeatedly refined story titles and descriptions around SwiftUI architecture changes, showing that scope wording mattered because the work was often deeper than the first symptom.
|
||||
- Historical Slack context also shows that SwiftUI-specific work frequently required cross-team clarification when external dependencies or consumer environments behaved differently.
|
||||
@@ -6,6 +6,6 @@ Recommended usage:
|
||||
|
||||
- `mattermost-latest.md` contains the most recent capture
|
||||
- timestamped snapshots can be stored here if needed
|
||||
- durable facts should be promoted into `ai/logs/`, `ai/state/`, or `ai/context/`
|
||||
- durable facts should be promoted into `vault/06-daily/`, `vault/01-current/`, `vault/02-work-items/`, `vault/03-context/`, `vault/04-people/`, or `vault/05-decisions/`
|
||||
|
||||
This directory is intentionally treated as an inbox, not as the final source of truth.
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
# 2026-04-08
|
||||
|
||||
## Work Done
|
||||
|
||||
- Investigated a Youth account flow issue reported externally
|
||||
- Compared the observed behavior against prior flow behavior
|
||||
- Captured notes to explain the issue clearly before sharing updates
|
||||
|
||||
---
|
||||
|
||||
## Findings
|
||||
|
||||
- Reproduction required an authenticated user
|
||||
- Behavior appeared consistent with previously observed flow behavior
|
||||
- The report did not yet prove a regression
|
||||
|
||||
---
|
||||
|
||||
## Communication
|
||||
|
||||
- Prepared a clearer explanation for follow-up through Mattermost
|
||||
- Framed the issue as an external report pending scope confirmation
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
- Confirm whether any additional action is needed before closing the issue
|
||||
@@ -1,53 +0,0 @@
|
||||
# 2026-04-09
|
||||
|
||||
## Work Done
|
||||
|
||||
- Refined manager-facing communication about a reported behavior difference
|
||||
- Reframed ambiguous language before documenting the outcome in Jira
|
||||
- Updated context to reflect auth-dependent behavior
|
||||
- Confirmed the reported DOB validation issue only reproduces for authenticated users on TeenIdentityCheck
|
||||
- Created `PDIAP-15836` for dismissal delegate lifecycle sequencing in pure SwiftUI (`8` points)
|
||||
- Aligned `PDIAP-15838` scope with REST migration cleanup and feature-flag removal
|
||||
- Confirmed XFlowViewMaker `0.5.0` is already in Fid4
|
||||
- Updated the root cause document for the AccountLink dismissal sequencing issue tied to `PDIAP-15836` and got approval on the proposed wording
|
||||
|
||||
---
|
||||
|
||||
## Findings
|
||||
|
||||
- The reported behavior depended on authenticated context
|
||||
- The original external report was incomplete
|
||||
- The comparison needed more precise wording to avoid implying regression
|
||||
- The dismissal sequencing change needs extra validation across flows, so the story was sized at 8 points
|
||||
- The REST deprecation story covers Apollo, GraphQL networking code, related tests/mocks, and transport feature flags
|
||||
|
||||
---
|
||||
|
||||
## Communication
|
||||
|
||||
- Prepared clearer wording for Jeff
|
||||
- Focused on context, observation, and action instead of vague comparison language
|
||||
- Proposed a root cause document update and got confirmation on the revised wording
|
||||
|
||||
---
|
||||
|
||||
## Slack Archive Import
|
||||
|
||||
- Imported 2,500 historical Slack messages spanning `2023-01-26` to `2025-11-24`
|
||||
- Channels covered: `fidelity-code-review`, `fidelity-grabaciones`, `fidelity-interface-meetings-on-calendar-outlook-team-etc`, `fidelity-jira`, `fidelity-preguntas`, `fidelity-reports-read-this-shit-no-excuses`, `fidelity-retrospective`, `fidelity-standup`
|
||||
- High-signal historical themes: XFlow SwiftUI migration work, Jira/story approval threads, pipeline debugging, and manager-reviewed message wording
|
||||
- Treated older pipeline and story details as historical evidence unless they still change current understanding
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
- Keep using explicit issue framing for future Mattermost and Jira updates
|
||||
|
||||
---
|
||||
|
||||
## Workflow Clarification
|
||||
|
||||
- This workspace is mainly used off the Fidelity work machine
|
||||
- Main practical use cases are: drafting Mattermost updates to Jeff, translating/refining English, reusing prior context, getting Swift technical support, and drafting PR/story text
|
||||
- Recommendations for new commands should prioritize communication support and context reuse over heavy local triage workflows that assume direct access to the product environment
|
||||
@@ -1,36 +0,0 @@
|
||||
# 2026-04-10
|
||||
|
||||
## Clarification
|
||||
|
||||
- `PDIAP-15838` should not be framed as directly tied to the UIKit-removal spike.
|
||||
- Avoid wording that implies `PDIAP-15838` is dependent on or part of the dismissal-sequencing / UIKit-removal spike.
|
||||
- Standups should prioritize updates directly tied to active work items and omit side questions such as version reminders that were only for internal context.
|
||||
- Current focus for today is to finalize `PDIAP-14859` with a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately.
|
||||
- Omit standup items that are not directly related to a story.
|
||||
- Use the approved title `Remove Apollo for iOS` for `PDIAP-15838`.
|
||||
- When a documentation or root cause update directly supports a story, report it under that story instead of as a separate standup item.
|
||||
- In standups, format Jira references as `ID - Title` or `ID Title`, not `ID, Title`.
|
||||
- Jeff clarified that `PDIAP-15838` is the next story to work on and `PDIAP-15836` comes later.
|
||||
- Clarification: the feature-flag and rollout planning feedback applies to the broader UIKit-removal spike, not only to the dismissal sequencing changes; the sequencing work should fit into that same consumer rollout plan.
|
||||
- Current priority is to create a process-oriented document that explains the rollout plan Jeff described for the UIKit-removal spike, with the goal of sharing it for feedback.
|
||||
- Clarification: the document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt. The dismissal sequencing work is only one part of that broader migration plan.
|
||||
- The document should clearly explain that the rollout uses a dual-path pattern to switch between the `UIHostingController` path and the SwiftUI-only path during migration.
|
||||
- Jeff said the remaining spike deliverable is a clear consumer-facing rollout plan covering risky entry points like FTTransfer, consumer communication, XQ1 validation, a 30-day production period with no reported bugs, and a follow-up release to remove the feature flag and old code; he suggested sending that process-oriented document to Quy for feedback when ready.
|
||||
- Reviewed the first Copilot-generated draft of the SwiftUI-only migration rollout document from screenshots.
|
||||
- The draft already includes the main requested elements: dual-path rollout, `xflow-master-swiftui-enabled`, XQ1 validation, FTTransfer coordination, rollback handling, 30-day stabilization window, and final cleanup release.
|
||||
- The next revision should shift the tone slightly away from formal incident/operations language and make the consumer rollout sequence, decision owners, and entry-point-based enablement flow feel more like an engineering migration plan than a generic release runbook.
|
||||
- Correction for the next rollout-document revision: the rollout should not be framed as entry-point-based enablement; it uses a global feature flag and should emphasize broad XQ1 validation before any production release.
|
||||
- Correction for audience framing: the document is consumer-facing and should avoid stakeholder-oriented wording.
|
||||
- Further correction for the rollout document: it should not say production rollout begins with lower-risk consumers. The production flag is global and applies across flows together once the team decides to enable it.
|
||||
- The document should present broad XQ1 validation as the required gate before any production rollout, not as one stage within a consumer-by-consumer enablement sequence.
|
||||
- The migration framing should also call out that the rollout incorporates architectural improvements learned from prior SwiftUI iterations, especially where earlier approaches introduced SwiftUI anti-patterns.
|
||||
- Reviewed the next screenshot-based revision of the rollout document. It now correctly reflects a global production flag model, broad XQ1 validation before production enablement, consumer-facing wording, and architectural improvements learned from prior SwiftUI iterations.
|
||||
- Remaining polish areas in the latest draft: reduce lingering operational/runbook wording (`SLA`, `operational response`, `release manager delegate`, heavy monitoring-threshold language) and make the high-risk-consumer section sound more like coordination/validation within a global rollout than a separate rollout phase.
|
||||
- The rollout document should be more concise and should not use an overly complex multi-phase model.
|
||||
- Reviewed the newer simplified screenshot-based revision. The rollout structure is now much closer to the intended model: a simple gated flow of broad XQ1 validation, global production enablement, then a 30-day stabilization window before cleanup.
|
||||
- Remaining issues in the latest draft are mostly wording and trimming: it still includes extra runbook-style sections such as `Production Monitoring and Guardrails`, `Coordination Model for High-Risk Consumers`, `Rollback and Operational Response`, and `Decision Gates Summary`, which may be more detail than needed for the concise consumer-facing version.
|
||||
- Reviewed another screenshot-based revision after the simplification prompt. The top-level rollout flow is still good and concise, but the lower half of the document still retains most of the extra runbook-style sections, so the latest revision did not yet materially reduce those details.
|
||||
- Clarified the AO/Discourse config explanation for the authenticated `TeenIdentityCheck` DOB issue: the requirement is not to rename the root from `birthDate` to `validations`; instead, the `validation-rules` payload should contain a JSON object whose root key is `validations`, and if the age gate is required it should include `eighteenOrAbove: true`, matching the `CheckIdentity` structure rather than relying on a separate transactional rule boolean like `"eighteen-or-above": true`.
|
||||
- Further clarification for the same AO/Discourse thread: the reply should explicitly state that the earlier comment was referring to the literal `"eighteen-or-above": true` attribute inside the transactional-rules array, while still distinguishing that from the separate `validation-rules` structure.
|
||||
- Additional clarification for the authenticated `TeenIdentityCheck` config issue: the `validation-rules` attribute is the structure that drives the check. `CheckIdentity` was already configured correctly. The `TeenIdentityCheck` problem had two parts: the wrong root key (`birthDate` instead of the expected `validations`) and the missing `eighteenOrAbove` attribute inside `validation-rules`.
|
||||
- For the Rashmi reply, the intended closing clarification is that the previous `CheckIdentity` `validation-rules` shape is the expected model for `TeenIdentityCheck`, and a JSON snippet can be shared to show the expected structure directly.
|
||||
@@ -1,15 +0,0 @@
|
||||
# 2026-04-13
|
||||
|
||||
## Standup Context
|
||||
|
||||
- Corrected the approved title for `PDIAP-14859` to `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`.
|
||||
- Manual clarification for Monday standup: reference Friday work rather than the prior calendar day.
|
||||
- Friday update for `PDIAP-14859`: created a draft rollout document for removing UIKit in favor of a SwiftUI-only path, including feature-flag planning.
|
||||
- Today update: publish the rollout document for `PDIAP-14859` and continue with `PDIAP-15838` `Remove Apollo for iOS`.
|
||||
- Standups should include story titles, not only Jira IDs, when the title is available.
|
||||
|
||||
## Mattermost Sync
|
||||
|
||||
- `PDIAP-14859`: sent Jeff the rollout draft for review after updating it around the global feature flag, broad `XQ1` validation, and the consumer-facing rollout flow.
|
||||
- Jeff replied that he will review the `PDIAP-14859` document this morning.
|
||||
- For `PDIAP-15765`, Jeff approved sending the config clarification that `CheckIdentity` was already correct and that `TeenIdentityCheck` needed the `validations` root key plus `eighteenOrAbove` inside `validation-rules`; the message was sent with an expected validation snippet.
|
||||
@@ -1,69 +0,0 @@
|
||||
# 2026-04-14
|
||||
|
||||
## Previous Workday Refresh
|
||||
|
||||
- `PDIAP-14859` rollout draft remained in revision on April 13 rather than being finalized; the work was limited to the specific draft changes requested in review, not a broad rewrite.
|
||||
- The rollout document should rename the proposed flag from `xflow-master-swiftui-enabled` to `xflow-swiftui-enabled`.
|
||||
- The first rollout phase should explicitly mention contacting consumers ahead of time and asking them to validate their flows in `XQ1`.
|
||||
- The rollout document should remove overly technical wording and avoid implying there are no consumer-side changes without qualification.
|
||||
- Current spike clarification: `FTTransfer` changes are no longer considered strictly required after applying the SwiftUI dismissal behavior correctly, but risky entry points still need explicit rollout coverage.
|
||||
|
||||
## AO / Discourse Findings
|
||||
|
||||
- The AO reply about `TeenIdentityCheck` was approved and sent after clarifying that `CheckIdentity` was already correct and that the `TeenIdentityCheck` issue was the missing `validations` root and missing `eighteenOrAbove` inside `validation-rules`.
|
||||
- Later validation showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
|
||||
- A `HybridBrokerage` scenario reproduces on both iOS and Android.
|
||||
- A Youth flow (`Open an account` -> `Save & Invest for a child` -> `Fidelity Youth Account`) fails on iOS while working on Android.
|
||||
- Current evidence suggests Android is more flexible when decoding rule variations, while iOS is stricter about the expected `validation-rules` structure in the Youth-flow scenario.
|
||||
- The iOS-only Youth-flow discrepancy is the scenario currently aligned with the story-level client fix.
|
||||
- The cross-platform `HybridBrokerage` scenario should stay scoped separately until it is clear whether it is a service/config issue or a distinct bug.
|
||||
|
||||
## Current Direction
|
||||
|
||||
- `PDIAP-14859` remains focused on incorporating rollout-document feedback and publishing a consumer-facing plan.
|
||||
- `PDIAP-15838` remains the next implementation story after the rollout-document work is in a good state.
|
||||
|
||||
## New Investigation Note
|
||||
|
||||
- For the Murali group discussion, there appears to be usage of `ApexBridgingAddressComponent` through references in `XFlowPageApexItem`.
|
||||
- If that usage is active, the dependency comes from `ApexKitV3`, which was expected to retain support after the earlier ApexKit removal.
|
||||
- Current guidance from that discussion is to migrate toward `FDS` or `ApexKitSwiftUI`, but the exact replacement for `ApexBridgingAddressComponent` is still unclear and needs investigation and validation.
|
||||
- Narrower wording for the current status: there are visible references at a glance, but it is not yet confirmed whether they are active or dead code; the next step is to validate with a run.
|
||||
|
||||
## Fresh Mattermost Sync
|
||||
|
||||
- Confirmed with breakpoints that `ApexBridgedAddressComponent` is not used when loading an address component; the observed path goes through `ApexGoogleAddressViewModel`.
|
||||
- A follow-up review raised that the old component may still be used to load rules and appears in `XFloaValueChanger`, so it should not be treated as dead code without deeper verification.
|
||||
- Current direction for that investigation is to be exhaustive and avoid assumptions before describing the old bridged path as unused.
|
||||
- Clarification from the same thread: the remaining `ApexKitV3` reference does not cause build issues because `ApexKitSwiftUI` still depends on `ApexKitV3`.
|
||||
- `PDIAP-14859` rollout-document follow-up: Jeff asked whether the FTTransfer section needed updating, and David confirmed the document had already been revised to clarify that root cause.
|
||||
- Latest clarification in the Murali thread: `ApexBridgedAddressComponent` belonged to the old UIKit rule-handling flow. In the current implementation, rules are described as being handled through the SwiftUI path, parsed from the payload and applied through the `XFlowViewApadater` / `ViewModelAdapter` layer using `ApexGoogleAddressViewModel`.
|
||||
- Clarification for the retro/ownership discussion: the earlier FTTransfer-side explanation was not fully wrong, but it was incomplete. The SwiftUI state behavior was a real symptom/effect on the consumer side; the deeper root cause was the dismissal flow handling that had not been covered correctly. The main gap was concluding consumer ownership before isolating that underlying dismissal root cause.
|
||||
- Suggested clarification for Jeff and Aylwing: the dismissal issue should be framed as a corner case that was not simple to identify without deeper analysis. The FTTransfer-side SwiftUI behavior was still a real observed symptom, but the deeper root cause only became clear after more thorough investigation.
|
||||
- Additional clarification for that same reply: the FTTransfer-side state-management behavior should be described as a real SwiftUI anti-pattern that can cause view/state identity loss. That behavior was valid to call out, but it still did not fully explain the deepest root cause until the dismissal-path analysis was completed.
|
||||
- Jeff clarified the broader lesson: if ownership is still uncertain, the safer path is to roll back and continue investigating rather than make confident claims about consumer-side fault before the code is fully understood. The risk is loss of trust and reduced ability for the framework team to make authoritative calls independently.
|
||||
- Jeff also clarified that in this case, if the root cause is architectural on the framework side, the team is not in an authoritative position to call out consumer code. His preferred pattern under uncertainty is rollback plus investigation rather than confident ownership claims.
|
||||
|
||||
## ApexKitV3 / Swift 6 Follow-up
|
||||
|
||||
- Jeff clarified that when the external team says they will stop support, they mean the dependency will be deleted, which would cause build errors on the XFlow side unless it is removed or replaced.
|
||||
- Breakpoint and import-removal follow-up showed that removing `import ApexKitV3` across XFlow causes `23` compilation issues.
|
||||
- Replacing those imports with `ApexKitSwiftUI` still leaves `13` build errors.
|
||||
- Current high-confidence understanding is that XFlow still has meaningful dependency impact from `ApexKitV3`, and this is not just a trivial dead-code cleanup.
|
||||
- Swift 6 support is not yet implemented; related work is planned under a `26Q3` backlog epic.
|
||||
- New direction from Jeff after speaking with Quy: spend the rest of today researching the impact of this change and prepare a short Confluence write-up by EOD, preferably by `4:30 PM`.
|
||||
- The requested write-up should cover what change is being requested, build-error and component impact, what needs retesting, which flows/components are affected, and the overall risk including whether consumers should be involved in testing.
|
||||
- Jeff explicitly wants the document framed as carrying impact and consumer-testing risk if the change requires more than small adjustments.
|
||||
- Confirmed wording note: Quy should be treated as Scrum Master in prompts and write-ups, not described generically as a stakeholder.
|
||||
- Additional analysis context for the ApexKitV3 investigation: the Swift version change was reverted back to Swift 5, and the Pods were updated to the latest versions including `ApexKitSwiftUI 1.27.14`. The current question is whether the ApexKitV3-removal impact remains the same under that updated dependency baseline.
|
||||
- Document-review guidance for the ApexKitV3 impact write-up: it should not read as if code changes have already been made, should stay understandable for a non-technical reader, and should avoid overcommitting on production impact where SwiftUI-vs-legacy-path usage is still being verified.
|
||||
- Additional document-review guidance: if the write-up already recommends consumer testing, it should not hedge with wording like `if the change extends beyond small cleanup`. The risk section should stay internally consistent and reflect the current conclusion directly.
|
||||
|
||||
## Late-Day Outcome
|
||||
|
||||
- The ApexKitV3 impact write-up was revised with the requested wording changes, including using `Impacted Flows` and making consumer validation a direct recommendation rather than a conditional one.
|
||||
- Jeff approved the ApexKitV3 write-up after those edits, and David published it and sent the Confluence link to Quy with a concise summary of the effort and risk.
|
||||
- End-of-day direction for `PDIAP-14859`: the rollout document was approved as good enough, but it was not published on April 14. The next step is to publish it on the next workday, then comment the spike with `Spike Results:` links and the follow-up story link.
|
||||
- The UIKit-removal follow-up story should be linked as a blocker for the reopened UIKit-removal work after the spike is closed out.
|
||||
- End-of-day direction for `PDIAP-15765`: move the story back to In Progress on the next workday and focus on the authenticated iOS-only Youth `TeenIdentityCheck` gap so iOS handles the service response the same way as Android.
|
||||
- The separate `HybridBrokerage` scenario remains distinct from the iOS-only Youth-flow issue and may need its own follow-up ticket if the service-side problem still stands after the client-side story is resumed.
|
||||
@@ -1,49 +0,0 @@
|
||||
# 2026-04-15
|
||||
|
||||
## Toggle Name Follow-up
|
||||
|
||||
- Additional historical context from Teams suggests the existing LaunchDarkly flag name `xflow-master-swiftui-enabled` was already shared in the Fid4 LaunchDarkly project as the SwiftUI toggle.
|
||||
- User-provided historical references: Neetu Gupta asked for the SwiftUI toggle name and Jason Mandozzi replied with `xflow-master-swiftui-enabled` plus the LaunchDarkly link; in January 2025, Thomas Payne also asked whether the team was ready to activate that same toggle.
|
||||
- Current interpretation: the team may be able to keep using the same flag name even though the rollout intent is now narrower. In the current rollout, toggling would switch only the final `UIHostingController` wrapping on or off, while SwiftUI remains in use either way.
|
||||
- This historical evidence supports keeping the existing flag name if renaming would add friction, but the semantic mismatch should still be acknowledged when describing the rollout.
|
||||
- Fresh clarification from Jeff on April 15: do not reuse the old SwiftUI LaunchDarkly flag for this rollout.
|
||||
- New required flag name for the rollout document: `xflow-swiftui-container-enabled`.
|
||||
- The rollout document should explicitly note that this new flag is `to be added in the future as part of implementation`.
|
||||
- Jeff plans to ask later how to get the new flag added when implementation time comes.
|
||||
|
||||
## PDIAP-15765 Follow-up Drafting Context
|
||||
|
||||
- David plans to confirm that `PDIAP-15765` was moved from investigation back to In Progress.
|
||||
- Current working interpretation: the `HybridBrokerageAccountOpening` / `JointIdentityCheck` behavior appears to be a different issue from the iOS-only Youth `TeenIdentityCheck` gap.
|
||||
- This separate `HybridBrokerage` path currently appears consistent across iOS and Android, so it may be expected flow/service behavior rather than the same client-side defect.
|
||||
- Confidence is still limited: David wants to re-check whether anything changed in that path before stating that conclusion too strongly.
|
||||
- One reason for suspicion is that the validation appears to use `min: 10` and `max: 10`, which may indicate questionable or non-meaningful validation setup rather than the same decoding problem tracked in the iOS story.
|
||||
- Latest clarification from David: the original iOS-only issue is specifically that iOS does not recognize rules when they come under the `birthDate` key.
|
||||
- Once the payload was changed from `birthDate` to `validations`, the originally reported iOS issue no longer reproduced and the validation loaded correctly.
|
||||
- Fresh guidance from Jeff after the Android reproduction: this follow-up question should be sent to Rashmi as a separate consumer-side confirmation request, not answered internally.
|
||||
- Jeff asked that the message start with: `One follow-up question about the other issue I found while attempting to reproduce (this was what I had originally thought your team was reporting):`
|
||||
- Jeff also wants the message to end by asking whether Rashmi thinks that behavior is a bug as well.
|
||||
- Later clarification from Jeff: send Rashmi a separate message asking whether their team changed the service payload on their side, since the original iOS-only Youth issue no longer reproduces after the payload moved from `birthDate` to `validations`.
|
||||
- Jeff's current framing: even if their side changed the payload and the issue no longer reproduces, the iOS-side handling gap likely still should be fixed because the problem was iOS-only.
|
||||
|
||||
## Jeff Context On AO Fallback Handling
|
||||
|
||||
- Jeff confirmed the minimal iOS fallback change is the right fix for this issue.
|
||||
- He clarified that the preexisting fallback-style validation handling in XFlow exists largely to accommodate AO flows.
|
||||
- Jeff's project history note: AO is the oldest service integration and has older, harder-to-change payload conventions, while newer consumer services were largely built through Slate and were the primary validation target during the SwiftUI refactor.
|
||||
- That history explains why `validations` aligned better with newer SwiftUI work, while older AO payload shapes can still require explicit iOS fallback handling.
|
||||
- Jeff's practical guidance: when the issue is AO-consumer-specific, iOS-only, and caused by a mismatch between what the AO service sends and what the SDK expects, the easiest fix is often to add the minimal compatibility fallback on iOS.
|
||||
|
||||
## PR Drafting Context
|
||||
|
||||
- The `xflow-for-ios` PR template currently uses sections `## What`, `## Why`, `## How`, `### Changes details`, and `## Missed anything?` with a final checklist.
|
||||
- The April 15 iOS fix PR is a one-line change in `XFlowViewAdapterRepresentable.swift` for `.apxDateSelect`, adding `birthDate` as a fallback after `validations`.
|
||||
- This PR should be described as a small compatibility bug fix for older AO-style payloads rather than as a broader Android-parity refactor.
|
||||
- David opened the PR for this minimal iOS compatibility fix.
|
||||
|
||||
## Standup And Flow Naming Notes
|
||||
|
||||
- David prefers standups to use one top-level Jira bullet with indented sub-bullets when a single ticket has multiple updates.
|
||||
- In recent standup wording, `Youth flow` should be treated as shorthand for the real flow ID `HybridYouthAccountOpening`.
|
||||
- The relevant page in that flow is `TeenIdentityCheck`.
|
||||
- The separate authenticated flow under discussion remains `HybridBrokerageAccountOpening`, with the relevant page `JointIdentityCheck`.
|
||||
@@ -1,31 +0,0 @@
|
||||
# 2026-04-16
|
||||
|
||||
## Mattermost
|
||||
|
||||
- Jeff clarified that `PDIAP-15765` should not move to Done until the PR is merged.
|
||||
- Santosh approved the PR, but one code-owner approval is still required before merge.
|
||||
- Jeff asked for one more AO working-group Teams reply that:
|
||||
- summarizes that the original iOS issue was reproduced and addressed with the iOS-side change
|
||||
- points the group to the Jira comment, Discourse comment, and PR
|
||||
- explains that the initially found `HybridBrokerageAccountOpening` / `JointIdentityCheck` problem is separate
|
||||
- notes which service-side changes were already made and which still appear to be needed
|
||||
- David clarified that the confirmed service-side change was limited to the Youth-flow `TeenIdentityCheck` path. For external communication, avoid overstating the scope or calling out Rashmi by name unless that attribution is specifically needed.
|
||||
- David clarified that the iOS change should be described as a compatibility improvement to reduce similar future issues with the older `birthDate` format. It should not be described in a way that implies it also applies to the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue.
|
||||
- Jeff said the AO working-group draft was still confusing and wanted to edit it himself to make it very clear and avoid follow-up questions.
|
||||
- David clarified that the `HybridYouthAccountOpening` / `TeenIdentityCheck` issue was iOS-only; it should not be described as affecting both iOS and Android.
|
||||
- David clarified that the service-side change and the iOS-side fallback address the same Youth / `TeenIdentityCheck` issue, not two separate Youth issues. The service change was the immediate resolution, while the iOS PR is a compatibility safeguard if that older `birthDate` format appears again.
|
||||
- David has personally seen `birthDate` used on two pages so far, but broader reuse in other flows is still unconfirmed and should be described carefully.
|
||||
- For Jeff's framing question, the current understanding is two affected flow scenarios, not three: the iOS-only Youth / `TeenIdentityCheck` issue, and the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue.
|
||||
- Jeff confirmed on April 15 that the minimal iOS `birthDate` fallback is the right change for the Youth / `TeenIdentityCheck` case and approved opening the PR under the same story.
|
||||
- Jeff clarified the historical reason for the fallback behavior: older AO services often still use older payload conventions, while the SwiftUI refactor was validated more heavily against newer Slate-based services using `validations`.
|
||||
- Jeff said the easiest fix is usually this kind of iOS-side fallback when the consumer is AO, the issue is iOS-only, and the service payload shape differs from what the SDK expects.
|
||||
- Jeff approved the Jira and Discourse comments with one wording change: say `I checked the original iOS issue again` instead of `I re-checked`.
|
||||
- Jeff approved sending a final AO working-group summary, but wanted it to be much clearer about what was fixed on iOS, what Rashmi changed on the service side, and what separate service-side issue still remains in `HybridBrokerageAccountOpening` / `JointIdentityCheck`.
|
||||
- David later checked Cogstore and confirmed that the relevant flow-definition change tied to Rashmi's service update is already in QA as version `0.0.142`, while Production is still on `0.0.133`, so that flow change is not live in production yet.
|
||||
- Jeff concluded there is no point relying on a separate service release for the Youth issue if it would also require its own rollout; the iOS PR should be treated as the primary fix path, while the QA-side flow-definition change explains why the issue no longer reproduces in XQ1.
|
||||
- Durable tooling/system note: in Fidelity flow work, Cogstore is the platform used to modify and publish many individual flow configurations, compare versions per flow, and check who/when a specific flow version was published to QA or Production. Slate was the newer consumer-side configuration tooling during the SwiftUI refactor, but Jeff believes it is now decommissioned.
|
||||
- Additional tooling note: flow IDs are not guaranteed to exist in both Cogstore and Slate, so the active configuration source for a given flow should be verified instead of assumed.
|
||||
- David confirmed that the `HybridBrokerageAccountOpening` / `JointIdentityCheck` flow-definition content is the same in QA and Production even though the versions differ (`0.0.267` vs `0.0.263`), so that separate rule-content issue should also be reproducible in Production.
|
||||
- Jeff asked Rashmi to revert the Youth-flow service change so the iOS-side PR can remain the single fix path for that issue.
|
||||
- David confirmed Rashmi reverted the QA change by publishing the earlier flow version, and local Fid4 validation with the iOS PR showed the `birthDate`-based validation now works as expected.
|
||||
- Jeff's preferred external summary is now very explicit: we went back and fixed their original iOS-only issue on the iOS side, while the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is a new service-side problem that still needs its own follow-up.
|
||||
@@ -1,27 +0,0 @@
|
||||
# Logs Index
|
||||
|
||||
Daily logs capture evolving evidence and same-day work context.
|
||||
|
||||
Promote durable facts into `ai/state/`, `ai/work-items/`, or `ai/context/` when they should survive beyond the day.
|
||||
|
||||
---
|
||||
|
||||
## Logs
|
||||
|
||||
- [2026-04-08](2026-04-08.md)
|
||||
- [2026-04-09](2026-04-09.md)
|
||||
- [2026-04-10](2026-04-10.md)
|
||||
- [2026-04-13](2026-04-13.md)
|
||||
- [2026-04-14](2026-04-14.md)
|
||||
- [2026-04-15](2026-04-15.md)
|
||||
- [2026-04-16](2026-04-16.md)
|
||||
|
||||
---
|
||||
|
||||
## Related Memory
|
||||
|
||||
- [Current Work](../state/current.md)
|
||||
- [Work Item State](../state/work-items.md)
|
||||
- [Work Item Index](../work-items/index.md)
|
||||
- [Context Index](../context/index.md)
|
||||
|
||||
@@ -1,78 +0,0 @@
|
||||
# Current Work
|
||||
|
||||
## Focus
|
||||
|
||||
- Keep Fidelity context current from daily work performed on another machine
|
||||
- Track REST migration findings
|
||||
- Debug Discourse and AO issues
|
||||
- Prepare better updates for the current manager or stakeholder through Mattermost
|
||||
- Follow up on active tickets through `ai/work-items/`, especially `PDIAP-14859`, `PDIAP-15765`, `PDIAP-15836`, and `PDIAP-15838`
|
||||
- Wrap up `PDIAP-14859` by publishing the approved rollout document, linking the spike-result documents and follow-up story, then closing the spike
|
||||
- After the immediate `PDIAP-14859` closeout and `PDIAP-15765` resume work, return to `PDIAP-15838`; `PDIAP-15836` comes later
|
||||
- Resume `PDIAP-15765` for the authenticated iOS-only `HybridYouthAccountOpening` / `TeenIdentityCheck` handling gap so iOS aligns with Android behavior
|
||||
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
|
||||
- Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
|
||||
- Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code
|
||||
- Reconcile the old UIKit address-rule path with the current SwiftUI handling path through the adapter/view-model layer before reporting final ownership or replacement guidance
|
||||
- The ApexKitV3 risk write-up for Quy has been published and sent; use that research as the current high-level framing for dependency-removal risk
|
||||
- Investigate the current XFlow dependency surface on `ApexKitV3`, including the `23` build errors on removal and the remaining `13` errors when swapping to `ApexKitSwiftUI`
|
||||
- The process-oriented rollout document for the UIKit-removal spike is approved and ready to publish for spike closure
|
||||
- The rollout document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt
|
||||
- The rollout document uses a global feature-flag rollout model with broad XQ1 validation before production enablement
|
||||
- The rollout document should use the new flag name `xflow-swiftui-container-enabled` and note that the flag will be added later during implementation
|
||||
- Re-check the authenticated AO validation issue with scenario-specific evidence: the `HybridYouthAccountOpening` / `TeenIdentityCheck` path currently points to an iOS-only decoding gap, while a separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` case reproduces on both platforms
|
||||
- The immediate Youth issue was fixed on the service side for the Youth-flow `TeenIdentityCheck` path after the payload moved from `birthDate` to `validations`; local Fid4 validation also confirmed it. The XFlowSDK-side fallback PR should still ship in the next release
|
||||
- Jeff later decided the iOS fallback PR should be treated as the primary fix path for the Youth issue rather than relying on a separate service rollout; the QA-side service change has since been rolled back and Fid4 validation still passed with the PR in place
|
||||
- When describing the XFlowSDK fallback PR, frame it as a compatibility improvement for similar future `birthDate` payloads, not as a fix for the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue
|
||||
- The Youth / `TeenIdentityCheck` issue was iOS-only; do not describe it as reproducing on both platforms
|
||||
- The service-side payload update and the XFlowSDK fallback PR address the same Youth / `TeenIdentityCheck` issue; do not split them into separate Youth issues when summarizing scope
|
||||
- `PDIAP-15765` should stay out of Done until the PR is merged; Santosh approved it, but code-owner approval is still required before merge
|
||||
- Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue
|
||||
- The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up
|
||||
|
||||
---
|
||||
|
||||
## Active Concerns
|
||||
|
||||
- Authenticated vs non-authenticated behavior
|
||||
- Reproducibility across entry points
|
||||
- Backend-driven inconsistencies in XFlow
|
||||
- Distinguishing external issues from true regressions
|
||||
- Preserving accurate context when summarizing work from another machine
|
||||
- Validating dismissal sequencing changes across SwiftUI flows
|
||||
- Keeping REST deprecation scope explicit while GraphQL fallback still exists
|
||||
- Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
|
||||
- Closing `PDIAP-14859` cleanly with the right links, blocker relationship, and feature-flag wording
|
||||
- Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope
|
||||
- Avoiding assumptions about legacy Apex/ApexKit paths; breakpoint evidence and helper usage both need to be reconciled before reporting ownership or replacement guidance
|
||||
- When ownership is still uncertain under production pressure, prefer rollback-plus-investigation framing over confident blame assignment to consumers
|
||||
- Swift 6 migration risk is now time-sensitive because external dependency removal could break XFlow before the planned `26Q3` work
|
||||
- The write-up for Quy should remain the reference framing for moderate effort, medium risk, and required consumer validation while deeper implementation details are still being researched
|
||||
|
||||
---
|
||||
|
||||
## Communication Priorities
|
||||
|
||||
- Standups should reflect the latest technical state, not generic progress
|
||||
- Standups should prefer updates directly tied to active work items over one-off memory refreshes or side questions
|
||||
- Standups should include story titles whenever a reported update maps to a Jira item
|
||||
- Standups should use bullet points for each item, but avoid dash-separated title formatting inside the sentence body
|
||||
- When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times
|
||||
- When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas
|
||||
- Standups should omit side questions or manager-only context refreshes unless they materially changed story work
|
||||
- If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item
|
||||
- Standups should omit items not tied to a story unless they are real blockers
|
||||
- If a new request is important work but not directly tied to a Jira item, include it as a standalone bullet instead of forcing it under a story
|
||||
- Manager updates should be short, precise, and natural in English
|
||||
- Mattermost messages should make scope and next action explicit
|
||||
- When root cause is not fully isolated, do not position framework conclusions as authoritative consumer-side fault
|
||||
- Standups should be written as David's external progress report and should not mention Jeff by name
|
||||
- Standups should never mention Mattermost because it is internal-only communication
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- REST remains behind a feature flag
|
||||
- Validate against main before calling something a regression
|
||||
- This workspace is the context source for communication, not the source of product code changes
|
||||
@@ -1,25 +0,0 @@
|
||||
# Active Work Items
|
||||
|
||||
Use this file as the quick summary for active Jira-linked work.
|
||||
|
||||
Detailed ticket memory now lives under `ai/work-items/`.
|
||||
|
||||
Update the per-ticket files first when scope, status, sequencing, or communication framing changes materially.
|
||||
|
||||
## Current
|
||||
|
||||
- `PDIAP-14859` - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation
|
||||
Detail: `ai/work-items/pdiap-14859.md`
|
||||
Current note: the impact write-up is published, and the rollout document is approved for publication; update it to use the new flag name `xflow-swiftui-container-enabled` with a note that it will be added later during implementation, then publish and close out the spike with `Spike Results:` links.
|
||||
|
||||
- `PDIAP-15838` - Remove Apollo for iOS
|
||||
Detail: `ai/work-items/pdiap-15838.md`
|
||||
Current note: approved at `8` points and next to work on; keep it separate from the UIKit-removal spike.
|
||||
|
||||
- `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
|
||||
Detail: `ai/work-items/pdiap-15836.md`
|
||||
Current note: approved at `8` points, rooted in the AccountLink dismissal sequencing investigation, and sequenced after `PDIAP-15838`.
|
||||
|
||||
- `PDIAP-15765` - AO DOB field error not showing investigation
|
||||
Detail: `ai/work-items/pdiap-15765.md`
|
||||
Current note: a small XFlowSDK PR is open for the iOS `birthDate` fallback, the immediate `HybridYouthAccountOpening` / `TeenIdentityCheck` issue appears fixed on the service side, and the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` case remains out of scope for this fix.
|
||||
@@ -1,25 +0,0 @@
|
||||
# Work Items
|
||||
|
||||
## Goal
|
||||
|
||||
Keep active Jira-linked work in one canonical place so standups, manager updates, and memory syncs can reference each ticket precisely.
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
- `index.md`
|
||||
Active index and quick status view.
|
||||
|
||||
- `<jira-id>.md`
|
||||
Canonical file for a specific ticket.
|
||||
|
||||
---
|
||||
|
||||
## Update Rules
|
||||
|
||||
- Use one file per active or recently relevant Jira item.
|
||||
- Keep titles exact when approved or explicitly confirmed.
|
||||
- If the title is not confirmed, store the Jira ID and current framing without inventing a final title.
|
||||
- Update the ticket file when scope, sequencing, points, status, rollout implications, or reproducibility meaningfully change.
|
||||
- Keep `ai/state/work-items.md` as a short bridge summary, not the primary source of detailed ticket context.
|
||||
@@ -1,31 +0,0 @@
|
||||
# Work Item Index
|
||||
|
||||
## Goal
|
||||
|
||||
Provide a quick view of active and recently relevant Jira-linked work while keeping the full detail in one file per ticket.
|
||||
|
||||
---
|
||||
|
||||
## Active
|
||||
|
||||
- [pdiap-14859.md](./pdiap-14859.md)
|
||||
`PDIAP-14859` `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation` spike wrap-up work around dual UIKit/SwiftUI support, dynamic `UIHostingController` removal, consumer rollout planning, and linking the final result documents.
|
||||
|
||||
- [pdiap-15838.md](./pdiap-15838.md)
|
||||
`PDIAP-15838` next story to work on; approved scope removes Apollo and GraphQL-specific iOS transport code while leaving REST.
|
||||
|
||||
- [pdiap-15836.md](./pdiap-15836.md)
|
||||
`PDIAP-15836` approved follow-up story for dismissal delegate lifecycle sequencing in pure SwiftUI; comes after `PDIAP-15838`.
|
||||
|
||||
## Active / Reopened
|
||||
|
||||
- [pdiap-15765.md](./pdiap-15765.md)
|
||||
`PDIAP-15765` authenticated-only DOB issue in `HybridYouthAccountOpening` / `TeenIdentityCheck`; reopened around the iOS-only handling gap while the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario stays out of scope.
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
- Read this file first for active ticket context.
|
||||
- Open the specific ticket file when you need exact scope, sequencing, or communication wording.
|
||||
- Update the per-ticket file first when ticket context changes materially.
|
||||
@@ -1,50 +0,0 @@
|
||||
# PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation
|
||||
|
||||
## Status
|
||||
|
||||
- Active
|
||||
- Rollout draft prepared and sent to Jeff for review on April 13, 2026
|
||||
- Rollout document approved for publication; publish and close out the spike next
|
||||
|
||||
---
|
||||
|
||||
## Current Framing
|
||||
|
||||
- Approved title: `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`.
|
||||
- This work is currently framed in the workspace as a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately.
|
||||
- The remaining deliverable is process-oriented, not just technical implementation.
|
||||
|
||||
---
|
||||
|
||||
## Current Scope
|
||||
|
||||
- Define a consumer-facing rollout plan for the broader UIKit-removal work.
|
||||
- Preserve both UIKit and SwiftUI paths appropriately while introducing the new path safely.
|
||||
- Cover risky entry points such as `FTTransfer`, while keeping the latest spike finding explicit that consumer-side changes there may no longer be strictly required after the SwiftUI dismissal behavior is applied correctly.
|
||||
- Include validation expectations in `XQ1`.
|
||||
- Use a global feature-flag rollout model rather than entry-point-based enablement.
|
||||
- Include consumer communication expectations.
|
||||
- Include a 30-day production period with no reported bugs before final removal.
|
||||
- Include a follow-up release to remove the feature flag and old code after rollout confidence is achieved.
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- The feature-flag and rollout planning guidance applies to the broader UIKit-removal spike, not only to dismissal-sequencing work.
|
||||
- Jeff suggested sending the process-oriented rollout document to Quy for feedback when ready.
|
||||
- The draft shared with Jeff already reflects the global feature flag, broad `XQ1` validation, and consumer-facing rollout flow guidance.
|
||||
- Additional review feedback from April 13: rename the proposed flag to `xflow-swiftui-enabled`, make consumer contact and `XQ1` validation explicit in the first phase, remove overly technical rollout wording, and avoid implying there are no consumer-side changes without qualification.
|
||||
- On April 14, Jeff asked whether the FTTransfer part of the rollout document also needed updating; David confirmed the document had already been revised to clarify that root-cause section.
|
||||
- April 15 clarification: do not reuse the existing SwiftUI LaunchDarkly flag for this rollout.
|
||||
- The new flag name for this work should be `xflow-swiftui-container-enabled`.
|
||||
- The document should note that the flag is `to be added in the future as part of implementation`.
|
||||
- Late April 14 guidance: the document was approved late in the day; the next step is to publish it, then close out the spike by commenting `Spike Results:` with the relevant document links and the new follow-up story link.
|
||||
- The new follow-up story should also be marked as a blocker for the reopened UIKit-removal story.
|
||||
|
||||
---
|
||||
|
||||
## Related Work
|
||||
|
||||
- Related consumer rollout thinking should stay aligned with `PDIAP-15836`.
|
||||
- `PDIAP-15838` should not be framed as part of this UIKit-removal spike.
|
||||
@@ -1,61 +0,0 @@
|
||||
# PDIAP-15765 - AO DOB field error not showing investigation
|
||||
|
||||
## Status
|
||||
|
||||
- Active again
|
||||
- Move back to In Progress on the next workday
|
||||
- Small XFlowSDK compatibility PR opened for the iOS-side fix
|
||||
- PR has Santosh approval, but still needs code-owner approval before merge and story completion
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- This ticket is tied to an AO DOB validation issue.
|
||||
- The issue was confirmed for authenticated users in the `HybridYouthAccountOpening` flow on the `TeenIdentityCheck` page.
|
||||
|
||||
---
|
||||
|
||||
## Confirmed Findings
|
||||
|
||||
- The issue reproduces only for authenticated users based on the currently stored evidence.
|
||||
- The Youth / `TeenIdentityCheck` scenario is the iOS-only issue; do not describe it as reproducing on Android.
|
||||
- Root cause was documented.
|
||||
- The original external report was incomplete.
|
||||
- For the config discussion, `CheckIdentity` was already correct. The `TeenIdentityCheck` issue had two config gaps inside `validation-rules`: the root key should be `validations`, and the age gate also needs `eighteenOrAbove` there when that rule is required.
|
||||
- Follow-up validation on April 13 showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
|
||||
- A `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario reproduces on both iOS and Android.
|
||||
- A `HybridYouthAccountOpening` / `TeenIdentityCheck` scenario works on Android but fails on iOS.
|
||||
- Current evidence suggests Android is more flexible in how it decodes rule variations, while iOS is stricter about the expected `validation-rules` structure.
|
||||
- Later validation on April 15 showed the original `HybridYouthAccountOpening` / `TeenIdentityCheck` issue no longer reproduces once the payload uses `validations` instead of `birthDate`.
|
||||
- A minimal XFlowSDK fix was still prepared on April 15 so the iOS `.apxDateSelect` path also falls back to `birthDate` for a future release.
|
||||
- Jeff confirmed on April 15 that this minimal iOS fallback is the right fix direction for the Youth / `TeenIdentityCheck` case and approved opening the PR under the same story.
|
||||
- On April 16, Jeff decided the iOS PR should be the primary fix path for the Youth / `TeenIdentityCheck` issue rather than relying on a separate service rollout.
|
||||
|
||||
---
|
||||
|
||||
## Current Guidance
|
||||
|
||||
- Treat the iOS-only `HybridYouthAccountOpening` / `TeenIdentityCheck` discrepancy as the main client-side issue currently aligned with the story.
|
||||
- Keep the cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario separate until it is clear whether it is a service/config issue, a distinct bug, or an unreported rule-processing difference.
|
||||
- Keep the authenticated-user qualifier whenever this ticket is mentioned.
|
||||
- Do not describe it as a generic validation issue without the `TeenIdentityCheck` and auth context.
|
||||
- The originally reported Youth issue was fixed for the Youth-flow `TeenIdentityCheck` path by the service-side payload update from `birthDate` to `validations`; local Fid4 validation also confirmed it. The XFlowSDK fallback PR should still be released so iOS handles the older `birthDate` format more safely.
|
||||
- That service-side Youth fix was later rolled back in QA so the iOS PR can remain the single fix path; local Fid4 validation with the PR still confirmed the `birthDate` validation works correctly.
|
||||
- Jeff provided historical context that these fallback paths exist largely to accommodate older AO payload conventions; when the issue is AO-specific, iOS-only, and caused by a service-vs-SDK key mismatch, this kind of iOS fallback is the usual fix.
|
||||
- The `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is different from the original Youth report: the rule content itself does not include `ageRange` or `eighteenOrAbove`, so that path still points to a service-side update rather than the same iOS parsing gap.
|
||||
- David compared `HybridBrokerageAccountOpening` / `JointIdentityCheck` in Cogstore and found the relevant rule content is the same in QA and Production despite different flow-definition versions, so that separate issue should also exist in Production.
|
||||
- The small iOS PR should be described as a compatibility safeguard for future older-format payloads and should not be framed as applying to the `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue.
|
||||
- The service-side `birthDate` -> `validations` change and the small iOS PR both relate to the same Youth / `TeenIdentityCheck` issue; they should not be described as separate Youth issues.
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
- Get the small XFlowSDK compatibility PR reviewed and released.
|
||||
- Send one more AO working-group Teams summary that points to the Jira comment, Discourse comment, and PR while keeping the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue clearly out of the original Youth-fix scope.
|
||||
- Keep the final AO working-group message very explicit about there being two flow scenarios: the Youth iOS-only issue now handled by the service change plus iOS fallback, and the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue.
|
||||
- Update that AO working-group message so it now reflects the final framing: the original Youth issue is fixed on the iOS side, and the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is the remaining service-side follow-up.
|
||||
- Close the story with comments explaining that the immediate Youth issue was resolved on the service side and that the XFlowSDK fallback fix will be available in the next release.
|
||||
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of the client-fix scope unless later evidence proves it is part of the same issue.
|
||||
- Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.
|
||||
@@ -1,38 +0,0 @@
|
||||
# PDIAP-15836 - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
|
||||
|
||||
## Status
|
||||
|
||||
- Approved
|
||||
- Sequenced after `PDIAP-15838`
|
||||
- Sized at `8` points
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- This story came out of the `AccountLink` root cause investigation.
|
||||
- It is tied to the dismissal sequencing problem found after UIKit removal in SwiftUI-only paths.
|
||||
- The root cause document was updated and the revised wording was approved.
|
||||
|
||||
---
|
||||
|
||||
## Approved Scope
|
||||
|
||||
- Modernize dismissal delegate lifecycle sequencing for pure SwiftUI flows.
|
||||
- Cover the missing lifecycle contract where delegate callbacks can happen before the view is fully removed.
|
||||
- Validate the change across affected SwiftUI flows rather than only in one narrow reproduction.
|
||||
|
||||
---
|
||||
|
||||
## Sequencing And Dependencies
|
||||
|
||||
- This story should come after `PDIAP-15838`.
|
||||
- It is aligned with epic `26Q2 - Updating XFlowSDK to Decouple and Fix ApexKit Dependencies (Split Part 2)`.
|
||||
- If possible, it should use the same consumer-impact feature flag strategy as the broader UIKit-removal rollout.
|
||||
|
||||
---
|
||||
|
||||
## Communication Notes
|
||||
|
||||
- Keep the scope framed as lifecycle sequencing in a pure SwiftUI environment, not only as a symptom like multiple modal presentation.
|
||||
- If mentioned externally, keep it separate from `PDIAP-15838`.
|
||||
@@ -1,37 +0,0 @@
|
||||
# PDIAP-15838 - Remove Apollo for iOS
|
||||
|
||||
## Status
|
||||
|
||||
- Approved
|
||||
- Next story to work on
|
||||
- Sized at `8` points
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- This ticket covers the REST migration cleanup on iOS.
|
||||
- The approved title is `Remove Apollo for iOS`.
|
||||
|
||||
---
|
||||
|
||||
## Approved Scope
|
||||
|
||||
- Remove Apollo from iOS.
|
||||
- Remove GraphQL-specific networking code.
|
||||
- Remove related tests and mocks.
|
||||
- Remove transport feature flags so REST remains.
|
||||
|
||||
---
|
||||
|
||||
## Current Guidance
|
||||
|
||||
- Do not frame this ticket as directly tied to the UIKit-removal spike.
|
||||
- Do not imply it is dependent on or part of dismissal-sequencing work.
|
||||
- Keep the migration framing explicit: REST remains behind a feature flag until otherwise confirmed, and GraphQL fallback context still matters when describing the overall migration.
|
||||
|
||||
---
|
||||
|
||||
## Sequencing
|
||||
|
||||
- This is the next story to work on before `PDIAP-15836`.
|
||||
Reference in New Issue
Block a user