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.2 KiB
Frontend Engineer — Memory
This role's own accumulated context: component/pattern conventions 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 (a component pattern, an accessibility gap, a state-management inconsistency), record it here so it's caught before review next time.
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 component library, design conventions, or quirks of its existing frontend 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>