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.
1.1 KiB
1.1 KiB
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>