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.
52 lines
2.1 KiB
Markdown
52 lines
2.1 KiB
Markdown
# 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.
|