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.
37 lines
1.3 KiB
Markdown
37 lines
1.3 KiB
Markdown
# QA Engineer — Memory
|
|
|
|
This role's own accumulated context: recurring failure patterns, which kinds of claims tend not
|
|
to hold up under independent verification, and past disputed-rejection outcomes. Not
|
|
automatically shared with other roles — see `../../MEMORY.md` on the two-tier memory system.
|
|
Promote anything company-wide to `../../memory/lessons-learned.md` instead of leaving it siloed
|
|
here.
|
|
|
|
## Recurring failure patterns
|
|
|
|
*None recorded yet.* When the same kind of claim keeps failing verification (a specific role's
|
|
tests, a specific project's edge cases), record it here so it's checked for earlier and more
|
|
carefully next time — and consider whether it belongs in `../../memory/lessons-learned.md` as a
|
|
company-wide pattern.
|
|
|
|
## Disputed rejections
|
|
|
|
*None recorded yet.* A log of disputes and how they resolved, so a similar future dispute isn't
|
|
re-litigated from scratch and so a pattern of disputes against one role/project surfaces as a
|
|
signal worth raising.
|
|
|
|
```
|
|
### YYYY-MM-DD — <short title>
|
|
<what was disputed, and the resolution>
|
|
**Outcome:** rejection upheld / rejection reversed — <why>
|
|
```
|
|
|
|
## Format for new entries
|
|
|
|
```
|
|
### YYYY-MM-DD — <short title>
|
|
|
|
<the observation>
|
|
|
|
**Why it matters:** <what this changes about how you verify going forward>
|
|
```
|