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