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:
@@ -0,0 +1,48 @@
|
||||
---
|
||||
type: decision
|
||||
project: fidelity
|
||||
status: accepted
|
||||
title: "Discourse Issues Handling"
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- decision
|
||||
- fidelity
|
||||
---
|
||||
# Discourse Issues Handling
|
||||
|
||||
## Context
|
||||
|
||||
External reports from AO testing or Discourse may:
|
||||
|
||||
- already exist in main
|
||||
- be partially reproducible
|
||||
- depend on authentication
|
||||
- reflect backend behavior rather than a new regression
|
||||
|
||||
---
|
||||
|
||||
## Decision
|
||||
|
||||
Treat incoming reports as external issues until scope is confirmed.
|
||||
|
||||
---
|
||||
|
||||
## Validation Rules
|
||||
|
||||
Always confirm:
|
||||
|
||||
- reproducibility
|
||||
- environment
|
||||
- auth state
|
||||
- entry point
|
||||
- whether the issue exists in main
|
||||
|
||||
---
|
||||
|
||||
## Communication Rule
|
||||
|
||||
Do not say a report is a regression until comparison has been validated.
|
||||
|
||||
Preferred framing:
|
||||
|
||||
"Investigating external report. Scope, auth state, and reproducibility still being confirmed."
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: decision
|
||||
project: fidelity
|
||||
status: accepted
|
||||
title: "REST vs GraphQL"
|
||||
updated: 2026-04-16
|
||||
tags:
|
||||
- decision
|
||||
- fidelity
|
||||
---
|
||||
# REST vs GraphQL
|
||||
|
||||
## Decision
|
||||
|
||||
Deprecate GraphQL and migrate to REST progressively.
|
||||
|
||||
---
|
||||
|
||||
## Constraints
|
||||
|
||||
- REST is behind a feature flag
|
||||
- GraphQL remains fallback
|
||||
- Behavior parity matters during migration
|
||||
|
||||
---
|
||||
|
||||
## Communication Rule
|
||||
|
||||
When reporting findings:
|
||||
|
||||
- state whether REST was confirmed enabled
|
||||
- avoid implying REST is the default path
|
||||
- call out when behavior may still come from GraphQL fallback
|
||||
|
||||
---
|
||||
|
||||
## Follow-up
|
||||
|
||||
- Remove Apollo when migration is safe
|
||||
- Retire GraphQL-specific tests only after parity is confirmed
|
||||
Reference in New Issue
Block a user