Christopher Clendening
038442d4fd
- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
38 lines
1.1 KiB
Markdown
38 lines
1.1 KiB
Markdown
# Backend Engineer — Memory
|
|
|
|
This role's own accumulated context: patterns in the codebase you work in, recurring review
|
|
feedback, and past implementation judgment calls along with the reasoning behind them. Not
|
|
automatically shared with other roles — see `../../MEMORY.md` on the two-tier memory system.
|
|
Promote anything company-wide to `../../memory/architecture-memory.md` instead of leaving it
|
|
siloed here.
|
|
|
|
## Recurring review feedback
|
|
|
|
*None recorded yet.* When the same kind of comment shows up across multiple PRs, record it here
|
|
so it's caught before review next time, not just after.
|
|
|
|
## Implementation judgment calls
|
|
|
|
*None recorded yet.*
|
|
|
|
```
|
|
### YYYY-MM-DD — <short title>
|
|
<the call made, and the situation it responded to>
|
|
**Reasoning:** <why this approach, over the alternatives>
|
|
```
|
|
|
|
## Project-specific context
|
|
|
|
*None recorded yet.* Notes specific to a project's data model, API conventions, or quirks of
|
|
its existing codebase that aren't obvious from reading the code cold.
|
|
|
|
## Format for new entries
|
|
|
|
```
|
|
### YYYY-MM-DD — <short title>
|
|
|
|
<the observation>
|
|
|
|
**Why it matters:** <what this changes about how you implement/review going forward>
|
|
```
|