New-System Work Process Implementation Baseline¶
- Status:
HISTORICAL RECONSTRUCTION RECORD - Record scope: the 2026-09-06 baseline and the follow-up observation of 2026-09-07.
- Source anchor:
qacommit702e9ed26d592f2c4370624a6bb08598cf5456ef— it is the original comparison baseline and does not mean the whole later added observation was executed at this revision. - Target at the time:
new-system/**. Legacy was a read-only comparison basis. - Evidence limit: the source comparison and the stored verification record at the time. It is not a judgement of the current implementation, the role, DB, provider or Production acceptance, or the current work order.
This document is the record that consolidates the implementation and investigation results at the time from the baseline and the follow-up guidance that had described the same work in duplicate. The current requirement is in the system specification, and the real follow-up work and result are in NS3-112. The original at the time is preserved in the baseline and and the follow-up record is pinned and preserved there.
1. Capability baseline¶
| Area | The implementation and observation recorded on 2026-09-06 and 07 | The limit of the evidence at the time |
|---|---|---|
| Booking | the list, filter, create, edit and detail, photos, the Packing and Confirmation display, and conflict and save result recovery | it does not mean the surrounding document issuance and external delivery is complete |
| Transload basic management | the editing of Reference, Load, PO, carrier, appointment, time, equipment, item, quantity, weight, seal, location, state and remarks, plus bulk edit and a re-query | field management and the field command are separate |
| Appointment and Inbound Planning | the list per state, DIP, Check-in and Plan, the plan save, and the link to the dedicated commands below | a state group on a screen is not a state transition, and it is not the acceptance of a full plan apply or assignment |
| Loader | the dedicated source link of Start, Undo and Complete was added in the follow-up record | the Complete not linked in the initial table is an earlier observation. The later source link does not mean the real role or DB acceptance either |
| Timeline and Analysis | the loader and time axis of a selected date, the aggregation, and the administrator time correction | it is separate from a field Start or Complete |
| Email intake | the original request, the proposed schedule and state, and a Reject based on expectedUpdatedAt |
the Approval-to-schedule and the provider reply were incomplete at the time |
| Commercial and Fulfillment | the creation conditions and the source link of Purchase and Sales with the execution order | it is separate from a Loader completion |
| Inventory | the Receipt, Lot, ledger and placement, the edit and cancel, and the allocation and reversal | there remained a gap in the evidence of the real weight preservation and the concurrent edit |
| Export and Import Dispatch and Yard | the commands for the queue, movement, reserve, container, delivery, occupancy, empty, break and equipment | the existence of an API and DB path is separate from the whole UI and field handoff |
| Driver | Check In and Out, a vehicle check, and reading the assigned delivery | Photo, Yard, Arrival, Parking, Actual Spot and the delivery completion are separate |
| Scale | the ticket create, weigh, edit, cancel and history, and a duplicate request, expected time, a sensitive change reason and the event | the Scale processing and the Loader completion are separate |
| Billing and Settlement | the rate, transaction and AR check, and the source fact aggregation | SOURCE_FACTS_ONLY; it is not the acceptance of margin, landed cost or lineage |
The initial table and the command record added later are from different points in time. While consolidating the tables, a past unlinked observation is not carried over as a current defect, and a later source implementation is not promoted to a real work completion.
2. Two separate business flows¶
| The flow compared at the time | The main record and boundary |
|---|---|
| Booking/Transload → Appointment → Check In → Loading Plan → Dock and assignment → Unload and Transload → Complete → the equipment, delivery, time and settlement follow-up processing | T_TRANSLOAD, T_LOADING_PLANNER and the equipment and delivery. Saving the plan, a field transition and the follow-up effect are different commands |
| Commercial Purchase/Sales → an Inbound or Outbound execution order → Scale → Receipt → Lot, ledger and placement → Allocation → execution and settlement | T_COMMERCIAL_ORDER, T_LOAD, T_LOAD_ITEM, T_INVENTORY_LOT, T_INVENTORY_LOT_LEDGER and T_LOAD_ALLOCATION. The atomicity and recovery of Receipt and Allocation are not an alternative evidence of a Loader Complete Unloading |
3. Office, Appointment and Transload command boundary¶
What follows is the linkage recorded at the time including the later source record. A browser mutation, DB read-back, recovery and cleanup of an item with no separate execution record is NOT_RUN.
| Command and screen | The processing recorded in the source at the time | The range that remains separate |
|---|---|---|
| Check In | a dedicated owner with driver and carrier coalescing and planner and carrier sync | the real role, DB and recovery |
| No Show | the non-dock plan is closed from SCHEDULED, PRE_PLANNED or ARRIVED, the automatic inbound queue is cancelled, a cancelled by <operator> <month/day> remark is written, the terminal purchase lot and placement and the Transload placement are closed, and then it is re-queried |
it is distinguished from a normal state edit; the real execution |
| Loading Plan | a tenant-scoped target, Reload, Unload, Transload, Other and Domestic, the Forklift Operator check, deduplication and a maximum of 10, an update of an active SCHEDULED or STARTED or a new SCHEDULED, a lock and a re-query |
only a confirmed 404 means there is no existing plan. It is not a complete preview, apply, submit, confirm and order |
| Dock-in | the eligible Yard location move, the warehouse placement close, and the dock-in plan sync and DOCKED are handled in the same transaction |
the UI, DB and recovery |
| Cancel Dock-in | a started Loader work is rejected, and after the Yard and warehouse are released it becomes AUTO_PLANNED |
the state, no change and recovery |
| Dock-in After Clear | a AUTO:DOCK_IN_AFTER_CLEAR Yard queue entry is created |
the real execution of the queue follow-up |
| Assign and unassign | the Forklift Operator is confirmed by the User UUID, the queue order, AUTO_PLANNED or STAGING → DOCKED, and the active planner is restored on unassign |
a drag write was not inferred from the board display alone |
| Work and Clock Out | a UUID-selected operator, a Legacy work-detail validation, idempotency and per-loader order, the T_LOADING_PLANNER.ASSIGNMENT_DATA save, and a Manual Work Queue re-query |
Telegram is an explicit PENDING; it is not a delivery completion |
| Start Transloading and Unloading | the loading equipment or the active warehouse placement is claimed, the planner starts, a forklift job event is recorded, and the Transload is re-queried | it is not replaced as execution evidence of a Loading Plan or Scale |
| Complete Transloading | the persisted final equipment, 5 TRANSLOAD photos, a valid bale result, and a seal and quantity check; the terminal Transload and equipment, the source placement and Yard, and the planner and staff time are processed |
the real role, DB and recovery are NOT_RUN |
| Complete Unloading | the active warehouse location, the purchase lot materialisation and the Inventory placement handoff, and the Transload placement and Yard cleanup; Complete + Space Review on a linked overflow |
the real role, DB and recovery are NOT_RUN |
| Undo | based on the locked state, ARRIVED→SCHEDULED, DOCKED→ARRIVED, TRANSLOADING, UNLOADING or UNLOADED→DOCKED; the planner and JOB_END, the EMPTY of that equipment, and the placement and Yard are compensated |
returnToAutoPlanned is the path that cancels a pending Yard queue. It is not an arbitrary numeric ID or a full provider rollback |
| Spare Load and Create Spare Bale | the row action and the global creation are separate owners; the source lookup, a positive quantity and whole-pound weight, and the location, lot and ledger and SPARE |
it is separate from a Domestic Pickup. The real mutation and read-back are NOT_RUN |
| Leftover | a global creation with an LFT-* reference and an optional atomic warehouse placement |
the follow-up transition and the real recovery are NOT_RUN |
| Domestic Pickup | an atomic creation of a source and PO match and of T_EQUIPMENT→T_EQUIPMENT_LOAD→ARRIVED/PICKUP |
it is separate from completion, cancel and unit |
| To Warehouse, Scale Ticket and Doc Submitted | a location update, the Scale owner, and a document-submission PATCH | each save is not interpreted as an Unloading, a Loader or a whole work completion |
The Docked screen group, the READY with no start time in the plan, and the OPENED that is started or open are display classifications.
The Start, Call and BOL of Inbound Planning, Break and Telegram, the auto assignment, the queue reorder, and some spare and leftover follow-up transitions were recorded as remaining at the time.
This list is the observation of 2026-09-07 and is not the current list of incomplete items.
4. Planning, assignment and Loader boundary¶
The UI follow-up record of 2026-09-07 is as follows.
| Target | The recorded change | The verification scope |
|---|---|---|
| Loader Timeline | a horizontal loader and time axis of a selected day; the Shift, Loader, Job Type and Time Range filters, work, break and clock blocks, and a Job Detail opener | a selected-day query is not expanded into a multi-day contract. The field execution and the Job Detail read-back are separate |
| Weekly Transload Planner | Create Export Load, the existing Block Manager, the creation of an appointment-prefilled empty cell, the edit of an existing entry, and a UUID PATCH on drag |
a source and focused check record. The authenticated create and move, the DB, the recovery and the deployment are separate |
| Native Dialog | a viewport-bounded body scroll with the header and action footer kept | the WorkspaceDialog with the same geometry was not changed |
| Export Dispatch | a change of the sidebar and My Pages display name of the existing export-dashboard URL |
the route, the data and the operational content are kept |
| Workspace tab overflow | Tab number is stored per signed-in workspace owner, with Alt+1 to Alt+9 |
the tab activation after a number selection was recorded in the existing shell browser scenario and in a live browser |
The weekly Planner was a calendar grid. It was not recorded as a change that added another operations list table.
5. Email, Inventory, Dispatch, Yard, Driver, Scale and Settlement¶
The bounded Reject of an email was distinguished from a provider reply. Inventory Receipt was recorded as validating the source order and item, the remaining quantity, the warehouse, the Scale policy, the order match, Gross, Tare and Net, and the active location, then creating the Lot, ledger and placement, and it was recorded as a path that re-queries after creating the Lot, ledger and placement.
The Receipt edit and cancel preserved the version, the lineage and the Scale owned weight, but a separate proof of the plan and actual weight preservation between the Commercial, the execution order and the Lot, and of the concurrent edit, was left. There was no decision to use the changed execution NET_WEIGHT as the original plan upper bound.
The command source of Dispatch and Yard, the work-record flow of Driver, the correction event of Scale, and the source totals of Settlement are each their own scope. This record has no completion evidence of the whole Loader-to-return handoff, of a real device or provider, or of a confirmed margin and landed-cost policy.
6. Architecture and evidence guardrails¶
This section is the linkage of the observations and decisions at the time and is not a new development instruction.
| Follow-up packet | The recorded result and original | The range that remained at the time |
|---|---|---|
01-transload-operating-screen-decomposition.md |
Transload decomposition record: a 40-line public shell and the screen modules in the same place | the public import, request and behaviour are kept; it is not the acceptance of a field command |
02-platform-api-route-split.md |
Platform route split ADR: a structural scope approval and a completion record | the URL, method, body, response, status, session, tenant and capability are kept; the parity is separate |
03-reduce-use-client-footprint.md |
client footprint investigation: a Step-1 inventory | there is no approval of a wholesale switch without the session-aware server contract and the measurement per screen |
| Role-ID normalization | investigation original | the T_USER.ROLE_ID compatibility is kept. There is no approval to change the T_USER_ROLE schema, query or data |
New-System UI/table boundary¶
The DataTable consumers at the time were Booking, Catalog, Reports, Billing, Export Dispatch, Platform Master, Reference, Admin and Trade and Transload.
The CompactTable was used for the Transload delivery and detail evidence and for the UI Catalog detail. operationsTable.ts was a column adapter, and
operationsCsv.ts was a serialiser and download helper.
The raw <table> investigation figure of 2026-09-07 was 38 = 32 screens + 5 document and export + 1 shared implementation.
Billing Presets, Inventory, Source Reconciliation, the completed Yard Dispatch and Fleet Management were operations list conversion candidates, and
the Planner, the document and export, and the static detail were not in the same category. This figure is not updated to a current measurement.
It is an observation that LegacyTable, DataTableV2 and UnifiedTable had no exact source definition and import caller.
LegacyKjView, the KJ consumers of Platform Master, the admin runtime, Yard and the UI Catalog, and the copied export-dashboard public URL, the dynamic loader and the recovery use were left separately.
It does not mean an asset was deleted from a source search result alone, or that a zero runtime caller is proven.
In CSS, a focused style check and a browser computed-style read-back were recorded for removing a duplicate .ctc-table-wrap radius against the shared primitives of ui.css and contract.css.
A duplicate in operations.css and the page style, a KJ override in globals.css and workspace-theme.css, and a duplicate inventory table-wrap in operational-pages.css were separate candidates.
A broad CSS rewrite or the deletion of a similarly named KJ override was not approved.
7. Development priority¶
What follows is the order proposed at the time. It does not set the execution order or the authority of the current Task.
| Classification at the time | Target |
|---|---|
| P0 the Office Check In, cancel, no-show, Dock and assignment, and the Loader Start, Complete, Undo, spare and leftover | |
| P1 the Driver field actions and the Inventory plan and actual weight and concurrent edit | |
| P2 the document issuance, the provider reply and the settlement integration | |
| P3 the Assignment UX and the calendar, preset and tenant-neutral cleanup |
The follow-up record is gathered in NS3-112. The active Task, manifest and EXECUTION resume instruction and the repeated work procedure that were managed in duplicate from this baseline were removed.
8. Current direct-user restoration directive¶
The previous section titles are kept for existing references. What follows is the historical scope of the 2026-09-06 and 07 request and is not the current authority for further execution.
The request at the time was not only an analysis report but the continuous work of the New-System implementation. The Legacy source and assets were read-only, and the scope was a usable 1:1 confirmation of the approved screen, tab, popup, input, column, filter, CRUD, command, state, follow-up result and recovery. However, replacing the table engine is not making the New-System work content Legacy. There was no Legacy-match obligation for the column and content of Phase-4 page 6, and an approval to resume the already finished P5 Review Queue S3 DataTable migration or to change the column and content was not included.
The real acceptance needed at the time included the authenticated Legacy and New conditions, a step screenshot and log, a DB and downstream read-back and cleanup, and the in-app Wiki.
When there is no role, fixture, provider, physical case or screenshot, the limit of BLOCKED or NOT_RUN is preserved.
This document consolidation neither executed nor waived that acceptance, and it did not re-judge the evidence or approval of an individual Task later.
Source:
new-system/docs/reconstruction/NEW_SYSTEM_WORK_PROCESS_IMPLEMENTATION_BASELINE.md— ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged. A user instruction quoted inside the text is kept in its original language.