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.

project-knowledge/04-people/jeff-dewitte.md

@@ -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