The DB coat_type enum only accepts: smooth, double, wire, curly, long, hairless.
"short" is not a valid value — corrected to "smooth".
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Lint Roller (QA) flagged that buildPet in factories.ts was missing the
4 fields added to the pets table schema, causing TS2739 in the Docker
build job (run 1701, job 3717).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Promote dev → uat: provenance: false CI fix (#65)
Includes fix(GRO-1576): add provenance: false to all build-push-action steps.
Approved-by: The Dogfather (CTO)
fix(GRO-1576): add provenance: false to all build-push-action steps (#64)
Disables OCI attestation manifest generation that was hitting a Gitea registry bug when image layers are pre-existing.
Reviewed-by: Lint Roller (QA)
Approved-by: The Dogfather (CTO)
Docker Buildx v6 defaults to OCI attestation manifests (--attest
type=provenance,mode=max). These hit a Gitea registry bug when image
layers are pre-existing (blob mount), causing "unknown" errors on manifest
list push. API image succeeds because it pushes new layers; migrate/seed/
reset fail because their layers already exist.
Disabling provenance attestation on all four build-push-action steps
resolves the push failures. Addresses GRO-1575.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The /api/health endpoint returns 401 on UAT because authMiddleware
was not skipping it — the health check was registered on the Hono app
instance (not the api sub-router), placing it below authMiddleware on
the base app. The fix adds /api/health to the auth skip list alongside
/api/auth/.
The /health endpoint (registered at app level, above all middleware)
correctly returns 200. The /api/health endpoint must also be public
since the task requires confirming it returns 200.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Lines 108-109 were duplicates of lines 102-103 from the PR #12 merge.
Removing the duplicate pair resolves the TS1117 error on dev.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
| TC-API-1.17 | SSO redirect to Authentik | Navigate to app → sign-in page shown → click "Sign in with SSO" | Redirected to Authentik at auth.farh.net | 403 error, redirect loop, no SSO button |
| TC-API-1.18 | Authenticate with valid OIDC credentials | At Authentik login page, enter valid credentials and authenticate | Redirected back to app with valid session | Redirect loop, 403, missing session cookie |
| TC-API-1.19 | SSO user auto-provisioned as groomer | Complete SSO login as a user with no pre-existing staff record | 200 response; groomer staff record auto-created; session active | 403 Forbidden, staff record not created |
| TC-API-1.20 | Existing staff record resolves correctly | Complete SSO login as uat-groomer (pre-existing staff) | 200 OK, correct staff identity resolved, no duplicate record created | 403, duplicate record, wrong staff data |
| TC-API-1.21 | SSO session grants dashboard access | After TC-API-1.18 SSO login, GET /api/staff/me | 200 OK, valid staff record returned, correct role displayed | 401/403, missing session, wrong identity |
| TC-API-1.22 | Fresh DB reports needsSetup | On a fresh DB (no super user), GET /api/setup/status | needsSetup: true returned | needsSetup: false when it should be true |
| TC-API-1.23 | Configure OIDC via auth-provider endpoint | POST /api/setup/auth-provider with valid OIDC config | 200 OK, auth provider configured, no 403 | 403, setup blocked, invalid config rejected |
| TC-API-1.24 | Complete setup creates super user | POST /api/setup with business name (after TC-API-1.23) | First user becomes super user, setup completes | Setup errors, 403 on admin endpoints |
| TC-API-1.25 | Super user accesses admin features | After TC-API-1.24, GET /api/staff/me and verify isSuperUser: true | isSuperUser: true, admin endpoints accessible | 403 on admin, isSuperUser: false |
| TC-API-1.26 | Auto-provision skipped during OOBE | During fresh setup (needsSetup: true), complete OIDC login — verify no duplicate staff record created before setup completes | No duplicate staff, OOBE completes successfully | Duplicate staff record, 403 before setup, auto-provision interferes with OOBE |
results.push(`Pet '${uatPet.name}' already exists for UAT Customer (id: ${existing.id})`);
}else{
const[created]=awaitdb
.insert(pets)
.values({
clientId: uatClientId,
name: uatPet.name,
species: uatPet.species,
breed: uatPet.breed,
coatType: uatPet.coatTypeasany,
weightKg: uatPet.weightKg,
dateOfBirth: newDate("2019-01-01T00:00:00Z"),
})
.returning();
results.push(`Created pet '${uatPet.name}' for UAT Customer (id: ${created!.id})`);
}
}
returnc.json({
message:"Seed complete",
details: results,
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.