Skip to content

Commit bfb70fa

Browse files
plainOldCodeplainOldCode
committed
ci: add live e2e smoke and business task PRD
1 parent ff214f4 commit bfb70fa

3 files changed

Lines changed: 140 additions & 3 deletions

File tree

‎.github/workflows/workspace-smoke.yml‎

Lines changed: 58 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -41,3 +41,61 @@ jobs:
4141
- uses: azure/setup-helm@v4
4242
- name: Render Helm chart
4343
run: helm template example-stack infrastructure/k3s/helm/example-stack
44+
45+
e2e-smoke:
46+
runs-on: ubuntu-latest
47+
steps:
48+
- uses: actions/checkout@v4
49+
- uses: actions/setup-java@v4
50+
with:
51+
distribution: temurin
52+
java-version: "21"
53+
- uses: actions/setup-node@v4
54+
with:
55+
node-version: "22"
56+
- name: Enable Corepack
57+
run: corepack enable
58+
- name: Install frontend dependencies
59+
working-directory: frontend
60+
run: pnpm install --frozen-lockfile
61+
- name: Install e2e dependencies and Playwright browser
62+
working-directory: e2e-test
63+
run: |
64+
pnpm install --frozen-lockfile
65+
pnpm exec playwright install --with-deps chromium
66+
- name: Start database
67+
run: docker compose -f database/dockerized/docker-compose.yml up -d
68+
- name: Wait for database
69+
run: |
70+
timeout 180 bash -c 'until docker exec example-workspace-db mariadb-admin ping -h 127.0.0.1 -uroot -proot --silent; do sleep 2; done'
71+
- name: Start backend
72+
run: |
73+
cd backend
74+
nohup ./gradlew bootRun --no-daemon > ../backend.log 2>&1 &
75+
echo $! > ../backend.pid
76+
- name: Wait for backend health
77+
run: |
78+
timeout 180 bash -c 'until curl -sf http://127.0.0.1:8080/api/health >/dev/null; do sleep 2; done'
79+
- name: Start frontend
80+
run: |
81+
cd frontend
82+
nohup pnpm exec vite --host 127.0.0.1 --port 5173 > ../frontend.log 2>&1 &
83+
echo $! > ../frontend.pid
84+
- name: Wait for frontend
85+
run: |
86+
timeout 180 bash -c 'until curl -sf http://127.0.0.1:5173 >/dev/null; do sleep 2; done'
87+
- name: Run Playwright smoke
88+
working-directory: e2e-test
89+
run: pnpm test
90+
- name: Dump service logs on failure
91+
if: failure()
92+
run: |
93+
test -f backend.log && tail -n 200 backend.log || true
94+
test -f frontend.log && tail -n 200 frontend.log || true
95+
docker compose -f database/dockerized/docker-compose.yml logs --tail=200 || true
96+
- name: Stop local services
97+
if: always()
98+
run: |
99+
test -f frontend.pid && kill "$(cat frontend.pid)" || true
100+
test -f backend.pid && kill "$(cat backend.pid)" || true
101+
docker compose -f database/dockerized/docker-compose.yml down -v || true

‎README.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -127,10 +127,10 @@ The supporting note for that workflow lives in [`docs/ai-workflow.md`](docs/ai-w
127127
`backend`, `frontend`, `e2e-test`, and `infrastructure` if deployment or ingress behavior changes.
128128
6. Use the PRD and spec together as the feature handoff.
129129

130-
Current documentation examples for the planned next feature:
130+
Current documentation examples:
131131

132-
- PRD: [`docs/prd/task-lifecycle-and-status-rules.md`](docs/prd/task-lifecycle-and-status-rules.md)
133-
- Spec: [`docs/spec/task-lifecycle-and-status-rules.md`](docs/spec/task-lifecycle-and-status-rules.md)
132+
- Planned implementation slice: [`docs/prd/task-lifecycle-and-status-rules.md`](docs/prd/task-lifecycle-and-status-rules.md) and [`docs/spec/task-lifecycle-and-status-rules.md`](docs/spec/task-lifecycle-and-status-rules.md)
133+
- PRD-stage business planning slice: [`docs/prd/business-task-intake-and-planning.md`](docs/prd/business-task-intake-and-planning.md)
134134

135135
## Workspace Shape
136136

‎docs/prd/business-task-intake-and-planning.md‎

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
# Business Task Intake And Planning PRD
2+
3+
Status: Candidate next feature. This PRD describes a business-facing task slice that could follow the current read-only task demo.
4+
5+
## Background
6+
7+
The current workspace proves the wiring between backend, frontend, database, e2e-test, and local infrastructure.
8+
9+
That is useful as a delivery skeleton, but the task shape is still too technical and too thin for business planning.
10+
11+
Real work intake usually starts with a customer or stakeholder request, not with an internal engineering title alone.
12+
13+
## Problem
14+
15+
The current task model can show a title, status, and creation time, but it cannot answer the planning questions that matter to a business-facing workflow:
16+
17+
- who asked for the work
18+
- what exactly is being requested
19+
- when the delivery is expected
20+
- how much effort the build is expected to take
21+
- who is responsible for doing it
22+
23+
Without those fields, the task list is useful as a demo of connectivity, but not as a useful planning artifact.
24+
25+
## Goal
26+
27+
Introduce a small task-planning feature that captures the minimum business context needed to turn a request into a trackable delivery item.
28+
29+
## Users
30+
31+
- A solo engineer or tech lead translating stakeholder requests into delivery work
32+
- A reviewer who wants to see that the workspace can represent both product context and execution ownership
33+
34+
## Requirements
35+
36+
1. A task can record the customer or stakeholder request that triggered the work.
37+
2. A task can record a plain-language description of what is being delivered.
38+
3. A task can record the expected delivery date.
39+
4. A task can record an engineering estimate for the build effort.
40+
5. A task can record who is responsible for doing the work.
41+
6. The frontend should make these fields easy to scan in a task list or detail view.
42+
7. The backend should validate required planning data instead of trusting the client.
43+
44+
## Suggested Data Shape
45+
46+
The exact contract can be refined in a spec, but the feature should cover these concepts:
47+
48+
- `customerRequest`
49+
- `requestedWork`
50+
- `targetDeliveryDate`
51+
- `buildEstimate`
52+
- `owner`
53+
54+
## Success Criteria
55+
56+
- A reviewer can understand a task as a business request, not only as an engineering placeholder.
57+
- The repo gains one credible example of how a PRD can push the task model beyond a seeded demo row.
58+
- The next spec can derive backend validation, frontend form behavior, and e2e coverage from this document.
59+
60+
## Out Of Scope
61+
62+
- Customer comments or long discussion threads
63+
- Attachments or uploaded files
64+
- Team capacity planning across multiple people
65+
- Actual time tracking versus estimated time
66+
- Notifications or reminders
67+
68+
## Why This Matters
69+
70+
This is a small feature, but it moves the task model closer to real delivery work.
71+
72+
It adds the planning context that bridges:
73+
74+
- stakeholder request
75+
- delivery expectation
76+
- engineering estimate
77+
- ownership
78+
79+
That makes the workspace more credible as a product-to-delivery example, not just a technical integration demo.

0 commit comments

Comments
 (0)