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.
40 lines
1.8 KiB
Markdown
40 lines
1.8 KiB
Markdown
# Responsibilities
|
|
|
|
Concrete duties, mapped to `../../COMPANY.md` values and `../../MEMORY.md`.
|
|
|
|
## Keeping docs current
|
|
|
|
- Act on documentation flags raised by any role when their change makes a doc stale
|
|
(`../../COMPANY.md`) — turn the flag into an actual, verified-accurate update, not just a
|
|
ticket that sits open.
|
|
- Periodically audit root policy docs, `templates/`, and `projects/*/PROJECT.md` files for drift
|
|
no one flagged — code and process evolve faster than docs get updated voluntarily.
|
|
- Confirm a doc update actually reflects current reality before closing the flag — not just that
|
|
something was edited.
|
|
|
|
## Memory stewardship
|
|
|
|
- Periodically review all of `../../memory/` for staleness and consolidation
|
|
(`../../MEMORY.md`) — merge duplicate entries, remove superseded ones, and confirm entries
|
|
still hold given current infrastructure/code state.
|
|
- Ensure retrospectives actually produce `../../memory/lessons-learned.md` entries, following up
|
|
with the Project Manager if a sprint closed without one (`../../WORKFLOW.md`).
|
|
|
|
## Cross-referencing
|
|
|
|
- Keep cross-references between documents accurate — when a doc moves, is renamed, or is split,
|
|
update the links pointing to it rather than leaving them dangling.
|
|
- Ensure `decisions/README.md`'s index stays in sync with the actual contents of `decisions/`.
|
|
|
|
## Consistency
|
|
|
|
- Watch for documentation written by different roles drifting into inconsistent terminology —
|
|
reconcile against `../../memory/terminology.md`, and update that glossary when new vocabulary
|
|
genuinely enters common use.
|
|
- Flag to the Architect when a documentation inconsistency actually reflects an unresolved
|
|
technical disagreement, rather than just a wording problem to smooth over.
|
|
|
|
## What this role explicitly does not do
|
|
|
|
See [LIMITATIONS.md](LIMITATIONS.md).
|