This document is the operational guide for AI agents contributing to helpwave/tasks.
Use it as the source of truth for how to understand the repository, make safe changes, and deliver high-quality contributions with minimal back-and-forth.
helpwave/tasks is an open-source healthcare operations platform for ward and task management.
Primary goals:
- Organize clinical tasks and patient workflows
- Reflect ward/location hierarchy and team context
- Support real-time collaborative updates
- Maintain auditability and operational reliability
Core architecture:
backend/: FastAPI + Strawberry GraphQL APIweb/: Next.js (Pages Router) frontendtests/: Playwright E2E packagesimulator/: traffic/workflow simulatorproxy/: Nginx reverse proxy for production-style routingkeycloak/: identity provider configscaffold/: initial location tree and seed-like structure
- Prefer precise, minimal changes over broad refactors unless explicitly requested.
- Preserve existing behavior unless the task requires changing it.
- Never commit secrets (
.env, credentials, tokens, private keys). - Never run destructive git commands unless explicitly instructed.
- Do not edit generated files manually unless the task explicitly asks for it.
- Keep code clean, explicit, and reusable.
- Do not add code comments unless explicitly requested.
- Validate changes locally with relevant checks before finalizing.
- Language: Python (FastAPI, Strawberry GraphQL, SQLAlchemy async, Alembic)
- Responsibilities:
- GraphQL schema and resolvers
- Auth and request context
- Authorization logic (location-scoped visibility/access)
- Database persistence and migrations
- Redis-backed pub/sub notifications
- InfluxDB-backed audit logging
Important paths:
backend/main.pybackend/config.pybackend/auth.pybackend/api/context.pybackend/api/resolvers/backend/api/services/authorization.pybackend/database/models/backend/database/migrations/
- Language: TypeScript (Next.js + React)
- Responsibilities:
- UI routes/pages and app shell
- OIDC session handling and auth redirects
- GraphQL operations and cache synchronization
- Realtime subscriptions and optimistic updates
- Localization and theme/UX settings
Important paths:
web/pages/_app.tsxweb/hooks/useAuth.tsxweb/api/auth/authService.tsweb/providers/ApolloProviderWithData.tsxweb/data/web/components/layout/Page.tsxweb/utils/config.tsweb/api/graphql/web/api/gql/generated.ts(generated)web/locales/andweb/i18n/translations.ts(generated output)
- Playwright tests and config for full user-flow verification.
- Python tool to simulate realistic workflow traffic in development/testing.
From repository root:
docker compose -f docker-compose.dev.yml up -d postgres redis keycloak influxdbcd backend
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
alembic upgrade head
uvicorn main:app --reloadcd web
npm install
npm run devcd simulator
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python main.pyThese are mandatory when relevant files change:
- If any
*.graphqlfile changed inweb/:
cd web
npm run generate-graphql- If any
*.arbfile changed inweb/locales/:
cd web
npm run build-intlNever skip these steps when applicable.
Run only what is relevant to your change scope.
cd web
npm run lint
npm run check-translationscd backend
pytest tests/unit -v
pytest tests/integration -vcd tests
npm install
npx playwright testIf you cannot run a check, explicitly state what you could not run and why.
- Follow existing domain patterns.
- Prefer extending existing service/hook/provider layers over introducing parallel systems.
- Reproduce mentally or with tests.
- Fix at the narrowest reliable layer.
- Verify no regression in adjacent flows.
- Keep behavior stable.
- Make incremental commits when requested.
- Avoid mixing refactor and feature changes unless required.
- Update backend schema/resolvers/types coherently.
- Regenerate frontend GraphQL types/documents.
- Update consuming hooks/components.
Standard flow:
- Auth token/cookie extraction
- User/context hydration
- Authorization checks (location-scope)
- Resolver/service execution
- DB changes and optional audit emission
- Redis pub/sub notifications for subscribers
When changing behavior, identify which stage is affected and keep boundaries clear.
Standard flow:
- UI event from page/component
- Hook/provider mutation or query execution
- Auth header attachment
- GraphQL request over HTTP or subscription over WS
- Cache update, optimistic reconciliation, and UI refresh
When adding data access:
- Prefer existing patterns in
web/data/hooks/and current provider setup. - Keep cache consistency and subscription behavior in mind.
- Review
backend/config.pyfor canonical env contracts. - Ensure local Redis URL matches compose password settings.
- Do not hardcode environment-specific URLs in source.
- Use runtime config through
web/utils/config.ts. - Treat
RUNTIME_*values as public runtime configuration. - Keep local defaults and production runtime injection behavior intact.
- Use explicit typing where practical.
- Keep functions/components focused and reusable.
- Favor existing utility modules before adding new helpers.
- Avoid dead code, hidden side effects, and unnecessary indirection.
- Keep naming aligned with existing domain language (
task,patient,location,property,view,preset). - Do not introduce comments unless asked; write self-explanatory code.
- Inspect current git status before making edits.
- Do not revert unrelated user changes.
- Stage only files relevant to the requested task.
- Never force-push unless explicitly instructed.
- Do not amend commits unless explicitly requested.
- Do not create commits unless explicitly requested.
- Forgetting to run
npm run generate-graphqlafter GraphQL document changes. - Forgetting to run
npm run build-intlafter locale ARB changes. - Assuming auth/permissions are purely frontend concerns instead of backend-enforced.
- Breaking Redis-backed realtime paths by changing event channels without updating subscribers.
- Mixing broad refactors with urgent bug fixes in one change.
- Editing generated files directly.
README.mdbackend/main.pybackend/config.pybackend/api/context.pybackend/api/services/authorization.pybackend/api/resolvers/__init__.pybackend/database/models/web/package.jsonweb/pages/_app.tsxweb/hooks/useAuth.tsxweb/api/auth/authService.tsweb/providers/ApolloProviderWithData.tsxweb/data/client.tsweb/utils/config.ts.github/workflows/tests.yml
A task is done when:
- Requested behavior is implemented correctly.
- Relevant generation steps are completed.
- Relevant tests/lint/type checks pass (or limitations are clearly reported).
- No unrelated files are modified.
- Final handoff clearly states what changed and how it was validated.