MK Physical Scale — Current Baseline And Caller Refresh — 2026-08-08¶

Status: CURRENT STATIC SOURCE REFRESH COMPLETE / WRITE-PATH CONTRADICTION AND ENVIRONMENT EVIDENCE REQUIRED
Process: PROC-YMS-SCALE-TICKET-EXECUTION-MK
Operating profile: mk-order
Original source baseline: qa@4f6165bc4c53a7d98b0c246392dd9ed5bd75c21c
Current review ref: qa/master@a71386e3baf176534939a42397249bcd2b535c49
Existing authority: MK_PHYSICAL_SCALE_SOURCE_AUTHORITY.md
Existing rebuild packet: MK_PHYSICAL_SCALE_CAPABILITY_REBUILD_PACKET.md
Read-only evidence package: RBR-SCALE-001-READONLY-CURRENT-SURFACE-PREFLIGHT.md
Phase implementation: USER HOLD
Effects: repository source inspection and documentation only

1. Baseline Correction¶

The cross-family drift register classified Physical Scale as having no exact source SHA. That classification is incorrect.

The existing source authority already declares:

qa@4f6165bc4c53a7d98b0c246392dd9ed5bd75c21c

This refresh independently revalidates the current owner set at a71386e....

Current result:

BASELINE MISSING:
FALSE

EXACT ORIGINAL BASELINE:
4f6165bc4c53a7d98b0c246392dd9ed5bd75c21c

CURRENT REVIEW REF:
a71386e3baf176534939a42397249bcd2b535c49

2. Exact Current Owner Set¶

Owner	Current blob	Current responsibility
`app/systems/YMS/scale/api_routes.php`	`b848c1d16fb1a8f32e3b8d806af0d1fa8b03d031`	YMS reads, integrated Check-in, Check-out, finalize, walk-in and delete routes
`app/systems/YMS/scale/query_handler.php`	`129b05fc78182f74f9a1bbbf025b207607375300`	YMS Scale read dispatch
`app/systems/OMS/inbound-order/mk_query_helper.php`	`1d449a7bd0bbd236280e81833a597de500bdb9ae`	Schedule, ticket and order-side read models
`app/systems/OMS/inbound-order/mk_post_helper.php`	`cf05b7096ef46b8215c2a8c9f9d13e4dba9bae00`	Scale stage/event/link/finalize and shared MK writes
`app/systems/OMS/outbound-order/post_handler.php`	`92000475f78f6a64a6d3b1f1e3d7f1c6c81cd39e`	Outbound Save used by integrated Check-in
`frontend/pages/system/YMS/scale/scale-portal.php`	`1c526ab2d9aa9251fdb1a7fa8a4694fc31dc97f3`	Scale Portal shell/live display placeholder
`public/assets/js/modules/yms/scale-portal.js`	`cc01b3f94ece2c61f9aaa26073cd63dbe9447bc0`	flow schema, UI orchestration, timeout and recovery messaging
`app/systems/BMS/scale-ticket/api_routes.php`	`5993d5d3b4b4200cea1e6558786a6bb462f6c2d3`	generic BMS ticket create/read/update/delete/closing/outbound apply
`app/systems/BMS/scale-ticket/post_handler.php`	`e0e6331a4f46e11f19181f33c6faca5e9fb22ad2`	BMS scale-ticket action dispatch

The core YMS route and Scale Portal JS blobs are byte-identical to the original 4f6165... baseline. The unresolved stage-direction contradiction documented at that baseline therefore remains present in current static source.

app/systems/BMS/transaction/post_helper.php changed after the baseline only in the reviewed Street Turn compensation block. The Scale-ticket update/delete block remains materially unchanged in targeted review.

3. Current YMS Scale Routes¶

Read¶

GET /api/yms/scale/schedule
GET /api/yms/scale/tickets?OPEN_ONLY=1
GET /api/yms/scale/tickets/{id}
GET /api/yms/scale/tickets/{id}/events

Current route metadata:

moduleKey = yms.scale
requiredMenuRoutes = scale-portal

Write¶

POST   /api/yms/scale/check-in
PATCH  /api/yms/scale/check-in
POST   /api/yms/scale/check-out
POST   /api/yms/scale/purchase-inbound/finalize
POST   /api/yms/scale/purchase-inbound/walk-in
POST   /api/yms/scale/check-in/execute
DELETE /api/yms/scale/tickets/{id}

All current YMS write callbacks execute through apiRouteRunLegacyWrite().

This provides a local transaction around each individual API request. It does not make a browser sequence of several API requests one transaction.

4. Current Integrated Check-In¶

Current route:

POST /api/yms/scale/check-in/execute

Current server sequence:

validate FLOW and commodity rows
-> create/update Purchase or Sales order and items
-> force ticket WEIGHT_PREFIX = GROSS
-> aggregate item Gross into GROSS_STEERING_WEIGHT
-> create/update Scale ticket through SCALE_IN
-> bind ticket through the owning MK helper
-> return order and ticket identities
-> commit once

The order and first ticket stage are one local transaction for this request.

Current accepted flow inputs¶

DOORTRADE
PURCHASE
SALES
EXPORT

Current forced first stage¶

GROSS for every accepted flow

This is source fact, not accepted product policy.

5. Persistent Stage-Direction Contradiction¶

The current Scale Portal flow schema expects:

Flow	UI first stage	UI second stage
Doortrade	Gross	Tare
Purchase	Gross	Tare
Sales	Tare	Gross
Export	Tare	Gross
Other/Walk-In default	Tare	Gross

But integrated Check-in forces Gross for every flow.

Therefore the current static contradiction remains:

Sales/Export Check-in writes Gross
while
Sales/Export board/checkout expects Tare first

Potential effects requiring controlled current evidence:

Sales/Export ticket omitted from expected active board state;
ticket shown under an unexpected stage;
Check-out refusing the expected second stage;
operator label and stored data disagreement;
static contract assertions preserving the contradiction.

Current disposition:

SCALE-DISCREPANCY-001
= CURRENT STATIC SOURCE CONTRADICTION CONFIRMED
= RUNTIME OCCURRENCE NOT RUN
= FIELD INCIDENT NOT ESTABLISHED
= WRITE-PATH ACTIVATION BLOCKER

Do not change the direction based only on this document. Four-flow fixture and downstream evidence are required.

6. Current Check-Out Boundaries¶

The current browser Check-out is a sequence, not one business transaction.

header PATCH
-> zero or more item PATCH/POST calls
-> POST /api/yms/scale/check-out
-> Sales/Export outbound close/update
-> Purchase/Doortrade branch or finalization

Each API request can commit independently.

Possible partial states:

header changed / item failed
items changed / scale-out failed
scale-out committed / outbound close failed
scale-out committed / purchase finalize pending

Recovery must identify the last committed owner boundary and resume only the missing step.

7. Ticket State And Event Lineage¶

Current ticket lifecycle is derived from:

GROSS_TIME and Gross weights
TARE_TIME and Tare weights
DELETED_AT

Current event table:

T_SCALE_TICKET_EVENT

Current event/read fields include:

EVENT_TYPE
WEIGHT_PREFIX
INPUT_UOM / CANONICAL_UOM / DISPLAY_UOM
before/after stage time
before/after axle weights
REASON_TEXT
ACTOR_USER_ID / ACTOR_USERNAME
REQUEST_ID
CREATED_AT

Current YMS helper supports:

identical same-stage retry returning the existing result;
pre-checkout reweigh with required reason;
compare-and-swap stage update;
append-only correction event;
duplicate second-stage identical result handling;
changed completed-stage replay rejection;
reasoned void/reversal event;
downstream execution guard;
transactional link detachment when reversal is allowed.

No environment evidence has yet proved event schema installation, current row population or every writer path.

8. Competing BMS Write Surface¶

Current BMS routes:

POST   /api/bms/scale-tickets
GET    /api/bms/scale-tickets/{id}
PATCH  /api/bms/scale-tickets/{id}
DELETE /api/bms/scale-tickets/{id}
POST   /api/bms/scale-tickets/closing
POST   /api/bms/scale-tickets/outbound-weight-apply
GET    /api/bms/scale-tickets/history

Current route module:

bms.scale-ticket

The generic BMS update/delete path uses transaction helper functions that do not apply the complete YMS stage/event/downstream-reversal contract.

Current risk:

same T_SCALE_TICKET family
+ two module/route owners
+ different update/delete semantics
= correction/reversal authority conflict

This conflict remains current and must be resolved before one-writer migration.

9. Current Page And Output Callers¶

Operational portal¶

?page=scale-portal
frontend/pages/system/YMS/scale/scale-portal.php
public/assets/js/modules/yms/scale-portal.js

Physical ticket output¶

frontend/pages/system/BMS/scale-ticket/scaleticket.php?IDS[]=...

This path is the current physical ticket output and uses tenant/active-row predicates and page-role access in the reviewed source.

Sales weight projection¶

frontend/pages/system/BMS/scale-ticket/scaleticket.php?ORDER_ID=...

This is an order projection, not physical ticket evidence.

Current live-weight display¶

00000 lb

No current repository source establishes a durable physical-device adapter, authenticated reading, device session, serial/scale feed, polling contract or signed evidence.

10. Current Role And Access Questions¶

YMS Scale routes declare:

moduleKey = yms.scale
requiredMenuRoutes = scale-portal

BMS Scale routes declare:

moduleKey = bms.scale-ticket

Current evidence still must establish:

which roles may use integrated Check-in;
which roles may Check-out and finalize;
which roles may reweigh, reverse or delete;
whether BMS generic writers are visible/reachable to the same roles;
whether physical ticket output role parity matches YMS operations;
Client 1 non-regression and Client 2 expected MK behavior.

Candidate target actions:

yms.scale.check-in
yms.scale.check-out
yms.scale.correct
yms.scale.reverse
yms.scale.finalize-purchase
bms.scale-ticket.read-history

These are documentation input only.

11. Current Evidence Required¶

Evidence owner:

RBR-SCALE-001

Four-flow fixture¶

Purchase: Gross -> Tare
Doortrade: Gross -> Tare
Sales: Tare -> Gross
Export: Tare -> Gross

For each flow record:

exact order/ticket/link IDs;
displayed expected stage;
stored first stage;
board presence;
second-stage acceptance;
downstream order/finalization result;
cleanup and reversal.

Schema/data¶

ticket/event columns/indexes;
active link integrity;
completed/open classification;
event lineage;
YMS/BMS writer evidence;
soft-deleted/reversed link state.

Role/UI¶

menu/page/API parity;
intended and denied roles;
direct route behavior;
mobile/keyboard behavior;
output page access.

Physical/device¶

actual device/interface inventory;
reading source and unit;
calibration/ownership;
loss/reconnect behavior;
signed/manual-entry distinction.

No physical effect is authorized by this document.

12. Target Migration Boundary¶

The future target must have one accepted Scale command authority.

React Scale Workspace
-> Next.js validated adapter
-> TypeScript Scale Application
-> Scale Policy
-> Ticket/Event repositories
-> approved Device Adapter
-> MySQL transaction

The target must not:

preserve conflicting first-stage rules;
keep YMS and BMS as independent writers;
treat browser print as execution evidence;
invent a live device adapter from the placeholder display;
dual-write PHP and TypeScript;
start PostgreSQL before one-writer/rollback/caller-zero.

13. Current Conclusion¶

Original exact baseline:
CONFIRMED

Current owner/caller inventory:
REFRESHED

Core YMS source drift:
NO MATERIAL DRIFT LOCATED

Stage-direction contradiction:
PERSISTS IN CURRENT STATIC SOURCE

YMS/BMS competing writers:
PERSISTS

Physical device contract:
NOT ESTABLISHED

Current DB/role/runtime/physical evidence:
NOT RUN

M3:
NO

M4:
NO

Phase progress:
NONE

---¶

Source: docs/reconstruction/MK_PHYSICAL_SCALE_CURRENT_BASELINE_AND_CALLER_REFRESH_2026-08-08.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.