Skip to content

MK Trade / Allocation / Physical Scale — Post-Refresh Release And QA Delta — 2026-08-09

  • Status: CURRENT STATIC SOURCE DELTA / RELEASE AND INTEGRATION AUTHORITIES SEPARATED
  • Previous detailed refresh: qa/master@a71386e3baf176534939a42397249bcd2b535c49
  • Previous documentation promotion: 40fb4020e2993347eb7cde9cb24ee9f6201cd806
  • Released source authority: master@baff406d964b9f785bf98d2ae84cfb262e26f4b2
  • QA integration authority: qa@1dfed7d5c827f992e763c63bfca95324a60af387
  • Operating profile: mk-order
  • Phase implementation: USER HOLD
  • Effects: source inspection and documentation only

1. Purpose

The 2026-08-08 MK refresh resolved the original Trade lineage question and pinned exact Allocation and Scale baselines. Source changed again immediately afterward.

This document owns only the post-refresh delta.

It answers:

What changed in released master after the earlier MK refresh?
What additional behavior exists only in QA?
Which old blockers are closed by source?
Which new source contradictions remain?
Which evidence packages must be extended?

It does not replace the detailed family packets and does not authorize Runtime, DB, role, device or migration changes.

2. Branch Authority

2.1 Release authority

master@baff406d964b9f785bf98d2ae84cfb262e26f4b2

Use this ref for:

  • released-source behavior;
  • current release rollback comparison;
  • operator documentation for an environment proven to run this SHA;
  • release-vs-QA compatibility review.

A remote branch SHA still does not prove a deployed environment is running it.

2.2 Integration authority

qa@1dfed7d5c827f992e763c63bfca95324a60af387

QA includes master and additional unpromoted source changes.

Use it for:

  • integration-candidate review;
  • candidate route/readback semantics;
  • QA-only acceptance design;
  • candidate rollback planning.

Do not describe QA-only behavior as released or operational without exact deployment evidence.

2.3 Intentional non-equivalence

At this review point:

qa ahead of master: 485 commits
master behind qa: 0 independent commits

The large difference contains source changes. Therefore this documentation update must be applied to both branches independently rather than promoting QA source to master.

3. Trade / Cost / Rate / Documents — Released Delta

3.1 Date-filtered Trade projection now retains undated rows

The released Trade Summary query changed its date predicate.

When a From or To date is supplied, the predicate now also includes:

ETA IS NULL
AND ETD IS NULL

Therefore an undated row can appear in every selected date window.

This is a current source fact, not an accepted product policy.

Potential interpretations:

A. undated records must remain visible so they are not lost from operations
B. undated records should be shown in a separate Missing Date group
C. undated records should be excluded from a bounded date report
D. current behavior is a compatibility fallback

Until Product/Accounting accepts one interpretation, the UI and exports must label the behavior explicitly.

Do not describe a date-filtered Trade result as a complete time-bounded financial population without accounting for undated rows.

3.2 Legacy mk-deal-ledger alias repair candidate

The released repository contains:

scripts/migrations/2026-08-05_p2_007_trade_summary_legacy_alias_canonicalize.sql

The script preserves the mk-deal-ledger page key and URL while changing its module owner from:

oms.deal-ledger
-> oms.trade-summary

The migration contains a targeted one-row repair pattern, but its presence does not prove:

  • the migration ran;
  • exactly one row matched;
  • the page/module row is current;
  • menu and role mappings align;
  • the legacy alias is safe to retire.

Applied-state evidence belongs to RBR-TRADE-001.

3.3 Outbound Cost actor guard changed

The released source removed the prior call that required the shared advancedOperations flag before Outbound Cost mutations.

Current effect:

route/page/module/role/record checks outside that removed helper
= remaining authorization boundary

The removal does not prove every authenticated module user is intended to manage Cost. The current Access matrix and role evidence must determine who can:

  • create a Cost transaction;
  • update a Cost transaction;
  • delete a Cost transaction;
  • correct a Cost after downstream use.

Module enabled must not be documented as Cost action authorized.

3.4 Broader Order/Booking mutation scope affects Trade children

Released source also removed several previous basic-operation restrictions from Commercial Order, Inbound, Outbound and Booking write paths.

Examples include removal of source-level restrictions that previously:

  • stripped selected fields for non-advanced roles;
  • blocked Commercial Order deletion for non-advanced roles;
  • blocked line-item deletion for non-advanced roles;
  • required at least one line item in selected atomic-save paths;
  • blocked selected Booking/Equipment-link mutations through the generic Booking form.

These changes are not a Trade Summary formula change, but they change the upstream records from which Trade, Cost, Documents and Export Brokerage derive results.

Required current evidence:

actor
+ page/control visibility
+ API route
+ exact requested field
+ persisted readback
+ child/effect readback

3.5 Reference-preservation behavior

Released shared order logic added update resolvers for Booking and Commercial Order references.

For an existing order, a submitted reference can now result in one of three dispositions:

APPLY NEW VALID REFERENCE
EXPLICITLY UNLINK
IGNORE REQUEST AND PRESERVE CURRENT REFERENCE

An invalid, foreign, stale or wrong-type requested ID may be ignored rather than replacing the stored reference.

Therefore:

HTTP success
!= requested reference applied

Every Save must reread the exact stored Booking/Commercial Order relationship.

Direct generic PATCH and atomic/editor Save may have different rejection behavior; they require separate evidence rows.

3.6 Locked execution bridge behavior

For non-ocean outbound orders with an existing locked execution bridge, released logic preserves existing bridge values for:

  • booking reference;
  • container number;
  • size.

The final release fix normalizes nonpositive current booking values and enforces booking equality only for OCEAN_FREIGHT bridge comparison.

This is intended to prevent unrelated edits from corrupting established execution data, but it means the submitted header is not necessarily the persisted execution bridge.

4. Inventory Allocation — Released Delta

4.1 No direct Allocation command change identified

No direct released change was identified after the 2026-08-08 refresh in the named Allocation Workbench Apply command or its dedicated page/API registration.

The prior source facts remain the current release baseline unless current environment evidence contradicts them:

source lot status OPEN or PARTIAL
received date present
remaining net weight positive
allocation relation persists source lot + target order/item
Apply is a local transaction

4.2 Shared writer changes are material handoff changes

Allocation relies on Inbound source lots and Outbound target orders/items. Released shared writers changed materially around it.

Current handoff questions include:

  • can an Outbound target exist with no line item after atomic Save;
  • can an existing line be deleted by a broader role set;
  • can a Commercial Order or Booking reference submission be ignored while Save succeeds;
  • can the target execution bridge preserve an old value rather than the submitted value;
  • what happens to Allocation relations when an item is removed or an order is changed through a path outside the Workbench;
  • which role owns Cost/Rate changes after an Allocation.

The Allocation Process document must not assume all target-order writes still pass through the restrictions described by the earlier packet.

4.3 Release evidence extension

RBR-ALLOC-001 must add:

ALLOC-DELTA-010  target order with zero active items
ALLOC-DELTA-011  target item deletion authorization and relation result
ALLOC-DELTA-012  invalid Commercial Order reference submitted with otherwise valid Save
ALLOC-DELTA-013  invalid Booking reference submitted with otherwise valid Save
ALLOC-DELTA-014  locked local execution bridge after unrelated order update
ALLOC-DELTA-015  source lot/target item relation after shared writer update

Read-only preflight can identify candidates. Mutating scenarios remain separately authorized.

5. Physical Scale — Released Delta

5.1 Previous Gross-for-all contradiction is closed in source

The earlier Scale discrepancy was:

integrated Check-in writes Gross for every flow
while Sales/Export expect Tare first

Released source now chooses:

Flow Released integrated Check-in prefix
Purchase GROSS
Doortrade GROSS
Sales TARE
Export TARE

Disposition:

SCALE-DISCREPANCY-001
CLOSED IN RELEASE SOURCE

This closes the static prefix-direction conflict only. It does not establish successful Runtime, DB, role or field acceptance.

5.2 Released outbound Tare source remains semantically questionable

Released integrated Check-in calculates a commodityGrossWeight sum and writes it to:

TARE_STEERING_WEIGHT

for Sales and Export because the selected prefix is TARE.

The source does not derive that value from commodity Tare or an explicitly accepted ticket Tare field.

Therefore:

outbound prefix direction = corrected
outbound entry weight provenance = unresolved

Potential impact:

  • a ticket can store a Tare stage numerically equal to the commodity Gross aggregate;
  • commodity and ticket semantics can diverge;
  • later Gross/Tare/Net calculations can appear internally consistent only after compensating input;
  • operator-entered Tare can be overwritten.

This is SCALE-DISCREPANCY-003 and requires controlled source/DB/browser evidence.

5.3 Release integrated Check-out route is absent

Released source exposes:

POST /api/yms/scale/check-out

through the legacy SCALE_OUT handler.

It does not expose:

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

The released Scale workflow smoke, however, waits for /check-out/execute.

Disposition:

SCALE-DISCREPANCY-002
CURRENT RELEASE SOURCE/TEST MISMATCH

This means the existence of the smoke script cannot be used as proof that the released route exists or that integrated Check-out was accepted.

5.4 Released Check-in and legacy Check-out have different command boundaries

Released integrated Check-in owns:

Order Save/Create
+ Item Save
+ Scale In
+ direct link creation inside existing helpers

Released Check-out continues through the legacy Scale Out route, while owner header/item updates and downstream finalize/close may occur through separate calls.

The earlier partial-result and recovery concerns therefore remain relevant for the released Check-out path.

5.5 Role-scoped Booking surface restored only at UI level

The final release fix sets advanced Booking operations in mk-booking-list.php to:

Super Admin
OR effective role 1

This is a UI/page scope. It does not restore every removed backend Order/Booking restriction.

For Scale-linked Booking/Order updates, Page visibility and API authorization must be verified separately.

6. Physical Scale — QA Integration Delta

QA adds behavior not present in the released source.

6.1 Item persistence readback

QA adds an exact count assertion after the Order save:

expected item count
== active persisted T_LOAD_ITEM count

This converts a successful helper response into an explicit item-persistence check for the integrated Check-in path.

6.2 Outbound Check-in weight handling

QA changes integrated Check-in so that:

  • Purchase/Doortrade can auto-populate Gross ticket axle input from commodity Gross;
  • Sales/Export use Tare as the entry prefix;
  • outbound ticket Tare is not overwritten from commodity Gross by the integrated route;
  • Export commodity weights can remain absent/zero under the current candidate policy;
  • non-Export commodity weight validation occurs when weight data is present.

This candidate addresses SCALE-DISCREPANCY-003 differently from released source, but it is not released behavior.

6.3 Integrated Check-out

QA adds:

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

The candidate command:

  1. validates Flow;
  2. validates that the Order and Scale Ticket are linked through the correct inbound/outbound bridge;
  3. saves the current Order header/items;
  4. derives the exit stage where applicable;
  5. performs Scale Out;
  6. returns combined sync tasks.

It does not automatically make Purchase Finalize or every outbound close a single universal transaction.

6.4 Legacy route still exists

QA retains the legacy route:

POST /api/yms/scale/check-out

alongside the integrated route.

Therefore QA currently has two possible Check-out command surfaces.

Required decision:

Which route is authoritative for which caller/cohort?
Which UI calls which route?
Which route owns correction/recovery?
When is the old route caller-zero?
How is rollback performed?

This is SCALE-DISCREPANCY-004.

6.5 QA-only source cannot close release blockers

A QA-only fix can be classified as:

INTEGRATION CANDIDATE
STATICALLY ADDRESSES RELEASE GAP

It cannot be classified as:

RELEASED
DEPLOYED
OPERATIONALLY VERIFIED
ACCEPTED

without promotion and exact environment evidence.

7. Trade And Allocation — QA Integration Delta

QA contains substantial additional changes to shared owners, including:

OMS inbound-order shared helper
OMS outbound cost/helper paths
OMS export-brokerage route
TMS Booking routes
OrderSyncService
Scale portal UI and routes
Capability diagnostics

These changes are not part of the released baseline.

7.1 Trade integration questions

  • Does the Trade projection still compute the same AP/AR/Margin values for the same released rows?
  • Do QA-only Cost helper changes alter owner identity or update eligibility?
  • Does Export Brokerage create/cancel the same child set?
  • Do QA capability definitions alter visibility without changing business authority?
  • Are mk-trade-summary and mk-deal-ledger mapped consistently in QA data?

7.2 Allocation integration questions

  • Does OrderSyncService change source/target projections or link timing?
  • Does the shared inbound helper modify lot creation or balance reconciliation around Allocation?
  • Can a QA target item be recreated, removed or synchronized differently from release?
  • Are Allocation relations preserved when QA synchronization updates order items?
  • Which QA role/capability controls Apply?

These questions extend the candidate review; they do not change the released operator procedure.

8. Revised Discrepancy Register

ID Previous/current issue Disposition
SCALE-DISCREPANCY-001 integrated Check-in used Gross for all flows CLOSED IN RELEASE SOURCE
SCALE-DISCREPANCY-002 release smoke expects integrated Check-out route absent from release Runtime OPEN — SOURCE/TEST MISMATCH
SCALE-DISCREPANCY-003 released outbound Tare uses commodity Gross aggregate OPEN — SEMANTIC/RUNTIME EVIDENCE
SCALE-DISCREPANCY-004 release legacy Check-out vs QA legacy + integrated Check-out OPEN — ONE-WRITER/CUTOVER
TRADE-DISCREPANCY-001 date filter includes undated rows OPEN POLICY
TRADE-DISCREPANCY-002 deal-ledger alias migration candidate not proven applied ENVIRONMENT EVIDENCE
ORDER-DISCREPANCY-001 role-scoped UI vs broadened backend write paths ACCESS EVIDENCE / POLICY
ORDER-DISCREPANCY-002 successful update may preserve current invalid-requested relation READBACK REQUIRED
ALLOC-DISCREPANCY-001 shared target/source writers changed after Allocation packet HANDOFF EVIDENCE

9. Documentation Consequences

The following old statements must no longer be repeated without qualification:

"Sales/Export Check-in currently writes Gross"
-> stale for released master

"Integrated Check-out exists in current release"
-> false for master@baff406...

"A successful reference Save means the requested reference was stored"
-> not established

"Advanced Booking UI scope proves backend write scope"
-> false

"Trade date range excludes undated rows"
-> false in released source

"QA Scale behavior is released behavior"
-> false

10. Current Readiness

post-refresh static source comparison: COMPLETE
release and QA authorities: SEPARATED
old Scale prefix blocker: CLOSED IN SOURCE
new Scale discrepancies: OPEN
Trade/Allocation handoff deltas: DOCUMENTED
read-only evidence addendum: DEFINED
current DB/browser/role/device/Wiki evidence: NOT RUN
M3: NO
M4: NO
Phase progress: NONE

11. Prohibited Conclusions

Do not conclude that:

  • master and QA are functionally equivalent;
  • QA may be merged because its Scale route looks more complete;
  • released Scale is broken in production solely from static source;
  • a smoke script proves a Runtime route;
  • the prior Scale blocker remains unchanged;
  • broad backend role access is approved policy;
  • undated Trade inclusion is an accounting requirement;
  • Allocation is unaffected merely because its dedicated route did not change;
  • a successful Save applied every requested reference;
  • documentation completeness establishes M3 or M4.

12. Next Evidence

The next evidence session, only after separate exact authorization, should run in this order:

1. deployed source identity
2. release/QA route inventory
3. read-only Trade alias/date population
4. read-only Order/Booking reference population
5. read-only Allocation source/target/relation integrity
6. read-only Scale ticket stage and weight provenance
7. controlled role/page/API observation
8. separately authorized command scenarios
9. authoritative readback and cleanup

No repair belongs in the read-only session.

---

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