112 lines
3.7 KiB
Markdown
112 lines
3.7 KiB
Markdown
# NEXT STEPS
|
|
|
|
This file is the implementation order from the current scaffold state.
|
|
|
|
## 1. Start Here: Lock API contracts first
|
|
|
|
Create a short API contract document before writing more feature code.
|
|
|
|
1. Define request/response payloads for:
|
|
- `POST /v1/auth/register`
|
|
- `POST /v1/auth/login`
|
|
- `POST /v1/auth/refresh`
|
|
- `POST /v1/auth/logout`
|
|
- `GET/POST/PATCH/DELETE` for groups, characters, rulesets
|
|
2. Define shared error schema and status code rules.
|
|
3. Decide role model now:
|
|
- global roles (from `cm_users`)
|
|
- campaign/group roles (service/domain-level)
|
|
|
|
Done when:
|
|
- All endpoints have stable JSON schema examples.
|
|
- Web + symbiote can be implemented against the same contract.
|
|
|
|
## 2. Implement Auth Core in `campaign-service`
|
|
|
|
Use `cm_users` as the auth source of truth (no extra auth service needed now).
|
|
|
|
1. Implement registration with `argon2` password hashing.
|
|
2. Implement login with password verification.
|
|
3. Persist refresh sessions in `refresh_sessions` table.
|
|
4. Return JWT access token + refresh token flow.
|
|
5. Add middleware/helper for auth context extraction.
|
|
|
|
Done when:
|
|
- Register/login/refresh/logout are fully working against Postgres.
|
|
- `content-service` accepts tokens issued by `campaign-service`.
|
|
|
|
## 3. Add migration runner + startup checks
|
|
|
|
1. Add migration execution command/process for both services.
|
|
2. Ensure services fail fast on invalid DB config.
|
|
3. Add health/readiness checks that include DB connectivity.
|
|
|
|
Done when:
|
|
- Fresh database can be initialized and migrated with one command path.
|
|
- Service startup gives clear errors if DB/env is wrong.
|
|
|
|
## 4. Implement `content-service` ruleset management
|
|
|
|
1. Replace stubbed ruleset list with DB-backed queries.
|
|
2. Add create/update/deactivate ruleset endpoints.
|
|
3. Enforce auth + authorization checks.
|
|
|
|
Done when:
|
|
- Rulesets are fully CRUD-capable with audit fields.
|
|
- API behaves correctly for authorized vs unauthorized users.
|
|
|
|
## 5. Implement `campaign-service` domain features
|
|
|
|
1. Build group endpoints (create/list/update membership).
|
|
2. Build character endpoints and ownership rules.
|
|
3. Add campaign/group role enforcement.
|
|
|
|
Done when:
|
|
- Core campaign management flow works end-to-end.
|
|
- Permissions are enforced at API level.
|
|
|
|
## 6. Wire web app flows to real APIs
|
|
|
|
1. Replace placeholder UI interactions with real API calls.
|
|
2. Implement login/logout/session refresh UX.
|
|
3. Add basic error handling and loading states for all core pages.
|
|
|
|
Done when:
|
|
- User can sign in, manage rulesets, groups, and characters through the web app.
|
|
|
|
## 7. Integrate symbiote MVP
|
|
|
|
1. Implement token/bootstrap handoff strategy from campaign backend.
|
|
2. Add minimal read/use flow needed inside TaleSpire.
|
|
3. Validate it with real campaign and ruleset data.
|
|
|
|
Done when:
|
|
- Symbiote performs one complete gameplay-relevant flow against live backend data.
|
|
|
|
## 8. Testing and CI hardening
|
|
|
|
1. Add integration tests for auth flows and permission checks.
|
|
2. Add API-level tests for rulesets/groups/characters.
|
|
3. Keep `pnpm ci:local` green and mirror same checks in Woodpecker.
|
|
|
|
Done when:
|
|
- Critical flows are covered by automated tests.
|
|
- CI failures are actionable and reproducible locally.
|
|
|
|
## 9. Kubernetes readiness pass
|
|
|
|
1. Add production env var matrix and secret mapping.
|
|
2. Add image/tag strategy for first release pinning.
|
|
3. Add readiness/liveness probes and resource requests/limits.
|
|
|
|
Done when:
|
|
- Services can be deployed to your cluster with the same topology as local dev.
|
|
|
|
## Suggested first implementation chunk (next PR)
|
|
|
|
1. Contract doc for auth + rulesets.
|
|
2. Full register/login/refresh/logout in `campaign-service`.
|
|
3. `content-service` token validation test against real JWT secret.
|
|
|
|
If you do only one thing first, do auth end-to-end; everything else depends on it.
|