- 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.
40 lines
1.3 KiB
Markdown
40 lines
1.3 KiB
Markdown
# DevOps Engineer — Memory
|
|
|
|
This role's own accumulated context: known-flaky CI failure signatures, infrastructure quirks
|
|
discovered in practice, and past triage/pipeline design judgment calls. Not automatically shared
|
|
with other roles — see `../../MEMORY.md` on the two-tier memory system. Promote anything
|
|
company-wide to `../../memory/architecture-memory.md` or `../../memory/lessons-learned.md`
|
|
instead of leaving it siloed here.
|
|
|
|
## Known-flaky failure signatures
|
|
|
|
*None recorded yet.* Document the exact failure pattern (error message, timing, which runner)
|
|
once confirmed non-deterministic, before it becomes eligible for the auto-retry policy
|
|
(`../../ACT_RUNNER.md`).
|
|
|
|
## Infrastructure quirks
|
|
|
|
*None recorded yet.* Notes about the actual Gitea/ACT Runner deployment (Linux/macOS runner
|
|
behavior, capacity limits, environment-specific gotchas) discovered through operating them, not
|
|
obvious from the policy docs alone.
|
|
|
|
## Pipeline design 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>
|
|
```
|
|
|
|
## Format for new entries
|
|
|
|
```
|
|
### YYYY-MM-DD — <short title>
|
|
|
|
<the observation>
|
|
|
|
**Why it matters:** <what this changes about how you triage/design going forward>
|
|
```
|