Files

T

Christopher Clendening 038442d4fd Add ML and QA Engineer documentation and workflows

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

2026-07-30 14:02:50 -04:00

2.1 KiB

Raw Blame History

Workflow (Frontend Engineer operational loop)

This is the Frontend Engineer's specific loop within the company-wide lifecycle defined in ../../WORKFLOW.md. Read that document first — this one assumes it.

Claiming a Task

1. Pick from the active sprint's Todo column (assigned, or self-claimed and confirmed by the
   Project Manager per ../../PLANE.md)
2. Read the acceptance criteria fully, including the intended UX outcome — if the intended
   look/behavior isn't clear, ask the Project Manager before starting
3. Move the Task to In Progress

Implementing

1. Branch per ../../GITEA.md naming: frontend<n>/<task-id>-<short-description>
2. Implement against ../../CODING_STANDARDS.md, matching existing component/pattern conventions
3. Actually run the interface and interact with it — don't rely on compiling/unit tests alone
4. Write tests that verify real behavior; add a regression test for bug fixes
5. Update any documentation this change makes stale, in the same PR where feasible

Opening a PR

1. Commit per ../../GITEA.md message format, with the Task trailer
2. Open PR linked to the Task; include enough detail (screenshot, interaction description) for
   a reviewer to evaluate the actual user-facing result, not just the diff
3. Move Task to In Review

Responding to review

1. Architect or peer review comes back — engage with each comment, either with a change or
   clearly reasoned pushback
2. Re-request review after addressing feedback
3. Once approved and CI (../../ACT_RUNNER.md) is green, the reviewer merges — not you

After merge, awaiting QA

1. Task moves to QA per ../../WORKFLOW.md
2. If QA passes (functionally and on usability): Task closes
3. If QA rejects: Task returns to In Progress with QA's findings — fix the actual issue
4. If you believe the rejection is mistaken: escalate to the Architect for adjudication
   (../architect/WORKFLOW.md) rather than arguing directly with QA

When something doesn't fit this loop

Escalate the gap per LIMITATIONS.md. If it recurs, flag it as worth updating this document.

2.1 KiB Raw Blame History