Ty_Tech/SlabUploader
6
0
Fork 0
Code Issues 15 Pull Requests Actions Packages Projects Releases Wiki Activity

Bug: Call 1 + human lock of taxonomy must complete before deterministic title/short desc #89

New Issue
Closed
opened 2026-09-21 06:10:24 +00:00 by Ty · 1 comment
Ty commented 2026-09-21 06:10:24 +00:00
Owner
Copy Link
Copy Source

Summary

Scope is Call 1 (vision taxonomy) and the human review of those results — not Call 2.

Flow that must work:

  1. Call 1 proposes AI-assisted taxonomy (species, wood categories, edge, figure, feat-* tags, etc.).
  2. Human reviews those suggestions on the Review screen (accept, edit, fill owner-only fields such as grade).
  3. Owner locks the confirmed metadata (persisted on the slab).
  4. Only after that lock may the server set title and short_description from the deterministic patterns (METADATA-80 / REVIEW-10).

Today the UI does not give a clear lock path after Call 1 review, so the metadata required for patterns never lands as the confirmed set, and title/short_description stay empty.

This is not about Call 2 long-description generation. Title and short_description never come from a model.

Observed (HEAD main @ 41401a7)

  • Review.svelte runInference() applies Call 1 suggestions into local state, then commitReview().
  • commitReview() PUTs fields and POSTs /review.
  • backend/review.py assembles title/short_description only when species + primary wood category resolve from stored slab data, and only when the owner has not already supplied those prose fields.
  • After Call 1, the human has no explicit lock / confirm taxonomy step that:
    • persists the reviewed Call 1 results (plus owner-required fields still missing from Call 1), and
    • then triggers deterministic title + short_description from that locked set.
  • Title/short_description inputs stay blank; assembly either never runs on a complete locked set, or review response values are not applied into the UI after lock.

Spec

  • METADATA-35 / 40 / 45: Call 1 proposes constrained taxonomy; ≥ threshold pre-fills; always editable by the owner.
  • METADATA-50: Typed / owner values win over inferred.
  • REVIEW-15: Owner declares primary wood category (default first selected); primary drives title patterns.
  • METADATA-80 / 85 / REVIEW-10: Server assembles name and short_description from the confirmed listing facts + primary category patterns + dimension fact block — never from the model.
  • Call 2 (METADATA-55+) is separate: long description only, and it should consume metadata already confirmed in review.

Expected behavior

  1. Call 1 runs → suggestions appear on Review with AI badges as today.
  2. Human reviews/edits Call 1 results and completes owner-only required taxonomy (e.g. grade; moisture default; thickness band per deterministic rule — see #88).
  3. Human locks that metadata (explicit confirm/save of the taxonomy set — not a silent half-commit that leaves prose empty).
  4. After lock only: server builds and stores title + short_description; UI shows them.
  5. Further taxonomy edits after lock either re-lock or re-assemble per product rules; owner prose overrides still win once the owner has edited title/short_desc.
  6. Call 2 / Generate text remains a later, separate action on locked metadata.

Acceptance

  • Issue/docs and UI copy make the sequence unmistakable: Call 1 → human review → lock metadata → then title & short_description.
  • Until lock, title and short_description are not set (or clearly shown as pending lock) — no false “ready” prose from unlocked AI drafts.
  • After lock with species + primary wood category (+ pattern inputs), title and short_description are populated deterministically and visible in the Review fields.
  • GET slab after lock shows stored title/short_description matching METADATA-80 patterns.
  • Call 2 is not required for title/short_desc; this bug is fixed without relying on Generate text.
  • E2E: Call 1 → human edit/confirm → lock → assert title & short_description; live UAT on deployed stack.
  • Independent issue from #88 (thickness band control); may interact only insofar as band is part of the locked set.

Type

bug · M3 Review · Call 1 → human lock → deterministic copy

## Summary **Scope is Call 1 (vision taxonomy) and the human review of those results — not Call 2.** Flow that must work: 1. **Call 1** proposes AI-assisted taxonomy (species, wood categories, edge, figure, feat-* tags, etc.). 2. **Human reviews** those suggestions on the Review screen (accept, edit, fill owner-only fields such as grade). 3. Owner **locks** the confirmed metadata (persisted on the slab). 4. **Only after that lock** may the server set **title** and **short_description** from the deterministic patterns (METADATA-80 / REVIEW-10). Today the UI does not give a clear lock path after Call 1 review, so the metadata required for patterns never lands as the confirmed set, and title/short_description stay empty. This is **not** about Call 2 long-description generation. Title and short_description never come from a model. ## Observed (HEAD `main` @ 41401a7) - `Review.svelte` `runInference()` applies Call 1 suggestions into local state, then `commitReview()`. - `commitReview()` PUTs fields and POSTs `/review`. - `backend/review.py` assembles title/short_description only when species + primary wood category resolve from stored slab data, and only when the owner has not already supplied those prose fields. - After Call 1, the human has no explicit **lock / confirm taxonomy** step that: - persists the reviewed Call 1 results (plus owner-required fields still missing from Call 1), and - then triggers deterministic title + short_description from that locked set. - Title/short_description inputs stay blank; assembly either never runs on a complete locked set, or review response values are not applied into the UI after lock. ## Spec - **METADATA-35 / 40 / 45**: Call 1 proposes constrained taxonomy; ≥ threshold pre-fills; always editable by the owner. - **METADATA-50**: Typed / owner values win over inferred. - **REVIEW-15**: Owner declares primary wood category (default first selected); primary drives title patterns. - **METADATA-80 / 85 / REVIEW-10**: Server assembles name and short_description from the **confirmed** listing facts + primary category patterns + dimension fact block — never from the model. - **Call 2** (METADATA-55+) is separate: long description only, and it should consume metadata **already confirmed in review**. ## Expected behavior 1. Call 1 runs → suggestions appear on Review with AI badges as today. 2. Human reviews/edits Call 1 results and completes owner-only required taxonomy (e.g. grade; moisture default; thickness band per deterministic rule — see #88). 3. Human **locks** that metadata (explicit confirm/save of the taxonomy set — not a silent half-commit that leaves prose empty). 4. **After lock only**: server builds and stores title + short_description; UI shows them. 5. Further taxonomy edits after lock either re-lock or re-assemble per product rules; owner prose overrides still win once the owner has edited title/short_desc. 6. Call 2 / Generate text remains a later, separate action on locked metadata. ## Acceptance - [ ] Issue/docs and UI copy make the sequence unmistakable: **Call 1 → human review → lock metadata → then title & short_description**. - [ ] Until lock, title and short_description are not set (or clearly shown as pending lock) — no false “ready” prose from unlocked AI drafts. - [ ] After lock with species + primary wood category (+ pattern inputs), title and short_description are populated deterministically and visible in the Review fields. - [ ] GET slab after lock shows stored title/short_description matching METADATA-80 patterns. - [ ] Call 2 is not required for title/short_desc; this bug is fixed without relying on Generate text. - [ ] E2E: Call 1 → human edit/confirm → lock → assert title & short_description; live UAT on deployed stack. - [ ] Independent issue from #88 (thickness band control); may interact only insofar as band is part of the locked set. ## Type bug · M3 Review · Call 1 → human lock → deterministic copy
Ty changed title from Bug: after AI inference, title and short description stay empty — Review flow never saves metadata needed to assemble them to Bug: Call 1 + human lock of taxonomy must complete before deterministic title/short desc 2026-09-21 06:11:42 +00:00
grokbot_ty commented 2026-09-21 19:59:55 +00:00
Owner
Copy Link
Copy Source

Closed by M3 Option A: main 0c00d25 + UAT QUALITY-110 evidence.

  • Deploy: version 0.5.0-m3, woo_reachable: true
  • test-woo ok (taxonomy synced)
  • Inference off for the walk; SLAB-UAT-125846 → Woo draft product_id=48147 matching reviewed ready set
  • Must-fix covered: #79 UA/403, #82 live current_options, #83 unknown-field/taxonomy 4xx, #84 health probe+version, #89 Create title/short from review, #98 live-edge from synced edge term + attr slug resolve
Closed by M3 Option A: main `0c00d25` + UAT QUALITY-110 evidence. - Deploy: version `0.5.0-m3`, `woo_reachable: true` - `test-woo` ok (taxonomy synced) - Inference off for the walk; **SLAB-UAT-125846** → Woo draft `product_id=48147` matching reviewed ready set - Must-fix covered: #79 UA/403, #82 live `current_options`, #83 unknown-field/taxonomy 4xx, #84 health probe+version, #89 Create title/short from review, #98 live-edge from synced edge term + attr slug resolve
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocking
Blocks POC acceptance; must be resolved before merge
 docs
Documentation change required
 gate-b
Gate B sprint issue
 gate-c
Gate C sprint issue
 gc-seq-01
Serial order 01/6 in Gate C sprint
 gc-seq-02
Serial order 02/6 in Gate C sprint
 gc-seq-03
Serial order 03/6 in Gate C sprint
 gc-seq-04
Serial order 04/6 in Gate C sprint
 gc-seq-05
Serial order 05/6 in Gate C sprint
 gc-seq-06
Serial order 06/6 in Gate C sprint
 poc
POC post-Gate-C issue
 poc-seq-01
Serial order 01 in POC sprint
 poc-seq-02
Serial order 02 in POC sprint
 poc-seq-03
Serial order 03 in POC sprint
 poc-seq-04
Serial order 04 in POC sprint
 poc-seq-05
Serial order 05 in POC sprint
 poc-seq-06
Serial order 06 in POC sprint
 poc-seq-07
Serial order 07 in POC sprint
 poc-seq-08
Serial order 08 in POC sprint
 poc-seq-09
Serial order 09 in POC sprint
 poc-seq-10
Serial order 10 in POC sprint
 poc-seq-11
Serial order 11 in POC sprint
 poc-seq-12
Serial order 12 in POC sprint
 poc-seq-13
Serial order 13 in POC sprint
 poc-seq-14
Serial order 14 in POC sprint
 poc-seq-15
Serial order 15 in POC sprint
 poc-seq-16
Serial order 16 in POC sprint
 poc-seq-17
Serial order 17 in POC sprint
 poc-seq-18
Serial order 18 in POC sprint
 poc-seq-19
Serial order 19 in POC sprint
 poc-seq-20
Serial order 20 in POC sprint
 post-launch
Deferred to post-launch / V1.5+
 seq-01
Serial order 1/10 in Gate B sprint
 seq-02
Serial order 2/10 in Gate B sprint
 seq-03
Serial order 3/10 in Gate B sprint
 seq-04
Serial order 4/10 in Gate B sprint
 seq-05
Serial order 5/10 in Gate B sprint
 seq-06
Serial order 6/10 in Gate B sprint
 seq-07
Serial order 7/10 in Gate B sprint
 seq-08
Serial order 8/10 in Gate B sprint
 seq-09
Serial order 9/10 in Gate B sprint
 seq-10
Serial order 10/10 in Gate B sprint
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
HA_Architect HA_Researcher Ty grokbot_ty grokbuild_ty tonyjbala (Tony Balascio)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Ty_Tech/SlabUploader#89
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?