Add project-knowledge structure and templates

- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People."
- Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views.
- Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation.
- Updated scripts and prompts to reflect the new project-knowledge directory structure.
- Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps.
- Ensured all references in workflows and scripts point to the new project-knowledge paths.
This commit is contained in:
2026-04-17 15:52:08 -06:00
parent 11fdb17fcb
commit dbc1894e27
175 changed files with 1163 additions and 914 deletions

View File

@@ -0,0 +1,27 @@
---
type: people-index
project: fidelity
updated: 2026-04-16
tags:
- people
- map
---
# People Context
Store reusable human context here.
Use this directory for:
- who is who
- current role ownership
- communication preferences
- recurring stakeholders
- stable relationship between people and project work
Guidelines:
- use one file per named person when that person matters repeatedly
- keep `manager.md` as the role mapping for the current active manager
- keep `index.md` as the quick roster for the active project
- do not put secrets here
- do not invent roles; use qualifiers when uncertain

View File

@@ -0,0 +1,34 @@
---
type: person
project: fidelity
role: collaborator
status: active
updated: 2026-04-16
tags:
- person
- fidelity
---
# Aylwing Olivas
## Role
Repeated Fidelity collaborator visible across multiple historical Slack channels.
---
## Known Context
- Appears in technical discussions about XFlow, SwiftUI limitations, navigation architecture, and dependency risk
- Surfaces cross-team constraints such as security or token access issues affecting pipeline work
- Frequently adds architectural framing rather than only status updates
- Often reframes implementation problems at the architecture/system-design level rather than the ticket level
- Repeatedly advised on state machines, navigation architecture, off-screen rendering, and long-term maintainability tradeoffs
- Common escalation point when the team needs a technical sounding board or higher-level design critique
---
## Guidance
- Treat Aylwing as a useful source for higher-level technical framing and dependency risk context
- Treat Aylwing as a strong reviewer for architecture direction, refactor scope, and risk framing
- If future context clarifies the formal team or title, update this file directly

View File

@@ -0,0 +1,31 @@
---
type: person
project: fidelity
role: collaborator
status: active
updated: 2026-04-16
tags:
- person
- fidelity
---
# Bruce Meeks
## Role
Repeated Fidelity collaborator in XFlow-related work.
---
## Known Context
- Reviewed and approved XFlow work repeatedly in historical threads
- Sometimes covered XFlow iOS issues while others were unavailable
- Later context suggests Bruce primarily worked on Android while still remaining a useful cross-platform contact
- Relevant in release coordination, PR review, and parity discussions between iOS and Android
---
## Guidance
- Treat Bruce as a useful source for cross-platform context and historical PR/review state
- If future context clarifies the formal role/team, update this file directly

View File

@@ -0,0 +1,33 @@
---
type: person
project: fidelity
role: collaborator
status: active
updated: 2026-04-16
tags:
- person
- fidelity
---
# David Delagneau
## Role
Repeated Fidelity collaborator in historical Slack threads.
---
## Known Context
- Appears heavily in pipeline, Jenkins, SonarQube, test-reporting, and release-process work
- Later historical activity also includes Sparta SDK proof-of-concept implementation and framework setup work
- Often provides implementation updates, process notes, and operational debugging context to Jeff
- Frequently handled CI/CD, Jenkins, reporting, and repo/setup tasks while Norman focused on SDK and consumer debugging
- Later archive activity shows him taking lead on SpartaSDK setup, JSON decoding, and repo/bootstrap work
---
## Guidance
- Treat David as a relevant source for CI/CD, release-process, and framework-setup context
- Treat David as especially relevant for Jenkins, SonarQube, Pod/repo setup, and Sparta SDK bootstrapping context
- If future context clarifies the formal role or team, update this file directly

View File

@@ -0,0 +1,36 @@
---
type: person
project: fidelity
role: collaborator
status: inactive
updated: 2026-04-17
tags:
- person
- fidelity
---
# Derian Cordoba
## Role
Historical Fidelity collaborator in project support discussions.
- No longer works with the current All-Win Software / Mattermost / Slack collaboration group.
---
## Known Context
- Appears in historical pipeline, Jenkins, and documentation conversations
- Helped document pipeline work and supported notification/credential troubleshooting
- Collaboration signal is real but current formal role remains unclear from the archive
- Often paired with David on CI/CD and notification-related work
- Showed up when the team needed operational documentation, release-process notes, or pipeline triage support
---
## Guidance
- Treat Derian as a relevant collaborator for historical pipeline/debugging context
- Treat Derian as most relevant for historical CI/CD coordination and documentation support
- Treat Derian as historical context, not a current active collaborator
- If future context clarifies the formal role or team, update this file directly

View File

@@ -0,0 +1,37 @@
---
type: person
project: fidelity
role: collaborator
status: inactive
updated: 2026-04-17
tags:
- person
- fidelity
---
# Erik Reynolds
## Role
Historical Fidelity collaborator in XFlow-related discussions.
- Previously worked for Fidelity but no longer does.
---
## Known Context
- Appears in discussions about XFlow manager behavior, consumer-vs-framework boundaries, and migration constraints
- Raises implementation and sizing concerns in architecture-heavy conversations
- Often comments on where responsibility lies between XFlow and consuming teams
- Deep archive signal suggests strong familiarity with XFlow and Apex internals, especially ownership boundaries and migration tradeoffs
- Often challenged weak assumptions about architecture, sizing, and framework responsibilities
- Useful source when deciding whether a problem belongs in XFlow, Apex, or the consumer app
---
## Guidance
- Treat Erik as a relevant source when historical context touches XFlow ownership boundaries or migration difficulty
- Treat Erik as a high-signal source for framework architecture and responsibility boundaries
- Treat Erik as historical Fidelity context, not a current active stakeholder
- If future context clarifies the formal role or team, update this file directly

View File

@@ -0,0 +1,35 @@
---
type: person
project: fidelity
role: collaborator
status: active
updated: 2026-04-16
tags:
- person
- fidelity
---
# Gurram Santosh
## Role
Project-related contact involved in issue discussions.
The exact formal role is not yet confirmed in workspace memory.
---
## Known Context
- Repeatedly appears in AO-related testing, screenshot validation, and issue verification conversations
- Often serves as a consumer-side validator or reporter when the team needs confirmation that a fix worked in their environment
- Relevant when tracking whether an issue still reproduces, whether a release build contains a fix, or whether additional consumer validation is needed
---
## Guidance
If future communication makes Santosh's role explicit, update this file with:
- team or function
- relationship to Fidelity work
- whether the person is a reporter, tester, partner, or stakeholder

View File

@@ -0,0 +1,64 @@
---
type: people-index
project: fidelity
updated: 2026-04-17
tags:
- people
- map
---
# People Index
## Active Roles
- Manager: [jeff-dewitte.md](./jeff-dewitte.md)
## Known People
- [jeff-dewitte.md](./jeff-dewitte.md)
Current direct manager for the active Fidelity project; repeated communication gatekeeper and scope shaper in historical XFlow work.
- [norman-arauz.md](./norman-arauz.md)
Former collaborator in historical Slack threads; primary implementer/investigator across SwiftUI, AO/Fid4 bugs, and release work, but no longer works with the current All-Win Software / Mattermost / Slack group.
- [david-delagneau.md](./david-delagneau.md)
Repeated historical collaborator on pipeline, CI/CD, and Sparta/SwiftUI proof-of-concept work, especially around Jenkins, reporting, and framework setup.
- [bruce-meeks.md](./bruce-meeks.md)
Repeated XFlow collaborator who often reviewed PRs, covered iOS work during absences, and later shifted primarily toward Android.
- [jason-mandozzi.md](./jason-mandozzi.md)
Repeated collaborator tied to XFlowViewMaker, FTPlanning/Fid4 integration, release support, and major architectural transitions.
- [aylwing-olivas.md](./aylwing-olivas.md)
Repeated historical collaborator who surfaces architectural concerns, SwiftUI constraints, and cross-team dependency risks.
- [erik-reynolds.md](./erik-reynolds.md)
Historical collaborator focused on XFlow manager behavior, integration boundaries, migration effort sizing, and framework responsibility boundaries; previously worked for Fidelity but no longer does.
- [gurram-santosh.md](./gurram-santosh.md)
AO-related contact who often validates fixes or confirms whether issues still reproduce in consumer environments.
- [raj-sundararaj.md](./raj-sundararaj.md)
Repeated collaborator involved in AO issue triage, release coordination, and backlog/story management around XFlow work.
- [quy-mai.md](./quy-mai.md)
Scrum/contact point who repeatedly managed backlog state, points, and closure expectations for Fidelity work.
- [tim-longfield.md](./tim-longfield.md)
FTPlanning-side contact relevant when issues crossed from XFlow into consumer-framework ownership.
- [derian-cordoba.md](./derian-cordoba.md)
Historical collaborator in pipeline and documentation work, especially around CI/CD support and operational notes; no longer works with the current All-Win Software / Mattermost / Slack group.
- [tauf.md](./tauf.md)
Taufiqur Ashrafy, often referred to as Tauf; CI/Jenkins support contact who helps with release-pipeline troubleshooting and related publication issues.
## Usage
When a person appears repeatedly in project communication, create or update their file here so the agent can reuse:
- name
- role
- relationship to the project
- communication expectations
- important context about how they influence work

View File

@@ -0,0 +1,31 @@
---
type: person
project: fidelity
role: collaborator
status: active
updated: 2026-04-16
tags:
- person
- fidelity
---
# Jason Mandozzi
## Role
Repeated Fidelity collaborator in XFlow and consumer-integration work.
---
## Known Context
- Closely associated with XFlowViewMaker, Fid4/FTPlanning integration, and release/version work
- Frequently authored or owned implementation branches later reviewed by others
- Showed up repeatedly in architecture, eventing, navigation, and consumer-facing integration discussions
- Often served as an important source of context on historical implementation choices inside XFlow and related consumer flows
---
## Guidance
- Treat Jason as a high-signal source for XFlowViewMaker and consumer integration history
- If future context clarifies the formal role/team, update this file directly

View File

@@ -0,0 +1,76 @@
---
type: person
project: fidelity
role: manager
status: active
updated: 2026-04-17
tags:
- person
- fidelity
---
# Jeff DeWitte
## Role
Current direct manager for the active Fidelity project.
---
## Historical Collaboration Pattern
- Repeatedly acted as reporting manager, reviewer, and communication gatekeeper across multi-year XFlow work
- Frequently rewrote PR descriptions, Jira updates, and cross-team messages before they were sent
- Regularly redirected work based on release risk, consumer pressure, or manager/stakeholder expectations
- Often pushed for explicit distinction between framework bugs, consumer bugs, service issues, and scope creep
- Acts as the main communication bridge into the Fidelity-side Teams context while David works from the All-Win Software side
---
## Communication Requirements
- Native US English
- Prefers clear, concise updates
- Needs accurate scope, not vague reassurance
- Frequently asks for precise reproducibility, auth context, and regression scope
---
## What Good Updates Include
1. Context
2. Observation
3. Action
Good updates usually clarify:
- what issue or task is being discussed
- whether the behavior is reproducible
- whether auth state matters
- whether this looks like an external issue or a regression
- what the next step is
---
## Influence On Work
- Story titles, points, and scope discussions with Jeff are often worth remembering
- Jeff approvals can change what belongs in current state or work-item memory
- Jeff feedback is often a signal to tighten wording before communicating externally
- Jeff often asks for evidence, reproduction detail, and exact next action before approving external communication
- If a draft is still ambiguous, Jeff may prefer to rewrite it directly so the external version is unambiguous and does not generate avoidable follow-up
- Jeff is often the person who reports progress or status into the Fidelity-facing context after David advances the implementation or investigation work
---
## Repeated Coaching / Expectations
- Test in the closest real consumer environment first when the issue is consumer-specific; use sample app mainly to rule ownership in or out
- Do not open or socialize a PR as "ready" until the issue is fully resolved and no obvious follow-up bug has been introduced
- Separate current-ticket scope from unrelated preexisting bugs; do not blur them in standups or status updates
- Be explicit about environment, branch/build/version, account, flow entry point, and repro steps before concluding where a bug belongs
- When blocked, keep reducing uncertainty with other available evidence sources instead of waiting passively
- Fast admin/process actions matter: update Jira/status/comments promptly when others are visibly waiting on them
- Prefer evidence-heavy communication: screenshots, videos, exact error text, branch/version, and direct comparisons to main/web/UIKit/Fid4 when relevant
- Use polished native-sounding English for external-facing comments; avoid sending rough wording when a cleaner version is easy to produce
- When a consumer issue may actually belong to another team/framework, document the finding clearly and route ownership instead of carrying it indefinitely in XFlow
- For cross-team status messages, make the sequence of events extremely explicit so the reader can tell what was the original issue, what changed, what XFlow changed, and what remains a separate service-side issue

View File

@@ -0,0 +1,43 @@
---
type: role-map
project: fidelity
role: manager
status: active
updated: 2026-04-17
tags:
- role
- manager
- fidelity
---
# Manager
## Current Holder
- Name: Jeff DeWitte
- Profile: [jeff-dewitte.md](./jeff-dewitte.md)
---
## Role
Direct supervisor or primary reporting manager for the active project.
- In practice, Jeff is also the main bridge between David's All-Win Software work and the Fidelity-side reporting context.
---
## Usage
This file maps the current project role to the actual person.
If the active manager changes in a future project, update this file to point to the new person while preserving their person-specific profile separately.
---
## Default Communication Requirements
- Clear written English
- Concise updates
- Explicit scope
- No vague reassurance
- Useful next action when relevant

View File

@@ -0,0 +1,35 @@
---
type: person
project: fidelity
role: collaborator
status: inactive
updated: 2026-04-17
tags:
- person
- fidelity
---
# Norman Arauz
## Role
Frequent Fidelity/XFlow engineer collaborator in historical Slack threads.
- No longer works with the current All-Win Software / Mattermost / Slack collaboration group.
---
## Known Context
- Repeated day-to-day implementer/investigator across XFlow SwiftUI, AO/Fid4 bugs, version bumps, analytics, and pipeline debugging
- Often coordinated with Jeff on scope, descriptions, approvals, and manager-ready wording
- Frequently investigated consumer-reported issues directly in Fid4 and sample-app parity checks
- Often produced detailed technical findings first, then asked Jeff to polish or approve external wording
- Exact formal role may need confirmation if used outside workspace memory
---
## Guidance
- Treat Norman as a strong source for historical implementation detail, reproduction findings, and release-process context
- Treat Norman as historical context, not a current active collaborator
- If later communication clarifies the formal team/title, update this file directly

View File

@@ -0,0 +1,31 @@
---
type: person
project: fidelity
role: collaborator
status: active
updated: 2026-04-16
tags:
- person
- fidelity
---
# Quy Mai
## Role
Confirmed Scrum Master / contact point repeatedly involved in backlog and process management.
---
## Known Context
- Repeatedly asked for clearer Jira/state management, points, and backlog hygiene
- Often confirmed whether work should remain in backlog, be canceled, or be reframed as separate stories
- Relevant for sprint structure, story cleanup, and expectation-setting around what counts as production or release-priority work
---
## Guidance
- Treat Quy as an important source for process expectations, backlog cleanup, and story framing
- When drafting notes or prompts, refer to Quy as Scrum Master rather than a generic stakeholder
- If future context clarifies the formal title/team, update this file directly

View File

@@ -0,0 +1,30 @@
---
type: person
project: fidelity
role: collaborator
status: active
updated: 2026-04-16
tags:
- person
- fidelity
---
# Raj Sundararaj
## Role
Repeated Fidelity collaborator involved in project coordination and active issue triage.
---
## Known Context
- Repeatedly surfaced or assigned XFlow/AO issues and asked for current status
- Involved in release coordination, validation follow-up, and backlog movement
- Relevant when the team needed to align issue ownership, repro state, or urgency with consumer-side expectations
---
## Guidance
- Treat Raj as a useful contact for issue routing, AO coordination, and release follow-up
- If future context clarifies the formal role/team, update this file directly

View File

@@ -0,0 +1,44 @@
---
type: person
project: fidelity
role: CI and Jenkins support
status: active
teams: [ci-cd, ios-frameworks]
topics: [jenkins, pipelines, podspec-publication, release-support]
related: [consumer-integration, pdiap-15765]
aliases: [Taufiqur Ashrafy, Tauf]
tags:
- person
- fidelity
updated: 2026-04-17
---
# Taufiqur Ashrafy
## Role
- CI / Jenkins support contact who helps unblock pipeline and publication issues.
---
## Collaboration Pattern
- David reaches out to Tauf when Jenkins or release-pipeline steps need support, especially around XFlowViewMaker publication or approval/pipeline follow-through.
- Tauf has been specifically relevant to the `PDIAP-15765` propagation work because David planned to ping him about the remaining XFlowViewMaker approval path.
---
## Communication Notes
- Useful contact for operational release and pipeline troubleshooting.
- David has seen podspec-repo edits happen after publication and specifically called out Tauf as someone involved in CI support around that ecosystem.
- Often referred to informally as `Tauf`.
- Fidelity Teams may show names in a surname-first style, so this person may appear under a different display order there.
- In the current XFlowViewMaker propagation issue, Tauf clarified that the needed fix belongs in the podspec repo rather than FTFrameworks source, and pointed David toward removing the XFlowViewMaker version constraint for `ftaccountopen`.
---
## Related Context
- `project-knowledge/03-context/workstreams/consumer-integration.md`
- `project-knowledge/02-work-items/pdiap-15765.md`

View File

@@ -0,0 +1,30 @@
---
type: person
project: fidelity
role: collaborator
status: active
updated: 2026-04-16
tags:
- person
- fidelity
---
# Tim Longfield
## Role
FTPlanning-side collaborator relevant to cross-framework issue ownership.
---
## Known Context
- Appeared when issues first thought to be XFlow bugs were traced into FTPlanning
- Relevant contact for whether a transfer/add-money bug belonged to FTPlanning instead of XFlow
- Useful when a consumer-side framework fix was needed before XFlow could close validation work
---
## Guidance
- Treat Tim as a relevant contact for FTPlanning-owned fixes and cross-team validation
- If future context clarifies the formal role/team, update this file directly