Add daily logs and templates for project fidelity
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
This commit is contained in:
1
workspaces/fidelity/inbox/.gitkeep
Normal file
1
workspaces/fidelity/inbox/.gitkeep
Normal file
@@ -0,0 +1 @@
|
||||
|
||||
12
workspaces/fidelity/inbox/README.md
Normal file
12
workspaces/fidelity/inbox/README.md
Normal file
@@ -0,0 +1,12 @@
|
||||
# Mattermost Inbox
|
||||
|
||||
This directory stores raw or semi-processed communication captured from Mattermost before it is promoted into the persistent workspace context.
|
||||
|
||||
Recommended usage:
|
||||
|
||||
- `mattermost-mirror/` is the preferred local Mattermost evidence source when present. It stores `latest.*`, `by-date/`, `channels/`, `threads/`, and `refs/` views from the local proxy mirror.
|
||||
- `mattermost-latest.md` contains the legacy most recent sync capture
|
||||
- timestamped snapshots can be stored here if needed
|
||||
- durable facts should be promoted into `workspaces/fidelity/project-knowledge/06-daily/`, `workspaces/fidelity/project-knowledge/01-current/`, `workspaces/fidelity/project-knowledge/02-work-items/`, `workspaces/fidelity/project-knowledge/03-context/`, `workspaces/fidelity/project-knowledge/04-people/`, or `workspaces/fidelity/project-knowledge/05-decisions/`
|
||||
|
||||
This directory is intentionally treated as an inbox, not as the final source of truth.
|
||||
@@ -0,0 +1,104 @@
|
||||
# Charles Session File Format (.chlsx)
|
||||
|
||||
Reference for AI agents that need to parse Charles Proxy session files.
|
||||
|
||||
---
|
||||
|
||||
## File Format
|
||||
|
||||
`.chlsx` is a **ZIP archive** containing numbered XML files, each representing one HTTP request/response pair.
|
||||
|
||||
### Structure inside the ZIP
|
||||
|
||||
```
|
||||
session.chlsx
|
||||
├── 00001.xml
|
||||
├── 00002.xml
|
||||
├── 00003.xml
|
||||
├── ...
|
||||
└── 00/
|
||||
├── 00001.xml
|
||||
├── 00002.xml
|
||||
└── ...
|
||||
```
|
||||
|
||||
Files may be flat at the root or grouped in two-digit subdirectories (`00/`, `01/`, etc.) depending on session size.
|
||||
|
||||
### XML Structure Per File
|
||||
|
||||
Each XML file contains:
|
||||
|
||||
- **Request**: method, URL, protocol, headers, body
|
||||
- **Response**: status, protocol, headers, body
|
||||
- **Timing**: start time, duration
|
||||
|
||||
Key XML elements:
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<session>
|
||||
<request>
|
||||
<method>GET</method>
|
||||
<url>https://discourse.example.com/t/123.json</url>
|
||||
<protocol>HTTP/1.1</protocol>
|
||||
<header name="Accept">application/json</header>
|
||||
<header name="Cookie">_t=abc123</header>
|
||||
<body></body>
|
||||
</request>
|
||||
<response>
|
||||
<status>200</status>
|
||||
<protocol>HTTP/1.1</protocol>
|
||||
<header name="Content-Type">application/json; charset=utf-8</header>
|
||||
<body>{"id": 123, "title": "...", "post_stream": {...}}</body>
|
||||
</response>
|
||||
<timing>
|
||||
<start>2026-01-15T10:30:00.000Z</start>
|
||||
<duration>450</duration>
|
||||
</timing>
|
||||
</session>
|
||||
```
|
||||
|
||||
### .chls vs .chlsx vs .chlsj
|
||||
|
||||
| Extension | Format | Notes |
|
||||
|---|---|---|
|
||||
| `.chls` | Binary | Legacy format, harder to parse |
|
||||
| `.chlsx` | ZIP + XML | **Prefer this**. Most common modern format |
|
||||
| `.chlsj` | JSON | Newer, less common; each session is one JSON file with an array of request/response objects |
|
||||
|
||||
**Recommendation**: Configure Charles to save as `.chlsx` (File → Save Session As... → choose `.chlsx`).
|
||||
|
||||
---
|
||||
|
||||
## Discourse API Endpoints to Look For
|
||||
|
||||
These are the endpoints worth extracting from a Charles session:
|
||||
|
||||
| Purpose | URL pattern | Parsing target |
|
||||
|---|---|---|
|
||||
| Topic feed | `/latest.json` | `topic_list.topics[]` |
|
||||
| Category topics | `/c/{slug}.json` | `topic_list.topics[]` |
|
||||
| Single topic | `/t/{id}.json` | The full topic with posts |
|
||||
| Posts in topic | `/t/{id}/{page}.json` | Paginated posts |
|
||||
| Search | `/search.json?q=...` | `topics[]`, `posts[]` |
|
||||
| User activity | `/u/{username}/activity.json` | User posts/topics |
|
||||
|
||||
---
|
||||
|
||||
## Extraction Strategy for AI
|
||||
|
||||
1. **Open the `.chlsx` as a ZIP** (it is not encrypted)
|
||||
2. **Iterate over all XML files** inside
|
||||
3. For each XML, check if the request URL matches a Discourse API endpoint
|
||||
4. Extract the JSON response body from `<response><body>`
|
||||
5. Parse the JSON and convert to Markdown
|
||||
6. Organize by topic ID + title for easy search
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- Some responses are paginated (`/t/{id}.json?page=1`). Collect all pages for completeness.
|
||||
- Binary responses (images, JS bundles) should be skipped.
|
||||
- The same topic may appear multiple times in different Charles sessions; deduplicate by topic ID + last updated timestamp.
|
||||
- Session cookies captured in Charles will be expired by the time the AI reads them; only the response data matters.
|
||||
@@ -0,0 +1,140 @@
|
||||
---
|
||||
type: copilot-prompt
|
||||
status: ready
|
||||
target: github-copilot
|
||||
purpose: Parse Charles .chlsx sessions to create a searchable Discourse archive
|
||||
---
|
||||
|
||||
# Copilot Prompt — Charles Discourse Archiver
|
||||
|
||||
Paste this into GitHub Copilot on the corporate device.
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
You are helping me build a local searchable archive of a Discourse forum from captured Charles Proxy session files.
|
||||
|
||||
### Background
|
||||
|
||||
I browse a Discourse forum in my browser while Charles Proxy records traffic. I save the session as a `.chlsx` file. Inside that file are all the HTTP request/response pairs for the pages I visited — including Discourse API calls that return structured JSON (topics, posts, categories, user profiles).
|
||||
|
||||
I need you to extract only the Discourse content and organize it into a Markdown archive that:
|
||||
- Is searchable by an AI in future sessions
|
||||
- Preserves topic titles, post authors, dates, and content
|
||||
- Groups by category
|
||||
- Deduplicates topics that appear across multiple sessions
|
||||
|
||||
### File format: `.chlsx`
|
||||
|
||||
`.chlsx` is a ZIP archive. Inside are numbered XML files (e.g. `00001.xml`, `00/00001.xml`). Each XML file represents one HTTP request/response pair with this structure:
|
||||
|
||||
```xml
|
||||
<session>
|
||||
<request>
|
||||
<method>GET</method>
|
||||
<url>https://forum.example.com/t/123.json</url>
|
||||
<protocol>HTTP/1.1</protocol>
|
||||
<header name="Cookie">...</header>
|
||||
<body></body>
|
||||
</request>
|
||||
<response>
|
||||
<status>200</status>
|
||||
<protocol>HTTP/1.1</protocol>
|
||||
<header name="Content-Type">application/json; charset=utf-8</header>
|
||||
<body>{"id": 123, "title": "Some Topic", "post_stream": {...}}</body>
|
||||
</response>
|
||||
<timing>
|
||||
<start>2026-01-15T10:30:00.000Z</start>
|
||||
<duration>450</duration>
|
||||
</timing>
|
||||
</session>
|
||||
```
|
||||
|
||||
### Discourse API endpoints to extract
|
||||
|
||||
| What | URL pattern | JSON fields |
|
||||
|---|---|---|
|
||||
| Latest topics | `/latest.json` | `topic_list.topics[].{id, title, slug, category_id, created_at, last_posted_at}` |
|
||||
| Category index | `/categories.json` | `category_list.categories[].{id, name, slug}` |
|
||||
| Single topic (with posts) | `/t/{id}.json` | `id, title, slug, category_id, post_stream.posts[].{username, cooked, created_at, post_number}` |
|
||||
| Topic with page | `/t/{id}/{page}.json` | Same as above, paginated |
|
||||
| User activity | `/u/{username}/activity.json` | `user_actions[]` |
|
||||
| Search results | `/search.json?q=...` | `topics[]`, `posts[]` |
|
||||
|
||||
### What to do
|
||||
|
||||
1. **Open the `.chlsx` file** as a ZIP archive.
|
||||
2. **List all XML files** inside (both flat and in subdirectories).
|
||||
3. **For each XML file**, parse it and check if the request URL matches one of the Discourse endpoints above.
|
||||
4. **Skip**: CSS, JS, images, font files, analytics, CDN assets, and any non-Discourse endpoint.
|
||||
5. **Parse the JSON response body** from `<response><body>`.
|
||||
6. **Create this folder structure** as output:
|
||||
|
||||
```
|
||||
discourse-archive/
|
||||
├── categories.json # All categories found
|
||||
├── index.md # Master index (table of all topics with ID, title, date, category, URL)
|
||||
├── topics/
|
||||
│ ├── 123-your-topic-slug.md
|
||||
│ ├── 456-another-topic.md
|
||||
│ └── ...
|
||||
```
|
||||
|
||||
### Markdown format per topic
|
||||
|
||||
Each topic file should be a clean Markdown document with YAML frontmatter:
|
||||
|
||||
```markdown
|
||||
---
|
||||
id: 123
|
||||
title: "Your Topic Title"
|
||||
slug: your-topic-slug
|
||||
category: "Category Name"
|
||||
created: 2026-01-15
|
||||
updated: 2026-01-16
|
||||
url: https://forum.example.com/t/your-topic-slug/123
|
||||
---
|
||||
|
||||
# Your Topic Title
|
||||
|
||||
**Category**: Category Name
|
||||
|
||||
---
|
||||
|
||||
## Post 1 — @username1 (2026-01-15T10:30:00Z)
|
||||
|
||||
Post content here (HTML stripped, plain Markdown preferred).
|
||||
|
||||
---
|
||||
|
||||
## Post 2 — @username2 (2026-01-16T14:00:00Z)
|
||||
|
||||
More content.
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
### Deduplication rules
|
||||
|
||||
- If the same topic ID appears in multiple `.chlsx` files, keep the one with the most recent `last_posted_at`.
|
||||
- If a session has page 2+ of a topic (`/t/123/2.json`), merge the posts with page 1.
|
||||
- Never duplicate posts within a topic.
|
||||
|
||||
### What to do with the output
|
||||
|
||||
Place the resulting `discourse-archive/` folder in a location I can reference in future Copilot sessions. I will point Copilot to that folder when I need to search past Discourse conversations.
|
||||
|
||||
### Constraints
|
||||
|
||||
- Do not modify the original `.chlsx` file.
|
||||
- Do not upload or send the extracted data anywhere — keep it local.
|
||||
- If a topic has no readable content (deleted, access restricted), note it in the index but skip the full extraction.
|
||||
- HTML in `cooked` fields should be converted to readable plain text / Markdown (Discourse stores posts as HTML in the JSON).
|
||||
|
||||
### First action
|
||||
|
||||
Ask me for:
|
||||
1. The path to the `.chlsx` file (or files)
|
||||
2. The Discourse base URL (so you can construct canonical topic URLs)
|
||||
3. Where I want the output folder created
|
||||
1
workspaces/fidelity/inbox/photos/.gitkeep
Normal file
1
workspaces/fidelity/inbox/photos/.gitkeep
Normal file
@@ -0,0 +1 @@
|
||||
|
||||
10
workspaces/fidelity/project-knowledge/.obsidian/app.json
vendored
Normal file
10
workspaces/fidelity/project-knowledge/.obsidian/app.json
vendored
Normal file
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"attachmentFolderPath": "attachments",
|
||||
"newFileLocation": "current",
|
||||
"userIgnoreFilters": [
|
||||
"**/.venv/",
|
||||
"**/generated/",
|
||||
"**/__pycache__/",
|
||||
"**/*.pyc"
|
||||
]
|
||||
}
|
||||
1
workspaces/fidelity/project-knowledge/.obsidian/appearance.json
vendored
Normal file
1
workspaces/fidelity/project-knowledge/.obsidian/appearance.json
vendored
Normal file
@@ -0,0 +1 @@
|
||||
{}
|
||||
39
workspaces/fidelity/project-knowledge/.obsidian/bookmarks.json
vendored
Normal file
39
workspaces/fidelity/project-knowledge/.obsidian/bookmarks.json
vendored
Normal file
@@ -0,0 +1,39 @@
|
||||
{
|
||||
"items": [
|
||||
{
|
||||
"type": "file",
|
||||
"path": "00-start/start-here.md",
|
||||
"title": "Start Here"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"path": "00-start/onboarding.md",
|
||||
"title": "Onboarding"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"path": "01-current/current-work.md",
|
||||
"title": "Current Work"
|
||||
},
|
||||
{
|
||||
"type": "folder",
|
||||
"path": "02-work-items",
|
||||
"title": "Work Items"
|
||||
},
|
||||
{
|
||||
"type": "folder",
|
||||
"path": "04-people",
|
||||
"title": "People"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"path": "08-bases/work-items.base",
|
||||
"title": "Work Items Base"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"path": "08-bases/people.base",
|
||||
"title": "People Base"
|
||||
}
|
||||
]
|
||||
}
|
||||
33
workspaces/fidelity/project-knowledge/.obsidian/core-plugins.json
vendored
Normal file
33
workspaces/fidelity/project-knowledge/.obsidian/core-plugins.json
vendored
Normal file
@@ -0,0 +1,33 @@
|
||||
{
|
||||
"file-explorer": true,
|
||||
"global-search": true,
|
||||
"switcher": true,
|
||||
"graph": true,
|
||||
"backlink": true,
|
||||
"canvas": true,
|
||||
"outgoing-link": true,
|
||||
"tag-pane": true,
|
||||
"footnotes": false,
|
||||
"properties": true,
|
||||
"page-preview": true,
|
||||
"daily-notes": true,
|
||||
"templates": true,
|
||||
"note-composer": true,
|
||||
"command-palette": true,
|
||||
"slash-command": false,
|
||||
"editor-status": true,
|
||||
"bookmarks": true,
|
||||
"markdown-importer": false,
|
||||
"zk-prefixer": false,
|
||||
"random-note": false,
|
||||
"outline": true,
|
||||
"word-count": true,
|
||||
"slides": false,
|
||||
"audio-recorder": false,
|
||||
"workspaces": false,
|
||||
"file-recovery": true,
|
||||
"publish": false,
|
||||
"sync": false,
|
||||
"bases": true,
|
||||
"webviewer": false
|
||||
}
|
||||
5
workspaces/fidelity/project-knowledge/.obsidian/daily-notes.json
vendored
Normal file
5
workspaces/fidelity/project-knowledge/.obsidian/daily-notes.json
vendored
Normal file
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"format": "YYYY-MM-DD",
|
||||
"folder": "06-daily",
|
||||
"template": "09-templates/daily.md"
|
||||
}
|
||||
3
workspaces/fidelity/project-knowledge/.obsidian/templates.json
vendored
Normal file
3
workspaces/fidelity/project-knowledge/.obsidian/templates.json
vendored
Normal file
@@ -0,0 +1,3 @@
|
||||
{
|
||||
"folder": "09-templates"
|
||||
}
|
||||
7
workspaces/fidelity/project-knowledge/.obsidian/types.json
vendored
Normal file
7
workspaces/fidelity/project-knowledge/.obsidian/types.json
vendored
Normal file
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"types": {
|
||||
"aliases": "multitext",
|
||||
"cssclasses": "multitext",
|
||||
"tags": "tags"
|
||||
}
|
||||
}
|
||||
51
workspaces/fidelity/project-knowledge/00-start/glossary.md
Normal file
51
workspaces/fidelity/project-knowledge/00-start/glossary.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
type: glossary
|
||||
audience: new-member
|
||||
tags:
|
||||
- onboarding
|
||||
- glossary
|
||||
---
|
||||
|
||||
# Glossary
|
||||
|
||||
Common terms used in the Fidelity project knowledge vault.
|
||||
|
||||
---
|
||||
|
||||
## Workspace Terms
|
||||
|
||||
- `workspaces/fidelity/project-knowledge`: this Obsidian vault; transferable Fidelity project knowledge.
|
||||
- `agent-memory`: agent operating rules outside this vault.
|
||||
- `operational memory`: curated file-based memory that helps future sessions reason accurately.
|
||||
- `daily log`: same-day evidence and evolving findings in `workspaces/fidelity/project-knowledge/06-daily/`.
|
||||
- `state`: near-term active work and priorities in `workspaces/fidelity/project-knowledge/01-current/`.
|
||||
- `work item`: canonical memory for a ticket, story, task, or investigation in `workspaces/fidelity/project-knowledge/02-work-items/`.
|
||||
- `stable context`: durable project knowledge under `workspaces/fidelity/project-knowledge/03-context/`.
|
||||
- `inbox`: raw or lightly processed communication evidence under `workspaces/fidelity/inbox/`.
|
||||
- `promotion`: moving high-confidence evidence into canonical memory.
|
||||
- `memory interface`: project-agnostic scripts under `scripts/memory/` that create, search, query, and validate project knowledge without coupling the workspace to Obsidian.
|
||||
|
||||
---
|
||||
|
||||
## Fidelity Terms
|
||||
|
||||
- `Fid4`: main Fidelity consumer iOS app and key validation environment.
|
||||
- `XFlowSDK`: backend-driven UI engine that renders flows from service-provided configuration.
|
||||
- `XFlowViewMaker`: adapter layer historically involved in integration and release propagation.
|
||||
- `FTFrameworks`: feature modules such as account opening or transfer flows that can mediate XFlow adoption.
|
||||
- `AO`: account opening context; many reports require careful reproduction and scope validation.
|
||||
- `Discourse`: external issue/report source; treat reports as external until confirmed.
|
||||
- `REST migration`: migration away from GraphQL/Apollo toward REST, with REST behind a feature flag unless confirmed otherwise.
|
||||
- `authenticated flow`: behavior reproduced while signed in; often differs from non-authenticated behavior.
|
||||
- `entry point`: the path used to reach a flow, which can affect backend-driven behavior.
|
||||
- `Cogstore`: flow-configuration publishing and version-comparison platform.
|
||||
|
||||
---
|
||||
|
||||
## Communication Terms
|
||||
|
||||
- `external report`: issue reported externally before regression status is confirmed.
|
||||
- `regression`: behavior confirmed to be newly broken relative to a known baseline.
|
||||
- `scope`: the exact affected flow, platform, auth state, environment, and ownership boundary.
|
||||
- `reproducibility`: whether the behavior can be repeated with known steps and context.
|
||||
- `manager-ready`: concise, explicit, natural professional English that can be sent without rewriting.
|
||||
93
workspaces/fidelity/project-knowledge/00-start/onboarding.md
Normal file
93
workspaces/fidelity/project-knowledge/00-start/onboarding.md
Normal file
@@ -0,0 +1,93 @@
|
||||
---
|
||||
type: onboarding
|
||||
audience: new-member
|
||||
project: fidelity
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- onboarding
|
||||
- map
|
||||
---
|
||||
|
||||
# New Member Onboarding
|
||||
|
||||
Use this guide when someone new needs to understand the Fidelity project context quickly.
|
||||
|
||||
This vault is project knowledge, not the product codebase and not the agent implementation manual.
|
||||
|
||||
---
|
||||
|
||||
## First 30 Minutes
|
||||
|
||||
Read these in order:
|
||||
|
||||
1. [Start Here](start-here.md)
|
||||
2. [Current Work Map](../07-maps/current-work.md)
|
||||
3. [Fidelity Domain Map](../07-maps/fidelity-domain.md)
|
||||
4. [Work Items Map](../07-maps/work-items.md)
|
||||
5. [People Map](../07-maps/people.md)
|
||||
|
||||
Goal:
|
||||
|
||||
- understand where current work lives
|
||||
- identify active tickets
|
||||
- understand the main systems and people
|
||||
- avoid treating raw logs or inbox evidence as confirmed durable truth
|
||||
|
||||
---
|
||||
|
||||
## First 60 Minutes
|
||||
|
||||
Read:
|
||||
|
||||
1. [Project Context](../03-context/project.md)
|
||||
2. [XFlowSDK](../03-context/systems/xflowsdk.md)
|
||||
3. [Fid4](../03-context/systems/fid4.md)
|
||||
4. [REST Migration](../03-context/workstreams/rest-migration.md)
|
||||
5. [AO And Discourse](../03-context/workstreams/ao-discourse.md)
|
||||
6. [Communication](../03-context/process/communication.md)
|
||||
|
||||
Goal:
|
||||
|
||||
- understand why auth state, entry point, and backend configuration matter
|
||||
- distinguish external reports from regressions
|
||||
- understand why communication precision is part of the engineering workflow
|
||||
|
||||
---
|
||||
|
||||
## First 120 Minutes
|
||||
|
||||
Read:
|
||||
|
||||
1. [Systems Index](../03-context/systems/index.md)
|
||||
2. [Workstreams Index](../03-context/workstreams/index.md)
|
||||
3. [iOS Context](../03-context/ios/index.md)
|
||||
4. [Jira Story Rules](../03-context/process/jira-story-rules.md)
|
||||
5. [Pull Requests](../03-context/process/pull-requests.md)
|
||||
|
||||
Goal:
|
||||
|
||||
- understand how Fidelity project knowledge is organized
|
||||
- know where to find durable systems, workstreams, people, decisions, and active tickets
|
||||
- know the communication standards expected for standups, Jira, PRs, and manager updates
|
||||
|
||||
---
|
||||
|
||||
## Daily Workflow
|
||||
|
||||
1. Start from [Current Work Map](../07-maps/current-work.md).
|
||||
2. Check [Current Work](../01-current/current-work.md).
|
||||
3. Open the active work item from [Work Items Map](../07-maps/work-items.md).
|
||||
4. Review the latest relevant note from [Daily Notes Index](../06-daily/index.md).
|
||||
5. Use [Communication](../03-context/process/communication.md) before writing standups, Jira comments, or manager updates.
|
||||
|
||||
---
|
||||
|
||||
## Rules Of Thumb
|
||||
|
||||
- `workspaces/fidelity/project-knowledge/06-daily/` is dated work evidence.
|
||||
- `workspaces/fidelity/project-knowledge/01-current/` is what matters now.
|
||||
- `workspaces/fidelity/project-knowledge/02-work-items/` is canonical ticket memory.
|
||||
- `workspaces/fidelity/project-knowledge/03-context/` is durable project knowledge.
|
||||
- `workspaces/fidelity/project-knowledge/04-people/` is collaborator and role memory.
|
||||
- `workspaces/fidelity/project-knowledge/05-decisions/` is durable decision history.
|
||||
- `workspaces/fidelity/inbox/` and generated files are raw evidence, not promoted memory.
|
||||
93
workspaces/fidelity/project-knowledge/00-start/start-here.md
Normal file
93
workspaces/fidelity/project-knowledge/00-start/start-here.md
Normal file
@@ -0,0 +1,93 @@
|
||||
---
|
||||
type: map
|
||||
audience: project-reader
|
||||
project: fidelity
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- map
|
||||
- onboarding
|
||||
---
|
||||
|
||||
# Start Here
|
||||
|
||||
Use this note as the entry point when opening `workspaces/fidelity/project-knowledge/` as the Obsidian vault.
|
||||
|
||||
This vault is the Fidelity project second brain. It is meant to be useful to the engineer, a new teammate, or an AI agent consuming project context. Agent implementation rules live outside this vault in `agent-memory/`.
|
||||
|
||||
---
|
||||
|
||||
## New Members
|
||||
|
||||
Read these first:
|
||||
|
||||
1. [New Member Onboarding](onboarding.md)
|
||||
2. [Glossary](glossary.md)
|
||||
3. [Current Work Map](../07-maps/current-work.md)
|
||||
4. [Fidelity Domain Map](../07-maps/fidelity-domain.md)
|
||||
5. [Fidelity Apps Map](../07-maps/fidelity-apps.md)
|
||||
6. [People Map](../07-maps/people.md)
|
||||
|
||||
---
|
||||
|
||||
## Current Work
|
||||
|
||||
- [Current State](../01-current/current-work.md)
|
||||
- [Active Work Items](../01-current/work-items.md)
|
||||
- [Work Item Index](../02-work-items/index.md)
|
||||
- [Daily Notes Index](../06-daily/index.md)
|
||||
|
||||
---
|
||||
|
||||
## Stable Context
|
||||
|
||||
- [Project Context](../03-context/project.md)
|
||||
- [Context Index](../03-context/index.md)
|
||||
- [Systems Index](../03-context/systems/index.md)
|
||||
- [Workstreams Index](../03-context/workstreams/index.md)
|
||||
- [People Index](../04-people/index.md)
|
||||
- [Manager Mapping](../04-people/manager.md)
|
||||
- [Decisions](../05-decisions/rest-vs-graphql.md)
|
||||
|
||||
---
|
||||
|
||||
## Project-Facing Process
|
||||
|
||||
- [Communication](../03-context/process/communication.md)
|
||||
- [Communication Rules](../03-context/process/communication-rules.md)
|
||||
- [Jira Story Rules](../03-context/process/jira-story-rules.md)
|
||||
- [Pull Requests](../03-context/process/pull-requests.md)
|
||||
|
||||
---
|
||||
|
||||
## Maps
|
||||
|
||||
- [Knowledge Maps](../07-maps/index.md)
|
||||
- [Current Work](../07-maps/current-work.md)
|
||||
- [Fidelity Domain](../07-maps/fidelity-domain.md)
|
||||
- [Fidelity Apps](../07-maps/fidelity-apps.md)
|
||||
- [Work Items](../07-maps/work-items.md)
|
||||
- [People](../07-maps/people.md)
|
||||
|
||||
---
|
||||
|
||||
## Daily Notes
|
||||
|
||||
Daily notes live in:
|
||||
|
||||
```text
|
||||
workspaces/fidelity/project-knowledge/06-daily/
|
||||
```
|
||||
|
||||
Use the latest dated note for recent evidence, but promote durable facts into `01-current/`, `02-work-items/`, or `03-context/` when they should survive beyond the day.
|
||||
|
||||
---
|
||||
|
||||
## Evidence Boundary
|
||||
|
||||
Inbox and generated files are evidence, not durable memory by default.
|
||||
|
||||
- `workspaces/fidelity/inbox/`
|
||||
- `scripts/mattermost/generated/`
|
||||
- `scripts/slack/generated/`
|
||||
|
||||
Promote only high-confidence, project-relevant facts into this vault.
|
||||
152
workspaces/fidelity/project-knowledge/01-current/current-work.md
Normal file
152
workspaces/fidelity/project-knowledge/01-current/current-work.md
Normal file
@@ -0,0 +1,152 @@
|
||||
---
|
||||
type: current
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-05-14
|
||||
tags:
|
||||
- current-work
|
||||
- fidelity
|
||||
---
|
||||
# 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 `workspaces/fidelity/project-knowledge/02-work-items/`, especially branch maintenance for `PDIAP-15838` and implementation planning for `PDIAP-15836` / `PDIAP-12284`
|
||||
- `PDIAP-15765` is done and `PDIAP-14859` is also done
|
||||
- `PDIAP-15838` is Done from a Jira/status perspective after external review feedback was addressed, but its draft PR must remain unmerged and kept current with `main` until REST backend production readiness and the required REST-toggle consumer validation window allow merge
|
||||
- `PDIAP-15836` has moved to In Progress. David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, but Jeff directed David to do the `PDIAP-15836` dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch because both are disruptive enough to require consumer testing.
|
||||
- `PDIAP-12284` remains paired with `PDIAP-15836`; plan the branch as combined UIKit-removal / SwiftUI lifecycle work rather than splitting the dismissal sequencing into an independently merged path unless direction changes.
|
||||
- Current `PDIAP-12284` implementation direction is to explore XFlowViewMaker-owned global host-mode resolution rather than Fid4-owned per-flow host-mode mapping: SwiftUI host should remain the default, missing/unknown feature configuration should also default to SwiftUI, and `UIHostingController` should be selected only through an explicit temporary fallback flag.
|
||||
- Keep host-mode resolution decoupled from XFlowSDK and app-specific LaunchDarkly/Flagship clients; XFlowSDK should consume a resolved host-mode decision, while Copilot/code inspection should confirm whether XFlowViewMaker can use existing `FeatureEnabling` / `Featuring` abstractions or needs a small dependency-injection path.
|
||||
- May 12 implementation pass for `PDIAP-12284` / `PDIAP-15836` indicates the host-mode API is branch-local/new, keeps two enum types to preserve the XFlowViewMaker/XFlowSDK boundary, uses neutral `swiftUIHost` / `uiKitHost` cases, sets the feature flag key to `iOS-XflowUIKitHostEnabled`, defaults missing/false/unavailable values to SwiftUI, and removes `AnyView` from `buildFlow` internals while leaving it only at the existing public `FlowViewMaker` boundary.
|
||||
- Current compile validation blocker for that branch appears to be dependency alignment: XFlowViewMaker's podspec resolves `XFlowSDK 2.8.48`, which does not expose the new host-mode API; XFlowSDK SwiftPM validation is also blocked in the current environment by missing `fidelity-src` registry configuration.
|
||||
- After manual dependency/build handling, Fid4 now compiles with the latest `FlowViewBuilder` shape. Next validation should be runtime log evidence: confirm a representative flow selects the default SwiftUI host path, then simulate/force `iOS-XflowUIKitHostEnabled == true` to confirm the temporary UIKit host path and dismissal-completion behavior.
|
||||
- `PDIAP-12284` moved to In Progress on May 12. Quy confirmed on May 13 that `PDIAP-12284` and `PDIAP-15836` can both remain In Progress together, so no immediate Jira restructuring is required.
|
||||
- Latest `PDIAP-12284` / `PDIAP-15836` simulator log review suggests the SwiftUI-host dismissal sequence is firing in the intended order for the tested run: host disappearance is confirmed before `fireEndActivityDelegates`, delegate callbacks, and `activitySession` cleanup. Treat this as a promising validation run, not final story closure.
|
||||
- May 13 AccountLink runtime validation looks good in both host modes: SwiftUI-default and forced UIKit-host paths selected the expected host branch and preserved dismissal sequencing, with delegate/session teardown after confirmed dismissal. Before push, clean temporary debug prints and consider moving dismissal-specific helper types out of `XFlowManager.swift` into a dedicated dismissal file.
|
||||
- Follow-up SampleApp validation found a likely branch-introduced dismissal regression caused by host-mode mismatch: SampleApp uses `initialViewController(...)` / UIKit presentation, but the branch defaulted manager host mode to SwiftUI, so `endActivity` can take the SwiftUI subject path without a SwiftUI dismissal host subscriber. Fix direction should preserve existing behavior by keeping `initialViewController(...)` on the UIKit dismiss-completion path and `makeInitialFlowView(...)` on the SwiftUI lifecycle path.
|
||||
- SampleApp should support explicit validation of both UIKit-host and SwiftUI-host scenarios. XFlowSDK should remain self-aware of which dismissal mechanism to use based on the active integration path, so SampleApp can exercise both paths without relying on stale singleton/default host-mode state.
|
||||
- May 14 SampleApp iteration: SampleApp was updated to choose between UIKit-host (`initialViewController(...)`) and SwiftUI-host (`makeInitialFlowView(...)`) paths from the existing `Use SwiftUI` setting / feature-toggle path. XFlowSDK entrypoints now prepare the matching dismissal mechanism, and the SampleApp SwiftUI-host rendering was refined to use a `ViewBuilder`/`flowContent` approach rather than storing an `AnyView` in state. Next validation is SampleApp back-to-back host-mode switching plus Fid4 AccountLink revalidation in both host modes.
|
||||
- Jeff recommended expanding validation beyond AccountLink before PR review: test as many current Fid4 XFlow entry and dismissal points as possible in both default SwiftUI-host and forced UIKit-host modes, with particular attention to AO flows. Use the existing Confluence entry-point list as a starting point, but verify it against current code and temporary logs because some entries may be stale.
|
||||
- May 20-21 validation: sessions 004, 005, 008, and 009 confirmed full validation for several key entry points:
|
||||
- `HybridBloomAccountOpening` (Affiliation-Gated AO Modal): Fully validated in both UIKit host (Session 008) and SwiftUI host (Session 009) with full dismissal/cleanup confirmed. (Requires enabling affiliation flags and manually injecting `affiliation_id` / `branch_affiliation_id` UserDefaults keys in LLDB, then navigating Pre-login -> "Open an account" -> UK Invests -> consent flow).
|
||||
- `HybridBrokerageAccountOpening`: Fully validated on both UIKit and SwiftUI hosts with full lifecycle/dismissal confirmed.
|
||||
- `HybridYouthAccountOpening`: Fully validated on both UIKit and SwiftUI hosts with full lifecycle/dismissal confirmed, resolving the previous dismissal coverage gap.
|
||||
- Remaining validation gaps on the combined PDIAP-12284 / PDIAP-15836 branch include:
|
||||
- `accountlink` (P2P Transfer Flow): UIKit host validation is pending (SwiftUI host and dismissal are validated).
|
||||
- `AODeeplinkLaunchView` (AO Deep-Link with Native/Web Toggle): untested on both branches (Native ON/OFF) and dismissal.
|
||||
- Fid4 surface attribution for launch wrappers and common-launch flows.
|
||||
- Draft PRs were opened for XFlowSDK and XFlowViewMaker on May 20 while validation continues.
|
||||
- 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
|
||||
- The `PDIAP-15765` compatibility fix is now fully closed out and the story is in Done
|
||||
- A new urgent consumer report says REST calls fail on iOS when the toggle is enabled, but current local validation says REST works on both `main` and `release/4.30`; treat version/flag mismatch as the leading explanation until broader evidence says otherwise
|
||||
- David has now confirmed the production build already contains the commit that added the LaunchDarkly flag, so the current investigation should focus more on LaunchDarkly evaluation context, targeting, initialization timing, and any additional transport-selection gating on iOS
|
||||
- Jeff explicitly wants the REST-flag investigation to stay ahead of Adam's separate service-side flow report for now and wants faster visible progress on that path
|
||||
- Jeff suggested broadening the investigation support path while direct Flagship LaunchDarkly access is still missing: monitor the Tauf thread, follow up with Jeffrey O'Leary, package the scenario for the AI tool with build settings and tool details, and ask Aylwing for a quick perspective if available
|
||||
- The Fidelity-side AI tool Jeff referenced for this investigation is GitHub Copilot
|
||||
- Jeff later relayed that Adam says the latest build is now activating REST correctly, so David should switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles
|
||||
- For the upcoming REST-layer validation meeting, David prepared Fid4 `4.32` in a separate folder on the release branch, aligned it with the published/internal build `Podfile.lock` from iOSInstaller, and verified the project builds. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated entry point for quick XFlow validation.
|
||||
- Jeff confirmed May 11 that the REST back end has now been deployed, and a validation meeting is scheduled for May 12 with the team lead and Bruce. They will toggle the REST flag during the meeting and test both states. Jeff asked David to smoke-test Fid4 `4.32` non-REST flows ahead of the meeting.
|
||||
- REST detection for the meeting: use Charles Proxy to check `/xflow/api` endpoints and inspect `mobile.launchdarkly.com` bulk payloads for the raw evaluated flag value.
|
||||
- Production testing: Raj is trying to get approval to test in production, or they may flip the toggle directly in production. A production test account will be needed; currently only Bruce is known to have one. David found a way to force the production environment from the simulator if needed.
|
||||
- May 12 REST validation nuance: pointing Fid4 at production through the plist by itself still showed GraphQL, but the fuller meeting result was successful iOS REST validation after Raj enabled the production LaunchDarkly toggle with specific targeting for the production test user's context, specifically the MID for the account tested with Bruce. The accurate framing is not simply "production still used GraphQL"; the key difference was production LD targeting for the specific user context.
|
||||
- Jeff confirmed the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) is in scope for the current `PDIAP-12284` / `PDIAP-15836` branch and asked David to implement it there.
|
||||
- `PDIAP-15838` draft PR has reached external review; Bruce left minor feedback, David addressed it, and Jeff directed David to move the ticket to Done while holding the merge
|
||||
- Do not merge the GraphQL/Apollo removal PR until REST backend is live in production and the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for at least 30 days without issues
|
||||
- Current `PDIAP-15838` follow-up centers on the `PicoSDK` update in `SampleApp`: the newer Pico path removes the remaining transitive Apollo dependency, re-enables FGO and FidFolios testing in `SampleApp`, and aligns the sample implementation with current Fid4 usage
|
||||
- The `PicoSDK` update affects `SampleApp`, not the `XFlowSDK` production runtime directly
|
||||
- The new Discourse / FTTransfer AccountLink issue is under investigation; Zachary believes it may come from XFlow, but current evidence shows it reproduces in `FTTransferPlayground` with Zachary's account and does not reproduce in `Fid4` with the same account
|
||||
- Current Discourse / FTTransfer findings point to the `BankInformationView` path rather than XFlow directly: XFlow appears to finish before `BankInformationView` takes over, and the web-view reload looks like a SwiftUI recomposition/state issue in the playground path
|
||||
- Continue the Discourse / FTTransfer investigation to verify root cause and any remaining relationship to XFlowViewMaker before assigning ownership or creating a story
|
||||
- Jeff asked David to try to resolve the Discourse consumer issue by end of day on April 30 if possible
|
||||
- Deeper Discourse / FTTransfer analysis now points to presentation-layer SwiftUI identity/lifecycle churn around `BankInformationView` and `BankSetupWebView`: XFlow eventing appears to set shared consumer-observed state, but current evidence does not show it directly mutating view identity, host lifecycle, or alert state.
|
||||
- The working non-XFlow route appears to avoid the issue because it bypasses the extra XFlow destination presentation layer and associated state-coupling surface, while the failing playground path keeps the alert/popup transition and cover lifecycle coupled in the same reactive chain.
|
||||
- The next implementation direction for the Discourse / FTTransfer issue is a pure SwiftUI fix that decouples alert state from the cover identity chain, avoiding unnecessary UIKit dependencies
|
||||
- `PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation` was created for the FTTransfer AccountLink investigation and root-cause report
|
||||
- Include in the `PDIAP-16167` report that the issue persists when rolling back `XFlowSDK` to `v0.1.0`, predating REST and modern architecture changes; Jeff explicitly asked David to include this in the document
|
||||
- `PDIAP-16167` is Done: the Confluence report was published, findings were sent to Zachary / Jira / Discourse, and future references should describe the root cause as a consumer-side SwiftUI presentation-topology issue in `BankInformationView`, not an XFlow/XFlowViewMaker regression
|
||||
- `PDIAP-12284` is the original UIKit-wrapping removal story reopened after rollback; track `PDIAP-15836` as blocked by `PDIAP-12284` unless further validation proves the lifecycle fix can be implemented independently on the SwiftUI path
|
||||
- After `PDIAP-15836` / `PDIAP-12284` implementation, expect a long-lived branch: Jeff's current planning assumption is that the GraphQL-removal branch merges first after the REST validation period, then that is merged into the UIKit-removal/lifecycle branch, with `PDIAP-15836` / `PDIAP-12284` merge around 90-100 days from 2026-05-05 unless Fidelity shortens the review periods
|
||||
- Backlog triage found future/reference items: `PDIAP-11962` has earlier secret-scanning closure evidence but two Google API Key alerts remain; `PDIAP-11961` is the related unassigned rotation/invalidation story for those alerts; `PDIAP-11562` concerns XFlow podspec/Fid4 debug-build configuration; Sparta items `PDIAP-12226`, `PDIAP-12227`, and `PDIAP-12228` are lower-priority until XFlow backlog items that can be closed are handled
|
||||
- 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
|
||||
- Current LaunchDarkly access does not include Flagship LD projects; only the sample app LD project is available from David's side
|
||||
- David does not yet know where the iOS app assembles or identifies the LaunchDarkly context attributes, but can inspect source code and use Charles Proxy during investigation
|
||||
- Current local evidence shows the LaunchDarkly boolean evaluating to `true`, with payload and context present from the iOS side, so the remaining uncertainty is around production-side context interpretation, timing, caching, or additional downstream gating
|
||||
- The urgent REST-activation investigation is no longer the immediate blocker after Adam reported the latest build working, but the earlier context/timing uncertainty remains useful background if the issue reappears
|
||||
- Adam reported the earlier REST activation problem, and he or his team validate behavior on real devices rather than simulator-only paths
|
||||
- Avoid treating GitHub Copilot or LaunchDarkly as story-specific tools; both are broader Fidelity workflow tools that happened to matter in this investigation
|
||||
- Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
|
||||
- Current Fid4 validation logs include duplicate Objective-C class warnings for `Secure` / `DeviceRisk` symbols loaded from both `SecureDocV.framework` and `Fid4.debug.dylib`; treat this as environment/integration noise unless runtime behavior points to a validation blocker, and redact raw device-token prints before sharing logs.
|
||||
- Keep Apollo-removal / REST-migration cleanup grounded in production readiness: source-level cleanup can continue, but merge/release timing depends on the prior REST-toggle implementation being QA-tested and stable in production for the agreed window
|
||||
- Keep the GraphQL/Apollo removal branch and the future `PDIAP-15836` / `PDIAP-12284` branch current with `main`; if conflict resolution looks non-trivial, flag it so a 1-2 point branch-maintenance story can be created
|
||||
- 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
|
||||
- Remaining Google API Key alerts should not be framed as newly introduced REST-story secrets unless evidence changes; current evidence ties them to older April 18, 2025 work and a separate backend/rotation support path
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience
|
||||
- For standups that may also be sent to Teams, keep the update concise, omit internal review-feedback details, and avoid phrasing like `confirmed` when the audience lacks the internal context for what was confirmed
|
||||
- When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone
|
||||
- Standups should omit side questions or manager-only context refreshes unless they materially changed story work
|
||||
- For `PDIAP-16167` standups after May 1, do not report story creation as previous-day work unless the previous-workday evidence explicitly says the story was created that day; focus on report publication, findings shared, closure, or remaining follow-up instead
|
||||
- For `PDIAP-15838` standups, focus on Apollo-removal progress and the `PicoSDK` transitive dependency work; omit extra exploratory asks unless they directly changed the story outcome or created a blocker
|
||||
- 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
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
type: current-work-items
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-05-14
|
||||
tags:
|
||||
- current-work
|
||||
- work-item
|
||||
- fidelity
|
||||
---
|
||||
# Active Work Items
|
||||
|
||||
Use this file as the quick summary for active Jira-linked work.
|
||||
|
||||
Detailed ticket memory now lives under `workspaces/fidelity/project-knowledge/02-work-items/`.
|
||||
|
||||
Update the per-ticket files first when scope, status, sequencing, or communication framing changes materially.
|
||||
|
||||
## Current
|
||||
|
||||
- `PDIAP-15838` - Remove Apollo for iOS
|
||||
Detail: `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15838.md`
|
||||
Current note: ticket moved to Done after external review feedback was addressed, but the draft PR stays unmerged. Keep the branch up to date with `main` until REST backend is live in production and REST toggles have been enabled for consumers for the required validation window; expected merge timing is at least 30 days out. May 13 follow-up validation succeeded on iOS after Raj enabled the production LaunchDarkly toggle for the specific production test user's MID.
|
||||
|
||||
- `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
|
||||
Detail: `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15836.md`
|
||||
Current note: moved to In Progress on May 7. David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, but Jeff directed David to do the dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch because both changes require consumer testing. A May 11 simulator log review suggests the tested SwiftUI-host path fires delegate/session-clear callbacks only after host-disappearance confirmation, but broader branch and consumer validation are still needed.
|
||||
|
||||
- `PDIAP-12284` - Remove UIKit wrapping from XFlow
|
||||
Detail: `workspaces/fidelity/project-knowledge/02-work-items/pdiap-12284.md`
|
||||
Current note: moved to In Progress on May 12 and should be handled with `PDIAP-15836` in the same branch. Quy confirmed both stories can remain In Progress together, so no immediate Jira restructuring is required. Current implementation direction is to avoid Fid4 per-flow host-mode mapping and instead evaluate XFlowViewMaker-owned global host-mode resolution, with SwiftUI as default and `UIHostingController` only as an explicit temporary fallback. May 12 implementation pass resolved earlier shape concerns with neutral enum names, `iOS-XflowUIKitHostEnabled`, SwiftUI default semantics, and `AnyView` removed from builder internals. Fid4 now compiles after manual dependency/build handling. May 13 AccountLink runtime validation looks good for both SwiftUI-default and forced UIKit-host paths. May 14 SampleApp work added explicit UIKit-host vs SwiftUI-host validation paths. May 20-21 status: sessions 004, 005, 008, and 009 confirmed full validation for HybridBloomAccountOpening (both hosts, full lifecycle/dismissal confirmed), HybridBrokerageAccountOpening (both hosts, full lifecycle confirmed), and HybridYouthAccountOpening (both hosts, full lifecycle/dismissal confirmed, resolving the dismissal gap). Remaining gaps are accountlink UIKit host, AODeeplinkLaunchView (both toggle branches and dismissal), and launch wrappers/common-launch flows. Draft PRs were opened for XFlowSDK and XFlowViewMaker on May 20 while validation continues.
|
||||
|
||||
## Backlog / Future Reference
|
||||
|
||||
- `PDIAP-11962` - Closure of secret scanning alerts
|
||||
Detail: `workspaces/fidelity/project-knowledge/02-work-items/pdiap-11962.md`
|
||||
Current note: prior closure was submitted on October 9, 2025 and Matthew closed earlier alerts/story on March 5, 2026. Two Google API Key alerts remain open and appear tied to old April 18, 2025 work, not the current REST story.
|
||||
|
||||
- `PDIAP-11961` - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation
|
||||
Detail: `workspaces/fidelity/project-knowledge/02-work-items/pdiap-11961.md`
|
||||
Current note: related unassigned story for remaining Google API Key alerts; not a current priority but should be preserved for future planning.
|
||||
|
||||
- `PDIAP-11562` - Investigate if XFlow is being built as debug
|
||||
Detail: `workspaces/fidelity/project-knowledge/02-work-items/pdiap-11562.md`
|
||||
Current note: likely tied to the `XFlowSDK_Debug` variable check in the XFlow podspec and Fid4 consumption, not Sparta-team work; historical Slack suggests Jenkins may build the xcframework path while local development consumes XFlow as a normal library, but this needs current validation.
|
||||
|
||||
- `PDIAP-12226`, `PDIAP-12227`, `PDIAP-12228` - Sparta backlog items
|
||||
Details: `workspaces/fidelity/project-knowledge/02-work-items/pdiap-12226.md`, `workspaces/fidelity/project-knowledge/02-work-items/pdiap-12227.md`, `workspaces/fidelity/project-knowledge/02-work-items/pdiap-12228.md`
|
||||
Current note: Slack history ties these to the SpartaSDK follow-up split from initialization/JSON decoding, grid rendering/core components, and interactive/lifecycle behavior. Decoding and rendering are partially complete; interactive components remain blocked by unresolved mobile JavaScript execution.
|
||||
|
||||
## Recently Completed
|
||||
|
||||
- `PDIAP-16167` - AccountLink - XFlow causing web view rewrites investigation
|
||||
Detail: `workspaces/fidelity/project-knowledge/02-work-items/pdiap-16167.md`
|
||||
Current note: moved to Done after publishing the Confluence report and sending the findings to Zachary / Jira / Discourse. Future references should frame this as a consumer-side SwiftUI presentation-topology issue, not an XFlow/XFlowViewMaker regression.
|
||||
@@ -0,0 +1,31 @@
|
||||
- Experiment-driven investigation
|
||||
- Debug print auto added
|
||||
- Iteratively detect now possible debug prints
|
||||
- Structured ticket artifacts with jira, patch, prompts, sessions
|
||||
- Tolerant to pre-experiment fix steps to fix any build error between experiments
|
||||
- Swift skill, specialized to debug prints
|
||||
- Xcode Integration
|
||||
- Xcode logs analysis
|
||||
- Find and read the full Xcode artifacts
|
||||
- Extract relevant logs
|
||||
- Efficient use of xcode commands to build, test, contexted for tuist, cocoapods, sample projects
|
||||
- Execute unit test proficiently, like executing only new tests or related
|
||||
- Auto breakpoint management
|
||||
- UITest integration
|
||||
- IA Investigation
|
||||
- Differences from skills with cli commands vs mcps
|
||||
- Differences of skills vs instructions from vscode copilot
|
||||
- Differences from agents vs skills using agent, what is more general? correct relationship and use
|
||||
- Fidelity
|
||||
- Charles Proxy integration
|
||||
- LaunchDarkly integration
|
||||
- Teams integration
|
||||
- Splunk analyzer
|
||||
- [x] Discourse integration
|
||||
- ServiceNow access
|
||||
- Photo uploader
|
||||
- [x] Multi photos session, copy multiples images in clipboard
|
||||
- [ ] Start as a service
|
||||
- [ ] Auto categorize by context
|
||||
- Swiftlint integration
|
||||
- Auto validator
|
||||
@@ -0,0 +1,25 @@
|
||||
# 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 `workspaces/fidelity/project-knowledge/01-current/work-items.md` as a short bridge summary, not the primary source of detailed ticket context.
|
||||
59
workspaces/fidelity/project-knowledge/02-work-items/index.md
Normal file
59
workspaces/fidelity/project-knowledge/02-work-items/index.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: work-item-index
|
||||
project: fidelity
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- map
|
||||
---
|
||||
# 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-15838.md](./pdiap-15838.md)
|
||||
`PDIAP-15838` ticket is Done, but the draft PR remains unmerged and must be kept current with `main` until REST backend production readiness and the required consumer validation window allow merge.
|
||||
|
||||
- [pdiap-15836.md](./pdiap-15836.md)
|
||||
`PDIAP-15836` approved follow-up story for dismissal delegate lifecycle sequencing in pure SwiftUI; paired with `PDIAP-12284` and should not move to In Progress until the next sprint starts.
|
||||
|
||||
- [pdiap-12284.md](./pdiap-12284.md)
|
||||
`PDIAP-12284` reopened original UIKit-wrapping removal story; current blocker/dependency path for `PDIAP-15836`.
|
||||
|
||||
## Backlog / Future Reference
|
||||
|
||||
- [pdiap-11962.md](./pdiap-11962.md)
|
||||
`PDIAP-11962` closure of secret scanning alerts; prior closure was submitted/closed, but two Google API Key alerts remain.
|
||||
|
||||
- [pdiap-11961.md](./pdiap-11961.md)
|
||||
`PDIAP-11961` related unassigned request for remaining Google API Key rotation/invalidation.
|
||||
|
||||
- [pdiap-11562.md](./pdiap-11562.md)
|
||||
`PDIAP-11562` investigate whether XFlow is being built as debug; historical Slack ties this to the `XFlowSDK_Debug` podspec variable and Fid4/Jenkins consumption.
|
||||
|
||||
- [pdiap-12226.md](./pdiap-12226.md), [pdiap-12227.md](./pdiap-12227.md), [pdiap-12228.md](./pdiap-12228.md)
|
||||
Sparta backlog items split across JSON decoding/initialization, grid rendering/core components, and interactive/lifecycle behavior; decoding/rendering are partially complete and interactive components remain blocked by unresolved mobile JavaScript execution.
|
||||
|
||||
## Recently Completed
|
||||
|
||||
- [pdiap-16167.md](./pdiap-16167.md)
|
||||
`PDIAP-16167` AccountLink investigation completed with Confluence/Jira/Discourse/Zachary follow-up; root cause is a consumer-side SwiftUI presentation-topology issue, not XFlow/XFlowViewMaker.
|
||||
|
||||
- [pdiap-15765.md](./pdiap-15765.md)
|
||||
`PDIAP-15765` authenticated-only DOB issue in `HybridYouthAccountOpening` / `TeenIdentityCheck`; completed while keeping the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of scope.
|
||||
|
||||
- [pdiap-14859.md](./pdiap-14859.md)
|
||||
`PDIAP-14859` spike around final UIKit wrapping removal and rollout planning is done.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-review
|
||||
ticket: PDIAP-11562
|
||||
title: "Investigate if XFlow is being built as debug"
|
||||
systems: [xflowsdk, fid4]
|
||||
workstreams: [dependency-management, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: []
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- build
|
||||
---
|
||||
|
||||
# PDIAP-11562 - Investigate if XFlow is being built as debug
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item under review for possible next work.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- This is related to how the XFlow podspec is configured and how Fid4 consumes it.
|
||||
- It is not currently understood as Sparta-team work.
|
||||
- The concern is whether a debug build configuration or debug-like flag is being used in a dependency-integration context where it should not be.
|
||||
- Next investigation should identify why/how the flag or build configuration is used and whether there is a safer integration approach.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- September 2025 backlog context lists the full title as `Spike: Research/investigate if Xflow is being built as debug in Fid4 and if that’s a concern or intentional.`
|
||||
- November 2025 Slack context says the relevant check is the `XFlowSDK_Debug` variable in the podspec, not a Podfile setting.
|
||||
- David confirmed in November 2025 that the `XFlowSDK_Debug` variable check was still present.
|
||||
- Working interpretation from that thread: Jenkins likely does not set the variable when building the static framework; the `if/else` path may be intended so local development consumes XFlow as a normal library while Jenkins builds/consumes it as an xcframework.
|
||||
- Treat that as a historical hypothesis to verify in current code/build settings, not as a confirmed current production behavior.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog
|
||||
ticket: PDIAP-11961
|
||||
title: "Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation"
|
||||
systems: [xflowsdk]
|
||||
workstreams: [security, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-11962]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- security
|
||||
---
|
||||
|
||||
# PDIAP-11961 - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item; not assigned yet.
|
||||
- Jeff relayed that this is not a priority yet, but asked David to keep the details noted for future reference.
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- Related to the remaining Google API Key alerts not included in the previous `PDIAP-11962` closure.
|
||||
- If key rotation or invalidation is required, David/XFlow likely needs backend support or clarification because Google API Key rotation is not owned directly by the XFlow iOS side.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- October 2025 Slack context describes `PDIAP-11961` as the request for rotation/invalidation of active exposed Google API keys.
|
||||
- The active Google API keys were documented as still valid/in use by the service, so they were intentionally separated from inactive-secret closure evidence.
|
||||
- `PDIAP-11962` was created as the second-phase closure story to run after `PDIAP-11961` invalidation/rotation work completed.
|
||||
- Earlier investigation noted that the API key appeared in a service response and that GitHub was flagging the old commit where the key had been hard-coded and later removed.
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-review
|
||||
ticket: PDIAP-11962
|
||||
title: "Closure of secret scanning alerts"
|
||||
systems: [xflowsdk]
|
||||
workstreams: [security, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-11961]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- security
|
||||
---
|
||||
|
||||
# PDIAP-11962 - Closure of secret scanning alerts
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item under review for future work.
|
||||
- Earlier alert-closure process appears partially completed, but two Google API Key alerts remain open.
|
||||
|
||||
---
|
||||
|
||||
## Current Findings
|
||||
|
||||
- David found an October 9, 2025 email confirming the prior submission.
|
||||
- Follow-up shows Matthew closed the earlier alerts/story on March 5, 2026.
|
||||
- Two Google API Key alerts remain open and were not part of that closure.
|
||||
- Those alerts appear tied to an old `MockPageViewWithHiddenToggle` commit from April 18, 2025, not newly introduced REST-story work.
|
||||
- Google API Key rotation is not owned by David/XFlow directly; backend support or clarification may be needed if rotation/invalidating is required.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- October 2025 Slack context ties this story to `PDIAP-11573 - Remediate secret scanning alerts in XFlow iOS SDK`.
|
||||
- The intended sequence was:
|
||||
1. report inactive secrets through the SSDLC/AAVD process,
|
||||
2. use `PDIAP-11961` to handle invalidation/rotation of still-active Google API keys,
|
||||
3. use `PDIAP-11962` to close the GitHub alerts after `PDIAP-11961` is completed.
|
||||
- Slack context from October 10, 2025 says inactive secrets were reported in `ESWR-35407`, `PDIAP-11961` was created for active-secret invalidation, and `PDIAP-11962` was created to manage alert closure after invalidation.
|
||||
- Slack context from November 19, 2025 says the secret-remediation alerts were still present and none had been marked resolved at that time.
|
||||
- Treat `PDIAP-11962` as the closure/follow-up story, not the rotation/invalidation story itself.
|
||||
|
||||
---
|
||||
|
||||
## Related Work
|
||||
|
||||
- `PDIAP-11961 - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation` is the related story for the remaining Google API Key alerts and is not assigned yet.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-partial
|
||||
ticket: PDIAP-12226
|
||||
title: "iOS: Implement SpartaSDK initialization and JSON decoding"
|
||||
systems: [sparta, xflowsdk]
|
||||
workstreams: [sparta, backlog-triage]
|
||||
people: [jeff-dewitte, aylwing-olivas]
|
||||
related: [pdiap-12227, pdiap-12228]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- sparta
|
||||
---
|
||||
|
||||
# PDIAP-12226 - iOS: Implement SpartaSDK initialization and JSON decoding
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item; partially complete.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- Last known work was a decoding-layer refactor based on internal feedback from Aylwing.
|
||||
- Direction was to make decoding strict so malformed backend responses surface errors to the consumer instead of silently skipping unsupported components.
|
||||
- Earlier approach used a `strict mode` toggle where unsupported components were omitted from rendering.
|
||||
- Refactor is still in progress; if no new component types are added, it may not require much beyond the existing work.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- October 2025 Slack context shows the work started from `PDIAP-11956` / `PDIAP-12066` exploration: dynamic JSON decoding, `SpartaNodeRegistry`, strict-mode behavior, and fallback handling for unknown node types.
|
||||
- By October 21, 2025, decoding tests validated fallback handling and registry lookups in an internal `SwiftUIBuilder` PR.
|
||||
- November 2025 planning split the remaining SpartaSDK work into separate stories; this one became the initialization and JSON-decoding story.
|
||||
- November 20-24, 2025 Slack context says `PDIAP-12226` was moved to a later sprint and David was reviewing whether the current JSON-decoding implementation was ready for a formal PR.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-partial
|
||||
ticket: PDIAP-12227
|
||||
title: "iOS: Render grid-based layout and core visual components"
|
||||
systems: [sparta, xflowsdk]
|
||||
workstreams: [sparta, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-12226, pdiap-12228]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- sparta
|
||||
---
|
||||
|
||||
# PDIAP-12227 - iOS: Render grid-based layout and core visual components
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item; partially complete.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- There is already a working base that places elements on the grid layout.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- October 2025 Slack context shows rendering work began after the decoding spike, with a SwiftUI renderer/protocol path and initial support for titles, buttons, text, and grid-related components.
|
||||
- The Sparta work uses JSON responses with grid-position attributes; Jeff advised avoiding the term `DSL` in user-facing/sample naming unless the team confirms that language.
|
||||
- November 2025 planning split the work so `PDIAP-12227` covered grid-based layout and core visual components.
|
||||
- November 20, 2025 Slack context says Quy wanted `PDIAP-12226` and `PDIAP-12227` placed into the sprint after next at that time, with the option to pull them in earlier if capacity allowed.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-blocked
|
||||
ticket: PDIAP-12228
|
||||
title: "iOS: Implement interactive components and lifecycle behaviors"
|
||||
systems: [sparta, xflowsdk]
|
||||
workstreams: [sparta, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-12226, pdiap-12227]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- sparta
|
||||
---
|
||||
|
||||
# PDIAP-12228 - iOS: Implement interactive components and lifecycle behaviors
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item; blocked or unresolved.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- Covers interactive components such as buttons.
|
||||
- Main unresolved question was how to execute JavaScript on mobile.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- November 2025 planning split the SpartaSDK proof-of-concept follow-up into initialization/decoding, rendering, interactive components/lifecycle, and navigation/flow logic tracks.
|
||||
- Earlier Slack updates show buttons and dropdown rendering were already partially explored under foundational SpartaSDK work, but full interactive behavior and lifecycle/navigation behavior were not complete.
|
||||
- Treat JavaScript execution on mobile as the major unresolved blocker for richer interactive behavior unless current project evidence supersedes it.
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: in-progress
|
||||
ticket: PDIAP-12284
|
||||
title: "Remove UIKit wrapping from XFlow"
|
||||
systems: [xflowsdk, xflowviewmaker]
|
||||
workstreams: [xflow-swiftui-migration, consumer-integration]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-15836, pdiap-15838]
|
||||
updated: 2026-05-14
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- swiftui
|
||||
- xflow
|
||||
---
|
||||
|
||||
# PDIAP-12284 - Remove UIKit wrapping from XFlow
|
||||
|
||||
## Status
|
||||
|
||||
- Reopened after rollback and moved to In Progress on May 12.
|
||||
- Jeff directed David to do this UIKit-removal work and `PDIAP-15836` dismissal/lifecycle work in the same branch because both are disruptive enough to require consumer testing.
|
||||
- Current implementation direction is to avoid Fid4-owned per-flow host-mode mapping and evaluate XFlowViewMaker-owned global host-mode resolution.
|
||||
- David continued the implementation/validation loop on May 11; current simulator log review is promising for the SwiftUI-host dismissal sequencing in the tested run.
|
||||
- Jeff confirmed on May 11 that the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) should be implemented as part of this branch's work.
|
||||
- May 12 implementation pass resolved several earlier concerns: host-mode API appears branch-local/new, enum cases were renamed to neutral `swiftUIHost` / `uiKitHost`, the final flag key is `iOS-XflowUIKitHostEnabled`, missing/false/unavailable flag values default to SwiftUI, and `AnyView` was removed from `buildFlow` internals while remaining only at the existing public `FlowViewMaker` boundary.
|
||||
- Current validation blocker appears to be dependency alignment rather than host-mode code correctness: XFlowViewMaker is resolving `XFlowSDK 2.8.48` from its podspec, which does not expose the new host-mode API needed by the branch.
|
||||
- After manual dependency/build handling, Fid4 now compiles with the latest `FlowViewBuilder` shape. Next validation should be runtime evidence: first verify a representative flow selects the default SwiftUI host path, then simulate/force `iOS-XflowUIKitHostEnabled == true` to verify the temporary UIKit host path and dismissal behavior.
|
||||
- Quy confirmed on May 13 that this story and `PDIAP-15836` can both remain In Progress together, so no immediate Jira restructuring is required.
|
||||
- May 13 AccountLink runtime validation looks good in both host modes. The SwiftUI-default path and forced UIKit-host path selected the expected branch and preserved dismissal sequencing; no AccountLink issue was observed in either mode during these runs.
|
||||
- Before push, cleanup should remove temporary `XFlow-DISMISS-DEBUG` prints and consider moving dismissal-specific helper types out of `XFlowManager.swift` into a dedicated dismissal file.
|
||||
- Follow-up SampleApp validation found a likely host-mode mismatch regression introduced by the branch: `initialViewController(...)` still represents the UIKit presentation path, but manager state could remain on SwiftUI host mode and route `endActivity` through the SwiftUI dismissal subject without an active `XFlowDismissalHost`. The minimal fix should preserve existing behavior by forcing/setting UIKit host mode for `initialViewController(...)` and SwiftUI host mode for `makeInitialFlowView(...)`.
|
||||
- SampleApp should be updated to support explicit validation of both UIKit-host and SwiftUI-host modes. The SDK should choose the appropriate dismissal mechanism from the active integration path, not from stale/default host-mode state.
|
||||
- May 14 SampleApp iteration updated the sample to exercise both host scenarios explicitly: UIKit-host through `initialViewController(...)` and SwiftUI-host through `makeInitialFlowView(...)`, selected by the existing `Use SwiftUI` / feature-toggle path. XFlowSDK entrypoints should prepare their own matching dismissal mechanism so `endActivity` cannot route to the SwiftUI subject unless the SwiftUI host is actually active.
|
||||
- The SampleApp SwiftUI-host rendering was refined to avoid storing `AnyView` in state; SwiftUI-host content now lives behind a `ViewBuilder` / `flowContent` rendering path. This keeps local SampleApp code aligned with the branch goal of avoiding unnecessary `AnyView`, while preserving type erasure only at true public boundaries such as the existing XFlowViewMaker boundary if still required.
|
||||
- Jeff recommended expanding validation before review: test as many current Fid4 XFlow entry and dismissal points as possible in both default SwiftUI-host and forced UIKit-host modes, with particular attention to AO flows. Use the prior Confluence entry-point list as a starting point, but verify it against current code and temporary runtime logs before treating it as complete.
|
||||
- May 20-21 status: validation sessions 004, 005, 008, and 009 confirmed full validation for several key entry points:
|
||||
- `HybridBloomAccountOpening` (Affiliation-Gated AO Modal): Fully validated in both UIKit host (Session 008) and SwiftUI host (Session 009) with full dismissal/cleanup confirmed.
|
||||
- `HybridBrokerageAccountOpening`: Fully validated on both UIKit and SwiftUI hosts with full lifecycle/dismissal confirmed.
|
||||
- `HybridYouthAccountOpening`: Fully validated on both UIKit and SwiftUI hosts with full lifecycle/dismissal confirmed, resolving the previous dismissal coverage gap.
|
||||
- Remaining gaps: `accountlink` UIKit host, `AODeeplinkLaunchView` (both toggle branches and dismissal), and launch wrappers/common-launch flows. Draft PRs were opened for XFlowSDK and XFlowViewMaker on May 20 while validation continues.
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- This is the original story for removing the UIKit wrapping.
|
||||
- Current relationship to track: `PDIAP-12284` should be handled with `PDIAP-15836` in the same implementation branch. David identified a possible minimal `PDIAP-15836` fix path that does not require removing `UIHostingController`, but Jeff prefers combined branch work because both changes require consumer testing.
|
||||
- Desired host-mode model: SwiftUI host is the default, missing or unknown feature configuration should also default to SwiftUI, and `UIHostingController` should remain only as an explicit temporary fallback while consumers validate the migration.
|
||||
- XFlowSDK should not be coupled directly to LaunchDarkly, Flagship, or app-specific feature-flag clients; it should receive an already-resolved host-mode decision.
|
||||
- If `hostMode` must be passed through `FlowConfig` or a similar object, keep it as adapter/internal plumbing rather than a new consumer-facing per-flow responsibility.
|
||||
- The latest tested run reported the expected dismissal order for the SwiftUI-host path, but the branch still needs review of the shared host-mode routing and any required broader validation before story closure.
|
||||
- Resolved implementation-shape decisions from the May 12 pass: keep two host-mode enum types to preserve the boundary where XFlowViewMaker owns host-selection policy and XFlowSDK owns presentation mechanics, keep the single conversion point in `FlowViewBuilder`, use neutral enum names, and keep SwiftUI as default unless `iOS-XflowUIKitHostEnabled` is explicitly true.
|
||||
- SampleApp-specific rendering should not reintroduce `AnyView` just to switch between validation paths. Prefer view-builder composition plus state that represents the selected host path, plugins, and controller.
|
||||
- Fid4 validation for this branch should go beyond AccountLink: inventory current entry points, confirm which older Confluence-listed entries are still valid, and temporarily log entry path, resolved host mode, dismissal mechanism, delegate callbacks, and session cleanup. Remove those logs before PR publication.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- November 21, 2025 Slack context says David created `PDIAP-12284` and `PDIAP-12285` to cover remaining UIKit-removal work inside XFlow after reviewing open Sendable and XFlowViewMaker-track stories.
|
||||
- That same backlog refinement closed out pending XFlowViewMaker stories that were no longer needed.
|
||||
- Current Mattermost context supersedes the old standalone refinement framing: this story is now reopened after rollback and should be handled together with `PDIAP-15836`.
|
||||
|
||||
---
|
||||
|
||||
## Sequencing
|
||||
|
||||
- Work can begin, but merge/release should wait until the REST-transition consumer-validation window has completed.
|
||||
- Keep the implementation branch up to date with `main` while waiting for approval to work with consumers and merge.
|
||||
- Before implementation is treated as settled, confirm through product-code inspection whether XFlowViewMaker can resolve host mode using existing `FeatureEnabling` / `Featuring` abstractions or whether a small dependency-injection path is needed.
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: done
|
||||
ticket: PDIAP-14859
|
||||
title: "Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation"
|
||||
systems: [xflowsdk, xflowviewmaker, fid4, ftframeworks]
|
||||
workstreams: [xflow-swiftui-migration, consumer-integration]
|
||||
people: [jeff-dewitte, quy-mai]
|
||||
related: [pdiap-15836]
|
||||
updated: 2026-04-20
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- xflow
|
||||
- swiftui
|
||||
---
|
||||
# PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation
|
||||
|
||||
## Status
|
||||
|
||||
- Done
|
||||
- Rollout draft prepared and sent to Jeff for review on April 13, 2026
|
||||
- Rollout document was approved, published, and the spike was later moved to Done
|
||||
|
||||
---
|
||||
|
||||
## 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 process-oriented deliverable has been completed and the spike is closed.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: done
|
||||
ticket: PDIAP-15765
|
||||
title: "AO DOB field error not showing investigation"
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4, cogstore]
|
||||
workstreams: [ao-discourse, xflow-debugging, consumer-integration]
|
||||
people: [jeff-dewitte, gurram-santosh, raj-sundararaj]
|
||||
related: [pdiap-15838]
|
||||
updated: 2026-04-20
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- ao
|
||||
- xflow
|
||||
---
|
||||
# PDIAP-15765 - AO DOB field error not showing investigation
|
||||
|
||||
## Status
|
||||
|
||||
- Done
|
||||
- Small XFlowSDK compatibility fix merged and released in XFlow `2.8.48`
|
||||
- XFlowViewMaker was updated to the new XFlow version, approved, and published after the required code-owner approval
|
||||
- The downstream Fid4 update was carried through a consumer PR that was later approved and merged
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
- Later on April 16, the PR received final approval, was merged, and the XFlow release was cut as version `2.8.48`.
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
- The XFlowViewMaker approval and publish step are complete.
|
||||
- The Fid4 dependency conflict was resolved through the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
|
||||
- The podspec-repo PR was sent to Tauf and approved.
|
||||
- After that merge, `pod install --repo-update` in Fid4 worked because the published podspecs no longer restricted the XFlowViewMaker version.
|
||||
- The Fid4 PR with the latest versions was later approved and merged.
|
||||
- Story moved to Done after the downstream release propagation completed.
|
||||
- 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.
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: in-progress
|
||||
ticket: PDIAP-15836
|
||||
title: "Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment"
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks]
|
||||
workstreams: [xflow-swiftui-migration, consumer-integration]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-14859, pdiap-12284, pdiap-15838]
|
||||
updated: 2026-05-14
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- xflow
|
||||
- swiftui
|
||||
---
|
||||
# PDIAP-15836 - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
|
||||
|
||||
## Status
|
||||
|
||||
- Moved to In Progress on May 7.
|
||||
- David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, and was validating it.
|
||||
- Jeff directed David to do this dismissal/lifecycle work together with `PDIAP-12284` in the same branch because both changes are disruptive enough to require consumer testing.
|
||||
- May 11 simulator log review suggests the tested SwiftUI-host path now fires in the intended order: host-disappearance confirmation precedes `fireEndActivityDelegates`, delegate callbacks, and `activitySession` cleanup. Treat this as promising validation evidence for the tested run, not final consumer validation.
|
||||
- May 12 branch validation reported that explicit UIKit host mode still preserves dismissal-completion behavior and delegate callbacks/session cleanup remain after confirmed dismissal. Broader compile validation still depends on resolving the XFlowViewMaker / XFlowSDK dependency mismatch.
|
||||
- May 13 AccountLink runtime validation looks good in both SwiftUI-default and forced UIKit-host modes. Both paths preserved the intended dismissal sequencing, with delegate callbacks and session cleanup after confirmed dismissal.
|
||||
- May 14 SampleApp work refined dismissal validation coverage: SampleApp can exercise both UIKit-host and SwiftUI-host paths, while XFlowSDK entrypoints prepare the matching dismissal mechanism for the active integration path. This supports validating that UIKit dismiss completion and SwiftUI `XFlowDismissalHost` lifecycle sequencing both converge on the canonical delegate/session teardown path.
|
||||
- Jeff recommended broad Fid4 validation before PR review: test as many current XFlow entry and dismissal points as possible in both host modes, especially AO flows, and use temporary logs to confirm the active entry path, host mode, dismissal mechanism, delegate callbacks, and session cleanup.
|
||||
- May 20-21 status: validation sessions 004, 005, 008, and 009 confirmed full validation for several key entry points:
|
||||
- `HybridBloomAccountOpening` (Affiliation-Gated AO Modal): Fully validated in both UIKit host (Session 008) and SwiftUI host (Session 009) with full dismissal/cleanup confirmed.
|
||||
- `HybridBrokerageAccountOpening`: Fully validated on both UIKit and SwiftUI hosts with full lifecycle/dismissal confirmed.
|
||||
- `HybridYouthAccountOpening`: Fully validated on both UIKit and SwiftUI hosts with full lifecycle/dismissal confirmed, resolving the previous dismissal coverage gap.
|
||||
- Remaining gaps: `accountlink` UIKit host, `AODeeplinkLaunchView` (both toggle branches and dismissal), and launch wrappers/common-launch flows. Draft PRs were opened for XFlowSDK and XFlowViewMaker on May 20 while validation continues.
|
||||
- Quy confirmed on May 13 that this story and `PDIAP-12284` can both remain In Progress together, so no immediate Jira restructuring is required.
|
||||
- Sequenced after `PDIAP-15838` source work, but merge/release is delayed until after REST-transition consumer validation
|
||||
- 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.
|
||||
- Preserve a single canonical delegate/session-clear path if possible, and do not treat SwiftUI `onDisappear` as proof of dismissal completion unless simulator logs validate that lifecycle contract.
|
||||
|
||||
---
|
||||
|
||||
## Sequencing And Dependencies
|
||||
|
||||
- This story should come after `PDIAP-15838`.
|
||||
- `PDIAP-12284` is the original UIKit-wrapping removal story and was reopened after rollback.
|
||||
- Current working relationship: implement and validate `PDIAP-15836` together with `PDIAP-12284` in the same branch unless direction changes. David identified a possible isolated/minimal fix path, but Jeff prefers combined branch work because consumer testing is required either way.
|
||||
- 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.
|
||||
- Current combined-branch planning should keep dismissal sequencing host-agnostic: the SwiftUI host path must prove dismissal completion before delegate callbacks, while the temporary `UIHostingController` fallback should preserve legacy dismiss-completion behavior.
|
||||
- Current validation logs did not show the key failure patterns for the tested run, such as delegate firing before host-disappearance confirmation or repeated host-disappearance confirmation for the same dismissal id.
|
||||
- SampleApp should be used as a guardrail for stale host-mode state by running UIKit-host and SwiftUI-host flows back-to-back without restarting the app.
|
||||
- Fid4 validation should also use the previous Confluence entry-point list as a starting point, but current source inspection/logging should decide which entries are still valid, renamed, removed, or replaced.
|
||||
- Expect a long-lived branch: after implementation, maintain the branch until consumer-testing approval. Jeff expects the GraphQL-removal branch to merge first after the REST validation period, then that branch should be merged into the `PDIAP-15836` / `PDIAP-12284` branch. Current estimate is roughly 90-100 days from 2026-05-05 unless Fidelity shortens the review windows.
|
||||
|
||||
---
|
||||
|
||||
## 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`.
|
||||
- The Confluence/root-cause document was updated to reflect that FTTransfer changes are not the primary need anymore.
|
||||
- The primary recommendation is to adjust the dismissal handling/sequencing correctly in the hosting path.
|
||||
- FTTransfer improvements can still be mentioned as a secondary improvement, but not as a required change to reproduce the same visual behavior.
|
||||
- When explaining why code still remains, clarify that the spike identified and documented the root cause, but implementation changes have not yet been published.
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: done-pending-merge
|
||||
ticket: PDIAP-15838
|
||||
title: "Remove Apollo for iOS"
|
||||
systems: [xflowsdk]
|
||||
workstreams: [rest-migration]
|
||||
people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
|
||||
related: [launchdarkly, github-copilot]
|
||||
updated: 2026-05-13
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- rest
|
||||
- graphql
|
||||
---
|
||||
# PDIAP-15838 - Remove Apollo for iOS
|
||||
|
||||
## Status
|
||||
|
||||
- Ticket moved to Done after external review feedback was addressed
|
||||
- Draft PR remains unmerged and must be kept up to date with `main`
|
||||
- PR merge should wait until REST backend is live in production and the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for at least 30 days without issues
|
||||
- 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.
|
||||
- Keep the REST-activation investigation context as useful background, but focus current updates on Apollo-removal cleanup, validation, and merge sequencing.
|
||||
- For standups and concise status updates, center the story on Apollo-removal progress and the `PicoSDK` transitive dependency path; omit extra exploratory asks unless they directly affect the story outcome or create a blocker.
|
||||
- Jeff confirmed this investigation should stay ahead of Adam's separate service-side flow report for now and asked for faster progress.
|
||||
- Current local evidence shows the LaunchDarkly boolean evaluating to `true`, with payload and context present from the iOS side; remaining uncertainty is around production-side context interpretation, timing/caching, or downstream transport gating.
|
||||
- Use the current support path while direct Flagship LaunchDarkly access is missing: monitor the Tauf thread, follow the outreach path to Jeffrey O'Leary, package the scenario for GitHub Copilot with build settings and tool details, and ask Aylwing for a quick perspective if available.
|
||||
- Adam later reported that the latest build is activating REST correctly, so the story context returned to the planned GraphQL-removal and related LaunchDarkly-toggle cleanup work.
|
||||
- Keep the real-device-only scenario in mind as a useful fallback hypothesis if the issue returns: environment-specific differences such as LaunchDarkly context, timing, or cached toggle state may explain behavior that does not reproduce in the simulator.
|
||||
- Adam was the reported source of the REST activation problem, and his side validates behavior on real devices.
|
||||
- Current codebase analysis suggests the main remaining source-level blockers are no longer transport selection but residual Apollo model/runtime coupling: `XFlow.Slot` usage in the page interactor/worker path, `NetworkClient` references still touched by init/session lifecycle, and Apollo/AppSync config surface that may still behave like public API.
|
||||
- Follow-up analysis suggested `XFlow.Slot` might be the only Apollo-generated production model still used outside the GraphQL-generated folder, but local trial changes surfaced additional Apollo-dependent models/build errors. Treat the `XFlow.Slot` simplification as a promising first step, not as a fully validated statement about the whole codebase.
|
||||
- The suggested simplification is to remove the current round-trip `stagedValues() -> [String: String] -> XFlow.Slot -> [String: String] -> XFlowUpdateSlotsRequest.slots` and instead pass `[String: String]` straight through to `XFlowUpdateSlotsRequest.slots`, keeping `SlotVariable: Encodable` in the REST model layer for request serialization.
|
||||
- The next AI follow-up should focus only on the first step and ask GitHub Copilot to corroborate residual Apollo-model dependencies by using `xcodebuild` failures, not just static reference search.
|
||||
- Follow-up enum validation indicates at least some Apollo-generated enum types can likely be replaced with native Swift `enum Name: String` definitions without preserving Apollo `EnumType` behavior. For the currently checked production callers, Copilot reported no Apollo-specific enum API dependency for `XFlow.ContentType`, `XFlow.ScreenshotFormat`, and `XFlow.NextTransitionType`; current behavior relies on `rawValue`, equality/switch use, and `init?(rawValue:)`-style parsing.
|
||||
- The currently observed fallback behavior is simple and code-local: unknown `ContentType` values are skipped by converter guards, unknown `ScreenshotFormat` values fall back to PDF in downstream callers, and unknown `NextTransitionType` values currently propagate as `nil` where the target property is optional.
|
||||
- Design direction for the Phase 1 Apollo cleanup: prefer replacing `XFlow.Slot` with a native Swift `Slot` model instead of collapsing it to `[String: String]` through the full production path. Keep `[String: String]` only at the boundary where the REST request/DTO is built in the worker or transport layer.
|
||||
- The current implementation state is cleaner on the model side: Apollo-generated production models have now been replaced with native Swift models/enums for the active path, so the next focus should move from model decoupling to remaining Apollo runtime/infrastructure dependencies.
|
||||
- The `XFlowInitManager` runtime/init cleanup step has now been applied successfully: the three `NetworkClient.shared.updateAppSyncURL(...)` calls were removed from the start/session lifecycle paths, `getAppSyncEndPoint()` was removed after becoming unused, and the project still compiles with `getEndPoint()` left intact for current REST selection.
|
||||
- `NetworkClient.swift` can likely stay temporarily in the tree as a disconnected compatibility shim until broader package/project cleanup, and `XFlowInitManagerConfig.swift` may need to keep AppSync getter/config surface temporarily to avoid an accidental public API break.
|
||||
- Follow-up runtime scan now suggests `GraphQL/NetworkClient.swift` has no live production callers and only self-references remain inside the file. The proposed next removal order is to delete `GraphQL/NetworkClient.swift` first, build/reference-check, then delete `GraphQL/ApolloGeneratedCode`, while keeping the AppSync members in `XFlowInitManagerConfig.swift` temporarily as compatibility-only surface.
|
||||
- Current local state after broader cleanup: runtime Apollo decoupling and most Apollo-specific test cleanup now appear complete, production code compiles cleanly aside from a pre-existing environment issue, and no live Apollo imports/references remain in production code. Remaining work is mainly package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
|
||||
- Current local state now also indicates the test target compiles cleanly after a minimal follow-up update to `XFlowTransportSelectionTests.swift`, preserving REST-relevant transport tests while removing obsolete GraphQL/Apollo assertions. The remaining Apollo-removal work appears concentrated in package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
|
||||
- Latest follow-up says the Apollo package/build cleanup has also now been applied: direct Apollo dependency references were removed from package/build ownership surfaces, leaving the main remaining follow-up as Fid4 validation plus any later decision on whether to deprecate/remove the temporary AppSync compatibility getters in `XFlowInitManagerConfig.swift`.
|
||||
- Apollo source-level cleanup appears sequenced as: replace `XFlow.Slot` with a transport-agnostic model first, decouple `XFlowInitManager` from `NetworkClient` while preserving current REST endpoint behavior, then remove runtime GraphQL code, project wiring, Apollo-only tests/scripts/docs, and finally treat any transitive PicoSDK Apollo dependency as a separate dependency-exit task.
|
||||
- Apollo may still remain in the pod graph transitively through PicoSDK even after source-level cleanup, so "Apollo removed" should be framed carefully unless the dependency graph is also cleared.
|
||||
- Latest local follow-up suggests `SampleApp` depends on `PicoSDK`, and that transitive dependency may still be the practical reason Apollo remains in the pod graph. Newer `PicoSDK` versions no longer depend on Apollo, but the upgrade path does involve real breaking changes. The current investigation is to determine how `SampleApp` can absorb those changes by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it.
|
||||
- Jeff later confirmed that this `PicoSDK` / `SampleApp` cleanup is in scope for `PDIAP-15838` because Apollo needs to be removed from the project, including the transitive sample-app path. Keep the nuance explicit that this update affects `SampleApp`, not the `XFlowSDK` production runtime directly.
|
||||
- David updated `SampleApp` to use the newer `PicoSDK` path, removing Apollo from the transitive sample-app dependency path and re-enabling the FGO and FidFolios flows for testing in `SampleApp`.
|
||||
- The `SampleApp` Pico changes now more closely mirror how Pico is already used in Fid4.
|
||||
- A draft PR has been opened for `PDIAP-15838 - Remove Apollo for iOS`; after internal review, the link should be sent to Bruce.
|
||||
- Internal review found and resolved `PicoSDK` integration concerns: `TransactionContextManager(resolver:)` handles Pico setup internally in `PicoSDK 4.3.18` through lazy resolver-based initialization, the resolver already exists on `XFlowSampleAppViewModel`, and `PicoInterface` was minimally patched so the async completion path avoids a strong `self` capture and returns through `MainActor.run` for UI-state safety.
|
||||
- The REST kill-switch removal is intentional for permanent GraphQL deprecation, but merge timing is gated: the previous REST-toggle implementation should first be QA-tested and active in production with REST enabled for all consumers for 30 days without issues.
|
||||
- Merge sequencing is now explicitly gated by backend production readiness: Bruce reinforced that the GraphQL/Apollo removal PR should not merge until the backend is in production because GraphQL fallback is still needed before then.
|
||||
- Bruce clarified that the current SDK-side updates are not REST behavior changes; the functional REST/backend fix is on the Flagship/Fid4 side, while SDK updates are cleanup, more graceful error handling, logging, and replacing a deprecated logger interface.
|
||||
- Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android; treat this as a validation/build-configuration question until clarified, not as evidence of a known iOS minification issue.
|
||||
- Jeff clarified the validation ask: inspect whether Fid4 has simulator-versus-physical-device or generated-build differences in build settings/schemes/configurations, including any optimized-build-size or release-style settings that could explain behavior seen in generated builds but not when running locally.
|
||||
- Current likely Fid4 build differences to report: Trunk/generated builds use the `Release` configuration while local runs are usually `Debug`; optimization settings such as `SWIFT_OPTIMIZATION_LEVEL` and `GCC_OPTIMIZATION_LEVEL` can differ; Jenkins uses a generated `build-overrides` xcconfig that local builds do not use and may affect values such as secrets; and CocoaPods dependency resolution can vary depending on the local specs repo state.
|
||||
- External review reached Bruce and produced minor feedback. David addressed the feedback and pushed the suggested change.
|
||||
- One accepted review change was to set `responseKey: String? = nil` as the default in `FlowRESTOperationContract`, allowing operations such as `updateSlots`, `storeString`, and `publishEvent` to omit `responseKey` when not needed.
|
||||
- The native Swift domain enum file should remain as the canonical location for XFlow domain enums after removal of GraphQL-generated code.
|
||||
- Jeff directed David to move the ticket to Done, while keeping the PR unmerged for at least 30 days.
|
||||
- Branch maintenance is now part of the work: keep the GraphQL/Apollo-removal branch up to date with `main` until the REST backend/toggle validation window allows merge. If future `main` merges create conflicts that look non-trivial, raise it so a 1-2 point maintenance story can be created.
|
||||
- May 11 preparation for another REST-layer validation meeting: Fid4 `4.32` was checked out in a separate folder, aligned to the published/internal build `Podfile.lock` from iOSInstaller, and built successfully. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated XFlow entry point to use for a quick readiness test.
|
||||
- Jeff confirmed May 11 that the REST back end has now been deployed, and a meeting is scheduled for May 12 with the team lead and Bruce to toggle the flag and test both REST and non-REST states.
|
||||
- REST detection for the meeting: Charles Proxy to verify `/xflow/api` endpoints and inspect `mobile.launchdarkly.com` bulk payloads for the raw evaluated flag value.
|
||||
- Production testing: Raj is trying to get approval to test in production. A production test account will be needed; currently only Bruce is known to have one. David found a way to force the production environment from the simulator if needed.
|
||||
- May 12 REST validation nuance: pointing Fid4 at production through the plist by itself still showed GraphQL, but the fuller meeting result was successful iOS REST validation after Raj enabled the production LaunchDarkly toggle with specific targeting for the production test user's context, specifically the MID for the account tested with Bruce. Treat this as evidence that the production REST path can activate on iOS when the LD targeting context matches.
|
||||
|
||||
---
|
||||
|
||||
## Sequencing
|
||||
|
||||
- This story remains sequenced before `PDIAP-15836`.
|
||||
- This branch should merge to `main` before the future `PDIAP-15836` / `PDIAP-12284` branch is updated and merged.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: done
|
||||
ticket: PDIAP-16167
|
||||
title: AccountLink - XFlow causing web view rewrites investigation
|
||||
systems: [xflowsdk, xflowviewmaker, fttransfer]
|
||||
workstreams: [ao-discourse, consumer-integration]
|
||||
people: [jeff-dewitte, zachary-boutyard]
|
||||
related: [pdiap-15836]
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- discourse
|
||||
- swiftui
|
||||
updated: 2026-05-05
|
||||
---
|
||||
|
||||
# PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation
|
||||
|
||||
## Status
|
||||
|
||||
- Done
|
||||
- Confluence report published
|
||||
- Findings/comment sent to Zachary and posted for Jira/Discourse follow-up
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- Discourse 30181: FTTransfer (Zachary) reported that the AccountLink webview reloads / goes blank when the user taps the exit button in the FTTransfer playground.
|
||||
- Zachary believes the issue is "new" and linked to a recent XFlow version change.
|
||||
|
||||
---
|
||||
|
||||
## Confirmed Findings
|
||||
|
||||
- **Root Cause:** SwiftUI Identity Reset (Modifier-Site Teardown). The `.ftFullScreenCover` modifier was anchored to a volatile branch inside `BankInformationView`. When the webview triggered an exit alert, the environment republish dismantled that volatile branch and rebuilt the presenter off-screen, causing the blank screen.
|
||||
- **XFlow is NOT the cause:** XFlow eventing fires once to toggle a boolean and exits. The teardown happens later on a local JS/alert callback. XFlow does not mutate view identity, host lifecycle, or alert state.
|
||||
- **v0.1.0 Rollback Proof:** The issue persists identically when rolling back XFlowSDK to v0.1.0 (pre-REST, pre-Apollo removal), empirically proving the defect is decoupled from the SDK's recent evolution.
|
||||
- **Comparative Analysis:** The non-XFlow entry point (Zachary's alternative flow) survives because it uses a stable coordinator boundary (`BankSetupContainerView` / `NavigationStack`), bypassing the fragile modifier placement.
|
||||
|
||||
---
|
||||
|
||||
## Verified Resolution
|
||||
|
||||
- Moving the `.ftFullScreenCover` and the `shouldShowWebView` observer to the **stable root** of `BankInformationView` resolves the issue. Pure SwiftUI fix, no UIKit workarounds needed.
|
||||
- Jeff acknowledged the fix and asked to include it in the Confluence report.
|
||||
|
||||
---
|
||||
|
||||
## Current Guidance
|
||||
|
||||
- Keep future references clear that this was documented as a consumer-side SwiftUI presentation-topology defect, not an XFlow/XFlowViewMaker regression.
|
||||
- Include Jeff's preferred clarification that `XFlowSDK v0.1.0` predates the REST and Apollo-related changes that were newer additions.
|
||||
|
||||
---
|
||||
|
||||
## Closure Notes
|
||||
|
||||
- The published recommendation is to move the full-screen cover modifier to the stable root of `BankInformationView`, outside the conditional branch.
|
||||
- David moved the story to Done on 2026-05-05.
|
||||
82
workspaces/fidelity/project-knowledge/03-context/index.md
Normal file
82
workspaces/fidelity/project-knowledge/03-context/index.md
Normal file
@@ -0,0 +1,82 @@
|
||||
---
|
||||
type: context-index
|
||||
project: fidelity
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- context
|
||||
- map
|
||||
---
|
||||
# Context Index
|
||||
|
||||
## Goal
|
||||
|
||||
Keep stable Fidelity context organized by domain so engineers and AI agents 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)
|
||||
- [systems/index.md](./systems/index.md)
|
||||
- [../07-maps/fidelity-apps.md](../07-maps/fidelity-apps.md) for internal Fidelity app/tool navigation
|
||||
|
||||
### `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)
|
||||
- [ios/cocoapods-dependency-management.md](./ios/cocoapods-dependency-management.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/`
|
||||
|
||||
Project-facing rules and expectations for how work should be communicated:
|
||||
|
||||
- [process/communication.md](./process/communication.md)
|
||||
- [process/communication-rules.md](./process/communication-rules.md)
|
||||
- [process/jira-story-rules.md](./process/jira-story-rules.md)
|
||||
- [process/pull-requests.md](./process/pull-requests.md)
|
||||
|
||||
### `people/`
|
||||
|
||||
Named people, role mapping, and collaboration context:
|
||||
|
||||
- [people/index.md](../04-people/index.md)
|
||||
- [people/manager.md](../04-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 PR descriptions.
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
type: guidance
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- ios
|
||||
- cocoapods
|
||||
- dependencies
|
||||
- fidelity
|
||||
---
|
||||
# CocoaPods Dependency Management
|
||||
|
||||
## Goal
|
||||
|
||||
Help the agent reason correctly about CocoaPods behavior, private podspec repos, and release propagation in the Fidelity iOS ecosystem.
|
||||
|
||||
---
|
||||
|
||||
## Why This Matters Here
|
||||
|
||||
- CocoaPods is a core part of how XFlowSDK changes reach XFlowViewMaker, FTFrameworks, and Fid4.
|
||||
- Many apparent SDK or consumer issues are actually dependency-resolution or published-podspec issues.
|
||||
- The workspace should treat CocoaPods knowledge as part of normal investigation and release reasoning, not as an edge case.
|
||||
|
||||
---
|
||||
|
||||
## Fidelity-Specific Context
|
||||
|
||||
- XFlowSDK releases publish artifacts and podspec updates that downstream consumers adopt through CocoaPods.
|
||||
- XFlowViewMaker, FTAccountOpen, FTTransfer, and Fid4 propagation all depend on correct podspec and resolver behavior.
|
||||
- The effective dependency constraint can come from the published podspec repo layer, not only from the source repo that developers inspect first.
|
||||
- Fid4 currently does not keep `Podfile.lock` in Git, which weakens reproducibility and makes published podspec changes more operationally significant.
|
||||
|
||||
---
|
||||
|
||||
## Agent Rules
|
||||
|
||||
- When a newly published dependency does not resolve in Fid4, check CocoaPods resolution before assuming the code change failed.
|
||||
- Distinguish these layers:
|
||||
- source repo podspec or helper code
|
||||
- published private podspec repo
|
||||
- consumer `Podfile`
|
||||
- local/pipeline lockfile state
|
||||
- Do not assume FTFrameworks source tells the whole truth about the active dependency graph.
|
||||
- Treat private podspec repo edits as high-signal release-path behavior that may explain why local or pipeline resolution differs from expectations.
|
||||
- When giving advice, separate:
|
||||
- what fixed the immediate unblock
|
||||
- what is healthy long-term dependency management
|
||||
|
||||
---
|
||||
|
||||
## CocoaPods Best-Practice Anchors
|
||||
|
||||
- CocoaPods podspecs are expected to declare dependency requirements explicitly.
|
||||
- CocoaPods documentation recommends the optimistic operator `~>` because it provides version control without being overly restrictive.
|
||||
- Overly restrictive dependency requirements can block compatibility.
|
||||
- Removing dependency constraints entirely can weaken compatibility guarantees and make transitive resolution less predictable.
|
||||
- `pod install` is the normal command after dependency-definition changes; `pod update` is for intentionally updating pod versions.
|
||||
- `Podfile.lock` is important for reproducible installs and should normally be committed.
|
||||
|
||||
---
|
||||
|
||||
## Current Project Caution
|
||||
|
||||
- In this project, removing the XFlowViewMaker version reference from published `FTAccountOpen` and `FTTransfer` podspecs unblocked Fid4 resolution.
|
||||
- That should be understood as the current operational fix, not automatically as the ideal dependency-management pattern.
|
||||
- Because `Podfile.lock` is not committed in Fid4, broad podspec-repo edits can silently change future resolutions more than they should in a healthier CocoaPods setup.
|
||||
|
||||
---
|
||||
|
||||
## What Good Answers Should Include
|
||||
|
||||
- Whether the issue is in source code, published specs, or consumer resolution
|
||||
- Whether `pod install`, `pod install --repo-update`, or `pod update` is the appropriate command for the stated goal
|
||||
- Whether the current fix improves compatibility or only removes guardrails
|
||||
- Whether the result is reproducible or vulnerable to future resolver drift
|
||||
- Whether the advice is a short-term unblock or a durable recommendation
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
type: guidance
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- ios
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
- CocoaPods, podspec, private specs repo, trunk/CDN, or dependency-resolution behavior
|
||||
- Swift Package Manager migration or package-resolution behavior
|
||||
- CI/build tooling behavior that may depend on current toolchain versions
|
||||
- claims that something is a "bad practice" when the answer depends on ecosystem status, migration cost, or project constraints
|
||||
|
||||
---
|
||||
|
||||
## Technical Verification Rule
|
||||
|
||||
For programming concepts tied to project decisions, the agent should behave like a senior engineer:
|
||||
|
||||
- distinguish stable engineering principles from ecosystem-specific guidance
|
||||
- verify current tool behavior with primary documentation when the topic is version-sensitive
|
||||
- separate general best practice from project-safe recommendation
|
||||
- avoid blanket statements such as "CocoaPods is bad practice" without context
|
||||
- explain tradeoffs: maintenance status, migration cost, consumer integration risk, release propagation, and validation path
|
||||
- suggest workspace improvements when a recurring answer-quality gap appears
|
||||
|
||||
For Fidelity, dependency tooling is project-relevant because XFlowSDK, XFlowViewMaker, FTFrameworks, and Fid4 integration can depend on published versions, podspec repos, release propagation, and consumer validation.
|
||||
|
||||
---
|
||||
|
||||
## 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/`
|
||||
- CocoaPods Build with CocoaPods: `https://guides.cocoapods.org/making/`
|
||||
- CocoaPods Specs and Specs Repo: `https://guides.cocoapods.org/making/specs-and-specs-repo.html`
|
||||
- CocoaPods Private Pods: `https://guides.cocoapods.org/making/private-cocoapods`
|
||||
- CocoaPods trunk read-only plan: `https://blog.cocoapods.org/CocoaPods-Specs-Repo/`
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
type: guidance-index
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- ios
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
|
||||
- [cocoapods-dependency-management.md](./cocoapods-dependency-management.md)
|
||||
CocoaPods, private podspec repo, and dependency-resolution guidance for Fidelity release and consumer integration work.
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
- Use these files before answering Swift, SwiftUI, iOS architecture, testing, concurrency, or debugging questions.
|
||||
- Use the CocoaPods guidance whenever the question touches release propagation, podspecs, dependency conflicts, Fid4 resolution, or FTFrameworks consumer updates.
|
||||
- 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.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: guidance
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- ios
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
- CocoaPods and private podspec-repo behavior are part of the real integration surface, not just build tooling details.
|
||||
- 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.
|
||||
- If the work touches dependency propagation, published specs, or consumer upgrade behavior, explicitly include CocoaPods and podspec-repo reasoning instead of treating them as secondary operational noise.
|
||||
- If the user asks whether CocoaPods, podspec repositories, or dependency propagation is good/bad practice, corroborate with current CocoaPods/Apple/Swift documentation and then adapt the recommendation to Fidelity's release path.
|
||||
- Do not recommend replacing CocoaPods with SPM just because SPM is modern; first identify current integration constraints, private specs usage, release ownership, consumer app expectations, and migration cost.
|
||||
- For manager-ready explanations, connect the technical recommendation to scope, risk, and validation.
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
type: process
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-21
|
||||
tags: [process, communication]
|
||||
---
|
||||
|
||||
# Communication Rules
|
||||
|
||||
## Purpose
|
||||
|
||||
These rules keep standups, Jira notes, and Mattermost messages aligned with the actual state of the work.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- Prefer explicit scope over short vague statements
|
||||
- Always mention auth state when it changes reproducibility
|
||||
- Separate external report from regression
|
||||
- Say whether behavior was confirmed in main when that comparison exists
|
||||
- End with the next action when writing status updates
|
||||
- Distinguish clearly between the current issue, unrelated preexisting bugs, workarounds, and follow-up work
|
||||
- Prefer evidence-backed statements over intuition when communicating status
|
||||
- Include branch, build, environment, account, flow, or entry-point details when they materially affect reproduction or ownership
|
||||
- When reporting several updates for the same Jira item, group them under one top-level `JIRA-ID - Title` bullet with indented markdown sub-bullets
|
||||
- Use real flow identifiers and page names when shorthand could be ambiguous
|
||||
- Prefer `toggle` over `flag` in Fidelity-facing communication, unless naming a specific external tool concept such as LaunchDarkly feature flags
|
||||
- Route ownership explicitly when the issue belongs to a consumer app, service/configuration, or another framework instead of XFlow
|
||||
- Do not present a fix as ready if it introduces a new bug or unresolved regression
|
||||
- Administrative/project-tracking updates should be prompt when others are visibly waiting on them
|
||||
|
||||
## English Quality Rules
|
||||
|
||||
- Write in natural, professional US English that sounds like a fluent engineer wrote it
|
||||
- Prefer direct phrasing over literal or translated-sounding wording
|
||||
- Avoid unnecessary softeners or filler such as "actually," "I think" or "for now" unless they add real scope or uncertainty
|
||||
- If the message was originally rough or written by a non-native speaker, rewrite it fully instead of preserving awkward phrasing
|
||||
- If a sentence can be misunderstood by a manager, stakeholder, or consumer team, rewrite it before sending
|
||||
|
||||
---
|
||||
|
||||
## Repeated Senior Communication Lessons
|
||||
|
||||
- Test in the closest real consumer environment first when consumer-specific behavior is under investigation, but use the sample app to rule ownership in or out quickly
|
||||
- Before escalating or concluding root cause, reduce uncertainty with available evidence: screenshots, videos, logs, code comparison, version checks, and parity checks across web/UIKit/SwiftUI/Fid4
|
||||
- Keep one issue per update unless a second issue is explicitly called out as separate scope
|
||||
- If blocked, communicate what was tried, what was ruled out, and the exact remaining question
|
||||
- Use Context, Observation, Action framing when possible so status is easy to forward without rewriting
|
||||
|
||||
---
|
||||
|
||||
## Avoid
|
||||
|
||||
- "same behavior"
|
||||
- "looks good"
|
||||
- "seems fixed"
|
||||
- "working now"
|
||||
- "it should be fine"
|
||||
- "for some reason"
|
||||
- "I think it's fixed" when evidence exists or is needed
|
||||
|
||||
Use concrete statements instead.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
type: process
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- process
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
- Fidelity Teams consistently displays names in surname-first order.
|
||||
- Mattermost is a separate internal communication context; most people visible in Teams are not the same people David interacts with in Mattermost, with Jeff as the main exception.
|
||||
- Jeff is the main bridge into the Fidelity-side Teams context.
|
||||
- David works on the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side.
|
||||
- Do not write updates as if David is directly embedded in the Fidelity Teams collaboration loop unless the context explicitly says so.
|
||||
- When drafting a message David will send to a Fidelity-side contact, do not phrase it as if Jeff is the sender or as if the recipient already knows David through Jeff unless the user explicitly says that framing is desired.
|
||||
- Avoid wording like `Jeff mentioned...` in David-to-contact drafts when that would incorrectly imply a shared reporting chain or prior relationship.
|
||||
- Keep Jeff's internal process requests separate from David's external message drafts unless the user explicitly wants them surfaced to the recipient.
|
||||
- Do not include lines like `I want to document the steps for future cases` in David-to-contact drafts when that motivation is only internal workspace/process context.
|
||||
- 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.
|
||||
- For Mattermost-ready standups, include a visible blank line before `Today:` and `Blockers:` section headers so copy/paste rendering is correct without manual edits.
|
||||
- When a flow/page shorthand could be ambiguous, prefer the real flow identifier and page name from `workspaces/fidelity/project-knowledge/03-context/workstreams/flow-page-references.md`.
|
||||
- For standups that may also be sent to Teams, prefer plain audience-friendly wording over internal implementation shorthand; avoid terms like `fallback` unless the audience already has the necessary context.
|
||||
- When a release is waiting on approvals or pipeline movement, make the concurrent work explicit so the update does not imply idle waiting.
|
||||
- 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.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
type: process-index
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- process
|
||||
- fidelity
|
||||
---
|
||||
|
||||
# Process Index
|
||||
|
||||
Project-facing process guides for Fidelity work.
|
||||
|
||||
Agent operating rules live in `agent-memory/`, not in this project vault.
|
||||
|
||||
---
|
||||
|
||||
## Guides
|
||||
|
||||
- [communication.md](./communication.md)
|
||||
How to frame technical updates and external communication.
|
||||
|
||||
- [communication-rules.md](./communication-rules.md)
|
||||
Reusable standards for standups, Jira, and stakeholder updates.
|
||||
|
||||
- [jira-story-rules.md](./jira-story-rules.md)
|
||||
How to create or reference stories with the right scope and precision.
|
||||
|
||||
- [pull-requests.md](./pull-requests.md)
|
||||
PR template and framing notes for repositories such as `xflow-for-ios`.
|
||||
|
||||
- [sprint-cadence.md](./sprint-cadence.md)
|
||||
Fidelity-side Scrum cadence, ceremonies, sprint naming, and planning rhythm.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: process
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- process
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
type: process
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- process
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
type: process
|
||||
project: fidelity
|
||||
status: active
|
||||
people: [quy-mai]
|
||||
related: [../process/index.md, ../../04-people/quy-mai.md]
|
||||
updated: 2026-04-20
|
||||
tags:
|
||||
- process
|
||||
- fidelity
|
||||
- scrum
|
||||
- sprint
|
||||
---
|
||||
|
||||
# Sprint Cadence And Ceremonies
|
||||
|
||||
## Goal
|
||||
|
||||
Capture the Fidelity-side Scrum rhythm so work status, planning, and story timing are interpreted correctly.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- On the Fidelity side, Quy Mai acts as the Scrum Master.
|
||||
- Quy manages the Scrum ceremonies.
|
||||
- Confirmed ceremonies include:
|
||||
- retrospective
|
||||
- DSE / daily syncs
|
||||
- sprint review
|
||||
- sprint planning
|
||||
- Retrospectives use Miro.
|
||||
- Jira is the work-tracking system.
|
||||
|
||||
---
|
||||
|
||||
## Sprint Model
|
||||
|
||||
- Sprints are two weeks long.
|
||||
- Sprint naming uses the `PDIAP 26QX.Y` pattern.
|
||||
- The examples currently captured are:
|
||||
- `PDIAP 26Q1.1` (`1/01` - `1/15`)
|
||||
- `PDIAP 26Q1.2` (`1/15` - `1/29`)
|
||||
- `PDIAP 26Q1.3` (`1/29` - `2/12`)
|
||||
- `PDIAP 26Q1.4` (`2/12` - `2/25`)
|
||||
- `PDIAP 26Q1.5` (`2/26` - `3/12`)
|
||||
- `PDIAP 26Q1.6` (`3/12` - `3/26`)
|
||||
- `PDIAP 26Q2.1` (`3/26` - `4/09`)
|
||||
- `PDIAP 26Q2.2` (`4/09` - `4/23`)
|
||||
|
||||
---
|
||||
|
||||
## Working Implications
|
||||
|
||||
- Story timing and status should be interpreted in the context of the current two-week sprint.
|
||||
- Quy is a key contact for ceremony timing, sprint structure, and Jira process expectations on the Fidelity side.
|
||||
- When discussing planning or delivery windows, prefer the explicit sprint label when it is known.
|
||||
|
||||
---
|
||||
|
||||
## Open Question
|
||||
|
||||
- The corrected examples align with the expected quarter-based naming pattern: year + quarter + sprint number within that quarter.
|
||||
72
workspaces/fidelity/project-knowledge/03-context/project.md
Normal file
72
workspaces/fidelity/project-knowledge/03-context/project.md
Normal file
@@ -0,0 +1,72 @@
|
||||
---
|
||||
type: project-context
|
||||
project: fidelity
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- fidelity
|
||||
- context
|
||||
---
|
||||
# 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:
|
||||
- `workspaces/fidelity/project-knowledge/03-context/systems/`
|
||||
- Durable workstreams live under:
|
||||
- `workspaces/fidelity/project-knowledge/03-context/workstreams/`
|
||||
- Project-facing communication and process rules live under:
|
||||
- `workspaces/fidelity/project-knowledge/03-context/process/`
|
||||
- Named people and role mapping live under:
|
||||
- `workspaces/fidelity/project-knowledge/04-people/`
|
||||
|
||||
The Slack archive has already been curated into these files so future sessions do not need to rediscover the same patterns from raw history.
|
||||
|
||||
---
|
||||
|
||||
## 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 `workspaces/fidelity/project-knowledge/06-daily/` and `workspaces/fidelity/project-knowledge/01-current/` hold the moving day-to-day view.
|
||||
|
||||
---
|
||||
|
||||
## First Files To Read
|
||||
|
||||
- `workspaces/fidelity/project-knowledge/03-context/index.md`
|
||||
- `workspaces/fidelity/project-knowledge/03-context/workstreams/index.md`
|
||||
- `workspaces/fidelity/project-knowledge/03-context/process/communication.md`
|
||||
- `workspaces/fidelity/project-knowledge/04-people/index.md`
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- ALMx Toolbox
|
||||
- ALMx - Toolbox
|
||||
---
|
||||
|
||||
# ALMx Toolbox
|
||||
|
||||
## Role
|
||||
|
||||
- Internal tool from the Fidelity app/bookmark set, likely tied to ALM/process workflows.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Base note only; add confirmed responsibilities and common tasks gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- The name suggests process tooling, but exact ownership and usage are still unknown.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `trackit.md`
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems:
|
||||
- xflowsdk
|
||||
- xflowviewmaker
|
||||
- fid4
|
||||
workstreams:
|
||||
- consumer-integration
|
||||
people: []
|
||||
related:
|
||||
- consumer-integration
|
||||
- xflowsdk
|
||||
- xflowviewmaker
|
||||
- fid4
|
||||
- iosinstaller
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- artifactory.fmr.com
|
||||
---
|
||||
|
||||
# Artifactory
|
||||
|
||||
## Role
|
||||
|
||||
- Internal artifact distribution system used in the Fidelity release path.
|
||||
- Known to be part of XFlowSDK/XFlowViewMaker publication and consumer-build inspection workflows.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Stores or exposes build artifacts that help verify what was published or shipped.
|
||||
- This is a base note; add repository names, navigation tips, and common artifact paths gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Artifact presence alone does not prove downstream consumer adoption.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `xflowsdk.md`
|
||||
- `xflowviewmaker.md`
|
||||
- `fid4.md`
|
||||
- `iosinstaller.md`
|
||||
- `../workstreams/consumer-integration.md`
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams:
|
||||
- ao-discourse
|
||||
- xflow-debugging
|
||||
related:
|
||||
- xflowsdk
|
||||
- fid4
|
||||
- pdiap-15765
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
aliases:
|
||||
- CogStore
|
||||
- XFlow Home CCP CogStore
|
||||
---
|
||||
# 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.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: [consumer-integration]
|
||||
people: []
|
||||
related: [jira]
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Confluence
|
||||
|
||||
## Role
|
||||
|
||||
- Internal documentation/wiki surface used across Fidelity workflows.
|
||||
- Commonly paired with Jira in the Fidelity-side delivery process, but Jira is the more central day-to-day work-tracking tool.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Likely useful for process docs, onboarding docs, and cross-team references.
|
||||
- Base note only; add important spaces/pages gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Documentation can drift from current implementation reality.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `../workstreams/consumer-integration.md`
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [fid4, xflowsdk]
|
||||
workstreams: [ao-discourse]
|
||||
people: []
|
||||
related: [ao-discourse, fid4, xflowsdk]
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
---
|
||||
|
||||
# Discourse
|
||||
|
||||
## Role
|
||||
|
||||
- External issue/reporting surface that appears in Fidelity debugging and communication workflows.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Often paired with Jira comments and follow-up communication when clarifying issue scope.
|
||||
- Base note only; add exact ownership boundaries and triage patterns gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- External reports can be incomplete, non-reproducible, or not true regressions.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `../workstreams/ao-discourse.md`
|
||||
- `fid4.md`
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [consumer-integration, xflow-debugging, ao-discourse, xflow-swiftui-migration]
|
||||
related: [xflowsdk, xflowviewmaker, ftframeworks, cogstore, consumer-integration]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
- Fid4 currently consumes XFlow through XFlowViewMaker rather than depending on XFlowSDK directly.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
- Fid4 currently adopts XFlow changes through the app repo `ap010981-ios-flagship-app` after XFlowViewMaker has been published.
|
||||
- Fidelity uses internal build-distribution tooling such as `iosinstaller` to inspect shipped consumer builds.
|
||||
- `iosinstaller` can provide App Store and internal build downloads and expose the build's `Podfile.lock`, which makes it a useful validation source when the repo itself does not track that lockfile.
|
||||
- The common update path is:
|
||||
- modify the Podfile to the new XFlowViewMaker version
|
||||
- run `tuist generate -n`
|
||||
- run `pod install --repo-update`
|
||||
- open and merge a PR
|
||||
- wait for the consumer team to carry the change forward in their normal App Store release flow
|
||||
- `Podfile.lock` is currently ignored in the Fid4 repo, so version verification often depends on Podfile references or published pipeline artifacts instead of Git-tracked lockfiles.
|
||||
- A useful app-store validation path is the Flagship app pipeline artifacts: `appstore/DistributionSummary.plist` records the framework versions installed in that build and can be used to confirm which XFlowViewMaker and XFlow versions were actually shipped.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
---
|
||||
|
||||
# Fidelity Central
|
||||
|
||||
## Role
|
||||
|
||||
- Internal Fidelity portal or central navigation surface.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Likely acts as an entry point to other internal systems or reference material.
|
||||
- Base note only; add high-value navigation paths gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Portal names can hide multiple unrelated functions behind one entry point.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `myaccess.md`
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [consumer-integration, xflow-swiftui-migration]
|
||||
related: [fid4, xflowsdk, xflowviewmaker, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
- `FTAccountOpen` and `FTTransfer` consume XFlow through XFlowViewMaker rather than directly from XFlowSDK.
|
||||
- For Account Opening flows, the current path is understood to go through `FTAccountOpen`.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
- FTFrameworks code-owner approval can also be a practical gate when the XFlowViewMaker update PR lives inside the shared `PR100660-ios-frameworks` monorepo.
|
||||
- In the current XFlowViewMaker propagation pattern, effective downstream constraints may be enforced in the podspec repo rather than the FTFrameworks source repo itself.
|
||||
- A successful Fid4 upgrade required removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs in the podspec repo, then rerunning `pod install --repo-update`.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: [jeff-dewitte]
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-20
|
||||
---
|
||||
|
||||
# GitHub Copilot
|
||||
|
||||
## Role
|
||||
|
||||
- GitHub Copilot is a broadly used AI tool in the Fidelity workflow, especially when product-side code access and richer implementation context are available on the Fidelity machine.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Use this tool when the local Fidelity-side product context is richer than what can be summarized indirectly in chat.
|
||||
- It is useful for investigation, code-oriented debugging, and implementation support when David can provide concrete build, file, and runtime details from the Fidelity development environment.
|
||||
- Tool output should still be checked against local evidence, reproduction results, and confirmed project context.
|
||||
|
||||
---
|
||||
|
||||
## Current Example
|
||||
|
||||
- During the April 20, 2026 REST / LaunchDarkly investigation, Jeff specifically suggested using GitHub Copilot with more detailed local context from David's side.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Do not assume the tool output is authoritative without checking it against local evidence.
|
||||
- Keep the tool's Fidelity-side access level and data visibility labeled as contextual rather than assumed workspace-wide.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `workspaces/fidelity/project-knowledge/04-people/jeff-dewitte.md`
|
||||
- `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15838.md`
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
type: system-index
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-20
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
---
|
||||
# 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](./cogstore.md)
|
||||
Flow-configuration publishing and version-comparison platform used to verify what is live in QA/Production.
|
||||
|
||||
---
|
||||
|
||||
## Internal Apps And Tools
|
||||
|
||||
- [iosinstaller.md](./iosinstaller.md)
|
||||
Internal build-inspection app that can expose App Store/internal builds and their `Podfile.lock`.
|
||||
|
||||
- [artifactory.md](./artifactory.md)
|
||||
Artifact distribution surface used in release and build-validation workflows.
|
||||
|
||||
- [splunk.md](./splunk.md)
|
||||
Internal logging/observability tool for debugging distributed behavior.
|
||||
|
||||
- [discourse.md](./discourse.md)
|
||||
External issue/reporting surface that often feeds Fidelity triage and communication.
|
||||
|
||||
- [confluence.md](./confluence.md)
|
||||
Internal documentation/wiki surface.
|
||||
|
||||
- [jira.md](./jira.md)
|
||||
Primary work-tracking system for stories, sprint state, and planning.
|
||||
|
||||
- [miro.md](./miro.md)
|
||||
Shared whiteboarding/collaboration tool.
|
||||
|
||||
- [myaccess.md](./myaccess.md)
|
||||
Internal access/authentication-related tool.
|
||||
|
||||
- [trackit.md](./trackit.md)
|
||||
Internal tracking tool from the Fidelity toolset.
|
||||
|
||||
- [fidelity-central.md](./fidelity-central.md)
|
||||
Internal portal/entry-point app.
|
||||
|
||||
- [wukong.md](./wukong.md)
|
||||
Internal test-data-related tool.
|
||||
|
||||
- [xq1-portfolio-summary.md](./xq1-portfolio-summary.md)
|
||||
Internal XQ1 environment summary page/tool.
|
||||
|
||||
- [vault.md](./vault.md)
|
||||
Internal Fidelity tool named Vault.
|
||||
|
||||
- [vault-preprod.md](./vault-preprod.md)
|
||||
Pre-production variant of the internal Vault tool.
|
||||
|
||||
- [slate.md](./slate.md)
|
||||
Internal tool from the current Fidelity bookmark/tool set.
|
||||
|
||||
- [almx-toolbox.md](./almx-toolbox.md)
|
||||
Internal ALM/process-related tool.
|
||||
|
||||
- [nexus-fidelity.md](./nexus-fidelity.md)
|
||||
Internal Fidelity tool identified from the current bookmark/tool set.
|
||||
|
||||
- [launchdarkly.md](./launchdarkly.md)
|
||||
Feature-flag platform used broadly across the Fidelity workflow for rollout and environment-controlled behavior.
|
||||
|
||||
- [github-copilot.md](./github-copilot.md)
|
||||
Fidelity-side AI tool used broadly when richer product-side context is available on the development machine.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
- Open `iosinstaller.md`, `artifactory.md`, or the [Fidelity Apps Map](../../07-maps/fidelity-apps.md) when the question is about internal tools, build inspection, or where to look next.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems:
|
||||
- fid4
|
||||
- artifactory
|
||||
workstreams:
|
||||
- consumer-integration
|
||||
people: []
|
||||
related:
|
||||
- consumer-integration
|
||||
- fid4
|
||||
- artifactory
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- Artifactory IOS Build Installer
|
||||
---
|
||||
|
||||
# iOSInstaller
|
||||
|
||||
## Role
|
||||
|
||||
- Internal Fidelity app used to inspect distributed mobile builds.
|
||||
- Current known use: download App Store/internal builds and inspect the build's `Podfile.lock`.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Useful when the repo does not keep `Podfile.lock` in Git but you still need to inspect what dependencies a shipped build used.
|
||||
- Can support version-validation and reproduction work for Fid4 / flagship investigations.
|
||||
- This is a base note; capture exact access patterns, URLs, and screenshots gradually as they become important.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Build snapshots alone may still be insufficient for exact reproduction if the private podspec repo changed after the build was produced.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `fid4.md`
|
||||
- `artifactory.md`
|
||||
- `../workstreams/consumer-integration.md`
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: [consumer-integration]
|
||||
people: [quy-mai]
|
||||
related: [confluence, miro, ../process/jira-story-rules.md, ../process/sprint-cadence.md]
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
- jira
|
||||
- tracking
|
||||
updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Jira
|
||||
|
||||
## Role
|
||||
|
||||
- Primary work-tracking system used in Fidelity.
|
||||
- Central system for stories, sprint organization, status tracking, and planning flow.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Fidelity-side Scrum work is organized in Jira.
|
||||
- Sprint naming uses labels like `PDIAP 26Q1.1`, `PDIAP 26Q2.1`, and `PDIAP 26Q2.2`.
|
||||
- Jira is part of the day-to-day delivery flow alongside DSE/daily syncs, sprint review, sprint planning, and retrospectives.
|
||||
- Story IDs and approved titles should remain explicit because they are reused in standups, planning, and stakeholder communication.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- Sprint cadence and ceremonies: `../process/sprint-cadence.md`
|
||||
- Story framing guidance: `../process/jira-story-rules.md`
|
||||
- Scrum coordination context: `../../04-people/quy-mai.md`
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-20
|
||||
---
|
||||
|
||||
# LaunchDarkly
|
||||
|
||||
## Role
|
||||
|
||||
- LaunchDarkly is the feature-flag platform used broadly in the Fidelity workflow.
|
||||
- It is part of the normal delivery path for controlled rollout, environment-specific behavior, and gradual activation of changes.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- LaunchDarkly can affect behavior by environment, context, targeting, timing, and cached flag state.
|
||||
- When a bug appears only on certain builds or devices, LaunchDarkly evaluation is a valid investigation path even if local simulator checks look correct.
|
||||
- Missing direct dashboard access does not remove LaunchDarkly from consideration; code-side evidence, payload inspection, and runtime evaluation still matter.
|
||||
|
||||
---
|
||||
|
||||
## Current Example
|
||||
|
||||
- During the April 20, 2026 REST migration investigation, LaunchDarkly was a central part of the debugging path because the behavior differed between local validation and consumer real-device reports.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Do not assume a simulator result fully represents real-device LaunchDarkly behavior.
|
||||
- Do not treat missing direct Flagship dashboard access as proof that LaunchDarkly is not involved; indirect evidence still matters.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15838.md`
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
---
|
||||
|
||||
# Miro
|
||||
|
||||
## Role
|
||||
|
||||
- Shared whiteboarding/collaboration tool.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Useful for diagrams, architecture sketches, or discussion artifacts when they matter to project context.
|
||||
- Base note only; add recurring boards or workflows gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Whiteboards can become stale quickly if not linked back to canonical notes.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `confluence.md`
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- My Access
|
||||
---
|
||||
|
||||
# MyAccess
|
||||
|
||||
## Role
|
||||
|
||||
- Internal access/authentication-related tool.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Likely relevant when environment access or role-based permissions affect day-to-day work.
|
||||
- Base note only; add common use cases gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Access assumptions can become stale as roles/projects change.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `../process/communication.md`
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- "Nexus : Fidelity"
|
||||
- Nexus
|
||||
---
|
||||
|
||||
# Nexus Fidelity
|
||||
|
||||
## Role
|
||||
|
||||
- Internal Fidelity app/tool identified from the current bookmark set.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Base note only; add confirmed purpose and relation to release/build flows gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Do not assume this is the same as other artifact or repository tools without confirmation.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `artifactory.md`
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- "Slate : Cognitive Mini App Designer"
|
||||
---
|
||||
|
||||
# Slate
|
||||
|
||||
## Role
|
||||
|
||||
- Internal tool currently identified from the Fidelity app/bookmark set.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Base note only; add confirmed purpose, ownership, and recurring workflows gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Do not infer too much from name alone.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `miro.md`
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [fid4, xflowsdk]
|
||||
workstreams: [xflow-debugging]
|
||||
people: []
|
||||
related: [xflow-debugging, fid4, xflowsdk]
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
---
|
||||
|
||||
# Splunk
|
||||
|
||||
## Role
|
||||
|
||||
- Internal observability/logging tool used for debugging production-like or distributed behavior.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Likely useful for validation and issue triage when app behavior differs from local expectations.
|
||||
- Base note only; add saved searches, index names, and practical debugging patterns later.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Logs can be misleading without auth-state, environment, and version context.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `../workstreams/xflow-debugging.md`
|
||||
- `fid4.md`
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- Track It
|
||||
---
|
||||
|
||||
# TrackIT
|
||||
|
||||
## Role
|
||||
|
||||
- Internal tracking tool referenced from the Fidelity app/tool set.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Base note only; capture exact purpose and recurring workflows gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Name alone is not enough to infer ownership or authoritative data.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `confluence.md`
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related:
|
||||
- vault
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- Vault preprod
|
||||
---
|
||||
|
||||
# Vault Preprod
|
||||
|
||||
## Role
|
||||
|
||||
- Pre-production variant of the internal Fidelity Vault app/tool.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Keep this separate from production Vault context when documenting behavior.
|
||||
- Base note only; add environment-specific usage gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Easy to mix up with production Vault or with the `workspaces/fidelity/project-knowledge/` documentation directory.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `vault.md`
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
---
|
||||
|
||||
# Vault
|
||||
|
||||
## Role
|
||||
|
||||
- Internal Fidelity app/tool named Vault.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Base note only; this refers to the Fidelity system named Vault, not the `workspaces/fidelity/project-knowledge/` documentation directory.
|
||||
- Add real purpose and usage patterns gradually as they become clear.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Name collision with Obsidian/project-knowledge terminology can cause confusion in notes and communication.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `vault-preprod.md`
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- Wukong3.0
|
||||
- Find test data easier
|
||||
---
|
||||
|
||||
# Wukong
|
||||
|
||||
## Role
|
||||
|
||||
- Internal tool associated with test-data workflows.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Recent bookmark evidence suggests it helps find or generate test data more easily.
|
||||
- Base note only; add exact supported workflows gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Test-data tooling often has environment-specific constraints and policy caveats.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `fid4.md`
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [rest-migration, ao-discourse, xflow-debugging, xflow-swiftui-migration, consumer-integration]
|
||||
related: [fid4, xflowviewmaker, ftframeworks, cogstore, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
- XFlowSDK is developed in the dedicated repository `pr100660-xflow-for-ios`.
|
||||
- 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
|
||||
|
||||
---
|
||||
|
||||
## Release Mechanics
|
||||
|
||||
- XFlowSDK publishing currently uses the Jenkins pipeline `xflow-for-ios-publish`.
|
||||
- The publish flow builds the XCFramework, publishes it to internal Fidelity Artifactory at `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`.
|
||||
- Once published, the new SDK version can be adopted downstream through `pod install` or `pod update`, but consumer validation still depends on XFlowViewMaker and Fid4 propagation.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [consumer-integration, xflow-swiftui-migration]
|
||||
related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-12284]
|
||||
updated: 2026-05-08
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
- XFlowViewMaker currently lives in the monorepo `PR100660-ios-frameworks` under `Adapters/XFlowViewMaker`.
|
||||
|
||||
---
|
||||
|
||||
## Release Mechanics
|
||||
|
||||
- When XFlowSDK releases a new version, XFlowViewMaker usually needs a follow-up dependency bump before Fid4 can consume the change.
|
||||
- The common release flow is:
|
||||
- update the XFlowViewMaker podspec to the new XFlowSDK version
|
||||
- run `tuist generate -n`
|
||||
- run `pod install`
|
||||
- open a PR
|
||||
- wait for required approvals, including protected-branch/code-owner approval when applicable
|
||||
- merge, often through automerge once approvals are complete
|
||||
- let the Jenkins pipeline `publish-XFlowViewMaker` publish the adapter release
|
||||
- `publish-XFlowViewMaker` usually auto-detects the next version and commonly increments the minor version automatically.
|
||||
- The publish flow distributes the new adapter version through Artifactory/podspec channels and updates the XFlowViewMaker version on `main`.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
- Current understanding is that Fid4 does not consume XFlowSDK directly; XFlowViewMaker remains the required integration layer for Fid4 and for other consumers such as `FTAccountOpen` and `FTTransfer`.
|
||||
- Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior.
|
||||
- For the current `PDIAP-12284` / `PDIAP-15836` migration planning, XFlowViewMaker is the preferred candidate owner for global host-mode resolution if product-code inspection confirms it can access the existing feature-flag abstraction cleanly. This avoids Fid4-owned per-flow mapping and keeps XFlowSDK decoupled from app-specific LaunchDarkly/Flagship clients.
|
||||
- The desired host-mode behavior for that migration is SwiftUI host by default, SwiftUI host when feature configuration is missing or unknown, and `UIHostingController` only when an explicit temporary fallback flag requests it.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: []
|
||||
workstreams: []
|
||||
people: []
|
||||
related: []
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
updated: 2026-04-17
|
||||
aliases:
|
||||
- XQ1
|
||||
---
|
||||
|
||||
# XQ1 Portfolio Summary
|
||||
|
||||
## Role
|
||||
|
||||
- Internal Fidelity app/page related to the XQ1 environment.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- Likely useful for environment-level validation or summary checks.
|
||||
- Base note only; add exact role in debugging/release validation gradually.
|
||||
|
||||
---
|
||||
|
||||
## Risks
|
||||
|
||||
- Environment pages can be read as status signals without proving app-level behavior.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `fid4.md`
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk, fid4, cogstore]
|
||||
work-items: [pdiap-15765]
|
||||
related: [xflow-debugging, flow-page-references]
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
---
|
||||
# AO And Discourse Issues
|
||||
|
||||
## Goal
|
||||
|
||||
Handle externally reported issues without misclassifying scope or over-claiming regression.
|
||||
|
||||
---
|
||||
|
||||
## Stable Patterns
|
||||
|
||||
- AO and Discourse reports are often incomplete or partially reproducible.
|
||||
- External reports should be treated as external behavior until verified.
|
||||
- Many issues only reproduce with authenticated users or in consumer-specific contexts.
|
||||
- Some historical reports turned out to be service/configuration issues, environment issues, or existing behavior rather than new regressions.
|
||||
- AO-backed flows still carry older service conventions that can differ from what newer XFlow SwiftUI paths were primarily validated against.
|
||||
- In at least some AO validation cases, iOS expected `validations` while older AO payloads could still send fallback-style keys such as `birthDate`.
|
||||
|
||||
---
|
||||
|
||||
## Investigation Rules
|
||||
|
||||
- Always clarify:
|
||||
- authenticated vs non-authenticated
|
||||
- reproducibility
|
||||
- entry point
|
||||
- whether the issue exists in main
|
||||
- whether the behavior is external, existing, or regression
|
||||
- Do not use vague comparison phrases like "same behavior" without scope.
|
||||
- For AO consumers, check whether the payload shape reflects older AO service conventions before concluding the issue is purely client-side.
|
||||
- If iOS-only behavior appears around validation decoding, compare what AO sends against older fallback handling already present in XFlow, especially when Android appears more permissive.
|
||||
|
||||
---
|
||||
|
||||
## Historical Signals From Slack
|
||||
|
||||
- Historical reports around button visibility, analytics, slot updates, and consumer validation repeatedly required deeper reproduction work before scoping a fix.
|
||||
- Slack history shows multiple examples where the original ticket or report was not enough to define the real root cause.
|
||||
- Jeff clarified on April 15, 2026 that these fallback validation paths exist largely to accommodate AO flows. AO was the earliest service integration, built around older custom backend tooling and harder-to-change payload conventions, while newer consumer services were primarily built through Slate and aligned more naturally with `validations` during the SwiftUI refactor.
|
||||
@@ -0,0 +1,123 @@
|
||||
---
|
||||
type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
|
||||
work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
|
||||
related: [xflow-swiftui-migration, xflow-debugging, xflowsdk, xflowviewmaker, ftframeworks, fid4]
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
|
||||
---
|
||||
|
||||
## Current Release Propagation Model
|
||||
|
||||
- The current release path is usually:
|
||||
- `pr100660-xflow-for-ios` releases XFlowSDK
|
||||
- `PR100660-ios-frameworks/Adapters/XFlowViewMaker` updates to that XFlowSDK version and publishes a new XFlowViewMaker release
|
||||
- `ap010981-ios-flagship-app` updates Fid4 to the new XFlowViewMaker version
|
||||
- downstream consumer release then determines when the change reaches the App Store build
|
||||
- A code fix in XFlowSDK is not ready for **published** Fid4 validation until that full dependency chain has propagated.
|
||||
- However, for **local validation**, developers can bypass the publication chain by modifying the `fid4` Podfile to use local path references for `XFlowSDK` and `XFlowViewMaker`.
|
||||
- In practice, the release effort often includes dependency bump work, PR approvals, protected-branch/code-owner requirements, Jenkins publishing, and local consumer dependency refresh steps.
|
||||
- In the current integration model, Fid4 consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
|
||||
- For current-state reasoning and communication, treat XFlowViewMaker as a required part of the Fid4 propagation path, not as an optional or "usually" present layer.
|
||||
- Other frameworks also consume XFlow through XFlowViewMaker, especially `FTAccountOpen` and `FTTransfer`.
|
||||
- For Account Opening paths, the practical consumer route is currently understood to run through `FTAccountOpen`.
|
||||
|
||||
---
|
||||
|
||||
## Step-By-Step Propagation
|
||||
|
||||
1. Release XFlowSDK from `pr100660-xflow-for-ios`.
|
||||
- Jenkins pipeline: `xflow-for-ios-publish`
|
||||
- Produces the XCFramework artifact
|
||||
- Publishes to internal Fidelity Artifactory at `artifactory.fmr.com`
|
||||
- Publishes the podspec to the dedicated podspec repo `ap010981-ios_podspecs_3x`
|
||||
- After publication, consumers can adopt the new SDK version through CocoaPods
|
||||
2. Update and release XFlowViewMaker from `PR100660-ios-frameworks`.
|
||||
- XFlowViewMaker lives in `Adapters/XFlowViewMaker`
|
||||
- Update the XFlowViewMaker podspec to the new XFlowSDK version
|
||||
- Run `tuist generate -n`
|
||||
- Run `pod install`
|
||||
- Open a PR and get required approvals
|
||||
- Ping code owners when protected-branch approval is the remaining blocker
|
||||
- After merge, the `publish-XFlowViewMaker` Jenkins pipeline publishes the adapter
|
||||
- That pipeline usually auto-detects the next release and commonly auto-increments the minor version, for example `0.5.0` -> `0.6.0`
|
||||
- Publication updates Artifactory/podspec distribution and also updates the XFlowViewMaker version on `main`
|
||||
3. Update Fid4 in `ap010981-ios-flagship-app`.
|
||||
- Modify the Podfile to consume the new XFlowViewMaker version
|
||||
- Run `tuist generate -n`
|
||||
- Run `pod install --repo-update`
|
||||
- Open a PR and get approvals
|
||||
- After merge, the consumer team owns the final application release to the App Store
|
||||
|
||||
---
|
||||
|
||||
## Local Validation Path
|
||||
|
||||
- Testing a change locally in `fid4` does **not** require publishing a new version of `XFlowSDK` or `XFlowViewMaker`.
|
||||
- The local validation path involves:
|
||||
- Modifying the `fid4` (`ap010981-ios-flagship-app`) Podfile.
|
||||
- Adding local path references pointing to the local directories of `XFlowSDK` y `XFlowViewMaker` instead of versioned pods.
|
||||
- Running `pod install` to link the local workspaces.
|
||||
- This allows for rapid iteration and testing of XFlow changes directly within the flagship app context before committing to the full release propagation chain.
|
||||
|
||||
---
|
||||
|
||||
## Investigation Rules
|
||||
|
||||
- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.
|
||||
- When the question is specifically about Account Opening, verify the path through `FTAccountOpen` before assuming a direct Fid4-only dependency view is sufficient.
|
||||
- Separate these failure modes:
|
||||
- SDK bug
|
||||
- adapter/version propagation issue
|
||||
- protected-branch or code-owner approval delay
|
||||
- publish pipeline failure or auto-versioning surprise
|
||||
- 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.
|
||||
- Version verification in Fid4 is not always straightforward because `Podfile.lock` is currently ignored in the app repo.
|
||||
- The fastest reliable signals are:
|
||||
- fixed version references in the Podfile when present
|
||||
- archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
|
||||
- Useful Fidelity-specific sources include `iosinstaller`, which exposes App Store/internal builds plus their `Podfile.lock`, and the Flagship app pipeline artifact `appstore/DistributionSummary.plist`, which records the framework versions included in a shipped build.
|
||||
- Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
|
||||
- When a consumer build must be reproduced exactly from an older dependency snapshot, `Podfile.lock` alone may still be insufficient if the private podspec repo changed afterward; the stronger reproduction path is to align the podspec repo revision too.
|
||||
- A newly published XFlowViewMaker version can still be blocked in Fid4 if downstream podspec constraints in `FTAccountOpen` or `FTTransfer` do not yet accept the new adapter version.
|
||||
- Historical/current evidence suggests Tauf has resolved similar propagation blocks by updating the relevant constraint directly in the podspec repo.
|
||||
- Current evidence suggests the effective constraint may live in the podspec repo layer rather than in the FTFrameworks source repo itself.
|
||||
- For the current XFlowViewMaker propagation issue, the practical fix was made in the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
|
||||
- After that podspec-repo PR was merged, `pod install --repo-update` in Fid4 resolved successfully because those podspecs no longer constrained the XFlowViewMaker version.
|
||||
- `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their checked FTFrameworks source podspec files; the effective resolution is managed through the published podspec layer and `ftAdapter` behavior.
|
||||
- This appears to be a risky workaround rather than a healthy long-term dependency-management pattern.
|
||||
- CocoaPods documentation recommends explicit dependency requirements in podspecs and specifically recommends the optimistic operator `~>` because it gives version control without being overly restrictive.
|
||||
- Removing version constraints entirely from published intermediate podspecs weakens compatibility guarantees, makes transitive resolution less predictable, and increases the chance that consumers pick up unvalidated downstream versions.
|
||||
- That risk is even higher in this workspace because Fid4 does not keep `Podfile.lock` in Git, so published podspec changes can alter future resolutions without a strong repository-level lockfile trail.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk, cogstore]
|
||||
work-items: [pdiap-15765]
|
||||
related: [ao-discourse, xflow-debugging]
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
type: workstream-index
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk]
|
||||
work-items: [pdiap-15838]
|
||||
related: [consumer-integration]
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk, fid4, cogstore, xflowviewmaker, ftframeworks]
|
||||
work-items: [pdiap-15765, pdiap-14859, pdiap-15836]
|
||||
related: [ao-discourse, consumer-integration, flow-page-references]
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
|
||||
work-items: [pdiap-14859, pdiap-15836, pdiap-12284]
|
||||
related: [consumer-integration, xflow-debugging]
|
||||
updated: 2026-05-08
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
- For UIKit-wrapping removal, prefer a host-mode design that keeps SwiftUI as the default and limits `UIHostingController` to an explicit temporary fallback. Missing or unknown rollout configuration should not silently restore the UIKit host.
|
||||
- Keep host-mode ownership at the shared integration layer when possible. A Fid4-only per-flow map is less reusable for XFlow's multiple consumers and creates cleanup work when the fallback is retired.
|
||||
- Dismissal sequencing changes must be validated as lifecycle contracts, not just visual symptom fixes: delegate/session-clear callbacks should fire after confirmed dismissal, and `onDisappear` should not be treated as sufficient proof without simulator-log evidence.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
27
workspaces/fidelity/project-knowledge/04-people/README.md
Normal file
27
workspaces/fidelity/project-knowledge/04-people/README.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
type: people-index
|
||||
project: fidelity
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- people
|
||||
- map
|
||||
---
|
||||
# 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
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: consumer-side validator
|
||||
status: active
|
||||
teams: []
|
||||
topics: [rest-migration, launchdarkly, real-device-validation]
|
||||
related: [pdiap-15838, launchdarkly]
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Adam Abdelhadi
|
||||
|
||||
## Role
|
||||
|
||||
- Adam reported the iOS-side REST activation problem during the current `PDIAP-15838` investigation.
|
||||
- He or his team validate behavior on real devices.
|
||||
|
||||
---
|
||||
|
||||
## Collaboration Pattern
|
||||
|
||||
- Jeff relayed Adam's report that REST was not activating for the affected build and later relayed Adam's update that the latest build was working.
|
||||
- Adam's reports are currently relevant as real-device validation input rather than as direct ownership proof for the root cause.
|
||||
|
||||
---
|
||||
|
||||
## Communication Notes
|
||||
|
||||
- Treat Adam's observations as high-value consumer-side validation, especially when simulator and real-device behavior differ.
|
||||
- If future context clarifies his exact team or ownership boundary, update this file directly.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15838.md`
|
||||
- `workspaces/fidelity/project-knowledge/03-context/systems/launchdarkly.md`
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: active
|
||||
updated: 2026-04-20
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
- Jeff explicitly suggested asking Aylwing for a quick perspective during the April 20, 2026 REST / LaunchDarkly investigation because of his broad cross-project experience
|
||||
- If future context clarifies the formal team or title, update this file directly
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: inactive
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# Derian Cordoba
|
||||
|
||||
## Role
|
||||
|
||||
Historical Fidelity collaborator in project support discussions.
|
||||
|
||||
- No longer works with the current All-Win Software / Mattermost / Slack collaboration group.
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- Treat Derian as historical context, not a current active collaborator
|
||||
- If future context clarifies the formal role or team, update this file directly
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: inactive
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# Erik Reynolds
|
||||
|
||||
## Role
|
||||
|
||||
Historical Fidelity collaborator in XFlow-related discussions.
|
||||
|
||||
- Previously worked for Fidelity but no longer does.
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- Treat Erik as historical Fidelity context, not a current active stakeholder
|
||||
- If future context clarifies the formal role or team, update this file directly
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
70
workspaces/fidelity/project-knowledge/04-people/index.md
Normal file
70
workspaces/fidelity/project-knowledge/04-people/index.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
type: people-index
|
||||
project: fidelity
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- people
|
||||
- map
|
||||
---
|
||||
# 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)
|
||||
Former collaborator in historical Slack threads; primary implementer/investigator across SwiftUI, AO/Fid4 bugs, and release work, but no longer works with the current All-Win Software / Mattermost / Slack group.
|
||||
|
||||
- [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; previously worked for Fidelity but no longer does.
|
||||
|
||||
- [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; no longer works with the current All-Win Software / Mattermost / Slack group.
|
||||
|
||||
- [tauf.md](./tauf.md)
|
||||
Taufiqur Ashrafy, often referred to as Tauf; CI/Jenkins support contact who helps with release-pipeline troubleshooting and related publication issues.
|
||||
|
||||
- [jeffrey-oleary.md](./jeffrey-oleary.md)
|
||||
Fidelity-side support contact that Tauf redirected David to during the April 20, 2026 REST / LaunchDarkly investigation; exact team and ownership still need confirmation.
|
||||
|
||||
- [adam-abdelhadi.md](./adam-abdelhadi.md)
|
||||
Consumer-side validator who reported the REST activation problem during `PDIAP-15838`; he or his team test on real devices.
|
||||
|
||||
## 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
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: manager
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
- Acts as the main communication bridge into the Fidelity-side Teams context while David works from the All-Win Software side
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- Jeff is often the person who reports progress or status into the Fidelity-facing context after David advances the implementation or investigation work
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- When direct access is missing, Jeff may push for progress through adjacent evidence sources and support contacts instead of waiting on missing permissions
|
||||
- Jeff explicitly suggested using the Fidelity-approved AI tool with detailed local context, plus outreach to Aylwing / Tauf / Jeffrey O'Leary, during the April 20, 2026 REST / LaunchDarkly investigation
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: support contact
|
||||
status: active
|
||||
teams: []
|
||||
topics: [rest-migration, launchdarkly, build-debugging]
|
||||
related: [pdiap-15838, github-copilot]
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Jeffrey O'Leary
|
||||
|
||||
## Role
|
||||
|
||||
- Fidelity-side contact that Tauf redirected David to during the April 20, 2026 REST / LaunchDarkly investigation.
|
||||
- Exact team and formal ownership are still unknown.
|
||||
|
||||
---
|
||||
|
||||
## Collaboration Pattern
|
||||
|
||||
- Jeff approved reaching out to Jeffrey after Tauf suggested he might be familiar with this type of issue.
|
||||
- Jeffrey is currently relevant as a possible support contact for build-specific or environment-specific behavior affecting REST activation on iOS.
|
||||
|
||||
---
|
||||
|
||||
## Communication Notes
|
||||
|
||||
- Treat Jeffrey as a suggested escalation/support contact, not yet as a confirmed owner.
|
||||
- If future context clarifies his team, access level, or ownership boundary, update this file directly.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15838.md`
|
||||
- `workspaces/fidelity/project-knowledge/03-context/systems/github-copilot.md`
|
||||
43
workspaces/fidelity/project-knowledge/04-people/manager.md
Normal file
43
workspaces/fidelity/project-knowledge/04-people/manager.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
type: role-map
|
||||
project: fidelity
|
||||
role: manager
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- role
|
||||
- manager
|
||||
- fidelity
|
||||
---
|
||||
# Manager
|
||||
|
||||
## Current Holder
|
||||
|
||||
- Name: Jeff DeWitte
|
||||
- Profile: [jeff-dewitte.md](./jeff-dewitte.md)
|
||||
|
||||
---
|
||||
|
||||
## Role
|
||||
|
||||
Direct supervisor or primary reporting manager for the active project.
|
||||
|
||||
- In practice, Jeff is also the main bridge between David's All-Win Software work and the Fidelity-side reporting context.
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: inactive
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# Norman Arauz
|
||||
|
||||
## Role
|
||||
|
||||
Frequent Fidelity/XFlow engineer collaborator in historical Slack threads.
|
||||
|
||||
- No longer works with the current All-Win Software / Mattermost / Slack collaboration group.
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- Treat Norman as historical context, not a current active collaborator
|
||||
- If later communication clarifies the formal team/title, update this file directly
|
||||
33
workspaces/fidelity/project-knowledge/04-people/quy-mai.md
Normal file
33
workspaces/fidelity/project-knowledge/04-people/quy-mai.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: active
|
||||
updated: 2026-04-20
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
- Manages Fidelity-side Scrum ceremonies including retrospectives, DSE/daily syncs, sprint review, and sprint planning
|
||||
- The Fidelity-side sprint cadence currently appears to be two weeks, with sprint names following examples like `PDIAP 26Q1.1` and `PDIAP 26Q2.1`
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
47
workspaces/fidelity/project-knowledge/04-people/tauf.md
Normal file
47
workspaces/fidelity/project-knowledge/04-people/tauf.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: CI and Jenkins support
|
||||
status: active
|
||||
teams: [ci-cd, ios-frameworks]
|
||||
topics: [jenkins, pipelines, podspec-publication, release-support]
|
||||
related: [consumer-integration, pdiap-15765]
|
||||
aliases: [Taufiqur Ashrafy, Tauf]
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
updated: 2026-04-20
|
||||
---
|
||||
|
||||
# Taufiqur Ashrafy
|
||||
|
||||
## Role
|
||||
|
||||
- CI / Jenkins support contact who helps unblock pipeline and publication issues.
|
||||
|
||||
---
|
||||
|
||||
## Collaboration Pattern
|
||||
|
||||
- David reaches out to Tauf when Jenkins or release-pipeline steps need support, especially around XFlowViewMaker publication or approval/pipeline follow-through.
|
||||
- Tauf has been specifically relevant to the `PDIAP-15765` propagation work because David planned to ping him about the remaining XFlowViewMaker approval path.
|
||||
|
||||
---
|
||||
|
||||
## Communication Notes
|
||||
|
||||
- Useful contact for operational release and pipeline troubleshooting.
|
||||
- David has seen podspec-repo edits happen after publication and specifically called out Tauf as someone involved in CI support around that ecosystem.
|
||||
- Often referred to informally as `Tauf`.
|
||||
- Fidelity Teams may show names in a surname-first style, so this person may appear under a different display order there.
|
||||
- In the current XFlowViewMaker propagation issue, Tauf clarified that the needed fix belongs in the podspec repo rather than FTFrameworks source, and pointed David toward removing the XFlowViewMaker version constraint for `ftaccountopen`.
|
||||
- During the April 20, 2026 REST / LaunchDarkly investigation, Tauf redirected David toward Jeffrey O'Leary as a better contact for that scenario.
|
||||
|
||||
---
|
||||
|
||||
## Related Context
|
||||
|
||||
- `workspaces/fidelity/project-knowledge/03-context/workstreams/consumer-integration.md`
|
||||
- `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15765.md`
|
||||
- `workspaces/fidelity/project-knowledge/02-work-items/pdiap-15838.md`
|
||||
- `workspaces/fidelity/project-knowledge/04-people/jeffrey-oleary.md`
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
type: person
|
||||
project: fidelity
|
||||
role: collaborator
|
||||
status: active
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- person
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
type: decision
|
||||
project: fidelity
|
||||
status: accepted
|
||||
title: "Discourse Issues Handling"
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- decision
|
||||
- fidelity
|
||||
---
|
||||
# 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."
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: decision
|
||||
project: fidelity
|
||||
status: accepted
|
||||
title: "REST vs GraphQL"
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- decision
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
40
workspaces/fidelity/project-knowledge/06-daily/2026-04-08.md
Normal file
40
workspaces/fidelity/project-knowledge/06-daily/2026-04-08.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: daily
|
||||
project: fidelity
|
||||
date: 2026-04-08
|
||||
focus: [ao-discourse]
|
||||
work-items: [pdiap-15765]
|
||||
blockers: []
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- daily
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
65
workspaces/fidelity/project-knowledge/06-daily/2026-04-09.md
Normal file
65
workspaces/fidelity/project-knowledge/06-daily/2026-04-09.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
type: daily
|
||||
project: fidelity
|
||||
date: 2026-04-09
|
||||
focus: [ao-discourse, xflow-swiftui-migration, rest-migration]
|
||||
work-items: [pdiap-15765, pdiap-15836, pdiap-15838]
|
||||
blockers: []
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- daily
|
||||
- fidelity
|
||||
---
|
||||
# 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
|
||||
48
workspaces/fidelity/project-knowledge/06-daily/2026-04-10.md
Normal file
48
workspaces/fidelity/project-knowledge/06-daily/2026-04-10.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
type: daily
|
||||
project: fidelity
|
||||
date: 2026-04-10
|
||||
focus: [xflow-swiftui-migration, rest-migration, ao-discourse]
|
||||
work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
|
||||
blockers: []
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- daily
|
||||
- fidelity
|
||||
---
|
||||
# 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.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user