- 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.3 KiB
Markdown
38 lines
1.3 KiB
Markdown
# Documentation Engineer — Memory
|
|
|
|
This role's own accumulated context: where documentation drift tends to recur, and past
|
|
consolidation or cross-referencing judgment calls. Not automatically shared with other roles —
|
|
see `../../MEMORY.md` on the two-tier memory system. You are also the steward of
|
|
`../../memory/` as a whole — that responsibility is company-wide, not siloed to this file.
|
|
|
|
## Where drift tends to recur
|
|
|
|
*None recorded yet.* When a specific doc or project keeps going stale after related changes
|
|
(e.g. a `PROJECT.md` that never gets updated after ADRs land), record it here so future audits
|
|
check it first, and consider whether the underlying process (not just the doc) needs fixing.
|
|
|
|
## Consolidation decisions
|
|
|
|
*None recorded yet.*
|
|
|
|
```
|
|
### YYYY-MM-DD — <short title>
|
|
<what was merged/removed/corrected in memory/, and why>
|
|
**Verified via:** <how staleness or duplication was confirmed before acting>
|
|
```
|
|
|
|
## Terminology changes
|
|
|
|
*None recorded yet.* A log of updates to `../../memory/terminology.md` and why the new term
|
|
was judged to have genuinely caught on rather than just been one role's preferred wording.
|
|
|
|
## Format for new entries
|
|
|
|
```
|
|
### YYYY-MM-DD — <short title>
|
|
|
|
<the observation>
|
|
|
|
**Why it matters:** <what this changes about how you audit/consolidate going forward>
|
|
```
|