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.

agent-memory/memory/promotion-rules.md

@@ -0,0 +1,145 @@
+---
+type: agent-memory
+status: active
+updated: 2026-04-17
+tags: [process, memory, promotion]
+---
+
+# Memory Promotion Rules
+
+## Goal
+
+Keep workspace memory current automatically without asking the user what to promote after every successful sync.
+
+---
+
+## Default Rule
+
+When new Mattermost context is explicit, project-relevant, and high-confidence, promote it automatically.
+
+Do not ask for promotion confirmation by default.
+
+If a fact is ambiguous, skip it or keep it only in the daily log with appropriate qualifiers.
+
+---
+
+## File Selection
+
+### Promote to `project-knowledge/06-daily/YYYY-MM-DD.md`
+
+Use the daily log for:
+
+- concrete same-day work updates
+- story creation, sizing, approval, and scope updates
+- manager-approved wording or root-cause framing tied to current work
+- confirmed version checks tied to active work
+- reproduction findings that are useful now but may still evolve
+
+Daily logs are the default destination for most promoted Mattermost facts.
+
+### Promote to `project-knowledge/01-current/current-work.md`
+
+Use current state only for facts that materially affect active work over the next few days, such as:
+
+- approved active story scope
+- confirmed current debugging constraints
+- current reproduction conditions that change how the work is approached
+- near-term priorities confirmed by manager communication
+
+Do not copy every daily update into current state.
+
+### Promote to `project-knowledge/02-work-items/*.md` and `project-knowledge/01-current/work-items.md`
+
+Use `project-knowledge/02-work-items/*.md` for:
+
+- explicit Jira IDs
+- approved or explicit story titles
+- current story points
+- current scope notes
+- active status notes that still matter for future updates
+
+If a Jira item is likely to appear again in standups or manager updates, it belongs here.
+
+Use `project-knowledge/01-current/work-items.md` as the compact summary of which ticket files are active.
+
+### Promote to `project-knowledge/03-context/project.md`
+
+Use project context only for durable project knowledge that should survive beyond the current work window, such as:
+
+- stable architecture constraints
+- recurring debugging truths
+- persistent testing limitations
+- enduring behavior of REST, GraphQL, XFlow, auth, or entry points
+
+Do not promote story-specific daily movement into project context unless it changes durable project understanding.
+
+### Promote to `project-knowledge/05-decisions/*.md`
+
+Use decisions only for explicit confirmed decisions with medium or long-term impact.
+
+### Promote to `project-knowledge/04-people/index.md` and `project-knowledge/04-people/*.md`
+
+Use these files when:
+
+- a person's identity matters repeatedly
+- a role becomes associated with a specific person
+- a stakeholder's communication or approval patterns affect future work
+- a human appears across multiple channels or years with repeated technical, process, or approval signal
+- the archive makes the collaboration pattern clear even if the formal title is still unknown
+
+Prefer:
+
+- `manager.md` for role mapping
+- `index.md` for active roster
+- one file per person for person-specific context
+
+If exact role confidence is low, store the person's repeated project relationship instead of inventing a title.
+
+---
+
+## Do Not Promote
+
+Do not record these as project memory:
+
+- tooling activity
+- sync status
+- missing dependencies
+- empty inbox situations
+- reminders or urgency without project substance
+- unapproved drafts
+- generic chat noise
+
+---
+
+## Confidence Rules
+
+Auto-promote when the signal is high-confidence, for example:
+
+- the manager explicitly approves something
+- a Jira story number, title, points, or scope is explicitly confirmed
+- a version is stated directly and tied to the active project
+- a reproduction condition is clearly stated with scope qualifiers
+
+If confidence is mixed:
+
+- prefer the daily log
+- preserve qualifiers such as "appears", "currently", or "for authenticated users"
+- avoid promoting to stable project context
+
+---
+
+## Example Policy
+
+Given Mattermost updates like:
+
+- PDIAP-15836 created and sized at 8 points
+- the manager approved a story title
+- REST-removal scope was approved
+- XFlowViewMaker 0.5.0 is already in Fid4
+- AO DOB validation issue appears auth-only in TeenIdentityCheck
+
+Automatic behavior should be:
+
+- add all of them to today's log if they are relevant to today's work
+- promote only the currently actionable subset to `project-knowledge/01-current/current-work.md`
+- keep story-specific details out of `project-knowledge/03-context/project.md` unless they reveal a durable project rule