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:
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.
|
||||
Reference in New Issue
Block a user