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