SlabUploader

Ty_Tech/SlabUploader

Fork 0

Commit Graph

Author	SHA1	Message	Date
Ty	e5afc7524b	fix(fe): upload slab photos to the server before publish ensureServerSlab sent calibration_photo_id at create, but slab_photos rows are only created by POST /slabs/{id}/photos, which the frontend never called - so the INSERT hit FOREIGN KEY (calibration_photo_id REFERENCES slab_photos(id)) and every create failed with a generic 400, blocking the whole create->publish walk. - stop sending calibration_photo_id at create - upload every draft photo (original + processed PNG) right after the slab row exists, via new review/photoUpload.ts (multipart FormData, same error envelope so failures surface through fail(e)) - link calibration_photo_id in the existing review PUT, once the row exists - extract the role rule into lineup.photoRole() so the review strip and the uploader cannot disagree	2026-09-25 12:14:35 -07:00
Ty	49c22c9385	feat(greenfield): rebuild SlabUploader M1-M3 on clean foundation, all gates green Clean re-implementation of the full product (not a port of the old M3 tree): - P0 foundation: 13-table schema + per-call sqlite factory (thread-safe), FastAPI app (health, JSON logging + secret redaction, CORS, startup guard). - P1 M1 Capture: mask/sheetKeep, geometry/rect (min-area rect), measure, png crop/inventory/overlay, EXIF decodeOrientedBitmap. - P2 M2 Photos: stateful capture session (batch, pick-cal, apply mask/crop to batch) + photos-ready lineup. - P3 M3 Create: real backend (crypto, woo client, taxonomy sync, pricing, inference Call1/Call2, review, publish, settings, slabs, photos) + real FE review/publish/settings screens consuming the API (no hardcoded Woo ids). - P4 gate exit: check_requirements + check_coverage both exit 0 (137/155 IDs, 0 gaps); backend 130/130, frontend 150/150, build green. Cite: docs/REQUIREMENTS.md (155 rows), docs/MILESTONES.md M1-M3.	2026-09-25 06:57:29 -07:00

Author

SHA1

Message

Date

e5afc7524b

fix(fe): upload slab photos to the server before publish

ensureServerSlab sent calibration_photo_id at create, but slab_photos rows are
only created by POST /slabs/{id}/photos, which the frontend never called - so
the INSERT hit FOREIGN KEY (calibration_photo_id REFERENCES slab_photos(id))
and every create failed with a generic 400, blocking the whole create->publish
walk.

- stop sending calibration_photo_id at create
- upload every draft photo (original + processed PNG) right after the slab row
  exists, via new review/photoUpload.ts (multipart FormData, same error
  envelope so failures surface through fail(e))
- link calibration_photo_id in the existing review PUT, once the row exists
- extract the role rule into lineup.photoRole() so the review strip and the
  uploader cannot disagree

2026-09-25 12:14:35 -07:00

49c22c9385

feat(greenfield): rebuild SlabUploader M1-M3 on clean foundation, all gates green

Clean re-implementation of the full product (not a port of the old M3 tree):
- P0 foundation: 13-table schema + per-call sqlite factory (thread-safe),
  FastAPI app (health, JSON logging + secret redaction, CORS, startup guard).
- P1 M1 Capture: mask/sheetKeep, geometry/rect (min-area rect), measure,
  png crop/inventory/overlay, EXIF decodeOrientedBitmap.
- P2 M2 Photos: stateful capture session (batch, pick-cal, apply mask/crop
  to batch) + photos-ready lineup.
- P3 M3 Create: real backend (crypto, woo client, taxonomy sync, pricing,
  inference Call1/Call2, review, publish, settings, slabs, photos) + real FE
  review/publish/settings screens consuming the API (no hardcoded Woo ids).
- P4 gate exit: check_requirements + check_coverage both exit 0
  (137/155 IDs, 0 gaps); backend 130/130, frontend 150/150, build green.

Cite: docs/REQUIREMENTS.md (155 rows), docs/MILESTONES.md M1-M3.

2026-09-25 06:57:29 -07:00

2 Commits