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/00-start/glossary.md

@@ -0,0 +1,51 @@
+---
+type: glossary
+audience: new-member
+tags:
+  - onboarding
+  - glossary
+---
+
+# Glossary
+
+Common terms used in the Fidelity project knowledge vault.
+
+---
+
+## Workspace Terms
+
+- `project-knowledge`: this Obsidian vault; transferable Fidelity project knowledge.
+- `agent-memory`: agent operating rules outside this vault.
+- `operational memory`: curated file-based memory that helps future sessions reason accurately.
+- `daily log`: same-day evidence and evolving findings in `project-knowledge/06-daily/`.
+- `state`: near-term active work and priorities in `project-knowledge/01-current/`.
+- `work item`: canonical memory for a ticket, story, task, or investigation in `project-knowledge/02-work-items/`.
+- `stable context`: durable project knowledge under `project-knowledge/03-context/`.
+- `inbox`: raw or lightly processed communication evidence under `ai/inbox/`.
+- `promotion`: moving high-confidence evidence into canonical memory.
+- `memory interface`: project-agnostic scripts under `scripts/memory/` that create, search, query, and validate project knowledge without coupling the workspace to Obsidian.
+
+---
+
+## Fidelity Terms
+
+- `Fid4`: main Fidelity consumer iOS app and key validation environment.
+- `XFlowSDK`: backend-driven UI engine that renders flows from service-provided configuration.
+- `XFlowViewMaker`: adapter layer historically involved in integration and release propagation.
+- `FTFrameworks`: feature modules such as account opening or transfer flows that can mediate XFlow adoption.
+- `AO`: account opening context; many reports require careful reproduction and scope validation.
+- `Discourse`: external issue/report source; treat reports as external until confirmed.
+- `REST migration`: migration away from GraphQL/Apollo toward REST, with REST behind a feature flag unless confirmed otherwise.
+- `authenticated flow`: behavior reproduced while signed in; often differs from non-authenticated behavior.
+- `entry point`: the path used to reach a flow, which can affect backend-driven behavior.
+- `Cogstore`: flow-configuration publishing and version-comparison platform.
+
+---
+
+## Communication Terms
+
+- `external report`: issue reported externally before regression status is confirmed.
+- `regression`: behavior confirmed to be newly broken relative to a known baseline.
+- `scope`: the exact affected flow, platform, auth state, environment, and ownership boundary.
+- `reproducibility`: whether the behavior can be repeated with known steps and context.
+- `manager-ready`: concise, explicit, natural professional English that can be sent without rewriting.