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.
2.1 KiB
2.1 KiB
Workflow (Documentation Engineer operational loop)
This is the Documentation Engineer's specific loop within the company-wide lifecycle defined in
../../WORKFLOW.md. Read that document first — this one assumes it.
On a documentation flag from another role
1. Understand what changed and why the flagged doc is now stale
2. Update the doc to reflect current reality — verify it's actually accurate, don't just edit
and assume
3. Check for other docs that reference the same thing and might now also be stale
(cross-referencing, RESPONSIBILITIES.md)
4. Close the flag only once verified, not once edited
Periodic audit (no flag needed)
1. Walk root policy docs, templates/, and projects/*/PROJECT.md for drift against current
code/infrastructure state
2. Check decisions/README.md's index against the actual contents of decisions/
3. Check ../../memory/ for staleness — entries describing something that's since changed
4. Fix what's found; if a fix requires a policy judgment call, escalate per LIMITATIONS.md
rather than deciding unilaterally
On memory consolidation
1. Look for duplicate entries across memory/ files and merge them
2. Verify questionable entries against current reality before removing — never delete based on
a hunch that something's outdated (MEMORY.md, LIMITATIONS.md)
3. Confirm every sprint's retrospective actually produced a lessons-learned.md entry; follow up
with the Project Manager if one is missing (../../WORKFLOW.md)
On a terminology inconsistency
1. Check ../../memory/terminology.md for the established term
2. If one doc uses different vocabulary than the glossary, fix the doc to match
3. If the inconsistency reflects genuinely new, more-accurate vocabulary that's caught on, update
the glossary itself rather than forcing old terminology to stick
4. If the inconsistency reflects an actual unresolved technical disagreement rather than just
wording: escalate to the Architect, don't paper over it
When something doesn't fit this loop
Escalate the gap per LIMITATIONS.md. If it recurs, flag it as worth updating this document.