Box Styles / FEFCO 0430 approved
How a dieline gets built and improved (the loop)
- Save test dims (panel 1) at the size you have a reference for. Everything below runs at these dims.
- Upload a reference (panel 5): a Pacdora DXF/PDF export, or a die maker's file. Pick the source — die-maker outranks Pacdora. The file is kept (⬇ file) and measured; if the style already has a generator, the report diffs the two.
- Ask Claude for the generator or the tuning. Paste this into a Claude Code session in
~/Web/rollfed-symfony:Claude pulls the file from this page, writes or adjusts the style indieline: FEFCO 0430 — build or tune the generator from the latest reference on its bench, render it, run the goldens, push dieline dev, and tell me what the diff against the reference says.
voom-dieline(code = this style's code), checks the flat size and a rendered PNG, runs the test suite, and pushesdev. Coolify rebuilds the service on Q within a few minutes. - Reload this page. An unbound style binds itself to the new generator by code (green flash, SERVICE in the header). The preview, mechanics panel and exports then come from the service.
- Upload the reference again to get the comparison; repeat step 3 with what it says until the diff is noise. Move to testing.
- Cut it. Export the DXF, cut and fold it on real board, record the result in Test notes, then approve. Only approved styles are quotable in the calculator.
Something looks wrong in the die? Two ways, use both:
- Tune it yourself first in panel 1b (Style options): glue flap, tuck depth, lock fractions… the preview follows as you type. When it looks right, Save as default — Claude bakes those values in as the style's defaults.
- Say what is wrong in panel 6 (Feedback). Mechanical terms work best: which flap, which edge, too deep / too shallow / won't clear / missing crease / wrong side, and at what dims (they are captured automatically). Then hand Claude:
dieline: FEFCO 0430 — fix the open feedback on its bench (and the saved style options), render it, run the goldens, push dieline dev, mark each item done with what changed.
A new style starts with a generator written from the reference (step 3), not from the upload alone; the upload teaches proportions to a generator that exists. Full write-up:
docs/PACKAGING_DIELINE_LOOP.md.
Workflow
draft → testing → approved = physical DXF test cut folds correctly. Record the cut in test notes before sign-off.
1 · Test dimensions
1b · Style options
— the generator's own knobs; preview follows as you type; Save as default keeps them
loading…
2 · Dieline preview
Service SVG — Pacdora colours (bleed green · cut blue · crease red) for overlay diffs
Loading…
3 · 3D fold check
Open Closed
4 · Files for physical test cut
Cut the DXF for real → record result in test notes → approve.
5 · Reference dielines (calibration corpus)
Upload a Pacdora export or a die maker's DXF/PDF at the CURRENT test dims.
The dieline service measures it, compares it against our generator, and stores
the report here. A few references per style is plenty — die-maker files
outrank Pacdora when rules get tuned; every change still ends in a test cut.
medicine_box_200×127×50_mm.pdf pacdora ✓ LLM done 07 Jul 2026 23:23
# Reference ingestion — medicine_box_200x127x50_mm
Source class: **pacdora** (die_maker outranks pacdora when rules are tuned)
## Reference measurements
```json
{
"blank_w_mm": 678.0,
"blank_h_mm": 352.5,
"panel_scores_x": [
25.0,
225.0,
352.0,
552.0
],
"panel_widths": [
200.0,
127.0,
200.0
],
"body_scores_y": [
25.0,
150.0,
152.0,
200.0,
202.0,
327.0
],
"cut_arc_radii": {},
"bleed_offset_mm": 5.0,
"dim_table": {
"inside": "198(L) \u00d7 125(W) \u00d7 46.5(H) mm",
"outside": "201(L) \u00d7 128(W) \u00d7 52.5(H) mm",
"manufacture": "200(L) \u00d7 127(W) \u00d7 50(H) mm",
"material": "E-flute",
"thickness": "1.5 mm",
"design_area": "678 \u00d7 352.5 mm"
},
"notes": [
"PDF; 152 colour-classified segs (clipped to blank); text keys: ['inside', 'outside', 'manufacture', 'material', 'thickness', 'design_area']"
]
}
```
## Comparison vs voom-dieline
| metric | reference | ours | delta |
|---|---|---|---|
| blank_w_mm | 678 | 678 | +0.00 |
| blank_h_mm | 352.5 | 352.5 | +0.00 |
| panel_widths | [200.0, 127.0, 200.0] | [200.0, 127.0, 200.0] | — |
| body_scores_y | [25.0, 150.0, 152.0, 200.0, 202.0, 327.0] | [25.0, 150.0, 152.0, 200.0, 202.0, 328.0] | DIFFERS |
| cut_arc_radii | {} | {13.0: 4, 52.6: 4, 1.5: 4} | DIFFERS |
| bleed_offset_mm | 5 | 5 | +0.00 |
### Rules our generator applied
- panel_widths: corrugated shrink_last: [200.0, 127.0, 200.0, 126.0] — free-edge panel −(2/3)t (measured Pacdora 0430 @t=1.5)
- lid_depth: w−t = 125.50 — tuck crease lands at D+W above the far hinge (measured exact)
- dust_hinge_offset: dust hinges 1.50 inside the lid hinges — flaps fold under the lid board
- tuck_shoulder_slit: 8mm land + r=1.5 drop + 1.5 undercut — tuck inset 11.0/side
- dust_depth: 76.2 = 0.6·w — straight side clears the lid wall by 3.5, far side swept (r≈0.73·chord)
- glue_tab: 25mm on the front panel's outer edge, 15° taper, spans the dust band (d−t)
- crease_vs_knife: creases only where hinges exist; tuck creases start where the shoulder slits end
## LLM analysis (DRAFT — gated by human review + test cut)
### 1. Style Identification (FEFCO/ECMA Code Family)
Based on the measurements, this dieline appears to be a **FEFCO 0201** style box. This is a standard regular slotted container (RSC) with a single corrugated wall and a tuck-in lid.
### 2. Engineering Differences That Matter
- **Panel Widths**: The reference uses `panel_widths = [200.0, 127.0, 200.0]`, while the generator applies a shrink policy to the last panel: `[200.0, 127.0, 200.0, 126.0]`. The reference does not apply this shrinkage.
- **Body Scores Y**: The reference has `body_scores_y = [25.0, 150.0, 152.0, 200.0, 202.0, 327.0]`, while the generator has `[25.0, 150.0, 152.0, 200.0, 202.0, 328.0]`. The difference is in the last score (327.0 vs 328.0).
- **Cut Arc Radii**: The reference has no cut arc radii, while the generator includes `cut_arc_radii = {13.0: 4, 52.6: 4, 1.5: 4}`.
- **Tuck Inset**: The reference does not specify a tuck inset, but the generator applies an 11.0 mm inset per side.
### 3. Concrete Rule-Change Hypotheses
#### Panel Widths
- **Hypothesis**: The die maker prefers no shrinkage on the last panel.
- **Confidence**: High (95%)
- **Test**: Cut a test dieline with `panel_widths = [200.0, 127.0, 200.0]` and compare the fit of the assembled box.
#### Body Scores Y
- **Hypothesis**: The reference's last score at 327.0 mm is intentional.
- **Confidence**: Medium (80%)
- **Test**: Cut a test dieline with `body_scores_y = [25.0, 150.0, 152.0, 200.0, 202.0, 327.0]` and check if the box assembles correctly.
#### Cut Arc Radii
- **Hypothesis**: The reference does not use cut arc radii, which might be a preference or an oversight.
- **Confidence**: Medium (75%)
- **Test**: Cut a test dieline with no cut arc radii and compare the ease of assembly and appearance.
#### Tuck Inset
- **Hypothesis**: The tuck inset is not necessary for this design.
- **Confidence**: Low (60%)
- **Test**: Cut a test dieline without the tuck inset and check if the tuck flap still functions correctly.
### 4. Questions to Ask the Die Maker
1. **Panel Widths**: Do you prefer no shrinkage on the last panel, or is the shrink policy `[200.0, 127.0, 200.0, 126.0]` acceptable?
2. **Body Scores Y**: Is the difference in the last score (327.0 vs 328.0) significant for assembly and fit?
3. **Cut Arc Radii**: Do you have a preference for using cut arc radii, or is it unnecessary for this design?
4. **Tuck Inset**: Is the tuck inset of 11.0 mm per side necessary, or can we omit it without affecting functionality?
5. **General Feedback**: Are there any other specific preferences or adjustments you would recommend based on your experience with similar designs?
_model: qwen2.5:72b_
6 · Feedback — what is wrong with this die
One problem per note, in mechanical terms (which flap / edge, too deep or shallow, won't clear, missing crease,
wrong side). The current dims and style options are attached automatically. Stays open until the fix lands.